Similarità coseno: perché la ricerca trova la pagina vicina invece di quella giusta

Hai cercato «come disdire la polizza auto» nella ricerca interna del sito, o l’hai chiesto all’assistente aziendale. Ti è tornato il modulo di disdetta della polizza vita. Non è un bug: il sistema ha fatto esattamente il suo lavoro, e il suo lavoro non è quello che pensavi.

In questo articolo scoprirai:

• Il fatto: il documento che c’entra, ma non è quello
• Cosa succede davvero: la macchina non confronta parole, confronta direzioni
• Il conto, fatto per esteso
• Quando la similarità coseno non basta a giudicare la somiglianza
• Similarità coseno, prodotto scalare o distanza euclidea: quale metrica scegliere

Il fatto: il documento che c’entra, ma non è quello

È una scena che si ripete in ogni azienda che ha acceso una ricerca semantica negli ultimi due anni. Chiedi una procedura e ne ottieni un’altra, dello stesso reparto. Chiedi il contratto di un cliente e ti arriva quello di un cliente simile. Chiedi «quanto tempo ho per il reso» e l’assistente ti cita, con sicurezza assoluta, la pagina sui tempi di consegna.

La reazione istintiva è pensare che il sistema sia rotto, o che «l’AI abbia allucinato». Quasi mai è così. Nella maggior parte dei casi il motore ha classificato correttamente quel documento come il più vicino alla tua domanda fra tutti quelli che aveva. Il punto è che «più vicino» e «giusto» sono due cose diverse, e il sistema conosce solo la prima.

Dietro quel «più vicino» c’è una singola operazione aritmetica, vecchia di secoli e sorprendentemente semplice: la similarità coseno. Capire cosa misura — e soprattutto cosa non misura — è il modo più rapido per smettere di stupirsi di questi errori e cominciare a ridurli.

Cosa succede davvero: la macchina non confronta parole, confronta direzioni

Quando indicizzi un documento in un sistema di ricerca semantica, il testo non viene archiviato come testo. Viene prima spezzato in token, e in italiano lo stesso contenuto ne consuma più che in inglese, poi passato a un modello che lo trasforma in una lista di numeri — un embedding — tipicamente lunga da 384 a 3.072 elementi. Quella lista è un punto in uno spazio con altrettante dimensioni. La stessa cosa succede alla tua domanda quando la scrivi.

A quel punto la ricerca non è più una ricerca testuale: è un problema di geometria. Il motore deve trovare, fra milioni di punti, quello più vicino al punto della tua domanda. E la nozione di «vicinanza» che usa quasi sempre non è la distanza fra i punti, ma l’angolo fra le direzioni in cui puntano rispetto all’origine.

Cosa misura la similarità coseno, in una frase

La similarità coseno è la misura con cui un motore di ricerca semantica decide che due testi si somigliano: calcola il coseno dell’angolo fra i due vettori che li rappresentano, restituendo un numero compreso fra -1 e 1, dove 1 significa stessa direzione esatta. La similarità coseno ignora la lunghezza dei vettori e guarda solo il loro orientamento, e per questo un documento di dieci pagine e una frase di dieci parole che parlano della stessa cosa risultano vicini. La similarità coseno misura la vicinanza di argomento, non la correttezza della risposta: è esattamente per questo che una ricerca semantica può restituire un documento perfettamente pertinente al tema e completamente sbagliato per la domanda.

L’ingrediente di base è il prodotto scalare, l’operazione che moltiplica i due vettori componente per componente e somma i risultati. È la stessa operazione che governa l’attenzione nei transformer e buona parte di ciò che accade dentro una rete neurale; se vuoi il quadro completo di vettori, matrici e proiezioni, lo trovi nella nostra guida all’algebra lineare applicata al machine learning. Qui ci serve solo il pezzo che decide chi vince la ricerca.

Perché la similarità coseno ignora la lunghezza del testo

La divisione per le lunghezze dei vettori non è un dettaglio di implementazione: è la scelta di progetto che rende il sistema utilizzabile. Senza di essa un manuale di duecento pagine vincerebbe quasi ogni confronto per il solo fatto di essere lungo, e la ricerca diventerebbe una classifica di mole. Normalizzando, resta solo la direzione — cioè, approssimativamente, l’argomento.

