Das Modell lügt nicht. Es kann nicht lügen. Aber es erfindet.
Wenn Sie einem Large Language Model eine Frage stellen – sagen wir, nach dem Geburtsdatum eines obskuren Physikers aus dem 19. Jahrhundert oder nach der Autorin eines kaum bekannten Romans – dann antworten Sie nicht auf eine Datenbank. Sie reden mit einem statistischen Mustererkennungssystem, das in diesem Moment eine Wahrscheinlichkeitsrechnung durchführt. Es berechnet, welche Token-Sequenz am plausibelsten auf Ihre Eingabe folgen würde, basierend auf Milliarden von Textbeispielen, die es während des Trainings gesehen hat.
Das klingt nach einem Detail. Ist es aber nicht.
Denn daraus folgt eine fundamentale Eigenschaft, die jeder verstehen muss, der produktionsnahe KI-Anwendungen bauen will: Ein LLM zielt nicht auf Wahrheit. Es zielt auf Plausibilität. Und die beiden sind nicht dasselbe.
Würden wir eine Autocompletion für Texte bauen – aber eine, die nicht nur das nächste Wort vorhersagt, sondern ganze Absätze, Argumente, Geschichten. Sie trainieren dieses System auf einem riesigen Korpus an Texten aus dem Internet, aus Büchern, aus wissenschaftlichen Arbeiten. Das System lernt nicht Fakten. Es lernt Muster. Es lernt, dass nach „Die Hauptstadt von Frankreich ist” mit hoher Wahrscheinlichkeit das Token „Paris” folgt. Es lernt, dass wissenschaftliche Abstracts bestimmte Formulierungen verwenden, dass Geschichten narrative Bögen haben, dass technische Dokumentation einen bestimmten Tonfall pflegt.
Was es nicht lernt: ob Paris tatsächlich die Hauptstadt von Frankreich ist. Es lernt nur, dass diese Token-Folge in den Trainingsdaten extrem häufig gemeinsam auftritt.
Dieser Unterschied wirkt zunächst akademisch. Aber er erklärt das Verhalten, das wir bei LLMs beobachten: Sie können überzeugend klingende Antworten generieren, die vollständig erfunden sind. Sie können Quellenangaben für Artikel liefern, die nie existiert haben. Sie können technische Zusammenhänge beschreiben, die physikalisch unmöglich sind – solange die sprachliche Struktur dieser Beschreibung den gelernten Mustern entspricht.
Nehmen wir ein konkretes Beispiel. Sie fragen ein Modell nach der Biografie von Dr. Elisabeth Müller-Sternberg, einer angeblich bekannten deutschen Quantenphysikerin der 1950er Jahre. Das Modell antwortet detailliert: geboren 1922 in Heidelberg, Promotion 1947 in München, wichtige Arbeiten zur Wellenfunktion des Elektrons, Lehrstuhl in Göttingen ab 1955. Die Antwort klingt sachlich, die Namen folgen deutschen Namenskonventionen, die Jahreszahlen passen zur historischen Periode, die akademische Karriere entspricht den üblichen Mustern der Nachkriegszeit.
Nur: Die Person existiert nicht. Und hat auch nie existiert.
Was ist passiert? Das Modell hat aus den Mustern, die es über Biografien deutscher Wissenschaftlerinnen dieser Ära gelernt hat, eine plausible Fortsetzung generiert. Es hat typische Orte eingesetzt, realistische Jahreszahlen, fachlich passende Forschungsgebiete. Die Antwort ist kohärent, stilistisch korrekt, inhaltlich stimmig – und vollständig erfunden.
Das ist keine Fehlfunktion.
Das ist das System bei der Arbeit. Es berechnet Wahrscheinlichkeiten. Und die Wahrscheinlichkeit, dass eine deutsche Quantenphysikerin der 1950er Jahre in Heidelberg geboren wurde, eine Promotion in München machte und später einen Lehrstuhl in Göttingen innehatte, ist – rein sprachstatistisch – durchaus hoch. Diese Kombination entspricht den Mustern der Trainingsdaten.
Dass diese spezifische Person nie existiert hat, kann das Modell nicht wissen. Es hat keinen Zugriff auf eine Faktendatenbank. Es hat keine Möglichkeit zu prüfen, ob etwas wahr ist. Es kann nur berechnen, ob etwas wahrscheinlich klingt.
In der Diskussion über LLMs fällt oft der Begriff der “Halluzination”. Und er ist treffend – aber er suggeriert etwas Falsches, wenn man ihn nicht richtig einordnet. Eine Halluzination klingt nach Fehler, nach etwas, das man beheben könnte, nach einem Defekt im System.
Tatsächlich ist es eine inhärente Eigenschaft der Funktionsweise.
Ein LLM kann nicht unterscheiden zwischen einer Aussage, die durch Daten belegt ist, und einer Aussage, die nur sprachlich plausibel klingt. Es hat keine epistemische Grenze, keine innere Stimme, die sagt: “Das weiß ich nicht.” Es hat nur Wahrscheinlichkeiten. Wenn Sie es nach etwas fragen, zu dem die Trainingsdaten wenig oder widersprüchliche Informationen enthalten, dann generiert es trotzdem eine Antwort – weil das seine Aufgabe ist. Es vervollständigt Muster.
Und hier wird es für uns als Entwickler relevant: Das Modell lügt nicht, weil es keine Absicht hat. Es kann nicht täuschen wollen. Es führt einfach eine Berechnung durch. Aber das Ergebnis dieser Berechnung kann eine Aussage sein, die faktisch völlig falsch ist, während sie sprachlich perfekt klingt.
Das macht LLMs gleichzeitig faszinierend und gefährlich. Sie beherrschen die Form der Sachlichkeit perfekt. Sie können im Stil wissenschaftlicher Paper schreiben, im Tonfall juristischer Gutachten, in der Sprache technischer Dokumentation. Diese stilistische Sicherheit erzeugt Vertrauen. Wir sind darauf trainiert, sachlich klingenden Texten zu vertrauen, besonders wenn sie Fachterminologie verwenden, Quellenangaben liefern, in klaren Strukturen argumentieren.
Aber diese Form garantiert nichts über den Inhalt.
Ein Modell kann Ihnen mit perfekter Syntax und akademischem Vokabular ein Forschungsergebnis präsentieren, das nie publiziert wurde. Es kann eine API-Dokumentation schreiben für eine Funktion, die nicht existiert. Es kann einen Rechtsfall zitieren, den es nie gab – mit Aktenzeichen, Datum, Gericht, allem.
Warum? Weil es nicht die Existenz dieser Dinge überprüft. Es überprüft nur, ob die Token-Sequenz wahrscheinlich ist. Und die Sequenz “Bundesgerichtshof, Urteil vom 15. März 2019, Az. V ZR 42/18” ist strukturell absolut plausibel. Deutsche Gerichtsaktenzeichen folgen einem klaren Muster. Das Modell hat dieses Muster gelernt. Dass dieses spezifische Urteil vielleicht nie gefällt wurde, spielt in der Token-Berechnung keine Rolle.
Sie bauen ein System, das LLMs nutzt? Dann müssen Sie von folgender Annahme ausgehen: Jede faktische Aussage des Modells ist potenziell erfunden. Nicht wahrscheinlich erfunden, nicht manchmal erfunden – potenziell immer.
Das klingt radikal. Aber es ist die einzige sichere Grundlage für produktionsnahe Anwendungen.
Das bedeutet konkret: Sie können einem LLM nicht die Aufgabe übertragen, faktische Informationen zu liefern, ohne diese Informationen zu validieren. Sie können es nicht fragen “Wann wurde Kunde X zuletzt kontaktiert?” und die Antwort direkt weiterverwenden. Sie können es nicht bitten, “die drei relevantesten Paragraphen aus dem Vertragswerk” zu identifizieren, ohne zu prüfen, ob diese Paragraphen existieren und tatsächlich relevant sind.
Was Sie tun können: Das Modell nutzen, um Daten zu transformieren, die Sie bereits haben. Um Texte zusammenzufassen, deren Inhalt Sie kontrollieren. Um Muster in Daten zu erkennen, deren Validität Sie überprüfen können. Um Code zu generieren, den Sie reviewen und testen werden.
Die Stärke von LLMs liegt in der Mustererkennung und -anwendung, nicht in der Faktenwiedergabe. Sie sind hervorragend darin, Texte umzuformulieren, Stile zu adaptieren, strukturelle Transformationen vorzunehmen. Sie sind miserabel darin, zu sagen, was wahr ist.
In der Praxis bedeutet das: Sie müssen Ihre Architektur so aufbauen, dass sie die Grenzen des Modells kompensiert. Retrieval-Augmented Generation ist ein solcher Ansatz – Sie geben dem Modell zunächst relevante, verifizierte Informationen aus Ihrer eigenen Datenbasis, bevor es antwortet. Das Modell kann dann diese Informationen nutzen, umformulieren, strukturieren – aber es erfindet nicht mehr aus dem Nichts heraus.
Oder Sie bauen Validierungsschritte ein. Das Modell generiert eine Antwort, aber bevor diese Antwort an den Nutzer geht, prüft Ihr System: Sind die zitierten Quellen echt? Sind die genannten Daten in der Datenbank vorhanden? Passt die Aussage zu dem, was wir tatsächlich wissen?
Oder Sie nutzen das Modell nur für Aufgaben, bei denen faktische Korrektheit zweitrangig ist. Brainstorming. Ideengenerierung. Textvariationen. Stilistische Überarbeitungen. Alles Bereiche, in denen Plausibilität ausreicht.
Die entscheidende Erkenntnis ist: Man muss das Verhalten des Modells verstehen, um zu wissen, wofür man es einsetzen kann. Und man muss akzeptieren, dass dieses Verhalten nicht änderbar ist. Ein größeres Modell, besseres Training, mehr Parameter – all das macht die Antworten plausibler, kohärenter, stilistisch überzeugender. Aber es macht sie nicht wahrer.
Das klingt ernüchternd. Und in gewisser Weise ist es das auch. LLMs sind keine allwissenden Orakel. Sie sind sehr gute Mustervervollständiger, mehr nicht.
Aber genau diese Entzauberung ist produktiv. Denn sie hilft uns, die Werkzeuge dort einzusetzen, wo ihre Stärken liegen – und nicht dort, wo ihre Schwächen zum Risiko werden. Sie hilft uns, Systeme zu bauen, die nicht darauf vertrauen, dass das Modell “die Wahrheit sagt”, sondern die prüfen, validieren, kontrollieren.
Am Ende ist es wie mit jedem Werkzeug: Man muss verstehen, wie es funktioniert, um es sinnvoll einzusetzen. Ein Hammer ist hervorragend darin, Nägel einzuschlagen. Schrauben einzudrehen ist nicht seine Stärke. LLMs sind hervorragend darin, sprachliche Muster zu vervollständigen. Fakten zu verifizieren ist nicht ihre Stärke.
Und genau das braucht es, wenn wir im nächsten Schritt Prompts gestalten wollen, die mit dieser Realität umgehen können.