Table of Contents

Embeddings verstehen: Warum Vektoren die Grundlage moderner KI-Anwendungen sind

Wer KI-Systeme baut, ohne Embeddings zu verstehen, baut auf Sand.

Embeddings sind keine neue Idee – Word2Vec erschien bereits 2013 – aber sie erleben gerade eine zweite Hochphase. Gemini Embedding 2, Anfang 2026 von Google als erstes nativ multimodales Embedding-Modell veröffentlicht, zeigt, wie weit das Feld in kurzer Zeit gekommen ist. Für IT-Professionals und Business Analysten, die KI-Projekte evaluieren oder umsetzen, ist ein solides Grundverständnis von Embeddings heute keine Kür mehr, sondern Pflicht.

Dieser Artikel erklärt, wie Embeddings funktionieren, wo sie konkret eingesetzt werden, und welche technischen Entscheidungen in der Praxis wirklich zählen.

Was Embeddings eigentlich sind – ohne Mystik

Ein Embedding übersetzt diskrete Objekte – Wörter, Sätze, Bilder, Audio – in Vektoren aus Gleitkommazahlen. Ein Satz wie „Lieferverzögerung bei Bestellung 4711“ wird zu einem Vektor mit mehreren hundert oder tausend Dimensionen. Der entscheidende Punkt: Ähnliche Bedeutungen landen im Vektorraum nahe beieinander. Geometrische Nähe entspricht semantischer Ähnlichkeit.

Das klingt abstrakt, hat aber konkrete Konsequenzen. Eine Suchanfrage nach „Paketproblem“ findet damit auch Dokumente, die „Lieferverzögerung“ oder „Sendungsfehler“ enthalten – obwohl diese Begriffe keine gemeinsamen Zeichen haben. Klassische Keyword-Suche scheitert hier, Embeddings nicht.

Die Dimensionalität eines Embedding-Vektors bestimmt, wie viel semantische Nuance er kodieren kann. Ältere Modelle arbeiteten mit 256 oder 512 Dimensionen. Aktuelle Modelle wie Gemini Embedding 2 erzeugen standardmässig 3.072-dimensionale Vektoren. Das erhöht die Präzision, kostet aber Speicher und Rechenzeit – ein Trade-off, der in jedem Projekt bewusst adressiert werden muss.

Wie Embedding-Modelle trainiert werden

Embedding-Modelle lernen durch Kontrastlernen: Ähnliche Paare (Frage + passende Antwort, Bild + Beschreibung) werden im Vektorraum angenähert, unähnliche Paare abgestossen. Das Ergebnis ist ein Modell, das generalisierbares semantisches Wissen enkodiert.

Wichtig für die Praxis: Ein allgemeines Embedding-Modell, das auf Wikipedia und Web-Texten trainiert wurde, versteht allgemeine Sprache gut. Es versteht aber nicht zwingend, dass „Churn“ in deinem Unternehmenskontext Kundenverlust bedeutet oder dass „Position“ in deiner Datenbank eine Lagerposition ist. Domain-spezifisches Fine-Tuning – also das Nachtrainieren auf eigenen Daten – kann hier 10 bis 30 Prozent bessere Retrieval-Qualität bringen.

Bi-Encoder vs. Cross-Encoder

Für Suchsysteme relevanter Unterschied: Bi-Encoder berechnen Embeddings für Query und Dokument getrennt und messen dann den Abstand. Das ist schnell und skaliert auf Millionen von Dokumenten. Cross-Encoder vergleichen Query und Dokument gemeinsam und sind deutlich genauer, aber langsam – zu langsam für Live-Suche über grosse Korpora.

Die Standardarchitektur in produktiven Systemen kombiniert beides: Bi-Encoder für die erste Selektion (Top-100), Cross-Encoder für das Re-Ranking der Finalliste.

Retrieval-Augmented Generation: Der häufigste Use-Case

Der meistgenannte Einsatzbereich für Embeddings heute ist RAG – Retrieval-Augmented Generation. Das Prinzip: Statt alle Unternehmensdokumente in den Kontext eines Sprachmodells zu laden (was bei GPT-4 und 100.000 Seiten schlicht nicht funktioniert), werden nur die relevantesten Passagen zur jeweiligen Anfrage abgerufen.

Der technische Ablauf ist überschaubar:

Dokumente werden in Chunks aufgeteilt und mit einem Embedding-Modell in Vektoren überführt.
Diese Vektoren werden in einer Vektordatenbank gespeichert (Qdrant, Weaviate, Pinecone, pgvector).
Bei einer Nutzeranfrage wird die Anfrage ebenfalls eingebettet.
Die ähnlichsten Chunks werden per Nearest-Neighbour-Suche gefunden.
Diese Chunks werden dem Sprachmodell als Kontext übergeben.

Ein mittelgrosses Unternehmen mit 50.000 internen Dokumenten kann so ein internes FAQ-System bauen, das tatsächlich korrekte Antworten liefert – statt Halluzinationen. Der Aufwand für einen Proof of Concept liegt realistisch bei zwei bis vier Wochen für ein erfahrenes Team.

Chunk-Grösse ist unterschätzter Hebel

Ein Detail, das in vielen Projekten zu wenig Aufmerksamkeit bekommt: die Chunk-Grösse. Zu kleine Chunks verlieren Kontext, zu grosse verringern die Retrieval-Präzision. 300 bis 500 Tokens pro Chunk mit 10 bis 20 Prozent Überlappung ist ein bewährter Startpunkt. Experimentieren und messen ist Pflicht – die optimale Grösse ist dokumenttyp- und anwendungsabhängig.

Multimodale Embeddings: Was Gemini Embedding 2 verändert

Bisherige Embedding-Modelle waren monomodal: Text-Embeddings für Text, CLIP für Bild-Text-Paare, separate Modelle für Audio. Das erzeugt ein strukturelles Problem: Wenn du Schulungsvideos, PDF-Anleitungen und Datenbanken durchsuchen willst, brauchst du mehrere Modelle mit inkompatiblen Vektorräumen.

Gemini Embedding 2 löst das anders. Es erzeugt Text-, Bild-, Video-, Audio- und Dokument-Embeddings im selben Vektorraum. Eine Textanfrage kann direkt relevante Videoclips finden. Qdrant hat dafür bereits native Unterstützung angekündigt, sodass alle Medien-Typen in einer einzigen Collection gespeichert werden können.

Das vereinfacht die Systemarchitektur erheblich. Statt drei Indizes zu pflegen und Ergebnisse zu fusionieren, gibt es einen einzigen Vektor-Index für alle Medientypen. Für Unternehmen mit gemischten Dokumententypen – was praktisch alle sind – ist das ein architektonisch relevanter Fortschritt.

Matryoshka Representation Learning: Flexibilität ohne Qualitätsverlust

Ein weiteres technisches Merkmal von Gemini Embedding 2 ist Matryoshka Representation Learning (MRL). Das Modell erzeugt 3.072-dimensionale Vektoren, die sich verlustarm auf 1.536 oder 768 Dimensionen kürzen lassen.

Warum relevant? Speicher- und Rechenkosten für Vektordatenbanken skalieren direkt mit der Dimensionalität. 768-dimensionale Vektoren brauchen nur 25 Prozent des Speichers im Vergleich zu 3.072-dimensionalen. MRL erlaubt es, bei weniger kritischen Anwendungen die kleinere Variante zu nutzen – ohne ein separates Modell trainieren zu müssen. Das ist ein sinnvoller Kompromiss für grosse Deployments.

Vektordatenbanken: Die Infrastrukturseite

Embeddings alleine nützen nichts ohne passende Infrastruktur. Vektordatenbanken speichern nicht nur Vektoren, sondern bieten auch approximative Nearest-Neighbour-Suche (ANN) in Millisekunden – auch über Millionen von Vektoren.

Die relevanten Optionen im DACH-Kontext:

Qdrant: Open-Source, in Rust geschrieben, sehr performant, On-Premises-Deployment möglich. Gut für Unternehmen mit Datenschutzanforderungen.
Weaviate: Ebenfalls Open-Source, GraphQL-API, gute Integration in bestehende Stacks.
pgvector: Postgres-Extension. Wenn du bereits Postgres betreibst, ist das der einfachste Einstieg – mit Einschränkungen bei sehr grossen Datensätzen.
Pinecone: Managed Service, niedrige Einstiegshürde, aber kein On-Premises.

Für produktive Systeme mit mehr als 1 Million Vektoren und Latenzanforderungen unter 100 ms empfiehlt sich ein dediziertes System wie Qdrant oder Weaviate. Für Prototypen und kleinere Korpora reicht pgvector vollständig aus.

Häufige Fehler in Embedding-Projekten

**Kein Evaluation-Set

Embeddings — Was du jetzt wissen musst