Embedding, Bedeutung als Zahlenreihe

Im vorigen Kapitel wurde Text in Token zerlegt und jedes Token bekam eine Nummer aus dem Vokabular. Diese Nummer ist eine Adresse und sonst nichts. Das Token ·Katze hat vielleicht die 168947, ·Hund die 74312. Aus den beiden Zahlen folgt nichts: Sie sind nicht ähnlicher als 3 und 4, obwohl die Wörter es sind.

Damit ein Modell überhaupt etwas mit Sprache anfangen kann, braucht es eine Darstellung, in der Ähnlichkeit sichtbar wird. Diese Darstellung heißt Embedding.

Aus einer Nummer wird eine Reihe

Jedes Token bekommt eine Reihe von Zahlen zugeordnet, und zwar einige hundert bis einige tausend. Wie viele es sind, legt das jeweilige Modell fest. Eine allgemein gültige Zahl gibt es nicht. Die Beispiele hier rechnen mit 3072, weil Googles Embedding-Modell von dieser Länge ausgeht (externe Seite, blog.google).

seitlich verschiebbar

eigene Darstellung, Stand 28.07.2026

Eine Reihe aus 3072 Zahlen ist ein Punkt in einem Raum mit 3072 Richtungen. Das kann sich niemand vorstellen, und man muss es auch nicht. Was zählt, ist eine einzige Eigenschaft dieses Raums: Abstand bedeutet etwas.

Wörter, die in Texten ähnlich verwendet werden, landen an ähnlichen Stellen. Katze, Hund und Hamster liegen beieinander, Auto und Laster liegen woanders beieinander, und zwischen den beiden Gruppen ist es weit.

Woher die Zahlen kommen

Niemand hat sie eingetragen. Sie entstehen beim Training, dessen Ablauf in KI-Wissen, Kapitel 02 steht, und zwar aus einer einzigen, sehr einfachen Beobachtung: Wörter, die in ähnlichen Zusammenhängen vorkommen, bedeuten meistens Ähnliches. Wer Millionen Sätze sieht, in denen „Katze“ und „Hund“ an vergleichbaren Stellen stehen, kann beiden ähnliche Zahlen geben, ohne je erfahren zu haben, was ein Tier ist.

Das ist alt. Die Arbeit, die es 2013 praktisch gemacht hat, heißt Efficient Estimation of Word Representations in Vector Space (externe Seite, arxiv.org) und brauchte für ihre Zeit erstaunlich wenig Rechenleistung. Berühmt wurde die Beobachtung, dass man mit diesen Vektoren rechnen kann: König minus Mann plus Frau landet in der Nähe von Königin. Sie stammt aus einer Vorarbeit derselben Gruppe, die die Arbeit von 2013 in ihrer Einleitung zitiert (externe Seite, arxiv.org); ihr eigener Beitrag ist der Testsatz, mit dem sich solche Rechnungen erstmals systematisch messen ließen.

Dieser Rechentrick wird bis heute gern vorgeführt. Er funktioniert bei den Wortvektoren von damals ordentlich und bei heutigen Modellen nur noch eingeschränkt, weil dort die Bedeutung vom Satz abhängt. Was bleibt, ist die Grundidee: Bedeutung als Lage im Raum.

Wozu das gut ist

Drei Dinge, die ohne Embeddings nicht gingen.

Suchen nach Sinn statt nach Wörtern. Wer „Wie storniere ich meine Bestellung?“ eingibt, findet auch den Abschnitt „Widerruf und Rücksendung“, in dem keines der Wörter aus der Frage vorkommt. Gesucht wird nach nahen Punkten, nicht nach gleichen Zeichenketten.

Eigene Dokumente nutzbar machen. Genau darauf beruht das Verfahren, mit dem Sprachmodelle Fragen zu Firmenunterlagen beantworten: Die Unterlagen werden in Abschnitte zerlegt, jeder Abschnitt bekommt seine Zahlenreihe, und zur Frage werden die nächstliegenden Abschnitte herausgesucht und dem Modell vorgelegt. Es ist einer der drei Wege, auf denen Neues in ein Modell kommt, und die stehen in Kapitel 08.

Sortieren und Gruppieren. Tausend Rückmeldungen lassen sich zu Häufungen zusammenfassen, ohne dass jemand vorher Kategorien festlegt. Die Häufungen sind Punktwolken.

Die Grenze, die man kennen muss

