IRCoT: Verschachtelung von Retrieval mit Chain-of-Thought für mehrstufige QA

Ich habe in den letzten Beiträgen über RAG-Varianten gelesen und wollte IRCoT verstehen – das Paper von Trivedi, Balasubramanian, Khot und Sabharwal (ACL 2023), das Retrieval mit Chain-of-Thought-Reasoning verschachtelt, anstatt nur einen einzigen Retrieval-Durchgang vorab durchzuführen. FLARE ging dasselbe Problem an, indem es vorhersagte, wann ein Retrieval stattfinden sollte; IRCoT wählt einen einfacheren mechanischen Ansatz und stellt eine gezieltere Frage: Was wäre, wenn jeder Satz einer Argumentationskette selbst eine Retrieval-Abfrage wäre?

Das Paper

Bestehende Retrieve-then-Read-Pipelines rufen Dokumente einmal basierend auf der ursprünglichen Frage ab und übergeben dann alles an ein LLM. Für Single-Hop-Fragen reicht das oft aus. Für mehrstufige Fragen – „Wer war der Komponist des Films, dessen Regisseur in derselben Stadt wie Bach geboren wurde?“ – lassen sich die relevanten Dokumente für den zweiten Schritt erst identifizieren, nachdem man den ersten Schritt teilweise beantwortet hat. Die Autoren nennen dies das Problem der Wissensabhängigkeit (Knowledge Dependency) und argumentieren, dass einstufiges Retrieval strukturell unfähig ist, dieses zu lösen.

IRCoT adressiert dies mit einer alternierenden Schleife: Erzeugen des nächsten Satzes einer Argumentationskette, Verwenden dieses Satzes als BM25-Abfrage zum Abrufen zusätzlicher Absätze, Hinzufügen der abgerufenen Absätze zum Prompt-Kontext, Erzeugen des nächsten Argumentationssatzes und Wiederholung. Die Schleife läuft bis zu acht Schritte lang und begrenzt den Gesamtkontext auf fünfzehn Absätze. Es ist kein Training erforderlich – die Methode basiert vollständig auf Prompting und wurde Zero-Shot auf GPT-3 (code-davinci-002) sowie in Few-Shot-Szenarien auf Flan-T5 evaluiert.

Kernaussagen

• Auf HotpotQA verbessert IRCoT das Retrieval-Recall im Vergleich zum einstufigen Retrieval mit GPT-3 um +11,3 Punkte und das nachgelagerte QA F1 um +7,1 Punkte (60,7 gegenüber 53,6).
• Die Gewinne sind bei schwierigeren Datensätzen größer: +22,6 Recall-Punkte und +13,2 F1-Punkte auf 2WikiMultihopQA mit GPT-3.
• Flan-T5-XXL (11B) mit IRCoT erzielt auf 2WikiMultihopQA ein um +15,3 höheres F1 als einstufiges Retrieval, was den größten Gewinn pro Datensatz im Paper darstellt.
• Flan-T5-XL (3B) mit IRCoT übertrifft GPT-3 (175B) mit einstufigem Retrieval – eine Lücke von 58-fachen Parametern, die allein durch die Retrieval-Strategie überwunden wurde.
• IRCoT reduziert faktische Fehler in der generierten CoT auf HotpotQA um 50 % und auf 2WikiMultihopQA um 40 % im Vergleich zum einstufigen Retrieval (manuelle Annotation von 40 Fragen pro Datensatz).
• Die Methode generalisiert Out-of-Distribution: Die Verwendung von Demonstrationen aus einem Datensatz zur Evaluierung eines anderen zeigt ähnliche Gewinne, was bestätigt, dass der Ansatz nicht nur In-Distribution-Muster lernt.

Was Bestand hat – und was nicht

Die Kernbehauptung – dass mehrstufiges Schlussfolgern ein mehrstufiges Retrieval benötigt – ist überzeugend und die Experimente sind sauber durchgeführt. Die Verwendung von vier wirklich schwierigen Multi-Hop-Benchmarks mit unterschiedlichen Wissensstrukturen (Bridge, Comparison, Discrete-Reasoning) untermauert das Argument auf breiter Basis. Das Ablation-Experiment, das zeigt, dass ein separater, dedizierter Reader (anstatt der direkten Extraktion der Antwort aus der CoT-Phase) konsistent hilft, ist eine nützliche praktische Erkenntnis.

