Una base di conoscenza RAG aziendale non è «caricare tutto il disco condiviso in un database vettoriale». È uno strato di ingegneria composto da quattro parti: fonti selezionate, suddivisione corretta dei documenti, ricerca ibrida con riordino e applicazione dei permessi. Secondo i report dei fornitori pubblicati nel 2026, tra il 70% e l’80% dei progetti RAG aziendali non arriva mai in produzione, e la maggior parte dei fallimenti nasce negli strati di ingestione e ricerca, non nel modello. Questa guida scompone i quattro strati e propone un piano a 90 giorni.
Perché la maggior parte dei progetti RAG muore prima della produzione
Lo schema si ripete. Un team costruisce un pilota in due settimane, la demo colpisce, poi il sistema incontra la realtà organizzativa e si sgretola. Uno studio MLOps Community del 2026 su 143 implementazioni RAG aziendali ha rilevato che il 73% ha subito almeno un guasto critico nel primo trimestre in produzione, e che il 41% di quei guasti non è mai stato segnalato dalle suite di valutazione standard.
La causa non è quasi mai la scelta del modello. La stima più citata nel settore è che l’80% dei fallimenti RAG risalga allo strato di ingestione e suddivisione. In altre parole: quando il sistema restituisce una risposta sbagliata, nella maggior parte dei casi al modello era stato passato il brano sbagliato fin dall’inizio. È una distinzione che conta, perché sposta il budget: non verso un modello più costoso, ma verso l’ingegneria del recupero.
Cosa comporta per il budget: nel 2026 il RAG non è un problema di modello, è un problema di ingegneria del recupero. Migliorare la suddivisione e il riordino produce un salto di accuratezza superiore al passaggio a un modello più costoso, con costi di esercizio molto più bassi. Se state monitorando l’economia unitaria di un progetto di IA, è la differenza tra un costo variabile che cresce con l’uso e un investimento una tantum in infrastruttura.
I quattro strati di una base di conoscenza aziendale
| Strato | Che cosa fa | Errore ricorrente |
|---|---|---|
| Fonti e metadati | Quali documenti entrano, chi ne è responsabile, quando sono stati aggiornati l’ultima volta | Ingerire tutto in una volta, comprese versioni obsolete e bozze |
| Suddivisione | Dividere i documenti nei brani che il modello riceve come contesto | Una sola regola di suddivisione per ogni tipo di documento, che spezza tabelle e sezioni |
| Recupero e ordinamento | Trovare i brani rilevanti e restituire i migliori | Affidarsi alla sola ricerca vettoriale, senza corrispondenza per parole chiave |
| Permessi | Garantire che un utente veda soltanto ciò a cui ha diritto | Permessi verificati nell’interfaccia anziché al momento del recupero |
Come suddividere correttamente i documenti
La suddivisione è la decisione che incide di più sull’accuratezza ed è anche quella che la maggior parte dei team prende per inerzia. Nel 2026 contano tre famiglie di metodi:
| Metodo | Più adatto a | Dimensione del blocco consigliata |
|---|---|---|
| Suddivisione ricorsiva a dimensione fissa | Prosa discorsiva, documenti di policy, descrizioni di processo | 256-512 token per domande e risposte fattuali |
| Suddivisione semantica | Documenti tecnici, specifiche, documentazione di prodotto | 512-1.024 token per compiti analitici |
| Late chunking (suddivisione tardiva) | Documenti lunghi in cui il contesto attraversa i confini fra sezioni | Prima si vettorializza l’intero documento, poi lo si suddivide |
Una regola pratica: un blocco deve contenere una risposta completa a una singola domanda. Se consegnaste quel brano su carta a un collega, riuscirebbe a rispondere senza consultare altro? Se no, il blocco è troppo corto. Se il brano copre tre argomenti diversi, è troppo lungo e la ricerca vettoriale farà fatica a metterlo a fuoco.
Due errori ricorrenti: spezzare le tabelle a metà, il che trasforma i dati numerici in rumore, e perdere il titolo gerarchico. La correzione del secondo costa poco: anteporre a ogni blocco una riga di contesto con nome del documento, sezione e data.
Ricerca ibrida e riordino
La sola ricerca vettoriale manca proprio ciò che le organizzazioni chiedono: codici articolo, nomi di clienti, codici di errore, clausole contrattuali. Sono stringhe esatte che l’embedding semantico sfuma. Per questo la ricerca ibrida, che combina embedding densi e corrispondenza per parole chiave in stile BM25, continua a superare la ricerca puramente densa sulla maggior parte dei tipi di documento aziendale.
La struttura diventata un punto di partenza comune: recuperare 20 candidati, riordinarli con un modello di reranking e passare i primi cinque all’LLM. Il riordino è il passo con il miglior rapporto resa/sforzo, perché corregge gli errori di recupero senza toccare lo strato di suddivisione.
Permessi: lo strato che tutti rimandano
È qui che muoiono i piloti. In un pilota tutti vedono tutto, poi arriva il momento in cui un agente del supporto non deve vedere i documenti delle buste paga. Se i permessi sono applicati solo nell’interfaccia, il recupero legge comunque il documento e il modello può ancora citarlo. L’applicazione deve avvenire al momento del recupero, come filtro sui metadati, prima che i brani raggiungano il modello.
In pratica: ogni blocco porta con sé gli identificativi dei gruppi autorizzati a vederlo, e la query filtra su quelli. È anche ciò che rende il sistema verificabile, perché potete mostrare esattamente quali documenti hanno alimentato ciascuna risposta.
Come misurare che il sistema funzioni
Circa il 70% dei team che gestiscono RAG in produzione non misura sistematicamente la qualità del recupero. È per questo che i guasti passano inosservati. Il quadro accettato è la «triade RAG», tre assi che potete eseguire automaticamente su un set fisso di domande:
| Asse | La domanda che verifica | Cosa fare quando è basso |
|---|---|---|
| Rilevanza del contesto | Il recupero ha trovato i documenti giusti? | Correggere la suddivisione, aggiungere la ricerca ibrida |
| Fondatezza nelle fonti | La risposta è davvero sostenuta dai brani recuperati? | Stringere il prompt, richiedere la citazione della fonte |
| Rilevanza della risposta | La risposta affronta ciò che è stato chiesto? | Scomporre le domande a più passaggi |
Un punto debole noto: il 71% dei sistemi RAG in produzione fallisce sulle domande a più passaggi, quelle che richiedono di combinare informazioni da due documenti diversi. Se è il vostro caso d’uso principale, costruite il set di valutazione attorno a esso dal primo giorno, anziché attorno a semplici domande fattuali che passano sempre.
Ciò che distingue i team che consegnano: un set di valutazione documentato, versionato ed eseguito automaticamente ogni notte. Senza, ogni modifica alla suddivisione o al prompt è una scommessa e non potete sapere se avete migliorato o rotto qualcosa.
Un piano a 90 giorni
Giorni 1-30: scegliete un caso d’uso con un pubblico definito. Mappate soltanto i 50-200 documenti rilevanti, eliminate le versioni obsolete e assegnate a ogni documento un responsabile e una data di ultimo aggiornamento. In parallelo, scrivete 40 domande reali che il team pone davvero, con risposte approvate. Quello è il vostro set di valutazione.
Giorni 31-60: costruite la pipeline: suddivisione, embedding, ricerca ibrida, riordino, filtro dei permessi. Eseguite il set di valutazione e registrate un punteggio di riferimento su tutti e tre gli assi. Migliorate suddivisione e ordinamento finché la rilevanza del contesto non si stabilizza.
Giorni 61-90: aprite a un vero gruppo pilota, registrate ogni domanda insieme ai brani recuperati e aggiungete un pulsante di feedback. Le domande fallite diventano aggiunte al set di valutazione. Solo dopo due settimane consecutive di metriche stabili estendete ad altre fonti.
Se lo state costruendo per la prima volta, leggete anche come misurare la visibilità nei motori di risposta IA: la stessa disciplina di misurazione vale sul fronte esterno. E quando arrivate al rilascio organizzativo, la nostra pratica di implementazione dell’IA parte esattamente da questo esercizio di mappatura.
Domande frequenti
Quanti documenti servono per avviare un progetto RAG aziendale?
Molti meno di quanto si pensi. Un singolo caso d’uso è ben coperto da 50-200 documenti puliti e aggiornati. Ingerire decine di migliaia di documenti all’inizio abbassa l’accuratezza, perché versioni obsolete e bozze competono per gli stessi slot di recupero.
Qual è la dimensione del blocco consigliata?
Tra 256 e 512 token per domande fattuali e tra 512 e 1.024 token per compiti analitici. La regola pratica: un blocco deve contenere una risposta completa a una singola domanda, senza spezzare le tabelle e senza perdere il titolo di sezione.
Perché la sola ricerca vettoriale non basta?
Perché sfuma le stringhe esatte come codici articolo, codici di errore e nomi di clienti. La ricerca ibrida, che combina embedding e corrispondenza per parole chiave in stile BM25, dà risultati migliori su quasi ogni tipo di documento aziendale.
Come si garantisce che un utente non veda mai un documento non consentito?
Applicando i permessi al momento del recupero anziché nell’interfaccia. Ogni blocco porta gli identificativi dei gruppi autorizzati a vederlo e la query filtra su quelli prima che qualsiasi brano raggiunga il modello.
Quanto tempo serve per arrivare in produzione?
Un singolo caso d’uso mirato può arrivare a un pilota reale in circa 90 giorni: un mese per mappare le fonti e costruire un set di valutazione, un mese per costruire e tarare la pipeline e un mese di pilota con feedback reale.