Simple Graph-RAG halbiert Halluzinationen – ohne komplexes Knowledge Graph Schema

Die kurze Version

Ein simpler Document-Graph halbiert Halluzinationen – bei nur moderater Token-Erhöhung.

Das Paper “Reducing Hallucinations in Complex Question Answering using Simple Graph-based Retrieval-Augmented Generation” (arXiv 2606.05901) testet Vector-RAG gegen Vector+Graph-RAG auf dem MoNaCo-Benchmark (1315 komplexe Wikipedia-Fragen). Das Ergebnis: Die Einführung eines leichtgewichtigen Graph-Toolsets steigert Precision und Recall der faktischen Korrektheit, halbiert die Anzahl halluzinierter Antworten und erreicht den höchsten Feingranular-Truthfulness-Score – bei nur bescheidener Erhöhung der Token-Nutzung.

---

Das Problem: Wo Vector-RAG scheitert

Retrieval-Augmented Generation (RAG) ist der Standard-Ansatz, um LLMs auf proprietäres Wissen zuzuschneiden. Der typische Flow:

1. Dokumente in Chunks zerlegen
2. Chunks vektorisieren
3. Bei Query: semantisch ähnliche Chunks zurückgeben
4. LLM synthetisiert Antwort aus den Chunks

Das funktioniert für einfache Fragen. Für komplexe Fragen nicht.

Beispiel aus dem Paper:

“Can you name all the battles between the Dutch and English in the First, Second and Third Anglo-Dutch Wars, and list the victor of each battle?”

Diese Frage erfordert:

• Multi-Entity-Reasoning (MEQA): Mehrere Nationen, Kriege, Schlachten, Sieger
• Multi-Hop-Navigation (MHQA): Hierarchische Traversierung, relationale Expansion
• Cross-Document-Zugriff (CDQA): Information verteilt über Dutzende Artikel

Vector-RAG gibt semantisch ähnliche Chunks zurück – aber die Verbindung zwischen “First Anglo-Dutch War” und “Battle of Scheveningen” ist ein struktureller Link, keine semantische Ähnlichkeit. Der Agent verpasst ihn.

---

Der Ansatz: Document-Graph statt Knowledge Graph

Vom Knowledge Graph zum Document Graph

Der Unterschied liegt nicht im Graph – sondern im Schema.

1. 01
   Artikel
2. 02
   Abschnitte
3. 03
   Paragraphen
4. 04
   Links
5. 05
   Antwort

Der entscheidende Design-Choice des Papers: Kein komplexes Knowledge Graph Schema.

Stattdessen nutzen sie den bestehenden Dokumenten-Baum:

(Article: Anglo-Dutch Wars)
  └─ (Section: First Anglo-Dutch War)
      └─ (Paragraph: Overview)
          └─ Link → (Article: Battle of Scheveningen)
              └─ (Section: Aftermath)
                  └─ (Paragraph: Dutch victory)

Der Graph hat nur drei Knotentypen:

• Article (Dokument-Ebene)
• Section (Abschnitts-Ebene)
• Paragraph (Text-Ebene)

Und drei Kantentypen:

• CONTAINS (Artikel → Section → Paragraph)
• LINKS_TO (Paragraph → Artikel)
• MENTIONS (Paragraph → Entity, optional)

Das ist absichtlich simpel. Das Paper argumentiert: Komplexe Schemas überfordern den LLM-Kontext. Ein kleines Schema ist besser verdaulich, auch wenn es weniger ausdrucksstark ist.

---

Die Tools: Nicht der Agent generiert Queries

Agent-Tool-Strategie

Text-to-Cypher

• Agent generiert Cypher/SPARQL aus Frage
• Flexibel, aber fehleranfällig
• Sicherheitsrisiko: Injection möglich
• Benötigt fein-tuned LLM

Pre-defined Tools

• Agent wählt aus vorgefertigten Tools
• Robust, aber weniger flexibel
• Kein Query-Generation, kein Injection-Risiko
• Funktioniert mit Standard-Modellen

Der entscheidene architektonische Unterschied: Der Agent generiert keine Datenbank-Queries. Stattdessen wählt er aus einem Toolset vorgefertigter Queries.

