Embeddings und Vector Databases: Das Fundament moderner KI-Suche

Wer im Jahr 2026 ein produktives KI-System baut, kommt an Embeddings und Vector Databases nicht vorbei. Sie sind das unsichtbare Fundament, auf dem RAG, semantische Suche, Empfehlungssysteme und Wissenshubs aufbauen. Wer sie nicht beherrscht, baut Systeme, die wie Demos aussehen, aber im Produktivbetrieb scheitern. Dieser Beitrag erklärt die Bausteine — von Embedding-Modellen über Chunking bis zu Indizes und Hybrid Search.

1. Was sind Embeddings?

Ein Embedding ist eine numerische Repräsentation von Bedeutung. Konkret: ein Vektor mit typisch 512 bis 4.096 Zahlen, der einen Text, ein Bild oder eine andere Eingabe in einem hochdimensionalen Raum verortet. Inhalte mit ähnlicher Bedeutung liegen in diesem Raum nahe beieinander; sehr unterschiedliche Inhalte weit entfernt.

Praktische Konsequenz: Ähnlichkeit zwischen Inhalten lässt sich als Distanz zwischen Vektoren berechnen. Cosinus-Ähnlichkeit (1 = identisch, 0 = unverwandt) ist die übliche Metrik. Damit funktioniert Suche, die nicht auf exakter Wortübereinstimmung beruht — sondern auf semantischer Nähe.

Beispiel: Eine Suche nach „Auto reparieren” findet auch Texte über „Fahrzeug instandsetzen”, obwohl kein Wort übereinstimmt. Das ist der Mehrwert von Embedding-Suche gegenüber klassischer Volltextsuche.

2. Embedding-Modelle 2026

Embedding-Modelle sind in den letzten Jahren stark spezialisiert worden. 2026 sind diese Familien relevant:

• Multilingual: bge-m3, jina-embeddings-v3, Cohere Embed. Solide Qualität für deutsch, englisch, romanische Sprachen. bge-m3 ist Open-Weight und unterstützt zudem sparse plus multi-vector Modi.
• Englisch-fokussiert: OpenAI text-embedding-3, Voyage AI, e5-Mistral. Höhere Präzision auf englischen Texten, aber für deutsche Inhalte oft unterlegen.
• Domain-spezialisiert. Code, Recht, Medizin, Finanzwesen — spezialisierte Embeddings übertreffen generische Modelle in ihrer Nische deutlich. Für sensible Domänen ist Fine-Tuning eines Embedding-Modells auf eigenen Daten oft sinnvoll.

Wichtige Achse: Dimensionalität. Kleinere Embeddings (256–768 Dimensionen) sind günstiger zu speichern und zu suchen. Größere (1.024–4.096) sind oft präziser. Moderne Modelle unterstützen Matryoshka Representation Learning — ein einzelnes Embedding lässt sich auf verschiedene Dimensionen verkürzen, ohne neu zu rechnen.

3. Chunking — die unterschätzte Disziplin

Ein Embedding kann nur so gut sein wie die Eingabe. Wer ein 100-Seiten-PDF als ein Embedding speichert, verliert Granularität. Wer pro Satz ein Embedding speichert, verliert Kontext. Chunking — das Aufteilen von Dokumenten in semantisch sinnvolle Einheiten — ist die unterschätzteste Disziplin in RAG.

Bewährte Strategien:

• Fixed-Size Chunking. Einfach: alle 500 Tokens schneiden. Robust, aber blind für Sinnabschnitte.
• Semantic Chunking. Schnitte an Satz- oder Absatzgrenzen. Besser, etwas aufwändiger.
• Recursive Chunking. Hierarchische Strategie: zuerst nach Sektionen, dann Absätzen, dann Sätzen.
• Document-aware Chunking. Berücksichtigt Struktur (Überschriften, Listen, Tabellen). Beste Qualität, höchster Aufwand.

Überlapp zwischen Chunks (10–20%) sichert, dass zusammenhängende Aussagen nicht durch Schnitte zerrissen werden. Die Chunking-Strategie wirkt sich oft stärker auf die RAG-Qualität aus als die Wahl des Embedding-Modells.

4. Vector Databases im Überblick

Eine Vector Database speichert Vektoren plus zugehörige Metadaten und ermöglicht effiziente Ähnlichkeitssuche. 2026 sind diese Optionen produktiv relevant:

