Identifier les modèles d'embeddings à partir de valeurs numériques brutes

Les modèles d'embeddings sont des boîtes noires. Vous y envoyez du texte, vous en sortez un vecteur. Une liste de nombres à virgule flottante sans étiquette, sans filigrane, sans métadonnées vous indiquant d'où elle provient. Si quelqu'un vous remet un vecteur de 1024 dimensions, pouvez-vous dire s'il a été produit par BGE-M3, jina-embeddings-v5-text-small ou Qwen3-Embedding ? Et même si deux vecteurs proviennent du même modèle, pouvez-vous dire s'ils ont été générés avec une instruction de recherche ou de classification ?

Il s'avère que c'est possible. Les motifs numériques dans un vecteur d'embedding portent une empreinte étonnamment forte du modèle qui l'a produit, et même du prompt d'instruction utilisé lors de l'inférence. Nous avons entraîné un petit classificateur transformer (800K paramètres) pour identifier 68 combinaisons différentes de modèles et de tâches à partir de plus de 25 modèles d'embeddings, atteignant une précision de 87 % en ne lisant rien d'autre que les chiffres bruts à virgule flottante. Vous pouvez essayer la démo en direct vous-même : collez n'importe quel vecteur d'embedding et voyez quel modèle et quelle tâche le classificateur pense avoir produits.

tagTokenization : traiter les nombres comme du texte

Un vecteur d'embedding de 1024 dimensions est une séquence de 1024 nombres à virgule flottante. Pour l'injecter dans un classificateur, nous avons besoin d'une représentation qui ne fait aucune hypothèse sur la structure des valeurs.

Nous avons adopté une approche audacieuse : traiter chaque nombre flottant comme une chaîne de caractères numériques et le diviser en tokens caractère par caractère. Cela peut sembler inefficace par rapport à des alternatives plus compactes, mais il s'avère que c'est le bon compromis. Pour une valeur comme -0.1234, la séquence de tokens est :

- 0 . 1 2 3 4
Copier

Les dimensions sont séparées par un token [SEP]. La séquence complète commence par [CLS]. Le vocabulaire complet contient 15 tokens :

Avec une précision de 4 décimales, un vecteur de 1024 dimensions produit environ 7 700 tokens. Un vecteur de 384 dimensions produit environ 2 900 tokens. La longueur de la séquence varie naturellement avec la dimension de l'embedding, et aucun remplissage (padding) ou troncature n'est nécessaire entre les dimensions. Comme le tokenizer est un mappage direct d'entiers sans composants appris, il est extrêmement efficace.

tagArchitecture du modèle

Le classificateur est un petit transformer de type encodeur seul avec 4 couches, 128 dimensions, 4 têtes d'attention avec RoPE, SwiGLU FFN et RMSNorm. Le token CLS est regroupé (pooled) et projeté dans l'espace de sortie de 68 classes. Le nombre total de paramètres est d'environ 800K.

Malgré le minuscule vocabulaire de 15 tokens, il s'agit fondamentalement d'une tâche de longue séquence. Un seul embedding de 1024 dimensions devient une séquence de 7 700 tokens, soit plus que les entrées NLP typiques. Le modèle doit traiter des milliers de tokens de chiffres pour capter les motifs statistiques qui distinguent la sortie d'un modèle d'un autre. Cela rend l'attention efficace et le codage positionnel (RoPE) essentiels, même à cette petite échelle.

tagDonnées

Nous avons utilisé 10 000 échantillons de texte multilingues, chacun converti en embedding par plus de 25 modèles avec divers préfixes de tâche tels que retrieval.query, retrieval.document, classification et clustering, produisant 68 classes distinctes. Fait important, les 68 classes incluent non seulement différents modèles, mais aussi différents prompts d'instruction appliqués au même modèle. Par exemple, jina-embeddings-v5-text-small avec une instruction de recherche et jina-embeddings-v5-text-small avec une instruction de classification sont traités comme des classes distinctes. L'objectif est de détecter à la fois l'identité du modèle et le comportement spécifique à la tâche à partir de la seule sortie brute.

Chaque classe est divisée en 7 000 échantillons d'entraînement et 3 000 échantillons de validation. Les modèles couvrent cinq dimensions de sortie.

Dans le seul groupe de 1024 dimensions, il y a 32 classes à séparer, incluant des modèles de la même famille avec différents préfixes de tâche. Le classificateur ne peut pas s'appuyer sur la longueur de la séquence ici ; il doit apprendre purement à partir des motifs numériques.

tagEntraînement

L'entraînement s'est déroulé sur un A100 40 Go avec une précision mixte, un traitement par lots groupés par longueur, et AdamW avec une planification en cosinus, atteignant environ 340K tokens par seconde et 23 800 étapes par époque.

