StructRAG (ICLR 2025): Die Wahl der richtigen Dokumentenstruktur schlägt GraphRAG um 28 Punkte
Die gängige Kritik an RAG in der Produktion lautet, dass das Retrieval ein stumpfes Instrument ist, wenn die relevanten Fakten über Dutzende von Dokumenten in inkompatiblen Formaten verstreut sind. StructRAG (Li et al., ICLR 2025) geht dieses Problem direkt an, indem es abgerufenen Text in einen aufgabengerechten Strukturtyp umwandelt – Tabelle, Graph, Katalog, Algorithmus oder einfacher Chunk –, bevor die eigentliche Argumentation stattfindet. Die Methode stützt sich auf eine kognitionstheoretische Behauptung: Menschen formen Rohinformationen natürlicherweise in strukturierte Darstellungen um, wenn sie komplexe Denkaufgaben bewältigen. Ob dieser Rahmen eher Metapher oder Mechanismus ist – die empirischen Zahlen verdienen eine genaue Betrachtung.
Das Paper
StructRAG schlägt eine Inferenzzeit-Pipeline mit drei Modulen vor. Erstens sagt ein hybrider Struktur-Router (Qwen2-7B-Instruct, feinabgestimmt mit DPO auf 900 synthetischen Präferenzpaaren) voraus, welcher von fünf Strukturtypen am besten zur eingehenden Frage und ihren Dokumenten passt. Zweitens schreibt ein Strukturierer für verstreutes Wissen (Qwen2-72B-Instruct) die abgerufenen Chunks in das gewählte Format um. Drittens zerlegt ein Nutzer strukturierter Erkenntnisse die Frage in Teilfragen, ruft die relevanten strukturierten Fragmente ab und generiert die endgültige Antwort. Die fünf Strukturtypen sind: Tabelle (statistische Vergleiche), Graph (Multi-Hop-Ketten, kodiert als Kopf–Relation–Schwanz-Triple), Algorithmus (Planungsaufgaben, geschrieben als Pseudocode), Katalog (Zusammenfassung, hierarchische Nummerierung) und Chunk (einfacher Single-Hop, der standardmäßige RAG-Fallback).
Die Autoren evaluieren primär auf dem Loong-Benchmark (EMNLP 2024 Oral), einem Multi-Dokument-QA-Benchmark, der Finanzberichte, Rechtsfälle und wissenschaftliche Arbeiten umfasst. Die Eingaben reichen von 10.000 bis 250.000 Token und decken vier Aufgabentypen ab: Spotlight-Lokalisierung, Vergleich, Clustering und Argumentationsketten (Chain of Reasoning).
Kernideen
- Der DPO-trainierte Router erreicht eine Genauigkeit von 94,38 % bei der Auswahl des Strukturtyps gegenüber 50,04 % im Zero-Shot-Verfahren mit Qwen2-72B-Instruct – die Routing-Entscheidung ist die kritischste Komponente. Ohne den Router fällt der LLM-Gesamtscore von 60,38 auf 45,33.
- Auf der schwierigsten Stufe der Dokumentenlänge (200K–250K Token) erzielt StructRAG 51,42 Punkte gegenüber 28,92 bei Long-Context-Modellen und 29,29 bei Standard-RAG – eine Differenz von ca. 22 Punkten, die mit wachsendem Kontext zunimmt. Der Standardansatz, "einfach alles reinzustopfen", verschlechtert sich drastisch, während StructRAG wesentlich stabiler bleibt.
- Obwohl GraphRAG ebenfalls Strukturen erzwingt, erreicht es im Loong-Benchmark nur einen LLM-Gesamtscore von 40,82 gegenüber 69,43 bei StructRAG. Zudem benötigt es 217,1 Minuten pro Abfrage im Vergleich zu 9,7 Minuten bei StructRAG. Der Vorab-Aufbau eines globalen Wissensgraphen ist sowohl langsamer als auch ungenauer als die bedarfsgerechte Wahl des richtigen Formats.
- Bei Podcast-Transkripten (offene Zusammenfassungen) erreicht StructRAG eine paarweise Gewinnrate von 95,75 % gegenüber Long-Context-Ansätzen. Dies deutet darauf hin, dass die strukturierte Synthese selbst bei weniger strukturiertem Quellmaterial die Full-Context-Ansätze übertrifft.
- Die Exact-Match-Scores (EM) liegen konsequent hinter den LLM-basierten Bewertungen zurück, da die Strukturierung die Oberflächenformulierung ändert (z. B. wird aus "$1,308,463" in einer Tabellenzelle "1308463"). Dies führt zu einem systematischen Token-Mismatch-Problem, das die automatisierte Auswertung benachteiligt.
Was Bestand hat – und was nicht
Das Kernergebnis ist fundiert und die Ablationsstudie klar: Das Routing ist am wichtigsten, gefolgt von der Strukturierung und der Nutzung. Die Verbesserung bei großen Dokumentenlängen ist die stärkste Erkenntnis – 22 Punkte Vorsprung bei 200.000 Token sind kein Zufall.
Dennoch habe ich drei Vorbehalte. Erstens ist die Benchmark-Abdeckung dünn. StructRAG berichtet nur über Loong und Podcast-Transkripte. Standard-Multi-Hop-Benchmarks (HotpotQA, 2WikiMultiHopQA, MuSiQue, NQ) fehlen auffällig, was einen Vergleich mit der umfangreichen Forschung zu etablierten Retrieval-Datensätzen unmöglich macht. Die Gutachter bei der ICLR haben dies vermutlich angemerkt; das Paper bietet in der veröffentlichten Version keine direkte Antwort darauf.
Zweitens dient GPT-4 als Evaluationsmodell. Ein LLM-als-Richter ist anfällig für Längen-Bias und stilistische Vorlieben, die Ausgaben aus demselben Strukturierungsprozess bevorzugen könnten, insbesondere wenn der Richter auf ähnlichen strukturierten Texten trainiert wurde. Die EM-Metrik dient als Korrektiv, aber die Autoren rahmen dies eher als Einschränkung der Metrik denn als Evidenz für ein Problem der Methode.
Drittens wurde StructRAG mit einem sehr leistungsstarken Backbone getestet (Qwen2-72B-Instruct für Strukturierung und Nutzung). Es ist unklar, wie viel des Gewinns auf das Routing entfällt und wie viel schlicht darauf basiert, ein mächtiges Modell zum Umschreiben und Zusammenfassen aufzurufen. Eine Ablationsstudie gegen eine gleich starke Direct-Answer-Baseline fehlt.
Warum dies für Finanz-KI wichtig ist
Beancount-Ledger sind der kanonische Anwendungsfall für das Problem der "verstreuten Informationen". Eine einzige Abstimmungsfrage – „Warum ist mein Nettovermögen im dritten Quartal gesunken?“ – kann das Lesen von Transaktionseinträgen aus drei Konten, den Abgleich mit einem Bilanzbericht und das Verfolgen einer mehrstufigen Korrekturkette erfordern. Diese lassen sich fast eins zu eins auf die Strukturtypen von StructRAG abbilden: Tabellen für Bilanzvergleiche, Graphen für Transaktionsketten, Kataloge für Periodenzusammenfassungen.
Die Erkenntnis zum Routing ist besonders wertvoll. Ein auf Abfragen fokussierter Beancount-Agent sollte nicht immer wahllos Chunks in den Kontext werfen; er sollte zuerst fragen, welche Form die Antwort erfordert. Eine Frage zu Bilanztrends benötigt eine Tabelle. Eine Frage zur Erläuterung einer Erstattungskette benötigt einen Graphen. Eine Zusammenfassung der Jahresausgaben benötigt einen Katalog. Diese Routing-Entscheidung explizit zu verdrahten – selbst mit einem kleinen Modell – könnte die Halluzinationen und Zahlenfehler, die aktuelle Versuche zur Ledger-QA plagen, drastisch reduzieren.
Auch die Latenzgeschichte (9,7 statt 217 Minuten) ist in der Praxis entscheidend. Für einen interaktiven Beancount-Agenten sind die Kosten für die Vorab-Indizierung bei GraphRAG für häufig aktualisierte Ledger zu hoch; der Inferenzzeit-Ansatz von StructRAG passt besser zum "schreibintensiven, abfragesparsamen" Nutzungsprofil von Ledgern.
Ein Wermutstropfen bleibt: Der Strukturierer von StructRAG erfordert bei jeder Abfrage einen Aufruf eines großen LLMs. Bei langen Ledger-Historien könnten diese Inferenzkosten erheblich sein. Eine Token-effiziente Strukturierung – vielleicht durch ein kleineres, spezialisiertes Modell – bleibt eine offene technische Frage.
Was man als Nächstes lesen sollte
- From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Edge et al., 2024, arXiv:2404.16130) – Microsoft GraphRAG nutzt Community-Zusammenfassungen für globale Abfragen; zu verstehen, wo die Inferenzzeit-Strukturierung von StructRAG die Vorab-Indizierung von GraphRAG schlägt, ist der entscheidende architektonische Trade-off.
- FinAuditing: A Financial Taxonomy-Structured Multi-Document Benchmark (arXiv:2510.08886) – testet 13 LLMs auf XBRL-Einreichungen mit hierarchischen Tabellen; ein direkter Test, ob die Tabellen- und Katalogstrukturen von StructRAG auf das strukturierte Format von Finanzberichten übertragbar sind, denen Beancount-Ledger ähneln.
- InvestorBench: A Benchmark for Financial Decision-Making Tasks with LLM-based Agent (arXiv:2412.18174, ACL 2025) – evaluiert Agenten bei realen finanziellen Entscheidungen. Dies ermöglicht die Messung, ob die strukturierte Argumentation von StructRAG tatsächlich die Qualität nachgelagerter Entscheidungen über die reine QA-Genauigkeit hinaus verbessert.
