Cosa causa la deriva degli embedding dopo la reindicizzazione della stessa libreria di documenti?

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Il drift degli embedding si verifica quando la reindicizzazione modifica il modello, il testo, le impostazioni dell’encoder, il percorso numerico o le regole di confronto utilizzati per rappresentare la libreria.

Una knowledge base domestica può contenere gli stessi PDF, note, manuali e documenti di famiglia prima e dopo una ricostruzione, ma restituire vicini più prossimi o punteggi di similarità diversi. Alcuni cambiamenti sono un vero drift degli embedding: il vettore prodotto per un input identico è cambiato. Altri sono drift di ingestione, quando cambia il testo inviato all’encoder, oppure drift del recupero, quando vettori identici vengono cercati con metriche o impostazioni dell’indice diverse. Il primo confine diagnostico consiste quindi nel confrontare separatamente i byte sorgente, il testo estratto, l’identità dei chunk, i vettori grezzi e i risultati ordinati.

Il vero drift dei vettori e il drift apparente del recupero sono fenomeni diversi

Il drift effettivo significa che lo stesso testo normalizzato produce un vettore diverso. Il drift apparente significa che il vettore è stabile, ma cambiano l’appartenenza ai chunk, la metrica di similarità, i filtri, la quantizzazione o la ricerca approssimata dei vicini, modificando i risultati ordinati.

Le collection di Qdrant definiscono la dimensione del vettore e la metrica di distanza come parametri a livello di collection. Ricostruire i dati in una collection con un’altra metrica può modificare i punteggi e l’ordine senza cambiare i valori degli embedding.

Confrontare soltanto i risultati principali della ricerca confonde queste cause. Un checksum dei vettori grezzi calcolato su stringhe di test fisse consente di distinguere il drift dell’encoder dal drift dell’indice o dell’ordinamento.

Una revisione del modello non bloccata può sostituire l’encoder

Il nome di un modello non corrisponde sempre a un insieme permanente di pesi e file di configurazione. Il proprietario di un repository può aggiornare i pesi, i file del tokenizer, la configurazione del pooling o il codice del modello mantenendo invariato il nome pubblico del repository.

I repository di Hugging Face sono sottoposti al controllo versione e i download possono utilizzare una revisione specifica invece dello stato del ramo più recente.

Questa causa produce un’ampia variazione su un set di probe fisso, spesso accompagnata da un commit diverso del modello, da un percorso della cache diverso, da un hash di configurazione modificato o da asset diversi del tokenizer. È diversa dal drift specifico dei documenti, che interessa solo i file la cui estrazione o segmentazione è cambiata.

Le opzioni dell’encoder possono modificare lunghezza, scala e geometria dei vettori

Gli stessi pesi possono produrre rappresentazioni diverse quando cambiano il pooling, la normalizzazione, la precisione, i prefissi dei prompt, la lunghezza massima della sequenza o le dimensioni dell’output.

Sentence Transformers mette a disposizione controlli dell’encoder tra cui precisione, normalizzazione, prompt e dimensioni troncate.

Una modifica della normalizzazione può preservare la direzione cambiando al contempo il modulo del vettore; un prefisso del prompt può spostare ogni documento in un altro spazio condizionato dall’attività; il troncamento può eliminare alcune dimensioni. Si tratta di modifiche alla configurazione, non di instabilità casuale.

Il testo che raggiunge l’encoder potrebbe non essere lo stesso

La reindicizzazione può utilizzare una versione diversa del parser, un percorso OCR diverso, una normalizzazione degli spazi bianchi diversa, una regola diversa per l’ordine delle pagine o una strategia di segmentazione differente, anche quando i file originali sono identici byte per byte.

Unstructured esegue la segmentazione dopo il partizionamento e documenta come dimensione dei chunk, sovrapposizione e confini delle sezioni determinino il testo incluso in ciascun chunk.

Se un’intestazione viene rilevata per la prima volta o una pagina produce un OCR diverso, tutti i confini dei chunk successivi possono spostarsi. I vettori risultanti non sono rappresentazioni alterate dello stesso input: rappresentano intervalli di testo diversi.

L’esecuzione non deterministica può creare piccole differenze numeriche

I kernel paralleli, le librerie hardware, l’ordine delle operazioni e i componenti casuali possono fare in modo che inferenze ripetute differiscano leggermente anche con lo stesso modello e lo stesso input.

PyTorch osserva che la riproducibilità completa non è garantita tra versioni, piattaforme o dispositivi diversi e fornisce controlli per gli algoritmi deterministici per le operazioni supportate.

Questa causa genera generalmente piccole differenze nelle coordinate, non una riorganizzazione completa dello spazio semantico. Se la similarità coseno tra i vettori probe vecchi e nuovi rimane estremamente elevata, il cambiamento potrebbe essere semplice rumore numerico, visibile solo in prossimità di pareggi nella classifica.

La precisione e la quantizzazione possono spostare i vicini ai margini

Una ricostruzione può passare da float32 a float16, int8 o a un altro profilo di runtime ottimizzato per ridurre l’uso della memoria e migliorare la velocità di elaborazione.

ONNX Runtime spiega che la conversione a float16 può introdurre differenze di accuratezza che richiedono test di tolleranza.

L’effetto semantico è spesso ridotto, ma una libreria locale può contenere molti chunk simili. Piccoli spostamenti delle coordinate possono invertire l’ordine di vicini i cui punteggi originali erano quasi uguali.

La reindicizzazione può mescolare generazioni di vettori vecchie e nuove

Una collection ricostruita parzialmente può contenere vettori generati con commit diversi del modello, impostazioni di segmentazione diverse, dimensioni diverse o regole di normalizzazione diverse.

Le generazioni miste producono comportamenti irregolari: i documenti non modificati possono rimanere stabili mentre cambiano solo i file rielaborati, e i vettori delle query possono risultare incompatibili con una parte della collection.

La guida di ZimaSpace sulla indicizzazione semantica su NAS fornisce il contesto correlato: la libreria sorgente, i record estratti, gli embedding e l’indice di ricerca sono livelli separati e non devono essere trattati come un unico oggetto immutabile.

Domande frequenti

Un testo identico dovrebbe produrre sempre embedding identici bit per bit?

Solo con un modello bloccato, una configurazione identica, un percorso di esecuzione deterministico e un ambiente hardware e software corrispondente. In caso contrario possono comunque verificarsi piccole differenze in virgola mobile.

Risultati di ricerca invariati possono dimostrare che gli embedding non sono cambiati?

No. I vettori possono spostarsi senza oltrepassare i confini della classifica. Confronta i vettori grezzi, oppure i relativi hash e le similarità, su un set di probe fisso.

Un vicino più prossimo diverso indica sempre un drift del modello?

No. La segmentazione, i filtri, le metriche di distanza, la quantizzazione e la costruzione dell’indice approssimato possono modificare il recupero anche quando l’output dell’encoder rimane stabile.

Hub Tecnologico e AI

Altro da leggere

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.