💬 NLP

DynaKRAG: A Unified Framework for Learnable Evidence Control in Multi-Hop Retrieval-Augmented Generation

DynaKRAG ist ein vereinheitlichtes Framework, das Multi-Hop-Retrieval-Augmented Generation als zustandsbedingtes Kontrollproblem formuliert, indem es eine gelernte Policy verwendet, um dynamisch aus validen Evidenz-Operationen wie Retrieval und Query-Reformulierung zu wählen, wodurch es bestehende Methoden auf Benchmarks wie HotpotQA, 2Wiki und MuSiQue übertrifft.

Ursprüngliche Autoren: Yaqi Wu, Xiaolei Guo, Chenyu Zhou, Jiaqi Huang, Xianfa Zhang, Junxu Zhang, Zhuo Yu, Zhubo Shi, Jianghao Lin, Dongdong Ge

Veröffentlicht 2026-07-08

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Yaqi Wu, Xiaolei Guo, Chenyu Zhou, Jiaqi Huang, Xianfa Zhang, Junxu Zhang, Zhuo Yu, Zhubo Shi, Jianghao Lin, Dongdong Ge

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Detektiv, der versucht, ein komplexes Rätsel zu lösen, wie zum Beispiel: „Wer hat die Kronjuwelen gestohlen und wo wurden sie versteckt?“

Auf die alte Art und Weise (Standard-KI-Systeme) würde dem Detektiv ein strenges Regelbuch vorgegeben werden: „Schauen Sie sich die ersten drei Akten im Aktenschrank an. Wenn Sie dort keine Antwort finden, schauen Sie sich die nächsten drei an. Hören Sie nach fünf Akten auf, egal was passiert.“ Das ist starr. Manchmal liefert die erste Akte einen Hinweis, der die gesamte Richtung der Untersuchung verändert, aber das Regelbuch zwingt den Detektiv dazu, weiterhin in den falschen Akten zu suchen.

DynaKRAG ist eine neue, intelligentere Art, wie der Detektiv arbeiten kann. Anstatt einem festen Regelbuch zu folgen, nutzt es einen flexiblen, lernbasierten Manager, der entscheidet, was der nächste Schritt ist, basierend auf dem, was bisher gefunden wurde.

So funktioniert es, unterteilt in einfache Konzepte:

1. Das Notizbuch des Detektivs (Der „Zustand“)

Jedes Mal, wenn der Detektiv ein neues Stück Papier (Beweismittel) findet, schreibt er es in ein Notizbuch. Dieses Notizbuch ist nicht einfach nur ein Stapel Papier; es ist eine lebendige Landkarte. Es verfolgt:

Was die ursprüngliche Frage war.
Welche Papiere bereits gelesen wurden.
Welche Hinweise fehlen (z. B. „Ich kenne den Namen des Diebes, aber ich weiß nicht, wo er wohnt“).
Welche Aktionen bisher unternommen wurden.

2. Das Menü der Züge (Die „Aktionen“)

In jedem Moment hat der Detektiv ein Menü mit möglichen Zügen zur Verfügung, aber nicht alle Züge sind immer verfügbar.

In den Regalen suchen: Nach weiteren Dokumenten suchen.
Die Frage neu formulieren: Vielleicht war die ursprüngliche Frage verwirrend; lassen Sie uns sie anders formulieren.
Einer Spur folgen: Wenn ein Dokument eine bestimmte Person erwähnt (eine „Brücken-Entität“), suchen Sie nach weiteren Informationen über diese Person.
Die Lücken prüfen: Fragen Sie: „Haben wir genug Informationen, um dies bereits zu lösen? Wenn nicht, was fehlt?“
Anhalten und lösen: Wenn die Beweise vollständig sind, schreiben Sie die endgültige Antwort.

3. Der zweistufige Entscheidungsprozess

Bevlich der Detektiv einen Zug wählt, passieren zwei Dinge:

Schritt A: Der Türsteher (Validitätsschicht): Stellen Sie sich einen Türsteher vor einem Club vor. Der Türsteher schaut sich die aktuelle Situation an und sagt: „Das kannst du gerade nicht tun.“ Zum Beispiel können Sie die Frage nicht „neu formulieren“, wenn Sie noch keine Dokumente gelesen haben. Sie können keiner Spur „folgen“, wenn Sie noch keinen Hinweis gefunden haben. Der Türsteher filtert die unmöglichen Züge heraus und lässt nur eine Liste von gültigen Optionen übrig.
Schritt B: Der Coach (Gelernter Controller): Nun, da der Türsteher dem Detektiv eine Liste der gültigen Züge überreicht hat, tritt der Coach ein. Der Coach hat aus tausenden vergangenen Detektivfällen gelernt. Er schaut in das aktuelle Notizbuch und sagt: „Von den verfügbaren gültigen Optionen ist diejenin, die uns gerade am effizientesten hilft, die Lösung des Rätsels zu finden, der Spur zur Adresse des Verdächtigen zu folgen.“

