Identificare i modelli di embedding a partire da valori numerici grezzi

I modelli di embedding sono scatole nere. Invii del testo, ottieni un vettore. Una lista di numeri a virgola mobile senza etichetta, senza watermark, senza metadati che ti dicano da dove provenga. Se qualcuno ti consegna un vettore a 1024 dimensioni, sai dire se è stato prodotto da BGE-M3, jina-embeddings-v5-text-small o Qwen3-Embedding? E anche se due vettori provengono dallo stesso modello, puoi dire se sono stati generati con un'istruzione di recupero o di classificazione?

Si scopre che è possibile. I pattern numerici in un vettore di embedding portano un'impronta digitale sorprendentemente forte del modello che lo ha prodotto, e persino del prompt di istruzione usato durante l'inferenza. Abbiamo addestrato un piccolo classificatore transformer (800K parametri) per identificare 68 diverse combinazioni modello-task da oltre 25 modelli di embedding, raggiungendo l'87% di accuratezza leggendo nient'altro che le cifre grezze a virgola mobile. Puoi provare la demo live tu stesso: incolla qualsiasi vettore di embedding e scopri quale modello e task il classificatore pensa lo abbia prodotto.

tagTokenizzazione: Trattare i Numeri come Testo

Un vettore di embedding a 1024 dimensioni è una sequenza di 1024 numeri a virgola mobile. Per inserirlo in un classificatore, abbiamo bisogno di una rappresentazione che non faccia supposizioni sulla struttura dei valori.

Abbiamo adottato un approccio audace: trattare ogni float come una stringa di caratteri numerici e tokenizzarlo carattere per carattere. Può sembrare inefficiente rispetto ad alternative più compatte, ma si è rivelato il giusto compromesso. Per un valore come -0.1234, la sequenza di token è:

- 0 . 1 2 3 4
Copy

Le dimensioni sono separate da un token [SEP]. La sequenza completa inizia con [CLS]. Il vocabolario completo ha 15 token:

Con una precisione di 4 cifre decimali, un vettore a 1024 dimensioni produce circa 7.700 token. Un vettore a 384 dimensioni ne produce circa 2.900. La lunghezza della sequenza varia naturalmente con la dimensione dell'embedding, e non è necessario alcun padding o troncamento tra le dimensioni. Poiché il tokenizer è una mappatura diretta di interi senza componenti apprese, è estremamente efficiente.

tagArchitettura del Modello

Il classificatore è un piccolo transformer encoder-only con 4 layer, 128 dimensioni, 4 testine di attenzione con RoPE, SwiGLU FFN e RMSNorm. Il token CLS viene aggregato (pooled) e proiettato nello spazio di output a 68 classi. I parametri totali sono circa 800K.

Nonostante il minuscolo vocabolario di 15 token, questo è fondamentalmente un compito a sequenza lunga. Un singolo embedding a 1024 dimensioni diventa una sequenza di 7.700 token, più lunga dei tipici input NLP. Il modello deve prestare attenzione a migliaia di token cifra per individuare i pattern statistici che distinguono l'output di un modello dall'altro. Ciò rende essenziali un'attenzione efficiente e la codifica posizionale (RoPE) anche a questa piccola scala.

tagDati

Abbiamo utilizzato 10.000 campioni di testo multilingue, ciascuno convertito in embedding da oltre 25 modelli con vari prefissi di task come retrieval.query, retrieval.document, classification e clustering, producendo 68 classi distinte. È importante notare che le 68 classi includono non solo modelli diversi, ma anche diversi prompt di istruzione applicati allo stesso modello. Ad esempio, jina-embeddings-v5-text-small con un'istruzione di recupero e jina-embeddings-v5-text-small con un'istruzione di classificazione sono trattati come classi separate. L'obiettivo è rilevare sia l'identità del modello che il comportamento specifico del task solo dall'output grezzo.

Ogni classe è suddivisa in 7.000 campioni di addestramento e 3.000 di validazione. I modelli coprono cinque dimensioni di output.

Solo nel gruppo a 1024 dimensioni ci sono 32 classi da separare, inclusi modelli della stessa famiglia con prefissi di task diversi. Il classificatore non può fare affidamento sulla lunghezza della sequenza in questo caso; deve apprendere puramente i pattern numerici.

tagAddestramento

L'addestramento è stato eseguito su una A100 40GB con precisione mista, batching raggruppato per lunghezza e AdamW con pianificazione del coseno, raggiungendo circa 340K token al secondo e 23.800 step per epoca.

tagRisultati Sperimentali

