Große Sprachmodelle schreiben flüssigen Text über fast alles. „Flüssig“ ist das Stichwort: Es beschreibt, wie der Text klingt, nicht, ob er stimmt.
Kurz gesagt
Ein Large Language Model (LLM, großes Sprachmodell) ist ein Programm, das mit riesigen Textmengen trainiert wurde, um vorherzusagen, welcher Text als Nächstes kommt. Deshalb schreibt es überzeugend klingende Texte, kann aber Falsches mit großer Sicherheit behaupten und arbeitet nur mit dem, was ihm gerade vorliegt. Behandle seine Antworten als Entwürfe, die du prüfen musst.
So funktioniert’s
- Tokens: Ein Modell liest nicht Buchstaben oder ganze Wörter. Es arbeitet mit Tokens, den kleinsten Einheiten, die es verarbeitet. Das können Wörter, Wortteile, einzelne Zeichen oder sogar Bytes sein.
- Vorhersage: Beim Vortraining lernen solche Modelle, das nächste Wort anhand des vorherigen Textes vorherzusagen. NIST formuliert es so: Generative Modelle nähern die statistische Verteilung ihrer Trainingsdaten an, und LLMs sagen das nächste Token voraus. Das kann treffende und stimmige Texte ergeben, genauso gut aber falsche oder in sich widersprüchliche.
- Die Architektur: Der 2017 vorgestellte Transformer beruht allein auf Aufmerksamkeitsmechanismen und kommt ohne die zuvor üblichen rekurrenten oder faltenden Netze aus.
- Das Kontextfenster: Es umfasst alles, was das Modell beim Schreiben einer Antwort ansehen kann, die Antwort selbst eingeschlossen. Anthropic nennt es einen „Arbeitsspeicher“, verschieden von den Daten, mit denen das Modell trainiert wurde. Systemanweisung, jede Nachricht, Werkzeugergebnisse, Dokumente und Werkzeugdefinitionen zählen mit. Mehr Kontext ist nicht automatisch besser: Mit wachsender Tokenzahl lassen Genauigkeit und Erinnerungsvermögen nach.
- Konfabulation: NIST nennt so selbstsicher vorgetragene, aber falsche Inhalte, auch „Halluzinationen“ genannt. Sie sind eine natürliche Folge der Bauweise dieser Modelle. Selbst Erklärungen und Quellenangaben, die ein Modell zu seiner Antwort liefert, können konfabuliert sein.
- Keine Wiederholungsgarantie: Selbst mit dem Parameter Temperatur auf 0 können identische Eingaben unterschiedliche Ausgaben liefern.
- Verankerung: Retrieval-Augmented Generation (RAG) legt Dokumente, die zur Abfragezeit gefunden werden, ins Kontextfenster, damit sich die Antwort auf Belege stützt statt auf das Gedächtnis des Modells. Wie gut das gelingt, hängt von der Qualität des gefundenen Materials ab.
- Werkzeuge und Agenten: Kann ein LLM Werkzeuge aufrufen, kann eine manipulierte oder unklare Ausgabe schädliche Aktionen auslösen (OWASP nennt das Excessive Agency), und speziell gebaute Eingaben können das Verhalten des Modells ändern, auch wenn Menschen sie nicht sehen (Prompt Injection). OWASP empfiehlt eine Kontrolle durch einen Menschen (Human in the Loop), der folgenreiche Aktionen freigibt, bevor sie passieren.
In der Praxis
Ein einfaches Muster, wenn du dem Modell einen Text zum Arbeiten gibst:
Antworte nur anhand des folgenden Textes. Steht die Antwort nicht darin, sag „steht nicht im Text“.
Zitiere den Satz, den du benutzt hast.
<dein Text>Das erleichtert die Kontrolle, weil du den zitierten Satz nachschlagen kannst. Eine richtige Antwort garantiert es nicht, also prüfst du sie trotzdem. Bei Bytearium spielen Sprachmodelle in zwei Projekten eine Rolle: Byte, unser KI-Maskottchen (in Arbeit), und das geplante KI-Agentenstudio. Die KI-Assistenten, die uns beim Betrieb von Bytearium helfen, arbeiten nach schriftlichen Regeln: Aussagen brauchen Belege, und Veröffentlichen, Geld ausgeben, Verträge und Kontoänderungen sind allein Leons Sache. Byte hält öffentlich eine ähnliche Linie: Er verspricht nichts, was nicht belegt ist. Das alles sagt nichts darüber, wie gut oder zuverlässig ein bestimmtes Modell ist, und wir behaupten das auch nicht.
Eines zu Hause betreiben: was die Zahlen auf dem Etikett bedeuten
Offen gewichtete Modelle erscheinen mit einer Parameterzahl (7B, 9B, 70B: Milliarden Gewichte) und, wenn sie für den lokalen Betrieb verpackt sind, mit einer Quantisierung wie Q4_K_M. Quantisierung senkt die Genauigkeit der gespeicherten Gewichte, zum Beispiel von 16-Bit-Zahlen auf 4-Bit-Ganzzahlen; das verkleinert die Datei und kann die Inferenz beschleunigen, auf Kosten von etwas Genauigkeit. Das Projekt llama.cpp, dessen GGUF-Format die meisten Heim-Setups nutzen, misst diesen Verlust als Perplexität oder KL-Divergenz. Die Faustregel: Speicherbedarf ≈ Parameter × Bytes je Gewicht, plus Platz für den Kontext. Ein 9B-Modell braucht bei 16 Bit rund 18 GB, bei 4 Bit grob 5 GB, und das passt auf eine Laptop-GPU. Genau so betreiben wir das Modell für Byte auf einem eigenen Laptop in unserem Netz statt auf dem Streaming-PC: ein Modell mit 9 Milliarden Parametern, 4-Bit-quantisiert, über llama.cpp im LAN bereitgestellt.
Woran du ein brauchbares lokales Setup erkennst
Drei Fragen vor dem ersten Prompt: Passt das Modell samt Kontext in den Grafikspeicher, oder lagert es in den Arbeitsspeicher aus und wird um ein Vielfaches langsamer? Wie viele Token je Sekunde liefert es bei deiner typischen Anfrage, gemessen, nicht geschätzt? Und wer darf den Dienst im Netz erreichen, denn ein Modellserver ohne Zugangsschutz beantwortet jedem alles, was er gelernt hat.
Was „lokal“ dir bringt und was nicht
Ein Modell auf eigener Hardware behält Prompts und Dokumente im Haus, kostet nichts pro Anfrage und arbeitet weiter, wenn das Internet es nicht tut. Wahrer wird das Modell dadurch nicht: Konfabulation, Prompt-Injection und die Kontextgrenze gelten genauso wie bei einem gehosteten, und ein kleineres, quantisiertes Modell konfabuliert in der Regel mehr, nicht weniger. Behandle das lokale Modell als schnelles Entwurfswerkzeug mit denselben Prüfregeln, und führe ein Protokoll über Modelldatei, Quantisierung und Prompt, damit sich ein Ergebnis nach dem nächsten Update nachstellen lässt.
Prüfliste
- Prüfe eine Antwort gegen ihre Quelle, bevor du sie weitergibst, und halte Antwort und Beleg auseinander.
- Gib dem Modell den Text, aus dem es arbeiten soll, und lass es zitieren, was es benutzt hat.
- Halte fest, welches Modell, welche Anweisungen und welche Dokumente ein Ergebnis erzeugt haben, damit du es nachvollziehen kannst.
- Setze Grenzen für Tokens, Zeit und Kosten, bevor du ein Modell unbeaufsichtigt laufen lässt.
- Lege fest, wer folgenreiche Aktionen freigibt, und mach diesen Schritt verbindlich.
- Teste den Aufbau mit Aufgaben, die deinen echten ähneln, und nimm Fälle auf, in denen das Modell ablehnen soll.
- Halte bei einem lokalen Modell Dateiname, Quantisierung und den tatsächlich belegten Speicher fest.