Das Sprachmodell und das System darum herum

Eine Antwort, mehrere verborgene Teile

Im letzten Kapitel haben wir Aufgabenarten, Modellfamilien und Systemfamilien getrennt. Jetzt betrachten wir das Sprachmodell und das System, das es für dich nutzbar macht.

Du arbeitest im Einkauf. Vor dir liegt ein neuer Liefervertrag mit 38 Seiten. Du lädst ihn in den KI-Assistenten deiner Firma und fragst: „Welche Kündigungsfristen und Preisrisiken sollten wir prüfen?“ Wenige Sekunden später erscheint eine ordentliche Liste mit Fundstellen.

Wer hat diese Antwort erzeugt?

„Das Sprachmodell“ wäre die kurze Antwort. Das stimmt ungefähr so weit, wie „der Motor“ ein fahrendes Auto erklärt. Der Motor ist wichtig. Allein kommt er trotzdem keinen Meter weit.

Vielleicht hat eine Oberfläche deine Datei angenommen. Eine Suche hat passende Absätze gefunden. Gespeicherte Vorgaben deiner Firma kamen hinzu. Ein Werkzeug hat Datumsangaben berechnet. Kontrollen haben vertrauliche Inhalte und erlaubte Zugriffe geprüft. Erst dann erhielt das Modell seinen Text. Nach der Antwort entschied die Oberfläche, welche Quellen du siehst. Eure Fachabteilung bleibt dafür zuständig, was mit dem Ergebnis geschieht.

Eine sichtbare Antwort kann also aus mehreren verborgenen Teilen entstehen. Dieses Kapitel trennt sie sauber. Das Arbeitspaket aus Anweisungen und Informationen für einen Modellaufruf nennen wir Kontext. Der gezielte Abruf passender Informationen aus einer externen Quelle heißt Retrieval. Für die vollständige Karte verwenden wir immer dieselben Begriffe: Modell, Kontext, Retrieval, Gedächtnis, Werkzeuge, Oberfläche, Evaluierung, Kontrollen und menschliche Verantwortung.

Diese Trennung ist praktisch. Wenn eine Frist falsch ist, reicht „Das Modell war schlecht“ als Erklärung nicht. Vielleicht fehlte die richtige Vertragsseite im Kontext. Vielleicht lieferte das Retrieval den falschen Absatz. Vielleicht rechnete ein Werkzeug mit dem falschen Datum. Oder niemand hatte festgelegt, wer das Ergebnis vor einer Bestellung prüft.

Was ein großes Sprachmodell ist

Ein Sprachmodell verarbeitet Sprache und berechnet, welche Fortsetzung zu einer vorhandenen Folge passt. Die Modelle in diesem Buch sind neuronale Netze. Das sind Rechensysteme mit vielen gelernten Zahlen, die Eingaben durch mehrere Schichten verarbeiten.

Der englische Begriff Large Language Model bedeutet großes Sprachmodell. Meist wird er als LLM abgekürzt. „Groß“ bezieht sich vor allem auf die Zahl der gelernten Parameter. Parameter sind die Zahlenwerte, die sich während des Trainings verändern. Viele davon sind Gewichte. Sie bestimmen, wie stark ein berechnetes Signal das nächste beeinflusst.

Die Größen unterscheiden sich stark. Die GPT-3-Arbeit untersuchte Modelle mit 125 Millionen bis 175 Milliarden Parametern. MobileLLM zeigte später Modelle unter einer Milliarde Parametern für Geräte vor Ort. Bei sogenannten Mixture-of-Experts-Modellen kann die Gesamtzahl noch viel höher liegen. Switch Transformer erreichte bis zu 1,6 Billionen Parameter. Solche Modelle nutzen für eine Eingabe nur ausgewählte Teilnetze. Deshalb sind Gesamtzahl und tatsächlich verwendete Parameter nicht dasselbe.

Mehr Parameter bedeuten nicht automatisch das bessere System für deine Aufgabe. Daten, Modellaufbau, Training, die Software für die Ausführung und Einbindung zählen ebenfalls. Ein kleineres Modell kann bei einem eng begrenzten Prozess reichen. Ein großes Modell kann trotz hoher allgemeiner Leistung an euren Formularen scheitern.

