Hirnfutter für KI-Systeme

"Eigentlich" ist es einfach: Man speichert seine Unternehmensdaten zuerst in einer SQL-Datenbank, analysiert und zerlegt sie dann in sinnvolle Häppchen (Chunks), reichert sie mit Meta-Informationen an und nutzt dann ein sogenanntes Embedding-Verfahren, um die Häppchen in einer Vektor-Datenbank zu speichern. Eigentlich. Und wie so oft gibt es kleine, feine Details zu entdecken, die später große Auswirkungen im operativen Betrieb haben.

Warum es in der KI-Ära keine One-Trick-Ponys geben sollte

In vielen meiner KI-Systeme und in der KI-Gemeinschaft setze ich seit geraumer Zeit auf mxbai-embed-large-v1 von Mixedbread als Einbettungsmodell. Es wandelt Texte in Zahlenvektoren um, damit ein Computer sie inhaltlich vergleichen kann. Es ist ein solides Arbeitspferd: schnell geladen, moderate Anforderungen an den Grafikspeicher (ca. 2 GB) und guter Durchsatz.

Doch bei der systematischen Analyse meiner eigenen Inhalte zeigen sich erhebliche Schwachstellen:

\n
• Zu kurzes Textfenster: Jedes Einbettungsmodell kann nur eine bestimmte Menge Text auf einmal verarbeiten, gemessen in sogenannten Tokens (Wortteilen). Bei mxbai liegt diese Grenze bei 512 Tokens. Bei semantischer Zerlegung meiner Inhalte werden immer noch 21% der Chunks abgeschnitten.
\n
• Verwechslung ähnlicher Inhalte: Wenn zwei Dokumente sich thematisch nahe sind, aber inhaltlich verschieden (zum Beispiel "Prompt Engineering Grundlagen" und "Fortgeschrittenes Prompting"), dann trifft mxbai nur in 40% der Fälle das richtige Dokument. In der Fachsprache nennt man das die sogenannte Hard Negative Precision.
\n
• Nicht für Deutsch optimiert: Das Modell wurde hauptsächlich mit englischen Texten trainiert. Für deutsche Inhalte funktioniert es, aber es ist nicht darauf spezialisiert.
\n

Gleichzeitig gibt es mittlerweile eine Vielzahl an Einbettungsmodellen: mehrsprachige, auf Deutsch spezialisierte, mit langen Textfenstern, mit unterschiedlichen Architekturen. Die Frage ist nicht, ob es bessere Alternativen gibt, sondern welche Alternative unter realen Bedingungen mit meinen konkreten Inhalten die beste Wahl ist.

Genau darum geht es in diesem Benchmark: Aus einer systemischen Sicht kluge Entscheidungen treffen. Nicht auf Basis von Herstellerversprechen oder theoretischen Bestenlisten, sondern auf Basis von messbaren Ergebnissen mit meinen eigenen deutschen KI-Inhalten, auf meiner eigenen Hardware, mit reproduzierbaren Messgrößen.

Benchmark V2: Statistisch robuste Methodik

Diese Seite zeigt die Ergebnisse von Benchmark V2, einer methodisch überarbeiteten Version:

\n
• 1.934 semantisch aufgeteilte Chunks statt 340 Dateien (realitätsnahe Chunk-Größen)
\n
• 5 Wiederholungen pro Messung mit festen Seeds (Reproduzierbarkeit)
\n
• 30 Hard Negative Paare statt 5 (statistische Aussagekraft)
\n
• 95%-Konfidenzintervalle für alle zentralen Metriken
\n
• 15 Keywords für Tail-End-Tests an 5 Positionen
\n

Ich vergleiche 7 Einbettungsmodelle unter identischen Bedingungen. Jedes Modell durchläuft denselben Testparcours: Geschwindigkeit, Ressourcenverbrauch, Textlängenverhalten, inhaltliche Treffsicherheit, Unterscheidungsfähigkeit und Kontextverarbeitung.

Die sieben Modelle im Vergleich

