Self-RAG (Asai et al., 2023): Wenn das Modell selbst entscheidet, wann es nachschlagen muss

1. Das Problem klassischer RAG-Pipelines

Naive und selbst Advanced RAG (vgl. Gao et al., 2023 ^[2]) leiden an drei Schwächen:

• Übermäßiges Retrieval: Auch bei Fragen, die das Modell aus Parametern beantworten kann, werden Passagen geholt — oft mit irrelevantem Kontext.
• Fehlende Belegprüfung: Das LLM generiert auf Basis der Passagen, ohne zu prüfen, ob diese die Aussage tatsächlich stützen.
• Statische Strategie: Eine Pipeline pro Frage, kein Anpassen während der Generation.

2. Wie Self-RAG das löst

Asai et al. (2023) ^[1] trainieren ein LLM, das vier Klassen spezieller Reflection-Tokens ausgibt:

• Retrieve: Entscheidet pro Segment, ob jetzt retrievet werden soll.
• IsRel: Bewertet, ob ein retrieveter Passage relevant ist.
• IsSup: Bewertet, ob die generierte Aussage durch die Passage gestützt wird.
• IsUse: Bewertet die Gesamtnützlichkeit der Antwort.

Das Modell wird auf einem Datensatz mit annotierten Reflection-Tokens trainiert (Generator-Modell + Critic-Modell). In Inferenz produziert es Antwort-Segmente und parallel die Self-Reflection — und kann Pfade per Tree-Decoding nach Score auswählen.

3. Empirische Befunde

Self-RAG übertrifft laut Asai et al. (2023) ^[1] starke Baselines (ChatGPT, Llama2-chat, Standard-RAG) auf mehreren Benchmarks (PopQA, TriviaQA, PubHealth, ASQA, FactScore). Besonders deutlich: die Faktentreue (Citation Precision/Recall) verbessert sich gegenüber Standard-RAG signifikant — konsistent mit den allgemeinen Halluzinationsbefunden aus Shuster et al. (2021) ^[3] und Trivedi et al. (2023) ^[4].

4. Warum wir bei BusFactor kein Self-RAG-Fine-Tuning machen

Self-RAG verlangt:

1. Annotierte Trainingsdaten mit Reflection-Tokens (im Paper über GPT-4 destilliert),
2. Custom-Fine-Tuning des Generators,
3. Inferenz-Tooling, das Reflection-Tokens parst und Tree-Decoding implementiert.

Für mittelständische Mandanten widerspricht das unseren Prinzipien aus der Methodik: Auditierbarkeit, Mandantenfähigkeit, Modellaustauschbarkeit. Wir nutzen daher das konzeptionelle Muster ohne Custom-Training.

5. Wie BusFactor das Pattern adaptiert

Konkret implementieren wir drei der vier Self-RAG-Ideen via Prompting + Routing:

• Adaptive Retrieval (Retrieve-Token-Äquivalent): Ein leichtgewichtiger Router entscheidet pro Frage, ob Snippets, Dokumente, Rollenwissen oder mehrere Quellen kombiniert werden — oder ob das Modell aus generischem Wissen antwortet.
• Relevanz-Filter (IsRel-Äquivalent): Cross-Encoder-Rerank entfernt irrelevante Passagen vor der Generation (vgl. Advanced RAG).
• Self-Critique (IsSup-Äquivalent): Bei hochsensiblen Antworten validiert ein zweiter Pass die Aussagen gegen die Quellen-Chunks und markiert nicht-gestützte Behauptungen.

Damit erreichen wir einen großen Teil der Self-RAG-Vorteile, ohne uns an ein spezifisches Modell zu binden.

6. Grenzen — und warum das ehrlich gesagt sein muss

Self-RAG ist kein Wundermittel:

• Tree-Decoding erhöht Latenz und Token-Kosten erheblich.
• Reflection-Tokens sind selbst fehleranfällig — Self-Critique kann systematische Bias übernehmen.
• Auf KMU-Wissensbasen mit weniger Trainingsdaten ist Custom-Self-RAG selten lohnend.

Fazit

Self-RAG (Asai et al., 2023) ^[1] verschiebt RAG von einer starren Pipeline zu einer adaptiven Strategie. Auch ohne Custom-Training ist das Pattern wertvoll — als Inspiration für Routing, Rerank und Self-Critique in produktiven RAG-Systemen. Genau dort verankern wir die Self-RAG-Logik in der BusFactor-Architektur.