Wie wir A-RAG gebaut haben: Wenn Retrieval nachdenkt, bevor es sucht

Alexander Bering
Alexander Bering
31. März 2026 · 4 min Lesezeit

Das Problem mit Standard-RAG

Retrieval-Augmented Generation (RAG) ist das Standardmuster, um LLMs Zugang zu externem Wissen zu geben. Die Pipeline ist einfach:

  1. Benutzeranfrage als Vektor einbetten
  2. Vektorstore nach ähnlichen Chunks durchsuchen
  3. Top-k-Ergebnisse in den Prompt einfügen
  4. Antwort generieren

Das funktioniert für einfache Abfragen. „Was ist unsere Rückgaberichtlinie?" Einbetten, suchen, fertig.

Aber was ist mit: „Vergleiche unsere Q1-Umsatztrends mit der Strategie aus dem letzten Board-Deck und identifiziere Widersprüche."

Diese Anfrage braucht mehrere Retrieval-Schritte. Sie braucht verschiedene Datenquellen. Sie braucht verschiedene Retrieval-Strategien. Sie braucht einen Plan.

Standard-RAG würde die gesamte Frage einbetten, den Vektorstore durchsuchen und eine zufällige Mischung aus Umsatzdaten und Strategiefragmenten zurückgeben — nichts davon beantwortet die eigentliche Frage.

Die Evolution: Von RAG zu CRAG zu A-RAG

Standard RAG (2023): Query einbetten, Vektoren suchen, Top-k zurückgeben. Keine Qualitätsbewertung. Kein Fallback bei schlechten Ergebnissen.

Self-RAG (Asai et al., 2023): Fügt einen Kritik-Schritt hinzu. Nach dem Retrieval bewertet das System, ob die Ergebnisse ausreichen. Bei niedriger Konfidenz wird reformuliert und erneut gesucht.

CRAG (Corrective RAG, Yan et al., 2024): Fügt ein Quality Gate hinzu, das Ergebnisse als korrekt, mehrdeutig oder falsch klassifiziert und entsprechend routet.

A-RAG (unser Ansatz): Ein Meta-Agent, der über die optimale Retrieval-Strategie nachdenkt, bevor er sucht. Er klassifiziert den Query-Typ, wählt Retrieval-Interfaces, generiert einen mehrstufigen Plan mit Abhängigkeiten und führt mit Quality Gates bei jedem Schritt aus.

Der Kernunterschied: A-RAG korrigiert nicht nur schlechtes Retrieval. Es verhindert es, indem es die richtige Strategie vorab wählt.

So funktioniert A-RAG

Schritt 1: Query-Klassifikation (ohne LLM-Kosten)