Für diesen Benchmark habe ich sieben Einbettungsmodelle ausgewählt, die alle mindestens 1024 Dimensionen erzeugen und über die Bibliothek sentence-transformers direkt geladen werden können. Die Auswahl deckt bewusst unterschiedliche Ansätze ab: rein englische Modelle, mehrsprachige Modelle und speziell für Deutsch trainierte Modelle.

Warum diese sieben?

mxbai-embed-large-v1 ist mein bisheriges Arbeitsmodell und dient als Referenzpunkt. Das Schwestermodell deepset-mxbai-embed-de-large-v1 von Mixedbread wurde auf Basis von multilingual-e5-large speziell für Deutsch nachtrainiert. Damit lässt sich direkt messen, ob eine deutsche Spezialisierung tatsächlich bessere Ergebnisse liefert.

jina-embeddings-v3 und bge-m3 sind zwei der meistgenutzten mehrsprachigen Modelle. Beide unterstützen lange Texte bis 8.192 Tokens und versprechen gute Ergebnisse über Sprachgrenzen hinweg. Qwen3-Embedding-0.6B geht noch weiter: Es basiert auf einer Decoder-Architektur (wie ein Sprachmodell) statt auf dem klassischen Encoder-Ansatz und verarbeitet bis zu 32.768 Tokens.

multilingual-e5-large-instruct bringt eine Besonderheit mit: Es kann mit natürlichsprachlichen Anweisungen gesteuert werden ("Retrieve relevant passages about..."). Und German_Semantic_V3 wurde ausschließlich mit deutschen Texten trainiert, was es zum spezialisiertesten Modell in diesem Vergleich macht.

Was alle gemeinsam haben

Alle sieben Modelle erzeugen Vektoren mit 1024 Dimensionen. Das macht die Ergebnisse direkt vergleichbar, denn die Vektorgröße beeinflusst den Speicherbedarf in der Vektor-Datenbank und die Geschwindigkeit der Ähnlichkeitssuche. Außerdem laufen alle Modelle lokal auf dem eigenen Server, ohne Cloud-Abhängigkeit oder API-Kosten.

Datenbasis und Methodik

Ein Benchmark ist nur so aussagekräftig wie die Daten, mit denen er arbeitet. Ich verwende keine künstlichen Testdatensätze, sondern meine eigenen, echten Inhalte aus der KI-Gemeinschaft und meinen KI-Systemen.

Die Daten

Die Datenbasis besteht aus 349 PHP-Dateien, die jeweils eine Inhaltsseite repräsentieren. Nach dem Parsen (HTML-Tags entfernen, reinen Text extrahieren) bleiben 340 gültige Textabschnitte übrig. Jeder Textabschnitt entspricht einer Datei, es findet kein zusätzliches Chunking statt.

Die Texte sind im Durchschnitt 7.283 Zeichen lang. Da einige Einbettungsmodelle mit sehr langen Texten Probleme haben, werden die Texte auf maximal 2.000 Zeichen gekürzt. Nach dieser Kürzung beträgt die durchschnittliche Länge 1.884 Zeichen. Das entspricht bei den meisten Modellen etwa 470 bis 660 Tokens, je nach Tokenizer.

Die Testverfahren

Jedes Modell durchläuft exakt denselben Testparcours. Die Reihenfolge der Tests und die verwendeten Texte sind für alle Modelle identisch:

• Ladezeit: Wie lange dauert es, bis das Modell einsatzbereit ist?
• Token-Analyse: Wie viele Tokens erzeugt der Tokenizer pro Text? Wie viele Texte werden am Textfenster abgeschnitten?
• Embedding-Geschwindigkeit: Wie viele Textabschnitte verarbeitet das Modell pro Sekunde?
• Ressourcenverbrauch: Wie viel Grafikspeicher und Arbeitsspeicher benötigt das Modell?
• Normalisierung: Liefert das Modell bereits normalisierte Vektoren?
• PCA-Analyse: Wie effizient nutzt das Modell seine 1024 Dimensionen?
• Paarweise Cosine-Similarity: Wie stark unterscheidet das Modell zwischen verschiedenen Texten?
• Self-Retrieval: Findet das Modell einen Text anhand seiner eigenen Kurzfassung wieder?
• Deutsche Testqueries: Wie gut beantwortet das Modell fünf deutsche Suchanfragen?
• Tail-End Sensitivity: Erkennt das Modell Informationen am Ende langer Texte?
• Hard Negatives: Unterscheidet das Modell ähnliche, aber verschiedene Dokumente?

