Retrieval-Augmented Generation für wissensintensive NLP-Aufgaben

Lewis et al.s „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks“ (NeurIPS 2020) ist wahrscheinlich das Paper, das am stärksten dafür verantwortlich ist, wie KI-Produktionssysteme heute architektonisch aufgebaut sind. Fünf Jahre nach der Veröffentlichung bleibt es die Baseline, an der fast jedes dokumentengestützte Sprachsystem gemessen wird. Ich lese es jetzt, weil alles in meinem Bean-Labs-Backlog – von der Hauptbuch-QA bis zur Anomalienerklärung – letztendlich auf die Retrieval-Frage stößt, und ich die ursprünglichen Designentscheidungen klar verstehen möchte, bevor ich mich den Nachfolgern zuwende.

Das Paper

Das Kernproblem, das RAG adressiert, besteht darin, dass vortrainierte Sprachmodelle Wissen während des Trainings in Gewichte einbacken, wodurch dieses Wissen statisch, undurchsichtig und ohne erneutes Training unmöglich zu aktualisieren ist. Lewis et al. schlagen eine hybride Architektur vor: einen parametrischen Speicher (BART-large als Generator), gepaart mit einem nicht-parametrischen Speicher (ein dichter FAISS-Index über 21 Millionen Wikipedia-Passagen), die durch einen gelernten Retriever auf Basis von Dense Passage Retrieval (DPR, Karpukhin et al. 2020) verbunden sind. Zur Inferenzzeit ruft das Modell die Top-K relevanten Passagen ab und marginalisiert dann über diese, um die endgültige Ausgabe zu erzeugen.

Das Paper stellt zwei Varianten vor. RAG-Sequence ruft einmal ab und verwendet denselben Satz von Dokumenten für die gesamte generierte Sequenz – kohärenter, aber weniger anpassungsfähig. RAG-Token ermöglicht es dem Modell, bei jedem Generierungsschritt ein anderes abgerufenes Dokument zu berücksichtigen, was es ihm ermöglicht, Informationen aus mehreren Quellen mitten im Satz zu synthetisieren. Beide Varianten lernen Retriever und Generator gemeinsam während des Feintunings, obwohl der Dokumenten-Encoder eingefroren bleibt, um die Kosten für den Neuaufbau des FAISS-Index während des Trainings zu vermeiden.

Kernaussagen

• RAG-Sequence erreicht 44,5 Exact Match bei Natural Questions, 56,8 EM bei TriviaQA und 68,0 EM bei WebQuestions – State-of-the-Art zum Zeitpunkt der Veröffentlichung.
• Bei MS-MARCO abstractive QA erzielt RAG-Sequence 40,8 ROUGE-L gegenüber 38,2 für eine reine BART-Baseline – bescheiden, aber konsistent.
• Jeopardy-Fragen-Generierung: Menschliche Evaluatoren beurteilten RAG-Ausgaben in 42,7 % der Fälle als faktischer als BART (BART war in 7,1 % der Fälle faktischer).
• Bei der FEVER-Faktenprüfung erreicht RAG eine 3-Wege-Genauigkeit von 72,5 % (4,3 Punkte unter dem spezialisierten SOTA), ohne jegliches aufgabenspezifisches Engineering.
• Das Einfrieren des Dokumenten-Encoders während des Trainings kostet nur ca. 3 EM-Punkte bei NQ (44,0 → 41,2), was den Ansatz rechnerisch machbar macht, zum Preis von veraltetem Indexwissen.
• Dense Retrieval übertrifft BM25 bei allen Aufgaben außer FEVER, wo entitätszentrierte Abfragen eine Term-Überlappung bevorzugen – ein konkretes Signal dafür, dass Sparse Retrieval nicht durchweg unterlegen ist.

Was Bestand hat – und was nicht

Die fundamentale Erkenntnis – die Trennung des Wissensspeichers von der Reasoning-Engine – ist sehr gut gealtert. Sie ermöglicht aktualisierbares Wissen (einfach neu indexieren), Quellenangabe (die abgerufenen Passagen sind überprüfbar) und sie lässt sich über Open-Domain QA, Generierung und Faktenprüfung hinweg ohne aufgabenspezifische Architekturen verallgemeinern. Diese Eigenschaften zählen in der Praxis immer noch mehr als die spezifischen Exact-Match-Zahlen.

