Embedding Models

Embedding Models übersetzen Text, Bilder oder Audio in Zahlenreihen (sogenannte Vektoren). Inhaltlich ähnliche Eingaben bekommen ähnliche Zahlenreihen. Dieser Trick macht semantische Suche (Suche nach Bedeutung statt nach Wortgleichheit) und Retrieval-Augmented Generation (RAG, „Antworten aus eigenen Dokumenten") möglich.

Was ist ein Embedding Model?

Ein Embedding Model ist ein trainiertes Modell, das eine Eingabe wie Text, Bild, Audio oder Code in eine feste Reihe von Zahlen (Vektor) umwandelt. Der Vektor ist typischerweise 384 bis 4.096 Zahlen lang. Der Kern-Effekt: Zwei inhaltlich verwandte Eingaben (etwa eine Frage und ihre Antwort) erhalten sehr ähnliche Zahlenreihen, zwei unverwandte Eingaben klar unterschiedliche. Wie ähnlich zwei Vektoren sind, lässt sich anschließend rechnerisch bestimmen, üblicherweise über die Cosine-Similarity (ein Maß, das den Winkel zwischen zwei Zahlenreihen vergleicht und Werte zwischen -1 und 1 liefert).

Architektonisch handelt es sich fast ausschließlich um Transformer-Modelle, häufig als Encoder-only-Varianten (BERT-Familie, RoBERTa, DeBERTa). Das Training erfolgt über kontrastive Loss-Funktionen: Semantisch verwandte Paare (Frage/Antwort, Query/Dokument, Übersetzungspaare) werden im Vektorraum zusammengezogen, unverwandte Paare gedrückt. Dieses Trainingssignal formt einen Raum, in dem geometrische Nähe mit inhaltlicher Nähe korreliert.

Der Begriff hat sich als eigene Modell-Klasse etabliert, weil Sprachmodelle Text erzeugen, aber keine Dokumente suchen. Für semantische Suche, Deduplikation, Clustering, Klassifikation oder Empfehlungssysteme braucht es eine Modell-Klasse, die Eingaben in eine geometrisch vergleichbare Repräsentation überführt. In einer Retrieval-Augmented-Generation-Architektur sind Embedding Model und generatives Modell zwei getrennte Bausteine: das Embedding Model sitzt im Retrieval-Pfad, das generative Modell übernimmt die Antwortformulierung.

Verbreitete Modelle im aktuellen Feld: [OpenAI](https://platform.openai.com/docs/guides/embeddings) text-embedding-3-small und -large, Voyage AI voyage-3, Cohere embed-v3 sowie offene Modelle wie BGE (BAAI), E5 (Microsoft), Nomic, GTE (Alibaba) und Jina Embeddings. Multimodale Varianten wie [CLIP](https://openai.com/index/clip/) betten Text und Bild in einen gemeinsamen Raum ein. Late-Interaction-Modelle wie [ColBERTv2](https://arxiv.org/abs/2112.01488) speichern pro Dokument mehrere Vektoren statt eines gepoolten Gesamtvektors und erlauben feinere Übereinstimmungen auf Token-Ebene. Als Vergleichsgrundlage dient häufig der [MTEB-Benchmark](https://huggingface.co/spaces/mteb/leaderboard), der Embedding Models über mehrere Aufgabentypen misst.

Abgrenzung zu LLMs, Vector Search, Foundation Models und Rerankern

Embedding Models werden in der Diskussion regelmäßig mit angrenzenden Bausteinen einer KI-Pipeline vermischt. Die Abgrenzung sitzt jeweils an einer klaren funktionalen Grenze.

Der Unterschied zu LLMs sitzt in der Ausgabeform. Ein LLM wie GPT-4 oder DBRX erzeugt Text, beantwortet Fragen und formuliert Code. Ein Embedding Model erzeugt eine Zahlenrepräsentation. Beide Modell-Klassen basieren auf Transformer-Architekturen, sind aber auf verschiedene Ausgaben trainiert. In einer RAG-Pipeline sitzen sie hintereinander: das Embedding Model beim Retrieval, das LLM bei der Antwortformulierung.

Vector Search ist die nachgelagerte Komponente zum Embedding Model. Das Embedding Model erzeugt die Vektoren; die Vektor-Datenbank (Mosaic AI Vector Search, pgvector, Pinecone, Weaviate, Qdrant) indexiert sie und findet zu einem Query-Vektor die Top-K nächstgelegenen Kandidaten per Approximate-Nearest-Neighbor-Verfahren wie HNSW oder IVF-PQ. Die beiden Bausteine sind unabhängig austauschbar.

Foundation Models sind die Oberkategorie: große, auf breiten Daten vortrainierte Basis-Modelle, die anschließend auf viele Aufgaben angepasst werden. Embedding Models entstehen häufig als Spezialisierung eines Foundation Models auf die Repräsentations-Aufgabe. Dasselbe Foundation Model kann als Ausgangspunkt für ein generatives Modell und für ein Embedding Model dienen.

Reranker-Modelle werden oft mit Embedding Models verwechselt, weil beide Ähnlichkeiten bewerten. Der Unterschied liegt in der Architektur: Embedding Models arbeiten als Bi-Encoder (Query und Dokument getrennt kodiert, Ähnlichkeit aus dem Vektor-Abstand). Reranker arbeiten als Cross-Encoder (Query und Dokument gemeinsam durch das Modell, Ergebnis ein einzelner Score). Reranker sind genauer, aber deutlich langsamer und daher nur auf einer Vor-Auswahl von 50 bis 200 Kandidaten sinnvoll, die das Embedding Model liefert.

Beispiel: Embedding Model in einer RAG-Pipeline auf Databricks

Ein interner Wissensassistent soll Fragen zu technischen Handbüchern beantworten. Die Ingest-Pipeline liest die PDFs, teilt sie über einen Recursive Chunker in Abschnitte von 800 Tokens mit 100 Tokens Overlap und übergibt jeden Chunk an ein Embedding Model. Für englischsprachige Handbücher fällt die Wahl auf bge-large-en-v1.5 (1.024 Dimensionen) oder OpenAI text-embedding-3-large (3.072 Dimensionen). Für rund 15.000 Chunks entstehen 15.000 Vektoren, die zusammen mit Chunk-Text und Herkunfts-Metadaten in Mosaic AI Vector Search landen.

Zur Query-Zeit läuft die Nutzerfrage durch dasselbe Embedding Model. Der Suchindex liefert die zehn nächstgelegenen Chunks per Cosine-Similarity, ein Reranker (etwa bge-reranker-large oder Cohere Rerank) sortiert diese Top-10 nach, und das Sprachmodell formuliert die Antwort aus den besten sechs bis acht Chunks. Das Embedding Model erscheint zweimal in der Pipeline: einmal als Batch-Job im Ingest, einmal synchron pro Anfrage. Ein Wechsel des Embedding Models (etwa von bge-large auf voyage-3) erzwingt einen Reingest aller Dokumente, weil Vektoren nur innerhalb desselben Modells vergleichbar sind. Diese Kopplung zwischen Modell und Index ist der wichtigste Betriebsaspekt einer produktiven RAG-Umgebung.