Identifizierung von Einbettungsmodellen anhand numerischer Rohwerte

Embedding-Modelle sind Blackboxen. Sie geben Text ein und erhalten einen Vektor zurück. Eine Liste von Gleitkommazahlen ohne Label, ohne Wasserzeichen und ohne Metadaten, die Ihnen verraten, woher sie stammen. Wenn Ihnen jemand einen 1024-dimensionalen Vektor gibt, können Sie sagen, ob er von BGE-M3, jina-embeddings-v5-text-small oder Qwen3-Embedding erzeugt wurde? Und selbst wenn zwei Vektoren vom selben Modell stammen, können Sie erkennen, ob sie mit einer Retrieval- oder einer Klassifizierungsanweisung generiert wurden?

Es stellt sich heraus: Man kann es. Die numerischen Muster in einem Embedding-Vektor tragen einen überraschend deutlichen Fingerabdruck des Modells, das ihn erzeugt hat, und sogar des während der Inferenz verwendeten Prompts. Wir haben einen kleinen Transformer-Klassifikator (800.000 Parameter) trainiert, um 68 verschiedene Modell-Aufgaben-Kombinationen von über 25 Embedding-Modellen zu identifizieren. Dabei erreichten wir eine Genauigkeit von 87 %, indem wir nichts als die rohen Gleitkommazahlen analysierten. Sie können die Live-Demo selbst ausprobieren: Fügen Sie einen beliebigen Embedding-Vektor ein und sehen Sie, welches Modell und welche Aufgabe der Klassifikator dahinter vermutet.

tagTokenisierung: Zahlen als Text behandeln

Ein 1024-dimensionaler Embedding-Vektor ist eine Sequenz von 1024 Gleitkommazahlen. Um ihn in einen Klassifikator einzuspeisen, benötigen wir eine Darstellung, die keine Annahmen über die Struktur der Werte trifft.

Wir wählen einen mutigen Ansatz: Wir behandeln jede Gleitkommazahl als eine Zeichenfolge aus Ziffern und tokenisieren sie Zeichen für Zeichen. Das mag im Vergleich zu kompakteren Alternativen verschwenderisch klingen, erweist sich aber als der richtige Kompromiss. Für einen Wert wie -0.1234 lautet die Token-Sequenz:

- 0 . 1 2 3 4
Kopieren

Dimensionen werden durch ein [SEP]-Token getrennt. Die vollständige Sequenz beginnt mit [CLS]. Das gesamte Vokabular umfasst 15 Tokens:

Bei einer Präzision von 4 Dezimalstellen erzeugt ein 1024-dimensionaler Vektor etwa 7.700 Tokens. Ein 384-dimensionaler Vektor erzeugt etwa 2.900 Tokens. Die Sequenzlänge variiert natürlich mit der Embedding-Dimension, und es ist kein Padding oder Truncation über die Dimensionen hinweg erforderlich. Da der Tokenizer ein direktes Integer-Mapping ohne gelernte Komponenten ist, arbeitet er extrem effizient.

tagModellarchitektur

Der Klassifikator ist ein kleiner Encoder-only Transformer mit 4 Layern, 128 Dimensionen, 4 Attention-Heads mit RoPE, SwiGLU FFN und RMSNorm. Das CLS-Token wird gepoolt und in den 68-Klassen-Ausgaberaum projiziert. Die Gesamtparameterzahl liegt bei etwa 800.000.

Trotz des winzigen Vokabulars von 15 Tokens handelt es sich grundlegend um eine Long-Sequence-Aufgabe. Ein einzelnes 1024-dimensionales Embedding wird zu einer Sequenz von 7.700 Tokens, was länger ist als typische NLP-Eingaben. Das Modell muss Tausende von Ziffern-Tokens verarbeiten, um statistische Muster zu erkennen, die die Ausgabe eines Modells von einem anderen unterscheiden. Dies macht effiziente Attention-Mechanismen und Positionskodierung (RoPE) selbst in diesem kleinen Maßstab unerlässlich.

tagDaten

Wir haben 10.000 mehrsprachige Textproben verwendet, die jeweils von über 25 Modellen mit verschiedenen Aufgaben-Präfixen wie retrieval.query, retrieval.document, classification und clustering eingebettet wurden, woraus 68 verschiedene Klassen resultierten. Wichtig ist, dass die 68 Klassen nicht nur verschiedene Modelle umfassen, sondern auch verschiedene Instruktions-Prompts, die auf dasselbe Modell angewendet wurden. Zum Beispiel werden jina-embeddings-v5-text-small mit einer Retrieval-Anweisung und jina-embeddings-v5-text-small mit einer Klassifizierungsanweisung als separate Klassen behandelt. Das Ziel ist es, sowohl die Modellidentität als auch das aufgabenspezifische Verhalten allein aus der rohen Ausgabe zu erkennen.

Jede Klasse ist in 7.000 Trainings- und 3.000 Validierungsproben unterteilt. Die Modelle decken fünf Ausgabedimensionen ab.

Allein in der 1024-Dimensionen-Gruppe gibt es 32 Klassen zu unterscheiden, einschließlich Modellen aus derselben Familie mit unterschiedlichen Aufgaben-Präfixen. Der Klassifikator kann sich hier nicht auf die Sequenzlänge verlassen; er muss rein numerische Muster lernen.

tagTraining

Das Training lief auf einer A100 40GB mit Mixed Precision, nach Länge gruppiertem Batching (length-bucketed batching) und AdamW mit Cosine-Schedule. Dabei wurden etwa 340.000 Tokens pro Sekunde und 23.800 Schritte pro Epoche erreicht.

tagExperimentelle Ergebnisse

