Lost in the Middle: Position Bias in LLMs und seine Auswirkungen auf Finance AI

Wenn ich auf den DocFinQA-Eintrag zurückblicke – in dem sowohl Retrieval-basierte Pipelines als auch Long-Context-LLMs bei SEC-Filings mit 123K-Token-Kontexten versagten – blieb die Frage offen, warum. Dieses Paper von Liu et al. (TACL 2024, arXiv:2307.03172) liefert die mechanistische Antwort, und es stellt sich heraus, dass der Fehlermodus einfacher und hartnäckiger ist, als ich erwartet hätte.

Das Paper

„Lost in the Middle: How Language Models Use Long Contexts“ von Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni und Percy Liang führt zwei gezielte Experimente durch: Multi-Dokument-Frage-Antwort-Systeme über NaturalQuestions-Open (mit 10, 20 und 30 abgerufenen Dokumenten) und synthetisches Key-Value-Retrieval (mit 75, 140 und 300 Paaren). In jedem Experiment variieren sie systematisch die Position des relevanten Dokuments oder Key-Value-Paares innerhalb des Eingabekontexts – Anfang, Mitte oder Ende – während alles andere gleich bleibt. Das Ergebnis ist eindeutig: Die Leistung folgt einer U-förmigen Kurve mit dem Tiefpunkt in der Mitte des Kontexts, und diese Kurve zeigt sich bei jedem getesteten Modell.

Kernaussagen

• Die U-Form ist real und konsistent. In der 20-Dokumente-QA-Einstellung lag die Leistung an der ersten Position bei etwa 75 % und sank auf rund 55 % an Position 10, bevor sie sich an Position 20 wieder auf etwa 72 % erholte – ein Unterschied von ca. 20 Punkten zwischen den Rändern und der Mitte.
• Alle Modelle folgen demselben Muster. Die getesteten Modelle umfassen proprietäre und Open-Source-Modelle, kleine und große: GPT-3.5-Turbo (4K und 16K), GPT-4, Claude-1.3 (8K und 100K), MPT-30B-Instruct und LongChat-13B. Die U-Kurve trat bei jedem von ihnen auf, einschließlich Modellen, die explizit für erweiterte Kontextfenster vermarktet werden.
• Selbst Claude-1.3-100K ist nicht immun. Die 100K-Kontext-Variante verhielt sich wie die anderen. Ein langes Kontextfenster bedeutet nicht, dass das Modell tatsächlich gleichmäßig darauf achtet.
• Die Closed-Book-Baseline setzt eine ernüchternde Untergrenze. GPT-3.5-Turbo ohne Dokumente beantwortete 56,1 % der NaturalQuestions korrekt; mit Oracle-Zugriff auf nur das eine relevante Dokument erreichte es 88,3 %. Doch an den schlechtesten mittleren Positionen in der 20-Dokumente-Einstellung sank die Leistung unter die Closed-Book-Baseline – was bedeutet, dass das Hinzufügen von mehr Kontext aktiv schädlich war.
• Encoder-Decoder-Modelle (Flan-T5-XXL, Flan-UL2) sind innerhalb ihrer Trainingslänge robuster, fallen aber zurück, wenn der Kontext diese überschreitet. Der architektonische Unterschied ist von Bedeutung, aber beide Modelle bauen bei zunehmender Skalierung dennoch ab.
• Die Ursache ist das kausale Attention-Masking. Da jeder Token nur auf vorangehende Token achten kann, kumulieren Positionen ganz am Anfang mehr Aufmerksamkeit über das gesamte Modell hinweg als Positionen in der Mitte. Recency-Effekte ziehen das Ende des Kontexts ebenfalls nach oben.

Was Bestand hat – und was nicht

Das experimentelle Design hier ist bewundernswert sauber: Die Position ist die einzige manipulierte Variable, die Aufgaben sind Standard-Benchmarks, und das Ergebnis repliziert sich über eine Vielzahl von Modellfamilien hinweg. Ich habe keine Einwände gegen das Kernergebnis.