• pgvector. PostgreSQL-Extension. Größter Vorteil: Lebt im selben Stack wie der Rest der Anwendung. Solide Performance bis in den zweistelligen Millionenbereich an Vektoren. Beste Wahl für viele Unternehmen.
• Qdrant. Open-Source, Rust-basiert, sehr performant. Lokal oder als Cloud verfügbar. Starke Filter-API.
• Weaviate. Open-Source mit GraphQL-Interface und integrierten Modulen für Reranking. Etwas anspruchsvoller im Betrieb.
• Milvus. Skaliert auf Milliarden Vektoren. Für sehr große Setups.
• Pinecone, MongoDB Atlas Vector Search. Managed Services. Schnell startbar, Vendor-Lock-in-Risiko.

Für die meisten Mittelstandsanwendungen ist pgvector der pragmatische Einstieg. Für sehr große Indizes oder spezifische Performance-Anforderungen lohnt Qdrant oder Milvus.

5. ANN-Indizes: HNSW, IVF, ScaNN

Eine naive Suche über Millionen Vektoren ist zu langsam. Vector Databases nutzen Approximate Nearest Neighbor-Indizes (ANN), die schnelle Antworten liefern, indem sie auf perfekte Genauigkeit verzichten — typischerweise erreichen sie 95–99% Recall der echten Top-K.

Wichtige Indizes:

• HNSW (Hierarchical Navigable Small World). Standard für mittelgroße bis große Indizes. Sehr schnell, gute Qualität, höherer Speicherbedarf.
• IVF (Inverted File Index). Cluster-basiert. Gut für sehr große Indizes, etwas langsamer als HNSW.
• ScaNN, FAISS, DiskANN. Spezialisierte Indizes für bestimmte Workloads (Disk-basiert, sehr hochdimensional).

Wichtige Hyperparameter (am Beispiel HNSW): M (Verbindungsgrad), ef_construction (Aufbauqualität), ef_search (Suchqualität). Die Defaults der meisten Datenbanken sind brauchbar; Tuning lohnt erst bei Performance-Engpässen.

6. Metadaten-Filter und Hybrid Search

Reine Embedding-Suche ist selten genug. Produktive Setups kombinieren:

• Metadaten-Filter. Nur Vektoren, die einer SQL-artigen Bedingung entsprechen (Sprache, Datum, Quelle, Tags). Vector Databases unterstützen das nativ.
• Hybrid Search. Kombination aus dichter Suche (Embeddings) und Sparse Search (BM25, Volltext). Fängt sowohl semantische Ähnlichkeit als auch exakte Begriffe ab.
• Reranking. Nach der initialen Suche wird die Top-100 mit einem stärkeren Cross-Encoder-Modell neu sortiert. Sehr effektiv für Präzision.

Diese drei Techniken zusammen erzielen in Enterprise-RAG eine deutlich bessere Antwortqualität als reines Vector-Search. Vertiefung in Hybrid Search, Reranking und GraphRAG.

7. Praxis: Was wirklich zählt

Aus über 30 RAG-Projekten kristallisieren sich diese Prioritäten heraus:

1. Datenqualität. Schlechte Quellen produzieren schlechte Antworten. Bereinigung, Dedupe, Versionierung sind die unsichtbare Hauptarbeit.
2. Chunking-Strategie. Wichtiger als das Embedding-Modell. Investieren Sie Zeit darin.
3. Hybrid Search von Anfang an. Reine Vector-Search reicht selten.
4. Reranking, wenn Qualität nicht reicht. Cross-Encoder-Reranker geben den letzten Präzisionsschub.
5. Eval-Suite. Realistische Testfragen mit erwarteten Quellen. Ohne Eval ist Optimierung Bauchgefühl. Details in Guardrails, Evals und Prompt Injection.
6. Embedding-Drift überwachen. Ein Modellwechsel macht alle alten Embeddings unbrauchbar. Strategie für Re-Indizierung von Anfang an mitdenken.

Embeddings und Vector Databases sind 2026 das Grundwerkzeug jeder produktiven KI-Anwendung mit Bezug auf eigene Daten. Wer sie sauber aufsetzt, hat ein System, das mit den eigenen Inhalten wächst, in der eigenen Infrastruktur läuft und sich kontinuierlich verbessert. Wer sie als technische Nebensache behandelt, bekommt einen Chatbot, der freundlich aber falsch antwortet. Der Unterschied liegt fast nie im LLM — sondern in dem, was vor dem LLM passiert.