Chiunque costruisca sistemi di retrieval tende ad avere l’intuizione che gli embedding catturino il significato. È un’intuizione abbastanza corretta da essere utile e abbastanza sbagliata da causare incidenti in produzione.
Un vettore è una compressione, e ogni compressione ha delle priorità
Un modello di embedding viene addestrato ad avvicinare alcune coppie e ad allontanarne altre. Quali coppie dipende interamente dall’obiettivo con cui è stato addestrato. Un modello addestrato su coppie domanda-risposta mette una domanda vicino alla sua risposta. Un modello addestrato sulle parafrasi mette una frase vicino a una sua riformulazione. Sono geometrie diverse, e una domanda non è necessariamente vicina alla propria risposta in uno spazio addestrato sulle parafrasi.
Questo è il fallimento silenzioso più comune nei sistemi RAG: fare retrieval con un modello di similarità quando il task reale è question answering. I punteggi sembrano buoni. I vicini sono pertinenti all’argomento. La risposta non è fra loro.
La geometria è anisotropa
Gli spazi di embedding non sono popolati in modo uniforme. I vettori tendono ad addensarsi in un cono stretto, il che significa che la similarità coseno grezza fra due testi arbitrari è spesso alta quasi indipendentemente dal contenuto — frequentemente 0,7 o più anche per documenti non correlati. Le soglie assolute tarate su un corpus raramente si trasferiscono bene a un altro.
Lavora sui ranking, non sui punteggi. “I dieci vicini più prossimi” è un criterio portabile. “Tutto ciò che supera 0,82” è un numero che ti tradirà la settimana in cui cambia il corpus.
Lunghezza, formato e boilerplate dominano più di quanto sembri
Dividi in chunk due documenti che condividono lo stesso header di navigazione e lo stesso footer legale, e avrai incorporato nel vettore in parte il template invece del contenuto. I chunk lunghi fanno media e diluiscono la frase specifica che contava. Quelli corti perdono il referente — un paragrafo che dice “questo non deve superare il limite” è inutile se il limite è stato nominato due paragrafi prima.
Rimuovi il boilerplate prima di calcolare gli embedding e porta in ogni chunk un po’ di contesto strutturale — titolo del documento, intestazione della sezione — così il vettore sa a che cosa appartiene.
Testa lo spazio, non soltanto la pipeline
Costruisci un piccolo set etichettato usando domande reali e i passaggi che le rispondono davvero — cinquanta coppie bastano già per ottenere un’indicazione utile. Poi misura recall@k usando il k che utilizzi realmente. Se recall@20 è 0,6, nessun prompt engineering a valle può risolvere il problema: due risposte su cinque non sono mai entrate nella stanza.
Fallo prima di ottimizzare qualunque altra cosa. È il diagnostico più economico dello stack e ribalta regolarmente le ipotesi su quale modello di embedding convenga usare.
Che cosa portarsi a casa
Scegli il modello di embedding in base alla relazione che ti serve — domanda verso risposta oppure testo verso testo simile — non in base alla posizione in una classifica. Confronta i ranking anziché i punteggi assoluti. Pulisci il boilerplate. Misura il recall su domande reali. La geometria è uno strumento con una forma precisa, e molti problemi di retrieval nascono dal fatto che quella forma è sbagliata per il lavoro.