Zwischen den Modellen

Nach jedem Modell wird der GPU-Speicher vollständig freigegeben. Das ist wichtig, weil verbliebene Speicherfragmente die Messungen des nächsten Modells verfälschen würden. Jedes Modell startet unter identischen Bedingungen.

Performance: Geschwindigkeit und Ressourcenverbrauch

Qualität allein reicht nicht. Ein Einbettungsmodell, das hervorragende Ergebnisse liefert, aber zehn Mal so lange braucht oder den Grafikspeicher sprengt, ist im Alltag unpraktisch. Deshalb messe ich zuerst die harten Fakten: Wie schnell laden die Modelle? Wie viele Texte schaffen sie pro Sekunde? Wie viel Speicher brauchen sie?

Benchmark V2: Diese Messungen basieren auf 1.934 semantisch aufgeteilten Textabschnitten (nicht 349 wie in V1). Jede Messung wurde 5× wiederholt mit festen Seeds für Reproduzierbarkeit.

Geschwindigkeit

jina-v3 ist der klare Geschwindigkeitssieger mit 51,7 Textabschnitten pro Sekunde, mehr als doppelt so schnell wie der langsamste Kandidat Qwen3 (14,0 Chunks/s). Der Vorsprung gegenüber V1 erklärt sich durch die größere Datenmenge: Mit 1.934 statt 349 Chunks kann die GPU ihre Parallelverarbeitung besser ausnutzen.

Die Mittelfeld-Modelle (mxbai-de, e5-instruct, mxbai, German V3, bge-m3) liegen alle zwischen 21 und 24 Chunks/s; praktisch gleichauf. Hier entscheiden andere Faktoren wie Qualität oder Speicherbedarf.

Speicherverbrauch

Beim Grafikspeicher gibt es enorme Unterschiede. mxbai ist mit 2,1 GB der sparsamste Kandidat. Am anderen Ende steht German_Semantic_V3 mit über 10 GB VRAM, obwohl es mit 335 Millionen Parametern eines der kleinsten Modelle ist. Das deutet auf eine weniger optimierte Implementierung hin.

Für einen Server mit 20 GB VRAM bedeutet das: mxbai lässt genug Platz für andere Prozesse, während German V3 mehr als die Hälfte des gesamten Speichers belegt. jina-v3 liegt mit 6,2 GB im Mittelfeld, das ist vertretbar für die Geschwindigkeit, die es liefert.

Ladezeiten

Die Ladezeit fällt nur einmal an, beim Start des Systems. mxbai ist mit 2,0 Sekunden fast sofort bereit. Auffällig: mxbai-de braucht mit 33 Sekunden am längsten, wahrscheinlich wegen des größeren deutschen Vokabulars, das geladen werden muss.

Token-Analyse: Wie viel Text geht verloren?

Eines der wichtigsten Qualitätskriterien ist das Textfenster: Wie viele Tokens kann ein Modell maximal verarbeiten? Text, der über dieses Limit hinausgeht, wird abgeschnitten und fließt nicht in den Zahlenvektor ein. Das Modell sieht diesen Teil des Textes schlicht nicht.

Das mxbai-Problem

Die Zahlen sind eindeutig: Bei mxbai werden 93,2% aller Textabschnitte abgeschnitten. Das liegt daran, dass mxbai einen englisch-optimierten Tokenizer verwendet, der deutsche Texte in deutlich mehr Tokens zerlegt als ein mehrsprachiger Tokenizer. Im Schnitt erzeugt mxbai 657 Tokens pro Text, während die mehrsprachigen Modelle mit denselben Texten nur auf 484 Tokens kommen.