4. Warum das besser ist

Keine verschwendete Anstrengung: Alte Systeme würden vielleicht weiterhin nach Antworten suchen, selbst wenn sie bereits genug haben, oder sie würden immer wieder dieselbe Frage stellen. DynaKRAG weiß, wann man aufhören muss.
Anpassung an das Rätsel: Wenn der erste Hinweis einen völlig neuen Aspekt offenbart, wechselt das System sofort die Taktik (wie das Neuformulieren der Frage), anstatt blind einem vorgegebenen Plan zu folgen.
Energie sparen: Das System ist „token-effizient“. In der KI-Welt sind „Tokens“ wie Wörter oder Datenteile, die Geld und Zeit kosten. DynaKRAG hört auf, Beweise zu sammeln, sobald es genug hat, um das Rätsel zu lösen, was im Vergleich zu Systemen, die einfach immer weiter graben, Zeit und Geld spart.

Die Ergebnisse

Die Autoren haben diesen „smarten Detektiv“ an drei sehr schwierigen Puzzle-Datensätzen getestet (HotpotQA, 2Wiki und MuSiQue).

Bessere Antworten: Es hat mehr Rätsel korrekt gelöst als die bisher besten Methoden.
Intelligenteres Ausgeben: Es hat weniger Ressourcen (weniger „Token-Nutzung“) verwendet, um diese besseren Antworten zu erhalten.
Beweis des Konzepts: Als sie den „Coach“ (den gelernten Entscheidungsträger) entfernten und das System einfach die Züge zufällig aus der Liste der gültigen Optionen wählen ließen, sank die Leistung signifikant. Dies beweist, dass die Wahl des nächsten Schritts genauso wichtig ist wie die Fähigkeit, den Schritt überhaupt auszuführen.

Kurz gesagt: DynaKRAG verwandelt die KI von einem Roboter, der einem starren Skript folgt, in einen flexiblen Detektiv, der genau weiß, welches Werkzeug er als Nächstes einsetzen muss, basierend auf dem, was er bereits entdeckt hat, um sicherzustellen, dass er das Rätsel mit dem geringsten Aufwand an verschwendeter Energie löst.

Technisches Resümee: DynaKRAG

Problemstellung

Multi-Hop Retrieval-Augmented Generation (RAG) adressiert Fragen, bei denen die Antwort von Evidenz abhängt, die über mehrere Dokumente und Reasoning-Schritte verteilt ist. Im Gegensatz zu Standard-RAG, das typischerweise einem festen „Retrieve-then-Generate“-Paradigma folgt, erfordert Multi-Hop-Fragen einen sich entwickelnden Prozess der Informationsakquisition. Ein einzeln abgerufener Passus reicht selten aus; stattdessen kann er eine „Brückenentität“ offenbaren, eine fehlende Relation aufzeigen, einen Abfragefehler indizieren oder ausreichende Unterstützung bieten, um den Prozess zu stoppen.

Bestehende adaptive RAG-Methoden (z. B. IRCoT, Self-Ask, CRAG, S2G-RAG) führen nützliche Verhaltensweisen wie iteratives Retrieval, Abfrage-Reformulierung, Evidenz-Kritik und Suffizienzprüfung ein. Diese Methoden organisieren diese Operationen jedoch typischerweise innerhalb methomenspezifischer Pipelines oder vordefinierter Kontrolltopologien. Diese Fragmentierung schafft zwei primäre Limitationen:

Mangel an vereinheitlichter Kontrolle: Heterogene Evidenz-Operationen sind innerhalb eines einzelnen Frameworks schwer auszudrücken, zu vergleichen und zu erlernen. Ein System, das entscheidet, mehr abzurufen, weiß möglicherweise nicht, wann eine Umformulierung besser wäre, und ein Suffizienzmodul erkennt zwar eine fehlende Information, kann aber nicht gemeinsam mit der Brücken-Expansion oder dem Stoppen abwägen.
Ineffizienz: Adaptive Trajektorien können wiederholt Retriever und Sprachmodelle aufrufen. Ohne eine gelernte Policy zur Koordination dieser Operationen verschwenden Systeme möglicherweise Token für redundante Evidenz oder versäumen es zu stoppen, wenn die Evidenz ausreichend ist.

