Perché un sistema RAG trova il documento sbagliato (anche se esiste quello giusto)

·

5 min

Link al paper di riferimento: On the Theoretical Limitations of Embedding-Based Retrieval

Paper originale

Un archivio enorme, una domanda semplice

Immagina un archivio tecnico con migliaia di manuali, macchinari, impianti, software, etc,. Ogni manuale copre una combinazione specifica di macchinario e tipologia di guasto.
Avviene un guasto ad una macchina in produzione, il tecnico apre la propria chat e fa una domanda precisa: “trovami il manuale che riguarda questo modello di macchina e questo tipo di guasto”. Il documento esiste, è lì, da qualche parte nell’archivio. Eppure il sistema RAG restituisce qualcos’altro: un manuale sullo stesso modello ma un guasto diverso, o sullo stesso guasto ma un modello diverso. Vicino, plausibile, ma purtroppo inutile.

La reazione istintiva è pensare che il sistema “non abbia capito bene” la domanda, o che serva un modello di embedding più potente. Ma purtoppo un paper recente di Google DeepMind e Johns Hopkins University dice qualcosa di più scomodo: in certi casi, nessun modello potrebbe farcela, per un motivo che non ha a che fare con quanto è “intelligente”, ma con la matematica che sta sotto la ricerca semantica.

Come funziona (in breve) la ricerca semantica

Ogni sistema RAG trasforma frasi e documenti in vettori numerici, gli embedding, e poi cerca i documenti il cui vettore è più “vicino” a quello della domanda, in uno spazio con centinaia o migliaia di dimensioni. L’idea è che frasi con significato simile finiscano vicine in questo spazio, anche se usano parole diverse. Funziona sorprendentemente bene per domande generiche (“parlami della manutenzione dei motori elettrici”). Il problema emerge quando la domanda non cerca un tema, ma l’intersezione esatta di più criteri.

Il limite dimostrato dal paper

Lo studio (“On the Theoretical Limitations of Embedding-Based Retrieval”, accettato a ICLR 2026) parte da una domanda diretta: può un singolo vettore, di dimensione fissata, rappresentare tutte le possibili combinazioni di rilevanza tra un insieme di domande e un insieme di documenti? La risposta, dimostrata matematicamente collegandosi a risultati noti di teoria della comunicazione, è no. Per ogni dimensione dell’embedding esiste un punto critico oltre il quale alcune combinazioni specifiche di documenti rilevanti non possono essere restituite da nessuna query, qualunque sia il modo in cui viene formulata. Non è che il modello “non trova” quella combinazione: è che lo spazio vettoriale, con quella dimensione, non ha abbastanza gradi di libertà per rappresentarla.

Per rendere il problema concreto, non solo teorico, i ricercatori hanno costruito un dataset apposito con domande linguisticamente banali (“chi ama le mele?”) ma costruite in modo da richiedere esattamente questo tipo di intersezione tra criteri. Anche i migliori modelli di embedding in commercio, su questo compito, crollano: in uno degli esperimenti il recall scende sotto il 20% quando l’archivio supera una certa soglia di documenti, mentre un motore di ricerca “vecchio stile” basato su corrispondenza di parole chiave (BM25), su questo specifico compito, se la cava sensibilmente meglio.

Numeri alla mano

Per dare un’idea di scala: con un embedding di 512 dimensioni, il limite teorico si colloca intorno a mezzo milione di documenti; a 1024 dimensioni, intorno a 4 milioni, e questo nello scenario migliore possibile, con il vettore ottimizzato ad hoc per il compito. Un archivio aziendale reale, con documenti più ambigui e un modello non ottimizzato su misura, arriva a toccare questi limiti molto prima.

Perché conta per chi costruisce (o commissiona) un sistema RAG

Il punto non è che la ricerca semantica “non funziona”: per il suo compito originale, trovare contenuti concettualmente simili, resta lo strumento giusto. Il punto è che un singolo vettore per documento ha un soffitto strutturale quando la domanda richiede di incrociare più criteri contemporaneamente, ed è esattamente il tipo di domanda che un’azienda fa più spesso di quanto si pensi: non “parlami di X”, ma “trovami il caso che ha sia questa caratteristica sia quest’altra”.

La parte pratica, per fortuna, è meno drammatica della scoperta teorica: i correttivi esistono e sono già usati in sistemi RAG progettati bene. Combinare la ricerca semantica con una ricerca per parole chiave (ibrida), aggiungere un passaggio di reranking che riordina i risultati con un modello più preciso ma più lento, o usare modelli multi-vettore invece di un singolo vettore per documento, riduce drasticamente il problema. Nessuno di questi è un dettaglio implementativo marginale: è la differenza tra un prototipo che funziona bene in demo e un sistema che regge davvero su un archivio aziendale di migliaia di documenti.

Chiusura

Il paper di DeepMind non dice “la ricerca semantica è rotta”. Dice qualcosa di più utile: ha un limite conosciuto, misurabile, prevedibile, non un difetto misterioso che emerge quando l’archivio cresce. E un limite che conosci in anticipo è un limite che puoi progettare per aggirare, invece di scoprirlo quando il sistema è già in produzione e un tecnico, davanti al guasto giusto, continua a ricevere il manuale sbagliato.

Fonte: “On the Theoretical Limitations of Embedding-Based Retrieval”, Google DeepMind & Johns Hopkins University, ICLR 2026