Das Toolset des Papers:

Tool	Funktion	Wann genutzt
vector_search	Semantische Suche über Paragraph-Chunks	Schnelle Antworten, einfache Fragen
article_by_title	Direkter Artikel-Zugriff	Wenn der Agent einen spezifischen Artikel kennt
sections_of_article	Liste aller Abschnitte eines Artikels	Navigation bei unbekanntem Artikel
paragraphs_of_section	Alle Paragraphen eines Abschnitts	Content-Extraction
linked_articles	Artikel, die von einem Paragraph verlinkt werden	Cross-Document-Traversal
search_within_article	Volltextsuche innerhalb eines Artikels	Fokussierte Suche bei großen Artikeln

Der Agent entscheidet welches Tool, nicht wie die Query lautet.

---

Die Ergebnisse

Szenario	Richtig	Falsch	Unbekannt	Halluziniert
Zero-Shot (nur LLM)	23.2%	34.8%	32.1%	9.9%
Vector-RAG	31.4%	28.3%	28.7%	11.6%
Vector+Graph-RAG	38.7%	22.1%	28.9%	5.3%

Die wichtigsten Zahlen:

• Halluzinationen halbiert: Von 11.6% (Vector-RAG) auf 5.3% (Vector+Graph)
• Korrekte Antworten +23%: Von 31.4% auf 38.7%
• Falsche Antworten -22%: Von 28.3% auf 22.1%
• Token-Overhead: Nur moderate Erhöhung (ca. 15-20% mehr Tokens pro Query)

Warum “Unbekannt” wichtig ist:

Das Paper nutzt explizit “safe refusal” – der Agent soll “I don’t know” sagen, wenn die Information fehlt. Vector+Graph-RAG behält dieses Verhalten bei (28.9% vs. 28.7%), während die Qualität der beantworteten Fragen steigt. Das ist kritisch: Das System lügt nicht öfter, es weiß öfter richtig.

---

Warum das funktioniert: Zwei Retrieval-Paradigmen

Die Komplementarität von Vector und Graph

• Vector-RAG: Findet was semantisch ähnlich ist. Gut für: Definitionen, Zusammenfassungen, thematisch verwandte Texte.
• Graph-RAG: Findet was strukturell verbunden ist. Gut für: Verknüpfungen, Hierarchien, zeitliche Abfolgen, Kausalitäten.
• Komplexe Fragen brauchen beides: Semantische Einstiegspunkte + strukturelle Navigation zu verwandten Dokumenten.

Die Erkenntnis ist nicht “Graph ist besser als Vector”. Die Erkenntnis ist: Die sind komplementär.

Typischer Agent-Loop im Paper:

1. Vector-Suche für den Einstieg: “Welche Artikel sind dem Thema nah?”
2. Graph-Traversal für die Vertiefung: “Welche Abschnitte/Paragraphen/Links führen zur Antwort?”
3. Kombination beider Kontexte für die Synthese

Das ist keine Ersatz-Strategie. Es ist eine Ergänzungs-Strategie.

---

Praktische Umsetzung: Was du brauchst

Das Schema (vereinfacht):

// Neo4j-Beispiel aus dem Paper
CREATE (a:Article {title: "Anglo-Dutch Wars"})
CREATE (s:Section {title: "First Anglo-Dutch War"})
CREATE (p:Paragraph {text: "The war began in 1652..."})
CREATE (a)-[:CONTAINS]->(s)
CREATE (s)-[:CONTAINS]->(p)
CREATE (p)-[:LINKS_TO]->(other:Article {title: "Battle of Scheveningen"})

Die Mindest-Toolset (für deinen Agenten):

# Vereinfachte Tool-Definitionen
tools = [
    {
        "name": "search_paragraphs",
        "description": "Semantic search over paragraph chunks",
        "parameters": {"query": "string", "top_k": "integer"}
    },
    {
        "name": "get_article_sections",
        "description": "List all sections of an article",
        "parameters": {"article_title": "string"}
    },
    {
        "name": "get_section_paragraphs",
        "description": "Get paragraphs of a specific section",
        "parameters": {"article_title": "string", "section_title": "string"}
    },
    {
        "name": "get_linked_articles",
        "description": "Articles linked from a paragraph",
        "parameters": {"paragraph_id": "string"}
    }
]

