Embeddings erklärt: Wie eine Suche versteht, was gemeint ist

Ein Servicetechniker tippt in den Assistenten: „Maschine wird zu heiß“. In den Dokumenten steht dieser Satz nirgends. Dort heißt der passende Artikel „Lagertemperatur zu hoch“: Steigt die Lagertemperatur über 90 °C, schaltet die Steuerung ab, Schmierung und Kupplung prüfen. Eine Suche, die nur Wörter vergleicht, findet dazu wenig oder nichts. Eine Suche mit Embeddings kann den Artikel auch ohne gemeinsames Wort finden.

Das ist der dritte Teil der Reihe über RAG. Nach dem Chunking geht es darum, wie aus den Chunks Zahlen werden und warum das eine Suche nach Bedeutung möglich macht.

Warum du das brauchst

Menschen fragen selten in den Worten des Handbuchs. Der Techniker schreibt „zu heiß“, das Handbuch sagt „Lagertemperatur“. Er schreibt „Maschine läuft unrund“, im Handbuch steht etwas über Ausrichtung und Schmierung. Eine reine Stichwortsuche zählt Wörter und findet bei solchen Umschreibungen meist nichts. Der Assistent bekäme keine Quelle und würde raten, und genau das soll RAG verhindern.

Embeddings lösen genau das. Sie übersetzen Text in Zahlen so, dass Texte mit ähnlicher Bedeutung nah beieinander liegen, auch wenn sie kein Wort gemeinsam haben.

Wie es funktioniert

Ein Embedding-Modell nimmt einen Text und gibt einen Vektor zurück, eine Liste von Zahlen. Wie viele es sind, hängt vom Modell ab: Gängige Modelle liefern zum Beispiel 384, 1024, 1536 oder 3072 Zahlen. Du kannst dir jeden Text als Punkt in einem sehr hochdimensionalen Raum vorstellen. Das Modell wurde so trainiert, dass Texte mit ähnlicher Bedeutung nah beieinander landen. „Wie nehme ich frei?“ liegt nahe bei „Urlaubsantrag stellen“, obwohl kein Wort übereinstimmt.

Gemessen wird die Nähe meist als Kosinus-Ähnlichkeit, also über den Winkel zwischen zwei Vektoren:

cos(q, d) = (q · d) / (‖q‖ · ‖d‖)

Ein Wert von 1 bedeutet gleiche Richtung, ein Wert um 0 bedeutet, dass die Texte inhaltlich nichts gemeinsam haben (mathematisch sind auch negative Werte möglich). Entscheidend ist die Richtung des Pfeils, nicht seine Länge. Bei der Suche wird die Frage mit demselben Modell in einen Vektor übersetzt, und die Chunks mit der größten Ähnlichkeit sind die Treffer. In großen Indizes nutzt man dafür Näherungsverfahren wie HNSW (Hierarchical Navigable Small World), damit nicht jeder Vektor einzeln verglichen werden muss. Das Ergebnis ist dann ein Näherungswert, kein garantiert exakter Treffer.

Ein Embedding speichert dabei keine Fakten und prüft nichts. Es sagt nur, welche Texte thematisch zusammenpassen. Ob ein Chunk die Frage wirklich beantwortet, entscheidet erst ein späterer Schritt, das Reranking im fünften Teil der Reihe.

Echte Vektoren haben Hunderte bis Tausende Dimensionen und lassen sich nicht zeichnen. Das Labor nimmt deshalb zwei: zehn Sätze aus vier Themen (Störung, Ersatzteile, Wartung, Fernzugriff), jeder als nummerierter Punkt auf einem Kreis. Wähle eine der Beispielfragen oder klick selbst in die Fläche und beobachte, welche drei Sätze nach vorn rücken. „Maschine läuft unrund“ findet die laute Pumpe, obwohl beide Sätze kein gemeinsames Wort haben.

Worauf du achten solltest

• Gleiches Modell für alles. Frage und Dokumente müssen mit demselben Modell vektorisiert werden. Vektoren verschiedener Modelle liegen in unterschiedlichen, nicht vergleichbaren Räumen. Wechselst du das Modell, musst du alles neu indexieren. Manche Modelle, etwa multilingual-e5, erwarten außerdem ein festes Präfix („query: “ bzw. „passage: “) vor Frage und Dokument.
• Sprache beachten. Für deutsche Texte nimmst du ein Modell, das Deutsch ausdrücklich unterstützt, zum Beispiel BGE-M3 (über 100 Sprachen), multilingual-e5 (rund 100 Sprachen) oder Cohere embed-multilingual (über 100 Sprachen). Auch OpenAI text-embedding-3 wird für deutsche Texte eingesetzt. Teste jedes Modell an deinen eigenen Fragen.
• Die Schwäche kennen. Fehlercodes, Teilenummern und Namen sind für ein Embedding schwer zu fassen: „E-217“ ist für das Modell kaum mehr als eine Zeichenkette. Bei exakten Kennungen ist die Stichwortsuche in der Regel zuverlässiger. Auch in Vergleichstests (BEIR) bleibt BM25 eine robuste Basislinie, hinter der Vektormodelle außerhalb ihrer Trainingsdomäne oft zurückbleiben. Das ist der Grund für den nächsten Teil der Reihe.
• Ähnlich heißt nicht richtig. Ein Embedding findet Texte zum selben Thema, nicht zwingend den, der die Frage beantwortet. Ein Artikel über Fernwartung kann einem Artikel über den Einsatz vor Ort sehr nahe liegen.

Fazit

Embeddings machen aus einer Suche nach Wörtern eine Suche nach Bedeutung. Das ist ihre Stärke bei Umschreibungen und ihre Schwäche bei Codes und Nummern. Wähle ein Modell, das deine Sprache kann, nimm für Frage und Dokumente dasselbe und rechne damit, dass die Vektorsuche allein nicht reicht. Wie du beide Suchen kombinierst, zeigt der nächste Teil: Hybrid Search erklärt.

Quellen

• OpenAI: Vector embeddings (Dokumentation) (Stand 2026), Standardlänge der Vektoren 1536 bzw. 3072, Empfehlung Kosinus-Ähnlichkeit
• Cohere: Embed (Dokumentation) (Stand 2026), embed-multilingual mit 1024 bzw. 384 Dimensionen, über 100 Sprachen
• intfloat: multilingual-e5-large (Modellkarte) (Stand 2026), 1024 Dimensionen, rund 100 Sprachen, Präfixe query: und passage:
• Chen et al.: BGE M3-Embedding (2024), Mehrsprachigkeit (über 100 Sprachen) und Eingaben bis 8192 Tokens
• Malkov und Yashunin: Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs (2016), HNSW als Näherungsverfahren
• Thakur et al.: BEIR, A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models (2021), BM25 als robuste Basislinie, dichte Modelle verallgemeinern oft schwächer