# RAG-Qualität

> Wenn Retrieval läuft, aber die Präzision nicht stimmt: Reranking, Query-Rewriting, Fusionsgewichtung und Grounding.

Track: [LLMOps](https://physar.tech/learn/llmops)  
Kanonische Fassung: https://physar.tech/learn/llmops/rag-quality  
Stand: 2026-07-22  
Interaktiver Teil: 11 Checks (nur im Browser)

## RAG-Qualität: warum das Retrieval läuft — und die Antworten trotzdem daneben liegen

### Erst diagnostizieren: Retrieval- oder Generierungs-Problem?

Die Pipeline steht, das System antwortet — aber die Qualität schwankt. Der teuerste Fehler an dieser Stelle ist, blind zu tunen. Bevor du irgendeinen Hebel ziehst, trenne die beiden Fehlerklassen: Sitzt das Problem im **Retrieval** (die richtigen Chunks kommen gar nicht erst an) oder in der **Generierung** (die richtigen Chunks sind da, aber das Modell nutzt sie schlecht)?

> **Trennschärfe:** Symptom „Antwort zitiert Irrelevantes“ → Retrieval. Symptom „relevanter Chunk war im Kontext, wurde aber ignoriert oder verdreht“ → Generierung. Derselbe Hebel hilft nie bei beidem.

### Präzision vs. Recall — die zwei Achsen des Retrievals

Retrieval-Qualität hat zwei Achsen, und sie brauchen **gegensätzliche** Eingriffe. **Recall:** Ist der relevante Chunk überhaupt unter den Kandidaten? **Präzision:** Stehen die relevanten Chunks weit oben und ist der Rest gefiltert?

|  |  |
| --- | --- |
| Der richtige Chunk fehlt ganz | Recall-Problem → mehr/andere Kandidaten holen |
| Der richtige Chunk ist dabei, aber verrauscht/weit unten | Präzisions-Problem → besser ranken/filtern |

> **Merksatz:** Recall-Probleme löst man **vor** dem Ranking (bessere Anfrage, mehr Kandidaten), Präzisions-Probleme **im** Ranking (Reranking, Filtern). Wer die falsche Achse tunt, dreht am toten Knopf.

### Bessere Anfragen: Query-Rewriting & Expansion

Retrieval ist nur so gut wie die Anfrage, die es bekommt. Kurze, mehrdeutige oder kontextabhängige Nutzer-Eingaben („geht nicht mehr“) sind der Normalfall — nicht die Ausnahme.

**Query-Rewriting** formuliert die Rohanfrage mit Chatverlauf/Kontext zu einer eigenständigen, präziseren Suchanfrage um — das adressiert Mehrdeutigkeit. **Query-Expansion** (mehrere Varianten der Frage, oder ein hypothetisches Antwort-Dokument à la HyDE) wirft ein breiteres Netz und hebt den **Recall**, wenn Nutzer- und Dokument-Vokabular auseinanderliegen.

> **Kosten benennen:** Beides sind zusätzliche LLM-Aufrufe **vor** dem Retrieval — Latenz und Geld. Nur einsetzen, wo Rohanfragen nachweislich schlecht performen, nicht prophylaktisch.

### Fusion justieren: die RRF-Gewichtung

Hybrid-Retrieval (BM25 + dense) fusioniert zwei Ranglisten, üblicherweise per Reciprocal Rank Fusion (RRF). RRF mit gleicher Gewichtung ist ein robuster Default — aber kein Naturgesetz.

_[Abbildung: RRF vereint beide Ranglisten allein über die Rangpositionen. Die relative Gewichtung der Signale ist ein Stellhebel — kein fixer Wert.]_

> **Wann justieren:** Erst wenn eine **schiefe** Query-Verteilung (z. B. viele exakte Codes) das eine Signal systematisch benachteiligt. Anfrageabhängige Gewichtung ist mächtig, aber jede Stellschraube ist auch Pflege- und Test-Fläche.

### Reranking: der stärkste Präzisions-Hebel

Der erste Retrieval-Schritt (BM25/dense) ist auf Durchsatz optimiert und rankt grob. Ein **Reranker** (Cross-Encoder) bewertet jedes Query–Chunk-Paar direkt und sortiert die Kandidaten neu — deutlich präziser, aber pro Paar teuer.

_[Abbildung: Der Cross-Encoder liest Query und Chunk gemeinsam und bewertet die Relevanz direkt — daher präziser als der Vektor-Abstand des ersten Schritts.]_

Zweiter Hebel am selben Ort: der **Cutoff** danach. Nach dem Reranking nur die besten `n` Chunks ans LLM geben — nicht alle Kandidaten. Mehr Chunks heißt nicht bessere Antwort, sondern mehr Rauschen und höhere Kosten.

> **Reihenfolge der Hebel:** Bei Präzisionsproblemen zuerst Reranking + Cutoff — nicht ein größeres LLM und nicht ein höheres `top-k` (das bringt nur mehr Rauschen).

### Den Kontext kuratieren: Diversität & Reihenfolge

Selbst nach dem Reranking ist der Kontext nicht automatisch gut. Zwei häufige Restprobleme:

**Redundanz:** Die Top-Treffer sind oft Beinahe-Duplikate — dieselbe Passage aus fünf leicht verschiedenen Dokumenten. Sie belegen einen Kontext-Platz, den ein ergänzender Aspekt bräuchte. **MMR** (Maximal Marginal Relevance) balanciert Relevanz gegen Neuheit und entdoppelt so.

**Reihenfolge:** Modelle nutzen den **Anfang und das Ende** eines langen Kontexts zuverlässiger als die Mitte („lost in the middle“). Die relevantesten Chunks gehören daher an die Ränder, nicht in die Mitte.

> **Merksatz:** Mehr Kontext ist nicht besser — **relevanter, vielfältiger und gut platzierter** Kontext ist besser.

### Grounding & Abstention: die Generierung ehrlich halten

Selbst mit perfektem Kontext kann das Modell **plausibel klingende, unbelegte** Details ergänzen. Das ist in RAG selten ein Wissens-, meist ein **Grounding**-Problem: es fehlt der Zwang, jede Aussage an eine konkrete retrievte Quelle zu binden.

Die zweite Ehrlichkeits-Frage: Was passiert, wenn die Antwort **nicht** im Kontext steht? Ein System, das immer antwortet, halluziniert bei Recall-Lücken. **Abstention** — kontrolliertes „das steht nicht in meinen Quellen“ — ist ein Feature, kein Versagen.

> **Beleg-Pflicht:** Aussagen an Quellen binden und Antworten ohne Beleg kennzeichnen oder verwerfen. Das macht unbelegte Aussagen **sichtbar**, statt sie hinter flüssiger Sprache zu verstecken.

### Die Decke erkennen — und alles messen

Irgendwann greift Ranking-Tuning nicht mehr: Wenn der relevante Chunk gar nicht im Bestand oder nicht unter den Kandidaten ist, kann kein Reranker ihn nach oben sortieren. Dann ist es ein **Recall-/Abdeckungs-Problem** (Chunking, Query-Expansion, fehlende Dokumente) — nicht noch eine Runde Präzisions-Tuning.

Und all das entscheidet man nicht per Bauchgefühl. Jeder Hebel hier — Rewriting, Fusion, Reranking, Ordering, Grounding — wird **vorher/nachher gemessen** (Faithfulness, Context Precision/Recall). Ohne Eval-Set weißt du nicht, ob ein Eingriff die eine Fragenklasse verbessert und eine andere kaputt macht.

> **Gleich im Check:** Du entscheidest jetzt selbst für konkrete Ops-Szenarien: welcher Hebel bei welchem Symptom — und wann du aufhörst zu tunen, weil das Problem woanders liegt.

## Quellen

- Retrieval-Augmented Generation for Large Language Models: A Survey — Gao et al., 2023
- Passage Re-ranking with BERT (Cross-Encoder) — Nogueira & Cho, 2019
- Reciprocal Rank Fusion — Cormack, Clarke, Buettcher, 2009
- Precise Zero-Shot Dense Retrieval without Relevance Labels (HyDE) — Gao et al., 2022
- The Use of MMR, Diversity-Based Reranking for Reordering Documents — Carbonell & Goldstein, 1998
- Lost in the Middle: How Language Models Use Long Contexts — Liu et al., 2023
- RAGAS: Automated Evaluation of Retrieval Augmented Generation — Es et al., 2023
- Passage Re-ranking with BERT — Nogueira & Cho, 2019
- Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods — Cormack, Clarke, Buettcher, 2009
- Okapi BM25 (Robertson/Zaragoza) — The Probabilistic Relevance Framework: BM25 and Beyond
- Survey of Hallucination in Natural Language Generation — Ji et al., 2023