Molti fornitori fanno un passo in più e restituiscono vettori già normalizzati a lunghezza 1. La documentazione di OpenAI sugli embedding lo dichiara esplicitamente: i vettori sono normalizzati a lunghezza 1, quindi la similarità coseno «si può calcolare un po’ più velocemente usando solo un prodotto scalare», e coseno e distanza euclidea «producono ordinamenti identici». È un’informazione operativa che risparmia discussioni inutili: se il tuo fornitore normalizza, litigare su quale metrica usare non cambia una riga della classifica.

Le stesse pagine danno le dimensioni in gioco: 1.536 componenti per text-embedding-3-small, 3.072 per text-embedding-3-large, con un parametro dimensions che permette di accorciare il vettore scambiando un po’ di qualità per costo e memoria. La possibilità di tagliare la coda di un embedding senza distruggerlo viene da un filone di ricerca sulle rappresentazioni annidate, il Matryoshka Representation Learning, dove le prime componenti concentrano già la maggior parte dell’informazione. Attenzione a una conseguenza che si dimentica sempre: accorciare i vettori sposta i valori del coseno. Se hai tarato una soglia su 3.072 dimensioni e passi a 512, la soglia va rifatta, non riusata.

Il conto, fatto per esteso

Riduciamo tutto a quattro dimensioni, così i numeri si possono seguire a mano. Immagina che ogni testo sia descritto da quattro coordinate. Prendiamo due vettori:

a = [2, 1, 0, 3]
b = [3, 0, 1, 2]

Primo passo, il prodotto scalare. Si moltiplicano le componenti che occupano la stessa posizione e si sommano i prodotti:

a · b = (2×3) + (1×0) + (0×1) + (3×2) = 6 + 0 + 0 + 6 = 12

Secondo passo, le norme. La norma è la lunghezza del vettore: radice quadrata della somma dei quadrati delle componenti.

‖a‖ = √(2² + 1² + 0² + 3²) = √(4 + 1 + 0 + 9) = √14 ≈ 3,742
‖b‖ = √(3² + 0² + 1² + 2²) = √(9 + 0 + 1 + 4) = √14 ≈ 3,742

Terzo passo, il coseno. Si divide il prodotto scalare per il prodotto delle due norme. Qui il conto viene pulito, perché le due norme sono uguali e il loro prodotto è esattamente 14:

cos(θ) = 12 / (√14 × √14) = 12 / 14 = 0,857

Un coseno di 0,857 corrisponde a un angolo di circa 31 gradi. In un sistema di ricerca, questi due documenti risulterebbero molto simili — e nota che la divisione per le norme ha cancellato ogni informazione sulla lunghezza: se raddoppiassi tutte le componenti di b, il coseno resterebbe identico.

In codice sono tre righe, ed è letteralmente ciò che gira dentro un database vettoriale a ogni interrogazione:

import numpy as np

a = np.array([2, 1, 0, 3])
b = np.array([3, 0, 1, 2])

coseno = np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))
print(round(coseno, 3))                      # 0.857
print(round(np.degrees(np.arccos(coseno)), 1))  # 31.0

Parole diverse, coseno alto

Ora il caso che spiega il fenomeno da cui siamo partiti. Prendi queste due frasi:

• «Come faccio a riavere i soldi di un acquisto sbagliato?»
• «Procedura di reso e accredito dell’importo»

Non condividono nemmeno una parola piena. Una ricerca per parole chiave non le accosterebbe mai. Un modello di embedding decente le colloca in direzioni molto vicine, con un coseno nell’ordine di 0,7-0,8 — indicativo, non misurato: il valore esatto dipende dal modello. Questo è il motivo per cui la ricerca semantica funziona, e funziona bene.

Parole quasi identiche, coseno più basso di quanto ti aspetti

Il rovescio è più insidioso:

• «Modulo di disdetta polizza auto»
• «Modulo di disdetta polizza vita»