Das bedeutet: mxbai verliert bei fast jedem deutschen Text einen erheblichen Teil der Information. Ein Text, der 657 Tokens lang ist, wird auf 512 gekürzt. Die letzten 22% des Textes verschwinden einfach.

Die Lösung: Längere Textfenster

jina-v3, bge-m3 und Qwen3 haben dieses Problem nicht. Mit Textfenstern von 8.192 bzw. 32.768 Tokens passen alle 340 Textabschnitte vollständig hinein, ohne Abschneidung. Kein einziger Text geht verloren.

Die deutschsprachigen Modelle (mxbai-de, German V3) und e5-instruct liegen dazwischen: Ihre mehrsprachigen Tokenizer sind effizienter als der von mxbai, aber bei rund einem Viertel der Texte wird trotzdem abgeschnitten. Das ist besser als 93%, aber immer noch ein spürbarer Informationsverlust.

Warum der Tokenizer entscheidet

Der Unterschied zwischen 657 und 484 Tokens für denselben Text liegt allein am Tokenizer. Ein englisch trainierter Tokenizer kennt deutsche Wörter nicht als Ganzes und zerlegt sie in viele kleine Teile. Das Wort "Qualitätskontrolle" könnte in fünf oder sechs Tokens aufgeteilt werden, während ein mehrsprachiger Tokenizer es in zwei oder drei schafft. Bei 340 Texten summiert sich das erheblich.

Semantische Qualität: Wie gut verstehen die Modelle den Inhalt?

Geschwindigkeit und Speicher sind wichtig, aber letztlich zählt, wie gut ein Modell den Inhalt eines Textes erfasst. Dafür messe ich zwei Kernmetriken: Wie stark unterscheidet das Modell zwischen verschiedenen Texten? Und findet es einen Text anhand einer Kurzfassung wieder?

Benchmark V2: Alle Messungen basieren auf 1.934 semantisch aufgeteilten Chunks. Jede Messung wurde 5× wiederholt mit festen Seeds. Die Tabellen zeigen Mittelwerte mit 95%-Konfidenzintervallen.

Self-Retrieval: Den eigenen Text wiederfinden

Beim Self-Retrieval nehme ich die ersten 50 Wörter jedes Chunks als Suchanfrage und prüfe, ob das Modell den Originaltext als erstes Ergebnis zurückliefert.

German_Semantic_V3 erreicht nahezu perfekte 99,95%: Nur 1 von 1.934 Chunks wird nicht als Top-1 gefunden. Das ist bemerkenswert für ein Modell, das in anderen Tests schwächelt. bge-m3 folgt mit 99,17%.

Überraschend: jina-v3 liegt hinten mit "nur" 95,92%. Das bedeutet: Bei etwa 80 Chunks findet das Modell nicht den Originaltext als erstes Ergebnis. In der Praxis ist das selten relevant, aber es zeigt eine Grenze des Modells.

Unterscheidungsfähigkeit: Paarweise Cosine-Similarity

Wenn ein Modell allen Texten sehr ähnliche Zahlenvektoren zuweist, kann es schlecht zwischen ihnen unterscheiden. Ein niedriger Wert bedeutet: Das Modell erzeugt gut unterscheidbare Vektoren.

jina-v3 und Qwen3 unterscheiden am besten zwischen verschiedenen Texten. Das klingt kontraintuitiv: Ist ein niedriger Ähnlichkeitswert nicht schlecht? Nein, denn hier geht es um die Ähnlichkeit zwischen verschiedenen Texten. Je niedriger, desto besser kann das Modell feine Unterschiede erfassen.

Am anderen Ende steht e5-instruct mit 0,850. Für dieses Modell sehen sich fast alle Texte sehr ähnlich. Die Streuung (Std.-Abw. 0,034) ist minimal. Das Modell komprimiert Bedeutungsunterschiede in einen sehr engen Bereich: gut für robuste Suche, schlecht für feine Unterscheidung.

