Drei Quellen, aus denen ein Modell sein Wissen bezieht

Ein Sprachmodell hat im Grunde drei Wissensquellen, zwischen denen man sauber trennen sollte.

Erstens das Pretraining. Das Modell wird auf einer enormen Menge öffentlich verfügbarer Texte darauf trainiert, das jeweils nächste Token vorherzusagen. Aus Milliarden solcher Vorhersagen entsteht ein statistisches Abbild dessen, wie Sprache und Fachwissen in diesem Textkorpus verteilt sind. Was oft und konsistent geschrieben wurde, ist stark repräsentiert. Was selten vorkommt, ist schwach repräsentiert. Was nie öffentlich geschrieben wurde, ist gar nicht vorhanden.

Zweitens das Nachtraining. Instruction-Tuning und Verfahren wie RLHF formen, wie das Modell antwortet: hilfsbereit, strukturiert, im gewünschten Ton. Das verändert das Verhalten, aber kaum den Faktenbestand.

Drittens das Kontextfenster. Alles, was du im Chat einfügst oder was ein System zur Laufzeit dazulädt. Das ist die einzige Stelle, an der aktuelles Wissen überhaupt eintreten kann.

Was daraus für Kanzleiwissen folgt

Deutschsprachige Fachinhalte sind im Trainingskorpus ein kleiner Anteil, deutsches Steuerrecht ein noch kleinerer. Ein Modell kennt deshalb die grobe Systematik gut, verliert aber an Präzision, je spezieller die Frage wird.

Für internes Kanzleiwissen ist die Lage eindeutig: Eure Bewertungspraxis, eure Textbausteine, eure Prüf-Checklisten, die Historie eines konkreten Mandanten, die Position, die ihr in der letzten Betriebsprüfung vertreten habt - dieser Text war nie öffentlich (zumindest hoffe ich das). Er kommt im Trainingskorpus mit Häufigkeit null vor. Kein Prompt der Welt holt Informationen aus Gewichten, in die sie nie eingeflossen sind.

Dazu kommt ein Effekt, der selten benannt wird: Das Modell optimiert auf die statistisch typische Fortsetzung. Es liefert dir also die durchschnittliche Antwort aus dem Korpus. Bei einer allgemeinen Frage ist der Durchschnitt eine gute Antwort. Bei der Frage, wie ihr diesen Mandanten behandelt, ist der Durchschnitt der falsche Maßstab.

Fünf technische Effekte, die du im Alltag siehst

Sampling erzeugt Varianz. Das Modell berechnet für jedes nächste Token eine Wahrscheinlichkeitsverteilung und zieht daraus eine Stichprobe. Parameter wie Temperature und Top-p steuern, wie breit gezogen wird. Deshalb bekommst du auf dieselbe Frage zweimal eine leicht andere Antwort. Selbst bei greedy decoding bleiben in der Praxis kleine Abweichungen, weil Batching und Fließkomma-Arithmetik auf GPUs nicht bitgenau reproduzierbar sind. Für Dokumentation und Vier-Augen-Prinzip ist das relevant.

Der Wissensstand ist eingefroren. Jedes Modell hat einen Trainings-Cutoff. Änderungen durch ein Jahressteuergesetz oder ein neues BMF-Schreiben danach sind schlicht nicht enthalten. Problematischer als die Lücke selbst: Das Modell hat kein zuverlässiges internes Signal dafür, dass es die Lücke hat, und antwortet häufig im gleichen souveränen Ton weiter.

Aufmerksamkeit verteilt sich ungleich. Über lange Eingaben gewichtet der Attention-Mechanismus Anfang und Ende stärker als die Mitte. Der Effekt ist als „lost in the middle" gut belegt. Ein Kontextfenster von 200.000 Token bedeutet nicht, dass 200.000 Token gleich sorgfältig verarbeitet werden. Bei einem 80-seitigen Prüfbericht ist es gut möglich, dass die Seiten in der Mitte vom LLM weniger stark beachtet werden.

Zahlen sind für den Tokenizer nur Text. Ein Modell zerlegt „1.247,83" in mehrere Token und rechnet nicht, es setzt Zeichenfolgen fort. Bei Beträgen, Steuer-IDs und IBANs ist das eine ernstzunehmende Fehlerquelle. Rechnen gehört in deterministischen Code, nicht ins Modell. Allerdings sei an dieser Stelle angemerkt, dass mittlerweile die meisten LLMs zu diesem Zweck intern auf Werkzeuge zugreifen können, um Berechnungen durchzuführen. Sie lagern den Prozess also aus.