Was ich weniger zufriedenstellend finde: Das Retrieval-Budget ist unabhängig von der Schwierigkeit der Frage auf fünfzehn Absätze festgelegt, und das Abbruchkriterium ist ein hartes Schrittlimit statt eines vom Modell bewerteten Signals („Ich habe genug Informationen“). Das unsicherheitsbasierte Triggering von FLARE ist in dieser Hinsicht prinzipieller, erfordert jedoch kalibrierte Token-Wahrscheinlichkeiten. Das BM25-Backbone von IRCoT ist bewusst einfach gehalten – dichtes Retrieval (Dense Retrieval) würde die Ergebnisse mit Sicherheit weiter verbessern, aber die Autoren testen es nicht; sie argumentieren, dass die Einfachheit den Beitrag der Argumentationskette deutlicher macht, was fair ist. Die Rechenkosten sind real: Jeder generierte Satz löst einen Retrieval-Aufruf aus, sodass die Latenz linear mit der Argumentationstiefe skaliert. Jüngste Arbeiten aus dem Jahr 2025 (LevelRAG, GlobalRAG) berichten, dass diese starre „Ein-Satz-ein-Retrieval“-Pipeline die Leistung bei Aufgaben einschränkt, die eine parallele Informationsbeschaffung anstelle eines sequenziellen Chain-Reasoning erfordern, wobei GlobalRAG eine Verbesserung von 6,54 F1-Punkten gegenüber IRCoT auf seinem Benchmark meldet.

Auch die Halluzinationsanalyse ist dünner als erhofft: 40 Fragen pro Datensatz sind zu wenig für starke Aussagen, und „faktische Fehler“ wurden manuell annotiert, ohne dass die Übereinstimmung zwischen den Annotatoren (Inter-Annotator Agreement) berichtet wurde.

Warum das für Finanz-KI wichtig ist

Das Abhängigkeitsproblem, das IRCoT löst, lässt sich direkt darauf übertragen, wie ein Beancount-Agent mehrstufige Finanzfragen verfolgt. „Wie hoch war der Nettoeffekt aller Transaktionen, die das Konto X zwischen den Daten Y und Z betreffen, unter Berücksichtigung der in den Memo-Feldern vermerkten Währungsumrechnungen?“ lässt sich nicht mit einer einzigen Vektorsuche beantworten – man muss die passenden Transaktionen finden, dann die referenzierten Wechselkurse abrufen und dann potenziell die Gegenkonten ermitteln. Jeder Retrieval-Schritt hängt davon ab, was im vorherigen gefunden wurde.

Die praktische Design-Lektion ist die Retrieve-Reason-Schleife: Anstatt ein gesamtes mehrjähriges Ledger in den Kontext zu stopfen oder eine einzige semantische Suche durchzuführen, würde ein Agent im IRCoT-Stil jeden Zwischenschritt der Argumentation – „die gesamten Soll-Buchungen für Ausgaben:Lebensmittel in Q1 betrugen 1.240 $“ – als Abfrage für den nächsten Retrieval-Schritt verwenden. Das hält das Kontextfenster schlank und die abgerufenen Belege zweckspezifisch. Die Erkenntnis, dass ein 3B-Modell mit gutem Retrieval ein 175B-Modell mit schlechtem Retrieval schlägt, ist besonders relevant angesichts der Kostenbeschränkungen beim Betrieb von Agenten über persönlichen oder kleingewerblichen Ledgern. Das Retrieval richtig hinzubekommen, ist möglicherweise wichtiger als die Modellgröße.

Die Einschränkung, die man im Hinterkopf behalten sollte: Die starre Struktur von IRCoT (ein Retrieval pro Satz) wird bei Ledger-Abfragen Schwierigkeiten haben, die eine gleichzeitige Aggregation über viele parallele Datenströme erfordern – z. B. die Berechnung einer Budgetabweichung über zwölf Ausgaben-Unterkonten gleichzeitig. Hier würde ein planungsorientierter Ansatz (wie LATS oder eine strukturierte Abfragedekomposition) IRCoT eher ergänzen als mit ihm konkurrieren.

Was man als Nächstes lesen sollte

• Das IRCoT-Paper selbst zitiert DecomP (Decomposed Prompting, Khot et al. 2022, arXiv:2210.06726) als wichtige Baseline – lesenswert, um die alternative Strategie zu verstehen, Fragen vor dem Retrieval in Teilfragen zu zerlegen, anstatt die Schritte zu verschachteln.
• LevelRAG (arXiv:2502.18139) baut auf dem iterativen Retrieval im IRCoT-Stil auf, indem es einen übergeordneten Planer hinzufügt, der Abfragen über mehrere Suchmaschinen hinweg umschreibt; eine aktuellere Herangehensweise an dasselbe Problem, die die Starrheit von IRCoT adressiert.
• „Chain-of-Retrieval Augmented Generation“ (CoRAG, arXiv:2501.14342) ist ein Follow-up aus dem Jahr 2025, das das mehrstufige Retrieval als Kette formuliert, die IRCoT-Schleife explizit macht und ein Trainingssignal hinzufügt – ein natürlicher Nachfolger nach diesem Paper.