Das Paradox von German V3

German_Semantic_V3 zeigt ein interessantes Muster: Beste Self-Retrieval-Werte, aber mittelmäßige Unterscheidungsfähigkeit. Das Modell ist offenbar darauf optimiert, den eigenen Text präzise wiederzuerkennen, aber nicht unbedingt ähnliche Texte sauber zu trennen. Für RAG-Systeme mit vielen ähnlichen Dokumenten kann das problematisch sein.

Hard Negatives: Ähnliches unterscheiden

Der anspruchsvollste Test in diesem Benchmark prüft, ob ein Modell thematisch verwandte, aber inhaltlich verschiedene Dokumente auseinanderhalten kann. Dieser Test heißt Hard Negative Precision und simuliert eine realistische Suchanforderung: Der Nutzer sucht etwas Bestimmtes, und im Bestand gibt es passende und leicht verwechselbare Treffer.

Benchmark V2: Statt nur 5 Testpaaren verwende ich jetzt 30 Paare, statistisch deutlich aussagekräftiger. Die Paare stammen aus semantisch aufgeteilten Chunks (nicht ganze Dateien), was näher an der Produktionsrealität liegt.

Metriken erklärt

• Precision@1: Wie oft ist der beste Treffer der richtige? (Höher = besser)
• Recall@5: Ist der richtige Treffer unter den Top 5? (Höher = besser)
• MRR: Mean Reciprocal Rank: auf welcher Position erscheint der richtige Treffer im Schnitt? (Höher = besser)

Ergebnisse (30 Testpaare)

Was bedeutet das?

e5-instruct und mxbai-de teilen sich den ersten Platz mit 70% Precision@1. Bei 30 schwierigen Testpaaren ist das ein solides Ergebnis. e5-instruct hat den leicht besseren Recall@5: Wenn der erste Treffer nicht stimmt, ist der richtige zumindest unter den Top 5.

Interessant: jina-v3 fällt gegenüber V1 zurück. Mit nur 5 Testpaaren hatte es noch 100% erreicht; mit 30 Paaren zeigt sich, dass es bei ähnlichen Dokumenten schwächelt (73,3% Recall@5 ist der zweitschlechteste Wert).

mxbai bleibt das Schlusslicht mit nur 40% Precision@1. Das englischsprachige Basismodell tut sich mit deutschen Nuancen schwer. Auch German_Semantic_V3 enttäuscht: Trotz Spezialisierung auf Deutsch erreicht es nur 43,3%.

Praktische Bedeutung

Für ein RAG-System bedeutet das: Mit e5-instruct oder mxbai-de bekommt der Nutzer in 7 von 10 Fällen sofort den richtigen Kontext. Mit mxbai nur in 4 von 10 Fällen: Das macht den Unterschied zwischen einer hilfreichen und einer frustrierenden KI-Assistenz.

Warum gleich lange Vektoren entscheidend sind

Gedankenspiel: Zwei Texte werden als Zahlenlisten dargestellt. Das eine Modell erzeugt dabei Vektoren mit einer durchschnittlichen Länge von 1,0 und das andere mit einer Länge von 24,2. Klingt erstmal egal, ist es aber nicht: Wenn ich die Ähnlichkeit zweier Texte über den Winkel zwischen ihren Vektoren berechne (das nennt sich Cosine-Similarity), dann funktioniert das besser, wenn alle Vektoren auf die gleiche Länge gebracht werden. Diesen Vorgang nennt man Normalisierung.

Fünf der sieben Modelle liefern bereits normalisierte Vektoren (Länge = 1,0). Zwei stechen heraus:

Die beiden nicht-normalisierten Modelle, mxbai-embed-large-v1 und German_Semantic_V3, erfordern eine nachträgliche Normalisierung vor dem Speichern in Qdrant. Das ist kein Ausschlusskriterium, aber ein zusätzlicher Schritt, der bei der Integration bedacht werden muss.

