Embedding-Modelle vergleichen: Kriterien für die richtige Wahl

Wer eine semantische Suche oder ein RAG-System aufbaut, steht früh vor der Wahl des Embedding-Modells. Die naheliegende Recherche führt zu öffentlichen Leaderboards, und dort beginnt die Verwirrung: Je nach Benchmark, Sprache und Aufgabentyp führt ein anderes Modell, die Abstände an der Spitze sind klein, und monatlich kommen neue Kandidaten dazu. Die Rangliste beantwortet die falsche Frage. Entscheidend ist nicht, welches Modell im Durchschnitt über fremde Datensätze gewinnt, sondern welches auf den eigenen Dokumenten und Anfragen funktioniert.

Dazu kommt, dass die Retrieval-Qualität nur eines von mehreren Kriterien ist. Ein Embedding-Modell ist eine Infrastrukturentscheidung: Es bestimmt Speicherbedarf und Suchgeschwindigkeit der Vektordatenbank, laufende Kosten bei jedem neuen Dokument und jeder Anfrage, und es bindet den gesamten Index an sich. Wer nur auf den Benchmark-Wert schaut, wählt am Bedarf vorbei.

Dimensionen, Kosten und Speicherbedarf

Die Dimensionalität eines Embeddings, also die Länge des Vektors, wird oft als Qualitätsmerkmal gelesen: mehr Dimensionen, mehr Bedeutung. Praktisch ist sie vor allem ein Kostenfaktor. Jeder Vektor wird für jeden Chunk gespeichert, und bei größeren Beständen summiert sich das: doppelte Dimension bedeutet grob doppelter Speicher und langsamere Suche. Viele neuere Modelle erlauben es, Vektoren auf eine kleinere Dimension zu kürzen und dabei den Großteil der Qualität zu behalten. Ob der Qualitätsverlust im eigenen Fall spürbar ist, lässt sich nur durch Messung klären, aber die Option gehört in die Abwägung.

Bei den laufenden Kosten lohnt ein Blick auf das Nutzungsprofil. Die Einbettung des Bestands fällt einmal an, danach dominieren zwei Ströme: neue oder geänderte Dokumente und die Anfragen der Nutzer. Ein Preisunterschied pro Million Tokens, der beim einmaligen Indexieren verschmerzbar wirkt, kann bei hohem Anfragevolumen zum relevanten Posten werden. Umgekehrt gilt: Bei kleinen Beständen und moderatem Verkehr sind die Embedding-Kosten meist vernachlässigbar gegenüber den Kosten des Sprachmodells dahinter.

Mehrsprachigkeit und deutsche Texte

Viele Embedding-Modelle werden überwiegend auf englischen Daten trainiert und bewertet. Für deutsche Fachtexte ist das ein reales Risiko: Komposita, Fachterminologie und flektierte Formen werden von schwach mehrsprachigen Modellen deutlich schlechter abgebildet, und der Abstand zeigt sich in keinem englischen Benchmark. Wer deutschsprachige Bestände durchsuchbar machen will, sollte gezielt Modelle mit ausgewiesener mehrsprachiger Ausrichtung in die engere Wahl nehmen und die Prüfung zwingend auf deutschen Texten durchführen.

Ein Sonderfall ist der gemischtsprachige Betrieb: deutsche Dokumente, aber Anfragen teils auf Englisch, oder umgekehrt. Dafür braucht es ein Modell, das Sprachen in denselben Vektorraum abbildet, sodass eine englische Frage die passende deutsche Passage findet. Ob das gelingt, gehört explizit getestet, denn die Fähigkeit variiert stark zwischen Modellen, die sich alle als mehrsprachig bezeichnen.

Der eigene Mini-Benchmark

Die verlässlichste Entscheidungsgrundlage ist ein kleiner Benchmark auf Domänendaten, und der Aufwand dafür ist geringer als sein Ruf. Benötigt werden einige Dutzend reale Anfragen, wie Nutzer sie tatsächlich formulieren, und pro Anfrage die Angabe, welche Stellen im eigenen Bestand die Antwort enthalten. Diese Paare stammen idealerweise aus echten Suchanfragen oder aus Gesprächen mit den künftigen Nutzern, nicht vom Schreibtisch des Entwicklers.

Damit lässt sich für jedes Kandidatenmodell dieselbe Auswertung fahren: Bestand einbetten, Anfragen einbetten, prüfen, wie oft die relevanten Stellen unter den vorderen Treffern landen. Schon dieser einfache Aufbau trennt die Kandidaten deutlich schärfer als jedes öffentliche Leaderboard, weil er die eigene Sprache, die eigene Terminologie und die eigenen Dokumenttypen abbildet. Häufige Erkenntnis solcher Läufe: Zwischen den vorderen Modellen liegt auf den eigenen Daten wenig, und die Entscheidung fällt dann zu Recht über Kosten, Dimensionen und Betriebsmodell.

API oder Selbst-Hosting, und der Preis des Wechsels

Embedding-Modelle gibt es als API-Dienst und als offene Modelle zum Selbst-Hosting. Die API ist der bequeme Start: kein Betrieb, aktuelle Modelle, Skalierung inklusive. Selbst-Hosting lohnt sich in zwei Situationen: wenn Datenschutzanforderungen verlangen, dass Dokumente das eigene Umfeld nicht verlassen, oder wenn das Volumen so hoch ist, dass eigene Hardware günstiger wird. Zu bedenken ist, dass Selbst-Hosting nicht nur eine GPU bedeutet, sondern Betrieb: Verfügbarkeit, Lastspitzen, Updates.

Der wichtigste strategische Punkt kommt zum Schluss: Embeddings verschiedener Modelle sind nicht kompatibel. Ein Modellwechsel bedeutet, den gesamten Bestand neu einzubetten, und bis dahin müssen alter und neuer Index parallel betrieben oder ein Umschaltzeitpunkt geplant werden. Bei kleinen Beständen ist das ein Skript über Nacht, bei großen ein Projekt mit Kosten und Koordination. Deshalb gehört zur Modellwahl von Anfang an die Wechselfähigkeit: das verwendete Modell samt Version zu jedem Vektor speichern, die Einbettungs-Pipeline so bauen, dass ein kompletter Neuaufbau des Index jederzeit reproduzierbar durchläuft, und den eigenen Mini-Benchmark aufheben. Er ist beim nächsten Modellvergleich das wertvollste Artefakt.

Fazit

Die Wahl des Embedding-Modells ist keine Leaderboard-Frage, sondern eine Abwägung aus vier Faktoren: Retrieval-Qualität auf den eigenen, deutschsprachigen Daten, Speicher- und Kostenprofil über das erwartete Volumen, Betriebsmodell zwischen API und Selbst-Hosting sowie die Kosten eines späteren Wechsels. Ein kleiner Benchmark aus realen Anfragen und bekannten Fundstellen beantwortet die Qualitätsfrage verlässlicher als jede fremde Rangliste, und eine reproduzierbare Indexierungs-Pipeline sorgt dafür, dass die heutige Entscheidung keine endgültige sein muss.