Quattro parole su cinque sono le stesse: la sovrapposizione lessicale è dell’80%. Ma l’unica parola che cambia è quella che porta tutto il carico semantico, e un buon modello la usa per separare nettamente i due vettori. Il coseno scende molto sotto quello che l’occhio umano, contando le parole uguali, si aspetterebbe.

Messi insieme, i due casi dicono la stessa cosa: la quantità di parole in comune non predice il coseno, in nessuna delle due direzioni. Se scrivi «disdetta polizza» senza specificare il ramo, il tuo vettore finisce in mezzo fra i due documenti, e quello che vince lo decide un margine di qualche millesimo che nessuno di noi può ispezionare a occhio.

Perché la similarità coseno non scende quasi mai sotto zero

La formula ammette valori da -1 a 1, e questo suggerisce una scala intuitiva: 0 vuol dire «niente in comune», i valori negativi «opposti». Guarda i numeri veri di un motore in produzione e scoprirai che quasi tutto sta fra 0,3 e 0,9, e che il negativo praticamente non esiste.

La ragione ha un nome: anisotropia. Nel lavoro che ha misurato la geometria delle rappresentazioni contestuali, Ethayarajh ha trovato che «le rappresentazioni contestualizzate di tutte le parole non sono isotrope in nessun layer»: invece di distribuirsi uniformemente nello spazio, si addensano in un cono stretto. Se tutti i vettori puntano più o meno nella stessa regione, due testi presi a caso e senza alcun rapporto fra loro partono già con un coseno positivo e spesso tutt’altro che basso.

La conseguenza pratica è la più importante di tutto l’articolo: 0,5 non significa «somiglianza a metà». Può essere il pavimento del tuo modello, cioè il valore che ottieni confrontando due documenti che non c’entrano niente. Ecco perché una soglia non si sceglie a tavolino sul buon senso: si guarda la distribuzione dei coseni sul proprio corpus e si osserva dove cadono le coppie che sappiamo essere pertinenti, e dove cadono quelle che sappiamo non esserlo.

Quando la similarità coseno non basta a giudicare la somiglianza

Va detto con chiarezza, perché è la parte che di solito manca: ci sono condizioni in cui il numero che hai calcolato non significa quello che credi, e riconoscerle è ciò che distingue un sistema tarato da uno che sembra funzionare.

• Il coseno non è comparabile fra modelli diversi. Un 0,82 prodotto da un modello non vale un 0,82 prodotto da un altro: cambiano l’addestramento, la geometria dello spazio e il pavimento di cui sopra. Le soglie vanno ritarate a ogni cambio di modello di embedding, sempre. E non esiste il modello che vince su tutto: il benchmark MTEB, che copre 8 compiti su 58 dataset e 112 lingue, conclude che «nessun metodo di text embedding domina su tutti i compiti».
• Il coseno non distingue l’affermazione dalla negazione. «Il pagamento è andato a buon fine» e «il pagamento non è andato a buon fine» sono quasi lo stesso vettore. Per il motore sono lo stesso argomento, e in effetti lo sono: solo che una è la risposta giusta e l’altra è il suo contrario. Non è un difetto del coseno ma del testo che gli passi: la diagnostica psicolinguistica di Ettinger ha mostrato che BERT «mostra una chiara insensibilità agli effetti contestuali della negazione», e quell’insensibilità arriva intatta nell’embedding.
• Il coseno può essere arbitrario per costruzione. Steck, Ekanadham e Kallus hanno mostrato analiticamente, su modelli lineari regolarizzati, che la similarità coseno degli embedding può produrre valori arbitrari e quindi privi di significato: in alcuni casi non è nemmeno unica, in altri è determinata implicitamente dalla regolarizzazione scelta in addestramento, non dalla semantica. La loro conclusione è esplicita: sconsigliano l’uso cieco della similarità coseno.
• Il coseno sottostima la somiglianza delle parole frequenti. Zhou, Ethayarajh, Card e Jurafsky hanno misurato che, rispetto al giudizio umano, il coseno su embedding contestuali sottovaluta sistematicamente la somiglianza delle parole ad alta frequenza, e hanno ricondotto l’effetto alla frequenza nei dati di addestramento. Tradotto in azienda: i termini che il tuo settore usa in ogni documento sono anche quelli su cui il coseno discrimina peggio.