Wie viele Dimensionen werden tatsächlich genutzt?

Alle sieben Modelle erzeugen 1024-dimensionale Vektoren. Aber nutzen sie diese Dimensionen auch wirklich aus? Um das herauszufinden, habe ich eine Methode namens PCA angewendet (Hauptkomponentenanalyse). Sie zeigt, wie viele Dimensionen nötig sind, um einen bestimmten Anteil der Informationen abzubilden.

Das Ergebnis überrascht: Bei allen Modellen reichen bereits 51 von 1024 Dimensionen, um 95 Prozent der Varianz abzudecken. Das bedeutet, dass der Informationsgehalt stark konzentriert ist. Interessanter ist der Blick auf die ersten zehn Dimensionen:

German_Semantic_V3 konzentriert die meiste Information in wenigen Dimensionen: Allein die erste Dimension erklärt 16 Prozent der gesamten Varianz. Das kann bedeuten, dass dieses Modell einen starken "Generalfaktor" hat, der alle Texte ähnlich einfärbt. Bei bge-m3 ist die Information am gleichmäßigsten über die Dimensionen verteilt, was auf eine differenziertere Repräsentation hinweist.

Die durchschnittliche paarweise Cosine-Similarity zeigt, wie stark sich die Vektoren im Corpus ähneln. Ein niedriger Wert bedeutet bessere Unterscheidungsfähigkeit. Hier liegen jina-embeddings-v3 (0,327) und Qwen3 (0,357) vorn. multilingual-e5-large-instruct (0,854) erzeugt dagegen Vektoren, die sich alle relativ ähnlich sehen, was die Unterscheidung feiner Bedeutungsunterschiede erschwert.

Was passiert mit Informationen am Ende langer Texte?

Jedes Embedding-Modell hat ein begrenztes Kontextfenster, typischerweise 512 oder 8192 Token. Aber selbst innerhalb dieses Fensters verarbeiten Modelle nicht jeden Textabschnitt gleich aufmerksam. Informationen, die am Ende eines langen Textes stehen, gehen oft unter. Dieses Phänomen heißt Tail-End Sensitivity und ist für die Praxis hochrelevant: Wenn ein entscheidender Fachbegriff erst im letzten Absatz auftaucht, findet das Modell den Text womöglich nicht mehr.

Benchmark V2: Statt einem einzelnen Keyword teste ich jetzt 15 verschiedene Fachbegriffe, jeweils an 5 Positionen im Text (10%, 30%, 50%, 70%, 90%). Das ergibt 75 Messpunkte pro Modell, statistisch deutlich robuster.

Mean Tail Retention

Die zentrale Metrik: Wie viel vom Keyword-Signal bleibt erhalten, wenn der Begriff weiter hinten im Text steht?

Was bedeutet "Δ bei 90%"?

Diese Spalte zeigt, wie stark das Signal zusätzlich abfällt, wenn der Begriff ganz am Ende (90% Position) steht statt in der Mitte. Ein Wert von 0% bedeutet: Das Modell behandelt alle Positionen gleich: ideal. Ein hoher Wert (wie 20% bei jina-v3) bedeutet: Das Modell "vergisst" Informationen am Textende überproportional.

Interpretation

e5-instruct ist der klare Sieger mit 83,6% Retention und konstantem Verhalten über alle Positionen. mxbai-de folgt dicht dahinter. Beide Modelle eignen sich für längere Texte ohne spezielle Chunking-Strategien.

jina-v3 überrascht negativ: Trotz des großen Kontextfensters (8192 Token) behält es nur 23,7% des Signals und verliert am Ende nochmal 20%. Das widerspricht der Intuition, dass größere Fenster automatisch besser sind. Offenbar wurde das Modell nicht für lange Einzeltexte optimiert, sondern für Retrieval mit kürzeren Chunks.

German_Semantic_V3 zeigt ähnlich schwache Werte (30,3%), aber immerhin keinen zusätzlichen Abfall am Ende. Das Modell hat generell Probleme mit langen Texten, nicht speziell mit dem Ende.