Nähe im Raum ist Ähnlichkeit der Verwendung. Sie ist keine Wahrheit und kein Urteil. „Der Vertrag wurde gekündigt“ und „Der Vertrag wurde nicht gekündigt“ liegen sehr nah beieinander, denn sie handeln von derselben Sache und unterscheiden sich in einem Wort.

Wer eine Suche über Embeddings baut, bekommt deshalb thematisch passende Treffer, keine inhaltlich richtigen. Der Unterschied klingt spitzfindig und ist im Betrieb der häufigste Grund für falsche Antworten aus einer Wissensbasis.

Wie ein Modell diese Zahlen bekommt und warum es dafür oft ein zweites, eigenes Modell braucht, steht in der nächsten Tiefe.

Ein Sprachmodell bringt seine Embeddings selbst mit. Trotzdem gibt es einen eigenen Markt für Embedding-Modelle, und wer eine Suche baut, benutzt fast immer eines davon statt des Sprachmodells, das später antwortet. Dieser Abschnitt erklärt, warum das kein Umweg ist.

Die Embedding-Schicht

Ganz vorn im Sprachmodell steht eine Tabelle. Sie hat so viele Zeilen wie das Vokabular Einträge hat, bei 200.000 Token also 200.000 Zeilen, und jede Zeile ist die Zahlenreihe für dieses eine Token. Der erste Schritt jeder Verarbeitung ist ein Nachschlagen: Token-Nummer rein, Zahlenreihe raus.

Diese Tabelle ist Teil der Modellgewichte und wird mittrainiert. Sie ist auch der Grund für eine Bemerkung aus dem vorigen Kapitel: Ein größeres Vokabular kostet Speicher, weil jeder zusätzliche Eintrag eine weitere Zeile in dieser Tabelle bedeutet.

Warum die Embedding-Schicht allein nicht reicht

Die Zeile für ·Bank ist immer dieselbe. Sie kennt keinen Zusammenhang, also auch nicht den Unterschied zwischen dem Geldhaus und dem Sitzmöbel. Ein Modell, das dabei stehenbliebe, könnte diesen Unterschied nie machen.

Er entsteht in den Schichten darüber. Der Mechanismus dafür heißt Aufmerksamkeit und stammt aus Attention Is All You Need (externe Seite, arxiv.org): Jedes Token sieht andere Token im Text an und verschiebt seine eigene Zahlenreihe entsprechend. Bei einem Modell, das Text fortsetzt, sind das nur die vorangehenden (externe Seite, arxiv.org), einschließlich seiner selbst. Anders könnte es beim Training die Fortsetzung ablesen, die es vorhersagen soll. Nach ein paar Schichten hat das Bank im Satz „Ich sitze auf der Bank“ eine andere Darstellung als das Bank im Satz „Ich gehe zur Bank“.

Damit stehen zwei verschiedene Dinge nebeneinander, die beide Embedding heißen:

	statisch	im Zusammenhang
Woher	Nachschlagetabelle ganz vorn	innere Schichten des Modells
Gilt für	ein Token, immer gleich	ein Token in diesem einen Satz
Kennt Mehrdeutigkeit	nein	ja

Ein Text ist kein Token

Für eine Suche braucht man eine Zahlenreihe für einen ganzen Abschnitt, damit sich Abschnitte vergleichen lassen. Sie entsteht aus den Reihen der einzelnen Token, die zu einer einzigen zusammengefasst werden. Das Verfahren dafür heißt Pooling.

Der naheliegende Weg ist der Durchschnitt, und er ist zugleich der übliche. Sentence-BERT (externe Seite, arxiv.org), die Arbeit, die 2019 aus einem Sprachmodell ein Suchwerkzeug gemacht hat, probiert drei Wege aus und stellt den Durchschnitt als Voreinstellung ein.

Entscheidend ist, worüber gemittelt wird. Über die statischen Reihen aus der Nachschlagetabelle gemittelt, gewichtet er Füllwörter wie Fachbegriffe und glättet weg, was zwei Texte über dasselbe Thema unterscheidet. Über die Reihen aus den inneren Schichten gemittelt, bringt jede einzelne bereits ihren Satz mit, und das Ergebnis taugt etwas.

Damit ist die dritte Sache benannt, die Embedding heißt: eine Reihe für einen ganzen Abschnitt. Dafür gibt es eigene Modelle, deren einzige Aufgabe das ist.

