Zum Inhalt springen
zensation

Forschungsüberblick

Drei Tracks, Architektur und Agenda

Publikationen

Preprints, Software, Identifikatoren

Methodik

Operative Standards und Validierung

Forschungsethik

Grundrechtsbezug und Compliance

Ressourcen

Code, Daten, Zitation, Open Science

KI einführen

Neutraler Fahrplan & interaktive Simulation

Behörden & Förderung

Kooperationen im öffentlichen Sektor

Schutz öffentlicher Räume

Track B — grundrechtswahrende Frühwarnung

Technologie

Die Architektur hinter allen Anwendungen

Playground

Den offenen Memory-Kern live ausführen

ZusammenarbeitÜberOpen SourceBlog
Kontakt
zensation
ForschungsüberblickPublikationenMethodikForschungsethikRessourcen
KI einführenBehörden & FörderungSchutz öffentlicher RäumeTechnologiePlayground
ZusammenarbeitÜberOpen SourceBlogKontakt
Blog
Engineering

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

Alexander Bering
Alexander Bering
11. April 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 3 Iterationen.

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

Auf X teilenAuf LinkedIn teilen

Ähnliche Artikel

Der Härtetest: warum wir vor dem ersten Kunden zehn Sicherheits-Sprints gefahren sind

Zwischen 'läuft bei mir' und 'ein Unternehmen vertraut ihm seine Daten an' liegt eine Kluft, die viele KI-Projekte unterschätzen. Wie wir sie mit zehn aufeinanderfolgenden Härtungs-Sprints überbrückt haben.

Vom KI-Überblick zur echten Demo: Wie aus einem Blueprint autonom eine ZenAi-Instanz wird

Die meisten KI-Piloten scheitern nicht an der Technik, sondern am Sprung von der Idee zur greifbaren, kontextechten Anwendung. Wie aus einer Bestandsaufnahme autonom eine leichte, branchengerechte ZenAi-Instanz entsteht — und warum Ehrlichkeit (klar markierte Demo-Daten) der wichtigste Baustein ist.

91 % der Genauigkeit bei 1 % der Tokens — die Pareto-Position für AI-Memory

Auf LongMemEval-500 erreicht ZenBrain 91,3 % der Genauigkeit eines Long-Context-Oracles — bei 1/106 des Token-Budgets pro Anfrage. Das Oracle gewinnt um 4,5 Prozentpunkte, verbrennt dafür 106-fach mehr Tokens und hat keinerlei Memory-Architektur.

zensationUnabhängiges KI-Forschungslabor · Kiel
ForschungPublikationenMethodikForschungsethikRessourcenKI einführenBehördenSchutz öffentlicher RäumeTechnologieSystem-ExplorerPlaygroundZusammenarbeitOpen SourceÜber unsBlogChangelog
GitHubLinkedInarXivZenodoORCIDScholarSemantic ScholarHuggingFacenpmDiscussions

© 2026 Alexander Bering / ZenSation Enterprise Solutions

RSSDatenschutzImpressumBarrierefreiheit