Praktische Konsequenz

Für Modelle mit niedriger Tail Retention ist gutes Chunking Pflicht. Bei jina-v3 oder German V3 sollten Chunks unter 300 Token bleiben. Bei e5-instruct oder mxbai-de können auch längere Abschnitte funktionieren.

Welches Modell findet die richtige Antwort?

Zahlen und Metriken sind wichtig, aber am Ende zählt die praktische Frage: Wenn ich etwas suche, findet das Modell den richtigen Inhalt? Dafür habe ich fünf deutschsprachige Suchanfragen formuliert und für jedes Modell die beste Übereinstimmung ermittelt.

"Wie funktioniert maschinelles Lernen?"

Fast alle Modelle liefern als bestes Ergebnis die Seite über Systeme, die mitlernen. multilingual-e5-large-instruct liegt mit einem Score von 0,871 weit vorn, gefolgt von deepset-mxbai-embed-de-large-v1 (0,800). jina-embeddings-v3 findet zwar die richtige Seite, aber mit einem deutlich niedrigeren Score von 0,394.

"Was ist ein neuronales Netz?"

Hier zeigen sich die größten Unterschiede: multilingual-e5-large-instruct und deepset-mxbai liefern hohe Scores (0,823 und 0,743), während jina-embeddings-v3 mit 0,211 kaum noch eine sinnvolle Zuordnung schafft. Interessant: Die Modelle finden unterschiedliche Seiten als bestes Ergebnis, was zeigt, wie verschieden sie "neuronales Netz" im Kontext interpretieren.

"Prompt Engineering Techniken"

Die spezialisierten Modelle wie deepset-mxbai (0,785) und multilingual-e5 (0,875) erzielen hier die höchsten Scores. German_Semantic_V3, Qwen3 und jina-embeddings-v3 finden alle die richtige Seite über Advanced Prompting, allerdings mit niedrigeren Confidence-Werten.

"KI-gestützte Code-Analyse"

multilingual-e5-large-instruct dominiert erneut mit 0,894. Alle Modelle finden relevante Seiten zum Thema Code und KI, wobei mxbai-embed-large-v1 (0,744) und deepset-mxbai (0,820) ebenfalls starke Ergebnisse liefern.

"Ethik und künstliche Intelligenz"

Vier von sieben Modellen finden die Seite über Gesellschaft und Ethik als Top-Ergebnis. multilingual-e5 erreicht 0,900, deepset-mxbai 0,835. German_Semantic_V3 ordnet die Anfrage dagegen eher dem Thema "menschliche Intelligenz" zu (0,551), was semantisch nachvollziehbar, aber weniger präzise ist.

Self-Retrieval: Findet sich jeder Text selbst?

Ein grundlegender Test: Wenn ich die ersten 50 Wörter eines Textes als Suchanfrage verwende, sollte der Originaltext als bestes Ergebnis erscheinen. Bei 340 Chunks erreichen German_Semantic_V3 (100%), bge-m3 und multilingual-e5 (je 99,1%) die besten Werte. Alle Modelle liegen über 97%, was zeigt, dass die grundlegende Self-Retrieval-Fähigkeit bei allen gegeben ist.

Die Gesamtbewertung

Nach sieben Modellen, 1.934 semantisch aufgeteilten Chunks, 5 Wiederholungen pro Metrik und über einem Dutzend Messwerten verdichtet sich das Bild. Kein Modell ist in allen Kategorien das beste. Aber es gibt klare Profile, die je nach Einsatzzweck die Entscheidung erleichtern.

Benchmark V2 vs. V1: Die erweiterte Testmethodik (30 statt 5 Hard Negatives, statistisch robuste Wiederholungen) hat die Rangfolge teilweise deutlich verändert. Was mit wenigen Testfällen nach 100% aussah, relativiert sich bei 30 Paaren.

