Was ein Embedding tatsächlich ist
Schicken Sie den Satz „Die Pumpe ist undicht“ durch ein Embedding-Modell. Zurück kommt eine Liste von Zahlen — 384 Stück, oder 1.024, oder 3.072, je nach Modell. Diese Liste ist das Embedding. Sie ist keine Zusammenfassung, keine komprimierte Kopie des Satzes, und kein Teil davon ist lesbar. Stelle 47 bedeutet nicht „mechanisch“, Stelle 300 bedeutet nicht „dringend“. Niemand kann Ihnen sagen, wofür eine einzelne Zahl darin steht — auch die Leute nicht, die das Modell trainiert haben.
Der Vektor taugt für genau eine Sache: den Vergleich. Fragen Sie, wie nah er am Vektor für „Hydraulikaggregat verliert Öl“ liegt, bekommen Sie eine Zahl — üblicherweise die Kosinus-Ähnlichkeit zwischen −1 und 1. Diese Zahl ist das ganze Produkt. Alles, was Embedding-Systeme leisten, steht auf ihr und auf sonst nichts.
Daraus folgt unmittelbar die Regel, die Teams sich meistens teuer erarbeiten: Ein Vektor ist nur mit Vektoren desselben Modells vergleichbar. Koordinaten aus text-embedding-3-large von OpenAI und Koordinaten aus einem selbst gehosteten multilingual-e5-large beschreiben zwei unverwandte Räume, die zufällig ähnlich geformt sind. Ein Vergleich darüber hinweg stürzt nicht ab. Er liefert eine plausibel aussehende Zahl ohne jede Aussage. Merken Sie sich das — es kommt am Ende als teuerste Falle dieses Artikels zurück.
Warum ähnliche Bedeutung nah beieinander landet
Diesen Raum hat niemand entworfen. Er ist ein Rückstand aus dem Training. Dem Modell wurden gewaltige Mengen an Textpaaren gezeigt, die zusammengehören — eine Frage und ihre Antwort, eine Überschrift und ihr Artikel, ein deutscher Satz und seine englische Übersetzung — und es wurde gedrängt, jedes Paar nah zusammenzulegen und zufällig gezogene Paare auseinanderzuschieben. Macht man das lange genug über einen großen Teil des Internets, landet Text, der in denselben Zusammenhängen auftaucht, in derselben Nachbarschaft. Die Geometrie fällt aus der Statistik heraus.
Diesen Mechanismus lohnt es sich präzise zu formulieren, denn jedes spätere Missverständnis entsteht aus Ungenauigkeit an dieser Stelle. Das Modell hat keine Bedeutung gelernt. Es hat gelernt, welche Texte vom selben Thema handeln. „Ähnlich“ heißt: „Diese beiden Sätze würden plausibel im selben Gespräch vorkommen“ — nicht: „Diese beiden sagen dasselbe“, und schon gar nicht: „Diese beiden stimmen“.
Die Konsequenz ist unbequem. „Wasserschäden sind vom Versicherungsschutz umfasst“ und „Wasserschäden sind vom Versicherungsschutz nicht umfasst“ handeln vom selben Thema: gleicher Wortschatz, ein Wort Unterschied. Ein Embedding-Modell legt sie fast übereinander. Für einen Regionalversicherer, der Suche über seine Bedingungswerke baut, ist das kein Randfall — das ist die eigentliche Aufgabe. Ausschlüsse, Ausnahmen und Sicherheitshinweise sind genau die Passagen, an denen die Unterscheidung über die Antwort entscheidet, und genau die, für die Ähnlichkeit blind ist.
Was Sie davon haben: Retrieval und Klassifikation
Retrieval ist die bekannte Hälfte. Dokumente in Chunks zerlegen, jeden Chunk embedden, die Vektoren ablegen, zur Laufzeit die Frage embedden und die nächsten Nachbarn holen. Das ist die Vorderseite jedes RAG-Systems — in der vollständigen Pipeline steckt erheblich mehr, und in der Datenbank darunter sitzt das interessante Engineering rund um approximative Suche. Embeddings sind eine Stufe dieser Pipeline — und praktischerweise selten die Stufe, die kaputt ist.
Die zweite Hälfte wird übersehen, und sie ist die, zu der ich die meisten Unternehmen zuerst dränge. Embeddings sind ein hervorragender Klassifikator, und fast niemand nutzt sie als einen. Wenn Sie tausend E-Mails haben, die ein Mensch bereits in „Ersatzteilanfrage“, „Reklamation“, „Rechnungsfrage“ und „Sonstiges“ sortiert hat — und genau das hat jedes Unternehmen, es liegt im Sammelpostfach —, dann embedden Sie alle, setzen in etwa zehn Zeilen scikit-learn eine logistische Regression darauf und haben einen Router, der in Millisekunden antwortet, pro Aufruf nichts kostet, auf einer CPU im eigenen Haus läuft und eine Konfusionsmatrix produziert, die Sie der Fachabteilung vorlegen können.
Der Reflex ist inzwischen, stattdessen ein LLM zu prompten. Manchmal ist das richtig — wenn die Kategorien fein sind, wenn Sie keine gelabelten Beispiele haben, oder wenn neben dem Label eine Begründung stehen muss. Aber das LLM kostet pro Aufruf Geld, braucht pro Aufruf eine Sekunde, ändert sein Verhalten still, sobald der Anbieter eine neue Version ausrollt, und liefert eine Ausgabe, die Sie nur durch Lesen bewerten können. Der Embedding-Klassifikator ist prüfbar wie normale Software. Für Routing in hoher Stückzahl und geringer Feinheit ist er schlicht das bessere Engineering — und ein Nachmittag Arbeit.
Ein Embedding-Modell auswählen
Die ehrliche Antwort: Das zählt weniger, als die Ranglisten es aussehen lassen — und über eine Rangliste ist es ohnehin nicht zu entscheiden. MTEB ist ein ernstzunehmender Benchmark und ein vernünftiger Weg, das Feld auf drei Kandidaten einzudampfen. Welcher dieser drei auf Ihren Wartungsberichten am besten trägt, kann er nicht sagen — Ihre Wartungsberichte waren nicht darin. In der Praxis ist der Abstand zwischen dem Spitzenreiter und dem soliden Mittelfeld kleiner als der Abstand, den Chunking-Entscheidungen aufreißen.
Machen Sie also das Unspektakuläre. Nehmen Sie 50 echte Fragen — aus dem Ticketsystem, nicht aus der Vorstellungskraft —, notieren Sie zu jeder, welches Dokument zurückkommen müsste, lassen Sie Ihre drei Kandidaten laufen und zählen Sie, wie oft das richtige Dokument unter den ersten fünf steht. Das ist ein Nachmittag. Er beendet die Diskussion mit Evidenz und hinterlässt Ihnen ein Prüfset, das Sie in zwei Jahren noch benutzen, jedes Mal wenn jemand eine Änderung vorschlägt.
Zum Deutschen eine Warnung und eine Entwarnung. Die Warnung: Nehmen Sie nicht an, dass ein Modell an der Spitze einer englischen Rangliste auch brauchbar Deutsch liest. Tokenizer, die überwiegend auf Englisch trainiert wurden, zerhacken deutsche Komposita — aus Betriebshaftpflichtversicherung wird eine Handvoll Fragmente, die einzeln nichts bedeuten, und ausgerechnet der Begriff, den Ihr Nutzer eingetippt hat, ist der, mit dem das Modell am schlechtesten umgeht. Die Entwarnung: Ein starkes mehrsprachiges Modell — multilingual-e5, bge-m3, jina-embeddings-v3, die mehrsprachigen Angebote von Cohere oder OpenAI — schlägt ein kleines reines Deutsch-Modell meistens, weil auf dieser Ebene Größe der Spezialisierung überlegen ist. Bauen Sie die Auswahl über die deutschen MTEB-Aufgaben, prüfen Sie sie dann mit Ihren eigenen 50 Fragen.
Noch etwas, falls Datenhaltung im Haus der Grund ist, warum ein Projekt hängt: Die Embedding-Schicht ist der günstige Teil von On-Premise. Modelle wie multilingual-e5-large oder bge-m3 passen bequem auf eine mittelklassige GPU und laufen für die nächtliche Batch-Indizierung auch auf der CPU. Teuer am Selbstbetrieb ist das Generierungsmodell, nicht dieses hier.
Drei Fallen, die keine Fehlermeldung werfen
Jede davon erzeugt ein System, das läuft, Ergebnisse liefert und falsch ist. Die Lautlosigkeit macht sie teuer.
Ihr Vokabular stand nicht in den Trainingsdaten
Ein Embedding-Modell weiß, was eine Schraube ist, weil das Internet voller Schrauben ist. Es hat keine Ahnung, dass „A-Teil“ bei Ihnen ein Teil auf dem kritischen Pfad meint, oder dass DIN 912 und DIN 913 verschiedene Verbindungselemente sind und nicht zwei Schreibweisen derselben Zeichenkette. Teilenummern, Artikelnummern, Hauskürzel, Projektjargon: Der Tokenizer zerlegt sie in Fragmente, und die Fragmente sehen sich ähnlich. Ein Servicetechniker beim Maschinenbauer, der ein Ersatzteil über seine Nummer sucht, ist der denkbar schlechteste Fall für reine Vektorsuche.
Die Lösung ist kein besseres Embedding-Modell. Kein Modell kennt Ihre Teileliste. Die Lösung ist, Embeddings nicht länger um etwas zu bitten, das sie nicht können: Stichwortsuche per BM25 neben die Vektorsuche stellen und die Treffer zusammenführen — und die Teilenummer in einem Metadatenfeld halten, auf das Sie exakt filtern können. Für jeden Bestand mit Kennnummern darin ist hybride Suche keine spätere Verfeinerung. Sie ist der Ausgangspunkt.
Ein Chunk, ein Punkt
Jeder Chunk bekommt genau einen Vektor, egal wie viel Text darin steht. Ein knapper Absatz über Gewährleistungsfristen landet sauber in der Gewährleistungs-Nachbarschaft. Ein fünfseitiger Chunk über Gewährleistung, Lieferbedingungen und Haftung landet im Mittel der drei — an einer Stelle im Raum also, an der nichts wohnt. Er liegt nicht mehr nah bei „Gewährleistung“. Er liegt nah bei nichts Bestimmtem und verliert gegen einen mittelmäßigen kleinen Chunk, der wenigstens vom richtigen Thema handelt.
Das ist der Mechanismus hinter dem Rat, den Sie vermutlich schon kennen: klein schneiden, an der Struktur entlang schneiden. Und es ist der Grund, warum „nehmen wir ein Modell mit 8k Kontext, dann embedden wir ganze Dokumente“ eine als Fortschritt verkleidete Falle ist. Die Grenze war nie, wie viel Text durch das Modell passt. Die Grenze ist, dass ein Vektor nicht gleichzeitig in drei Richtungen zeigen kann.
Zwei Arten von veraltet, nur eine davon fällt auf
Die offensichtliche: Das Dokument hat sich geändert, der Index nicht. Die Preisliste ist von März, die Antwort zitiert überzeugt den März, der Kunde bekommt den März-Preis. Jedes RAG-Projekt plant dafür — bei Änderung neu indizieren, alles mit Zeitstempel versehen, verfallen lassen, was nicht überprüfbar ist. Das Problem ist gelöst, sobald es jemanden gibt, der es besitzt.
Die Art, die Teams erwischt, ist die andere: Das Modell hat sich geändert. Sie steigen auf ein neueres Embedding-Modell um, oder Ihr Anbieter stellt die Version ab, mit der Sie indiziert haben, oder jemand tauscht ein e5-Modell ein, ohne zu bemerken, dass die e5-Familie Anfragen mit query: und Dokumente mit passage: präfigiert erwartet — eine Konvention, die in einer Zeile der Modellkarte steht und sonst nirgends. Nichts wirft einen Fehler. Die Kosinus-Ähnlichkeit vergleicht klaglos zwei Vektoren aus zwei unverwandten Räumen und gibt eine vollkommen vernünftig aussehende Zahl zurück. Die Qualität bricht nicht auf null ein — das wäre wenigstens sichtbar. Sie sinkt auf mittelmäßig, und niemandem fällt es auf, weil niemand einen Vergleichswert aufbewahrt hat.
Also: Modellname, Version und Prompt-Konvention in die Index-Metadaten schreiben und den Abfragepfad prüfen lassen, dass es zusammenpasst, bevor er sucht. Neu-Embedden als Migration mit Umschaltpunkt behandeln, nicht als Konfigurationsänderung. Und beachten Sie das stille Argument, das das für den Eigenbetrieb des Embedding-Modells liefert: Ein Anbieter kann ein Modell nach seinem Zeitplan abkündigen — und dann wird Ihr Index nach seinem Zeitplan neu gebaut.
Wo Tippel ins Spiel kommt
Fast jedes Embedding-Problem, zu dem ich gerufen werde, entpuppt sich als eines dieser drei, und keines davon wird durch ein besseres Modell behoben. Das ist die Erkenntnis, die mitzunehmen sich lohnt: Die Embedding-Schicht ist selten der Engpass. Die Arbeit gehört ins Chunking, in hybrides Retrieval und in 50 echte Fragen, gegen die Sie messen können.
Wenn Sie wissen wollen, ob eine Retrieval- oder Klassifikationsidee auf Ihren tatsächlichen Dokumenten trägt, ist genau das der KI-Readiness-Check: ein Use Case, Ihre Daten, ein gemessenes Ergebnis, Festpreis und ein ehrliches Go/No-Go am Ende. Oder nehmen Sie Kontakt auf und beschreiben Sie den Bestand — meist reicht ein Gespräch, um zu sagen, ob der schwierige Teil das Modell ist oder die Dokumente.