RAG von Grund auf – Teil 5: Reranking und Retrieval-Strategien
In Teil 4 haben wir gesehen, wie Dense Retrieval und Sparse Retrieval kombiniert werden können.
Eine typische Pipeline sah am Ende ungefähr so aus:
Query
│
├── Dense Search
│
└── Sparse Search
↓
Fusion
↓
Kandidatenmenge
Damit haben wir allerdings noch nicht zwangsläufig die besten Chunks gefunden.
Wir haben zunächst nur eine gute Vorauswahl erzeugt.
Genau hier beginnt Reranking.
Die zentrale Frage lautet jetzt:
Welche der gefundenen Passagen beantwortet die konkrete Benutzerfrage tatsächlich am besten?
Das klingt ähnlich wie Retrieval.
Es ist aber eine andere Aufgabe.
Ein First-Stage Retriever versucht sehr schnell, aus vielleicht Millionen Chunks einige plausible Kandidaten zu finden.
Ein Reranker erhält dagegen nur noch eine kleine Menge und kann deshalb wesentlich genauer prüfen.
Damit entsteht eines der wichtigsten Muster moderner Retrieval-Systeme:
hoher Recall zuerst
↓
hohe Precision danach
Oder ausführlicher:
gesamter Index
↓
Candidate Retrieval
↓
50–100 Kandidaten
↓
Reranking
↓
5–10 hochwertige Treffer
↓
Context Selection
↓
LLM
Dieser Teil behandelt genau diese zweite Hälfte des Retrieval-Problems.
1. Retrieval ist nicht gleich Reranking
Ein Retriever durchsucht einen grossen Index.
Ein Reranker bewertet eine bereits reduzierte Kandidatenmenge erneut.
Vereinfacht:
Retriever:
100'000 Chunks
→ 50 Kandidaten
Reranker:
50 Kandidaten
→ sortierte Top 10
Beide bewerten Relevanz.
Aber sie arbeiten unter unterschiedlichen Bedingungen.
Der Retriever muss:
- sehr schnell,
- skalierbar,
- recall-stark
sein.
Der Reranker kann:
- langsamer,
- rechenintensiver,
- präziser
sein.
2. Warum die erste Rangliste oft nicht genügt
Nehmen wir folgende Frage:
Wie lange ist die Kündigungsfrist während der Probezeit?
Dense Retrieval findet:
1. Die Probezeit dauert drei Monate.
2. Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
3. Nach der Probezeit gelten ordentliche Kündigungsfristen.
4. Während der Probezeit gelten besondere Regelungen.
Diese Treffer sind alle semantisch nah.
Aber nur Treffer 2 beantwortet die Frage direkt.
Ein Reranker soll deshalb lernen:
thematisch ähnlich
≠
konkret relevant
3. Candidate Retrieval
Die erste Stufe wird häufig als Candidate Retrieval oder Candidate Generation bezeichnet.
Typische Retriever sind:
- Dense Retriever,
- BM25,
- Learned Sparse Retriever,
- Hybrid Search,
- Multi-Retriever-Systeme.
Ziel:
Die relevante Passage soll möglichst sicher in der Kandidatenmenge enthalten sein.
Perfekte Sortierung ist hier noch nicht zwingend notwendig.
4. Recall-orientierte erste Stufe
Angenommen, relevant ist Chunk R.
Ein guter First-Stage Retriever liefert:
Top 50:
...
Rank 17 → Chunk R
...
Das ist zunächst akzeptabel.
Denn der Reranker kann Chunk R später nach oben ziehen.
Wenn Chunk R aber überhaupt nicht auftaucht:
Top 50:
kein Chunk R
ist er verloren.
Deshalb lautet die wichtigste Forderung an die erste Stufe:
Nicht zu früh relevante Kandidaten verlieren.
5. Reranking
Beim Reranking werden Kandidaten erneut bewertet und neu sortiert.
Beispiel:
Vorher:
1. Chunk A
2. Chunk B
3. Chunk C
4. Chunk D
5. Chunk E
Nach Reranking:
1. Chunk C
2. Chunk A
3. Chunk E
4. Chunk B
5. Chunk D
Die Kandidaten bleiben grundsätzlich dieselben.
Nur ihre Reihenfolge verändert sich.
6. Bi-Encoder noch einmal
In Teil 3 haben wir den Bi-Encoder kennengelernt.
Query und Passage werden getrennt verarbeitet:
Query
↓
Encoder
↓
Query Vector
Passage
↓
Encoder
↓
Passage Vector
Danach:
Similarity(Query Vector, Passage Vector)
Das ist sehr effizient.
Aber Query und Passage interagieren während der Modellverarbeitung nicht direkt miteinander.
7. Cross-Encoder
Ein Cross-Encoder arbeitet anders.
Er erhält Query und Passage gemeinsam:
Query + Passage
↓
Transformer
↓
Relevance Score
Beispielsweise:
[QUERY]
Wie lange ist die Kündigungsfrist während der Probezeit?
[PASSAGE]
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Das Modell verarbeitet beide Texte gemeinsam.
Dadurch kann es feinere Beziehungen erkennen.
8. Warum Cross-Encoder genauer sein können
Der Cross-Encoder sieht Token-Interaktionen zwischen Query und Passage.
Er kann beispielsweise erkennen, dass:
Frage:
Wie lange ist die Kündigungsfrist?
und:
Passage:
Die Probezeit dauert drei Monate.
zwar thematisch zusammengehören, die Frage aber nicht beantworten.
Ein Bi-Encoder kann beide Texte wegen gemeinsamer Semantik relativ nah platzieren.
Ein Cross-Encoder kann die konkrete Relevanz wesentlich direkter bewerten.
9. Cross-Encoder als Relevance Model
Man kann einen Reranker konzeptionell als Funktion betrachten:
relevance(query, passage)
→ score
Beispiel:
Passage A → 0.98
Passage B → 0.71
Passage C → 0.24
Danach werden die Passagen nach diesem Score sortiert.
10. Warum nicht alles mit Cross-Encoder durchsuchen?
Angenommen, der Index enthält:
5'000'000 Chunks
Für jede Query müsste der Cross-Encoder:
5'000'000 Query-Passage-Paare
bewerten.
Das wäre extrem teuer.
Deshalb nutzt man:
schneller Retriever
↓
kleine Kandidatenmenge
↓
teurer Reranker
11. Retrieve-then-Rerank
Dieses Muster wird häufig als:
Retrieve-then-Rerank
bezeichnet.
Query
↓
Retriever
↓
Top 50
↓
Reranker
↓
Top 5
Es gehört zu den wichtigsten Retrieval-Architekturen überhaupt.
12. First-Stage Score und Reranker Score
Die Scores der ersten Stufe und des Rerankers sollten konzeptionell getrennt betrachtet werden.
Beispiel:
Dense Similarity = 0.83
und:
Reranker Score = 0.94
Diese Zahlen liegen zwar zufällig in einem ähnlichen Bereich.
Sie messen aber unterschiedliche Dinge.
Man sollte sie nicht blind miteinander vergleichen.
13. Reranking nach Hybrid Search
Ein typischer Ablauf ist:
Dense Top 50
+
Sparse Top 50
↓
RRF
↓
60 eindeutige Kandidaten
↓
Cross-Encoder
↓
Top 10
Hier übernimmt Hybrid Retrieval den Recall.
Der Cross-Encoder optimiert die Präzision.
14. Reranking Candidate Size
Wie viele Kandidaten sollte man reranken?
Beispielsweise:
10
20
50
100
200
Ein grösserer Kandidatenpool kann Recall verbessern.
Aber:
- mehr Latenz,
- mehr Modellaufrufe,
- mehr Rechenaufwand.
Die optimale Grösse hängt vom Korpus und vom Reranker ab.
15. Reranking Depth
Die Anzahl der Kandidaten, die ein Reranker bewertet, wird häufig als Reranking Depth verstanden.
Beispiel:
First Stage Top 100
Rerank Depth = 50
Dann werden nur die besten 50 Kandidaten der ersten Stufe genauer bewertet.
16. Reranker Top-k
Nach dem Reranking bleibt erneut eine Auswahl.
Beispiel:
50 Kandidaten
↓
Reranking
↓
Top 8
Aber auch diese Top 8 müssen nicht zwingend alle in den Prompt.
Danach kann noch Context Selection erfolgen.
17. Relevance versus Redundancy
Angenommen, die Top-Ergebnisse sind:
1. Kündigungsfrist beträgt sieben Tage.
2. Kündigungsfrist beträgt 7 Tage.
3. In der Probezeit gilt eine Kündigungsfrist von sieben Tagen.
4. Die Probezeit dauert drei Monate.
Die ersten drei Treffer sind hochrelevant.
Sie sind aber fast identisch.
Wenn alle in den Prompt gelangen, wird Kontextbudget verschwendet.
Damit entsteht ein weiteres Problem:
Relevanz allein genügt nicht. Wir benötigen auch Diversität.
18. Maximal Marginal Relevance
Ein bekanntes Verfahren dafür ist Maximal Marginal Relevance, kurz MMR.
MMR versucht einen Kompromiss zwischen:
- Relevanz zur Query,
- Neuartigkeit gegenüber bereits ausgewählten Treffern.
Vereinfacht:
MMR =
Relevanz zur Query
-
Ähnlichkeit zu bereits gewählten Chunks
19. MMR intuitiv
Wir besitzen diese Treffer:
A: Kündigungsfrist = sieben Tage
B: Kündigungsfrist = sieben Tage
C: Probezeit = drei Monate
D: Nach Probezeit gelten andere Fristen
Ein reines Relevance Ranking könnte wählen:
A
B
C
MMR könnte stattdessen wählen:
A
C
D
Damit erhält das Modell mehr unterschiedliche Information.
20. MMR-Parameter Lambda
Typischerweise existiert ein Parameter λ.
Vereinfacht:
hohes λ
→ mehr Fokus auf Relevanz
niedriges λ
→ mehr Fokus auf Diversität
Auch hier gibt es keinen universell optimalen Wert.
21. Wann MMR hilft
MMR ist besonders nützlich bei:
- redundanten Dokumenten,
- Near-Duplicates,
- ähnlichen Chunks,
- mehreren Quellen mit gleichem Inhalt.
Es hilft weniger, wenn eine Frage nur einen einzigen sehr spezifischen Fakt benötigt.
22. Deduplication versus MMR
Deduplication entfernt echte oder fast identische Duplikate.
MMR geht weiter.
Es versucht auch, thematisch sehr ähnliche, aber nicht identische Treffer zugunsten von Diversität zu reduzieren.
Beide Konzepte können kombiniert werden.
23. Query Processing
Bisher haben wir die Benutzerfrage direkt an den Retriever weitergegeben.
Aber eine Benutzerfrage ist nicht immer eine gute Suchanfrage.
Beispiel:
Und wie lange gilt das dann?
Für einen Menschen ist im Chatkontext möglicherweise klar, worauf sich „das“ bezieht.
Für einen Retriever isoliert betrachtet nicht.
Deshalb gibt es Query Processing.
24. Query Rewrite
Beim Query Rewrite wird die Benutzerfrage in eine retrieval-freundlichere Form umgeschrieben.
Original:
Und wie lange gilt das dann?
Chatkontext:
Wir sprechen über die Probezeit.
Rewrite:
Wie lange dauert die Probezeit?
Der Retriever erhält jetzt eine eigenständige Suchanfrage.
25. Standalone Query
Eine solche umgeschriebene Frage wird häufig als Standalone Query bezeichnet.
Sie enthält genügend Kontext, um unabhängig vom Chatverlauf verstanden zu werden.
Beispiel:
Original:
Und wann endet sie?
Standalone:
Wann endet die dreimonatige Probezeit?
26. Warum Query Rewrite wichtig ist
Retriever sehen häufig nur den aktuellen Query-Text.
Pronomen wie:
er
sie
das
dort
dann
können ohne Kontext unverständlich sein.
Query Rewrite rekonstruiert die eigentliche Informationsfrage.
27. Query Rewrite darf die Bedeutung nicht verändern
Ein gefährlicher Fehler wäre:
Original:
Gilt das auch für Teilzeitmitarbeiter?
Rewrite:
Welche Regeln gelten generell für Teilzeitmitarbeiter?
Die Anfrage wurde erweitert.
Das kann Retrieval in eine falsche Richtung lenken.
Ein gutes Rewrite sollte die ursprüngliche Informationsabsicht erhalten.
28. Query Normalization
Neben vollständigem Rewrite gibt es einfachere Normalisierung.
Beispielsweise:
"kündigungsfrist???? probezeit"
wird zu:
Kündigungsfrist Probezeit
Das kann:
- Schreibfehler,
- überflüssige Zeichen,
- Formatierung
bereinigen.
29. Query Expansion
In Teil 4 haben wir Query Expansion kurz kennengelernt.
Dabei wird die Query um zusätzliche Suchbegriffe erweitert.
Beispiel:
Kündigung Probezeit
wird:
Kündigung
Kündigungsfrist
Arbeitsverhältnis beenden
Probezeit
Ziel ist höherer Recall.
30. Query Expansion versus Query Rewrite
Diese Begriffe sollte man unterscheiden.
Rewrite
Frage besser formulieren
Expansion
zusätzliche Suchkonzepte hinzufügen
Beides kann kombiniert werden.
31. Multi-Query Retrieval
Beim Multi-Query Retrieval wird nicht nur eine Suchanfrage erzeugt.
Stattdessen werden mehrere semantisch unterschiedliche Varianten erstellt.
Beispiel:
Original:
Wie kann ich während der Probezeit kündigen?
Varianten:
Welche Kündigungsfrist gilt in der Probezeit?
Wie kann ein Arbeitsverhältnis während der Probezeit beendet werden?
Welche Fristen gelten für eine Kündigung in den ersten Monaten?
Jede Query wird separat gesucht.
32. Warum Multi-Query hilft
Ein einzelnes Embedding bildet nur eine bestimmte Formulierung ab.
Mehrere Query-Varianten können unterschiedliche Bereiche des Vektorraums erreichen.
Schematisch:
Original Query
├── Query A → Treffer
├── Query B → Treffer
└── Query C → Treffer
↓
Union
Damit kann Recall steigen.
33. Multi-Query Candidate Union
Beispiel:
Query A findet:
A
B
C
Query B:
B
D
E
Query C:
A
F
G
Union:
A
B
C
D
E
F
G
Danach folgt typischerweise Deduplication und Reranking.
34. Nachteile von Multi-Query
Mehr Queries bedeuten:
- mehr Embeddings,
- mehr Suchvorgänge,
- mehr Kandidaten,
- mehr Reranking,
- höhere Latenz.
Ausserdem kann eine generierte Variante die ursprüngliche Frage falsch interpretieren.
35. Query Decomposition
Manche Fragen enthalten mehrere Teilfragen.
Beispiel:
Wie lange dauert die Probezeit und welche Kündigungsfrist gilt dabei?
Man kann daraus erzeugen:
Query 1:
Wie lange dauert die Probezeit?
Query 2:
Welche Kündigungsfrist gilt während der Probezeit?
Das nennt man Query Decomposition.
36. Warum Query Decomposition hilft
Eine lange komplexe Query kann mehrere Informationsbedürfnisse vermischen.
Durch Zerlegung kann jeder Teil gezielter gesucht werden.
Danach werden die Ergebnisse kombiniert.
Das wird besonders wichtig bei Multi-Hop Retrieval, das wir in Teil 7 vertiefen.
37. Multi-Hop Question
Eine Multi-Hop-Frage benötigt Informationen aus mehreren Quellen oder Schritten.
Beispiel:
Welche Kündigungsfrist gilt für Mitarbeiter,
deren Probezeit auf drei Monate verlängert wurde?
Vielleicht steht:
Dokument A:
Die Probezeit kann auf drei Monate verlängert werden.
und:
Dokument B:
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Eine einzelne Passage beantwortet die Frage nicht vollständig.
38. Query Decomposition als Vorbereitung für Multi-Hop
Das System könnte zerlegen:
1. Welche Regeln gelten für eine verlängerte Probezeit?
2. Welche Kündigungsfrist gilt während der Probezeit?
Erst danach werden die Informationen zusammengeführt.
39. HyDE
Ein weiteres interessantes Verfahren ist HyDE:
Hypothetical Document Embeddings
Die Idee klingt zunächst ungewöhnlich.
Statt die Benutzerfrage direkt einzubetten, erzeugt ein LLM zunächst eine hypothetische Antwort beziehungsweise ein hypothetisches Dokument.
Dieses wird dann eingebettet.
40. HyDE-Beispiel
Frage:
Wie lange ist die Kündigungsfrist während der Probezeit?
Das Modell erzeugt hypothetisch:
Während der Probezeit gilt eine kurze Kündigungsfrist.
Die genaue Dauer ist im Personalreglement festgelegt.
Dieser Text wird eingebettet.
Hypothetischer Text
↓
Embedding
↓
Vector Search
41. Warum HyDE funktionieren kann
Eine Frage und eine relevante Passage besitzen unterschiedliche sprachliche Formen.
Frage:
Wie lange ist die Kündigungsfrist?
Dokument:
Während der Probezeit beträgt die Frist sieben Tage.
HyDE erzeugt zunächst Text, der eher wie ein Dokument aussieht.
Dadurch kann die Embedding-Repräsentation näher an realen Dokumentpassagen liegen.
42. HyDE benötigt keine faktisch richtige Hypothese
Das klingt paradox.
Die hypothetische Antwort muss nicht zwingend korrekt sein.
Sie soll primär eine semantische Repräsentation erzeugen, die besser zum Dokumentraum passt.
Trotzdem besteht natürlich das Risiko, dass eine falsche Hypothese das Retrieval in eine falsche Richtung lenkt.
43. HyDE ist Retrieval, nicht Antwortgenerierung
Wichtig:
Der hypothetische Text wird nicht als finale Antwort ausgegeben.
Er dient nur als Suchhilfe.
Pipeline:
Question
↓
LLM
↓
Hypothetical Document
↓
Embedding
↓
Retrieval
↓
echte Quellen
↓
Antwort
44. Query2Doc
HyDE gehört zu einer grösseren Familie von Verfahren, bei denen Queries in dokumentähnliche Repräsentationen transformiert werden.
Die Grundidee:
Query-Sprache
≠
Dokument-Sprache
Durch Transformation versucht man diese Lücke zu verkleinern.
45. Query Expansion mit LLMs
Ein LLM kann auch explizit zusätzliche Suchbegriffe erzeugen.
Beispiel:
User:
Wie kündige ich in der Probezeit?
Expansion:
Probezeit
Kündigung
Kündigungsfrist
Arbeitsvertrag
Beendigung Arbeitsverhältnis
Diese Begriffe können besonders Sparse Retrieval verbessern.
46. LLM-basierte Query Transformation ist nicht kostenlos
Jeder zusätzliche Modellaufruf erzeugt:
- Latenz,
- Kosten,
- potenzielle Fehler.
Deshalb sollte Query Transformation gezielt eingesetzt werden.
Ein einfacher Exact-ID-Query braucht beispielsweise kein komplexes LLM-Rewrite.
47. Query Classification
Ein System kann zunächst Queries klassifizieren.
Beispiel:
Identifier Query
Semantic Query
Multi-Hop Query
Follow-up Query
Structured Query
Danach wird eine geeignete Retrieval-Strategie gewählt.
Das ist Query Classification beziehungsweise Teil von Query Routing.
48. Adaptive Retrieval
Wenn das System je nach Query unterschiedliche Strategien verwendet, spricht man oft von Adaptive Retrieval.
Beispiel:
exakte ID
→ Sparse Search
semantische Frage
→ Hybrid Search
komplexe Frage
→ Multi-Query + Reranking
Das kann effizienter sein als für jede Frage die maximal komplexe Pipeline auszuführen.
49. Query Router
Ein Query Router entscheidet, welcher Retriever oder Workflow verwendet wird.
Schematisch:
Query
↓
Router
├── Dense
├── Sparse
├── Hybrid
├── SQL
└── Graph
Damit nähert man sich bereits modularen RAG-Systemen.
50. Retrieval Strategy
Eine Retrieval Strategy umfasst mehr als nur den Suchalgorithmus.
Sie kann beinhalten:
- Query Rewrite,
- Query Expansion,
- Dense Search,
- Sparse Search,
- Filter,
- Multi-Query,
- Fusion,
- Reranking,
- Deduplication,
- Context Expansion.
Das gesamte Zusammenspiel bestimmt die Retrieval-Qualität.
51. Context Selection
Nach dem Reranking besitzen wir beispielsweise:
Top 10 Chunks
Aber der Prompt bietet vielleicht nur Platz für:
Top 4
Jetzt muss entschieden werden, welche Chunks tatsächlich übernommen werden.
Das ist Context Selection.
52. Context Selection ist nicht dasselbe wie Reranking
Reranking beantwortet:
Welcher Kandidat ist relevanter?
Context Selection beantwortet:
Welche Kombination von Kandidaten soll das LLM erhalten?
Das ist ein subtiler, aber wichtiger Unterschied.
53. Beispiel Context Selection
Reranker:
1. Kündigungsfrist: sieben Tage
2. Kündigungsfrist: sieben Tage
3. Probezeit: drei Monate
4. Nach Probezeit andere Kündigungsfristen
5. Kündigungsfrist: 7 Kalendertage
Wenn nur drei Chunks Platz haben, wäre:
1
3
4
möglicherweise informativer als:
1
2
5
obwohl 2 und 5 höhere Relevance Scores besitzen.
54. Relevance-Diversity Trade-off
Context Selection optimiert deshalb häufig:
Relevanz
+
Diversität
+
Informationsabdeckung
+
Tokenkosten
Das ist komplexer als simples Top-k.
55. Context Budget
Das Context Budget beschreibt, wie viele Tokens für retrievten Kontext verfügbar sind.
Beispiel:
Modellkontext: 32'000 Tokens
System Prompt: 2'000
Chatverlauf: 8'000
User Query: 500
Antwortreserve: 4'000
verfügbar für Retrieval:
17'500 Tokens
Damit kann nicht unbegrenzt Kontext übernommen werden.
56. Token-aware Selection
Eine Auswahlstrategie kann deshalb tokenbewusst arbeiten.
Beispiel:
Chunk A: 300 Tokens
Chunk B: 2'500 Tokens
Chunk C: 450 Tokens
Chunk B muss einen entsprechend hohen Informationswert liefern, um seinen grossen Platzverbrauch zu rechtfertigen.
57. Context Packing
Context Packing bezeichnet das Zusammenstellen ausgewählter Chunks in einen Prompt.
Dabei stellen sich Fragen wie:
- Reihenfolge,
- Quellenmarkierung,
- Trennzeichen,
- maximale Länge,
- Nachbar-Chunks,
- Parent-Kontext.
Das behandeln wir in Teil 6 noch ausführlicher.
58. Chunk Expansion
Ein hochrangiger Retrieval-Chunk kann vor der Prompt-Erstellung erweitert werden.
Beispiel:
gefunden:
Chunk 42
danach:
laden:
Chunk 41
Chunk 42
Chunk 43
Das ist die bereits bekannte Neighbor Expansion.
59. Parent Expansion
Alternativ:
Child Chunk gefunden
↓
Parent Section laden
Das ist Parent-Child Retrieval beziehungsweise Small-to-Big.
Teil 2 hat die Ingestion-Seite davon beschrieben.
Hier sehen wir jetzt die Query-Seite.
60. Retrieval Unit versus Context Unit
Diese Unterscheidung wird hier besonders wichtig.
Retrieval Unit:
kleiner Chunk
Context Unit:
grösserer Abschnitt
Die beste Einheit für Suche muss nicht die beste Einheit für Antwortgenerierung sein.
61. Passage Aggregation
Mehrere relevante Chunks können aus demselben Dokument stammen.
Man kann sie gruppieren.
Beispiel:
Document A
├── Chunk 7
├── Chunk 8
└── Chunk 12
Statt drei einzelne Quellen zu behandeln, kann ein System einen zusammenhängenden Abschnitt rekonstruieren.
Das nennt man allgemein Passage Aggregation beziehungsweise Kontextzusammenführung.
62. Overlapping Chunks zusammenführen
Durch Chunk Overlap können Treffer enthalten:
Chunk A:
... Kündigungsfrist beträgt sieben Tage ...
Chunk B:
... beträgt sieben Tage. Nach der Probezeit ...
Beide enthalten denselben Satz.
Vor der Prompt-Erstellung sollte dieser Overlap idealerweise nicht doppelt erscheinen.
63. Context Deduplication
Context Deduplication entfernt redundante Informationen aus dem finalen Kontext.
Das spart:
- Tokens,
- Aufmerksamkeit,
- Promptplatz.
Es erhöht ausserdem die Informationsdichte.
64. Document Diversity
Manchmal möchte man bewusst Treffer aus unterschiedlichen Dokumenten.
Beispielsweise:
Richtlinie
Vertrag
FAQ
statt fünf Chunks aus derselben Datei.
Das kann helfen, mehrere Perspektiven oder ergänzende Evidenz zu erhalten.
65. Source Diversity ist nicht immer besser
Bei einer sehr spezifischen Frage kann eine einzige autoritative Quelle besser sein als mehrere ähnliche oder weniger zuverlässige Quellen.
Diversität ist deshalb kein Selbstzweck.
Sie muss zur Frage passen.
66. Source Authority
Retrieval kann auch Quellenqualität berücksichtigen.
Beispielsweise:
offizielle Richtlinie
sollte möglicherweise höher gewichtet werden als:
informelle Notiz
Das ist ein zusätzliches Ranking-Signal.
67. Relevance versus Authority
Eine informelle FAQ kann die Query exakt beantworten.
Eine offizielle Richtlinie kann allgemeiner formuliert sein.
Dann entsteht ein Trade-off:
Relevanz
vs.
Autorität
Ein robustes RAG-System muss solche Signale bewusst modellieren.
68. Freshness
Auch Aktualität kann Teil der Auswahl sein.
Beispiel:
Richtlinie 2026
gegen:
Richtlinie 2024
Wenn beide semantisch ähnlich sind, sollte die aktuelle Quelle möglicherweise bevorzugt werden.
69. Version Conflicts
Ein schwieriger Fall:
Quelle A:
Kündigungsfrist = 7 Tage
Quelle B:
Kündigungsfrist = 14 Tage
Ein Reranker kann beide als hochrelevant bewerten.
Das Retrieval-Problem ist damit nicht gelöst.
Jetzt geht es um:
- Versionierung,
- Autorität,
- Aktualität,
- Konflikterkennung.
Das wird später beim Grounding besonders wichtig.
70. Query-Document Interaction
Cross-Encoder verbessern Ranking, weil sie Query und Passage gemeinsam betrachten.
Ein moderner Reranker kann dadurch feine Muster erkennen:
Query verlangt Zahl
→ Passage enthält konkrete Zahl
oder:
Query fragt nach Ausnahme
→ Passage beschreibt nur allgemeine Regel
Diese Interaktion ist bei reiner Vektorähnlichkeit schwächer.
71. Pairwise Ranking
Manche Rankingmodelle lernen nicht direkt einen absoluten Score.
Sie lernen:
Ist A relevanter als B?
Das nennt man Pairwise Ranking.
Beispiel:
Query + Passage A + Passage B
→ A > B
72. Pointwise Ranking
Beim Pointwise Ranking wird jeder Kandidat einzeln bewertet.
Query + Passage
→ Score
Danach werden die Scores sortiert.
Viele Reranking-Modelle können so verwendet werden.
73. Listwise Ranking
Beim Listwise Ranking betrachtet das Verfahren eine ganze Kandidatenliste und optimiert deren Reihenfolge direkt.
Das kann theoretisch besser zur eigentlichen Ranking-Aufgabe passen.
Es ist aber oft komplexer.
74. LLM als Reranker
Auch ein generatives LLM kann zum Reranking verwendet werden.
Beispielsweise:
Frage
+
10 Passagen
+
Anweisung:
Ordne die Passagen nach Relevanz.
Das Modell gibt:
3 > 1 > 7 > 2 > ...
zurück.
75. Vorteile eines LLM-Rerankers
Ein grosses LLM kann:
- komplexe Semantik verstehen,
- Bedingungen erkennen,
- mehrere Kriterien berücksichtigen,
- natürliche Sprache flexibel interpretieren.
Es kann besonders bei komplizierten Queries stark sein.
76. Nachteile eines LLM-Rerankers
LLM-Reranking ist typischerweise:
- langsamer,
- teurer,
- weniger deterministisch,
- schwieriger zu skalieren.
Für viele Systeme ist ein spezialisierter Cross-Encoder daher attraktiver.
77. RankGPT-artige Ansätze
Es existieren Verfahren, bei denen generative LLMs Ranglisten erzeugen oder Kandidaten iterativ vergleichen.
Die Grundidee ist nicht auf ein bestimmtes Modell beschränkt:
LLM
→ Rankingentscheidung
Solche Verfahren gehören zur Familie LLM-basierter Reranking-Ansätze.
78. Sliding-Window Reranking
Wenn zu viele Kandidaten für einen einzigen LLM-Prompt vorhanden sind, kann man sie in Fenstern bewerten.
Beispiel:
Kandidaten 1–20
Kandidaten 11–30
Kandidaten 21–40
Ergebnisse werden anschliessend zusammengeführt.
Das erhöht jedoch Komplexität und Kosten.
79. Reranker Calibration
Auch Reranker-Scores sind nicht automatisch Wahrscheinlichkeiten.
Ein Score wie:
0.91
bedeutet nicht zwingend:
91 % relevant
Die Interpretation hängt vom Modell und dessen Output ab.
80. Relevance Threshold
Man kann nach dem Reranking einen Mindestscore verlangen.
Beispiel:
Reranker Score ≥ 0.6
Treffer darunter werden verworfen.
Das kann helfen, bei schlechten Queries keinen irrelevanten Kontext an das LLM zu geben.
Der Threshold muss aber evaluiert werden.
81. No-Relevant-Context Decision
Nach dem Reranking kann ein System feststellen:
Kein Kandidat ist ausreichend relevant.
Das ist eine wichtige Entscheidung.
Denn dann sollte das System möglicherweise gar keine wissensgebundene Antwort erzeugen.
82. Retrieval Confidence
Manche Systeme berechnen eine Art Retrieval Confidence.
Das kann basieren auf:
- Top Score,
- Score-Abstand,
- Anzahl guter Treffer,
- Retriever-Übereinstimmung,
- Reranker-Score.
Aber auch hier gilt:
Confidence ist nicht automatisch eine echte Wahrscheinlichkeit.
83. Score Gap
Ein mögliches Signal ist der Abstand zwischen Rang 1 und Rang 2.
Beispiel:
Top 1 = 0.97
Top 2 = 0.52
Das sieht anders aus als:
Top 1 = 0.81
Top 2 = 0.80
Der zweite Fall kann auf Ambiguität hinweisen.
84. Retriever Agreement
Bei Hybrid Search kann auch die Übereinstimmung mehrerer Retriever ein Signal sein.
Beispiel:
Dense Rank 1
Sparse Rank 1
Reranker Rank 1
Das ist ein starkes konsistentes Signal.
Aber auch das garantiert keine faktische Richtigkeit.
85. Query Ambiguity
Manche Fragen sind mehrdeutig.
Beispiel:
Wie lange gilt die Frist?
Ohne Kontext könnte gemeint sein:
- Kündigungsfrist,
- Zahlungsfrist,
- Einsprachefrist,
- Garantiefrist.
Ein Retrieval-System sollte diese Ambiguität nicht einfach erraten.
86. Clarification versus Retrieval Expansion
Bei mehrdeutigen Queries existieren zwei Möglichkeiten.
Clarification
Welche Frist meinen Sie?
oder:
breiteres Retrieval
mehrere Interpretationen suchen
Welche Strategie besser ist, hängt von der Anwendung ab.
87. Query Intent Preservation
Jede Query-Transformation muss die ursprüngliche Benutzerabsicht erhalten.
Das ist besonders wichtig bei LLM-basierten Rewrites.
Aus:
Kann ich während der Probezeit sofort kündigen?
darf nicht werden:
Wie lange dauert die Probezeit?
Beide hängen thematisch zusammen.
Die Informationsabsicht ist aber unterschiedlich.
88. Hallucinated Query Expansion
LLMs können beim Query Rewrite Begriffe hinzufügen, die der Benutzer nie gemeint hat.
Beispiel:
Original:
Wie lange gilt die Kündigungsfrist?
Expansion:
Kündigungsfrist bei fristloser Kündigung
„fristlos“ wurde erfunden.
Das kann Retrieval verzerren.
89. Conservative Rewrite
Eine robuste Strategie ist deshalb ein conservative rewrite.
Das Modell soll:
- Referenzen auflösen,
- Grammatik verbessern,
- Kontext ergänzen,
aber keine neuen fachlichen Annahmen einführen.
90. Multi-Query Diversity
Bei Multi-Query sollen Varianten nicht bloss minimale Wortänderungen sein.
Schlecht:
Wie lange ist die Kündigungsfrist?
Wie lang ist die Kündigungsfrist?
Welche Länge hat die Kündigungsfrist?
Besser:
Welche Kündigungsfrist gilt während der Probezeit?
Wie schnell kann das Arbeitsverhältnis in der Probezeit beendet werden?
Welche Fristen gelten bei einer Kündigung in den ersten Beschäftigungsmonaten?
Die Varianten decken unterschiedliche Ausdrucksweisen ab.
91. Multi-Query und Sparse Search
Multi-Query kann auch Sparse Retrieval verbessern.
Ein Dokument enthält vielleicht:
Beendigung des Arbeitsverhältnisses
während die Originalquery nur:
kündigen
enthält.
Eine alternative Query kann diese lexikalische Lücke schliessen.
92. Multi-Query und Dense Search
Auch Dense Retrieval kann profitieren.
Obwohl Embeddings semantische Varianten bereits abdecken, erzeugen unterschiedliche Formulierungen leicht unterschiedliche Query-Vektoren.
Dadurch können zusätzliche relevante Regionen des Vektorraums erreicht werden.
93. Fusion nach Multi-Query
Die Ergebnisse mehrerer Queries können wieder mit Verfahren wie RRF kombiniert werden.
Query A Ranking
Query B Ranking
Query C Ranking
↓
RRF
↓
kombiniertes Ranking
RRF ist also nicht nur für Dense + Sparse nützlich.
Es kann allgemein mehrere Ranglisten fusionieren.
94. Retrieval Explosion
Wenn man kombiniert:
3 Query Varianten
×
2 Retriever
×
Top 50
entstehen potenziell:
300 Rohkandidaten
vor Deduplication.
Das zeigt, wie schnell Retrieval-Komplexität wachsen kann.
95. Mehr ist nicht automatisch besser
Eine Pipeline kann theoretisch enthalten:
- Rewrite,
- Multi-Query,
- Dense,
- Sparse,
- Learned Sparse,
- Fusion,
- Reranker,
- MMR,
- Expansion,
- Compression.
Das bedeutet nicht automatisch bessere Qualität.
Jede Stufe:
- erhöht Komplexität,
- erhöht Latenz,
- kann neue Fehler erzeugen.
Die einfachste Pipeline, die das Qualitätsziel erreicht, ist häufig vorzuziehen.
96. Retrieval Ablation Testing
Deshalb sollte man Komponenten einzeln testen.
Beispiel:
Baseline:
Hybrid Search
gegen:
Hybrid + Reranker
gegen:
Rewrite + Hybrid + Reranker
gegen:
Multi-Query + Hybrid + Reranker
Dann misst man, welcher Schritt tatsächlich verbessert.
97. Reranker Gain
Ein sinnvoller Vergleich ist:
MRR vor Reranking
vs.
MRR nach Reranking
oder:
nDCG@10
Diese Metriken behandeln wir in Teil 8 ausführlich.
98. Retrieval Latency Budget
Ein RAG-System besitzt ein Latenzbudget.
Beispiel:
Query Rewrite 100 ms
Dense Retrieval 30 ms
Sparse Retrieval 20 ms
Fusion 5 ms
Reranking 80 ms
Generation 1500 ms
Die Zahlen sind nur illustrative Beispiele.
Wichtig ist die Denkweise:
Jede zusätzliche Retrieval-Stufe kostet Zeit.
99. Parallel Retrieval
Dense und Sparse Retrieval können häufig parallel ausgeführt werden.
Query
│
┌───────┴───────┐
▼ ▼
Dense Sparse
│ │
└───────┬───────┘
▼
Fusion
Damit muss ihre Latenz nicht zwingend addiert werden.
100. Sequential Retrieval
Query Rewrite muss dagegen typischerweise vorher erfolgen:
Original Query
↓
Rewrite
↓
Retrieval
Das erhöht die kritische Pfadlänge.
Pipeline-Design ist deshalb auch Performance-Design.
101. Query Rewrite Cache
Bei wiederkehrenden Queries könnten bestimmte Query-Transformationen gecacht werden.
Das ist aber nur sinnvoll, wenn:
- Kontext identisch,
- Rewrite deterministisch genug,
- Benutzerkontext nicht relevant
ist.
Bei Chat-Follow-ups ist Caching oft schwieriger.
102. Reranking Cache
Auch Query-Passage-Bewertungen können theoretisch gecacht werden.
Schlüssel:
Query Hash
+
Chunk ID
+
Reranker Version
In stark dynamischen Systemen kann der Nutzen begrenzt sein.
103. Contextual Compression
Nach Retrieval kann ein grosser Chunk auf die queryrelevante Information reduziert werden.
Original:
Die Probezeit dauert drei Monate.
Während dieser Zeit beträgt die Kündigungsfrist sieben Tage.
Ferien werden anteilig berechnet.
Homeoffice muss vereinbart werden.
Frage:
Wie lange ist die Kündigungsfrist?
Komprimiert:
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Das nennt man häufig Contextual Compression.
104. Extractive Compression
Bei Extractive Compression werden relevante Teile des Originaltexts ausgewählt.
Es wird möglichst nichts neu formuliert.
Beispiel:
Originalsatz auswählen
Das ist für quellengebundene Systeme besonders interessant, weil weniger neue Information erzeugt wird.
105. Abstractive Compression
Bei Abstractive Compression wird der Inhalt zusammengefasst oder neu formuliert.
Beispiel:
Original:
Während der Probezeit kann das Arbeitsverhältnis
mit einer Frist von sieben Kalendertagen beendet werden.
Komprimiert:
Kündigungsfrist in der Probezeit: 7 Tage.
Das spart Tokens.
Aber es erzeugt neue Modellgenerierung vor der eigentlichen Antwort.
106. Risiko abstraktiver Compression
Ein Modell könnte aus:
sieben Kalendertage
versehentlich machen:
sieben Arbeitstage
Dadurch wäre bereits der Kontext verfälscht.
Für stark quellengebundene Systeme ist Extractive Compression deshalb oft sicherer.
107. Contextual Compression ist Query-abhängig
Ein Chunk kann für zwei Fragen unterschiedlich komprimiert werden.
Frage A:
Wie lange dauert die Probezeit?
→
Die Probezeit dauert drei Monate.
Frage B:
Wie lange ist die Kündigungsfrist?
→
Die Kündigungsfrist beträgt sieben Tage.
Die zugrunde liegende Quelle ist dieselbe.
Die relevante Evidenz unterscheidet sich.
108. Sentence Selection
Eine einfache Form der Compression besteht darin, relevante Sätze innerhalb eines Chunks zu ranken.
Chunk
├── Satz 1
├── Satz 2 ← relevant
├── Satz 3
└── Satz 4
Nur Satz 2 und eventuell Nachbarsätze werden übernommen.
109. Passage Extraction
Ähnlich können kleinere Spans aus grossen Texten extrahiert werden.
Das reduziert den Kontext auf die eigentliche Evidenz.
Dabei darf aber notwendiger Kontext nicht verloren gehen.
110. Compression versus Small-to-Big
Interessanterweise gibt es zwei entgegengesetzte Bewegungen.
Small-to-Big
kleinen Chunk finden
→ Kontext vergrössern
Contextual Compression
grossen Chunk finden
→ Kontext verkleinern
Beide versuchen dasselbe Ziel:
Die richtige Informationsmenge für die Antwort finden.
111. Optimal Context Granularity
Die optimale Kontextgrösse liegt häufig irgendwo zwischen:
zu wenig Kontext
und:
zu viel Rauschen
Retrieval und Context Selection versuchen genau diesen Bereich zu treffen.
112. Retrieval Noise
Retrieval Noise bezeichnet irrelevante oder wenig hilfreiche Informationen, die zusammen mit relevanter Evidenz in den Kontext gelangen.
Beispiel:
1 relevanter Satz
+
2'000 irrelevante Tokens
Das kann die Generation verschlechtern.
113. Signal-to-Noise Ratio
Eine hilfreiche Perspektive ist das Signal-to-Noise Ratio.
Signal:
Information, die zur Antwort beiträgt
Noise:
Information, die nicht beiträgt
Ein guter Kontext besitzt möglichst viel Signal und wenig Noise.
114. Warum mehr Kontext nicht automatisch besser ist
Es ist verführerisch zu denken:
mehr Chunks
=
mehr Wissen
=
bessere Antwort
Aber zusätzliche Chunks können:
- widersprechen,
- ablenken,
- relevante Information verdrängen,
- Tokenbudget verbrauchen.
Deshalb wird Context Selection immer wichtiger, je grösser das Korpus wird.
115. Retrieval Position
Auch die Position eines relevanten Chunks im finalen Prompt kann eine Rolle spielen.
Ein Treffer kann korrekt retrieved sein, aber ungünstig platziert werden.
Dieses Thema hängt mit Lost in the Middle zusammen und wird in Teil 6 ausführlich behandelt.
116. Query-Focused Context
Das Ziel ist letztlich ein query-fokussierter Kontext.
Nicht:
alles über Probezeit
sondern:
genau die Informationen,
die zur konkreten Frage über Kündigungsfristen benötigt werden
Das ist der Übergang von Retrieval zu Augmentation.
117. Reranking Failure
Ein Reranker kann ebenfalls Fehler machen.
Beispiel:
Relevanter Chunk:
Die Kündigungsfrist beträgt sieben Tage.
Hard Negative:
Die Probezeit dauert drei Monate.
Wenn der Reranker den Hard Negative höher bewertet, verschlechtert er die Pipeline.
Reranking ist deshalb kein garantierter Qualitätsgewinn.
118. Reranker Domain Mismatch
Ein allgemeiner Reranker kann in Spezialdomänen schlechter funktionieren.
Beispiele:
- juristische Sprache,
- medizinische Dokumente,
- Source Code,
- wissenschaftliche Formeln.
Auch Reranker müssen gegen den eigenen Korpus evaluiert werden.
119. Multilingual Reranking
Bei mehrsprachigem Retrieval stellt sich zusätzlich die Frage:
deutsche Query
+
französische Passage
Kann der Reranker beide zuverlässig vergleichen?
Ein multilingualer Dense Retriever allein genügt nicht, wenn der Reranker nur eine Sprache gut beherrscht.
120. Reranker Input Length
Cross-Encoder besitzen ebenfalls Kontextlimits.
Ein extrem langer Chunk kann abgeschnitten werden.
Wenn die relevante Information am Ende liegt, kann sie dem Reranker fehlen.
Chunk-Grösse aus Teil 2 beeinflusst also auch hier die Qualität.
121. Truncation
Truncation bedeutet, dass Input abgeschnitten wird, weil er länger als das Modelllimit ist.
Beispiel:
Query + Passage = 900 Tokens
Reranker Limit = 512 Tokens
Dann gehen Teile verloren.
Das kann Ranking-Ergebnisse verfälschen.
122. Head-only Truncation
Wenn nur die ersten Tokens behalten werden:
[Anfang..............................]
kann relevante Information am Ende verschwinden.
Deshalb können lange Passagen spezielle Strategien benötigen.
123. Chunking wirkt durch die ganze Pipeline
Wir sehen jetzt erneut:
Chunking
→ Retrieval
→ Reranking
→ Context Selection
→ Generation
Eine schlechte Chunking-Entscheidung kann jede spätere Stufe beeinflussen.
RAG-Komponenten sind eng gekoppelt.
124. Reranker versus Answerability Model
Ein Reranker bewertet:
Wie relevant ist diese Passage?
Ein Answerability Model bewertet eher:
Enthält diese Passage genügend Information, um die Frage zu beantworten?
Das ist ähnlich, aber nicht identisch.
125. Relevante Passage ohne Antwort
Frage:
Wie hoch ist der Ferienanspruch?
Passage:
Ferien müssen frühzeitig geplant und genehmigt werden.
Das ist relevant zum Thema Ferien.
Aber nicht answerable.
Ein reiner Relevance-Reranker kann den Chunk trotzdem hoch bewerten.
126. Answerability als zusätzliche Stufe
Eine Pipeline könnte deshalb so aussehen:
Retrieval
↓
Reranking
↓
Answerability Check
↓
Context Selection
Nicht jedes System benötigt eine separate Stufe.
Das Konzept ist aber wichtig.
127. Entailment
Ein weiterer verwandter Begriff ist Entailment.
Eine Passage entails eine Aussage, wenn die Aussage logisch aus ihr folgt.
Beispiel:
Passage:
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Behauptung:
Die Kündigungsfrist in der Probezeit beträgt sieben Tage.
Die Passage unterstützt die Behauptung direkt.
Entailment wird später beim Grounding und bei Faithfulness relevant.
128. Evidence Selection
Nach Retrieval und Reranking kann man die final ausgewählten Chunks auch als Evidence bezeichnen.
Dann lautet der Prozess:
Search
↓
Candidate Ranking
↓
Evidence Selection
↓
Generation
Diese Perspektive ist besonders hilfreich bei streng quellengebundenen Systemen.
129. Retrieval soll Evidenz finden, nicht nur Text
Ein zentraler Denkwechsel lautet deshalb:
Nicht:
Welche Texte sind ähnlich?
Sondern:
Welche Passagen liefern Evidenz für die konkrete Antwort?
Embeddings, BM25, Hybrid Search und Reranking sind Werkzeuge, um dieses Ziel zu erreichen.
130. Retrieval Pipeline in ihrer erweiterten Form
Wir können die Pipeline jetzt deutlich vollständiger darstellen:
USER QUERY
│
▼
Query Processing
│
┌───────────┴───────────┐
│ │
▼ ▼
Query Rewrite Multi-Query
│ │
└───────────┬───────────┘
▼
Candidate Search
┌────────┴────────┐
▼ ▼
Dense Sparse
│ │
└────────┬────────┘
▼
Fusion
↓
Candidates
↓
Reranker
↓
Deduplication
↓
MMR
↓
Context Expansion
↓
Context Compression
↓
Evidence Selection
↓
Context Packing
↓
LLM
Nicht jede Pipeline braucht alle diese Komponenten.
Aber fast alle modernen Retrieval-Techniken lassen sich irgendwo in dieser Landkarte einordnen.
131. Eine einfachere Produktionspipeline
Eine pragmatische Pipeline könnte beispielsweise lauten:
Query
↓
Standalone Rewrite
↓
Dense + BM25
↓
RRF
↓
Top 40
↓
Cross-Encoder
↓
Top 8
↓
Deduplication
↓
Top 5 Context
↓
LLM
Das ist bereits deutlich leistungsfähiger als naive reine Vektorsuche.
132. Wann reicht einfache Dense Search?
Nicht jede Anwendung benötigt all diese Techniken.
Dense Search kann völlig ausreichend sein, wenn:
- Korpus klein,
- Dokumente sauber,
- Queries einfach,
- keine exakten IDs,
- geringe Ambiguität,
- hohe semantische Übereinstimmung.
Komplexität sollte durch gemessene Probleme gerechtfertigt werden.
133. Wann wird Reranking besonders wertvoll?
Reranking hilft besonders, wenn:
- viele semantisch ähnliche Chunks existieren,
- Hard Negatives auftreten,
- Dense Ranking unpräzise ist,
- Hybrid Candidate Sets gross sind,
- hohe Precision benötigt wird.
134. Wann hilft Query Rewrite?
Query Rewrite ist besonders nützlich bei:
- Chat-Follow-ups,
- Pronomen,
- implizitem Kontext,
- langen unstrukturierten Benutzerfragen.
135. Wann hilft Multi-Query?
Multi-Query kann helfen bei:
- schwierigen Paraphrasen,
- breiten Fragen,
- unterschiedlichen Terminologien,
- hohem Recall-Bedarf.
Bei einfachen Queries ist der zusätzliche Aufwand oft unnötig.
136. Wann hilft HyDE?
HyDE kann interessant sein, wenn:
- Query und Dokumentstil stark unterschiedlich sind,
- reine Query-Embeddings schwachen Recall liefern,
- semantisches Dense Retrieval dominiert.
Auch HyDE sollte anhand realer Retrieval-Metriken evaluiert werden.
137. Wann hilft MMR?
MMR lohnt sich vor allem, wenn:
- viele Near-Duplicates,
- redundante Chunks,
- ähnliche Dokumentversionen,
- breitere Informationsfragen
auftreten.
138. Wann hilft Contextual Compression?
Compression hilft, wenn:
- Retrieval-Chunks gross sind,
- nur kleine Textbereiche relevant sind,
- Kontextbudget knapp ist,
- hohe Informationsdichte benötigt wird.
Bei kleinen fokussierten Chunks kann sie unnötig sein.
139. Nicht jede Optimierung gleichzeitig aktivieren
Ein häufiger Fehler besteht darin, jede bekannte RAG-Technik einzubauen:
Rewrite
+
Multi-Query
+
HyDE
+
Dense
+
BM25
+
RRF
+
Cross-Encoder
+
MMR
+
Compression
Das Ergebnis kann:
- teuer,
- langsam,
- schwer testbar,
- schwer debugbar
werden.
Die richtige Reihenfolge lautet eher:
Baseline bauen
↓
Fehler messen
↓
konkrete Ursache erkennen
↓
gezielte Technik hinzufügen
↓
erneut messen
140. Retrieval Debugging
Wenn ein RAG-System falsch antwortet, kann man nun wesentlich genauer diagnostizieren.
Fall 1
Der relevante Chunk fehlt bereits im First-Stage Retrieval.
→ Retrieval Recall Problem
Mögliche Ursachen:
- Chunking,
- Embeddings,
- BM25,
- Query Rewrite,
- Top-k.
Fall 2
Chunk ist im Kandidatenpool, aber Reranker sortiert ihn schlecht.
→ Reranking Problem
Fall 3
Chunk rankt hoch, wird aber nicht in den Kontext übernommen.
→ Context Selection Problem
Fall 4
Korrekter Kontext erreicht das LLM, Antwort ist trotzdem falsch.
→ Generation / Grounding Problem
Diese Trennung ist für echtes RAG-Debugging entscheidend.
141. Traces
Ein Retrieval-Trace sollte idealerweise zeigen:
Original Query
Rewritten Query
Dense Results
Sparse Results
Fusion Scores
Reranker Scores
Selected Context
Final Prompt
Damit wird sichtbar, an welcher Stufe Information verloren ging.
142. Warum End-to-End-Tests allein nicht reichen
Wenn man nur prüft:
Frage → richtige Antwort?
weiss man bei einem Fehler nicht, warum er passiert ist.
Besser ist zusätzlich:
War relevante Passage retrieved?
War sie nach Reranking noch vorhanden?
Wurde sie in den Prompt aufgenommen?
Hat die Antwort sie korrekt verwendet?
Damit werden Fehler lokalisierbar.
143. Retrieval-Evaluation vor LLM-Evaluation
Man kann Retrieval vollständig testen, ohne überhaupt ein Antwortmodell aufzurufen.
Query
↓
Retrieval Pipeline
↓
Top-k
Dann wird geprüft:
Ist die Gold-Passage enthalten und wie hoch rankt sie?
Das macht Tests schneller, günstiger und reproduzierbarer.
144. Retrieval Dataset
Ein Testdatensatz kann enthalten:
Query
Expected Document
Expected Chunk
Optional Relevant Alternatives
Damit können:
- Recall@k,
- MRR,
- nDCG
berechnet werden.
Diese Metriken behandeln wir in Teil 8.
145. Hard-Negative Dataset
Für Reranking-Tests sind Hard Negatives besonders wertvoll.
Beispiel:
Query:
Wie lange ist die Kündigungsfrist in der Probezeit?
Positive:
Kündigungsfrist = sieben Tage.
Hard Negatives:
Probezeit = drei Monate.
Nach Probezeit = drei Monate Kündigungsfrist.
Während Probezeit gelten besondere Ferienregeln.
Damit wird getestet, ob der Reranker wirklich fein unterscheiden kann.
146. Reranking und Chunking gemeinsam evaluieren
Ein Reranker kann nur bewerten, was im Chunk steht.
Wenn der relevante Satz über zwei Chunks geteilt wurde, kann auch ein perfekter Reranker Schwierigkeiten haben.
Deshalb muss die Retrieval-Pipeline als Gesamtsystem betrachtet werden.
147. Retrieval ist nicht nur Modellwahl
Es ist verführerisch zu fragen:
Welches Embedding-Modell ist das beste?
oder:
Welcher Reranker ist der beste?
Die tatsächliche Qualität hängt jedoch von der Kombination ab:
Parsing
+
Chunking
+
Query Processing
+
Retrieval
+
Fusion
+
Reranking
+
Context Selection
Ein einzelnes Modell kann eine schlechte Pipeline nicht automatisch reparieren.
148. Die drei Retrieval-Ebenen
Eine nützliche mentale Struktur ist:
Ebene 1: Candidate Generation
Finde möglichst alle plausiblen Kandidaten.
Werkzeuge:
- Dense,
- Sparse,
- Hybrid,
- Multi-Query.
Ebene 2: Candidate Ranking
Welche Kandidaten sind wirklich relevant?
Werkzeuge:
- Cross-Encoder,
- LLM Reranking.
Ebene 3: Evidence Selection
Welche Kombination soll das LLM erhalten?
Werkzeuge:
- MMR,
- Deduplication,
- Parent Expansion,
- Compression,
- Token-aware Selection.
Diese Dreiteilung hilft enorm beim Verständnis komplexer RAG-Pipelines.
149. Begriffe dieses Teils
| Begriff | Bedeutung |
|---|---|
| Candidate Retrieval | erste breite Auswahl plausibler Treffer |
| Candidate Generation | Erzeugung einer Kandidatenmenge |
| Reranking | erneute Bewertung und Sortierung von Kandidaten |
| Cross-Encoder | Modell, das Query und Passage gemeinsam verarbeitet |
| Bi-Encoder | getrennte Kodierung von Query und Passage |
| Retrieve-then-Rerank | schnelle Suche gefolgt von präzisem Reranking |
| Reranking Depth | Anzahl Kandidaten, die genauer bewertet werden |
| MMR | Auswahl unter Berücksichtigung von Relevanz und Diversität |
| Query Rewrite | Umformulierung einer Query für besseres Retrieval |
| Standalone Query | kontextunabhängig verständliche Suchanfrage |
| Query Expansion | Ergänzung einer Query um verwandte Begriffe |
| Multi-Query | mehrere Query-Varianten für dieselbe Informationsfrage |
| Query Decomposition | Zerlegung einer komplexen Query in Teilfragen |
| HyDE | Retrieval über ein hypothetisch erzeugtes Dokument |
| Query Routing | Auswahl einer geeigneten Retrieval-Strategie |
| Adaptive Retrieval | queryabhängige Wahl von Retrieval-Verfahren |
| Context Selection | Auswahl der final an das LLM gegebenen Treffer |
| Context Budget | verfügbare Tokenmenge für Retrieval-Kontext |
| Context Packing | Zusammenstellung des finalen Kontextes |
| Context Deduplication | Entfernen redundanter Informationen |
| Contextual Compression | Reduktion eines Chunks auf queryrelevante Inhalte |
| Extractive Compression | Auswahl vorhandener Originalpassagen |
| Abstractive Compression | generierte Zusammenfassung relevanter Inhalte |
| Evidence Selection | Auswahl der finalen Belege für die Antwort |
| Retrieval Confidence | geschätzte Sicherheit der Retrieval-Ergebnisse |
| Hard Negative | thematisch ähnlicher, aber nicht relevanter Kandidat |
| Answerability | Frage, ob der Kontext tatsächlich eine Antwort erlaubt |
150. Die vollständige Retrieval-Pipeline
Nach Teil 5 lässt sich Retrieval wesentlich vollständiger darstellen:
USER QUERY
│
▼
Query Processing
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
Rewrite Multi-Query Decomposition
│ │ │
└──────────────┴──────────────┘
│
▼
Candidate Retrieval
┌───────────┴───────────┐
▼ ▼
Dense Sparse
│ │
└───────────┬───────────┘
▼
Fusion
↓
Candidates
↓
Reranker
↓
Deduplication
↓
MMR
↓
Context Expansion
↓
Contextual Compression
↓
Evidence Selection
↓
Context Packing
↓
AUGMENTATION
Und erst danach:
Context
+
Query
+
Instructions
↓
LLM
↓
Antwort
Damit haben wir den Retrieval-Teil der Serie weitgehend komplett.
151. Die wichtigste Erkenntnis aus Teil 5
Der erste Retriever muss nicht perfekt sein.
Er muss den relevanten Chunk finden.
Der Reranker muss ihn anschliessend erkennen.
Die Context-Selection-Stufe muss ihn behalten.
Und erst dann kann das LLM ihn verwenden.
Damit lautet die Pipeline:
Find
↓
Rank
↓
Select
↓
Generate
Jede dieser Stufen kann unabhängig scheitern.
Genau deshalb ist ein gutes RAG-System nicht einfach:
Vector Search
+
Prompt
sondern eine Kette unterschiedlicher Informationsentscheidungen.
Und jetzt gelangen wir an die letzte Grenze zwischen Retrieval und Generation.
Wir besitzen hochwertige Evidenz.
Aber nun stellen sich neue Fragen:
Wie viel davon geben wir dem Modell?
In welcher Reihenfolge?
Wie verhindern wir, dass relevante Informationen im langen Kontext untergehen?
Wie zwingt man das Modell dazu, sich an die Quellen zu halten?
Wann darf es überhaupt antworten?
Was bedeuten Grounding, Faithfulness und Answerability technisch?
Genau darum geht es in Teil 6: Kontext, Grounding und Antworten.
RAG von Grund auf
Teil 1 – RAG verstehen
LLM, parametrisches Wissen, Kontext, Retrieval, Augmentation, Generation und Grounding.
Teil 2 – Dokumente, Parsing und Chunking
Ingestion, Parser, OCR, Dokumentstruktur, Chunks, Overlap, Structured Chunking, Parent-Child und Small-to-Big.
Teil 3 – Embeddings und Vektorsuche
Embeddings, Dense Vectors, Bi-Encoder, Cosine Similarity, ANN, HNSW und Vector Stores.
Teil 4 – Information Retrieval und Hybrid Search
TF, IDF, TF-IDF, BM25, Sparse Retrieval, Hybrid Search und Reciprocal Rank Fusion.
Teil 5 – Reranking und Retrieval-Strategien
Cross-Encoder, Retrieve-then-Rerank, MMR, Query Rewrite, Multi-Query, Query Decomposition, HyDE, Context Selection und Compression.
Teil 6 – Kontext, Grounding und Antworten
Kontextfenster, Token-Budget, Lost in the Middle, Prompt Construction, Grounding, Faithfulness, Citations und Answerability.
Teil 7 – Advanced RAG
Naive RAG, Advanced und Modular RAG, Multi-Hop, Self-RAG, CRAG, RAPTOR, GraphRAG, ColBERT und Agentic RAG.
Teil 8 – Evaluation, Sicherheit und Abgrenzung
Recall, Precision, Hit@k, MRR, nDCG, RAG-Evaluation, Prompt Injection, RAG Poisoning, Fine-Tuning und Tool Calling.