Long-Context-Halluzinationen: Warum die Demo nicht das System ist
8 Minuten Lesezeit English
Viele Kunden fragen mich, warum ich bremse, wenn jemand ein LLM oder einen Agenten auf jeden langsamen internen Prozess setzen will.
Das Argument klingt am Anfang oft plausibel.
Ein Mensch kann die Aufgabe erledigen. Die Schritte sind bekannt. Die Dokumente liegen vor. Die Antwort entsteht durch Lesen, Extrahieren, Prüfen und Addieren. Ein Chatbot hat drei Beispieldateien in einer Demo geschafft. Warum also nicht den ganzen Prozess automatisieren?
Weil die Demo nicht das System ist.
Klassische Software funktioniert anders. Wenn ein Mensch den Prozess Ende zu Ende beschreiben kann, und wenn jede Regel und jede Berechnung spezifiziert werden kann, kann Software daraus deterministisches Verhalten machen. Dieselbe Eingabe liefert dieselbe Ausgabe. Sonderfälle gibt es weiterhin, aber man kann sie benennen, testen und beheben.
LLMs liefern dieses System nicht automatisch.
Sie erzeugen das nächste Token aus Wahrscheinlichkeiten. Man kann die Temperatur senken. Man kann den Prompt verbessern. Man kann strukturierte Ausgabe nutzen. Man kann Retrieval und Validierung ergänzen. Das hilft alles. Aber es macht aus einem probabilistischen Modell kein deterministisches Programm.
Dieser Unterschied ist besonders wichtig, wenn die Aufgabe langweilig aussieht.
Kleine Demos erzeugen falsche Sicherheit
Die meisten KI-Demos sind zu klein, um den Fehler sichtbar zu machen.
Drei Rechnungen hochladen. Nach der Summe fragen. Das Modell antwortet korrekt.
Fünf Verträge hochladen. Eine Zusammenfassung anfordern. Das Modell findet die offensichtliche Klausel.
Ein paar Richtliniendokumente hochladen. Eine Frage stellen. Die Antwort wirkt brauchbar.
Für nicht-technische Stakeholder kann das wie ein Beweis wirken. Das Werkzeug hat die Aufgabe geschafft. Der nächste Schritt scheint klar: API anbinden, alle Dokumente hochladen und das Modell dieselbe Arbeit in groß erledigen lassen.
Genau dort bricht die Annahme.
Ein Modell, das in einem kleinen Kontext funktioniert, kann in einem großen Kontext scheitern. Nicht, weil die Aufgabe fachlich schwerer wurde. Sie kann weiterhin einfach sein. Das Problem ist, dass das Modell mehr Fakten, mehr Anweisungen, mehr Ausnahmen und mehr Störinformationen im aktiven Kontext halten muss.
Je länger der Prompt wird, desto mehr Möglichkeiten gibt es, ein Dokument zu überspringen, die falsche Zahl zu verwenden, die Extraktionsregel zu verlieren oder sich bei der Addition zu verrechnen.
Deshalb bin ich vorsichtig bei Aussagen wie “das Modell unterstützt eine Million Tokens”.
Die theoretische Kontextgröße ist nicht dasselbe wie ein zuverlässig nutzbarer Arbeitskontext.
Long Context bedeutet nicht verlässlicher Kontext
Dazu gibt es hilfreiche Forschung.
Lost in the Middle zeigt, dass Modelle schlechter werden können, wenn die relevante Information in der Mitte einer langen Eingabe steht, obwohl sie im Prompt vorhanden ist.
Context Is What You Need spricht nicht zufällig vom “maximum effective context window”. Die Frage ist nicht nur, wie viele Tokens ein Modell annehmen kann. Die Frage ist, wie viel davon es für eine echte Aufgabe zuverlässig nutzen kann.
Shadows in the Attention untersucht, wie Kontextänderungen und Representation Drift mit Halluzinationen zusammenhängen. Die Details sind technisch, aber der praktische Punkt ist einfach: Mehr Kontext kann das Verhalten eines Modells verändern, ohne dass man das dem Prompt direkt ansieht.
Das erklärt auch, warum viele proprietäre Chatprodukte Uploads, Dateianzahlen oder die praktisch nutzbare Kontextmenge begrenzen, obwohl das zugrunde liegende Modell ein viel größeres Fenster bewirbt. Ein Teil davon ist Produktdesign, Kostenkontrolle, Latenz, Missbrauchsschutz und Nutzerführung. Verlässlichkeit gehört in dasselbe Bild.
Ein großes Kontextfenster ist nützlich.
Es ist keine Garantie.
Der Rechnungstest
Um das fachfremden Teams einfacher zu erklären, habe ich ein kleines kontrolliertes Experiment gebaut.
Die Aufgabe ist absichtlich langweilig.
Es werden viele künstliche Dokumente erzeugt. Ein Modell soll alle lesen, die relevanten Ganzzahlen extrahieren und die Summe zurückgeben.
Mehr nicht.
Es geht nicht darum, dass Addition schwer ist. Es geht darum, dass die korrekte Antwort exakt bekannt ist. Wenn das Modell falsch liegt, brauchen wir keine Diskussion über Geschmack, Urteil, Domänenwissen oder Schreibstil.
Das Modell ist an einer deterministischen Extraktions- und Summenaufgabe gescheitert.
Der Benchmark hat drei Modi.
1. Feste Rechnungsbeträge
Der erste Modus erzeugt Rechnungen, in denen jede Datei dieselbe Zielzeile enthält:
Total amount due: 10 EURBei 100 Dokumenten ist die Antwort 1.000.
Bei 1.500 Dokumenten ist die Antwort 15.000.
Das ist absichtlich simpel. Es testet, ob das Modell Dokumentenanzahl und Extraktionsregel über einen wachsenden Kontext hinweg sauber behält.
2. Indexwerte
Der zweite Modus erzeugt Dokumente mit einem Wert, der dem Dokumentindex entspricht:
Value: 37Die bekannte Sollantwort ist die Formel:
num_docs * (num_docs + 1) / 2Damit muss man dem Modell nicht vertrauen. Der Benchmark kennt die Antwort, ohne das Modell danach zu fragen.
3. Freigegebene Zufallsrechnungen
Der dritte Modus ist näher an echter Arbeit.
Er erzeugt Rechnungsdokumente mit reproduzierbaren Beträgen, irrelevanten Störzahlen und einem Statusfeld. Einige Rechnungen sind freigegeben. Andere sind storniert. Nur freigegebene Rechnungen zählen.
Das Modell sieht Dokumente mit Rechnungsnummern, Kontonummern, Bestellreferenzen, alten Salden, Freigabecodes und Zielbeträgen. Es muss der Regel folgen:
Only sum Total amount due values where Status is approved.Die Beträge wirken zufällig genug, damit das Modell die Aufgabe nicht durch ein einfaches Muster lösen kann. Der Benchmark kennt die Antwort trotzdem, weil die Dokumente aus einem festen Seed erzeugt werden.
Das ist der nützliche Teil.
Die Aufgabe ist leicht zu erklären, aber gnadenlos. Das Modell extrahiert die richtigen Werte und addiert sie, oder eben nicht.
Warum Temperatur 0 keine magische Lösung ist
Der Benchmark läuft mit zwei Temperaturen:
0.0, was das Modell zu möglichst konsistentem und sorgfältigem Verhalten drängt0.7, was eher dem Sampling entspricht, das man bei Chatbots und Agenten oft sieht
Dieser Vergleich ist wichtig.
Wenn ein Modell bei Temperatur 0.7 scheitert, kann jemand sagen, dass das Sampling zu locker war. Das ist fair.
Wenn es bei Temperatur 0.0 scheitert, ist das schwerer wegzuerklären. Der Fehler kommt dann weniger wahrscheinlich aus zufälliger Stilvariation und eher aus Kontextverarbeitung, Extraktion, Arithmetik, Ausgabeformat oder der internen Verarbeitung der Aufgabe.
Temperatur 0 reduziert Zufall. Sie macht das Modell nicht zu Taschenrechner, Parser, Datenbank oder Workflow-Engine.
Halluzinationen von Betriebsfehlern trennen
Die Suite trennt zwei Arten von Problemen.
Falsche Summen zählen als Halluzinationen. Das Modell hat eine Antwort geliefert, aber diese Antwort widerspricht der deterministischen Sollantwort.
Timeouts, API-Fehler, Kontextlängenfehler und ungültige strukturierte Ausgaben werden separat als Betriebsfehler gemeldet.
Diese Trennung ist in echten Projekten wichtig.
Wenn das Modell eine falsche Summe zurückgibt, hast du ein Korrektheitsproblem.
Wenn das Modell abbricht oder kein gültiges JSON erzeugt, hast du ein Verfügbarkeitsproblem.
Beides kann den Workflow brechen. Nur auf unterschiedliche Weise.
Bei lokalen Ollama-Modellen können große Prompts auf Laufzeitgrenzen stoßen, bevor man überhaupt eine Halluzination sieht. Das ist kein Erfolg. Es bedeutet, dass die lokale Laufzeit nicht in der Größe arbeiten konnte, die der Workflow verlangt.
So läuft das Experiment
Das Repository ist ein kleines uv-Projekt. Die vollständige Suite erzeugt alle drei Experimenttypen für 10, 100, 500, 1000 und 1500 Dokumente. Sie wiederholt jeden Fall und schreibt einen integrierten Bericht.
Ein typischer lokaler Lauf sieht so aus:
uv run -m long_context_demo.cli suite run \
--ollama-model ollama:gpt-oss:20b \
--ollama-model ollama:gemma2:9b \
--timeout-seconds 600 \
--output-dir reportsDie Ausgabe enthält:
reports/<run_id>/results.jsonl
reports/<run_id>/summary.md
reports/<run_id>/config.yaml
reports/<run_id>/result_table.svgDie Tabelle ist nützlich für Artikel, Stakeholder-Gespräche und Architektur-Reviews. Sie macht den Fehler sichtbar, ohne dass vorher jemand Transformer-Paper lesen muss.
Was das beweist, und was nicht
Dieses Experiment beweist nicht, dass LLMs für Dokumenten-Workflows nutzlos sind.
Sie sind nützlich.
Sie können klassifizieren, zusammenfassen, extrahieren, normalisieren, entwerfen, suchen und unterstützen. In vielen Workflows sparen sie echte Zeit.
Das Experiment beweist etwas Engeres: Ein Modell kann bei einer einfachen deterministischen Aufgabe scheitern, wenn der Kontext wächst, obwohl alle nötigen Informationen im Prompt stehen.
Das reicht, um die Architekturdiskussion zu verändern.
Wenn die Antwort exakt sein muss, sollte das Modell nicht die Quelle der Wahrheit sein.
Nutze deterministischen Code für deterministische Teile:
- Strukturierte Daten mit Parsern lesen
- Extrahierte Werte in einer Datenbank speichern
- Schemas und Validierung nutzen
- Summen in Code berechnen
- Audit-Logs führen
- Modellausgaben gegen bekannte Regeln prüfen
- Menschen dort einbinden, wo Urteil nötig ist
Nutze das LLM dort, wo es stark ist:
- Unordentlichen Text in Kandidaten für strukturierte Daten übersetzen
- Unklare Fälle erklären
- Dokumente für die Prüfung sortieren
- Zusammenfassungen für Menschen entwerfen
- Natürliche Sprache um einen deterministischen Kern herum verarbeiten
Das ist eine andere Architektur als “alle Dokumente an einen Agenten schicken und der Antwort vertrauen”.
Sie ist weniger magisch.
Sie übersteht echte Daten besser.
Die Entscheidungsregel
Wenn ein Prozess Zeit frisst, sollte die erste Frage nicht lauten:
Kann ein LLM das?
Die bessere Frage lautet:
Welcher Teil dieses Prozesses braucht Sprachverständnis, und welcher Teil braucht deterministische Korrektheit?
Das sind unterschiedliche Aufgaben.
Wenn ein Mensch jede Berechnung und jede Regel erklären kann, schreibe Software für diesen Teil. Nutze Tests. Nutze bekannte Eingaben. Nutze bekannte Ausgaben. Mach das Verhalten langweilig.
Wenn die Eingabe aus unordentlicher Sprache besteht, nutze das Modell, um daraus etwas zu machen, das Software prüfen kann.
Verwechsele diese beiden Schichten nicht.
Das Modell kann den Workflow unterstützen. Es sollte nicht stillschweigend zum Buchhaltungssystem, zur Compliance-Engine oder zum finalen Entscheider werden, nur weil die Demo gut aussah.
Kleine Demos beantworten eine Frage: Kann das einmal funktionieren?
Produktionsarchitektur muss eine härtere Frage beantworten: Kann das sicher scheitern, wenn der Kontext wächst, die Dokumente unordentlich werden und die Antwort wichtig ist?
Für diese Frage sollte man bauen.