tagRésultats expérimentaux

Le faible écart entre l'entraînement et la validation et l'amélioration continue suggèrent un apprentissage généralisable plutôt qu'une simple mémorisation. À 800K paramètres, le modèle approche de sa limite de capacité, et un modèle plus grand permettrait probablement d'augmenter encore la précision.

tagMatrice de confusion

La précision globale est de 87,0 %, soit 59 fois supérieure au hasard (1,5 %). Plusieurs modèles sont classés parfaitement, notamment GTE-large, les variantes de classification de jina-embeddings-v3 / jina-embeddings-v5-text-small, LaBSE et Paraphrase MiniLM. Les cas les plus difficiles sont les variantes de préfixes de tâche d'un même modèle de base. Qwen3-0.6B présente le plus de confusion au sein de sa propre famille à travers ses 4 types de tâches, tandis que jina-embeddings-v5-text-small atteint 92 % de précision au sein de sa famille sur 5 tâches. Le fait que différents prompts d'instruction sur le même modèle produisent des motifs de sortie distinguables est en soi une découverte remarquable, suggérant que l'adaptation à la tâche laisse une trace numérique mesurable même lorsque les poids de base sont identiques.

Les modèles de familles différentes (BGE vs Jina vs E5 vs Nomic) sont beaucoup plus faciles à séparer que les variantes de tâches d'un même modèle. L'architecture de base et la méthodologie d'entraînement laissent une signature plus forte que les adaptateurs spécifiques aux tâches. Le véritable défi réside dans le groupe de 1024 dimensions (32 classes) et celui de 768 dimensions (24 classes), où le classificateur doit se fier exclusivement aux motifs numériques plutôt qu'à la longueur de la séquence.

tagApproches alternatives

tagTokenizer par compartiments (Bucketing)

Quantifier chaque dimension dans l'un des K compartiments (par exemple, 256), produisant une séquence compacte de longueur D, soit un token par dimension. C'est l'approche utilisée par Embedding-Converter (ICLR 2025). Pour un vecteur de 1024 dimensions, on obtient 1024 tokens au lieu de 7 700.

Le compartimentage impose un a priori sur la distribution des valeurs. Il faut décider des limites des compartiments avant de voir les données. Or, différents modèles distribuent leurs valeurs de manières fondamentalement différentes. Certains concentrent la masse dans une plage étroite autour de zéro, d'autres étalent les valeurs uniformément sur [-1, 1], et la distribution varie par dimension au sein d'un seul modèle. Tout schéma de compartimentage fixe gaspille de la résolution là où les valeurs se regroupent ou sous-résout là où elles s'étalent. Un compartimentage adaptatif par modèle va à l'encontre du but recherché, puisqu'il nécessite de connaître l'identité du modèle à l'avance.

tagMLP à longueur fixe

Injecter le vecteur d'embedding brut directement dans un classificateur MLP. Le problème fondamental dépasse la question de la dimension variable (nos modèles produisent des vecteurs de 384 à 1536 dimensions). Même en complétant tout (padding) à une longueur fixe, on suppose implicitement que les indices de dimension sont alignés sémantiquement entre les modèles : que la dimension 1 de BGE-M3 correspond à la dimension 1 de jina-embeddings-v5-text-small. Cette hypothèse est fausse. Différentes architectures, données d'entraînement et objectifs d'entraînement produisent des représentations internes totalement différentes.

Ces deux alternatives imposent des hypothèses structurelles que le modèle doit contourner. La tokenization au niveau des chiffres les évite toutes. C'est la représentation la plus libre d'hypothèses que nous ayons trouvée : voici les chiffres exacts de chaque nombre, dans l'ordre, séparés par des marqueurs. Débrouillez-vous avec ça.

tagConclusion

Les modèles d'embeddings sont entraînés pour mapper des textes sémantiquement similaires vers des vecteurs proches. L'objectif d'entraînement ne dit rien sur le fait de rendre les vecteurs identifiables, ni sur l'encodage d'une signature du modèle. Pourtant, la signature est bien là, suffisamment forte pour qu'un minuscule classificateur la détecte. Le « style » d'un modèle d'embeddings, les motifs numériques spécifiques qu'il utilise pour représenter le sens, est aussi distinctif qu'une écriture manuscrite. Même le choix du prompt d'instruction laisse une trace détectable.

Cela présente une valeur pratique pour l'audit de bases de données vectorielles lorsque le modèle source est inconnu, pour vérifier qu'une API utilise réellement le modèle qu'elle prétend utiliser, et pour détecter les changements de version de modèle. Plus fondamentalement, cela nous indique que les modèles d'embeddings encodent le sens de manières structurellement distinctes, même lorsqu'ils produisent des vecteurs de même dimensionnalité.