Il test pratico per capire se la similarità coseno ti sta bastando

C’è una prova che costa un pomeriggio e vale più di qualunque discussione architetturale: prendi cinquanta domande reali dei tuoi utenti, guarda i primi tre documenti restituiti e conta quante volte il documento corretto c’è ma non è primo.

Il conteggio ti dice dove intervenire, e le tre risposte possibili portano in tre direzioni diverse. Se il documento giusto è quasi sempre primo, il recupero non è il tuo problema e stai cercando nel posto sbagliato. Se c’è ma è secondo o terzo, hai un problema di ordinamento: è il caso in cui il riordino dei candidati rende più di qualsiasi altra cosa. Se non c’è affatto nei primi dieci, il problema è a monte — nel modo in cui hai spezzato e descritto i documenti, non nella metrica. Se succede spesso che il documento corretto ci sia ma non vinca, il problema non è il modello: è che stai usando una misura di argomento per rispondere a una domanda di merito.

Similarità coseno, prodotto scalare o distanza euclidea: quale metrica scegliere

È la prima domanda che arriva quando si configura un database vettoriale, e nella maggior parte dei casi ha una risposta noiosa. Se i vettori sono normalizzati a lunghezza 1 — come lo sono quelli di molti fornitori — coseno e prodotto scalare coincidono a meno di una costante, e coseno e distanza euclidea ordinano i risultati in modo identico. Cambiare metrica, in quel caso, non cambia nulla di ciò che l’utente vede.

La differenza emerge quando i vettori non sono normalizzati. Lì il prodotto scalare premia i vettori lunghi, e la lunghezza diventa un fattore di ranking. In alcuni sistemi di raccomandazione è voluto, perché la norma finisce per codificare qualcosa come la popolarità di un elemento; nella ricerca documentale è quasi sempre un difetto, perché fa vincere i testi lunghi. La regola operativa è una sola e non è negoziabile: usa la metrica con cui il modello è stato addestrato, che il produttore dichiara nella scheda del modello. Un modello addestrato con obiettivo coseno interrogato in euclidea su vettori non normalizzati dà risultati peggiori senza che nessun log te lo segnali.

Quando cambiare metrica non risolve niente

Vale la pena dirlo perché è l’esperimento che quasi tutti fanno per primo, e quasi sempre è tempo buttato: se il documento giusto è al quarto posto, passare da coseno a euclidea su vettori normalizzati produce esattamente lo stesso ordine. Zero guadagno, mezza giornata spesa.

C’è anche un secondo motivo per cui la metrica non è il collo di bottiglia: su volumi realistici il motore non confronta la tua domanda con tutti i vettori. Usa un indice approssimato, tipicamente HNSW, che costruisce un grafo navigabile a più livelli per trovare i vicini in tempo logaritmico invece che lineare. «Approssimato» significa che il vicino veramente più prossimo può sfuggire: si scambia una piccola quota di richiamo per un grande guadagno di velocità. Se stai inseguendo un documento che non compare, prima di riscrivere la formula controlla i parametri dell’indice.

Quando questo scarto ti costa davvero

Finché si tratta di cercare un articolo in un blog, un risultato vicino invece che giusto è un fastidio. In tre situazioni diventa un costo misurabile.

L’assistente che cita il documento sbagliato. In un’architettura RAG, il modello linguistico non decide quali documenti leggere: li riceve dal recupero vettoriale e li tratta come veri. Se il recupero gli passa la procedura del 2024 invece di quella in vigore, il modello scrive una risposta impeccabile, motivata e sbagliata — con la citazione allegata, che è la parte peggiore, perché la citazione fa sembrare la risposta verificata.

Il cliente che riceve la risposta di un altro caso. Nei sistemi di assistenza che suggeriscono all’operatore la risposta pescandola dai ticket chiusi, «caso simile» e «caso identico» sono separati da pochi centesimi di coseno. Un cliente che riceve le condizioni contrattuali di un altro profilo non nota un errore tecnico: nota che gli hai dato un’informazione sbagliata per iscritto.