Was ein Embedding-Modell anders macht

Der wichtigste Unterschied liegt im Trainingsziel.

Ein Sprachmodell wird darauf trainiert, das nächste Token vorherzusagen. Ein Embedding-Modell wird darauf trainiert, dass zusammengehörige Textpaare nah beieinander landen und unzusammengehörige weit auseinander. Man legt ihm also Millionen Paare vor, etwa Frage und passende Antwort, Titel und Artikel, Übersetzung und Original, und straft es, wenn der Abstand nicht stimmt. Dieses Verfahren heißt Contrastive Learning.

Das erklärt drei praktische Eigenschaften:

Sie sind klein. Ein Embedding-Modell hat oft einige hundert Millionen Parameter, nicht hunderte Milliarden. Es muss nichts formulieren, nur einordnen.

Sie sind billig. Eine Million Textabschnitte einzubetten kostet einen Bruchteil dessen, was eine Million Antworten kosten würde. Anders ließe sich eine Wissensbasis gar nicht aufbauen.

Manche kennen die Richtung der Frage. Eine Suchanfrage ist kurz und fragend, ein Dokument lang und behauptend. Ein Teil der Modelle unterscheidet beim Einbetten, ob das Stück als Frage oder als Fundstelle gemeint ist, meist über einen Aufgabentyp im Aufruf oder ein vorangestelltes Stichwort. Ob das eigene Modell dazugehört, steht in seiner Dokumentation. Wer die Angabe übersieht, verschenkt Trefferqualität, ohne dass es auffällt.

Wie Nähe gemessen wird

Der übliche Abstand ist der Kosinus zwischen zwei Zahlenreihen: der Winkel, den sie einschließen, ohne Rücksicht auf ihre Länge. Zwei Texte gelten als ähnlich, wenn ihre Reihen in dieselbe Richtung zeigen.

Die Werte liegen zwischen 1 (gleiche Richtung) und minus 1 (Gegenrichtung). Welcher Teil dieser Spanne in einem konkreten System vorkommt, hängt vom Modell, von der Sprache und vom Bestand ab und gehört gemessen. Eine feste Schwelle wie „ab 0,8 ist es ein Treffer“ lässt sich deshalb von einem Modell auf ein anderes nicht übertragen. Die Zahlen sind Hausnummern des jeweiligen Modells.

Die Länge der Reihe ist wählbar

Mehr Zahlen kosten mehr Speicher und mehr Rechenzeit. Bei einer Million Abschnitten macht der Unterschied zwischen 768 und 3072 Zahlen den Unterschied zwischen wenigen und einigen Gigabyte, und die Suche wird entsprechend langsamer. Ob mehr Zahlen auch bessere Treffer bringen, ist eine eigene Frage mit einer überraschenden Antwort.

Aktuelle Modelle nutzen dafür Matryoshka Representation Learning (externe Seite, arxiv.org): Die Reihe wird so trainiert, dass schon ihr Anfang für sich brauchbar ist. Wer Speicher sparen will, schneidet sie hinten ab, statt ein zweites, kleineres Modell zu betreiben. Die Arbeit dazu beziffert, was dabei übrig bleibt: In ihrem Versuchsaufbau zur Bilderkennung ist die gekürzte Reihe bis zu vierzehnmal kleiner bei gleicher Genauigkeit (externe Seite, arxiv.org), und die gekürzten Reihen sind mindestens so gut wie eigens dafür trainierte kleine (externe Seite, arxiv.org). Wie weit sich das auf den eigenen Bestand überträgt, zeigt erst die Messung daran.

Was das für den Bau bedeutet

Die Aufteilung im Betrieb sieht deshalb meistens so aus: Ein kleines Embedding-Modell bettet den Bestand einmal ein und jede Suchanfrage neu, ein großes Sprachmodell formuliert aus den gefundenen Stellen die Antwort. Beide Modelle stammen oft von verschiedenen Anbietern, und das ist kein Problem, solange innerhalb des Index nichts gemischt wird.

Wie diese Zahlen zusätzlich Bilder, Ton und Video aufnehmen, und warum das die Bauform von Suchsystemen verändert, steht in der nächsten Tiefe.

Zwei Entwicklungen haben sich in den vergangenen Jahren durchgesetzt. Die eine ist technisch: Ein Raum nimmt jetzt alle Medienarten auf. Die andere ist handwerklich: Die Qualität einer Suche entscheidet sich weniger am Modell als an der Zerlegung des Bestands.