Jede Anfrage wird per Heuristik klassifiziert — kein LLM-Aufruf nötig:

  • simple_lookup — Einzelfakt-Abruf („Was ist X?")
  • multi_hop — Verbindung von Informationen über Dokumente hinweg
  • comparison — Daten aus mehreren Quellen vergleichen
  • temporal — Zeitbasierte Abfragen („Was hat sich seit Q1 geändert?")
  • analytical — Synthese über mehrere Datenpunkte

Einfache Queries (60-70% des Traffics) überspringen die Planung komplett — null zusätzliche Latenz. Nur komplexe Queries lösen die volle Pipeline aus.

Schritt 2: Strategie-Agent (LLM-gestützte Planung)

Für komplexe Queries erstellt ein Claude-basierter Strategie-Agent einen Retrieval-Plan als strukturiertes JSON:

{
  "steps": [
    { "interface": "semantic", "query": "Q1 Umsatztrends 2026", "depends_on": [] },
    { "interface": "keyword", "query": "Board Deck Strategie Q1", "depends_on": [] },
    { "interface": "graph", "query": "Umsatz Strategie Widersprüche", "depends_on": [0, 1] }
  ]
}

Fünf Retrieval-Interfaces stehen zur Verfügung:

| Interface | Funktionsweise | Ideal für | |-----------|---------------|-----------| | keyword | BM25-Volltextsuche | Exakte Begriffe, Namen | | semantic | Vektorähnlichkeit (pgvector) | Konzeptuelle Ähnlichkeit | | chunk_read | Direkter Dokumentzugriff | Bekannte Dokumente | | graph | Wissensgraph-Traversierung | Beziehungen, Multi-Hop | | community | Graph-Community-Summaries | Übergeordnete Themen |

Unabhängige Schritte laufen parallel. Abhängige warten auf Voraussetzungen. Maximum 4 Schritte.

Schritt 3: Graph-basierte Query-Erweiterung

Wenn ein Retrieval-Schritt niedrige Konfidenz liefert, wiederholt A-RAG nicht einfach die gleiche Query. Es erweitert sie über den Wissensgraphen:

  1. Entitäten in der Query nachschlagen
  2. Verwandte Entitäten und Relationstypen aus dem Graph finden
  3. Erweiterungsterme zur Original-Query hinzufügen
  4. Erneut abrufen mit angereicherter Query

Der Unterschied: Statt nach „Umsatztrends" zu suchen, sucht man nach „Umsatztrends, ARR, MRR, Quartalswachstum, Board-Projektionen" — der Graph liefert domänenspezifischen Kontext.

Schritt 4: Quality Gates mit Konfidenz-Scoring

Nach jeder Iteration wird ein 4-Komponenten-Score berechnet:

  • topScore — Beste individuelle Trefferqualität
  • avgScore — Durchschnitt über alle Ergebnisse
  • variance — Konsistenz der Ergebnisse
  • diversity — Abdeckung verschiedener Quellen

Drei Schwellwerte steuern den Fluss:

EARLY_EXIT = 0.8    Stopp, Ergebnisse sind exzellent
CONTINUE   = 0.5    Weiter zur nächsten Iteration
REFORMULATE < 0.5   Query erweitern und erneut versuchen

Maximum 3 Iterationen. In der Praxis lösen sich die meisten Queries in 1-2 Iterationen.

Die GraphRAG-Grundlage

A-RAG operiert auf einer 3-Schichten-Graph-Architektur:

Schicht 1 — Event-Subgraph: Temporale Interaktionen mit Zeitstempeln. „Nutzer besprach Projekt X mit Kollege Y am 15. März." Diese Schicht bedient temporale Queries.

Schicht 2 — Semantischer Graph: Benannte Entitäten, getypte Relationen, Community-Detection via Louvain-Algorithmus, Zentralitätsmetriken.

Schicht 3 — Community-Zusammenfassungen: Auto-generierte Cluster-Summaries für übergeordnete Fragen. „Was sind die Hauptthemen meiner Forschung?" nutzt Community-Summaries statt einzelner Fakten.

Retrieval-Strategien werden mit gelernten Gewichten kombiniert: Semantisch 0,5, Events 0,3, Community 0,2.

Contextual Retrieval: Bessere Chunks

Bevor Retrieval stattfindet, erweitern wir unsere Chunks mit Anthropics Contextual-Retrieval-Methode. Jeder Chunk bekommt einen 1-2 Satz Kontextpräfix, generiert von Claude Haiku, der erklärt, wo der Chunk im Quelldokument vorkommt.

Das erreicht 35-67% weniger Retrieval-Fehler gegenüber Standard-Chunking.

Referenzen

  • Asai, A., et al. (2023). Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. arXiv:2310.11511.
  • Yan, S., et al. (2024). Corrective Retrieval Augmented Generation. arXiv:2401.15884.
  • Anthropic (2024). Introducing Contextual Retrieval. anthropic.com/news/contextual-retrieval.

Implementierung

A-RAG ist in ZenAIs Backend implementiert:

  • arag/strategy-agent.ts — Query-Klassifikation + Plan-Generierung
  • arag/iterative-retriever.ts — Plan-Ausführung mit Quality Gates
  • arag/strategy-evaluator.ts — Konfidenz-Scoring

Quellcode: github.com/zensation-ai/zenbrain Technische Referenz: zensation.ai/technologie