Warum gilt ein Sprachmodell als Generalist? Viele ältere KI-Systeme wurden für eine bestimmte Aufgabe gebaut. Ein Modell erkannte Bilder, ein anderes sortierte Spam. Ein Sprachmodell kann über dieselbe Texteingabe einen Brief entwerfen, Sitzungsnotizen zusammenfassen, ins Spanische übersetzen, Programmcode erklären oder Möglichkeiten für eine Entscheidung ordnen. Es braucht dafür nicht jedes Mal einen neuen Programmaufbau.

Sprache kann Aufgaben, Wissen und Regeln beschreiben. Darin liegt ein großer Teil dieser Bandbreite. Die Ergebnisse bleiben aber Ausgaben eines trainierten Modells. Je nach Folge musst du sie prüfen.

Einige Modelle verarbeiten zusätzlich Bilder, Ton oder Video. Dafür verwenden wir den Begriff multimodal. Ein multimodales Produkt kann ein gemeinsames Modell einsetzen oder mehrere spezialisierte Modelle verbinden. In der Oberfläche sieht beides ähnlich aus. Technisch ist es nicht dasselbe.

Das Modell sagt Token für Token voraus

Ein Sprachmodell arbeitet nicht direkt mit Wörtern. Es zerlegt Text zuerst in Tokens. Ein Token ist ein nummerierter Textbaustein. Das kann ein ganzes Wort sein, ein Wortteil oder ein Satzzeichen. Die genaue Zerlegung betrachten wir im nächsten Kapitel.

Nehmen wir vereinfachend den Anfang „Die Rechnung ist seit 30 Tagen“. Das Modell berechnet nun Wahrscheinlichkeiten für mögliche nächste Tokens. „offen“ könnte 46 Prozent erhalten, „überfällig“ 31 Prozent und ein Satzzeichen einen kleineren Wert. Diese Zahlen sind nur ein Beispiel. Die wirkliche Verteilung hängt vom Modell und vom gesamten Kontext ab.

Das Laufzeitprogramm ist die Software, die das Modell ausführt. Es wählt nach seinen Einstellungen ein Token aus und hängt es an die vorhandene Folge. Das Modell berechnet wieder die möglichen Fortsetzungen. So wächst die Antwort Stück für Stück.

Das erklärt zwei Beobachtungen aus dem Alltag. Erstens kann dieselbe Frage unterschiedliche Antworten ergeben, weil die Auswahl nicht immer nur den höchsten Wert nimmt. Zweitens plant ein gewöhnliches Sprachmodell nicht zuerst einen vollständigen Absatz und schreibt ihn danach ab. Es erzeugt die sichtbare Folge schrittweise.

Aus der Trainingsaufgabe, passende Fortsetzungen vorherzusagen, entstehen viele Fähigkeiten. In großen Textsammlungen stecken Übersetzungen, Erklärungen, Dialoge, Programmcode und zahlreiche Muster für Aufgaben. Beim Training verdichtet das Modell Regelmäßigkeiten daraus in seinen Parametern. Das allgemeine Training heißt Pretraining. Beim späteren Post-Training lernt das Modell zusätzlich aus Beispielen und bewerteten Antworten, Anweisungen besser zu befolgen. Je nach Modell gehören dazu auch Beispiele für Werkzeugaufrufe und Verhaltensregeln.

Die Vorhersage prüft eine Behauptung nicht automatisch gegen eine verlässliche Quelle. Eine sprachlich passende Fortsetzung kann sachlich falsch sein. Retrieval und Werkzeuge können dem System aktuelle oder genaue Informationen geben. Sie ändern aber nichts am Grundschritt des Modells: Es berechnet das nächste Token.

Was in Gewichten gespeichert ist und was erst bei der Nutzung entsteht

Woher kommen die Fähigkeiten? Im Pretraining verarbeitet das Modell große Mengen an Daten und verändert dabei seine Parameter. Veröffentlichte Arbeiten nennen beispielsweise Webtexte, Bücher, Wikipedia und Programmcode. Quellen und Mischung unterscheiden sich je nach Modell. Bei einigen Modellen kommen private oder lizenzierte Datensätze hinzu. Im Post-Training werden außerdem eigens erstellte Beispiele und Bewertungen verwendet. Nicht jeder Anbieter veröffentlicht eine vollständige Liste.

