RAG von Grund auf – Teil 4: Information Retrieval und Hybrid Search
In Teil 3 ging es um Embeddings und Vektorsuche.
Wir haben gesehen, dass Dense Retrieval besonders stark darin ist, semantisch ähnliche Inhalte zu finden.
Beispiel:
Frage:
Wie kann ich meinen Vertrag während der Probezeit beenden?
Dokument:
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Die Wörter stimmen nur teilweise überein.
Die Bedeutung ist jedoch sehr ähnlich.
Embeddings können genau diese Beziehung modellieren.
Aber Dense Retrieval hat Grenzen.
Was passiert bei:
INC-847291
oder:
CVE-2026-12345
oder:
Artikel 17.4
oder:
QX-9107-B
Hier ist nicht primär die semantische Bedeutung entscheidend.
Hier zählt die exakte Zeichenfolge.
Damit kommen wir zur zweiten grossen Welt des Retrievals:
lexikalische beziehungsweise sparse Suche.
Und genau aus der Kombination von semantischer und lexikalischer Suche entsteht eines der wichtigsten Konzepte moderner RAG-Systeme:
Hybrid Search.
1. Information Retrieval ist älter als RAG
RAG wird häufig behandelt, als hätte die Suche nach relevanten Informationen erst mit Large Language Models begonnen.
Das ist natürlich nicht der Fall.
Das Forschungsgebiet Information Retrieval, kurz IR, beschäftigt sich seit Jahrzehnten mit Fragen wie:
- Welche Dokumente sind für eine Suchanfrage relevant?
- Wie werden Dokumente indexiert?
- Wie werden Suchbegriffe gewichtet?
- Wie ordnet man Treffer nach Relevanz?
- Wie misst man die Qualität einer Suche?
Klassische Websuchmaschinen, Bibliothekskataloge, Enterprise Search und Dokumentensuchsysteme basieren auf diesen Grundlagen.
RAG übernimmt einen grossen Teil dieser Konzepte.
Das LLM kommt erst später hinzu.
2. Retrieval ist ein Ranking-Problem
Angenommen, wir besitzen 100’000 Chunks.
Ein Benutzer fragt:
Wie lange ist die Kündigungsfrist während der Probezeit?
Das Suchsystem muss nicht bloss entscheiden:
relevant
oder
nicht relevant
Es muss eine Reihenfolge bilden.
Zum Beispiel:
1. Kündigungsfrist während der Probezeit
2. Dauer der Probezeit
3. Kündigung nach Probezeit
4. Ferien während der Probezeit
5. Allgemeine Arbeitsvertragsbestimmungen
Retrieval ist deshalb typischerweise ein Ranking-Problem.
Jeder Kandidat erhält einen Score.
Danach werden die Kandidaten sortiert.
3. Lexical Retrieval
Lexical Retrieval sucht anhand von Wörtern, Tokens oder Zeichenfolgen.
Beispiel:
Query:
Kündigungsfrist Probezeit
Dokument A:
Die Kündigungsfrist während der Probezeit beträgt sieben Tage.
Dokument B:
Während der ersten drei Monate gelten besondere Regeln zur Beendigung des Arbeitsverhältnisses.
Eine rein lexikalische Suche bevorzugt sehr wahrscheinlich Dokument A.
Denn dort kommen die Suchbegriffe direkt vor.
4. Exact Match
Der einfachste Fall ist ein Exact Match.
Query:
INC-847291
Dokument:
Incident INC-847291 wurde am Montag geschlossen.
Hier ist die exakte Übereinstimmung extrem aussagekräftig.
Dense Retrieval kann diesen Zusammenhang ebenfalls erfassen.
Aber ein klassischer Suchindex kann solche exakten Tokens häufig noch zuverlässiger und transparenter behandeln.
5. Tokenisierung
Bevor klassische Suchverfahren Wörter bewerten können, muss Text in kleinere Einheiten zerlegt werden.
Dieser Vorgang heisst Tokenisierung.
Beispiel:
Die Kündigungsfrist beträgt sieben Tage.
könnte werden zu:
[
"die",
"kündigungsfrist",
"beträgt",
"sieben",
"tage"
]
Diese Tokens bilden die Grundlage vieler lexikalischer Suchverfahren.
6. Suchmaschinen-Tokens und LLM-Tokens sind nicht dasselbe
Der Begriff Token kommt sowohl bei Suchmaschinen als auch bei Sprachmodellen vor.
Er bezeichnet aber nicht zwingend dieselbe Zerlegung.
Ein LLM-Tokenizer könnte:
Kündigungsfrist
in mehrere Subword-Tokens zerlegen.
Ein klassischer Suchindex behandelt das Wort möglicherweise als einzelnes Term.
Deshalb sollte man unterscheiden zwischen:
LLM Tokenization
und:
IR Tokenization
Beide dienen unterschiedlichen Zwecken.
7. Normalisierung von Suchbegriffen
Suchsysteme normalisieren Text häufig vor der Indexierung.
Beispielsweise:
KÜNDIGUNGSFRIST
Kündigungsfrist
kündigungsfrist
werden zu:
kündigungsfrist
Mögliche Normalisierungsschritte sind:
- Lowercasing,
- Unicode-Normalisierung,
- Entfernen bestimmter Sonderzeichen,
- Sprachnormalisierung.
Die konkrete Strategie beeinflusst direkt, welche Begriffe später matchen.
8. Stopwords
Stopwords sind sehr häufig vorkommende Wörter, die bei klassischen Suchverfahren häufig wenig Unterscheidungskraft besitzen.
Beispiele:
der
die
das
und
oder
ist
Historisch wurden solche Wörter oft vollständig entfernt.
Moderne Suchsysteme können differenzierter damit umgehen.
Denn Stopwords können in bestimmten Queries durchaus Bedeutung tragen.
Beispiel:
To be or not to be
Ein blindes Entfernen wäre hier offensichtlich problematisch.
9. Stemming
Stemming reduziert Wörter auf einen künstlich erzeugten Wortstamm.
Beispielhaft:
kündigen
kündigt
gekündigt
kündigung
könnten auf einen gemeinsamen Stamm reduziert werden.
Der genaue Stamm muss sprachlich nicht korrekt sein.
Ziel ist lediglich:
ähnliche Wortformen sollen matchen.
10. Lemmatization
Lemmatization verfolgt ein ähnliches Ziel, versucht aber die linguistische Grundform eines Wortes zu bestimmen.
Beispiel:
ging
geht
gegangen
→
gehen
Lemmatization ist sprachlich anspruchsvoller als einfaches Stemming.
Beide Verfahren dienen dazu, Flexionsvarianten besser zusammenzuführen.
11. N-Grams
Ein N-Gram ist eine Folge von n Elementen.
Bei Wörtern:
"Kündigungsfrist Probezeit"
als Bigram.
Bei Zeichen:
ABC
BCD
CDE
als Character Trigrams.
N-Grams können hilfreich sein für:
- Tippfehler,
- Teilbegriffe,
- Komposita,
- Produktcodes,
- Namen.
12. Deutsche Komposita
Deutsch stellt klassische Suchsysteme vor eine besondere Herausforderung.
Beispiel:
Kündigungsfrist
enthält:
Kündigung
+
Frist
Eine Suche nach:
Frist
soll möglicherweise trotzdem matchen.
Sprachspezifische Analyzer können solche Komposita berücksichtigen.
13. Inverted Index
Die zentrale Datenstruktur vieler klassischer Suchmaschinen ist der Inverted Index.
Statt für jedes Dokument zu speichern:
Dokument → Wörter
speichert man:
Wort → Dokumente
Beispiel:
kündigungsfrist
→ Dokument 2
→ Dokument 7
→ Dokument 12
probezeit
→ Dokument 1
→ Dokument 2
→ Dokument 9
Damit kann das System sehr schnell herausfinden, welche Dokumente bestimmte Begriffe enthalten.
14. Warum „inverted“?
Ein normaler Dokumentbestand könnte so gedacht werden:
Dokument A:
Probezeit, Kündigung, Frist
Dokument B:
Ferien, Urlaub, Anspruch
Der invertierte Index dreht die Perspektive um:
Probezeit → A
Kündigung → A
Frist → A
Ferien → B
Urlaub → B
Anspruch → B
Das macht Wortsuche extrem effizient.
15. Posting List
Die Liste der Dokumente beziehungsweise Positionen zu einem Term wird häufig Posting List genannt.
Beispiel:
Term:
kündigungsfrist
Posting List:
Doc 3
Doc 18
Doc 41
Doc 92
Ein Posting kann zusätzlich enthalten:
- Häufigkeit,
- Position im Text,
- Feld,
- weitere Statistiken.
16. Term Frequency
Term Frequency, kurz TF, beschreibt, wie häufig ein Term in einem Dokument vorkommt.
Beispiel:
Dokument A:
Probezeit Probezeit Kündigung Probezeit
Dann gilt:
TF(Probezeit) = 3
Die Intuition:
Wenn ein Begriff häufiger vorkommt, ist er möglicherweise wichtiger für dieses Dokument.
Aber allein reicht das nicht.
17. Das Problem mit häufigen Wörtern
Angenommen, der Begriff:
Mitarbeiter
kommt in fast jedem Dokument vor.
Dann hilft er kaum dabei, relevante Dokumente voneinander zu unterscheiden.
Dagegen könnte:
Kündigungsfrist
nur in wenigen Dokumenten vorkommen.
Dieser Begriff ist wesentlich informativer.
Dafür benötigen wir Document Frequency und Inverse Document Frequency.
18. Document Frequency
Die Document Frequency, kurz DF, beschreibt:
In wie vielen Dokumenten kommt ein Term vor?
Angenommen:
1000 Dokumente insgesamt
und:
"mitarbeiter"
kommt in 900 Dokumenten vor
während:
"kündigungsfrist"
kommt in 30 Dokumenten vor
Dann besitzt „Kündigungsfrist“ eine höhere Unterscheidungskraft.
19. Inverse Document Frequency
Die Inverse Document Frequency, kurz IDF, gewichtet seltene Begriffe höher.
Eine vereinfachte Form lautet:
IDF(t) = log(N / DF(t))
Dabei ist:
N
die Anzahl der Dokumente und:
DF(t)
die Anzahl der Dokumente, in denen Term t vorkommt.
Je seltener ein Begriff:
höhere IDF
Je häufiger:
niedrigere IDF
20. TF-IDF
TF-IDF kombiniert:
Term Frequency
×
Inverse Document Frequency
also vereinfacht:
TF-IDF(t,d) = TF(t,d) × IDF(t)
Ein Term erhält dadurch einen hohen Score, wenn:
- er im Dokument häufig vorkommt,
- aber im gesamten Korpus relativ selten ist.
21. TF-IDF intuitiv
Angenommen, Dokument A enthält:
Probezeit Kündigungsfrist Kündigungsfrist
und Dokument B:
Probezeit Ferien
Wenn „Probezeit“ in sehr vielen Dokumenten vorkommt, erhält es eine geringere Gewichtung.
„Kündigungsfrist“ könnte dagegen sehr spezifisch sein.
Dokument A erhält dadurch für die Query:
Kündigungsfrist Probezeit
einen höheren Score.
22. TF-IDF ist ein Vektormodell
Interessanterweise erzeugt auch TF-IDF Vektoren.
Angenommen, das gesamte Vokabular lautet:
[
probezeit,
kündigung,
ferien,
arbeitszeit
]
Dann könnte ein Dokument dargestellt werden als:
[
0.8,
1.4,
0,
0
]
Das ist ebenfalls ein Vektor.
Aber ein Sparse Vector.
23. Sparse Vector
Ein Sparse Vector besitzt sehr viele Dimensionen, von denen die meisten null sind.
Beispiel:
[
0,
0,
0,
1.2,
0,
0,
0.7,
0,
0,
...
]
Das Vokabular kann zehntausende oder hunderttausende Dimensionen besitzen.
Ein einzelner Text verwendet davon nur wenige.
Daher:
sparse = dünn besetzt.
24. Dense versus Sparse
Dense Embedding:
[0.12, -0.74, 0.21, 0.55, ...]
Fast jede Dimension hat einen Wert.
Sparse Representation:
[0, 0, 1.2, 0, 0, 0.7, 0, ...]
Die meisten Dimensionen sind null.
Das ist die grundlegende technische Unterscheidung.
25. Sparse bedeutet nicht automatisch BM25
Dieser Punkt ist wichtig.
BM25 ist ein Sparse-Retrieval-Verfahren.
Aber nicht jedes Sparse Retrieval ist BM25.
Es gibt auch Learned Sparse Retrieval.
Dabei lernen neuronale Modelle gewichtete Sparse-Repräsentationen.
Ein bekanntes Konzept in dieser Familie ist beispielsweise SPLADE.
Die Repräsentation bleibt sparse, wird aber nicht ausschliesslich mit klassischen Termstatistiken erzeugt.
26. BM25
BM25 ist eines der wichtigsten klassischen Ranking-Verfahren im Information Retrieval.
Es baut auf ähnlichen Ideen wie TF-IDF auf, berücksichtigt aber weitere Faktoren.
Eine typische Form lautet:
score(D,Q)
=
Σ IDF(qi) ×[f(qi,D) × (k1 + 1)]
/
[f(qi,D) + k1 × (1 – b + b × |D| / avgdl)]
Die Formel sieht zunächst kompliziert aus.
Die Grundidee ist jedoch gut verständlich.
27. Bestandteile von BM25
BM25 berücksichtigt unter anderem:
Termhäufigkeit
Wie oft kommt der Suchbegriff im Dokument vor?
Termseltenheit
Wie selten ist dieser Begriff im Korpus?
Dokumentlänge
Ist das Dokument ungewöhnlich lang?
Damit verbessert BM25 einige Schwächen eines einfachen TF-IDF-Modells.
28. Term Frequency Saturation
Bei einfachem TF könnte man implizit denken:
10 Vorkommen
= doppelt so relevant wie
5 Vorkommen
Das ist oft unrealistisch.
BM25 verwendet eine Sättigung.
Die ersten Vorkommen eines Terms erhöhen den Score stark.
Weitere Wiederholungen bringen immer weniger zusätzlichen Nutzen.
Vereinfacht:
1 → grosser Gewinn
2 → weiterer Gewinn
3 → kleinerer Gewinn
20 → kaum noch zusätzlicher Nutzen
29. Parameter k1
Der BM25-Parameter k1 steuert, wie stark Term Frequency gesättigt wird.
Vereinfacht:
kleiner k1
→ schnelle Sättigung
grösserer k1
→ Häufigkeit wirkt länger
In der Praxis werden häufig etablierte Standardbereiche verwendet und anschliessend evaluiert.
30. Dokumentlängen-Normalisierung
Ein langes Dokument enthält statistisch mehr Wörter.
Dadurch steigt die Wahrscheinlichkeit, dass ein Suchbegriff zufällig häufiger vorkommt.
BM25 berücksichtigt deshalb die Dokumentlänge.
Ein Dokument mit 10’000 Wörtern soll nicht allein deshalb höher ranken als ein fokussierter Absatz mit 100 Wörtern.
31. Parameter b
Der Parameter b steuert die Stärke der Längennormalisierung.
Vereinfacht:
b = 0
→ Dokumentlänge spielt keine Rolle
b nahe 1
→ Dokumentlänge wird stark berücksichtigt
Der klassische Default liegt häufig ungefähr bei:
b = 0.75
Dieser Wert ist aber kein Naturgesetz.
32. avgdl
avgdl steht für:
average document length
also die durchschnittliche Dokumentlänge im Index.
BM25 vergleicht die Länge eines Dokuments mit diesem Durchschnitt.
Im Chunk-RAG bedeutet „Dokument“ in der BM25-Formel praktisch oft:
Chunk
weil Chunks die Retrieval-Einheiten sind.
33. BM25 und Chunking
Hier zeigt sich die Verbindung zu Teil 2.
Wenn Chunks extrem unterschiedlich gross sind:
Chunk A: 50 Wörter
Chunk B: 2'000 Wörter
spielt die Längennormalisierung eine grössere Rolle.
Wenn alle Chunks ähnlich gross sind, reduziert sich dieser Effekt.
Chunking beeinflusst also auch klassische Retrieval-Scores.
34. Warum BM25 heute noch relevant ist
BM25 wirkt im Zeitalter neuronaler Modelle zunächst altmodisch.
Aber es besitzt Eigenschaften, die Dense Retrieval nicht zuverlässig ersetzt.
BM25 ist besonders stark bei:
- exakten Begriffen,
- seltenen Wörtern,
- Eigennamen,
- Produktcodes,
- IDs,
- Paragraphen,
- Akronymen,
- Fachterminologie.
Beispiel:
ZX-419-B
Eine exakte lexikalische Übereinstimmung ist hier extrem wertvoll.
35. Beispiel Dense versus BM25
Query:
Wie lange kann ich während der Probezeit kündigen?
Dokument A:
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Dokument B:
In den ersten Monaten kann das Arbeitsverhältnis
mit kurzer Frist beendet werden.
Dense Retrieval könnte beide stark finden.
BM25 bevorzugt möglicherweise A, weil:
Probezeit
Kündigungsfrist
direkt vorkommen.
36. Beispiel mit Identifier
Query:
INC-847291
Dokument A:
Incident INC-847291 wurde geschlossen.
Dokument B:
Ein schwerwiegender Incident wurde gestern geschlossen.
Semantisch sind beide ähnlich.
Für den Benutzer ist aber nur A relevant.
BM25 beziehungsweise Exact Matching besitzt hier einen klaren Vorteil.
37. Beispiel mit Synonymen
Query:
Wie kann ich meinen Vertrag beenden?
Dokument:
Das Arbeitsverhältnis kann gekündigt werden.
BM25 sieht möglicherweise wenig Überlappung.
Dense Retrieval erkennt:
Vertrag beenden
≈
Arbeitsverhältnis kündigen
Hier hat Dense Retrieval den Vorteil.
38. Keine Methode gewinnt immer
Damit ergibt sich:
| Query-Typ | Dense | Sparse |
|---|---|---|
| Paraphrase | stark | eher schwächer |
| Synonym | stark | schwächer |
| exakte ID | unsicherer | sehr stark |
| seltene Fachbezeichnung | unterschiedlich | stark |
| natürlicher Satz | stark | gut bis mittel |
| exakter Produktname | gut | sehr stark |
| semantische Umschreibung | sehr stark | schwächer |
Das ist der Grund für Hybrid Search.
39. Hybrid Search
Hybrid Search kombiniert mehrere Retrieval-Signale.
Im einfachsten Fall:
Dense Retrieval
+
Sparse Retrieval
↓
kombiniertes Ranking
Damit versucht man, die Stärken beider Welten zu nutzen.
40. Eine typische Hybrid-Pipeline
Query
│
┌─────────┴─────────┐
▼ ▼
Dense Search Sparse Search
│ │
▼ ▼
Dense Top-k Sparse Top-k
│ │
└─────────┬─────────┘
▼
Fusion
↓
Hybrid Ranking
Danach kann zusätzlich ein Reranker folgen.
41. Warum Fusion notwendig ist
Dense und Sparse Retrieval erzeugen unterschiedliche Scores.
Dense beispielsweise:
0.82
0.76
0.71
BM25 möglicherweise:
14.7
9.3
6.1
Diese Zahlen haben völlig unterschiedliche Bedeutungen.
Man kann nicht einfach rechnen:
0.82 + 14.7
ohne die Score-Räume zu berücksichtigen.
Deshalb braucht man eine Fusion Strategy.
42. Score Fusion
Bei Score Fusion werden die Scores verschiedener Retriever normalisiert und kombiniert.
Beispielsweise:
Hybrid Score
=
0.5 × Dense Score
+
0.5 × Sparse Score
Das klingt einfach.
Aber zunächst müssen beide Scores sinnvoll auf vergleichbare Skalen gebracht werden.
43. Min-Max Normalization
Eine einfache Normalisierung ist:
normalized(x)
=
(x - min)
/
(max - min)
Damit werden Scores ungefähr in den Bereich:
0 bis 1
transformiert.
Danach können sie kombiniert werden.
Problem:
Die Normalisierung hängt stark von den aktuellen Trefferverteilungen ab.
44. Z-Score Normalization
Eine andere Möglichkeit ist eine Standardisierung anhand von Mittelwert und Standardabweichung.
z = (x - μ) / σ
Auch das kann Score-Räume vergleichbarer machen.
Aber auch hier entstehen praktische Fragen:
- Welche Kandidatenmenge?
- Welche Verteilung?
- Welche Ausreisser?
Score Fusion kann deshalb aufwendiger werden, als es zunächst klingt.
45. Weighted Fusion
Bei Weighted Fusion bekommen verschiedene Retriever unterschiedliche Gewichte.
Beispiel:
score =
0.7 × dense
+
0.3 × sparse
Das kann sinnvoll sein, wenn eine Retrieval-Art im jeweiligen Korpus zuverlässig stärker ist.
Die Gewichte müssen jedoch evaluiert werden.
46. Query-Adaptive Fusion
Noch flexibler ist eine queryabhängige Gewichtung.
Beispiel:
Query:
INC-847291
→ Sparse stärker gewichten.
Query:
Wie kann ich meinen Vertrag während der ersten Monate beenden?
→ Dense stärker gewichten.
Das kann leistungsfähig sein, erhöht aber die Komplexität.
47. Rank Fusion
Eine Alternative zur Score Fusion ist Rank Fusion.
Dabei interessieren nicht die absoluten Scores.
Es zählt nur die Rangposition.
Beispiel:
Dense:
1. A
2. B
3. C
Sparse:
1. B
2. D
3. A
Eine Rank-Fusion-Methode kombiniert diese Ranglisten.
48. Reciprocal Rank Fusion
Eine der wichtigsten Methoden ist Reciprocal Rank Fusion, kurz RRF.
Die Formel lautet:
RRF(d)
=
Σ 1 / (k + rank_i(d))
Dabei ist:
rank_i(d)
der Rang des Dokuments d in Retriever i.
Der Parameter k ist eine Konstante, die den Einfluss sehr hoher Ränge glättet.
49. RRF intuitiv
Angenommen:
Dense:
A → Rang 1
B → Rang 2
C → Rang 3
Sparse:
B → Rang 1
A → Rang 2
D → Rang 3
A und B werden von beiden Retrievern hoch eingestuft.
RRF belohnt genau diese Übereinstimmung.
50. Warum RRF beliebt ist
RRF besitzt einen grossen praktischen Vorteil:
Es muss keine inkompatiblen Score-Skalen normalisieren.
Dense kann Scores zwischen:
0.4 und 0.9
liefern.
Sparse kann:
3 bis 25
liefern.
RRF ignoriert die absoluten Werte und nutzt nur die Rangposition.
Das macht die Methode robust und einfach.
51. Der RRF-Parameter k
In der RRF-Formel:
1 / (k + rank)
steuert k, wie stark Spitzenränge gegenüber niedrigeren Rängen bevorzugt werden.
Ein häufig zitierter klassischer Wert ist:
k = 60
Dieser Wert stammt aus der Information-Retrieval-Literatur und ist kein universell optimaler Wert für jedes RAG-System.
52. RRF-Beispiel
Nehmen wir vereinfacht:
k = 60
Dokument A:
Dense Rank = 1
Sparse Rank = 2
Dann:
RRF(A)
=
1/(60+1)
+
1/(60+2)
Dokument C:
Dense Rank = 3
Sparse Rank = nicht vorhanden
Dann erhält C nur den Beitrag aus einer Liste.
A wird dadurch stärker bewertet.
53. Dokument fehlt in einer Rangliste
Wenn ein Dokument in einem Retriever nicht auftaucht, erhält es aus dieser Rangliste keinen Beitrag.
Damit bevorzugt RRF tendenziell Kandidaten, die:
- von mehreren Retrievern gefunden werden,
- oder in einem Retriever extrem hoch ranken.
54. Candidate Union
Bevor Rankings fusioniert werden können, werden Kandidaten häufig vereinigt.
Beispiel:
Dense Top 5:
A
B
C
D
E
Sparse Top 5:
B
F
A
G
H
Union:
A
B
C
D
E
F
G
H
Diese Kandidaten erhalten anschliessend einen Fusionsscore.
55. Duplicate Handling
Da derselbe Chunk in beiden Suchwegen vorkommen kann, benötigt man stabile IDs.
So wird:
Dense: Chunk 42
Sparse: Chunk 42
als derselbe Kandidat erkannt.
Ansonsten könnten identische Chunks mehrfach in der Ergebnisliste auftauchen.
56. Hybrid Search ist nicht einfach „mehr Treffer“
Das Ziel lautet nicht:
Dense 10
+
Sparse 10
=
20 Treffer an LLM
Sondern:
verschiedene Retrieval-Signale
↓
bessere Kandidatenmenge
↓
besseres Ranking
Danach kann die Menge wieder reduziert werden.
57. Candidate Generation
Dense und Sparse Retrieval werden häufig als Candidate Generators eingesetzt.
Beispielsweise:
Dense Top 50
Sparse Top 50
↓
Fusion
↓
70 eindeutige Kandidaten
↓
Reranker
↓
Top 10
Das Ziel der ersten Stufe ist hoher Recall.
58. Recall First
In der Candidate-Generation-Phase ist es oft wichtiger, die richtige Passage überhaupt im Kandidatenpool zu haben, als sofort perfekt zu sortieren.
Denn:
nicht retrieved
=
später nicht rerankbar
Ein Reranker kann einen Kandidaten nur verbessern, wenn er vorher gefunden wurde.
59. Precision Later
Nachdem genügend Kandidaten vorhanden sind, kann eine teurere zweite Stufe die Präzision erhöhen.
hoher Recall
↓
Reranking
↓
hohe Precision
Diese zweistufige Denkweise ist zentral für modernes Retrieval.
60. Keyword Search versus BM25
Nicht jede Keyword-Suche verwendet automatisch BM25.
Es gibt beispielsweise:
- Boolean Search,
- Exact Match,
- Phrase Search,
- Prefix Search,
- Fuzzy Search,
- TF-IDF,
- BM25.
BM25 ist ein Ranking-Modell innerhalb der grösseren Welt lexikalischer Suche.
61. Boolean Retrieval
Bei Boolean Retrieval arbeitet man mit logischen Bedingungen.
Beispiel:
probezeit AND kündigung
oder:
probezeit AND NOT ferien
Das System entscheidet primär anhand logischer Matches.
Für klassische Suchinterfaces kann das sehr nützlich sein.
Für natürlichsprachliche RAG-Queries ist es allein meist zu starr.
62. Phrase Search
Bei Phrase Search wird eine exakte Wortfolge gesucht.
Beispiel:
"Kündigungsfrist während der Probezeit"
Das ist stärker als eine Suche nach den einzelnen Terms irgendwo im Dokument.
Phrase Matching kann besonders für:
- Namen,
- Titel,
- Fachbegriffe,
- Zitate
hilfreich sein.
63. Proximity Search
Proximity Search berücksichtigt, wie nahe Suchbegriffe im Text beieinander liegen.
Beispiel:
Probezeit ... Kündigungsfrist
im selben Satz ist wahrscheinlich relevanter als:
Probezeit
auf Seite 1 und:
Kündigungsfrist
auf Seite 30.
Positionen im invertierten Index ermöglichen solche Signale.
64. Field Boosting
Dokumente besitzen häufig Felder:
title
heading
body
tags
Ein Treffer im Titel kann stärker gewichtet werden als derselbe Begriff im Body.
Beispiel:
Title:
Kündigung während der Probezeit
ist ein sehr starkes Signal für die Query:
Kündigung Probezeit
Diese Technik heisst häufig Field Boosting.
65. Metadata Boosting
Neben Textfeldern können auch Metadaten das Ranking beeinflussen.
Beispiel:
aktuelles Dokument
könnte gegenüber:
archiviertes Dokument
bevorzugt werden.
Das ist allerdings kein rein textbasiertes Relevanzsignal mehr.
66. Recency Boost
Bei zeitabhängigen Wissensbeständen kann Recency relevant sein.
Beispiel:
Richtlinie 2026
soll möglicherweise höher ranken als:
Richtlinie 2023
wenn beide ansonsten ähnlich sind.
Das kann durch Filter oder Ranking-Boosts erfolgen.
67. Fuzzy Search
Fuzzy Search toleriert kleine Schreibabweichungen.
Query:
Kündigunsfrist
Dokument:
Kündigungsfrist
Eine exakte Suche würde scheitern.
Fuzzy Matching kann den Tippfehler überbrücken.
68. Edit Distance
Ein häufig verwendetes Konzept hinter Fuzzy Search ist die Edit Distance.
Sie misst, wie viele Zeichenoperationen nötig sind, um einen String in einen anderen umzuwandeln.
Beispielsweise:
Haus
Maus
benötigt eine Ersetzung.
Die bekannteste Variante ist die Levenshtein Distance.
69. Prefix Search
Bei Prefix Search kann eine Anfrage wie:
kündig
Begriffe finden wie:
kündigung
kündigungsfrist
kündigen
Das ist besonders für Suchfelder mit Autocomplete interessant.
In RAG-Pipelines spielt es je nach Query-Typ eine kleinere, aber mögliche Rolle.
70. Analyzer
Ein Analyzer definiert in klassischen Suchmaschinen typischerweise eine Verarbeitungskette aus:
Character Filters
↓
Tokenizer
↓
Token Filters
Beispielsweise:
Text
↓
Lowercase
↓
German Tokenizer
↓
Stemming
↓
Index Terms
Der Analyzer bestimmt wesentlich, welche Begriffe später matchen.
71. Index-Time Analysis
Bei der Indexierung wird Dokumenttext analysiert.
Dokument
↓
Analyzer
↓
Terms
↓
Inverted Index
Das ist Index-Time Analysis.
72. Query-Time Analysis
Auch die Suchanfrage muss verarbeitet werden.
Query
↓
Analyzer
↓
Query Terms
Index- und Query-Analyse müssen sinnvoll aufeinander abgestimmt sein.
Wenn Dokumente und Queries völlig unterschiedlich tokenisiert werden, sinkt die Trefferqualität.
73. Query Expansion
Query Expansion erweitert eine Suchanfrage um verwandte Begriffe.
Beispiel:
Query:
Auto
erweitert zu:
Auto
Fahrzeug
PKW
Das kann lexikalischen Recall erhöhen.
Bei RAG kann Query Expansion regelbasiert, modellbasiert oder über LLMs erfolgen.
74. Synonym Expansion
Eine spezielle Form ist Synonym Expansion.
Beispiel:
kündigen
↔
Arbeitsverhältnis beenden
Dadurch kann Sparse Retrieval teilweise semantische Varianten abdecken.
Das zeigt:
Sparse Search muss nicht zwingend auf exakte Wortgleichheit beschränkt bleiben.
75. Expansion birgt Risiken
Zu aggressive Expansion kann falsche Treffer erzeugen.
Beispiel:
Bank
kann bedeuten:
Finanzinstitut
oder:
Sitzbank
Kontextabhängige Bedeutungen machen Synonymregeln schwierig.
Dense Retrieval löst solche Ambiguitäten häufig besser.
76. Learned Sparse Retrieval
Klassische sparse Verfahren verwenden explizite Termstatistiken.
Neuere Ansätze lernen Sparse-Repräsentationen neuronaler Modelle.
Ein Text könnte dadurch Gewichte nicht nur für direkt vorkommende Wörter erhalten, sondern auch für semantisch verwandte Begriffe.
Vereinfacht:
Text:
Arbeitsverhältnis beenden
könnte zusätzlich hohe Gewichte erhalten für:
kündigung
kündigen
kündigungsfrist
Das verbindet teilweise Vorteile von Sparse und semantischer Suche.
77. SPLADE
SPLADE ist eine bekannte Familie neuronaler Sparse-Retrieval-Modelle.
Die Grundidee:
Text
↓
Transformer
↓
gewichtete Sparse-Term-Repräsentation
Die Repräsentation bleibt kompatibel mit sparse Suchprinzipien, enthält aber gelernte semantische Expansion.
Für das Grundverständnis genügt:
Sparse Retrieval kann klassisch oder gelernt sein.
78. Dense versus Learned Sparse
Beide können semantische Information transportieren.
Der strukturelle Unterschied bleibt:
Dense:
kleiner fester Vektorraum
mit vielen Nichtnullwerten
Learned Sparse:
sehr grosser Vokabularraum
mit wenigen gewichteten Terms
Das beeinflusst Indexierung, Speicher und Suchverfahren.
79. Hybrid kann mehr als zwei Retriever kombinieren
Hybrid Search muss nicht nur bedeuten:
Dense + BM25
Man könnte kombinieren:
Dense Embedding Search
+
BM25
+
Learned Sparse
+
Metadata Signals
oder sogar weitere Suchkanäle.
Je mehr Signale hinzukommen, desto wichtiger wird eine robuste Fusion.
80. Multi-Retriever Systems
Ein System mit mehreren unabhängigen Retrieval-Methoden wird häufig als Multi-Retriever-Ansatz beschrieben.
Beispiel:
Query
├── Dense Retriever
├── BM25 Retriever
├── Metadata Retriever
└── Graph Retriever
Danach werden Kandidaten kombiniert.
Hybrid Retrieval ist damit ein Spezialfall eines allgemeineren Multi-Retriever-Prinzips.
81. Query Routing
Nicht jede Query benötigt zwingend alle Retriever.
Ein System könnte erkennen:
Query enthält exakte ID
und Sparse Search stärker einsetzen.
Oder:
Query ist konzeptionell
und Dense Search bevorzugen.
Diese Entscheidung nennt man häufig Query Routing.
82. Routing versus Fusion
Bei Routing entscheidet man:
Welcher Retriever soll verwendet werden?
Bei Fusion entscheidet man:
Wie kombiniere ich mehrere Retriever-Ergebnisse?
Beides sind unterschiedliche Strategien.
83. Warum immer beide Retriever verwenden?
Ein einfacher Ansatz lautet:
jede Query
→ Dense
→ Sparse
→ Fusion
Vorteile:
- einfach,
- robust,
- keine falsche Routing-Entscheidung.
Nachteile:
- mehr Suchaufwand,
- potenziell höhere Latenz,
- mehr Kandidaten.
Für viele Systeme ist dieser Trade-off trotzdem attraktiv.
84. Warum nicht nur BM25?
BM25 kann erstaunlich stark sein.
Aber bei semantischer Umschreibung entstehen Grenzen.
Query:
Kann ich in den ersten Monaten kurzfristig aus dem Arbeitsvertrag raus?
Passage:
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Die lexikalische Überschneidung ist gering.
Dense Retrieval kann hier deutlich besser funktionieren.
85. Warum nicht nur Dense?
Umgekehrt:
Query:
CVE-2026-12345
Dense Retrieval muss diese konkrete Zeichenfolge nicht zwingend perfekt priorisieren.
BM25 sieht dagegen einen extrem seltenen, exakten Term.
Hier ist Sparse Retrieval strukturell besser geeignet.
86. Hybrid Search als Robustheitsstrategie
Hybrid Search ist deshalb weniger eine exotische Optimierung als eine Robustheitsstrategie.
Sie reduziert die Abhängigkeit von einer einzigen Vorstellung von Relevanz.
Dense sagt:
Diese Texte bedeuten Ähnliches.
Sparse sagt:
Diese Texte verwenden dieselben wichtigen Begriffe.
Beides zusammen liefert ein stärkeres Signal.
87. Lexical Match und Semantic Match
Man kann zwei unterschiedliche Relevanztypen unterscheiden.
Lexical Match
Query:
Kündigungsfrist
Passage:
Kündigungsfrist
Semantic Match
Query:
Vertrag beenden
Passage:
Arbeitsverhältnis kündigen
Hybrid Search versucht beide Arten gleichzeitig abzudecken.
88. Score Calibration
Bei Score Fusion stellt sich die Frage, ob Scores verschiedener Retriever kalibriert sind.
Ein Dense Score von:
0.78
und ein BM25 Score von:
11.6
sind nicht direkt vergleichbar.
Calibration versucht, Scores in eine interpretierbarere oder gemeinsame Skala zu bringen.
Das ist schwieriger als Rank Fusion.
89. RRF versus Weighted Score Fusion
Vereinfacht:
RRF
Vorteile:
- robust,
- einfach,
- keine Score-Normalisierung nötig.
Nachteile:
- ignoriert Score-Abstände.
Weighted Score Fusion
Vorteile:
- kann Stärke einzelner Scores berücksichtigen.
Nachteile:
- benötigt Normalisierung beziehungsweise Calibration.
Es gibt keinen universellen Gewinner.
90. Score-Abstand kann Information enthalten
Angenommen Dense liefert:
A = 0.91
B = 0.90
Das ist ein sehr kleiner Unterschied.
Oder:
A = 0.91
B = 0.55
Hier ist der Unterschied wesentlich grösser.
Rank Fusion betrachtet in beiden Fällen nur:
A Rang 1
B Rang 2
und verliert die Information über den Score-Abstand.
Das ist eine der Grenzen von RRF.
91. Trotzdem ist Rang oft stabiler als Score
Absolute Scores können sich stark verändern durch:
- anderes Embedding-Modell,
- andere Query,
- anderen Korpus,
- andere BM25-Statistiken.
Ränge sind oft leichter zu kombinieren.
Deshalb ist RRF als Baseline sehr beliebt.
92. Top-k pro Retriever
Bei Hybrid Search benötigt jeder Retriever ein eigenes k.
Beispiel:
Dense Top 30
Sparse Top 30
oder:
Dense Top 50
Sparse Top 20
Diese Werte beeinflussen den Recall der fusionierten Kandidatenmenge.
93. Warum ein zu kleines k gefährlich ist
Angenommen, die relevante Passage liegt:
Dense Rank 7
Sparse Rank 2
Bei:
Dense k = 5
Sparse k = 5
wird sie trotzdem über Sparse gefunden.
Wenn sie aber:
Dense Rank 7
Sparse Rank 9
ist und beide Retriever nur Top 5 liefern, ist sie vollständig verloren.
94. Warum ein zu grosses k teuer wird
Bei:
Dense k = 200
Sparse k = 200
kann die Union hunderte Kandidaten enthalten.
Das belastet:
- Fusion,
- Reranking,
- Latenz,
- Speicher,
- eventuell LLM-basierte Rankingstufen.
Deshalb muss k evaluiert werden.
95. Candidate Recall
Eine wichtige Metrik für diese Stufe ist:
Ist mindestens eine relevante Passage im Kandidatenpool?
Das ist Candidate Recall beziehungsweise Retrieval Recall.
Wenn die relevante Passage bereits hier fehlt, kann keine spätere Stufe sie retten.
96. Search Recall versus Answer Quality
Ein System kann hervorragenden Retrieval Recall haben und trotzdem schlechte Antworten erzeugen.
Beispiel:
Top 50 enthält richtigen Chunk
aber:
Reranker wirft ihn weg
oder:
LLM ignoriert ihn
Deshalb müssen die Pipeline-Stufen separat gemessen werden.
97. Search Precision
Precision betrachtet den Anteil relevanter Treffer innerhalb der zurückgegebenen Menge.
Vereinfacht:
10 Treffer
davon 7 relevant
Precision = 0.7
Bei der ersten Candidate-Generation ist perfekte Precision oft weniger wichtig als guter Recall.
Später wird sie wichtiger.
98. Recall und Precision stehen oft im Spannungsfeld
Ein sehr breites Retrieval:
Top 100
erhöht die Chance, relevante Dokumente zu finden.
Aber es enthält möglicherweise viele irrelevante Kandidaten.
Ein sehr enges Retrieval:
Top 3
kann hohe Precision besitzen, aber relevante Passagen verpassen.
Das ist der klassische Recall-Precision-Trade-off.
99. Threshold Search
Statt nur Top-k kann man Treffer auch anhand eines Mindest-Scores filtern.
Beispiel:
nur Similarity ≥ 0.70
oder:
BM25 Score ≥ X
Aber Thresholds sind problematisch, weil Scores query- und modellspezifisch sind.
100. Top-k und Threshold kombinieren
Man kann beide Strategien kombinieren:
hole maximal 20 Treffer
aber nur wenn Score ≥ Threshold
Damit verhindert man beispielsweise, dass bei völlig irrelevanten Queries trotzdem 20 schlechte Treffer zurückgegeben werden.
Auch hier muss der Threshold empirisch bestimmt werden.
101. Null Result
Ein gesundes Suchsystem muss zulassen:
0 brauchbare Treffer
Es sollte nicht zwanghaft immer Ergebnisse liefern.
Denn:
Top-k
bedeutet nur:
Die besten k aus dem vorhandenen Korpus.
Nicht:
Diese k sind gut.
102. Das Top-k-Paradox
Wenn das Korpus überhaupt nichts Relevantes enthält, liefert eine reine Top-k-Suche trotzdem:
Top 5
Diese fünf Treffer sind mathematisch die besten.
Aber möglicherweise alle ungeeignet.
Deshalb benötigt ein RAG-System später zusätzliche Answerability- oder Relevance-Prüfungen.
103. Query Intent und Retrieval
Die Form einer Query beeinflusst, welche Suchart stark ist.
Beispiel:
"INC-847291"
ist identifier-orientiert.
"Welche Regeln gelten, wenn ich in den ersten Monaten kündigen möchte?"
ist semantisch.
"Artikel 17 Kündigungsfrist"
ist gemischt.
Hybrid Search reduziert die Notwendigkeit, jede Query perfekt zu klassifizieren.
104. Filters versus Search Terms
Angenommen, die Query lautet:
Was sagt das Personalreglement 2026 zur Probezeit?
Man könnte alles als Text suchen.
Oder strukturierte Teile extrahieren:
document_type = personalreglement
year = 2026
und nur:
Probezeit
retrieven.
Das kann präziser sein.
105. Filter sind harte Bedingungen
Ein Filter bedeutet typischerweise:
muss erfüllt sein
Beispiel:
year = 2026
Ein Dokument von 2025 wird ausgeschlossen, selbst wenn es semantisch perfekt passt.
106. Boosts sind weiche Bedingungen
Ein Boost bedeutet dagegen:
bevorzugen, aber nicht zwingend
Beispiel:
Dokumente von 2026 höher ranken
Ein Dokument von 2025 kann weiterhin auftauchen.
Filter und Boosts dürfen nicht verwechselt werden.
107. Query Parser
Ein Query Parser kann versuchen, strukturierte Bestandteile einer Anfrage zu erkennen.
Beispiel:
"Personalreglement 2026 Probezeit"
wird zu:
text_query = "Probezeit"
document_type = "Personalreglement"
year = 2026
Das kombiniert natürliche Sprache mit strukturierter Suche.
108. Metadata-aware Retrieval
Wenn Metadaten sauber während der Ingestion erzeugt wurden, kann Retrieval sie nutzen.
Damit zeigt sich wieder die Verbindung zu Teil 2:
gute Ingestion
↓
gute Metadaten
↓
präzisere Filter
↓
besseres Retrieval
109. Retrieval ist ein System aus Signalen
Man sollte sich Retrieval nicht als einen einzelnen Score vorstellen.
Ein modernes System kann viele Signale berücksichtigen:
Dense Similarity
BM25
Exact Match
Title Match
Metadata
Recency
Document Type
Permissions
Danach werden diese Signale kombiniert oder in mehreren Stufen verarbeitet.
110. First-Stage Retrieval
Die erste Suchstufe wird häufig First-Stage Retrieval genannt.
Ihre Aufgabe:
sehr viele Dokumente
↓
kleine Kandidatenmenge
Sie muss:
- schnell,
- skalierbar,
- recall-stark
sein.
Dense ANN und BM25 sind typische First-Stage Retriever.
111. Second-Stage Ranking
Danach folgt häufig:
Second-Stage Ranking
oder:
Reranking.
Dabei werden nur noch die Kandidaten genauer bewertet.
100'000 Chunks
↓
First Stage
↓
50 Kandidaten
↓
Second Stage
↓
5 Kandidaten
Darum geht es ausführlich in Teil 5.
112. Lexical Retrieval ist transparent
Ein Vorteil klassischer Suchverfahren ist ihre relative Erklärbarkeit.
Bei einem Treffer kann man häufig nachvollziehen:
Query-Term "Kündigungsfrist"
kommt im Dokument vor
und:
ist im Korpus selten
Dense Embeddings sind wesentlich schwieriger direkt zu interpretieren.
Diese Transparenz ist bei Debugging wertvoll.
113. Dense Retrieval ist flexibler
Dense Retrieval kann dagegen Beziehungen erkennen, die lexikalisch nicht sichtbar sind.
Beispiel:
Query:
Wie verlasse ich meinen Arbeitgeber während der ersten Monate?
Dokument:
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Das ist die grosse Stärke semantischer Repräsentationen.
114. Hybrid Retrieval erhöht Fehlertoleranz
Wenn Dense Retrieval eine relevante Passage verpasst, kann Sparse sie finden.
Wenn Sparse wegen fehlender Wortüberschneidung scheitert, kann Dense sie finden.
Damit entsteht Redundanz:
Dense Failure
↓
Sparse kann retten
Sparse Failure
↓
Dense kann retten
Das ist ein wesentlicher Grund, warum Hybrid Retrieval so attraktiv ist.
115. Hybrid Search löst nicht alles
Auch Hybrid Search kann scheitern.
Beispielsweise:
- relevante Information wurde schlecht gechunkt,
- OCR hat den Schlüsselbegriff zerstört,
- Query ist mehrdeutig,
- Antwort benötigt mehrere Dokumente,
- passende Passage liegt ausserhalb beider Top-k,
- ähnliche Versionen konkurrieren,
- der relevante Chunk enthält zu wenig Kontext.
Hybrid Retrieval verbessert die Kandidatensuche.
Es ersetzt nicht die restliche RAG-Pipeline.
116. Beispiel einer vollständigen Hybrid-Suche
Angenommen, die Query lautet:
Welche Kündigungsfrist gilt während der Probezeit?
Dense Search:
1. Dauer und Kündigung in der Probezeit
2. Kündigung nach der Probezeit
3. Allgemeine Regeln zum Arbeitsverhältnis
4. Ferien während der Probezeit
BM25:
1. Kündigungsfrist während der Probezeit
2. Allgemeine Kündigungsfristen
3. Probezeit
4. Kündigung von Arbeitsverhältnissen
RRF könnte daraus erzeugen:
1. Kündigungsfrist während der Probezeit
2. Dauer und Kündigung in der Probezeit
3. Allgemeine Kündigungsfristen
4. Probezeit
Danach kann ein Reranker die Kandidaten nochmals präziser bewerten.
117. Beispiel mit exakter ID
Query:
Was steht zu INC-847291?
Dense:
1. allgemeines Incident-Dokument
2. ähnliches Incident-Ticket
3. INC-847291
Sparse:
1. INC-847291
2. anderer Text mit Incident-Begriffen
Fusion:
1. INC-847291
Hier rettet das exakte lexikalische Signal das Ranking.
118. Beispiel mit Paraphrase
Query:
Wie kann ich in den ersten Monaten meinen Arbeitsvertrag beenden?
Dense:
1. Kündigung während der Probezeit
BM25:
1. Arbeitsvertrag allgemein
2. erste Monate Beschäftigung
3. Kündigung
Fusion kann Dense stark berücksichtigen und trotzdem zusätzliche lexikalische Kandidaten behalten.
119. Search Pipeline als Funnel
Eine hilfreiche Darstellung ist ein Funnel:
gesamter Index
100'000 Chunks
↓
Dense + Sparse
↓
100 Kandidaten
↓
Fusion
↓
50 Kandidaten
↓
Reranking
↓
10 Kandidaten
↓
Context Selection
↓
5 Chunks
↓
LLM
Jede Stufe reduziert die Menge und erhöht idealerweise die Qualität.
120. Retrieval Quality beginnt bei Candidate Generation
Die wichtigste Frage der First Stage lautet:
Ist der richtige Chunk überhaupt dabei?
Wenn nein:
Reranker
LLM
Grounding
können nichts mehr retten.
Darum sollte Retrieval separat evaluiert werden.
121. Query Set für Evaluation
Ein guter Testbestand enthält unterschiedliche Query-Typen.
Zum Beispiel:
Exact Match
INC-847291
Fachbegriff
Kündigungsfrist Probezeit
Paraphrase
Wie schnell kann ich in den ersten Monaten kündigen?
Synonym
Wie kann das Arbeitsverhältnis beendet werden?
Mehrsprachig
What is the notice period during probation?
So zeigt sich, welche Retriever welche Stärken besitzen.
122. Ablation Testing
Bei einem Ablation Test entfernt man gezielt eine Komponente.
Beispielsweise:
Dense only
gegen:
BM25 only
gegen:
Dense + BM25 + RRF
Dann vergleicht man die Retrieval-Metriken.
So lässt sich messen, ob Hybrid Search tatsächlich einen Mehrwert bringt.
123. Warum Benchmarks allein nicht reichen
Ein Embedding-Modell oder Retriever kann auf öffentlichen Benchmarks hervorragend abschneiden.
Der eigene Korpus kann aber bestehen aus:
- deutschen Verträgen,
- Abkürzungen,
- internen IDs,
- Tabellen,
- Fachbegriffen.
Deshalb muss Retrieval mit realistischen eigenen Queries evaluiert werden.
124. Retrieval ist korpusabhängig
Ein Korpus voller natürlicher Fliesstexte stellt andere Anforderungen als:
API-Dokumentationen
oder:
Support-Tickets
oder:
Gesetzestexte
oder:
Produktkataloge mit Artikelnummern
Die optimale Mischung aus Dense und Sparse kann deshalb unterschiedlich sein.
125. Dokumentfrequenz ist korpusabhängig
Auch IDF-Werte hängen direkt vom Korpus ab.
Der Begriff:
Kündigung
kann in einem allgemeinen Unternehmenswiki relativ selten sein.
In einer Sammlung arbeitsrechtlicher Dokumente kann er sehr häufig sein.
Damit verändert sich seine IDF.
BM25 ist deshalb intrinsisch korpusabhängig.
126. Embeddings sind ebenfalls domänenabhängig
Dense Retrieval hat eine andere Art von Korpusabhängigkeit.
Ein allgemeines Embedding-Modell kann gewisse Fachbegriffe schlechter repräsentieren.
Deshalb gilt für beide Welten:
nicht theoretisch entscheiden
sondern
mit echten Daten evaluieren
127. BM25 ist keine „alte Version von Embeddings“
Diese Vorstellung ist falsch.
BM25 und Dense Retrieval modellieren Relevanz unterschiedlich.
BM25 sagt im Kern:
Welche wichtigen Query-Terme tauchen im Dokument auf?
Dense Retrieval sagt eher:
Welche Passage liegt semantisch nahe an der Query?
Beide besitzen auch heute unterschiedliche Stärken.
128. Sparse Retrieval ist kein Fallback
Sparse Search sollte nicht bloss als Notlösung betrachtet werden, falls Dense Search versagt.
In vielen Fachkorpora trägt Sparse Retrieval substanzielle Qualität bei.
Besonders bei:
IDs
Namen
Versionen
Akronymen
Fachterminologie
kann es der wichtigere Retriever sein.
129. Dense Retrieval ist keine „intelligentere Suche“
Es ist ebenfalls irreführend, Dense Search pauschal als intelligentere Version klassischer Suche zu betrachten.
Sie optimiert einen anderen Signaltyp.
Ein System, das:
AB-4711
nicht exakt findet, obwohl der String im Dokument steht, wirkt für den Benutzer nicht intelligent.
Semantik ersetzt Präzision nicht.
130. Hybrid Search ist keine Magie
Hybrid Search verbessert die Robustheit, erzeugt aber neue Designfragen:
- Welche Retriever?
- Wie grosses k?
- Welche Fusion?
- Welche Gewichte?
- Welche Filter?
- Welche Query-Normalisierung?
- Welche Kandidaten gehen ins Reranking?
- Wie werden Duplikate behandelt?
Auch Hybrid Search muss evaluiert werden.
131. Begriffe dieses Teils
| Begriff | Bedeutung |
|---|---|
| Information Retrieval | Fachgebiet zur Suche und Bewertung relevanter Informationen |
| Lexical Retrieval | Suche anhand von Begriffen beziehungsweise Textmerkmalen |
| Sparse Retrieval | Retrieval mit dünn besetzten Repräsentationen |
| Inverted Index | Term-zu-Dokument-Struktur für schnelle Textsuche |
| Posting List | Liste der Dokumente beziehungsweise Positionen eines Terms |
| Term Frequency | Häufigkeit eines Terms in einem Dokument |
| Document Frequency | Anzahl der Dokumente, die einen Term enthalten |
| IDF | Gewichtung seltener Begriffe |
| TF-IDF | Kombination aus Termhäufigkeit und Termseltenheit |
| BM25 | klassisches probabilistisches Ranking-Verfahren |
| k1 | BM25-Parameter für Term-Frequency-Sättigung |
| b | BM25-Parameter für Längennormalisierung |
| avgdl | durchschnittliche Dokumentlänge |
| Analyzer | Verarbeitungskette für Index- und Query-Text |
| Stemming | Reduktion auf Wortstämme |
| Lemmatization | Rückführung auf linguistische Grundformen |
| Stopwords | sehr häufige, oft schwach unterscheidende Wörter |
| N-Gram | Folge von n Wörtern oder Zeichen |
| Phrase Search | Suche nach exakten Wortfolgen |
| Fuzzy Search | fehlertolerante Textsuche |
| Edit Distance | Mass für Zeichenunterschiede |
| Field Boosting | stärkere Gewichtung bestimmter Dokumentfelder |
| Query Expansion | Erweiterung der Query um zusätzliche Begriffe |
| Learned Sparse Retrieval | neuronales sparse Retrieval |
| Hybrid Search | Kombination mehrerer Retrieval-Verfahren |
| Score Fusion | Kombination numerischer Retriever-Scores |
| Rank Fusion | Kombination von Ranglisten |
| RRF | Reciprocal Rank Fusion |
| Candidate Generation | erste breite Erzeugung relevanter Kandidaten |
| First-Stage Retrieval | schnelle Retrieval-Stufe über den gesamten Index |
| Second-Stage Ranking | genauere Bewertung einer kleineren Kandidatenmenge |
| Query Routing | Auswahl geeigneter Retriever für eine Query |
| Filter | harte Einschränkung des Suchraums |
| Boost | weiche Bevorzugung eines Kandidaten |
| Top-k | Anzahl der höchsten Suchtreffer |
| Threshold | Mindestscore für akzeptierte Treffer |
| Precision | Anteil relevanter Ergebnisse unter den gelieferten Ergebnissen |
| Recall | Anteil gefundener relevanter Informationen |
132. Dense und Sparse in einer Übersicht
| Eigenschaft | Dense Retrieval | Sparse Retrieval |
|---|---|---|
| Grundlage | Embeddings | Terms / Sparse Weights |
| Stärke | Semantik | exakte Begriffe |
| Synonyme | stark | abhängig von Expansion |
| Paraphrasen | stark | eher schwach |
| IDs | potenziell schwächer | sehr stark |
| Eigennamen | gut bis unterschiedlich | stark |
| Erklärbarkeit | geringer | höher |
| Index | Vector Index | Inverted Index |
| typische Verfahren | ANN, HNSW | BM25, TF-IDF |
| typische Repräsentation | Dense Vector | Sparse Vector |
Die Kombination lautet:
Dense
+
Sparse
↓
Hybrid Retrieval
133. Die vollständige Retrieval-Landkarte bis hierhin
Wir können die ersten vier Teile jetzt zusammenführen.
INGESTION
Dokument
↓
Parsing / OCR
↓
Struktur
↓
Chunking
↓
Chunks
│
├───────────────┐
│ │
▼ ▼
Embedding Sparse Index
│ │
▼ ▼
Vector Index Inverted Index
QUERY
Frage
│
┌────────┴────────┐
▼ ▼
Query Embedding Query Terms
│ │
▼ ▼
Dense Search Sparse Search
│ │
└────────┬────────┘
▼
Fusion
↓
Hybrid Candidates
↓
Reranking
↓
Context Selection
↓
LLM
Damit haben wir den Kern moderner Retrieval-Pipelines erreicht.
134. Die wichtigste Erkenntnis aus Teil 4
Dense Retrieval beantwortet grob:
Welche Texte bedeuten etwas Ähnliches?
Sparse Retrieval beantwortet grob:
Welche Texte enthalten die wichtigen gesuchten Begriffe?
Keine dieser Fragen ist identisch mit:
Welche Passage beantwortet die Benutzerfrage am besten?
Deshalb kombiniert man beide zunächst zur Candidate Generation.
Danach folgt eine neue Aufgabe:
Wir haben gute Kandidaten.
Welche davon sind wirklich die besten?
Genau hier beginnt Reranking.
Ein Bi-Encoder kann Millionen Chunks schnell auf wenige Kandidaten reduzieren.
Ein BM25-Retriever kann exakte Begriffe zuverlässig ergänzen.
RRF kann beide Ranglisten zusammenführen.
Aber eine Passage kann immer noch:
- semantisch ähnlich,
- lexikalisch passend,
- und trotzdem nicht die richtige Antwort
sein.
Die nächste Stufe muss deshalb die Query und jeden Kandidaten wesentlich genauer miteinander vergleichen.
Damit kommen wir zu:
Cross-Encodern, Rerankern, MMR, Query Rewrite, Multi-Query und HyDE.
Das ist Teil 5.
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
Inverted Index, TF, IDF, TF-IDF, BM25, Sparse Retrieval, Hybrid Search, Score Fusion und Reciprocal Rank Fusion.
Teil 5 – Reranking und Retrieval-Strategien
Cross-Encoder, Top-k, MMR, Query Rewrite, Multi-Query, HyDE und Context Selection.
Teil 6 – Kontext, Grounding und Antworten
Kontextfenster, Token-Budget, Lost in the Middle, Answerability, Faithfulness und Citations.
Teil 7 – Advanced RAG
Naive RAG, 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.