Ein Raum für Text, Bild, Ton und Video

Ein gemeinsamer Raum für zwei Medienarten ist alt. CLIP hat 2021 ein Bild- und ein Textnetz gleichzeitig darauf trainiert, dass zusammengehörige Paare denselben Platz bekommen (externe Seite, arxiv.org), und dafür 400 Millionen Bild-Text-Paare (externe Seite, arxiv.org) aus dem Netz verwendet. Danach fehlte lange die Breite: Ton, Video und ganze Dokumentseiten blieben draußen, und für jede weitere Medienart brauchte es ein eigenes Verfahren, das zwischen den Räumen vermittelte.

Im März 2026 hat Google mit Gemini Embedding 2 ein Modell vorgestellt, das Text, Bild, Ton, Video und Dokumentseiten in denselben Raum legt (externe Seite, blog.google). Die technische Arbeit dazu beschreibt es als ein Modell für alle Modalitäten (externe Seite, arxiv.org) in einem gemeinsamen Darstellungsraum, trainiert mit Contrastive Learning über mehrere Stufen.

seitlich verschiebbar

eigene Darstellung nach der Beschreibung in Gemini Embedding 2, Stand 28.07.2026

Warum das mehr ist als ein Zusatzmerkmal auf einem Datenblatt:

Die Frage muss nicht mehr die Form des Bestands haben. Ein gesprochener Satz findet die Stelle im Video, ein Foto findet den Absatz im Handbuch, ein Screenshot findet das Ticket. Vorher brauchte jede dieser Richtungen einen eigenen Weg.

Der Zwischenschritt entfällt. Der übliche Umweg war, alles zuerst in Text zu verwandeln: Bilder beschreiben lassen, Ton transkribieren, PDF-Seiten durch Texterkennung schicken. Jeder dieser Schritte kostet Zeit, Geld und Genauigkeit, und was die Beschreibung nicht erwähnt, ist unwiederbringlich weg. Das Layout einer Rechnung zum Beispiel. Beim Vorlegen eines einzelnen Bildes entfällt derselbe Umweg aus demselben Grund, dort allerdings ohne Index (Kapitel 13).

Der Index bleibt einer. Ein Bestand, eine Suche, ein Satz Nachbarschaften. Wer vorher drei Indizes führte, führte auch drei Wahrheiten über dieselbe Sache.

Die Grenzen stehen im Kleingedruckten: Ein Aufruf verarbeitet Eingaben bis zu einer festen Größe, bei diesem Modell rund 8000 Token Text, wenige Bilder, zwei Minuten Video, drei Minuten Ton, wenige PDF-Seiten. Ein Film wird also weiterhin zerschnitten, bevor er in den Index kommt. Und die Werte, die Anbieter zu ihren eigenen Modellen veröffentlichen, sind Herstellerangaben.

Die Zerlegung entscheidet mehr als das Modell

In der Praxis liegt der größte Hebel vor dem Embedding-Modell. Ein Abschnitt, der zwei Themen enthält, bekommt eine Zahlenreihe, die zwischen beiden liegt und zu keinem gehört. Ein Abschnitt, der mitten im Satz endet, verliert seinen Bezug.

Drei Regeln, die sich bewährt haben:

In Token messen, nicht in Zeichen. Warum das bei deutschen Fachtexten einen Unterschied macht, steht in Kapitel 03.

An inhaltlichen Grenzen schneiden. Überschrift, Absatz, Listenpunkt. Eine feste Länge ohne Rücksicht auf die Struktur zerschneidet Zusammenhänge genau dort, wo sie gebraucht werden.

Den Zusammenhang mitgeben. Ein Abschnitt aus der Mitte eines Handbuchs sagt allein oft wenig. Wer ihm die Überschriftenkette voranstellt, bevor er ihn einbettet, verbessert die Trefferlage deutlich, ohne am Modell etwas zu ändern.

Wo die Ähnlichkeitssuche systematisch danebenliegt

Vier Fälle, in denen der nächste Nachbar der falsche ist. Sie zählen auf, was neben dem Verfahren stehen muss.

Verneinung. „Der Vertrag wurde gekündigt“ und „Der Vertrag wurde nicht gekündigt“ sind sich im Raum sehr nah, denn gemessen wird die Verwendung eines Textes, und in der Verwendung trennt die beiden ein einziges Wort. Wie weit ein Modell den Unterschied trotzdem abbildet, ist eine Eigenschaft dieses Modells und gehört an eigenen Beispielen gemessen.