Die gelernten Parameter speichern statistische Zusammenhänge. Sie sind keine ordentlich sortierte Bibliothek mit einem Fach für Verträge und einem Fach für Kochrezepte. Trotzdem können Modelle einzelne Trainingsstellen wiedergeben. Versuche zur Extraktion von Trainingsdaten haben solche fast wörtlichen Wiedergaben gezeigt. „Keine Datenbank“ bedeutet also nicht „keine Erinnerung an einzelne Texte“.

Während einer normalen Anfrage bleiben die Gewichte unverändert. Dein Vertrag trainiert das Modell nicht innerhalb dieses Gesprächs neu. Er beeinflusst die laufende Berechnung über den Kontext. Zu diesem Arbeitspaket können deine Frage, ausgewählte Gesprächsteile, Vertragsabsätze, Systemvorgaben und Ergebnisse von Werkzeugen gehören.

Die drei Speicherorte darfst du nicht vermischen:

• In den Gewichten steckt, was das Training dauerhaft verändert hat.
• Im Kontext steht, was das Modell bei dieser Berechnung berücksichtigen soll.
• Im Gedächtnis speichert das umgebende System Informationen für spätere Aufrufe.

Ein Produkt kann Gesprächsdaten speichern oder später für Training verwenden. Das ist eine eigene Entscheidung über Daten und Training. Daraus folgt nicht, dass die Gewichte sich schon während deiner Antwort verändern.

Pretraining und Inferenz sind ebenfalls verschiedene Vorgänge. Pretraining verändert die Gewichte über sehr viele Rechenschritte. Für große Trainingsläufe rechnen viele Spezialchips parallel. Inferenz nennt man die Nutzung des fertigen Modells für eine Eingabe. Dabei lädt das Laufzeitprogramm die vorhandenen Gewichte und berechnet eine Ausgabe. Das vollständige Pretraining braucht insgesamt viel mehr Rechenarbeit als eine einzelne Anfrage. Bei Millionen Anfragen wird aber auch die Inferenz zu einem großen laufenden Aufwand. Ein kleines, passend komprimiertes Modell kann lokal auf einem leistungsfähigen Rechner laufen. Sehr große Modelle werden meist über mehrere Spezialchips verteilt.

Die vollständige Systemkarte

Im Vertragsbeispiel lassen sich die Teile so benennen. Die Reihenfolge ist keine feste technische Bauanleitung. Manche Systeme lassen Teile weg oder rufen Werkzeuge mehrfach auf. Die Begriffe bleiben trotzdem gleich.

1. Modell. Das Modell nimmt Tokens als Eingabe und berechnet weitere Tokens. Seine Gewichte stammen aus Training und Post-Training. Es ist ein Teil des Systems.

2. Kontext. Das Arbeitspaket für einen einzelnen Modellaufruf enthält nur eine begrenzte Menge an Tokens. Das Kontextfenster bezeichnet diese technische Grenze. Was nicht in den Kontext gelangt und nicht in den Gewichten steckt, kann das Modell bei diesem Aufruf nicht direkt verwenden.

3. Retrieval. Im Vertragsbeispiel ruft es Absätze zu Kündigung und Preisen aus der Vertragsablage ab. Das System fügt die gefundenen Stellen anschließend in den Kontext ein. Diese Verbindung aus Abruf und Antworterzeugung heißt Retrieval-Augmented Generation, kurz RAG.

4. Gedächtnis. Gedächtnis bewahrt Informationen über einen Aufruf hinaus. Das können deine Spracheinstellung, eine Projektentscheidung oder eine Zusammenfassung früherer Gespräche sein. Meist liegt dieses Gedächtnis außerhalb der Modellgewichte. Das System wählt daraus etwas aus und gibt es dem Modell als Kontext.

5. Werkzeuge. Werkzeuge sind Programme oder Dienste, die das System aufrufen kann. Eine Datenbankabfrage liest einen aktuellen Lieferstatus. Ein Rechner bestimmt eine Frist. Ein Kalender legt nach Bestätigung einen Termin an. Das Modell kann einen Aufruf vorschlagen. Ausführen muss ihn die umgebende Software mit passenden Berechtigungen.