Die Spalte "Diskrim." zeigt die durchschnittliche paarweise Cosine-Similarity: Je niedriger der Wert, desto besser unterscheidet das Modell zwischen verschiedenen Texten.

Meine Empfehlungen nach Benchmark V2

Für deutschsprachige Produktivsysteme: e5-instruct hat sich als überraschender Gewinner etabliert. Beste Hard Negative Precision (70%) und Tail Retention (83,6%) bei nur 2,5 GB VRAM. Der Nachteil: Hohe Intra-Corpus-Similarity (0,850) kann bei sehr ähnlichen Dokumenten problematisch werden. mxbai-de ist eine gute Alternative mit ausgeglichenerem Profil.

Für maximale Self-Retrieval-Genauigkeit: German_Semantic_V3 erreicht 99,95%, praktisch perfekt. Der Preis: 10,6 GB VRAM und schwache Hard Negative Precision (43%). Nur sinnvoll, wenn exaktes Wiederfinden wichtiger ist als Unterscheidung ähnlicher Dokumente.

Für hohe Geschwindigkeit: jina-v3 bleibt unangefochtener Geschwindigkeitssieger mit 51,7 Chunks/s. Aber Vorsicht: Die katastrophale Tail Retention (23,7%) erfordert kurze Chunks unter 300 Token. Und die niedrigste Self-Retrieval-Accuracy (95,9%) zeigt, dass Geschwindigkeit ihren Preis hat.

Für minimalen Ressourcenverbrauch: mxbai braucht nur 2,1 GB VRAM. Die Hard Negative Precision von 40% ist allerdings zu niedrig für anspruchsvolle Anwendungen. e5-instruct mit 2,5 GB ist die bessere Wahl.

Für beste semantische Unterscheidung: jina-v3 (0,316) und Qwen3 (0,351) erzeugen die am besten unterscheidbaren Vektoren. Beide eignen sich für Anwendungen, wo feine semantische Nuancen zählen, aber nur mit gutem Chunking.

Dimensionen und Faktoren für die Modellwahl

Nicht jedes Einbettungsmodell passt zu jedem Anwendungsfall. Die Wahl hängt von drei Faktoren ab: Was hast Du an Hardware? Was willst Du damit machen? Und was ist Dir bei der Qualität wichtig?

Hardware-Constraints: Was hast Du?

Anwendungsfälle: Was willst Du?

Metrik-Gewichtungen

Je nach Priorität gewichtest Du die Benchmark-Metriken unterschiedlich (0 = egal, 5 = kritisch):

Normalisierte Benchmark-Scores

Werte von 0 (schlechtester im Test) bis 100 (bester im Test):

Beispiel-Szenarien

Szenario A: Kleiner Server, RAG-Chatbot

• GPU: Ja, aber nur 4 GB VRAM
• Use Case: RAG
• Priorität: Hard Negative Precision hoch
• → Empfehlung: e5-instruct (2,5 GB VRAM, 70% HardNeg, 84% TailEnd)

Szenario B: Maximale Geschwindigkeit

• GPU: Ja, 8+ GB VRAM
• Use Case: Echtzeit-Suche
• Priorität: Speed kritisch, kurze Chunks OK
• → Empfehlung: jina-v3 (51,7 Chunks/s, beste Discrimination)

Szenario C: Nur CPU

• GPU: Nein
• Use Case: Dokument-Clustering
• Priorität: Niedriger RAM-Verbrauch
• → Empfehlung: mxbai (2,1 GB, läuft auch auf CPU gut)

Szenario D: Lange deutsche Texte

• GPU: Ja, 6+ GB VRAM
• Use Case: Lange Dokumente, deutsch
• Priorität: Tail-End Retention, Hard Negatives
• → Empfehlung: mxbai-de (77% TailEnd, 70% HardNeg)

Finde Dein Modell

Stelle Deine Hardware-Constraints ein, wähle Deinen Anwendungsfall und gewichte die Metriken nach Deinen Prioritäten. Das Tool berechnet live, welches Einbettungsmodell am besten zur gegebenen Aufgabe passt.