Embeddings: Bedeutung als Zahlenreihe

Embeddings sind Zahlenreihen, die die Bedeutung von Text, Bildern oder anderen Daten darstellen. Sie sind die technische Grundlage für semantische Suche, Empfehlungssysteme und die Wissensanbindung von Sprachmodellen (RAG). Dieser Artikel erklärt, was sie sind, wie sie entstehen und worauf es in der Praxis ankommt.

Die Grundidee

Ein Sprachmodell verarbeitet Text intern als Zahlen. Ein Embedding-Modell macht diesen Zwischenschritt zugänglich: Es wandelt einen Text in einen Vektor fester Länge um – typisch 384 bis 3072 Zahlen. Der entscheidende Punkt ist nicht die Zahl selbst, sondern die Geometrie: Texte mit ähnlicher Bedeutung liegen im Vektorraum nah beieinander.

# Beispiel: Abstand sagt etwas ueber Aehnlichkeit\nembed("Wie sichere ich einen Server?")      ->  [...]\nembed("Server absichern und haerten")       ->  [...]   # sehr nah\nembed("Welche Temperatur hat Wasser?")      ->  [...]   # weit weg\n\n# Gemessen wird ueblicherweise ueber den Kosinus des Winkels\n# 1.0  = identische Bedeutung\n# 0.8+ = sehr aehnlich\n# 0.5  = verwandtes Thema\n# 0.0  = ohne Bezug

Diese Eigenschaft ist der ganze Nutzen: Eine Suche muss nicht mehr dasselbe Wort enthalten wie das Dokument. „Wie schütze ich meinen Rechner?“ findet auch einen Text über „Server-Härtung“, obwohl kein gemeinsames inhaltstragendes Wort vorkommt.

Modelle wählen

Drei Kriterien entscheiden:

Sprache: Manche Modelle sind auf Englisch trainiert und verlieren bei deutschen Texten deutlich an Qualität. Für deutschsprachige Anwendungen muss das Modell ausdrücklich mehrsprachig sein.
Dimension: Höhere Vektoren können mehr Informationen aufnehmen, kosten aber Speicher und Rechenzeit. Bei einer Million Dokumente mit 1536 Dimensionen sind das rund 6 GB nur für die Vektoren – bei 384 Dimensionen nur 1,5 GB.
Länge des Eingabetexts: Modelle haben eine Höchstlänge (oft 512 oder 8192 Token). Längere Texte müssen aufgeteilt werden.

Chunking: die unterschätzte Entscheidung

Ein Embedding gilt immer für einen Textabschnitt. Wie man lange Dokumente aufteilt (chunking), hat enormen Einfluss auf die Ergebnisqualität:

Zu groß: Ein Abschnitt enthält mehrere Themen; der Mittelwert der Bedeutung passt zu keinem davon. Die Suche findet den Abschnitt, aber nicht die relevante Stelle.
Zu klein: Zusammenhänge zerfallen in Bruchstücke; das Modell erhält später nicht genug Kontext.
Überlappung: Benachbarte Abschnitte sollten sich um 10 bis 20 % überlappen, damit kein Satz an der Grenze zerrissen wird.
Strukturgrenzen beachten: Absätze, Überschriften und Codeblöcke sind natürliche Grenzen. Ein Abschnitt, der mitten im Codebeispiel endet, ist unbrauchbar.

# Typische Groessen (Richtwerte, je nach Inhalt anzupassen)\n#   Fliesstext, technische Doku:  400-800 Token, 15 % Ueberlappung\n#   Handbuecher, Vertraege:       250-500 Token (praeziser)\n#   Gespraechsverlaeufe:          ein Gespraechsabschnitt je Chunk\n\n# Wichtige Zusatzinformationen am Chunk speichern:\n#   quelle, abschnittsnummer, ueberschrift, dokumenttitel\n# Ohne diese Metadaten kann man spaeter keine Quelle angeben.

Speicherung und Suche

Für die Suche braucht man eine Struktur, die ähnliche Vektoren schnell findet. Ein einfacher Vergleich gegen alle Einträge ist linear langsam – bei einer Million Chunks nicht praktikabel. Zum Einsatz kommen spezialisierte Vektor-Indizes:

HNSW: graphbasiert, sehr schnell, braucht viel Speicher. Der Standard in den meisten Vektordatenbanken.
IVF: teilt den Raum in Zellen und sucht in den nächsten. Weniger Speicher, etwas ungenauer.
Produktquantisierung: komprimiert Vektoren stark, mit Qualitätsverlust. Sinnvoll bei sehr großen Beständen.

Diese Indizes liefern annähernd die nächsten Nachbarn. In der Praxis ist das völlig ausreichend – die genaue Reihenfolge unter den ersten Treffern ist bedeutungslos.

Hybride Suche: der wichtigste Praxistipp

Reine Vektorsuche hat eine Schwäche: Seltene, exakte Begriffe. Fragt jemand nach einer spezifischen Modellnummer, einem Fehlercode oder einem Eigennamen, versagt die Ähnlichkeitssuche – semantisch ist das Wort austauschbar, exakt ist es nicht. Stichwortsuche bleibt unverzichtbar.

Die Lösung ist die Kombination: Beide Verfahren laufen parallel, und die Ergebnisse werden zusammengeführt (reciprocal rank fusion). Diese hybride Suche ist bei technischen Inhalten meist deutlich besser als jede der beiden Methoden allein.

Worauf es in der Praxis ankommt

Chunking und Modelle sind entscheidender als die Datenbank. Die erste Wahl einer Vektordatenbank ist selten das Problem; falsche Abschnittsgrößen sind es fast immer.
Metadaten immer mitspeichern. Ohne Angabe der Quelle ist ein Treffer für den Nutzer wertlos – niemand kann ihn überprüfen.
Qualität der Eingangsdaten prüfen. Ein Embedding über eine schlecht konvertierte PDF-Datei mit eingestreuten Kopf- und Fußzeilen ist Müll – unabhängig vom Modell.
Nicht zuviele Treffer übergeben. Fünf bis zehn gute Abschnitte sind besser als dreißig mittelmäßige. Der Kontext des Sprachmodells ist begrenzt, und zu viel Füllmaterial verwässert die Antwort.
Testfragen festhalten. Eine Sammlung echter Fragen mit erwarteten Treffern ist das einzige Mittel, um Änderungen an Chunking oder Modell zu bewerten.