RAG von Grund auf – Teil 3: Embeddings und Vektorsuche verstehen
In Teil 1 haben wir RAG als Zusammenspiel von Retrieval, Augmentation und Generation betrachtet.
In Teil 2 ging es darum, wie Dokumente durch Parsing, OCR und Chunking überhaupt erst in durchsuchbare Informationseinheiten zerlegt werden.
Jetzt kommt der nächste Schritt:
Wie kann eine Maschine erkennen, dass zwei Texte inhaltlich ähnlich sind, obwohl sie unterschiedliche Wörter verwenden?
Eine Benutzerfrage könnte lauten:
Wann kann ich während der Probezeit kündigen?
Im Dokument steht aber:
Während der Probezeit kann das Arbeitsverhältnis
mit einer Frist von sieben Tagen aufgelöst werden.
Eine reine Wortsuche sieht zwischen beiden Texten nur begrenzte Übereinstimmung.
Semantisch behandeln sie jedoch dasselbe Thema.
Genau hier kommen Embeddings und Vektorsuche ins Spiel.
1. Von Text zu Zahlen
Computer arbeiten nicht direkt mit Bedeutung.
Ein Suchsystem benötigt eine mathematische Repräsentation von Text.
Eine sehr einfache Repräsentation könnte beispielsweise zählen, welche Wörter vorkommen:
Probezeit 1
Kündigung 1
Arbeitsvertrag 0
Ferien 0
Damit entsteht bereits eine numerische Darstellung.
Moderne Embedding-Modelle gehen wesentlich weiter.
Sie bilden Texte auf Vektoren ab, deren Position im Vektorraum semantische Eigenschaften des Textes repräsentiert.
Vereinfacht:
"Wie lange ist die Kündigungsfrist?"
↓
Embedding-Modell
↓
[0.12, -0.44, 0.91, 0.03, ...]
Diese Zahlenfolge ist ein Embedding.
2. Was ist ein Vektor?
Mathematisch ist ein Vektor zunächst eine geordnete Liste von Zahlen.
Ein zweidimensionaler Vektor könnte beispielsweise sein:
[3, 5]
Ein dreidimensionaler:
[3, 5, 2]
Embeddings besitzen wesentlich mehr Dimensionen.
Beispielsweise:
[0.021, -0.481, 0.173, ..., 0.044]
mit möglicherweise:
384 Dimensionen
768 Dimensionen
1024 Dimensionen
1536 Dimensionen
...
Die konkrete Dimension hängt vom Embedding-Modell ab.
3. Was bedeutet Dimension?
Eine Dimension entspricht einer Position im Vektor.
Ein Vektor mit vier Dimensionen könnte so aussehen:
[
0.2,
-0.7,
0.4,
0.1
]
Bei Text-Embeddings darf man diese Dimensionen normalerweise nicht naiv interpretieren als:
Dimension 1 = Kündigung
Dimension 2 = Probezeit
Dimension 3 = Arbeitsrecht
So funktionieren moderne Embeddings nicht.
Bedeutung ist verteilt über viele Dimensionen repräsentiert.
Man spricht deshalb von einer distributed representation.
4. Was ist ein Embedding?
Ein Embedding ist eine gelernte numerische Repräsentation eines Objekts.
Das Objekt kann sein:
- ein Wort,
- ein Satz,
- ein Absatz,
- ein Chunk,
- ein Dokument,
- ein Bild,
- Audio,
- Code.
Im RAG-Kontext interessieren uns zunächst Text-Embeddings.
Text
↓
Embedding-Modell
↓
Dense Vector
Die entscheidende Eigenschaft lautet:
Semantisch ähnliche Texte sollen im Vektorraum nahe beieinander liegen.
5. Der semantische Vektorraum
Stellen wir uns der Einfachheit halber einen zweidimensionalen Raum vor.
Ferien
•
Probezeit • • Kündigung
• Vertragsende
• Datenbank
• Netzwerk
Texte über Arbeitsverhältnisse liegen in diesem vereinfachten Beispiel nahe beieinander.
Texte über Datenbanken und Netzwerke liegen an einer anderen Stelle.
Reale Embedding-Räume besitzen nicht zwei, sondern hunderte oder tausende Dimensionen.
Wir können sie nicht direkt visualisieren.
Das Grundprinzip bleibt jedoch dasselbe.
6. Semantische Ähnlichkeit
Betrachten wir zwei Texte:
A:
Wie lange ist die Kündigungsfrist während der Probezeit?
B:
Während der Probezeit kann das Arbeitsverhältnis
mit einer Frist von sieben Tagen beendet werden.
Lexikalisch sind sie nicht identisch.
Semantisch sind sie stark verwandt.
Ein gutes Embedding-Modell erzeugt deshalb Vektoren, die nahe beieinander liegen.
Embedding(A) ≈ Embedding(B)
Ein Text über Ferien sollte weiter entfernt liegen:
Embedding(A) ≠ Embedding(Ferienregelung)
7. Warum Embeddings für RAG interessant sind
Eine klassische Keyword-Suche sucht primär nach Wörtern.
Eine Embedding-Suche sucht nach semantischer Ähnlichkeit.
Beispiel:
Frage:
Wie kann ich meinen Vertrag in der Probezeit beenden?
Dokument:
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Es existiert keine perfekte Wortübereinstimmung zwischen:
Vertrag beenden
und:
Kündigungsfrist
Ein semantisches Modell kann die Beziehung trotzdem erkennen.
8. Dense Vector
Text-Embeddings werden häufig als Dense Vectors bezeichnet.
Dense bedeutet, dass die meisten Dimensionen einen Wert besitzen.
Beispiel:
[0.14, -0.22, 0.81, 0.04, -0.37, ...]
Fast jede Position enthält eine Zahl.
Das Gegenstück ist ein Sparse Vector, bei dem die meisten Werte null sind.
Sparse Retrieval behandeln wir ausführlich in Teil 4.
9. Dense Retrieval
Beim Dense Retrieval werden sowohl Dokumente als auch Suchanfragen in Dense Vectors umgewandelt.
Während der Ingestion:
Chunk
↓
Embedding-Modell
↓
Chunk-Vektor
↓
Index
Bei einer Suchanfrage:
Frage
↓
dasselbe Embedding-Modell
↓
Query-Vektor
↓
Ähnlichkeitssuche
Danach sucht das System nach den Chunk-Vektoren, die dem Query-Vektor am ähnlichsten sind.
10. Query Embedding
Das Embedding einer Suchanfrage wird häufig als Query Embedding bezeichnet.
Beispiel:
Query:
"Wie lange ist die Kündigungsfrist?"
↓
Embedding Model
↓
Query Vector
Dieser Vektor wird mit den bereits indexierten Chunk-Vektoren verglichen.
11. Document Embedding
Analog kann man von Document Embeddings sprechen.
Im RAG-Kontext handelt es sich häufig genauer um:
Chunk Embeddings
weil nicht das gesamte Dokument, sondern einzelne Chunks eingebettet werden.
Aus:
Personalreglement.pdf
entstehen:
Chunk 1 → Vector 1
Chunk 2 → Vector 2
Chunk 3 → Vector 3
...
Damit kann die Suche gezielt einzelne relevante Passagen finden.
12. Bi-Encoder
Die klassische Embedding-Suche basiert typischerweise auf einem Bi-Encoder beziehungsweise Dual Encoder.
Die Grundidee:
Die Frage und der Dokumenttext werden getrennt verarbeitet.
Frage
↓
Encoder
↓
Query Vector
und:
Chunk
↓
Encoder
↓
Chunk Vector
Danach werden die beiden Vektoren mathematisch verglichen.
Das ist entscheidend.
Der Encoder sieht beim Erzeugen des Dokumentvektors die spätere Benutzerfrage nicht.
13. Warum getrennte Kodierung wichtig ist
Wenn Dokumente unabhängig von einer späteren Frage eingebettet werden können, müssen ihre Embeddings nur einmal berechnet werden.
Beispiel:
100'000 Chunks
↓
einmal Embeddings berechnen
↓
Vektoren speichern
Danach kommen beliebig viele Fragen:
Frage A → Query Embedding
Frage B → Query Embedding
Frage C → Query Embedding
Die Dokumentvektoren bleiben bestehen.
Das macht Dense Retrieval skalierbar.
14. Der Preis des Bi-Encoder-Prinzips
Die getrennte Verarbeitung besitzt aber einen Nachteil.
Das Modell bewertet nicht direkt:
Wie relevant ist genau dieser Absatz für genau diese Frage?
Es erzeugt nur zwei unabhängige Repräsentationen.
Danach wird deren mathematische Nähe gemessen.
Deshalb ist ein Bi-Encoder schnell und skalierbar, aber nicht immer maximal präzise.
Später werden wir sehen, warum Cross-Encoder häufig als zweite Ranking-Stufe eingesetzt werden.
15. Ähnlichkeit messen
Wir besitzen nun zwei Vektoren:
Query Vector
und:
Chunk Vector
Jetzt benötigen wir eine mathematische Funktion, um deren Ähnlichkeit oder Distanz zu bestimmen.
Drei wichtige Verfahren sind:
- Cosine Similarity,
- Dot Product / Inner Product,
- Euclidean Distance / L2.
16. Cosine Similarity
Die Cosine Similarity misst den Winkel zwischen zwei Vektoren.
Die Formel lautet:
cos(A,B) = (A · B) / (||A|| ||B||)
Dabei ist:
A · B
das Skalarprodukt und:
||A||
die Länge des Vektors.
Die Intuition:
Zwei Vektoren, die in eine ähnliche Richtung zeigen, sind ähnlich.
17. Cosine Similarity intuitiv
Stellen wir uns zwei Pfeile vor.
A ↗
B ↗
Beide zeigen fast in dieselbe Richtung.
Hohe Cosine Similarity.
Dagegen:
A ↗
B ↙
Sie zeigen in entgegengesetzte Richtungen.
Niedrige beziehungsweise negative Cosine Similarity.
Die Länge der Pfeile spielt bei der Cosine Similarity keine direkte Rolle.
Entscheidend ist der Winkel.
18. Wertebereich der Cosine Similarity
Mathematisch liegt die Cosine Similarity zwischen:
-1 und 1
Vereinfacht:
1 gleiche Richtung
0 orthogonal
-1 entgegengesetzte Richtung
Bei realen Embedding-Modellen hängt die praktische Interpretation der Scores stark vom Modell ab.
Ein Wert wie:
0.82
ist deshalb nicht universell gleichbedeutend mit:
82 % relevant.
Das wäre eine falsche Interpretation.
19. Similarity Score ist keine Wahrscheinlichkeit
Das ist eine wichtige Falle.
Ein Similarity Score von:
0.76
bedeutet nicht:
76 % Wahrscheinlichkeit, dass der Chunk relevant ist.
Der Score ist ein mathematisches Ähnlichkeitsmass.
Seine praktische Bedeutung hängt ab von:
- Embedding-Modell,
- Korpus,
- Query-Typ,
- Normalisierung,
- Distanzfunktion.
Thresholds müssen deshalb empirisch bestimmt werden.
20. Dot Product
Beim Dot Product beziehungsweise Inner Product werden die entsprechenden Vektorkomponenten multipliziert und addiert.
A · B = Σ AiBi
Beispiel:
A = [1, 2]
B = [3, 4]
A · B = 1×3 + 2×4
= 11
Bei normalisierten Vektoren hängt Dot Product eng mit Cosine Similarity zusammen.
21. Normalisierte Vektoren
Ein Vektor kann auf Länge 1 normalisiert werden.
Dann gilt:
||A|| = 1
Sind beide Vektoren normalisiert, vereinfacht sich Cosine Similarity zu:
cos(A,B) = A · B
Deshalb können Cosine und Inner Product bei normalisierten Embeddings äquivalent sein.
22. Euclidean Distance
Die Euclidean Distance, häufig L2 Distance, misst den direkten Abstand zwischen zwei Punkten.
In zwei Dimensionen entspricht das dem bekannten geometrischen Abstand.
distance(A,B) = sqrt(Σ(Ai-Bi)²)
Hier gilt:
kleiner Abstand = ähnlicher
Bei Cosine Similarity gilt dagegen normalerweise:
höherer Score = ähnlicher
Diese Richtung sollte man bei Datenbanken und APIs beachten.
23. Cosine versus L2 versus Inner Product
Keine Distanzmetrik ist universell die beste.
Entscheidend ist, womit das Embedding-Modell trainiert wurde und welche Metrik empfohlen wird.
| Metrik | Grundidee |
|---|---|
| Cosine | Winkel zwischen Vektoren |
| Inner Product | Skalarprodukt |
| L2 | geometrischer Abstand |
Man sollte die Distanzmetrik nicht beliebig wechseln, nur weil eine Datenbank mehrere Optionen anbietet.
24. Ein einfaches Retrieval-Beispiel
Angenommen, unser Index enthält vier Chunks:
A:
Die Kündigungsfrist während der Probezeit beträgt sieben Tage.
B:
Mitarbeiter haben Anspruch auf 25 Ferientage.
C:
Die Probezeit dauert drei Monate.
D:
Die VPN-Verbindung benötigt eine Zwei-Faktor-Authentifizierung.
Frage:
Wann kann ich während der Probezeit kündigen?
Das Embedding-Modell erzeugt einen Query-Vektor.
Danach könnten die Ähnlichkeiten beispielsweise sein:
A → 0.86
C → 0.71
B → 0.39
D → 0.18
Dann wird sortiert:
1. A
2. C
3. B
4. D
Das ist ein Ranking.
25. Top-k
Mit Top-k bezeichnet man die k bestbewerteten Treffer.
Bei:
k = 3
würde das System zurückgeben:
A
C
B
Der vierte Treffer wird verworfen.
Top-k ist ein zentraler Parameter im Retrieval.
26. Warum Top-k wichtig ist
Ist k zu klein:
k = 1
kann ein relevanter Treffer knapp verloren gehen.
Ist k sehr gross:
k = 100
gelangen viele irrelevante Kandidaten in spätere Stufen.
Das verursacht:
- mehr Rechenaufwand,
- mehr Reranking-Kosten,
- mehr Rauschen,
- potenziell grössere Prompts.
Top-k ist deshalb ein Recall-gegen-Kosten-Trade-off.
27. Top-k ist nicht Prompt-k
Ein häufiger Denkfehler:
Wenn ich Top 20 retrieve, muss ich 20 Chunks an das LLM schicken.
Nein.
Man kann beispielsweise:
Retrieval Top-k = 50
danach reranken:
50 → 10
und schliesslich nur:
5 Chunks
in den Prompt übernehmen.
Retrieval-Kandidaten und finaler Kontext sind unterschiedliche Dinge.
28. Embedding-Modell und LLM sind unterschiedliche Modelle
Ein RAG-System verwendet häufig mindestens zwei unterschiedliche Modelltypen.
Embedding-Modell
für Retrieval und:
Generatives LLM
für die Antwort.
Das Embedding-Modell erzeugt:
Vector
Das LLM erzeugt:
Text
Ein starkes Chatmodell ist nicht automatisch ein starkes Embedding-Modell.
29. Embedding Dimension
Ein Embedding-Modell definiert normalerweise eine feste Vektordimension.
Beispielsweise hypothetisch:
Model A → 384 Dimensionen
Model B → 768 Dimensionen
Model C → 1024 Dimensionen
Alle Vektoren innerhalb desselben Index müssen zur erwarteten Dimension passen.
Ein 768-dimensionaler Query-Vektor kann nicht sinnvoll direkt mit einem 1024-dimensionalen Dokumentvektor verglichen werden.
30. Embedding-Modelle sind nicht austauschbar
Noch wichtiger:
Zwei Modelle mit derselben Dimension erzeugen nicht automatisch kompatible Vektorräume.
Angenommen:
Model A → 768 Dimensionen
Model B → 768 Dimensionen
Trotzdem gilt nicht:
Embedding_A(Text)
≈
Embedding_B(Text)
Die Dimension sagt nur etwas über die Form des Vektors aus.
Nicht über die Bedeutung der einzelnen Koordinaten.
31. Warum ein Modellwechsel Re-Indexing verlangt
Angenommen, alle Dokumente wurden mit Modell A eingebettet.
Chunks
↓
Model A
↓
Index
Später erzeugt man Query-Vektoren mit Modell B:
Query
↓
Model B
↓
Vector
Dann vergleicht man Vektoren aus zwei unterschiedlichen semantischen Räumen.
Das ist normalerweise nicht sinnvoll.
Deshalb gilt:
Ein Wechsel des Embedding-Modells erfordert in der Regel neue Embeddings für den gesamten betroffenen Index.
32. Embedding-Modell wählen
Die Qualität eines Embedding-Modells hängt vom Anwendungsfall ab.
Relevante Kriterien sind:
- Sprache,
- Mehrsprachigkeit,
- Domäne,
- maximale Eingabelänge,
- Retrieval-Qualität,
- Dimension,
- Geschwindigkeit,
- Speicherbedarf,
- Lizenz,
- Hardwareanforderungen.
Ein englisch optimiertes Modell ist nicht automatisch optimal für deutschsprachige Dokumente.
33. Multilingual Embeddings
Ein multilinguales Embedding-Modell versucht, semantisch ähnliche Texte verschiedener Sprachen nahe beieinander abzubilden.
Beispiel:
DE:
Wie lange ist die Kündigungsfrist?
EN:
What is the notice period?
PT:
Qual é o prazo de aviso prévio?
Idealerweise liegen alle drei Embeddings nahe beieinander.
Das ermöglicht Cross-Lingual Retrieval.
34. Cross-Lingual Retrieval
Bei Cross-Lingual Retrieval kann die Suchsprache von der Dokumentsprache abweichen.
Beispiel:
Frage auf Deutsch
↓
Embedding
↓
französisches Dokument
Das kann in mehrsprachigen Wissensbeständen sehr wertvoll sein.
Die tatsächliche Qualität hängt stark vom Embedding-Modell ab.
35. Domain-Specific Embeddings
Allgemeine Embedding-Modelle kennen viele Sprachmuster.
Spezialisierte Domänen können jedoch besondere Anforderungen haben.
Beispiele:
- Medizin,
- Recht,
- Finanzwesen,
- wissenschaftliche Literatur,
- Source Code.
Ein Begriff kann in einer Fachdomäne eine präzisere Bedeutung besitzen als in Alltagssprache.
Deshalb existieren domänenspezifische Embedding-Modelle.
36. Query und Passage können unterschiedliche Rollen haben
Einige Embedding-Modelle unterscheiden explizit zwischen:
Query
und:
Passage
Das kann durch spezielle Präfixe oder unterschiedliche Encoder geschehen.
Beispielsweise konzeptionell:
query: Kündigungsfrist Probezeit
und:
passage: Während der Probezeit beträgt ...
Man sollte deshalb die Dokumentation des verwendeten Modells beachten.
37. Asymmetric Search
RAG ist häufig eine asymmetrische Suche.
Die Query ist kurz:
Wie lange ist die Probezeit?
Die Passage ist länger:
Das Arbeitsverhältnis beginnt mit einer Probezeit
von drei Monaten. Während dieser Zeit ...
Query und Passage besitzen unterschiedliche sprachliche Formen.
Embedding-Modelle für Retrieval werden häufig genau für diese Art von Aufgabe trainiert.
38. Symmetric Search
Bei symmetrischer Suche besitzen Query und Kandidaten ähnliche Form.
Beispielsweise:
Satz A ↔ Satz B
bei Duplicate Detection.
Das unterscheidet sich von:
Frage ↔ Passage
bei Retrieval.
Nicht jedes Embedding-Modell ist für beide Aufgaben gleich gut.
39. Sentence Embeddings
Sentence Embeddings repräsentieren Sätze oder kurze Textpassagen als einzelne Vektoren.
Der Begriff ist historisch verbreitet, obwohl moderne Modelle häufig auch Absätze oder längere Texte einbetten können.
Die zentrale Idee bleibt:
variable Textlänge
↓
fester Vektor
40. Pooling
Transformer erzeugen intern Repräsentationen für einzelne Tokens.
Für Retrieval benötigt man häufig einen einzigen Vektor für den gesamten Text.
Dazu wird Pooling verwendet.
Vereinfacht:
Token 1 Vector
Token 2 Vector
Token 3 Vector
...
↓
Pooling
↓
Text Vector
Mögliche Verfahren sind beispielsweise Mean Pooling oder spezielle Repräsentationstokens.
Die konkrete Methode gehört normalerweise zum Embedding-Modell.
41. Mean Pooling
Beim Mean Pooling werden Token-Repräsentationen gemittelt.
Vereinfacht:
Text Vector =
Durchschnitt aller relevanten Token-Vektoren
Das ist nur eine mögliche Strategie.
Moderne Embedding-Modelle werden oft gezielt so trainiert, dass die resultierende gepoolte Repräsentation für semantische Suche geeignet ist.
42. Training von Embedding-Modellen
Embedding-Modelle lernen typischerweise anhand von Beispielen, welche Texte ähnlich oder unähnlich sein sollen.
Beispielsweise:
Query:
Wie lange dauert die Probezeit?
Positive Passage:
Die Probezeit beträgt drei Monate.
Negative Passage:
Der Ferienanspruch beträgt 25 Tage.
Das Training versucht:
distance(Query, Positive) ↓
distance(Query, Negative) ↑
43. Positive und Negative Samples
Ein Positive Sample ist ein relevanter Text.
Ein Negative Sample ist ein nicht relevanter Text.
Besonders wichtig sind Hard Negatives.
44. Hard Negatives
Ein Hard Negative ist ein Text, der der Query ähnlich erscheint, aber nicht die gesuchte Information enthält.
Beispiel:
Query:
Wie lange ist die Kündigungsfrist während der Probezeit?
Positive:
Während der Probezeit beträgt die Kündigungsfrist sieben Tage.
Hard Negative:
Die Probezeit dauert drei Monate.
Der Hard Negative enthält dieselben Themenbegriffe, beantwortet aber die Frage nicht.
Solche Beispiele helfen Modellen, feinere Relevanzunterschiede zu lernen.
45. Semantic Similarity ist nicht Relevanz
Dieser Unterschied ist fundamental.
Ein Chunk kann semantisch ähnlich zur Frage sein, ohne sie zu beantworten.
Frage:
Wie hoch ist der Ferienanspruch?
Chunk:
Ferien müssen mit dem Vorgesetzten abgestimmt werden.
Hohe thematische Ähnlichkeit.
Aber keine Antwort auf die konkrete Frage.
Deshalb gilt:
Similarity ist nicht dasselbe wie Relevance.
Dense Retrieval erzeugt Kandidaten.
Es löst das vollständige Relevanzproblem nicht.
46. Warum Dense Search allein scheitern kann
Dense Search ist stark bei:
- Paraphrasen,
- Synonymen,
- semantischen Beziehungen,
- natürlicher Sprache.
Sie kann schwächer sein bei:
- exakten IDs,
- Artikelnummern,
- seltenen Namen,
- Produktcodes,
- Paragraphennummern,
- Versionsnummern,
- exakten Zahlen.
Beispiel:
INC-847291
besitzt kaum „Semantik“.
Hier ist exaktes lexikalisches Matching häufig stärker.
47. Das Exact-Match-Problem
Frage:
Was steht in Ticket INC-847291?
Ein semantisches Embedding kann möglicherweise verschiedene Tickets ähnlich repräsentieren.
Für den Benutzer ist aber genau:
INC-847291
entscheidend.
Eine Keyword- oder Sparse-Suche kann diesen exakten Token sehr stark gewichten.
Genau deshalb kombinieren moderne RAG-Systeme häufig Dense und Sparse Retrieval.
Das ist Thema von Teil 4.
48. Vector Store
Ein Vector Store ist ein System, das Vektoren zusammen mit zugehörigen Daten speichert und Ähnlichkeitssuche ermöglicht.
Konzeptionell:
Vector
+
Chunk Text
+
Metadata
Beispiel:
ID: 42
Vector: [0.12, -0.41, ...]
Text: "Die Kündigungsfrist beträgt sieben Tage."
Document: Personalreglement
Page: 7
49. Vector Database
Der Begriff Vector Database wird häufig für Datenbanksysteme verwendet, die speziell für:
- Vektorspeicherung,
- Similarity Search,
- Indexierung,
- Metadatenfilter,
- Skalierung
optimiert sind.
Nicht jeder Vector Store muss eine eigenständige Datenbank sein.
Auch bestehende Datenbanksysteme können Vektorsuche unterstützen.
50. Was wird im Vector Store gespeichert?
Typischerweise mindestens:
ID
Vector
Häufig zusätzlich:
Chunk Text
Document ID
Page
Heading
Language
Date
Source
Permissions
weitere Metadata
Der Vektor allein wäre für eine spätere Antwort nicht ausreichend.
Nach dem Treffer muss das System den ursprünglichen Text wieder abrufen können.
51. Point, Record oder Object
Vektordatenbanken verwenden unterschiedliche Begriffe für eine gespeicherte Einheit.
Beispiele:
Point
Record
Object
Node
Entity
Konzeptionell ist häufig gemeint:
ID
+
Vector
+
Payload / Metadata
Die konkrete Terminologie hängt vom Produkt ab.
52. Payload
Als Payload bezeichnet man häufig die nicht-vektoriellen Daten eines gespeicherten Vektorobjekts.
Beispiel:
vector:
[0.12, ...]
payload:
{
document_id: "123",
page: 7,
text: "...",
language: "de"
}
Die Payload ermöglicht später:
- Quellenanzeige,
- Filterung,
- Kontextrekonstruktion.
53. Metadata Filtering
Vektorsuche kann mit strukturierten Filtern kombiniert werden.
Beispiel:
Similarity Search
AND
year = 2026
AND
language = "de"
Damit muss das Embedding nicht jede Einschränkung semantisch lösen.
Das ist besonders nützlich für:
- Datum,
- Dokumenttyp,
- Mandant,
- Benutzerrechte,
- Kategorie,
- Sprache.
54. Pre-Filtering und Post-Filtering
Bei Pre-Filtering wird der Suchraum vor oder während der Vektorsuche eingeschränkt.
nur Dokumente aus 2026
↓
Vektorsuche
Bei Post-Filtering wird zuerst gesucht und danach gefiltert.
Vektorsuche
↓
Treffer
↓
nur 2026 behalten
Pre-Filtering kann effizienter und für Recall sicherer sein, wenn der Filter zwingend ist.
Post-Filtering kann dazu führen, dass nach dem Filter zu wenige Treffer übrig bleiben.
55. Brute-Force Vector Search
Die einfachste Vektorsuche wäre:
Query Vector
↓
mit jedem gespeicherten Vektor vergleichen
↓
sortieren
Bei 1’000 Vektoren ist das möglicherweise problemlos.
Bei:
100 Millionen Vektoren
wird es teuer.
Deshalb verwendet man spezielle Indexstrukturen.
56. Exact Nearest Neighbor
Wenn jeder Kandidat exakt verglichen wird, spricht man von Exact Nearest Neighbor Search.
Das liefert mathematisch die exakten nächsten Nachbarn.
Der Nachteil ist der Rechenaufwand.
Mit wachsendem Index wird eine vollständige Suche zunehmend teuer.
57. Approximate Nearest Neighbor
Deshalb verwendet man häufig Approximate Nearest Neighbor, kurz ANN.
Die Idee:
Nicht garantiert den mathematisch absolut nächsten Vektor finden, sondern sehr schnell einen sehr guten Kandidaten.
Das klingt zunächst nach einem Qualitätsverlust.
In der Praxis ermöglicht ANN aber Vektorsuche über sehr grosse Datenmengen.
58. ANN als Trade-off
ANN optimiert den Trade-off zwischen:
Geschwindigkeit
Speicher
Recall
Mehr Suchaufwand kann höheren Recall liefern.
Weniger Suchaufwand kann schnellere Antworten liefern.
Vektordatenbanken bieten dafür unterschiedliche Indexparameter.
59. Was bedeutet Nearest Neighbor?
Angenommen, der Query-Vektor liegt hier:
A •
Q •
B •
C •
Die nächsten Nachbarn zu Q sind A und B.
C liegt weiter entfernt.
Das System sucht also geometrisch nach nahegelegenen Punkten im hochdimensionalen Vektorraum.
60. HNSW
Eine der wichtigsten ANN-Strukturen ist HNSW:
Hierarchical Navigable Small World
HNSW organisiert Vektoren als Graph.
Jeder Punkt ist mit bestimmten anderen Punkten verbunden.
Die Suche muss dadurch nicht jeden Vektor prüfen.
61. HNSW intuitiv
Stellen wir uns Städte vor.
Eine naive Suche würde die Entfernung zu jeder Stadt berechnen.
HNSW funktioniert eher wie ein Strassennetz mit verschiedenen Ebenen.
Oben existieren wenige grosse Verbindungen:
Zürich ───────── Bern ───────── Genf
Auf tieferen Ebenen werden die Verbindungen feiner:
Olten ─ Aarau ─ Zürich
Die Suche springt zunächst grob durch den Raum und wird danach immer präziser.
62. Hierarchie bei HNSW
Das „Hierarchical“ in HNSW bedeutet, dass der Graph mehrere Ebenen besitzt.
Vereinfacht:
Level 2:
A -------- F -------- K
Level 1:
A --- C --- F --- H --- K
Level 0:
A-B-C-D-E-F-G-H-I-J-K
Die Suche beginnt auf einer höheren Ebene und bewegt sich schrittweise in Richtung des Query-Vektors.
Danach steigt sie in feinere Ebenen hinab.
63. Small World
Der Begriff Small World stammt aus Graphstrukturen, bei denen weit entfernte Regionen durch wenige Verbindungen erreichbar sind.
Dadurch kann die Suche schnell grosse Bereiche des Vektorraums überspringen.
Das macht HNSW für hochdimensionale Vektorsuche sehr leistungsfähig.
64. HNSW ist approximativ
HNSW durchsucht nicht zwingend jeden möglichen Kandidaten.
Deshalb kann der mathematisch exakte nächste Nachbar theoretisch verpasst werden.
Die Suchparameter beeinflussen, wie gründlich gesucht wird.
Mehr Gründlichkeit:
höherer Recall
aber
mehr Latenz
Weniger Gründlichkeit:
schneller
aber
potenziell weniger Recall
65. efSearch
Ein häufiger HNSW-Parameter ist konzeptionell efSearch.
Er beeinflusst, wie viele Kandidaten während der Suche berücksichtigt werden.
Vereinfacht:
kleines efSearch
→ schneller
→ möglicherweise weniger Recall
grosses efSearch
→ gründlicher
→ langsamer
Die genaue Bezeichnung und Implementierung kann je nach System variieren.
66. HNSW-Build-Parameter
Auch beim Aufbau des Graphen existieren Parameter.
Sie beeinflussen beispielsweise:
- Anzahl der Verbindungen,
- Indexbauzeit,
- Speicherbedarf,
- spätere Suchqualität.
Ein besser vernetzter Graph kann die Suche verbessern, benötigt aber mehr Ressourcen.
67. HNSW-Speicherbedarf
HNSW speichert nicht nur Vektoren.
Zusätzlich benötigt der Graph Verbindungen zwischen Punkten.
Bei Millionen Vektoren kann dieser Overhead erheblich sein.
Deshalb ist Vektorsuche nicht nur eine Frage der Embedding-Grösse.
Auch die Indexstruktur benötigt Speicher.
68. IVF
Eine weitere ANN-Familie ist IVF:
Inverted File Index.
Die Grundidee ist Clustering.
Vektoren werden zunächst grob in Regionen gruppiert.
Cluster A
Cluster B
Cluster C
Cluster D
Bei einer Query werden nur die wahrscheinlich relevanten Cluster durchsucht.
69. IVF intuitiv
Statt jedes Haus in der Schweiz zu prüfen, entscheidet man zunächst:
Die gesuchte Adresse liegt wahrscheinlich im Kanton Solothurn.
Danach sucht man nur dort.
Das reduziert den Suchraum.
Je mehr Cluster untersucht werden, desto höher typischerweise der Recall und desto höher die Kosten.
70. Product Quantization
Product Quantization, kurz PQ, ist eine Technik zur Kompression von Vektoren.
Ein hochdimensionaler Float-Vektor benötigt relativ viel Speicher.
PQ approximiert Vektoren mit kompakteren Codes.
Dadurch sinken:
- Speicherbedarf,
- Speicherbandbreite.
Der Preis ist potenzieller Genauigkeitsverlust.
71. Vector Quantization
Allgemeiner bezeichnet Vector Quantization Verfahren, die Vektoren kompakter repräsentieren.
Dabei entsteht ein Trade-off:
weniger Speicher
↕
weniger Präzision
Bei sehr grossen Indizes kann dieser Trade-off notwendig sein.
72. Index-Quantisierung versus LLM-Quantisierung
Diese beiden Dinge dürfen nicht verwechselt werden.
LLM-Quantisierung
Modellgewichte
FP16 → INT8 → 4 Bit
reduziert den Speicherbedarf eines Modells.
Vector-Index-Quantisierung
Embedding-Vektoren
→ kompaktere Repräsentation
reduziert den Speicherbedarf des Suchindexes.
Beides verwendet den Begriff Quantisierung, betrifft aber unterschiedliche Daten.
73. Float32
Embedding-Vektoren werden häufig als Gleitkommazahlen gespeichert.
Beispielsweise:
float32
Eine einzelne Dimension benötigt dann typischerweise 4 Byte.
Ein Vektor mit 768 Dimensionen benötigt grob:
768 × 4 Byte
= 3072 Byte
≈ 3 KB
nur für die Rohwerte.
74. Speicher grob abschätzen
Bei einer Million Vektoren mit 768 Float32-Dimensionen:
1'000'000 × 768 × 4 Byte
≈ 3.07 GB
Das berücksichtigt noch nicht:
- IDs,
- Payloads,
- Indexstrukturen,
- Graphkanten,
- Datenbank-Overhead.
Der tatsächliche Speicherbedarf liegt deshalb höher.
75. Dimension und Speicher
Höhere Dimension bedeutet tendenziell:
mehr Speicher pro Vektor
mehr Speicherbandbreite
mehr Rechenaufwand
Eine höhere Dimension bedeutet aber nicht automatisch bessere Retrieval-Qualität.
Die Qualität hängt vom trainierten Modell ab.
76. Matryoshka Embeddings
Manche modernen Embedding-Modelle unterstützen Matryoshka Representation Learning.
Die Idee:
Ein grosser Embedding-Vektor kann auf weniger Dimensionen gekürzt werden, während möglichst viel Retrieval-Qualität erhalten bleibt.
Beispielsweise:
1024 Dimensionen
↓
512
↓
256
Damit kann man Speicher und Suchkosten reduzieren.
Das funktioniert aber nur sinnvoll bei Modellen, die entsprechend trainiert wurden.
77. Vector Normalization
Bei manchen Modellen werden Embeddings vor dem Speichern normalisiert.
Vector
↓
L2 Normalize
↓
Vector mit Länge 1
Das kann Vergleiche vereinfachen und ist insbesondere bei Cosine- beziehungsweise Dot-Product-Suche relevant.
Ob normalisiert werden soll, hängt vom Modell ab.
78. Batch Embedding
Während der Ingestion werden häufig viele Chunks gleichzeitig eingebettet.
Statt:
Chunk 1 → Modell
Chunk 2 → Modell
Chunk 3 → Modell
verwendet man Batches:
Chunk 1
Chunk 2
Chunk 3
...
Chunk 64
↓
Embedding Model
↓
64 Vektoren
Das kann Hardware wesentlich effizienter nutzen.
79. Embedding Throughput
Für grosse Korpora ist nicht nur die Qualität des Embedding-Modells relevant.
Auch der Throughput zählt.
Beispielsweise:
Chunks pro Sekunde
Tokens pro Sekunde
Bei hundert Chunks spielt das kaum eine Rolle.
Bei Millionen Chunks bestimmt es die Dauer eines Re-Indexings.
80. Embedding Latency
Bei Queries wird normalerweise nur eine kleine Anzahl Texte eingebettet.
Hier interessiert eher die Latenz:
Query
↓
Embedding
↓
10 ms / 30 ms / 100 ms / ...
Die Query-Embedding-Latenz ist Teil der gesamten RAG-Antwortzeit.
81. Caching
Embeddings können gecacht werden.
Wenn derselbe Text bereits eingebettet wurde, muss die Berechnung nicht zwingend wiederholt werden.
Ein möglicher Schlüssel ist beispielsweise ein Hash aus:
Text
+
Embedding Model
+
Model Version
Damit wird verhindert, dass ein Cache-Eintrag eines anderen Modells verwendet wird.
82. Content Hash
Ein Content Hash ist ein Fingerabdruck des Inhalts.
Beispielsweise:
SHA-256(Text)
Ändert sich der Text nicht, bleibt der Hash gleich.
Damit können Systeme erkennen:
Dieser Chunk wurde bereits verarbeitet.
Das kann Reprocessing effizienter machen.
83. Embedding Drift
Wenn ein Modell oder seine Version verändert wird, können sich Embeddings ändern.
Dann kann ein gemischter Index entstehen:
alte Vektoren → Modell A
neue Vektoren → Modell B
Das ist problematisch.
Deshalb gehört die Embedding-Version zur Identität eines Indexes.
84. Vector Index Lifecycle
Ein Vektorindex besitzt einen Lebenszyklus:
Dokument
↓
Chunk
↓
Embedding
↓
Upsert
↓
Search
↓
Update / Delete
↓
Re-Index
RAG-Systeme müssen deshalb nicht nur suchen können.
Sie müssen auch mit verändertem Wissen umgehen.
85. Upsert
Upsert bedeutet:
Update + Insert
Existiert eine ID bereits, wird sie aktualisiert.
Existiert sie nicht, wird sie eingefügt.
Bei Vektorindizes ist das praktisch für wiederholbare Ingestion.
86. Idempotenz
Ein Ingestion-Vorgang sollte möglichst idempotent sein.
Das bedeutet:
Wird derselbe Vorgang mehrfach ausgeführt, sollte nicht jedes Mal ein weiterer identischer Chunk entstehen.
Beispiel:
Ingest document A
Ingest document A erneut
sollte nicht automatisch ergeben:
A
A
im Index.
Stabile IDs und Content Hashes helfen dabei.
87. Delete ist genauso wichtig wie Insert
Wird ein Dokument gelöscht oder ersetzt, müssen seine alten Vektoren ebenfalls entfernt werden.
Sonst entstehen Ghost Chunks.
Das Originaldokument existiert nicht mehr, aber die alte Information wird weiterhin gefunden.
Das kann besonders gefährlich bei geänderten Richtlinien sein.
88. Stale Embeddings
Stale Embeddings sind Vektoren, die nicht mehr zum aktuellen Dokumentbestand passen.
Beispiel:
Dokument 2025 gelöscht
aber
Chunks 2025 noch im Vector Store
Dann kann das RAG-System veraltete Informationen liefern.
Indexpflege ist deshalb Teil der Wissensqualität.
89. Vector Search und Filter
Eine typische Suche besteht nicht zwingend nur aus:
nearest(query_vector)
sondern beispielsweise:
nearest(query_vector)
WHERE
language = "de"
AND year = 2026
Semantische und strukturierte Suche ergänzen sich.
90. Tenant Filtering
In Mehrbenutzersystemen können Filter auch Sicherheitsgrenzen darstellen.
Konzeptionell:
Similarity Search
WHERE user_has_access = true
Ein semantisch perfekter Treffer darf nicht zurückgegeben werden, wenn der Benutzer ihn nicht sehen darf.
Retrieval-Sicherheit ist deshalb nicht nachgelagerte UI-Logik.
91. Recall
Bei ANN-Suche taucht der Begriff Recall auf.
Vereinfacht fragt Recall:
Wie viele der tatsächlich relevanten beziehungsweise richtigen Treffer wurden gefunden?
Angenommen, die exakte Suche kennt zehn relevante Nachbarn.
ANN findet neun davon.
Dann ist der Recall sehr hoch, aber nicht perfekt.
Retrieval-Metriken behandeln wir ausführlich in Teil 8.
92. ANN Recall versus RAG Recall
Hier sollte man zwei Ebenen unterscheiden.
ANN Recall
Hat die ANN-Indexstruktur die Nachbarn gefunden, die eine exakte Vektorsuche gefunden hätte?
RAG Retrieval Recall
Hat das gesamte Retrieval die tatsächlich für die Benutzerfrage relevanten Informationen gefunden?
Ein ANN-Index kann technisch nahezu perfekten Recall besitzen und trotzdem fachlich schlechte Treffer liefern, wenn das Embedding-Modell ungeeignet ist.
93. Der Index kann nicht besser sein als das Embedding
HNSW kann extrem schnell und präzise die nächsten Vektoren finden.
Wenn das Embedding-Modell aber:
"Kündigungsfrist"
und:
"Ferienanspruch"
schlecht repräsentiert, löst HNSW dieses Problem nicht.
ANN beantwortet:
Welche Vektoren liegen nahe?
Das Embedding-Modell bestimmt:
Was bedeutet „nahe“ semantisch?
Diese Ebenen müssen getrennt werden.
94. Der Embedding-Test
Eine sinnvolle Evaluation beginnt deshalb nicht erst beim vollständigen Chatbot.
Man kann direkt testen:
Query
↓
Embedding Search
↓
Top 10 Chunks
und prüfen:
Ist die relevante Passage enthalten?
Wenn nicht, braucht man das Antwort-LLM noch gar nicht zu untersuchen.
95. Semantic Search
Semantic Search bezeichnet allgemein Suche anhand von Bedeutung statt nur exakter Wortübereinstimmung.
Dense Embeddings sind eine verbreitete Umsetzung davon.
Semantic Search ist aber nicht exakt synonym mit Vector Search.
Vector Search ist ein technisches Verfahren.
Semantic Search beschreibt das Ziel beziehungsweise Suchverhalten.
96. Vector Search ist nicht automatisch semantisch
Man kann beliebige numerische Vektoren durchsuchen.
Beispielsweise:
- Bildmerkmale,
- Audiofeatures,
- Sensordaten,
- geografische Eigenschaften.
Erst ein semantisch trainiertes Text-Embedding macht Text-Vektorsuche zu semantischer Textsuche.
97. Embeddings sind keine Zusammenfassungen
Ein Embedding enthält nicht einfach einen komprimierten Text, den man später wieder dekodieren kann.
Aus:
[0.12, -0.44, ...]
kann man nicht einfach den ursprünglichen Absatz rekonstruieren.
Das Embedding ist eine Repräsentation für mathematische Aufgaben wie Ähnlichkeitsvergleich.
Der Originaltext muss separat gespeichert werden.
98. Embeddings sind keine Verschlüsselung
Auch das wird gelegentlich verwechselt.
Ein Embedding ist keine verschlüsselte Version eines Dokuments.
Es besitzt andere Eigenschaften und andere Sicherheitsrisiken.
Sensible Informationen werden nicht automatisch sicher, nur weil man ihre Embeddings speichert.
Vector Stores gehören deshalb genauso in das Sicherheitsmodell wie andere Datenspeicher.
99. Embeddings sind keine eindeutigen IDs
Ähnliche Texte erzeugen ähnliche Vektoren.
Das ist gerade der Zweck.
Ein Embedding eignet sich deshalb nicht als eindeutiger Identifikator eines Dokuments.
Dafür verwendet man IDs oder Hashes.
100. Semantische Nähe kann unerwartet sein
Embedding-Modelle bilden statistisch gelernte Bedeutungsräume.
Dadurch können Texte nahe beieinander liegen, die aus menschlicher Sicht nur indirekt verwandt sind.
Beispielsweise:
Probezeit
Kündigung
Arbeitsvertrag
Personalreglement
Das kann hilfreich sein.
Es kann aber auch zu False Positives führen.
Deshalb braucht Retrieval zusätzliche Ranking-Stufen.
101. False Positive
Ein False Positive ist ein Treffer, der vom System als relevant angesehen wird, tatsächlich aber nicht relevant ist.
Frage:
Wie lange ist die Kündigungsfrist?
Treffer:
Die Probezeit dauert drei Monate.
Thematisch nah, aber keine Antwort.
102. False Negative
Ein False Negative ist eine relevante Passage, die nicht gefunden wird.
Frage:
Wie kann ich während der Probezeit kündigen?
Relevante Passage:
Das Arbeitsverhältnis kann während der ersten drei Monate
mit einer Frist von sieben Tagen aufgelöst werden.
Wenn diese Passage nicht in den Kandidaten auftaucht, haben wir einen Retrieval-Fehler.
103. Dense Retrieval optimiert nicht automatisch Answerability
Dense Search beantwortet im Kern:
Welche Passagen sind semantisch ähnlich?
Nicht:
Welche Passage enthält garantiert die vollständige Antwort?
Diese Differenz erklärt, warum moderne RAG-Pipelines häufig mehrere Stufen besitzen:
Dense Retrieval
↓
Kandidaten
↓
Reranking
↓
Context Selection
↓
Answerability
104. Warum mehrere Retrieval-Stufen sinnvoll sind
Die erste Suchstufe muss schnell über sehr viele Chunks suchen.
Sie optimiert deshalb eher:
Recall
Eine spätere Stufe kann auf wenigen Kandidaten teurere Modelle einsetzen und stärker auf:
Precision
optimieren.
Das führt zu einer klassischen Sucharchitektur:
Candidate Retrieval
↓
Reranking
Diese Idee stammt ebenfalls aus Information Retrieval und nicht erst aus RAG.
105. Dense Retrieval als Candidate Generator
Eine gute mentale Einordnung lautet deshalb:
Dense Retrieval ist häufig ein Candidate Generator.
Es muss nicht allein die endgültige Wahrheit über Relevanz bestimmen.
Seine Aufgabe kann sein:
Millionen Chunks
↓
50 plausible Kandidaten
Danach entscheidet ein genaueres Verfahren:
50
↓
5 wirklich relevante Chunks
106. Warum ein Cross-Encoder genauer sein kann
Beim Bi-Encoder:
Query → Vector A
Chunk → Vector B
↓
Similarity
Beim Cross-Encoder:
Query + Chunk
↓
gemeinsam durch Modell
↓
Relevance Score
Der Cross-Encoder sieht die konkrete Beziehung zwischen Frage und Passage.
Dadurch kann er beispielsweise besser unterscheiden:
Frage:
Wie lange ist die Kündigungsfrist?
Passage A:
Die Kündigungsfrist beträgt sieben Tage.
Passage B:
Die Probezeit dauert drei Monate.
Beide sind thematisch ähnlich.
Nur A beantwortet die Frage.
Cross-Encoder behandeln wir ausführlich in Teil 5.
107. Warum nicht alles mit Cross-Encoder suchen?
Weil ein Cross-Encoder jedes Paar einzeln bewerten muss.
Bei:
1 Query
×
1'000'000 Chunks
wären:
1'000'000 Modellbewertungen
nötig.
Das ist teuer.
Bi-Encoder erlauben dagegen vorab berechnete Dokumentvektoren und schnelle ANN-Suche.
Deshalb:
Bi-Encoder
→ schnell Kandidaten finden
Cross-Encoder
→ wenige Kandidaten genauer bewerten
108. Embedding Search als zweistufiges System
Ein typischer Ablauf lautet deshalb:
Dokumente
↓
Embeddings
↓
Vector Index
Query
↓
Query Embedding
↓
ANN Search
↓
Top 50
↓
Reranker
↓
Top 5
Das ist bereits wesentlich robuster als:
Top 5 Vector Search
→ direkt in Prompt
109. Aber Dense Search ist nur die halbe Geschichte
Wir haben bisher semantische Suche betrachtet.
Nun kommt das Problem:
Ein Benutzer fragt:
Was steht zu CVE-2026-12345?
oder:
Was bedeutet Artikel 17.4?
oder:
Wie ist der Status von AB-84921?
Hier sind exakte Tokens extrem wichtig.
Dense Search kann sie berücksichtigen, aber klassische lexikalische Retrieval-Verfahren besitzen hier einen strukturellen Vorteil.
Deshalb benötigt man den zweiten grossen Suchraum:
Sparse Retrieval.
110. Dense und Sparse als unterschiedliche Stärken
Vereinfacht:
Dense
→ Bedeutung
Sparse
→ Wörter
Dense findet:
Vertrag beenden
≈
kündigen
Sparse findet:
INC-847291
=
INC-847291
Die stärkste Retrieval-Pipeline muss sich häufig nicht zwischen beiden entscheiden.
Sie kombiniert beide.
111. Warum Vector Search RAG nicht definiert
Nach diesem Teil sollte eine wichtige Abgrenzung klar sein.
RAG bedeutet nicht:
Embedding
+
Vector Database
+
LLM
Das ist lediglich eine verbreitete RAG-Implementierung.
RAG verlangt konzeptionell:
Retrieval
+
Augmentation
+
Generation
Das Retrieval könnte:
Dense
Sparse
SQL
Graph
Web Search
Hybrid
sein.
Embeddings sind ein Werkzeug innerhalb dieser grösseren Idee.
112. Begriffspaare, die man nicht verwechseln sollte
| Begriffe | Unterschied |
|---|---|
| Embedding vs. Vector | Embedding ist eine gelernte Repräsentation; technisch wird sie als Vektor dargestellt |
| Embedding-Modell vs. LLM | Embedding-Modell erzeugt Repräsentationen; LLM erzeugt Sprache |
| Dense vs. Sparse | dichte semantische Repräsentation vs. dünn besetzte lexikalische Repräsentation |
| Similarity vs. Relevance | mathematische Nähe vs. tatsächliche Relevanz zur Frage |
| Cosine vs. L2 | Winkelähnlichkeit vs. geometrischer Abstand |
| Vector Store vs. RAG | Speicher-/Suchkomponente vs. vollständiges Retrieval-Generation-Verfahren |
| Semantic Search vs. Vector Search | Suchziel nach Bedeutung vs. technisches Suchen in Vektoren |
| Bi-Encoder vs. Cross-Encoder | getrennte vs. gemeinsame Verarbeitung von Query und Passage |
| ANN vs. HNSW | Problemklasse/Verfahren vs. konkrete ANN-Indexfamilie |
| Top-k vs. Prompt-k | Retrieval-Kandidaten vs. tatsächlich an das LLM gegebene Chunks |
| Index-Quantisierung vs. LLM-Quantisierung | Kompression von Suchvektoren vs. Kompression von Modellgewichten |
| Embedding Dimension vs. Qualität | Vektorgrösse vs. Retrieval-Leistung |
| Document Embedding vs. Chunk Embedding | ganzes Dokument vs. kleinere Retrieval-Einheit |
| Embedding vs. Hash | semantische Repräsentation vs. Identitätsfingerabdruck |
| Embedding vs. Verschlüsselung | Ähnlichkeitsrepräsentation vs. Schutz vertraulicher Daten |
113. Die vollständige Dense-Retrieval-Pipeline
Wir können Teil 2 und Teil 3 jetzt zusammenführen.
Ingestion
Dokument
↓
Parsing
↓
Struktur
↓
Chunking
↓
Chunk
↓
Embedding Model
↓
Dense Vector
↓
Vector Index
Query
Benutzerfrage
↓
Embedding Model
↓
Query Vector
↓
ANN Search
↓
Similarity Ranking
↓
Top-k Chunks
Zusammen:
INGESTION
Dokumente
↓
Parsing
↓
Chunking
↓
Chunks
↓
Embedding
↓
Vektoren
↓
Vector Index
▲
│
│ ANN / Similarity Search
│
Query Vector
▲
│
Embedding
▲
│
Benutzerfrage
114. Was diese Pipeline gut kann
Dense Retrieval ist besonders stark, wenn:
- Benutzer natürlich formulieren,
- Dokument und Frage unterschiedliche Wörter verwenden,
- Synonyme auftreten,
- Paraphrasen erkannt werden müssen,
- semantische Nähe wichtiger ist als exakte Wortgleichheit.
Beispiel:
Query:
Wie verlasse ich die Firma während der Probezeit?
Passage:
Das Arbeitsverhältnis kann während der Probezeit
mit einer Frist von sieben Tagen gekündigt werden.
Das ist genau die Art von Problem, bei der Embeddings ihre Stärke zeigen.
115. Was diese Pipeline nicht zuverlässig löst
Dense Retrieval allein löst nicht automatisch:
- exakte Identifier,
- seltene Eigennamen,
- Versionsnummern,
- Paragraphennummern,
- präzise Zahlen,
- semantisch sehr ähnliche, aber fachlich unterschiedliche Dokumente,
- vollständige Answerability,
- Quellenwidersprüche,
- Halluzinationen.
Dafür benötigt man weitere Retrieval- und Generationstechniken.
116. Die wichtigste Erkenntnis aus Teil 3
Embeddings lösen ein fundamentales Problem:
Sie ermöglichen, Bedeutung mathematisch vergleichbar zu machen.
Dadurch wird aus:
Text
eine numerische Repräsentation:
Vector
und aus einer semantischen Suche ein mathematisches Nachbarschaftsproblem:
Query
↓
Embedding
↓
Query Vector
↓
Nearest Neighbors
↓
semantisch ähnliche Chunks
Aber genau hier liegt auch die Grenze.
Semantisch ähnlich bedeutet nicht automatisch relevant.
Relevant bedeutet nicht automatisch beantwortbar.
Und Vektorsuche bedeutet nicht automatisch gutes RAG.
Dense Retrieval ist deshalb eine starke erste Suchstufe, aber nicht die gesamte Retrieval-Lösung.
Die nächste Frage lautet:
Was passiert, wenn nicht die Bedeutung, sondern ein exaktes Wort, eine ID, ein Paragraph oder eine seltene Bezeichnung entscheidend ist?
Dann betreten wir die klassische Welt des Information Retrieval:
Term Frequency, Inverse Document Frequency, TF-IDF, BM25 und Sparse Retrieval.
Und danach können beide Welten zusammengeführt werden:
Dense Retrieval
+
Sparse Retrieval
↓
Hybrid Search
↓
RRF
Genau darum geht es in Teil 4.
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, Vector Stores, ANN, HNSW, IVF, Quantisierung und die Grenzen semantischer Suche.
Teil 4 – Information Retrieval und Hybrid Search
Term Frequency, IDF, TF-IDF, BM25, Sparse Retrieval, Dense vs. Sparse, Hybrid Search und Reciprocal Rank Fusion.
Teil 5 – Reranking und Retrieval-Strategien
Top-k, Cross-Encoder, MMR, Query Rewrite, Multi-Query, HyDE und Context Selection.
Teil 6 – Kontext, Grounding und Antworten
Kontextfenster, Token-Budget, Lost in the Middle, Answerability, Faithfulness, Citations und Grounding.
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.