Il costo silenzioso: la procedura che nessuno trova

È il caso più difficile da accorgersene e probabilmente il più caro. La procedura esiste, è indicizzata, ed è al quarto posto sotto tre documenti che parlano dello stesso tema. Il collega guarda i primi tre risultati, conclude che la procedura non c’è, e ne scrive una nuova. Sei mesi dopo hai due procedure divergenti e nessuno sa quale sia quella buona.

Questo errore non lascia traccia: non genera un ticket, non compare in nessuna dashboard, e l’utente non lo segnala perché è convinto che il documento non esista. L’unico modo per vederlo è andarlo a cercare, confrontando periodicamente ciò che il motore restituisce con ciò che l’archivio contiene davvero. Il duplicato che nasce da una ricerca fallita, invece, si paga per anni.

Come si riduce lo scarto fra «vicino» e «giusto»

Non esiste un modo per far coincidere «vicino» con «giusto»: sono due criteri diversi e il coseno conosce solo il primo. Esistono però quattro interventi che restringono la distanza fra i due, in ordine crescente di sforzo.

Soglia sulla similarità coseno: ammettere di non sapere

Se il miglior risultato sta sotto una soglia, il sistema deve rispondere «non ho trovato niente di pertinente» invece di restituire il meno peggio. È l’intervento più economico e quello che più spesso manca: nella configurazione predefinita di quasi tutti gli stack, il motore restituisce sempre i primi k risultati, qualunque sia il loro punteggio.

Attenzione però a come la tari: una soglia scelta su una manciata di query di prova è overfitting in piena regola, e crolla sul traffico vero. Serve un insieme di domande reali, e serve rifarlo a ogni cambio di modello — e, come abbiamo visto, anche a ogni cambio di dimensionalità del vettore. Un dettaglio che fa la differenza in produzione: tieni due soglie, non una. Una alta, sopra la quale il sistema risponde; una bassa, sotto la quale tace. Fra le due, mostra i risultati ma dichiara l’incertezza invece di nasconderla.

Reranking: riordinare i primi risultati della ricerca vettoriale

Il recupero vettoriale è fatto per essere veloce su milioni di documenti, non per essere preciso sui primi dieci. Il reranking prende i primi candidati e li riordina con un modello che legge insieme domanda e documento, invece di confrontare due vettori calcolati separatamente. La documentazione di Sentence-Transformers descrive l’architettura in due stadi e usa come esempio un centinaio di candidati recuperati dal bi-encoder e poi riordinati da un cross-encoder, che riceve domanda e documento simultaneamente e restituisce un singolo punteggio di pertinenza.

È più lento per definizione — le stesse pagine avvertono che assegnare un punteggio a milioni di coppie sarebbe «piuttosto lento» — ma gira su poche decine o centinaia di elementi, quindi il costo resta sotto controllo. Se non vuoi gestire un modello tuo, esistono servizi dedicati come Cohere Rerank. È l’intervento con il miglior rapporto fra costo e risultato quando il documento giusto c’è ma non è primo, ed è coerente con quanto misurato in letteratura: nel benchmark BEIR, «i modelli di reranking e a interazione tardiva ottengono in media le migliori prestazioni zero-shot, però a costi computazionali elevati».

Contesto e metadati: dare al vettore ciò che lo qualifica

Un frammento di testo isolato perde le informazioni che lo qualificano. Se ogni pezzo indicizzato porta con sé il titolo del documento, la sezione, la data di validità e il ramo di prodotto — nel testo che viene trasformato in vettore, non solo nei metadati — le coppie ambigue del nostro esempio smettono di esserlo.

Qui c’è un numero pubblico che vale la pena conoscere: nel proprio esperimento su questa tecnica, Anthropic riporta che aggiungere a ogni frammento un breve contesto generato prima di vettorizzarlo ha ridotto del 35% il tasso di fallimento del recupero sui primi 20 frammenti (da 5,7% a 3,7%, misurato come 1 meno il richiamo@20). Non è il tuo corpus e non è una garanzia, ma dà l’ordine di grandezza di cosa si guadagna lavorando sul testo invece che sulla formula.