6. Oberfläche. Die Oberfläche ist der Teil, den du bedienst. Sie nimmt Text, Sprache oder Dateien an und zeigt Antworten, Quellen sowie Bestätigungen. Sie kann Informationen ausblenden, kürzen oder anders anordnen. Damit beeinflusst sie, was du eingibst und wie du das Ergebnis verstehst.

7. Evaluierung. Evaluierung bedeutet geplante Prüfung mit repräsentativen Fällen und festgelegten Maßstäben. Für den Vertragsassistenten prüfst du nicht nur schöne Formulierungen. Du misst auch, ob das Retrieval die richtige Klausel findet, Fristen stimmen, Quellen sichtbar sind und das System bei fehlenden Unterlagen stoppt.

8. Kontrollen. Kontrollen begrenzen Datenzugriffe und Handlungen. Dazu gehören Rollen, Berechtigungen, Freigaben, Protokolle, Filter sowie Grenzen für Kosten und Laufzeit. Eine Regel im Text kann Verhalten beeinflussen. Eine echte Berechtigung entscheidet technisch, ob ein Werkzeug eine Bestellung auslösen darf.

9. Menschliche Verantwortung. Menschen legen Zweck, erlaubte Daten, Prüfpflichten und Folgen fest. Sie entscheiden auch, wer Fehler untersucht und wer einen Vorgang stoppen darf. Das Modell kann Text erzeugen. Es kann keine Verantwortung für eine Bestellung, eine Kündigung oder einen medizinischen Rat übernehmen.

Ein KI-System ist die vollständige Anwendung aus diesen Teilen. Es kann ein oder mehrere Modelle enthalten. Nicht jedes System braucht Retrieval, Gedächtnis oder Werkzeuge. Oberfläche, Evaluierung, Kontrollen und menschliche Verantwortung verschwinden dadurch aber nicht. Auch eine einfache Schnittstelle hat Nutzer, Testbedingungen und Folgen.

Warum ein Chatprodukt nicht dasselbe ist wie sein Modell

OpenAI veröffentlichte ChatGPT am 30. November 2022. Du öffnest dabei ein Produkt, nicht bloß eine Datei mit Gewichten. Auch Namen wie Claude von Anthropic und Gemini von Google begegnen dir über Produkte und Oberflächen. Welche Modelle und Funktionen dahinter verfügbar sind, können die Anbieter ändern.

Ein Chatprodukt verwaltet Gespräche, Dateien und Konten. Es kann Retrieval, Gedächtnis oder Werkzeuge ergänzen. Es setzt Anweisungen vor deine Eingabe, wählt ein Modell aus und formatiert dessen Ausgabe. Manche Produkte bieten mehrere Modelle unter derselben Oberfläche an. Umgekehrt kann dasselbe Modell über einen technischen Zugang für andere Programme anders wirken als in einer fertigen Chat-Anwendung.

Deshalb sind zwei Aussagen gleichzeitig möglich:

• Das Modell erzeugte die Tokens der Antwort.
• Das Produkt bestimmte einen großen Teil der Bedingungen, unter denen diese Tokens entstanden.

Ein Modellvergleich beantwortet damit nur einen Teil deiner praktischen Frage. Für die Arbeit im Unternehmen zählen auch Quellenanbindung, Datenverarbeitung, Berechtigungen, Bedienung, Messung und Support. Selbst die Größe des Kontextfensters reicht nicht als Produktvergleich. Das Produkt entscheidet, womit es dieses Fenster füllt und welche Teile eines langen Gesprächs es auswählt.

Offene Modelle machen die Trennung besonders sichtbar. Open Weights bedeutet, dass du die trainierten Gewichte herunterladen kannst. Solche Modellpakete findest du beispielsweise auf Hugging Face, einer Plattform für Modelle, Datensätze und Anwendungen. Dazu brauchst du Angaben zum Modellaufbau, die nötigen Dateien für die Zerlegung von Text in Tokens und ein Laufzeitprogramm. Die Lizenz bestimmt, was du verändern, weitergeben oder geschäftlich nutzen darfst. Herunterladbare Gewichte allein machen ein System noch nicht vollständig offen. Trainingsdaten und Trainingscode können fehlen.