Weniger überzeugend finde ich die Einordnung der Key-Value-Retrieval-Aufgabe als aussagekräftigen Proxy für die reale Nutzung. UUID-zu-UUID-Lookups testen, ob ein Modell einen auswendig gelernten String wiedergeben kann, nicht ob es zu logischem Schlussfolgern fähig ist. Die U-Kurve zeigt sich auch dort, was die Behauptung des Positions-Bias stärkt, aber es bedeutet auch, dass das Paper zwei verschiedene Phänomene vermischt: Retrieval-Genauigkeit bei Exact-Match-Aufgaben und Reasoning-Qualität über relevante Passagen. Ich wüsste gerne, ob die U-Form schlimmer oder besser wird, wenn das relevante Dokument mehrstufige Inferenzen vor der endgültigen Antwort erfordert, statt nur eine wörtliche Wiedergabe.

Es gibt zudem eine Lücke, welche die Autoren zwar größtenteils anerkennen, aber nicht schließen: Sie testen nie, ob Instruction-Fine-Tuning oder RLHF die Positionssensitivität verändert, sondern nur, ob ein größeres Kontextfenster dies tut. Da die Ursache architektonisch bedingt ist (kausales Masking), vermute ich, dass Instruction-Tuning das Problem nicht beheben wird, aber das Paper bestätigt dies nicht.

Warum das für Finance-KI wichtig ist

Dieses Paper liefert die mechanistische Erklärung für ein empirisches Muster, auf das ich immer wieder stoße. DocFinQA scheiterte an langen SEC-Filings. IRCoT und FLARE rufen beide mehrere Passagen ab und verketten sie vor dem Reasoning. Jede RAG-Pipeline, die ich mir im Finanzkontext angesehen habe, wirft abgerufene Passagen sequenziell in den Prompt und hofft, dass das Modell die richtige beachtet.

Die Auswirkungen für Beancount-Agenten sind konkret. Wenn ein Agent zehn Ledger-Einträge als Kontext abruft, besteht bei den Einträgen an den Positionen 3–7 das höchste Risiko, ignoriert oder durch Halluzinationen verfälscht zu werden. Dies ist kein Retrieval-Problem – es ist ein Präsentationsproblem. Aus diesem Paper ergeben sich zwei Konsequenzen: Entweder man platziert die diagnostisch relevantesten Einträge an den Anfang (und das Ende), oder man verzichtet ganz auf die Verkettung und führt das Reasoning über jeweils eine Passage einzeln durch.

Das Ergebnis verkompliziert auch das Long-Context-LLM-Narrativ. Jedes Quartal kündigt ein neues Modell ein größeres Kontextfenster an. Dieses Paper besagt, dass ein langes Fenster nicht das bedeutet, was man denkt, wenn man Informationen gleichmäßig darin verteilt. Ein 128K-Kontext-Modell, das die relevante Transaktion an Position 60K vergräbt, ist schlechter als ein 4K-Kontext-Modell, das präzise die richtige Passage abruft.

Hinsichtlich der Sicherheit beim Rückschreiben (Write-Back-Safety) sind die Implikationen unbequem: Wenn das Modell gebeten wird, eine Ledger-Sitzung zusammenzufassen, und die relevante Regel „diese Transaktion nicht buchen“ in der Mitte eines langen System-Prompts erscheint, verhält sich das Modell möglicherweise so, als hätte es diese Regel nie gelesen.

Was man als Nächstes lesen sollte

• "Found in the Middle: How Language Models Use Long Contexts Better via Plug-and-Play Positional Encoding" (Zhang et al., arXiv:2403.04797) – schlägt Multi-scale Positional Encoding (Ms-PoE) als trainingsfreie Lösung mittels RoPE-Skalierung vor; behauptet eine Verbesserung von bis zu 3,8 Punkten bei Zero-SCROLLS und adressiert damit direkt die U-Kurve.
• "Never Lost in the Middle: Mastering Long-Context Question Answering with Position-Agnostic Decompositional Training" (arXiv:2311.09198) – verfolgt den entgegengesetzten Ansatz und trainiert das Modell darauf, explizit positionsagnostisch zu sein; der Vergleich mit Ms-PoE klärt, ob Fine-Tuning oder Inferenz-Tricks der bessere Hebel sind.
• "Mitigate Position Bias in Large Language Models via Scaling a Single Dimension" (arXiv:2406.02536) – identifiziert die spezifische Dimension der positional hidden states, die für den Bias verantwortlich ist, und skaliert sie ohne erneutes Training; der bisher präziseste Lösungsvorschlag, relevant für den Einsatz bestehender Modelle ohne Retraining.