Naive, Advanced, Modular RAG: Die Architektur-Taxonomie nach Gao et al. (2023)

1. Warum Naive RAG nicht ausreicht

Gao et al. (2023) ^[1] beschreiben Naive RAG als simple Sequenz aus Indexierung, Retrieval (typischerweise Dense Passage Retrieval nach Karpukhin et al., 2020 ^[2]) und Generation. Das ist die Architektur jeder Demo — und scheitert in Produktion an drei Punkten:

• Recall-Probleme: Eine einzige Query trifft selten alle relevanten Chunks.
• Precision-Probleme: Top-k enthält oft irrelevante oder veraltete Passagen.
• Generation-Bias: Das LLM ignoriert Quellen, wenn diese widersprüchlich oder fragmentarisch sind (vgl. Shuster et al., 2021 ^[3]).

2. Advanced RAG — Pre- und Post-Retrieval-Optimierung

Advanced RAG fügt zwei Schichten ein:

• Pre-Retrieval: Query-Rewrite, Query-Expansion, hypothetische Antwortdokumente (HyDE), Routing nach Frage-Typ.
• Post-Retrieval: Rerank (Cross-Encoder), Kontext-Kompression, Deduplikation, Quellen-Scoring.

Beide Schichten sind empirisch validiert: Trivedi et al. (2023) ^[4] zeigen mit IRCoT, dass iteratives Retrieval die Antwortqualität bei mehrstufigen Fragen substantiell hebt. Advanced RAG ist heute der Industriestandard für Enterprise-Wissensanwendungen.

3. Modular RAG — Pipeline als Baukasten

Modular RAG (Gao et al., 2023 ^[1]) ersetzt die fixe Sequenz durch austauschbare Bausteine: Search-Module, Memory-Module, Fusion-Module, Routing-Module, Predict-Module. Praktische Pattern:

• Rewrite-Retrieve-Read: Query wird vor Retrieval umformuliert.
• Generate-Read: Hypothetische Antwort erzeugen, dann gegen Belege validieren.
• Iterative Retrieval: Mehrere Retrieval-Runden, gesteuert durch Zwischenantworten.
• Adaptive Retrieval: Modell entscheidet pro Frage, ob retrievet werden soll (vgl. Self-RAG, Asai et al., 2023 ^[5]).

Modular RAG ist die Voraussetzung für Auditierbarkeit: Jeder Baustein lässt sich isoliert testen, loggen und ersetzen — eine Grundbedingung für betriebsrätlich genehmigte KM-Systeme.

4. Was BusFactor aus der Taxonomie übernimmt

Unsere produktive RAG-Pipeline implementiert:

1. Pre-Retrieval: Query-Rewriting auf Rollen-Kontext, Routing zwischen Snippets, Dokumenten und Rollenwissen.
2. Hybrid Retrieval: Dense (Embeddings) + Sparse (BM25) mit Reciprocal Rank Fusion.
3. Post-Retrieval: Cross-Encoder-Rerank, Quellen-Filter nach Berechtigung, Kontext-Kompression.
4. Generation: Antworten mit Inline-Citations auf die zugrunde liegenden Chunks (vgl. RAG-Grundlagen).
5. Iterative Retrieval: Bei mehrstufigen Fragen folgen wir dem IRCoT-Pattern (Trivedi et al., 2023 ^[4]).

5. Was wir bewusst (noch) nicht modular machen

Gao et al. (2023) ^[1] beschreiben weitere Bausteine — z.B. Generator-Fine-Tuning, Retriever-Fine-Tuning, End-to-End-Optimierung. Wir setzen diese bewusst nicht ein, weil sie:

• die Auditierbarkeit reduzieren (Fine-Tuning verschleift Belege im Modell),
• die Übertragbarkeit zwischen Mandanten schwächen,
• in mittelständischen Kontexten selten den Aufwand rechtfertigen.

Fazit

Die Taxonomie von Gao et al. (2023) ^[1] gibt uns ein gemeinsames Vokabular: Wenn wir von »Rerank«, »HyDE« oder »Iterative Retrieval« sprechen, beziehen wir uns auf empirisch validierte Bausteine — nicht auf Marketing-Begriffe. BusFactor ist Advanced RAG mit ausgewählten Modular-Pattern; das ist 2026 der Sweet Spot zwischen Qualität, Auditierbarkeit und Betriebskosten.