Il ridotto divario tra addestramento e validazione e il continuo miglioramento suggeriscono un apprendimento generalizzabile piuttosto che una semplice memorizzazione. Con 800K parametri, il modello si avvicina al suo limite di capacità e un modello più grande porterebbe probabilmente a un'accuratezza superiore.

tagMatrice di Confusione

L'accuratezza complessiva è dell'87,0%, ovvero 59 volte superiore alla probabilità casuale (1,5%). Diversi modelli vengono classificati perfettamente, tra cui GTE-large, le varianti di classificazione di jina-embeddings-v3/jina-embeddings-v5-text-small, LaBSE e Paraphrase MiniLM. I casi più difficili sono le varianti del prompt di istruzione dello stesso modello di base. Qwen3-0.6B presenta la maggiore confusione interna alla famiglia tra i suoi 4 tipi di task, mentre jina-embeddings-v5-text-small raggiunge un'accuratezza interna alla famiglia del 92% su 5 task. Il fatto che diversi prompt di istruzione sullo stesso modello producano pattern di output distinguibili è di per sé una scoperta degna di nota, suggerendo che l'adattamento al task lasci una traccia numerica misurabile anche quando i pesi di base sono identici.

I modelli di famiglie diverse (BGE vs Jina vs E5 vs Nomic) sono molto più facili da separare rispetto alle varianti di task dello stesso modello. L'architettura principale e la metodologia di addestramento lasciano una firma più forte rispetto agli adattatori specifici per il task. La vera sfida risiede nel gruppo a 1024 dimensioni (32 classi) e in quello a 768 dimensioni (24 classi), dove il classificatore deve fare affidamento puramente sui pattern numerici invece che sulla lunghezza della sequenza.

tagApprocci Alternativi

tagBucket Tokenizer

Quantizzare ogni dimensione in uno dei K bin (ad esempio, 256), producendo una sequenza compatta di lunghezza D, un token per dimensione. Questo è l'approccio utilizzato da Embedding-Converter (ICLR 2025). Per un vettore a 1024 dimensioni, si ottengono 1024 token invece di 7.700.

Il bucketing impone un a priori sulla distribuzione dei valori. È necessario decidere i confini dei bin prima di vedere i dati. Ma modelli diversi distribuiscono i loro valori in modi fondamentalmente differenti. Alcuni concentrano la massa in un intervallo stretto intorno allo zero, altri diffondono i valori uniformemente tra [-1, 1], e la distribuzione varia per dimensione all'interno di un singolo modello. Qualsiasi schema di binning fisso spreca risoluzione dove i valori si raggruppano o sotto-risolve dove si diffondono. Il binning adattivo per modello vanifica lo scopo, poiché richiede di conoscere l'identità del modello in anticipo.

tagMLP a Lunghezza Fissa

Inviare il vettore di embedding grezzo direttamente a un classificatore MLP. Il problema fondamentale va oltre la questione della dimensione variabile (i nostri modelli producono vettori da 384 a 1536 dimensioni). Anche se si eseguisse il padding di tutto a una lunghezza fissa, si starebbe implicitamente assumendo che gli indici delle dimensioni siano semanticamente allineati tra i modelli, ovvero che la dimensione 1 di BGE-M3 corrisponda alla dimensione 1 di jina-embeddings-v5-text-small. Questa ipotesi è falsa. Architetture, dati di addestramento e obiettivi di addestramento diversi producono rappresentazioni interne completamente differenti.

Entrambe le alternative impongono presupposti strutturali che il modello deve aggirare. La tokenizzazione a livello di cifra li evita tutti. È la rappresentazione più libera da presupposti che siamo riusciti a trovare: ecco le cifre esatte di ogni numero, in ordine, separate da marcatori. Scopri il resto da solo.

tagConclusione

I modelli di embedding sono addestrati per mappare testi semanticamente simili a vettori vicini. L'obiettivo dell'addestramento non dice nulla sul rendere i vettori identificabili, né sul codificare una firma del modello. Eppure la firma c'è, abbastanza forte da essere rilevata da un minuscolo classificatore. Lo "stile" di un modello di embedding, i pattern numerici specifici che utilizza per rappresentare il significato, è distintivo come la grafia. Persino la scelta del prompt di istruzione lascia una traccia rilevabile.

Questo ha un valore pratico per l'audit dei database vettoriali quando il modello sorgente è sconosciuto, per verificare che un'API utilizzi effettivamente il modello che dichiara e per rilevare modifiche alla versione del modello. Fondamentalmente, ci dice che i modelli di embedding codificano il significato in modi strutturalmente distinti, anche quando producono vettori della stessa dimensionalità.