Stellt ein Anbieter die Gewichte nicht zum Herunterladen bereit, nutzt du sein Modell meist über dessen Dienst. Andere Programme können über einen solchen technischen Zugang Anfragen senden. Bei sensiblen Daten musst du dann prüfen, welche Inhalte den eigenen Bereich verlassen, wo sie verarbeitet oder gespeichert werden und wer zugreifen darf. Lokale Open-Weights-Ausführung kann diesen Datenfluss begrenzen. Sie macht das System nicht automatisch sicher, datenschutzkonform oder für den Zweck geeignet. Dafür zählen weiterhin Rechenzeit, Geräte, Berechtigungen, Protokolle, Lizenz, Verträge und geltende Regeln.

Für mich wurde der Unterschied beim ersten lokalen Modell greifbar. Ich lud mehrere Gigabyte Gewichte, die Dateien für die Zerlegung des Texts und das nötige Laufzeitprogramm auf meinen Rechner. Dann trennte ich die Internetverbindung und stellte eine Frage. Die Antwort entstand vor mir auf dem eigenen Computer. Meine Eingabe musste dafür keinen fremden Server erreichen. Das sagte noch nichts über die Qualität des Modells. Aber es zeigte sehr deutlich, wo Modell und Produkt auseinanderfallen.

Technischer Exkurs: Gewichte, Architektur, Tokenisierung, Laufzeitprogramm, Aktivierungen und KV-Cache

Für ein lauffähiges Modell reichen Gewichte allein nicht. Das Zerlegen von Text in Tokens heißt Tokenisierung. Das dafür verwendete Programm heißt Tokenizer. Das folgende Bild trennt dauerhaft gespeicherte Teile von Werten einer konkreten Anfrage.

Abbildung 1: Gewichte, Modellaufbau, Tokenizer und Laufzeitprogramm bleiben gespeichert. Bei einer Anfrage führt der gespeicherte Tokenizer die Tokenisierung aus. Tokenfolge, Aktivierungen und KV-Cache entstehen dabei für die konkrete Eingabe und können danach verworfen werden.

Die Gewichte sind gelernte Zahlen. Viele liegen in Matrizen. Eine Matrix ist hier eine rechteckige Tabelle aus Zahlen. Der Modellaufbau heißt Architektur. Sie beschreibt, welche Schichten existieren und wie Zahlen durch sie fließen. Viele heutige Sprachmodelle verwenden eine Transformer-Architektur. Der Transformer verbindet Tokenpositionen über Attention. Attention ist ein Verfahren, mit dem das Modell berechnet, welche früheren Positionen für die aktuelle Verarbeitung wichtig sind.

Der Tokenizer wandelt Text in Token-IDs um. Eine ID ist die Nummer eines Tokens im Vokabular. Nach der Berechnung setzt der Tokenizer die erzeugten IDs wieder zu lesbarem Text zusammen. Ein Modell und ein unpassender Tokenizer gehören nicht einfach zusammen. Die Nummer 812 kann in zwei Vokabularen völlig verschiedene Textbausteine bezeichnen.

Das Laufzeitprogramm führt die Berechnungen aus. Es lädt Architektur, Einstellungen und Gewichte in den verfügbaren Speicher. Es verteilt die Arbeit bei Bedarf auf Prozessoren oder Grafikkarten. Außerdem steuert es die schrittweise Erzeugung und verwaltet vorübergehende Werte.

Diese Zwischenwerte heißen Aktivierungen. Sie entstehen, wenn das Netz eine konkrete Eingabe durch seine Schichten verarbeitet. Andere Tokens erzeugen andere Aktivierungen. Nach der Anfrage werden sie gewöhnlich nicht als Teil des Modells gespeichert. Gewichte sind gelernt und dauerhaft. Aktivierungen sind berechnet und vorübergehend.

Beim Erzeugen des nächsten Tokens müsste ein Transformer viele Ergebnisse für frühere Tokens erneut berechnen. Dafür gibt es den KV-Cache. KV steht für Key und Value, zwei Arten interner Vektoren der Attention. Das Laufzeitprogramm speichert diese Werte für bereits verarbeitete Tokens und verwendet sie beim nächsten Schritt wieder. Der Cache spart Rechenarbeit, braucht aber Speicher und wächst bei vielen Transformer-Modellen mit der verarbeiteten Folge.

