FLARE: Aktive Retrieval Augmented Generation

Letzte Woche las ich das grundlegende RAG-Paper von Lewis et al. – einmal abrufen (retrieve), das Ergebnis voranstellen, generieren. Es funktioniert, setzt aber voraus, dass man im Voraus weiß, was man benötigt. FLARE (EMNLP 2023) greift diese Annahme direkt an: Was wäre, wenn der richtige Zeitpunkt für das Retrieval mitten im Satz liegt, genau dann, wenn das Modell unsicher wird? Diese Frage ist es wert, für jedes System sorgfältig durchdacht zu werden – wie etwa einen Beancount-Agenten –, das über eine Ledger-Historie urteilen muss, die nicht in ein einzelnes Kontextfenster passt.

Das Paper

"Active Retrieval Augmented Generation" von Zhengbao Jiang, Frank F. Xu, Luyu Gao, Zhiqing Sun, Qian Liu, Jane Dwivedi-Yu, Yiming Yang, Jamie Callan und Graham Neubig schlägt FLARE vor: Forward-Looking Active REtrieval augmented generation. Das Problem, das sie lösen, ist die Halluzination während der Langform-Generierung, bei der ein Modell mehrere Wissenselemente über eine längere Ausgabe hinweg abrufen muss. Standard-RAG führt das Retrieval einmal zum Zeitpunkt der Abfrage durch und hofft, dass der abgerufene Abschnitt alles abdeckt, was die Generierung benötigen wird – in Ordnung für kurze Antworten, aber anfällig für Antworten über mehrere Absätze.

FLARE unterteilt die Generierung in Schritte auf Satzebene. Bei jedem Schritt wird ein potenzieller nächster Satz generiert. Wenn ein Token in diesem Kandidaten eine vorhergesagte Wahrscheinlichkeit unter einem Schwellenwert θ aufweist, behandelt FLARE diese Spannen mit geringem Vertrauen als Retrieval-Signale, verwendet sie (entweder maskiert oder vervollständigt), um eine Suchanfrage zu formulieren, ruft Informationen von Wikipedia ab und generiert den Satz mit dem abgerufenen Kontext neu. Das Ergebnis ist ein System, das nur dann und in etwa dort abruft, wo es unsicher ist – anstatt das Retrieval für Inhalte vorzuziehen, die es vielleicht nie benötigt. Alle Experimente wurden auf GPT-3.5 (text-davinci-003) ohne Feinabstimmung durchgeführt.

Kernideen

• Konfidenz als Retrieval-Trigger: Eine Token-Wahrscheinlichkeit unter θ signalisiert, dass das Modell wahrscheinlich halluziniert; das Retrieval wird nur dann ausgelöst, nicht standardmäßig. Die Autoren stellten fest, dass das Auslösen bei 40–80 % der Sätze typischerweise am besten funktioniert.
• Vorausschauende Suchanfragen (Forward-looking queries): Anstatt nur das bereits Generierte als Suchanfrage zu verwenden (der „Previous-Window“-Ansatz), nutzt FLARE den vorhergesagten kommenden Satz – das, was das Modell glaubt sagen zu wollen – als eine viel gezieltere Retrieval-Anfrage.
• Zwei Varianten: FLARE-instruct maskiert Token mit geringem Vertrauen und verwendet die maskierte Spanne als Suchanfrage; FLARE-direct verwendet den gesamten vorhergesagten Satz. Bei 2WikiMultihopQA erreicht die Direct-Variante 51,0 EM gegenüber 42,4 bei der Instruct-Variante.
• Gewinne gegenüber Single-Retrieval sind real, aber ungleichmäßig: Bei 2WikiMultihopQA erreicht FLARE-direct 51,0 EM gegenüber 39,4 bei einmaligem Retrieval und 28,2 ohne Retrieval – eine deutliche Verbesserung. Bei ASQA ist der Unterschied viel geringer (41,3 vs. 40,0), und WikiAsp (UniEval 53,4 vs. 52,4) ist fast ein Gleichstand.
• Explizite Fehlerfälle: Die Autoren berichten, dass FLARE bei Wizard of Wikipedia und ELI5 keinen Gewinn bringt, da kurze Ausgaben bedeuten, dass mehrstufiges Retrieval zusätzlichen Overhead ohne Nutzen verursacht.
• Kosten: Da Generierung und Retrieval ineinandergreifen, kann jedes Beispiel mehrere LM-Vervollständigungen und Retrieval-Aufrufe auslösen. Caching ist nicht trivial.

Was Bestand hat – und was nicht

Der vorausschauende Ansatz ist der wirklich clevere Teil. Die Verwendung vorhergesagter Inhalte als Retrieval-Anfrage ist informativer als nur das Präfix, insbesondere bei Multi-Hop-Aufgaben, bei denen Zwischenergebnisse bestimmen, welche Fakten als Nächstes benötigt werden. Die Lücke von 51,0 zu 39,4 EM bei 2WikiMultihopQA untermauert dies.

