Embeddings – Was du jetzt wissen musst

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 als Googles 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.

Stand: Mai 2026. Modellnamen, Preise und Verfügbarkeiten in diesem Feld ändern sich schnell; prüfe vor einer Entscheidung die aktuellen Angaben des jeweiligen Anbieters.

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 die Retrieval-Qualität deutlich verbessern.

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:

1. Dokumente werden in Chunks aufgeteilt und mit einem Embedding-Modell in Vektoren überführt.
2. Diese Vektoren werden in einer Vektordatenbank gespeichert (Qdrant, Weaviate, Pinecone, pgvector).
3. Bei einer Nutzeranfrage wird die Anfrage ebenfalls eingebettet.
4. Die ähnlichsten Chunks werden per Nearest-Neighbour-Suche gefunden.
5. 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:

System	Profil
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.

Datenschutz: Wo die Vektoren liegen

Sobald du interne oder personenbezogene Dokumente einbettest, wird der Speicherort der Vektordatenbank zur Datenschutzfrage. In der Schweiz gilt das revidierte Datenschutzgesetz (revDSG), in Deutschland und der EU die DSGVO ergänzt durch das BDSG, in Österreich die DSGVO ergänzt durch das DSG. Wer Vektoren bei einem reinen Managed-Dienst ohne Standortwahl ablegt, verlagert die Daten unter Umständen in ein Drittland; ein selbst betriebenes System behält sie im eigenen Rechenzentrum. Prüfe das früh, nicht erst nach dem Proof of Concept. Eine Einordnung findest du unter Datenschutz. Das ist eine Orientierung, keine Rechtsberatung.

Häufige Fehler in Embedding-Projekten

Vier Fehler tauchen in Embedding-Projekten immer wieder auf:

• Kein Evaluation-Set: Ohne eine Testmenge aus echten Anfragen und erwarteten Treffern lässt sich Retrieval-Qualität nicht messen. Was nicht gemessen wird, wird auch nicht besser.
• Falsche Chunk-Grösse: Zu kleine Chunks verlieren Kontext, zu grosse senken die Präzision. Ohne Experiment auf den eigenen Dokumenten bleibt die Wahl Raten.
• Allgemeines Modell für eine Spezial-Domäne: Ein auf Web-Texten trainiertes Modell kennt deinen Fachjargon nicht. Domain-Fine-Tuning oder zumindest eine Evaluation auf eigenen Daten ist Pflicht.
• Dimensionalität blind maximieren: Mehr Dimensionen bedeuten mehr Speicher und Rechenzeit. Mit Matryoshka-Modellen lässt sich die kleinere Variante nutzen, wo die Präzision es zulässt.

Embeddings sind die unscheinbare Schicht, auf der Suche, RAG und semantische Analyse aufbauen. Wer die vier Punkte oben von Anfang an mitdenkt, spart sich später teure Nachbesserungen und baut nicht auf Sand.

Mehr Grundlagen im Überblick: KI-Grundlagen.