Der KV-Cache ist nicht das persönliche Gedächtnis eines Produkts. Er speichert berechnete Vektoren für eine Tokenfolge. Ein Laufzeitprogramm kann diesen Cache manchmal für denselben Anfang einer späteren Anfrage wiederverwenden. Wenn ein Produkt deine Sprachwahl kennt, stammt die Information trotzdem aus seinem Gedächtnis oder erneut bereitgestelltem Kontext. Der Cache spart dann nur die erneute Berechnung.

Prüfe Modell, Datenweg und Betrieb getrennt

Wenn du nur das Modell prüfst, übersiehst du mögliche Fehlerstellen. Ein gutes Modell kann mit schlechtem Retrieval die falsche Vertragsklausel erhalten. Ein gutes Retrieval kann durch zu breite Berechtigungen vertrauliche Dokumente zeigen. Ein fachlich richtiger Entwurf kann Schaden verursachen, wenn die Oberfläche ihn wie eine freigegebene Entscheidung darstellt.

Prüfe deshalb das vollständige System unter Bedingungen, die eurem Betrieb ähneln. NIST nennt dafür sinngemäß vier fortlaufende Aufgaben: steuern, einordnen, messen und behandeln. Für deinen Anwendungsfall heißt das ganz praktisch:

• Lege fest, welche Aufgabe das System übernehmen soll und welche ausdrücklich nicht.
• Teste echte, anonymisierte oder künstlich erstellte Fälle aus eurem Prozess.
• Prüfe Modell, Kontext, Retrieval, Gedächtnis, Werkzeuge und Oberfläche gemeinsam.
• Setze Kontrollen passend zur möglichen Folge eines Fehlers.
• Benenne Menschen für Freigabe, Überwachung, Beschwerden und Abschaltung.

Die Verantwortungsgrenzen sollten vor dem Pilotbetrieb sichtbar sein. Der Modellanbieter entscheidet über Entwicklung und Dokumentation des angebotenen Modells. Der Produktanbieter oder das interne Produktteam baut Kontext, Retrieval, Gedächtnis, Werkzeuge und Oberfläche zusammen. Eure Organisation bestimmt Zweck, Datenzugriff, Freigaben und akzeptables Risiko. Die Person im Prozess muss wissen, was sie prüfen muss und wann sie das Ergebnis weitergeben darf.

Das ist keine pauschale juristische Zuordnung. Verträge und Gesetze können Pflichten anders verteilen. Es ist eine Arbeitskarte. Ohne diese Karte bleibt nach einem Fehler nur eine Runde gegenseitiger Verweise.

Allgemeine Ranglisten ersetzen diese Evaluierung nicht. Ein Modell kann in einem öffentlichen Test gut abschneiden und trotzdem eure Artikelnummern verwechseln. Ein anderes schreibt weniger elegant, findet aber mit eurem Retrieval zuverlässig die gültige Arbeitsanweisung. Für den Prozess zählt das Systemergebnis.

Trenne die Teile des Systems

Du solltest die neun Begriffe jetzt an einem beliebigen KI-Produkt finden können. Nimm ruhig den Assistenten, den du im Alltag nutzt, und beantworte diese Fragen:

1. Welches Modell erzeugt die Ausgabe, und kann das Produkt dieses Modell wechseln?
2. Was gelangt für eine Anfrage in den Kontext?
3. Welche Informationen kommen durch Retrieval oder Gedächtnis hinzu?
4. Welche Werkzeuge dürfen lesen, rechnen oder etwas verändern?
5. Was zeigt oder verschweigt die Oberfläche?
6. Mit welchen Fällen wurde das vollständige System evaluiert?
7. Welche Kontrollen begrenzen Datenzugriff und Handlungen?
8. Wer trägt wofür die menschliche Verantwortung?

Ein letzter Unterschied hilft beim Prüfen: Gewichte, Architektur und Tokenizer gehören zum geladenen Modellpaket. Kontext, Aktivierungen und KV-Cache entstehen bei der Nutzung. Retrieval, Gedächtnis, Werkzeuge, Oberfläche, Evaluierung und Kontrollen liegen um das Modell herum.

Als Nächstes betrachten wir den ersten Schritt jeder Texteingabe genauer. Wie wird aus „Kündigungsfrist“ eine Folge von Nummern, mit der das Modell rechnen kann? Dafür müssen wir Tokens und den Tokenizer verstehen. Danach folgen Embeddings, Attention, Training und die Grenzen der Modelle.