Die zentrale Herausforderung besteht darin, eine gemeinsame zustandsbedingte Policy zu erlernen, die dynamisch zwischen derzeit gültigen Evidenz-Operationen wählt, während sich der Evidenzzustand entwickelt, wobei Retrieval, Diagnose und gap-gerichtete Akquisition gegeneinander abgewogen werden.

Methodik: DynaKRAG

DynaKRAG (Dynamic Knowledge Retrieval-Augmented Generation) formuliert die Multi-Hop-Evidenzakquisition als zustandsbedingte Kontrolle über atomare Evidenz-Operationen. Es entkoppelt die Gültigkeit einer Aktion von ihrem Nutzen, wodurch Regeln die Konsistenz der Übergänge erzwingen können, während das Lernen bestimmt, welche Operation am nützlichsten ist.

1. Unified Evidence-Action Framework

Das System modelliert den Prozess als Trajektorie $\tau = (s_0, a_0, s_1, a_1, \dots, s_T)$ .

Zustand ( $s_t$ ): Kodiert beobachtbare Informationen einschließlich der Frage, abgerufer Dokumente, Statistiken der Retrieval-Frontier, Aktionshistorie, detektierte Brückenentitäten und diagnostisches Feedback (z. B. Beschreibungen fehlender Informationen). Entscheidend ist, dass es zur Inferenzzeit keine Gold-Antworten oder Support-Annotationen enthält.
Atomare Operationen: Das Framework definiert sieben atomare Aktionen:
- Retrieval/Expansion: retrieve_more (treibt die Frontier voran), gap_query (zielt auf fehlende Fakten ab), bridge_entity_expand (ruft Informationen um detektierte Entitäten ab), rewrite_query (reformuliert basierend auf der Evidenz).
- Diagnose/Terminierung: sufficiency_check (fragt den Generator, ob die Evidenz ausreichend ist; falls nicht, wird die fehlende Information protokolliert), stop_answer.
- Post-Processing: compress_answer_evidence (extrahiert unterstützende Textfragmente vor der finalen Generierung).
Validity Layer (Gültigkeitsschicht): Eine harte, regelbasierte Schicht konstruiert den ausführbaren Aktionssatz $A(s_t)$ , indem sie undefinierte, erschöpfte oder verfrühte Operationen herausfiltert (z. B. verhindert das Ausführen von gap_query, wenn keine Lücke bekannt ist).

2. Gelernte State-Conditioned Control Policy

DynaKRAG verwendet einen gelernten Controller, um die gültigen Aktionen zu ranken:

Action-Value Model: Ein Random-Forest-Regressor $\hat{v}_\theta(s, a)$ $\overset{v}{^}_{θ} (s, a)$ schätzt die Verbesserung, die eine Aktion zum Evidenzzustand beiträgt.
- Trainingsziele: Während des Trainings wird der Wert $v(s, a)$ durch die Änderung der Support Recall (SR) (der Anteil der annotierten unterstützenden Dokumente) definiert. Für Akquisitionsaktionen gilt $v = SR(s') - SR(s)$. Für die Suffizienzprüfung sagt es voraus, ob $SR(s)=1$. Für den Stopp wird basierend auf der aktuellen Abdeckung gewertet.
- Inferenz: Der Controller wählt die Aktion $a^*$ , die den Wert abzüglich eines Kosten-Terms maximiert: $a^* = \arg\max_{a \in A(s_t)} [\hat{v}_\theta(s_t, a) - \lambda c(s_t, a)]$ .
Continuation Model: Ein separates Modell schätzt den Nutzen der Fortsetzung der Trajektorie, um ein vorzeitiges Stoppen zu verhindern, wenn zusätzliche Evidenz voraussichtlich helfen würde.
Terminal Compression: Bei der Terminierung extrahiert ein Kompressor sich gegenseitig unterstützende Fragmente aus dem akkumulierten Kontext, um die Belastung des finalen Antwort-Generators zu reduzieren.

3. Inferenzprozedur

Die Inferenzschleife (Algorithmus 1) iteriert wie folgt:

Konstruiere den gültigen Aktionssatz $A(s_t)$ basierend auf den aktuellen Zustandsbeschränkungen.
Score die gültigen Aktionen mittels des gelernten Value-Modells.
Wähle die am höchsten bewertete Aktion aus.
Führe die Aktion aus (z. B. Abfrage des dichten Index, Aktualisierung des Zustands).
Wiederhole, bis stop_answer gewählt wird oder eine Limitierung für Retrieval/Aktionen erreicht ist.
Optional: Komprimiere die Evidenz und generiere die finale Antwort.

Kernbeiträge

Vereinheitlichtes Framework: Die Arbeit schlägt ein einheitliches Evidenz-Aktions-Framework vor, in dem heterogene RAG-Strategien als atomare Operationen über einen gemeinsamen Zustand dargestellt werden, weg von isolierten, methodenspezifischen Pipelines.
Kosteneffizienter gelernter Controller: Es wird ein Controller entwickelt, der die harte Validität einer Aktion von deren zustandsbedingtem Nutzen trennt. Dies ermöglicht die dynamische Koordination von Retrieval, Diagnose, Reformulierung und Terminierung entlang einer sich entwickelnden Trajektorie, ohne den zugrunde liegenden Retriever oder Generator zu ersetzen.
Empirische Validierung: Durch kontrollierte Experimente auf drei Benchmarks isolieren die Autoren die Effekte des gelernten Action-Rankings, des Suffizienz-Feedbacks und der terminalen Kompression und zeigen, dass die dynamische Kontrolle konsistente Gewinne in Qualität und Effizienz liefert.

Experimentelle Ergebnisse

Die Autoren evaluierten DynaKRAG unter Verwendung von Qwen2.5-7B-Instruct, GPT-4o-mini und Llama-3.1-8B-Instruct als Backbone-Generatoren, trainiert auf HotpotQA, 2WikiMultiHopQA und MuSiQue.

Performance: DynaKRAG erreichte die höchsten F1-Scores auf allen drei Benchmarks mit Qwen2.5-7B (0,5998 auf HotpotQA, 0,5340 auf 2Wiki, 0,3061 auf MuSiQue) und übertraf die stärksten kontrollierten Baselines (z. B. S2G-RAG, CoRAG) um 2,88 bis 7,19 Punkte.
Generalisierung: Die Policy, die auf Qwen-Trajektorien trainiert wurde, transferierte effektiv auf GPT-4o-mini und Llama-3.1-8B ohne Retraining und erreichte in den meisten Konfigurationen State-of-the-Art-Ergebnisse. Dies deutet darauf hin, dass die gelernte Policy allgemeine Präferenzen für die Evidenzakquisition erfasst, statt auf einen spezifischen Generator zu überoptimieren.
Effizienz: DynaKRAG reduzierte den gesamten Token-Verbrauch im Vergleich zur stärksten F1-Baseline (S2G-RAG) um 13,1 % bis 20,7 %, während es gleichzeitig eine höhere Genauigkeit erzielte.
Ablationsstudien:
- Ersetzte man den gelernten Controller durch eine uniforme-valide Policy, sank der F1-Wert um 3,96–5,78 Punkte, was beweist, dass die bloße Bereitstellung von Aktionen nicht ausreicht; das Ranking der Aktionen ist entscheidend.
- Das Entfernen des Suffizienz-Feedbacks verschlechterte die Performance über alle Datensätze hinweg, was den Wert einer expliziten Bewertung der Evidenz-Bereitschaft bestätigt.
- Das Entfernen der terminalen Kompression verschlechterte die Performance ebenfalls, was den Nutzen der Kontext-Verfeinerung unterstreicht.
Sensitivität des Retrieval-Budgets: Kontrollierte Experimente zeigten, dass „mehr Retrieval“ nicht einheitlich vorteilhaft ist. Beispielsweise erreichte die Performance auf MuSiQue bei zwei Retrieval-Aufrufen ihren Höhepunkt und sank bei drei, was zeigt, dass eine dynamische Kontrolle notwendig ist, um Budgets basierend auf dem spezifischen Evidenzzustand effektiv zuzuweisen.

Bedeutung und Behauptungen

Die Arbeit behauptet, dass adaptive Multi-Hop-RAG davon abhängt, geeignete Evidenz-Operationen aus dem aktuellen Informationszustand auszuwählen. Durch die Rahmung der Evidenzakquisition als geschlossener Regelkreis (Closed-Loop Control) überwindet DynaKRAG die Fragmentierung bestehender Methoden.

Die Autoren betonen, dass ihr Ansatz den Nutzen der Koordination von Retrieval, Diagnose und Gap-gerichteter Akquisition unter einem sich entwickelnden Evidenzzustand demonstriert. Die Ergebnisse legen nahe, dass eine vereinheitlichte, gelernte Kontroll-Policy spezialisierten, pipeline-basierten Systemen sowohl in der Antwortqualität als auch in der Token-Effizienz überlegen sein kann und dass diese Kontrollstrategien über verschiedene Sprachmodell-Backbones hinweg generalisieren können. Die Arbeit etabliert, dass die Entscheidung darüber, was als Nächstes zu tun ist (Retrieval, Rewrite, Suffizienzprüfung oder Stopp), ebenso kritisch ist wie das Retrieval selbst, und dass diese Entscheidung durch eine zustandsbedingte Policy getrieben werden sollte und nicht durch feste Heuristiken.