Die NeurIPS-Reviewer hatten recht damit, dass die technische Neuheit begrenzt ist. DPR und BART existierten bereits; RAG ist eine sorgfältige Integration, kein fundamentaler algorithmischer Fortschritt. Die Entscheidung für den eingefrorenen Dokumenten-Encoder schafft zudem ein subtiles Problem, das das Paper etwas beschönigt: Der Index wird einmal erstellt und wird zu einer Momentaufnahme. Jeder Fakt, der sich nach der Erstellung des Index ändert, ist für das Modell unsichtbar. Für statische Corpora wie SEC-Einreichungen ist das akzeptabel. Für Live-Systeme – Echtzeitkurse, tägliche Transaktionsfeeds – ist dies eine echte architektonische Einschränkung, kein nebensächliches Detail.

Der Befund des Retrieval-Collapse verdient mehr Aufmerksamkeit, als er bekommt. Bei Aufgaben zur Geschichtengenerierung lernte das Modell, abgerufene Dokumente vollständig zu ignorieren und aus dem parametrischen Speicher zu generieren. Das Paper merkt an, dass dies geschieht, wenn die Aufgabe „kein spezifisches Wissen erfordert“, erklärt aber nicht den Mechanismus oder gibt Praktikern eine prinzipielle Methode an die Hand, dies zu erkennen. Ein Agent, der stillschweigend aufhört abzurufen, während er scheinbar normal funktioniert, ist genau der Fehlermodus, der mich in Finanzsystemen im Produktiveinsatz beunruhigt.

Der Speicherbedarf ist ebenfalls nicht trivial: Allein der Wikipedia-Index benötigt ca. 100 GB CPU-RAM. Das Paper stellt dies als Feature dar (nicht-parametrischer Speicher ist „schnell zu aktualisieren“), aber es sind reale Betriebskosten, die die Entwicklung der Technik in den folgenden Jahren prägten – hin zu komprimierten Indizes und approximativem Retrieval.

Warum dies für Finanz-KI wichtig ist

Die Retrieval-Architektur lässt sich natürlich auf die Problemstruktur von Beancount übertragen. Ein Beancount-Hauptbuch ist ein großer Append-only-Dokumenten-Corpus, in dem einzelne Einträge semantisch verknüpft sind: Eine steuerlich absetzbare Ausgabe referenziert eine Kategorie, eine Kategorie eine Regel, eine Regel ein Geschäftsjahr. Kein parametrisches Modell, das auf öffentlichen Daten trainiert wurde, kennt den spezifischen Kontenrahmen eines Benutzers. Die Trennung von Reasoning und Wissen macht RAG zur richtigen strukturellen Antwort: Feintuning des Generators auf Aufgabenformate der Buchhaltung, aber Erdung der faktischen Lookups im tatsächlichen Hauptbuch-Index des Benutzers.

Die praktische Sorge ist dieselbe, die das Paper identifiziert, aber unterbewertet: veraltete Indizes. Wenn ein Beancount-Agent aus einem Index abruft, der gestern erstellt wurde, verpasst er möglicherweise die Transaktionen von heute. Inkrementelle Indexierung und getriggertes Re-Indexing bei Schreibvorgängen im Hauptbuch müssen von Anfang an Teil des Systemdesigns sein und nicht erst nachträglich hinzugefügt werden. Die andere Sorge ist die Retrieval-Präzision über strukturierte Daten. RAG wurde für Wikipedia-Prosa entwickelt. Ein Beancount-Hauptbuch enthält Datumsbereiche, Kontenhierarchien und Währungsbezeichnungen, die von prosaoptimierten Retrievern nicht nativ verarbeitet werden. Die Frage „Können LLMs über tabellarische Daten schlussfolgern“, die ich zuvor untersucht habe, schränkt direkt ein, was RAG sinnvoll abrufen kann.

Weiterführende Literatur

• Fusion-in-Decoder (FiD), Izacard & Grave 2020 (arXiv:2007.01282) – verarbeitet jede abgerufene Passage unabhängig und fusioniert sie im Decoder, wobei höhere NQ-Scores als RAG erzielt werden und die Architektur einfacher ist; es lohnt sich, dies zu verstehen, bevor man den Joint-Reading-Ansatz von RAG-Token übernimmt.
• FLARE: Active Retrieval Augmented Generation, Jiang et al. 2023 (arXiv:2305.06983) – ruft bei Bedarf während der Generierung ab, indem vorhergesagt wird, wann das Modell im Begriff ist zu halluzinieren; die natürlichste Erweiterung der RAG-Ideen hin zu adaptiveren Agenten.
• „Fine-Tuning or Retrieval?“ Ovadia et al. 2023 (arXiv:2312.05934) – systematischer Vergleich von Wissensinjektionsmethoden über Aufgaben hinweg; die empirische Evidenz, die man benötigt, bevor man entscheidet, ob man einen hauptbuchspezifischen Generator feintunt oder einfach nur das Retrieval verbessert.