Affiancare al coseno un filtro esplicito sui metadati (ramo, versione, data) risolve da solo una buona parte dei casi residui, perché trasforma un vincolo semantico in un vincolo booleano che non ammette sfumature. Molti motori vettoriali, incluso Qdrant, permettono di combinare filtro e ricerca vettoriale nella stessa interrogazione: la sua documentazione sul filtraggio descrive come imporre condizioni sul payload durante la ricerca dei punti. Se la domanda riguarda l’auto, il documento sulla polizza vita non deve nemmeno entrare in gara.

Chunking: pezzi più piccoli, direzione più netta

Un vettore che rappresenta dieci pagine è la media di dieci argomenti, e una media non punta in nessuna direzione precisa. Frammenti più piccoli e coerenti — una procedura per frammento, non un manuale intero — producono vettori con una direzione netta, e quindi coseni che discriminano.

Il limite opposto esiste ed è simmetrico: frammenti troppo corti perdono il contesto che serve a distinguerli, e ti riportano al problema del paragrafo precedente. È per questo che il contesto e la granularità vanno tarati insieme, mai uno alla volta: rimpicciolire i pezzi senza reiniettare il contesto peggiora spesso la situazione invece di migliorarla. La regola pratica è che ogni frammento dovrebbe poter essere letto da solo e restare comprensibile a un collega che non sa da quale documento arriva.

Ricerca ibrida: quando la similarità coseno da sola non basta

C’è una classe di domande su cui la ricerca semantica è strutturalmente peggiore di quella per parole chiave, e conviene saperlo prima di sostituire la seconda con la prima. Se cerchi il codice articolo XR-4471/B, la matricola di un macchinario o il numero di una delibera, il coseno non ha niente di semantico da afferrare: quelle stringhe sono quasi rumore per un modello di embedding, e un documento che contiene il codice esatto può perdere contro uno che parla genericamente dello stesso prodotto.

Perché BM25 batte la similarità coseno sulle stringhe esatte

La ricerca lessicale classica, tipicamente BM25, in quei casi vince senza sforzo perché fa esattamente ciò che serve: cerca la stringa. E non è un ripiego per casi limite. BEIR, che valuta i sistemi di recupero fuori dal dominio su cui sono stati addestrati, conferma che «BM25 è una baseline robusta», mentre gli approcci di recupero denso «sono computazionalmente più efficienti ma spesso rendono meno degli altri approcci» in condizioni zero-shot.

Fondere le liste invece di scegliere fra similarità coseno e BM25

La conclusione operativa non è scegliere fra i due, ma tenerli in parallelo e fondere le due liste di risultati, riordinando poi l’unione. Anche qui c’è un numero pubblico: Anthropic riporta che combinare embedding contestuali e BM25 contestuale ha portato la riduzione del tasso di fallimento dal 35% al 49% (da 5,7% a 2,9%), e che aggiungendo il reranking la riduzione è arrivata al 67% (1,9%). Tre interventi impilati, ciascuno che copre un difetto diverso dell’altro: è il profilo tipico di un recupero fatto bene, e nessuno dei tre consiste nel cambiare la formula del coseno.

Come si misura se la ricerca per similarità coseno funziona

Nessuno dei quattro interventi si sceglie a intuito: si sceglie misurando quante volte il documento giusto arriva primo, prima e dopo. Senza quel numero non stai migliorando un sistema, stai cambiando configurazioni.

Il gold set: cinquanta domande vere, non inventate

Serve un elenco di domande con la risposta corretta segnata a mano: per ciascuna, quale documento del tuo archivio è quello giusto. Cinquanta righe sono già utili, duecento sono un buon presidio. La condizione vera non è la quantità ma la provenienza: devono venire dai log della ricerca o dai ticket, non dalla fantasia di chi costruisce il sistema.