Zahlen und Kennungen. Wer nach einer Rechnungsnummer sucht, sucht nach genau dieser Zeichenkette. Ähnlichkeit hilft nicht, sie schadet: Die benachbarte Rechnung sieht fast genauso aus. Solche Fälle gehören in eine Volltextsuche, nicht in eine Ähnlichkeitssuche.

Fachbegriffe, die selten sind. Was im Trainingsmaterial kaum vorkam, hat eine unzuverlässige Lage. Deutsche Komposita und Behördenbegriffe sind dafür anfällig, weil sie sich beliebig neu bilden lassen und deshalb im Material oft gar nicht als Ganzes stehen. Wie stark das beim eigenen Modell durchschlägt, zeigen eigene Suchfragen mit bekannter richtiger Fundstelle.

Die Frage nach dem Gegenteil. „Welche Regelungen gelten nicht für Teilzeitkräfte“ liefert zuverlässig die Regelungen für Teilzeitkräfte.

Die übliche Antwort darauf ist ein zweistufiges Vorgehen: Erst Kandidaten über die Ähnlichkeitssuche und über eine klassische Wortsuche einsammeln, dann von einem kleinen Modell in eine Reihenfolge bringen lassen. Die zweite Stufe kostet mehr, sieht aber genau hin.

Was beim Modellwechsel passiert

Ein neues Embedding-Modell bringt einen eigenen Raum mit. Alte und neue Vektoren im selben Index ergeben stille Fehler: Die Rechnung läuft durch, die Nachbarschaften stimmen nicht mehr, und niemand bekommt eine Fehlermeldung.

Was dazugehört:

• Vollständig neu einbetten, nicht nur die neuen Dokumente. Bei einer Million Abschnitten ist das eine planbare Aufgabe mit Kosten und Laufzeit.
• Beide Indizes parallel fahren, bis der neue gemessen besser ist. Die Messung braucht eigene Testfragen mit bekannter richtiger Fundstelle.
• Die Länge der Reihe festlegen und aufschreiben. Wenn ein Modell nach Matroschka-Art (externe Seite, arxiv.org) kürzbar ist, gehört die gewählte Länge zum Index. Wer sie später ändert, hat wieder zwei Räume.

Ein Vektor ist keine Anonymisierung

Eine Zahlenreihe sieht nach Ergebnis aus, und darauf beruht die verbreitete Annahme, ein Vektorindex sei harmloser als der Text darin. Morris und Mitautoren haben 2023 gemessen, wie weit sie reicht. Ihr Verfahren bettet einen Versuch ein, vergleicht ihn mit dem Zielvektor und bessert schrittweise nach (externe Seite, arxiv.org), bis der Text wieder dasteht; bei Eingaben von 32 Token trifft es in 92 Prozent der Fälle den Wortlaut. Aus einem Bestand klinischer Notizen holte es Klarnamen zurück (externe Seite, arxiv.org).

Praktisch heißt das: Der Index gehört dorthin, wo auch die Dokumente liegen dürfen. Wer einen Bestand bei einem Dienst einbettet und die Vektoren dort ablegt, hat den Bestand dort abgelegt, und dieselbe Frage nach Zugriffsrechten stellt sich innerhalb des eigenen Hauses: Ein Abschnitt, den nur die Personalabteilung sehen darf, wird als Vektor nicht weniger lesbar.

Was man messen sollte, bevor man optimiert

Zum Schluss die brauchbaren Kennzahlen und eine unbrauchbare.

Nützlich ist der Anteil der Fragen, bei denen die richtige Stelle überhaupt unter den gefundenen war. Diese Zahl trennt sauber: Ist sie schlecht, hilft kein besseres Sprachmodell, denn was nicht gefunden wurde, kann nicht in die Antwort kommen. Nützlich ist außerdem die Position der richtigen Stelle in der Trefferliste, weil sie zeigt, ob eine zweite Stufe zum Sortieren lohnt.

Nicht nützlich ist der durchschnittliche Ähnlichkeitswert. Er steigt, wenn die Abschnitte kürzer werden, und er sagt nichts darüber, ob das Richtige gefunden wurde. Eine Zahl, die sich verbessern lässt, ohne dass das System besser wird, taugt nicht als Kennzahl. Sie beruhigt, mehr nicht.