Quando un assistente basato su RAG — quelli che rispondono usando i documenti dell'azienda — dà risposte sbagliate, la reazione istintiva è sempre la stessa: «serve un modello più potente», oppure «riscriviamo il prompt». Quasi sempre è la mossa sbagliata, e anche la più costosa. Il collo di bottiglia è a monte, in un componente di cui si parla poco: il retrieval, cioè la ricerca che decide quali documenti finiscono sotto gli occhi del modello. Se il documento con la risposta non arriva sul suo tavolo, nessun modello — per quanto grande — può inventarselo.
È il seguito naturale delle cinque lezioni dalla nostra piattaforma RAG, dove scrivevamo che «la qualità si decide nel retrieval». Qui spieghiamo perché — e soprattutto come accorgersene prima di spendere.
Il numero che gira nelle presentazioni
Circola ovunque la cifra «il 95% dei progetti di IA generativa fallisce». Viene da un report del MIT (The GenAI Divide, 2025), secondo cui il 95% dei progetti pilota non produce un impatto misurabile sul conto economico, a fronte di 30–40 miliardi di dollari investiti.
Tre onestà necessarie prima di usare quel numero: non è un dato specifico sul RAG ma sui pilot GenAI in generale; «nessun impatto misurabile sui conti» non significa «il sistema non funziona»; e la metodologia del report è stata contestata per la fragilità del campione rispetto al titolo.
Detto questo, il report indica una causa che coincide con la nostra esperienza sul campo: il problema non sta nella qualità dei modelli, ma nell'integrazione — nel contesto che gli si dà. La tesi di questo articolo è quindi più circoscritta e più difendibile: nella maggioranza dei progetti RAG che abbiamo visto arenarsi, la causa prima è la ricerca, non il modello. Ed è una tesi che si può misurare, non solo raccontare.
Il tetto che nessun modello può sfondare
Un sistema RAG è una catena di due anelli: c'è un componente che cerca i passaggi rilevanti nei vostri documenti, e un modello che scrive la risposta leggendo quei passaggi. Tutta l'attenzione (e il budget) va di solito al secondo anello. Ma vale una regola tanto banale quanto ignorata:
La qualità massima delle risposte è limitata dalla qualità della ricerca: se il passaggio giusto non viene trovato, il modello può solo dire «non lo so» — oppure inventare.
Non esiste una terza opzione. Cambiare modello sposta la scelta tra queste due, non risolve il problema. Ecco perché il primo investimento sensato non è un modello più grande: è misurare quanto spesso la ricerca porta il documento giusto. Se lo fa 6 volte su 10, il tetto di accuratezza dell'intero sistema è il 60% — e nessuna sistemazione del prompt lo alzerà.
Perché la ricerca sbaglia
Le cause ricorrenti sono poche e concrete:
- Documenti spezzati male. Per essere cercati, i documenti vengono divisi in frammenti. Se il taglio è meccanico, una tabella finisce a metà, una regola si separa dalla sua eccezione, e il frammento «in tal caso il termine è ridotto a 15 giorni» non dice più di quale caso parla.
- Parole diverse per la stessa cosa. L'utente chiede «posso pagare a rate una bolletta scaduta?», il documento parla di «piano di rientro per posizioni insolute». Zero parole in comune: la ricerca per parole chiave non lo troverà mai.
- La correzione che crea il problema opposto. La risposta tipica è passare alla ricerca «semantica», che capisce il significato al di là delle parole. Vero — ma è debole proprio dove l'altra è forte: codici prodotto, sigle, numeri di articolo, nomi propri. Il codice errore
ERR_5012la ricerca per parole lo trova al primo colpo; quella semantica lo «annega» tra concetti simili. - Nessun collaudo. Il peccato originale: senza un insieme di domande vere con la risposta attesa, ogni modifica è una scommessa e ogni riunione un confronto di opinioni.
La soluzione: far lavorare due ricerche insieme
Il punto chiave: la ricerca per parole e la ricerca per significato sbagliano su domande diverse e complementari. Non è una scelta tra le due — servono entrambe.
La ricerca ibrida fa esattamente questo: esegue le due ricerche in parallelo e ne fonde le classifiche con un criterio che premia il consenso — un documento trovato da entrambe, anche se non in cima, batte un documento primo per una sola. Che è il comportamento giusto: un passaggio trovato sia dalle parole sia dal significato è quasi certamente quello che serve.
Un esempio reale, che abbiamo verificato con i numeri alla mano. Domanda: «posso rateizzare una fattura già scaduta?». Il documento giusto — quello sul «piano di rientro per crediti insoluti» — era quinto nella classifica della ricerca per parole e quarto in quella per significato: con una sola delle due tecniche non sarebbe mai entrato tra i primi tre passaggi letti dal modello, e la risposta sarebbe stata sbagliata. Con la fusione delle due classifiche è salito al primo posto — perché era l'unico presente in tutte e due.
| Strategia di ricerca | Posizione del documento giusto | Il modello lo legge? |
|---|---|---|
| Solo per parole chiave | 5ª | ✗ |
| Solo per significato | 4ª | ✗ |
| Ibrida (fusione delle due) | 1ª | ✓ |
Due cose importanti per chi decide. Primo: non è tecnologia esotica — la ricerca ibrida è integrata di serie nei principali motori di ricerca enterprise (Elasticsearch, OpenSearch, Azure AI Search) e si abilita, non si inventa. Secondo: dopo la ricerca serve un passaggio di riordino dei risultati, perché i modelli leggono meglio ciò che sta in cima al contesto — un dettaglio documentato in letteratura che da solo cambia sensibilmente la qualità percepita.
È la stessa filosofia della nostra piattaforma ACME ECMS IA & RAG Integration: più assi di ricerca sulla base di conoscenza e riordino dei passaggi prima della generazione. Non è teoria: è lo schema pubblicato in quella pagina.
Come si capisce se funziona (prima di fidarsi)
Il collaudo è sorprendentemente semplice, e quasi nessuno lo fa. Si costruisce un set di prova: 50–100 domande reali — raccolte da chi userà il sistema, non inventate a tavolino — ciascuna con l'indicazione del documento che contiene la risposta. Poi si misura una cosa sola, sulla ricerca isolata, prima ancora di coinvolgere il modello: quante volte il documento giusto compare tra i primi risultati?
Quel numero è il tetto dell'intero progetto. Misurato prima e dopo ogni intervento — attivazione della ricerca ibrida, riordino, taglio migliore dei documenti — trasforma le discussioni in decisioni: si vede in una tabella che cosa ha migliorato le cose e di quanto, e si smette di attribuire al «modello scarso» colpe che stanno altrove.
Le cinque domande da fare a chi ve lo costruisce
- Esiste un set di prova con domande nostre e risposte attese? Possiamo vederlo?
- Qual è la percentuale di volte in cui la ricerca porta il documento giusto tra i primi risultati, misurata sul nostro archivio?
- La ricerca usa entrambi gli assi — parole chiave e significato — o uno solo?
- C'è un passaggio di riordino dei risultati prima che il modello li legga?
- Quando una risposta è sbagliata, sapete dirci se il documento giusto era stato trovato? (Se sì, il problema è la generazione; se no, è la ricerca. Nella nostra esperienza è quasi sempre la seconda.)
Se a queste domande arrivano risposte vaghe, il progetto sta navigando a vista — qualunque modello ci sia sotto.
La sintesi
Il RAG non fallisce perché il modello è stupido. Fallisce perché gli si dà da leggere il documento sbagliato — e poi lo si accusa di aver risposto male.
Prima di investire in un modello più grande: misurare la ricerca, attivare l'asse che manca, aggiungere il riordino. Nella nostra esperienza è l'ordine di interventi con il miglior rapporto tra risultato e costo — ma è un'esperienza, non un teorema: il set di prova costruito sulle vostre domande è l'unico arbitro che conta.
Se il vostro assistente documentale si è arenato in fase pilota, possiamo guardarci dentro insieme — partendo, ovviamente, dalla misura.
Fonti.
- MIT Media Lab, Project NANDA — The GenAI Divide: State of AI in Business 2025 (luglio 2025); sintesi su Fortune, 18 agosto 2025. La metodologia è stata oggetto di critiche indipendenti per la fragilità del campione.
- Sulla fusione delle classifiche (Reciprocal Rank Fusion): Cormack, Clarke, Büttcher, SIGIR 2009; documentazione di Azure AI Search, Elastic e OpenSearch. L'esempio numerico citato è stato ricalcolato e verificato dalla redazione.
- Sul degrado di lettura nei contesti lunghi: Liu et al., Lost in the Middle, TACL 2024.