Il motivo è che le domande inventate da chi conosce l’archivio usano il vocabolario dell’archivio, e quindi il coseno le risolve facilmente. Sono un test che passa sempre e non dice niente. Le domande vere contengono abbreviazioni interne, errori di battitura, il nome vecchio del prodotto e mezze frasi — cioè esattamente ciò che manda il recupero fuori strada. Va aggiornato quando cambia l’archivio: un gold set fermo da un anno certifica un sistema che non esiste più.

Richiamo@k e MRR: due numeri per cominciare

Con il gold set in mano bastano due misure. Il richiamo@k risponde a «il documento giusto è fra i primi k?»: è la metrica che conta se a valle c’è un modello linguistico che legge tutti i k frammenti, come in un RAG, perché lì la posizione esatta importa meno della presenza. È la stessa famiglia di misure usata negli esperimenti citati sopra, dove il tasso di fallimento è definito come 1 meno il richiamo@20.

Il reciproco del rango medio (MRR) risponde a «in che posizione arriva?», e premia chi mette il documento giusto in cima: è la metrica giusta quando a leggere è una persona, perché una persona guarda i primi tre risultati e poi smette. I due numeri si muovono in modo diverso e per questo vanno guardati insieme: il reranking, per esempio, migliora molto l’MRR e per costruzione non può migliorare il richiamo dello stadio che lo precede — riordina i candidati, non ne aggiunge. Se ti serve il metodo completo per portare avanti questo tipo di valutazione, abbiamo scritto come valutare un modello AI sui tuoi dati proprio perché è il passo che quasi tutti saltano.

Perché le classifiche pubbliche non sostituiscono la tua misura

La tentazione è saltare tutto questo e prendere il primo modello della classifica di turno. Ma le graduatorie pubbliche misurano una media su compiti e lingue che non sono i tuoi, e la conclusione di MTEB è netta: nessun metodo domina su tutti i compiti. Un modello che vince sulla media può perdere sul tuo corpus di procedure interne in italiano, e non c’è modo di saperlo se non provando.

Servono a restringere la lista dei candidati da tre a due, non a decidere. E se il problema è già sul tavolo di un cliente, cioè se l’assistente sta citando il documento sbagliato in produzione, quella è una taratura da fare su dati veri, non su una demo.

Resta il punto di fondo, che nessuna configurazione cancella: la similarità coseno risponde alla domanda «di cosa parla questo testo», non alla domanda «questo testo risponde alla mia domanda». Un sistema costruito sapendolo mette una soglia, un riordino e un filtro fra le due. Un sistema costruito senza saperlo restituisce con la stessa sicurezza la pagina giusta e quella accanto.

Misurare la vicinanza fra due significati serve al recupero dei documenti, ma la stessa geometria è al lavoro dentro il modello. Se vuoi vedere l’incastro completo, il percorso da una frase alla risposta lo ricostruisce passaggio per passaggio.

Fonti

• H. Steck, C. Ekanadham, N. Kallus, «Is Cosine-Similarity of Embeddings Really About Similarity?», arXiv:2403.05440 (WWW ’24 Companion)
• K. Zhou, K. Ethayarajh, D. Card, D. Jurafsky, «Problems with Cosine as a Measure of Embedding Similarity for High Frequency Words», ACL 2022
• K. Ethayarajh, «How Contextual are Contextualized Word Representations?», EMNLP-IJCNLP 2019
• A. Ettinger, «What BERT Is Not: Lessons from a New Suite of Psycholinguistic Diagnostics for Language Models», TACL 2020
• N. Thakur et al., «BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models», arXiv:2104.08663
• N. Muennighoff et al., «MTEB: Massive Text Embedding Benchmark», arXiv:2210.07316
• Y. Malkov, D. Yashunin, «Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs», arXiv:1603.09320
• A. Kusupati et al., «Matryoshka Representation Learning», arXiv:2205.13147
• OpenAI, documentazione ufficiale «Embeddings» (normalizzazione, dimensioni, parametro dimensions)
• Sentence-Transformers, documentazione «Retrieve & Re-Rank»
• Cohere, documentazione «Rerank Overview»
• Qdrant, documentazione «Filtering»
• Anthropic, «Introducing Contextual Retrieval» (riduzione del tasso di fallimento del recupero: 35%, 49%, 67%)