Das Trainingsziel ist Plausibilität, nicht Korrektheit. Ein Modell wurde darauf optimiert, überzeugende Fortsetzungen zu erzeugen. Eine flüssig formulierte, gut strukturierte, falsche Antwort ist aus Sicht der Zielfunktion kein Fehlerfall. Confidence im Text und Korrektheit im Inhalt sind entkoppelt.

Vier Wege, Kanzleiwissen ins System zu bekommen

Im Grunde genommen lässt sich das, was den Modellen fehlt, mit einem Wort zusammenfassen: Kontext. Nämlich Kontext eurer Kanzlei. Je mehr relevanten Kontext ein Modell bekommt, desto bessere Ergebnisse liefert es am Ende. Nun gibt es verschiedene Möglichkeiten, dem Modell mehr Kontext über eure Kanzlei, eure Mandanten sowie eure Arbeitsroutinen zu geben.

Copy&Paste. Sicherlich nicht die eleganteste Lösung, aber in gewissen Arbeitsschritten durchaus hilfreich. Reichert den Prompt mit Kontext an; beschreibt den Sachverhalt so genau wie möglich und gebt dem Modell Hintergrundwissen. Achtet dabei strikt auf sensible Informationen.

Retrieval. Diverse KI-Tools wie z.B. unsere momentum Suite bieten spezielle Wissensspeicher an, die deine Dokumente in Abschnitte zerlegen, in Vektoren überführen und bei jeder Anfrage die passenden Abschnitte in den Kontext des Modells laden. Technisch der sinnvollste Weg für Fakten, weil sich Quellen belegen und Inhalte jederzeit ändern lassen. Der Engpass liegt in der Retrieval-Qualität: Wie wird eine Bilanz zerlegt, ohne Struktur zu zerstören? Findet das Embedding-Modell zu „Pensionsrückstellung" auch die relevante Passage, wenn dort „Zusage nach § 6a EStG" steht? Genau hier entscheidet sich die Qualität, nicht am Modell dahinter. Wir optimieren unsere Wissensdatenbank der momentum Suite dahingehend stetig weiter, sodass wir eine zunehmend bessere Qualität erzeugen können.

Fine-Tuning. Gut geeignet, um Form, Ton und Struktur zu lernen, etwa euren Schreibstil gegenüber Mandanten. Für Fakten ist es unzuverlässig und teuer. Und es hat einen Haken, den viele übersehen: Was in die Gewichte eingegangen ist, lässt sich nicht selektiv wieder entfernen. Ein Löschverlangen nach Art. 17 DSGVO ist damit technisch kaum sauber erfüllbar. Außerdem sind die technischen Hürden für die meisten Kanzleien hoch.

Orchestrierung. Der Teil, der nach außen unsichtbar bleibt und am meisten bringt. Ein langes Dokument wird in definierte Prüfschritte zerlegt, jeder Schritt bekommt nur den Ausschnitt, den er braucht, Zwischenergebnisse werden geprüft, Berechnungen laufen in Code. Damit legst du eine deterministische Struktur um einen probabilistischen Kern. Die wenigsten Tools gehen so vor.

Warum das direkt ein Berufsrechtsthema ist

An dieser Stelle sei erneut darauf hingewiesen, dass relevanter Kontext in einer Kanzlei häufig Mandantendaten enthält. Damit sind § 203 StGB und die DSGVO im Spiel, bevor über Nutzen überhaupt gesprochen wird.

Technisch entscheidet sich das an wenigen Punkten: Werden Steuer-IDs, IBANs und Klarnamen maskiert, bevor der Text die Kanzlei verlässt? Wo wird gehostet? Ist der Ausschluss vom Training vertraglich und technisch belegt? Existieren Rechte, Protokollierung und ein funktionierender Löschpfad?

Wir haben die Anonymisierung deshalb vor die Verarbeitung gelegt und die Wissensbasis an bestehende Ablagen wie SharePoint oder das DATEV DMS angebunden. Der Weg über Copy-Paste ins private Chatfenster erzeugt exakt das Risiko, das ihr vermeiden wollt — und läuft in vielen Kanzleien längst mit.

Der Engpass ist eure Datenlage

Am Ende lässt sich sagen, dass die Modellwahl inzwischen der einfachere Teil ist. Ob ein KI-Projekt in der Kanzlei wirklich läuft, entscheidet sich an anderen Fragen: Wie sind eure Dokumente abgelegt und wie zuverlässig sind sie benannt? Existieren Prüfroutinen als geschriebene Schritte oder als Erfahrung einzelner Personen? Welcher Prozess ist stabil genug, um überhaupt automatisiert zu werden? Und kann all dieser Kontext einem Modell zur Verfügung gestellt werden?

Bei diesen Fragen helfen wir gerne weiter und entwickeln mit euch eine KI-Strategie, die zu eurer Kanzlei passt.