🧠 Page 08 von 8 · ~30 Min · Final

Embeddings & RAG – die KI-Ära der Suche 🧠

Was passiert, wenn du Wörter nicht mehr als Buchstaben, sondern als Punkte im 768-dimensionalen Raum behandelst? Du bekommst semantisches Verstehen. In dieser Final-Page: Embeddings, Vektor-Datenbanken, Hybrid Retrieval – und wie RAG moderne KI-Suche orchestriert.

🧬 Embeddings 🗄 Vector DBs 🔀 Hybrid Search 🤖 RAG

01Was ist ein Embedding?

Ein Wort, ein Satz, ein ganzes Dokument – als Liste von ~768 Zahlen.

Ein Embedding ist ein Vektor (typisch 384, 768 oder 1536 Dimensionen), der die Bedeutung eines Textstücks kodiert. Der Trick: ähnliche Texte → ähnliche Vektoren. Verschiedene Texte → entfernte Vektoren.

EMBEDDING
# Vereinfacht (ein echter Vektor hat 768 Dimensionen):
embed("Roboter")   = [0.12, -0.34, 0.81, 0.05, ...]
embed("Maschine")  = [0.14, -0.30, 0.77, 0.08, ...]   # sehr ähnlich
embed("Pizza")     = [-0.65, 0.22, -0.43, 0.91, ...]   # völlig anders
    

Wo kommen Embeddings her?

Aus einem trainierten Encoder-Modell – typisch ein BERT-/Transformer-Modell. Beispiele:

Modell	Dimensionen	Bemerkung
OpenAI `text-embedding-3-small`	1536	API, leistungsstark, kostenpflichtig
Cohere `embed-v3`	1024	Multi-Sprache, gute Mid-Range
sentence-transformers `all-MiniLM-L6-v2`	384	Open-Source, läuft lokal, sehr schnell
BGE / GTE (Hugging Face)	768-1024	Aktuelle SOTA Open-Source Modelle

🧬

Magisch ist: Diese Modelle wurden auf riesigen Textmengen trainiert (Wikipedia, Web, Bücher). Sie haben dabei von selbst gelernt, dass „Auto" und „PKW" das Gleiche bedeuten. Ohne Wörterbuch. Aus reinem Lesen.

02Ähnlichkeit im Vektorraum

Genau die gleiche Cosine-Similarity wie bei TF-IDF – aber auf semantischen Vektoren.

similarity(a, b) = cos(a, b) = ( a · b ) / ( ||a|| × ||b|| )

Konkret: Du embeddest deine Suchanfrage in einen Vektor. Du embeddest alle Dokumente in Vektoren (das ist die teure Vorarbeit). Bei der Suche → Cosine-Similarity zwischen Query und allen Doc-Vektoren. Top-K als Treffer.

Aber: 100 Mio Vektoren? Linear vergleichen?

Naiv wäre das O(N) pro Anfrage – bei Millionen Docs zu langsam. Die Lösung: ANN-Algorithmen (Approximate Nearest Neighbor).

HNSW (Hierarchical Navigable Small World) – Graph-basiert, Lucene/Elastic-Standard
IVF (Inverted File) + PQ (Product Quantization) – FAISS-Standard
Liefert ~95% genaue Top-K-Treffer in logarithmischer Zeit

03Vektor-Datenbanken

Spezialisierte Datenbanken, die nichts anderes machen als Vektoren speichern und durchsuchen.

🦋 Pinecone

Managed Cloud, einfach zu starten. Bezahlt. Standard für viele AI-Startups.

POST /vectors/upsert

🐘 Weaviate

Open-Source, modular, GraphQL-API. Hybrid built-in (BM25 + Vector).

docker run weaviate

🌶 Chroma

Sehr leichtgewichtig, lokal, Python-friendly. Perfekt zum Lernen / Prototypen.

pip install chromadb

⚡ FAISS

Meta's Library, Embedded (keine DB), super-schnell. Pure C++/Python.

pip install faiss-cpu

🐳 Qdrant

Rust-basiert, sehr performant, Open-Source. Aufstrebende Wahl 2024+.

docker run qdrant

📚 Elasticsearch / OpenSearch

Bereits etablierte Such-Engines, mittlerweile mit Vector-Support (HNSW).

"type": "dense_vector"

🔄

Trend 2025/26: Klassische Such-Engines (Elastic, Postgres mit pgvector) integrieren Vektor-Support direkt. Reine Vector-DBs werden zunehmend zu „Hybrid-Suchmaschinen". Die Grenze verschwimmt.

04Hybrid Retrieval – das Beste aus zwei Welten

BM25 + Embeddings parallel laufen lassen, Ergebnisse fusionieren.

🔤 Sparse (BM25)

