Per chi lavora con AI aziendale, una delle pietre miliari è stata la nascita degli embedding vettoriali: trasformare testi, immagini, audio in “vettori” numerici in uno spazio ad alta dimensione, per permettere al sistema di riconoscere somiglianze semantiche, rispondere a query complesse, effettuare ricerche intelligenti. Questa tecnica è al cuore dei sistemi RAG (Retrieval-Augmented Generation), che uniscono memoria/documenti esterni + modelli generativi per rispondere in modo informato, contestuale, “intelligente”.
Eppure, un recente studio condotto da DeepMind rivela che questa tecnologia, potente come è, ha un collo di bottiglia insospettato: un limite matematico strutturale, che non si supera semplicemente con modelli più grandi o più dati, ma che emerge quando le richieste di ricerca si fanno “complesse” — e cioè quando serve che una query identifichi non uno, ma molti documenti rilevanti; quando rilevanza non vuol dire “uno simile al quesito”, ma “una combinazione specifica di documenti”.
Ciò che distingue questo studio è che non si tratta solo di fare benchmark più duri, o interrogarsi se i modelli sbagliano su certi dati “strani”: DeepMind ha cercato di capire qual è il limite intrinseco di questa architettura “single-vector embedding”. Hanno costruito esperimenti ideali, in cui si bypassa quella che è la variabilità del linguaggio naturale, le imperfezioni del modello, le differenze di dominio: si lavora direttamente con vettori numerici ottimizzati per la ricerca, nella forma più pura.
Anche in quelle condizioni “perfette”, è emerso che, per qualsiasi dimensione dell’embedding (cioè quanti numeri compongono ogni vettore), arriva un punto critico in cui diventa impossibile rappresentare tutte le possibili combinazioni di documenti che potrebbero essere rilevanti. Se hai tantissimi documenti, e vuoi rispondere query che chiedono insiemi di documenti specifici (non solo “trova il documento più simile”), la capacità geometrica dello spazio vettoriale finisce per non bastare.
Questa scoperta ribalta un po’ molte convinzioni diffuse: spesso si pensa che basti “più dimensioni”, più dati, più esempi di addestramento per far diventare un embedding “abbastanza buono”. Ma lo studio mostra che anche con dimensioni grandi, anche con addestramento perfetto, se il numero di documenti cresce molto (come succede su scala web), il singolo vettore resta inadeguato a garantire sempre risposte corrette per tutte le query che implicano combinazioni.
Per mostrare concretamente questo limite, DeepMind e i suoi collaboratori hanno creato un dataset chiamato LIMIT. Non è un dataset costruito per far soffrire il modello con frasi astruse: i documenti sono semplici, le domande chiare, ma l’organizzazione è pensata per esplorare molteplici combinazioni di documenti rilevanti. Ad esempio, un documento può essere rilevante per molte query diverse, le relazioni tra documenti e query si incrociano, si sovrappongono.
I risultati sono sorprendenti: sistemi all’avanguardia di embedding (di Google, Snowflake e altri) fanno fatica su LIMIT. In molti casi, il recall — la percentuale di documenti rilevanti che vengono effettivamente trovati — scende sotto il 20 % quando la query richiede l’identificazione di un insieme completo di documenti rilevanti. E non basta “allenare con LIMIT” per risolvere: anche quando i modelli vengono finemente ottimizzati per quel dataset, l’aumento di performance è minimo. Questo suggerisce che non è un problema di “non aver visto dati simili prima” (domain shift) ma un limite più profondo.
Un fatto particolarmente interessante: in molti compiti del dataset LIMIT, metodi “tradizionali” come BM25 — basati su ricerca testuale lessicale, matching di parole chiave — performano sorprendentemente bene, meglio di molti sistemi più moderni basati solo su embedding. È un promemoria che tecniche antiche, ben calibrate, restano utili — in certi scenari anche migliori, quando la struttura della domanda-risposta richiede precisione combinatoria.
La lezione è evidente: non si può più dare per scontato che embedding vettoriali “facciano tutto”. Per i prodotti che si basano su RAG, semantic search, assistenti con accesso a grandi corpora, è importante capire quando una query richiede non solo “trovare il documento più vicino”, ma “trovare tutti i documenti che soddisfano condizioni multiple” (ad esempio query che usano “e”, “sia… che”, “sia questo che quello”, “comparare”…). In quei casi, il modello potrebbe fallire silenziosamente, restituendo solo una parte delle risposte utili.
Uno scenario tipico: hai un sistema che deve aiutare un team legale a trovare tutti i documenti di contratto che contengono clausole A, B e C; oppure un motore di ricerca interno che deve restituire tutti gli studi clinici che condividono certe proprietà. Se il sistema si affida solo a embedding singoli, potrebbe restituire solo uno dei documenti o tutti quelli che appaiono più “vicini”, ma non garantire che compaiano tutti quelli rilevanti. E a volte quel che manca è proprio critico.
Anche se il problema è strutturale, lo studio non lascia le mani in mano ai lettori: propone alcune strade per gestire la situazione, per rendere i sistemi più robusti.
Una di queste è quella che potremmo chiamare architettura ibrida. In pratica significa non usare solo embeddings densi (dense embeddings) ma combinare metodi diversi: quelli semantici, che “capiscono il concetto” anche se non è la stessa espressione, insieme a metodi sparsi (sparse) come BM25, che funzionano bene quando le condizioni della query richiedono precisione testuale. Usare entrambi permette di avere resilienza: se l’embedding fallisce nel catturare tutte le combinazioni, il metodo lessicale può contribuire a colmare il vuoto.
Un’altra idea è cambiare il modo in cui si valutano i modelli. Spesso, i benchmark che usiamo per dire “questo modello è tra i migliori” testano scenari relativamente semplici — non stressano il modello su tutte le combinazioni possibili, su query complesse, su set di documenti che si sovrappongono molto. Lo studio suggerisce di creare valutazioni interne simili alla realtà aziendale: domande che richiedono di recuperare insiemi di documenti specifici, di testare con molte query “combinate”, di verificare cosa succede quando una query contiene “e”, “o”, “sia… sia”, “compara”.
Poi ci sono le architetture alternative che potrebbero vincere la sfida: modelli che usano multi-vector embeddings (cioè non uno ma più vettori per rappresentare un documento, per catturare diversi aspetti), cross-encoder (che esaminano insieme query e documento prima di decidere, piuttosto che separatamente), oppure modelli che permettano rappresentazioni più ricche, più contestuali, che non comprimano tutto in un solo punto vettoriale.
Non tutto è nero: il fatto che il limite emerga non significa che tutti i sistemi falliranno in tutte le situazioni. Per molte applicazioni, soprattutto quelle in cui si cerca semplicemente uno o pochi documenti rilevanti, o dove il set di documenti non è enorme, o le query non richiedono combinazioni complesse, gli embedding singoli funzionano molto bene. Molti prodotti oggi restano validi ed efficaci.
Tuttavia, per aziende che operano su scala vasta (migliaia o milioni di documenti), per casi in cui la rilevanza non è lineare ma combinatoria, per caratteristiche come affidabilità, comprensione completa, trasparenza, queste scoperte vanno prese molto sul serio. Il rischio è che sistemi che sembrano andare bene nei test standard comincino a mostrare debolezze non previste nel reale utilizzo: mancano documenti importanti nelle risposte, si perde parte dell’informazione richiesta, gli utenti vengono delusi — e questo può compromettere fiducia e valore.
Lo studio di DeepMind ci mette di fronte a una verità che non sempre si vuole riconoscere: il progresso tecnologico non significa automaticamente che i vecchi limiti siano spariti. Gli embedding vettoriali sono una tecnologia potente, ma non infallibile. Hanno limiti intrinseci che emergono quando le richieste di ricerca diventano più sofisticate, quando serve combinare informazioni, quando si lavora su scala molto grande.
Per le imprese, i product manager, gli architetti dell’AI, la sfida è ascoltare il dataset “LIMIT” come se fosse uno specchio che ci fa vedere ciò che potremmo non aver voluto vedere: che il sistema ideale non è quello che funziona bene sui benchmark popolari, ma quello che tiene insieme tecniche, che verifica, che costruisce valutazioni realistiche, che considera combinazioni.
Questo non significa che dobbiamo abbandonare gli embedding, ma che li dobbiamo usare con consapevolezza, nel modo giusto, sapendo dove rischiano di cedere, integrandoli con altre tecniche, testandoli su casi reali, costruendo architetture ibride. Solo così le promesse del RAG, della ricerca semantica, dei sistemi intelligenti, possono davvero tradursi in affidabilità concreta.