Die geringe Lücke zwischen Training und Validierung sowie die kontinuierliche Verbesserung deuten auf generalisierbares Lernen statt auf bloßes Auswendiglernen hin. Mit 800.000 Parametern nähert sich das Modell seiner Kapazitätsgrenze; ein größeres Modell würde die Genauigkeit wahrscheinlich noch weiter steigern.

tagKonfusionsmatrix

Die Gesamtgenauigkeit liegt bei 87,0 %, was 59-mal besser ist als der Zufallswert von 1,5 %. Mehrere Modelle werden perfekt klassifiziert, darunter GTE-large, die Klassifizierungs-Varianten von jina-embeddings-v3/jina-embeddings-v5-text-small, LaBSE und Paraphrase MiniLM. Die schwierigsten Fälle sind Aufgaben-Präfix-Varianten desselben Basismodells. Qwen3-0.6B weist die meisten Verwechslungen innerhalb der Modellfamilie über seine 4 Aufgabentypen hinweg auf, während jina-embeddings-v5-text-small eine Genauigkeit von 92 % innerhalb der Modellfamilie über 5 Aufgaben hinweg erreicht. Dass unterschiedliche Instruktions-Prompts beim gleichen Modell unterscheidbare Ausgabemuster erzeugen, ist an sich eine bemerkenswerte Erkenntnis und deutet darauf hin, dass die Aufgabenanpassung eine messbare numerische Spur hinterlässt, selbst wenn die Basisgewichte identisch sind.

Modelle aus verschiedenen Familien (BGE vs. Jina vs. E5 vs. Nomic) lassen sich viel leichter trennen als Aufgaben-Varianten desselben Modells. Die Kernarchitektur und die Trainingsmethodik hinterlassen eine stärkere Signatur als aufgabenspezifische Adapter. Die eigentliche Herausforderung liegt in der 1024-Dimensionen-Gruppe (32 Klassen) und der 768-Dimensionen-Gruppe (24 Klassen), in denen sich der Klassifikator rein auf numerische Muster statt auf die Sequenzlänge verlassen muss.

tagAlternative Ansätze

tagBucket-Tokenisierung

Hierbei wird jede Dimension in einen von K Bins (z. B. 256) quantisiert, was eine kompakte Sequenz der Länge D erzeugt – ein Token pro Dimension. Dies ist der Ansatz, der vom Embedding-Converter (ICLR 2025) verwendet wird. Für einen 1024-dimensionalen Vektor erhält man 1.024 Tokens anstelle von 7.700.

Bucketing setzt jedoch eine Annahme über die Werteverteilung voraus. Man muss die Bin-Grenzen festlegen, bevor man die Daten sieht. Verschiedene Modelle verteilen ihre Werte jedoch auf grundlegend unterschiedliche Weise. Einige konzentrieren die Masse in einem engen Bereich um Null, andere verteilen die Werte gleichmäßig über [-1, 1], und die Verteilung variiert innerhalb eines einzelnen Modells je nach Dimension. Jedes feste Binning-Schema verschwendet entweder Auflösung dort, wo sich Werte häufen, oder löst dort zu grob auf, wo sie weit gestreut sind. Eine adaptive Bin-Einteilung pro Modell würde den Zweck verfehlen, da man dafür die Modellidentität bereits im Vorhinein kennen müsste.

tagMLP mit fester Länge

Dabei wird der rohe Embedding-Vektor direkt in einen MLP-Klassifikator eingespeist. Das grundlegende Problem geht über die Frage der variablen Dimensionen hinaus (unsere Modelle erzeugen Vektoren von 384 bis 1536 Dimensionen). Selbst wenn man alles auf eine feste Länge auffüllt (Padding), geht man implizit davon aus, dass die Dimensionsindizes über Modelle hinweg semantisch ausgerichtet sind – dass also Dimension 1 von BGE-M3 der Dimension 1 von jina-embeddings-v5-text-small entspricht. Diese Annahme ist falsch. Unterschiedliche Architekturen, Trainingsdaten und Trainingsziele erzeugen völlig unterschiedliche interne Repräsentationen.

Beide Alternativen erzwingen strukturelle Annahmen, die das Modell umgehen muss. Die Tokenisierung auf Ziffernebene vermeidet diese. Es ist die annahmefreieste Darstellung, die wir finden konnten: Hier sind die exakten Ziffern jeder Zahl in der richtigen Reihenfolge, getrennt durch Markierungen. Den Rest muss das Modell selbst herausfinden.

tagFazit

Embedding-Modelle werden darauf trainiert, semantisch ähnliche Texte auf nahe beieinander liegende Vektoren abzubilden. Das Trainingsziel sagt nichts darüber aus, die Vektoren identifizierbar zu machen oder eine Modellsignatur zu kodieren. Dennoch ist die Signatur vorhanden und stark genug, um von einem winzigen Klassifikator erkannt zu werden. Der „Stil“ eines Embedding-Modells – die spezifischen numerischen Muster, die es zur Darstellung von Bedeutung verwendet – ist so unverwechselbar wie eine Handschrift. Sogar die Wahl des Instruktions-Prompts hinterlässt eine nachweisbare Spur.

Dies hat praktischen Nutzen für das Auditieren von Vektordatenbanken, wenn das Quellmodell unbekannt ist, für die Überprüfung, ob eine API tatsächlich das angegebene Modell verwendet, und für das Erkennen von Modellversionsänderungen. Grundsätzlich zeigt es uns, dass Embedding-Modelle Bedeutung auf strukturell unterschiedliche Weise kodieren, selbst wenn sie Vektoren mit der gleichen Dimensionalität erzeugen.