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

Canonical URL: https://huecki.com/blog/simple-graph-rag-hallucinations/
Markdown URL: https://huecki.com/blog/simple-graph-rag-hallucinations.md
Language: German
Published: 2026-07-02
Updated: 2026-07-02
Author: Dominic Hückmann
Topic: AI-first Engineering
- Agent topics: Agent Evals, LLM-native Engineering
- Tags: RAG, GraphRAG, Hallucinations, Knowledge Graph, AI Engineering, QA
Content status: field-note

## Summary

Vector-RAG + einfacher Document-Graph halbiert Halluzinationen auf komplexen QA-Aufgaben im MoNaCo-Benchmark. Die Erkenntnis: Man braucht kein komplexes Knowledge Graph Schema – nur strukturierte Navigation über Dokumente.

## Description

Ein neues Paper zeigt: Ein einfacher Document-Graph über Artikel, Abschnitte und Paragraphen reicht aus, um Halluzinationen in komplexen QA-Aufgaben zu halbieren. Der Trick ist nicht das Schema – sondern die Tool-Strategie.

## Body

## 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

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

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 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):**

```cypher
// 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):**

```python
# 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

**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](https://arxiv.org/abs/2606.05901)  
**Benchmark:** MoNaCo (1315 komplexe Wikipedia-Fragen)  
**Code:** ( angekündigt, noch nicht veröffentlicht)

## FAQ

### Was ist der Unterschied zwischen GraphRAG und dem Ansatz im Paper?

Klassisches GraphRAG (z.B. Microsoft) extrahiert Entitäten und Beziehungen aus Text und baut daraus ein Knowledge Graph. Dieser Paper-Ansatz nutzt den bestehenden Dokumenten-Baum: Artikel → Abschnitte → Paragraphen → Verlinkungen. Kein Entity-Extraction, kein Community-Detection – nur strukturierte Navigation.

### Warum funktioniert ein simpler Graph besser als Vector-RAG allein?

Vector-RAG gibt semantisch ähnliche Text-Chunks zurück. Bei komplexen Fragen fehlen oft die Verbindungsstücke zwischen Dokumenten. Ein Document-Graph erlaubt explizite Navigation: vom Artikel zum Abschnitt, zum Paragraph, zur verlinkten Quelle. Der Agent findet strukturell, was er semantisch verpasst hätte.

### Brauche ich Neo4j für diesen Ansatz?

Das Paper nutzt Neo4j/Cypher, aber der Graph ist simpel genug für jede Graph-Datenbank oder sogar rekursive Dateisystem-Abfragen. Das Schema ist: Dokument → Section → Paragraph → Link. Keine komplexen Ontologien nötig.