Il prototipo RAG di uno sviluppatore rifiutava qualsiasi query con una similarità del coseno inferiore a 0,50. Funzionava perfettamente — finché il modello di embedding non è stato sostituito. Il guard ha poi lasciato passare risposte errate silenziosamente. L'incidente dimostra che una soglia di similarità hard-coded può crollare tra i diversi modelli, un rischio che minaccia qualsiasi sistema che si affidi alla similarità degli embedding per i controlli di sicurezza.
Perché la soglia era importante
Le pipeline di Retrieval-Augmented Generation (RAG) utilizzano spesso un similarity guard: se la similarità del coseno tra una query e il documento più vicino scende sotto un valore prestabilito, il sistema interrompe la risposta. Il guard impedisce al modello di allucinare quando il contesto recuperato è debole. Nella configurazione originale, una soglia di 0,50 manteneva il sistema onesto: le query non rispondibili ottenevano punteggi sotto la soglia, quelle rispondibili sopra.
Quando il backend di embedding è cambiato, lo stesso cut-off di 0,50 non ha più separato i due gruppi. La pipeline ha iniziato a restituire risposte sicure, ma errate, senza alcun crash o errore esplicito. Il fallimento è sfuggito alle metriche di ranking standard ed è emerso solo quando un essere umano ha notato la deriva.
La geometria non è universale
Ogni modello di embedding mappa il linguaggio in uno spazio ad alta dimensionalità con la propria geometria. I valori di similarità del coseno, pertanto, assumono significati diversi da un modello all'altro. Un punteggio di 0,50 può trovarsi al limite di un netto distacco per un modello e in una profonda zona di sovrapposizione per un altro.
- Voyage-3 – la linea dello 0,50 si trova tra le query non rispondibili a basso punteggio e quelle rispondibili ad alto punteggio. Il guard funziona come previsto.
- BGE-Small – molte query non rispondibili ottengono punteggi superiori a 0,50, quindi il guard non scatta mai. Alzare il cut-off a 0,70 ripristina il margine di sicurezza.
- Hashing-64 – i punteggi per le query rispondibili e non rispondibili si mescolano così strettamente che nessuna singola soglia può separarli; il modello è troppo debole per supportare affatto un similarity guard.
Questi casi illustrano una verità più ampia: una soglia appartiene a una specifica coppia modello-dati, non è una regola universale.
Il costo nascosto di una costante
Le soglie di similarità appaiono in molti task a valle:
- caching semantico
- rilevamento dei duplicati
- controlli di rilevanza dei documenti
- corrispondenza delle entità
Utilizzare un valore costante presuppone che tutti i modelli di embedding condividano la stessa distribuzione dei punteggi — un'assunzione pericolosa. Quando l'assunzione fallisce, i sistemi producono silenziosamente output con una falsa sicurezza, erodendo la fiducia dell'utente e fornendo dati errati ai processi a valle.
Calibrare i guard per ogni modello
La soluzione è semplice: non distribuire mai una costante hard-coded. Tratta la soglia come un iperparametro che deve essere ottimizzato per ogni nuovo modello di embedding.
- Assembla un modesto set di validazione etichettato che copra sia query rispondibili che non rispondibili.
- Calcola le similarità del coseno per ogni coppia query-documento utilizzando il modello target. 3