Doch das Konfidenzsignal von FLARE hängt vollständig davon ab, wie gut das Modell kalibriert ist. Token-Wahrscheinlichkeiten eines Basis-Completion-Modells wie text-davinci-003 korrelieren einigermaßen mit Unsicherheit. Das Gleiche gilt nicht für instruktionsoptimierte oder per RLHF feinabgestimmte Chat-Modelle, die oft übermäßig selbstbewusst (overconfident) sind – sie geben Token mit hoher Wahrscheinlichkeit aus, selbst wenn sie halluzinieren. Eine Folgestudie aus dem Jahr 2024, Unified Active Retrieval (UAR, arXiv:2406.12534), testet FLARE an einer breiteren Suite von Retrieval-Entscheidungen und stellt fest, dass es in verschiedenen Szenarien nur eine Genauigkeit von 56,50 % erreicht, verglichen mit 85,32 % beim klassifikatorbasierten Ansatz von UAR. Das Kalibrierungsproblem ist kein Randfall; es ist die Kernannahme, auf der die Methode beruht.

Es gibt auch eine Frage zur Retrieval-Granularität, die das Paper nicht vollständig adressiert. Die Auslösung auf Satzebene ist eine vernünftige Heuristik, aber einige Fakten erstrecken sich über Satzgrenzen hinweg, während andere auf einen einzelnen Entitätsnamen beschränkt sind. Eine niedrige Wahrscheinlichkeit bei einem numerischen Token (ein Geldbetrag, ein Datum) sollte das Retrieval wahrscheinlich anders auslösen als eine niedrige Wahrscheinlichkeit bei einem Bindewort. Das Paper behandelt alle Token mit geringem Vertrauen symmetrisch.

Schließlich führt die Schleife „bei Unsicherheit neu generieren“ zu Latenzzeiten. Die Autoren räumen dies ein, quantifizieren es jedoch nicht im Verhältnis zu einem Latenzbudget, was für interaktive oder Echtzeitanwendungen von Bedeutung ist.

Warum dies für Finanz-KI wichtig ist

Ein Beancount-Agent, der ein mehrjähriges Ledger zusammenfasst, kann nicht alle historischen Einträge im Voraus abrufen – der Kontext würde überlaufen und das meiste davon wäre für die aktuelle Antwort irrelevant. Das Design von FLARE passt gut zu diesem Problem: Erstelle einen ersten Entwurf des Abstimmungskommentars, bemerke eine geringe Konfidenz beim laufenden Saldo eines bestimmten Kreditors, rufe nur die relevanten Transaktionen ab und generiere diesen Satz dann neu. Das Muster ist solide.

Das Kalibrierungsproblem ist jedoch ein ernsthaftes Bedenken. Produktive Finanz-Agenten verwenden fast ausschließlich instruktionsoptimierte Chat-Modelle (GPT-4, Claude, Gemini), keine Basis-Completion-Modelle. Wenn diese Modelle übermäßig selbstbewusst sind – was sie bei numerischen Angaben häufig sind –, werden sie das Retrieval genau dann überspringen, wenn sie es eigentlich auslösen sollten. Ein Beancount-Write-Back-Agent, der ein Transaktionsdatum mit hoher Konfidenz halluziniert und niemals einen Abruf zur Verifizierung durchführt, ist schlimmer als nutzlos.

Die praktische Lehre daraus ist, FLAREs vorausschauende Suchanfragenkonstruktion mit einem Retrieval-Trigger zu kombinieren, der sich nicht allein auf die Token-Wahrscheinlichkeit verlässt. Explizite Unsicherheitsmarker (Vermeidungsfloskeln, runde Zahlen, benannte Entitäten, die das Modell seit Längerem nicht gesehen hat) könnten das Konfidenzsignal ergänzen. Oder man wählt den UAR-Ansatz: Trainieren Sie einen leichtgewichtigen Klassifikator auf Basis der Hidden States des Modells, der robuster gegenüber Fehlkalibrierungen ist als reine Logits.

Was man als Nächstes lesen sollte

• IRCoT: "Interleaving Retrieval with Chain-of-Thought Reasoning for Knowledge-Intensive Multi-Step Questions" (arXiv:2212.10509) – koppelt Retrieval mit CoT-Schritten anstatt mit Token-Konfidenz; ein direkter Vergleich mit FLARE bei Multi-Hop-Aufgaben lohnt sich.
• Unified Active Retrieval (UAR, arXiv:2406.12534) – die direkte Folgestudie, die die Kalibrierungslücke von FLARE aufdeckt und klassifikatorbasierte Retrieval-Entscheidungen über vier Retrieval-Szenarien hinweg vorschlägt.
• "Adaptive Retrieval without Self-Knowledge? Bringing Uncertainty Back Home" (arXiv:2501.12835) – ein Paper aus dem Jahr 2025, das untersucht, ob Token-Wahrscheinlichkeits-basierte Trigger durch bessere Kalibrierungstechniken rehabilitiert werden können.