Die falsche Problemstellung
Jeder gibt dem Modell die Schuld wenn ein Agent halluziniert. "GPT-4 hat sich etwas ausgedacht." "Claude hat eine Funktion erfunden die nicht existiert." "Das Modell ist unzuverlässig."
Nein. Das Modell hat genau das getan wofür es entwickelt wurde.
Du hast ihm einen System-Prompt gegeben der sagt "Du bist ein Datenbank-Experte." Es hat keine Datenbank. Kein Schema. Keine Tabellen. Keine Daten. Was hast du erwartet? Es hat geraten. Es hat selbstbewusst geraten. Und du hast das eine Halluzination genannt.
Ich habe darüber geschrieben warum die Umgebung wichtiger ist als der Prompt — die Idee dass wir LLMs einen Jobtitel gegeben und Expertise erwartet haben. Dieser Artikel geht weiter. Das Halluzinationsproblem ist kein Modell-Problem. Es ist ein Umgebungs-Problem. Und die Lösung sind nicht bessere Prompts oder Guardrails. Es ist bessere Architektur.
Was sind Halluzinationen eigentlich?
Eine Halluzination ist kein Bug. Es ist das Modell das genau so funktioniert wie es entworfen wurde.
Sprachmodelle sind probabilistische Textgeneratoren. Sie produzieren das wahrscheinlichste nächste Token basierend auf dem Kontext. Wenn der Kontext keine Grundlagendaten enthält, ist das wahrscheinlichste Token immer noch das was richtig klingt. Das Modell weiß nicht dass es falsch liegt. Es hat kein Konzept von "falsch." Es hat ein Konzept von "wahrscheinlich."
Konfidenz ist orthogonal zu Korrektheit. Das Modell kann 99% konfident und 100% falsch sein. Das ist keine Fehlfunktion. Das ist die Architektur die wie beabsichtigt arbeitet.
Die echte Frage ist nicht "warum halluzinieren Modelle?" Die Antwort ist offensichtlich — sie sind probabilistisch. Die echte Frage ist: warum hast du ein System gebaut das probabilistischen Output ohne Verifikation an deine User durchlässt?
Halluzination vs Fehler: Die Unterscheidung die niemand macht
Hier liegt die Branche fundamental falsch.
Menschen halluzinieren keine Daten. Sie machen Fehler mit Daten. Das ist ein kritischer Unterschied.
Ein menschlicher Buchhalter mit Zugang zu den Büchern macht vielleicht einen Fehler — falsche Formel, Off-by-One, vertauschte Zahlen. Aber er erfindet keinen Kunden der nicht existiert. Er fabriziert keinen Umsatz von einem Produkt das die Firma nicht verkauft. Er hat Zugang zur Realität. Seine Fehler sind in dieser Realität verankert.
Ein Agent ohne Datenzugang macht keine Fehler. Er halluziniert. Er erfindet Dinge die nicht existieren weil er nichts hat woran er sich orientieren kann. Keine Datenbank. Kein Schema. Keine Live-Daten. Nur ein Prompt der sagt "du bist ein Experte" und ein Kontextfenster voller Muster.
Und jetzt kommt der Shift der alles ändert: Gib demselben Agent echten Datenzugang und Code-Ausführung, und das Problem transformiert sich.
Der Agent mit Datenbankzugang, Schema-Injektion und der Fähigkeit Code gegen echte Daten auszuführen hört auf zu halluzinieren. Er kann immer noch Fehler machen — falsche Joins, schlechte Aggregationen, Off-by-One-Fehler in seinem SQL. Aber das sind normale Engineering-Fehler. Die gleiche Art Fehler die ein Junior-Entwickler macht. Keine Konfabulation. Keine Erfindung. Fehler.
Und Fehler weiß ich zu fixen. Ich kann Tests für Fehler schreiben. Ich kann Assertions hinzufügen. Ich kann Verifikationsschleifen bauen. Nichts davon kann ich für Halluzinationen tun weil Halluzinationen in einer Welt ohne Ground Truth existieren.
Das ist der Paradigmenwechsel: Sobald du dem Agent die Fähigkeit gibst seine Arbeit gegen die Realität zu beweisen, ist es nicht mehr "die KI lügt." Es ist "die KI hat einen Bug." Bugs sind Engineering-Probleme. Engineering-Probleme haben Engineering-Lösungen.
Warum Umgebung wichtiger ist als Training
Bessere Modelle halluzinieren immer noch. GPT-4 halluziniert. Claude Opus 4.6 halluziniert. Jedes Modell das jemals gebaut wird wird halluzinieren — weil Halluzination kein Fehler ist den man wegtrainieren kann. Es ist eine Eigenschaft probabilistischer Generierung.
Das Einzige was ich je gesehen habe das Halluzinationen tatsächlich eliminiert ist Umgebungsdesign.
In meiner eigenen Arbeit tauchten Halluzinationen nur in Systemen mit Prompt-Ketten und ohne Datenzugang auf. In dem Moment wo ich Agenten Zugang zu echten Datenbanken gab, Schemas zur Laufzeit injizierte und Code-Ausführung ermöglichte — hörten Halluzinationen auf. Nicht reduziert. Aufgehört.
Der Agent sieht die Umgebungsrealität. Er schreibt eine SQL-Query gegen eine echte Datenbank. Er bekommt echte Zeilen zurück. Er berechnet echte Zahlen. Es gibt nichts worüber man halluzinieren könnte weil die Daten direkt da sind.
Wöchentliche Insights zu AI-Architektur. Kein Spam.
Das ist was ich meine wenn ich sage baut Umgebungen, nicht Personas. Eine Persona ist ein Jobtitel. Eine Umgebung ist ein Schreibtisch mit Tools, Daten und Constraints. Das eine produziert selbstbewusstes Raten. Das andere produziert verifizierbare Arbeit.
Das Triangulation Protocol
Ich brauchte etwas Stärkeres als "gib ihm einfach Datenzugang." Datenzugang verhindert Halluzination, aber er garantiert keine Korrektheit. Der Agent kann immer noch eine schlechte Query schreiben. Er kann das Schema immer noch falsch interpretieren. Er kann immer noch Fehler machen.
Also habe ich ein Verifikationssystem gebaut, inspiriert von Ilya Sutskever's "Value Function"-Konzept — die Idee verschiedene kognitive Pfade zu nutzen um auf einer verifizierten Wahrheit zu konvergieren.
Ich nenne es das Triangulation Protocol. Es ist doppelte Buchführung für KI.
Für jede quantitative Frage vertraut das System keinem einzelnen Ausführungspfad. Stattdessen führt es zwei unabhängige Berechnungen durch:
Vektor A — Database Engine. Der Agent schreibt eine SQL-Query gegen die strukturierte Datenbank. Direkter Pfad. Schema-bewusst. Gibt eine Zahl zurück.
Vektor B — Runtime Computation. Der Agent nimmt die Rohdaten, schreibt ein Python-Skript in einer isolierten Sandbox und berechnet die Antwort durch eine komplett unabhängige Methode. Andere Logik. Andere Ausführung. Gleiche Frage.
Dann: vergleichen. Wenn beide Vektoren konvergieren — Delta unter 1% — ist die Antwort verifiziert. Wenn sie divergieren, rät das System nicht welcher richtig ist. Es verweigert die Antwort. Es wirft eine Exception statt potenziell falsche Daten zurückzugeben.
Die Kernidee ist nicht kompliziert: Der Agent hat keine andere Option als seine Arbeit zu beweisen. Wenn die Architektur beweisbare Outputs verlangt, ändert sich die Qualität dieser Outputs. Nicht weil das Modell "sich mehr anstrengt" — weil strukturell nicht-verifizierbarer Output abgelehnt wird. Nur bewiesene Ergebnisse überleben.
Warum das alles andere schlägt
Die Branche hat drei Standardantworten auf Halluzinationen. Alle drei verfehlen den Punkt.
"Prompte stärker." Mehr Instruktionen hinzufügen. "Sei immer wahrheitsgemäß." "Erfinde nie etwas." "Wenn du es nicht weißt, sag es." Das funktioniert nicht weil das Modell nicht weiß was es nicht weiß. Konfidenz ist orthogonal zu Korrektheit. Einem probabilistischen System per Textinstruktion zu sagen es soll deterministisch sein ist wie Wasser per streng formuliertem Memo zu sagen es soll bergauf fließen.
"Fine-tune das Modell." Trainiere es mit deinen Daten damit es die richtigen Antworten "kennt." Das ist langsam, teuer und fundamental falsch gedacht. Du versuchst Wissen in Gewichte einzubrennen wenn du es zur Laufzeit injizieren solltest. Wissen ändert sich. Gewichte nicht — nicht bis du neu trainierst. Und du hast immer noch null Verifikation.
"Füge Guardrails hinzu." Baue Filter, Klassifizierer, Content-Moderation obendrauf. Prüfe den Output bevor er den User erreicht. Das ist der Versuch den Output zu beschränken wenn du den Input fixen solltest. Guardrails sind Symptombehandlung. Sie adressieren nicht die Ursache. Das Modell hat halluziniert weil es keine Daten hatte — nachträglich einen Halluzinationsdetektor hinzuzufügen ist Rückwärts-Engineering.
Mein Ansatz ist anders: Mach Halluzination strukturell unmöglich.
Gib dem Agent echten Datenzugang. Injiziere das Schema zur Laufzeit. Ermögliche Code-Ausführung. Baue duale Verifikationspfade. Verlange Assertions. Lehne alles Unverifizierte ab.
Du bittest das Modell nicht ehrlich zu sein. Du baust eine Umgebung in der Unehrlichkeit architektonisch unmöglich ist.
Der Shift
Das Modell wird immer probabilistisch sein. Hör auf zu versuchen das zu fixen. Es ist nicht kaputt.
Was kaputt ist, ist die Umgebung in die du es gesetzt hast. Ein Agent ohne Datenzugang, ohne Verifikation, ohne Constraints — dieser Agent wird halluzinieren. Nicht weil es ein schlechtes Modell ist. Weil du ihm einen schlechten Schreibtisch gegeben hast.
Fix den Schreibtisch. Injiziere die Daten. Verlange Verifikation. Baue das Triangulation Protocol. Verwandle Halluzinationen in Fehler. Verwandle Fehler in Bugs. Fixe die Bugs.
Dein Job war nie das Modell wahrheitsgemäß zu machen. Dein Job war die Welt drum herum so zu bauen dass Wahrheit der einzig mögliche Output ist.