Was du NICHT brauchst:

• Entity-Extraction-Pipelines
• Ontologie-Design
• Graph-Embeddings
• Community-Detection
• Komplexe Query-Generation

---

Grenzen und Trade-offs

Wann dieser Ansatz passt – und wann nicht

Passt

• ✓ Dokumentenbasierte KBs mit klarer Hierarchie (Wiki, Handbücher, Docs).
• ✓ Fragen, die über Dokumentgrenzen hinweg navigieren müssen.
• ✓ Setups, wo einfache Vector-RAG bei Multi-Hop-Fragen scheitert.
• ✓ Wenig Dev-Ressourcen: Der Graph ist schnell gebaut.

Nicht passend

• × Unstrukturierte Daten ohne Links oder Hierarchie (reine PDF-Sammlungen).
• × Fragen, die nur semantische Ähnlichkeit brauchen (Single-Doc-QA).
• × Wenn du bereits ein reichhaltiges Knowledge Graph mit Ontologie hast.
• × Wenn die Token-Kosten (15-20% mehr) das Budget sprengen.

Wichtige Einschränkungen aus dem Paper:

1. Benchmark-Spezifisch: MoNaCo ist Wikipedia-basiert. Andere Domänen (medizinische Texte, juristische Dokumente) haben andere Strukturen.

2. Graph-Bau notwendig: Der Ansatz braucht einen vorhandenen Dokumenten-Baum. Unstrukturierte PDF-Sammlungen müssen erst strukturiert werden.

3. Tool-Auswahl ist der Flaschenhals: Der Agent muss lernen, wann Vector vs. Graph-Tools genutzt werden. Das Paper nutzt ein festes Agent-Prompt; Adaptive Tool-Selektion ist offenes Problem.

4. Skalierung des Graphs: Bei sehr großen KBs (Millionen Artikel) werden Graph-Traversierungen langsam. Das Paper testet mit einer “curated subset” – nicht Web-Scale.

---

Vergleich mit anderen Graph-RAG-Ansätzen

Ansatz	Schema-Komplexität	Graph-Bau	Query-Strategie	Token-Kosten
Microsoft GraphRAG	Hoch (Communities, Entitäten, Beziehungen)	LLM-basiert (teuer)	Community-Summaries	Sehr hoch
Text-to-Cypher/SPARQL	Mittel (Ontologie-basiert)	Manuell oder Semi-auto	LLM-generiert	Mittel (LLM generiert Queries)
Dieser Ansatz	Niedrig (Dokument-Baum)	Automatisch (Dokumentstruktur)	Pre-defined Tools	Niedrig-Mittel

Der entscheidende Trade-off:

• GraphRAG (Microsoft): Reichhaltiges Schema, aber teuer im Bau und Query
• Text-to-Cypher: Flexibel, aber fehleranfällig und sicherheitskritisch
• Document-Graph (dieser Ansatz): Einfach, robust, sicher – aber weniger ausdrucksstark für komplexe relationale Queries

---

Fazit

Das Paper liefert eine pragmatische Erkenntnis: Man braucht kein komplexes Knowledge Graph Schema, um Halluzinationen in komplexen QA-Systemen zu halbieren. Man braucht nur strukturierte Navigation über Dokumente.

Der Document-Graph (Artikel → Abschnitte → Paragraphen → Links) ist simpel genug für schnellen Bau, robust genug für Produktion, und komplementär genug zu Vector-RAG, um beide Welten zu verbinden.

Für Agent-Builder:

• Nutze Vector-RAG für den Einstieg und thematische Verwandtschaft
• Nutze Document-Graph-Tools für strukturelle Navigation und Cross-Document-Reasoning
• Lass den Agent entscheiden welches Tool, nicht wie die Query lautet
• Akzeptiere “Unbekannt” als legitime Antwort – besser als Halluzination

Paper: arXiv:2606.05901
Benchmark: MoNaCo (1315 komplexe Wikipedia-Fragen)
Code: ( angekündigt, noch nicht veröffentlicht)