Exakte Wort-Matches
Sehr schnell
Sehr erklärbar („Wort kommt 3x vor")
Top bei IDs, Codes, Namen
Versteht keine Synonyme

🧠 Dense (Embeddings)

Semantische Matches (Synonyme, Paraphrasen)
Langsamer (teurer pro Query)
Weniger erklärbar
Top bei natürlichsprachigen Queries
Kann exakte Strings übersehen

Reciprocal Rank Fusion (RRF)

Wie kombiniert man die zwei Ranglisten? Die einfachste & populärste Methode: RRF.

RRF(d) = Σ 1 / (k + rank_i(d)) k ≈ 60 (Konstante). rank_i = Position des Docs in Liste i. Niedriger Rang = höherer RRF-Score.

Genial: RRF braucht keine Score-Normalisierung. Es zählt nur die Position. Funktioniert quer über völlig unterschiedliche Ranker.

05RAG – Retrieval-Augmented Generation

Die Architektur, die hinter Perplexity, ChatGPT-Search, Claude-Search steckt.

Das Problem: Ein LLM wie GPT-4 oder Claude weiss viel, aber:

Wissen ist „eingefroren" zum Trainings-Zeitpunkt
Es kann halluzinieren (Sachen erfinden)
Es kennt deine privaten Dokumente nicht

Die Lösung – RAG: Bevor das LLM antwortet, holt ein Retriever relevante Dokumente aus einer Knowledge-Base. Das LLM bekommt die Docs als „Kontext" – und antwortet darauf basierend.

RAG-Pipeline in 5 Schritten

Indexing (einmalig): Alle Docs in Chunks zerlegen → embedden → in Vector DB speichern.
Query Embedding: User-Frage embedden.
Retrieval: Top-K Chunks aus Vector DB (oder hybrid mit BM25).
(Optional) Re-Ranking: Ein zweites Modell ordnet die Top-K nochmals neu.
Generation: LLM bekommt Query + relevante Chunks als Prompt, antwortet darauf basierend, zitiert Quellen.

🎯

Warum das so wichtig ist: Mit RAG kann ein LLM deine Dokumente abfragen – Lunolabs-Knowledge-Base, Firmen-Wiki, eigene PDFs. Ohne Re-Training. Das ist die Standard-Architektur für KI-Apps 2024+.

06Das Chunking-Problem

Embeddings funktionieren am besten auf kurzen Textstücken. Wie zerlegt man ein Dokument richtig?

Ein Embedding-Modell hat eine maximale Input-Länge (z.B. 512 Tokens). Bei langen Docs muss man chunken – aber gut. Schlechte Chunks = schlechte Suche.

Fixed-Size Chunking: alle 500 Wörter ein Chunk. Einfach, aber zerreisst Sätze/Konzepte.
Sentence/Paragraph Chunking: an natürlichen Grenzen schneiden. Besser.
Overlap: Chunks um z.B. 50 Wörter überlappen lassen → weniger „verloren" zwischen Chunks.
Semantic Chunking: mit einem Modell schneiden, wo Themenwechsel sind. State-of-the-art.

07Grenzen & was als nächstes kommt

Embeddings sind mächtig – aber kein Allheilmittel.

Wo Embeddings schwächeln:

Exakte Matches: Wenn jemand "FA-3215-Z" sucht, ist BM25 zuverlässiger.
Negative Logik: „Roboter ohne Sensoren" → Embedding mag „Roboter mit Sensoren" trotzdem.
Aktuelle / dynamische Daten: Re-Embedding ist teuer. Inkrementelle Updates sind kompliziert.
Multi-Hop-Fragen: „Wer ist der Trainer des Spielers, der gegen X gewann?" – ein einzelner Retrieval-Step reicht nicht.

Aktuelle Trends:

Agentic Retrieval: LLM entscheidet selbst, was es noch suchen muss (mehrere Hops)
Long-Context Models: Modelle mit 1M Token Context – manchmal kein RAG mehr nötig
ColBERT / Late Interaction: Hybride aus Sparse & Dense, sehr genau
Multi-Modal Embeddings: Text + Bild + Audio im gleichen Vektorraum (CLIP & Co.)

🎯Key Takeaways

Embeddings sind Vektoren (typisch 768 Dim) mit semantischer Bedeutung – ähnliche Texte → ähnliche Vektoren.
Sie kommen aus trainierten Transformer-Encodern (BERT, MiniLM, BGE …).
Vektor-Datenbanken (Pinecone, Weaviate, Chroma, FAISS) speichern Millionen Embeddings effizient.
ANN-Algorithmen (HNSW, IVF+PQ) machen Suche in Mrd. Vektoren in ms möglich.
Hybrid Retrieval (BM25 + Embeddings + RRF) ist die State-of-the-Art-Lösung.
RAG (Retrieval-Augmented Generation) lässt LLMs auf deinen Daten antworten – ohne Re-Training.
Chunking ist wichtiger als die meisten denken – schlecht gechunkte Docs = schlechte Antworten.
Die Zukunft: Agentic Retrieval, Long-Context-Modelle, Multi-Modal Embeddings.

Geschafft! 🎉

Du hast jetzt verstanden: vom Kabel im Boden bis zur KI-Suche, die Llama, ChatGPT & Claude im Hintergrund benutzen. Das ist Wissen, das vor 5 Jahren nur Industrie-Insider hatten.

→ Zurück zum Hub