Il manuale aggiornato è in una cartella, la procedura per i resi in un’altra e il team continua a chiedere le stesse informazioni agli esperti. Una RAG può trasformare quei documenti in risposte consultabili e corredate di fonti, ma il risultato dipende da come i contenuti vengono preparati e recuperati.
Una RAG aziendale funziona quando recupera fonti pertinenti e verificabili
- RAG combina ricerca nei documenti e generazione di risposte con un modello linguistico.
- La qualità dei contenuti e dei permessi incide su ciò che il modello può citare.
- Ricerca e risposta vanno valutate separatamente: una risposta fluida può basarsi su passaggi sbagliati.
- Un primo caso d’uso circoscritto aiuta a capire se il sistema risolve un problema aziendale misurabile.
La RAG risponde usando documenti che l’azienda può aggiornare
Quando una persona pone una domanda, il sistema cerca nei contenuti autorizzati, seleziona passaggi pertinenti e li fornisce al modello come contesto. Il modello formula la risposta a partire da quel materiale e può indicare i documenti da cui proviene l’informazione: è questa combinazione di recupero e generazione a definire la Retrieval-Augmented Generation.
La differenza pratica rispetto a un chatbot basato solo sul modello è che la risposta può riflettere procedure interne e informazioni aggiornate senza riaddestrare il modello ogni volta che cambia un documento. Ma una citazione non garantisce da sola che la risposta sia corretta: se il sistema recupera la versione sbagliata di una policy, può riassumerla con sicurezza e fuorviare chi legge. ([learn.microsoft.com](https://learn.microsoft.com/en-us/azure/foundry/concepts/retrieval-augmented-generation?trk=article-ssr-frontend-pulse_little-text-block))
Il primo caso d’uso dovrebbe avere confini chiari
Una RAG è adatta quando le risposte esistono già in fonti consultabili, ma trovarle richiede tempo o coinvolge sempre le stesse persone. Un archivio di procedure per il servizio clienti, per esempio, può diventare una base interrogabile che restituisce istruzioni e riferimenti ai documenti pertinenti.
La scelta è meno convincente se il problema richiede di prendere decisioni autonome, aggiornare sistemi o applicare regole complesse in più passaggi: in questi casi possono servire integrazioni e controlli ulteriori, oppure un’architettura diversa. Se il bisogno è trovare e sintetizzare informazioni documentate, prova una RAG su un reparto; se il sistema deve anche eseguire azioni, definisci prima autorizzazioni e responsabilità. Ritengo più prudente partire da un processo circoscritto che collegare subito l’assistente a tutta l’azienda.
Questa cautela è coerente con uno studio basato su interviste a 13 professionisti dell’industria: gli autori descrivono applicazioni spesso limitate a domande e risposte specialistiche e ancora in fase di prototipo; tra le difficoltà riportate compaiono la preparazione dei dati e la valutazione dei sistemi. Il dato non prova che ogni progetto aziendale seguirà lo stesso percorso, ma invita a non scambiare una demo convincente per un servizio pronto all’uso. ([arxiv.org](https://arxiv.org/abs/2508.14066))
Documenti, permessi e ricerca determinano quali risposte arrivano
Una base documentale disordinata si traduce in risultati disordinati. Prima dell’indicizzazione, controlla se i file contengono versioni superate, tabelle difficili da estrarre, titoli poco descrittivi o passaggi privi di contesto; poi verifica che ogni documento conservi metadati utili, come reparto, data di validità e proprietario.
Il sistema suddivide i documenti in porzioni di testo, chiamate chunk, che il motore cerca in base alla domanda. Se sono troppo brevi, possono perdere il contesto; se sono troppo lunghe, possono mescolare istruzioni diverse. Anche la ricerca cambia il risultato: quella per parole intercetta termini esatti, quella vettoriale cerca somiglianze di significato, mentre una modalità ibrida combina i due approcci.
La protezione dei dati va progettata nella fase di recupero, non aggiunta come rifinitura. Se una persona non può leggere un documento nell’archivio aziendale, il filtro dei permessi deve impedirne il recupero anche tramite l’assistente; in caso contrario, la RAG rischia di rendere accessibili informazioni che l’interfaccia originale proteggeva. Un indice condiviso non dovrebbe diventare un accesso condiviso.
Una risposta sbagliata può dipendere dal recupero o dalla generazione
Quando l’assistente dà una risposta imprecisa, il problema può nascere prima che il modello scriva una parola. Potrebbe aver trovato documenti irrilevanti, oppure aver recuperato il passaggio giusto e averlo interpretato male: distinguere questi casi evita di correggere il prompt quando invece serve sistemare l’indice.
| Situazione | Possibile causa | Intervento |
|---|---|---|
| La risposta cita un documento superato | Indice non aggiornato o versioni duplicate | Rivedi le regole di aggiornamento e distingui le versioni tramite metadati. |
| Il passaggio recuperato non risponde alla domanda | Ricerca o segmentazione poco adatta ai documenti | Controlla le fonti restituite e prova una ricerca ibrida o chunk con più contesto. |
| La fonte è pertinente, ma la risposta aggiunge dettagli non presenti | Il modello ha oltrepassato il contesto fornito | Valuta l’aderenza alla fonte e istruisci il sistema ad astenersi quando mancano prove. |
| Una persona visualizza contenuti di un altro reparto | Filtri di autorizzazione assenti o applicati male | Sospendi il caso interessato e verifica i permessi durante il recupero. |
Per testare il comportamento, prepara domande reali e verifica sia i passaggi trovati sia il testo generato. La documentazione di Microsoft Foundry distingue, tra le altre, le valutazioni di retrieval, groundedness e rilevanza: la prima guarda ai contenuti recuperati, la groundedness controlla l’aderenza al contesto e la rilevanza considera la risposta rispetto alla domanda. Un unico punteggio complessivo può nascondere il punto esatto in cui il flusso si rompe.
Una prova utile misura fonti, risposte e casi senza risposta
Un prototipo può sembrare efficace perché risponde bene alle domande facili. Per capire se serve davvero, costruisci un piccolo insieme di quesiti raccolti dal processo scelto, includendo richieste frequenti, domande ambigue e casi in cui i documenti non contengono la risposta.
Per ciascun quesito, annota quale fonte dovrebbe essere recuperata e quali elementi sono necessari nella risposta. Poi verifica separatamente se il sistema trova il passaggio atteso, se la risposta resta fedele a quel passaggio e se affronta la domanda senza omettere informazioni necessarie. Una risposta che inventa una scadenza e una risposta che non menziona un’eccezione sono due errori diversi, anche se entrambe risultano “non corrette”.
La documentazione di Azure Databricks sottolinea l’utilità di un insieme di valutazione rappresentativo, aggiornato e abbastanza vario, oltre al monitoraggio di qualità, costo e latenza. Per una prova aziendale, registra anche quante domande richiedono l’intervento di una persona e se le citazioni portano davvero alla versione corretta del documento.
Se il sistema recupera spesso fonti sbagliate, correggi prima indicizzazione e ricerca; se trova le fonti giuste ma le riassume male, intervieni su istruzioni e generazione. Se non sa quando astenersi, aggiungi al test domande senza risposta documentale e stabilisci quale comportamento è accettabile prima di estendere il servizio.
Una RAG affidabile comincia da una risposta controllabile
La promessa utile per un’impresa non è un assistente che risponde a qualsiasi domanda, ma uno strumento che aiuta a trovare informazioni interne e rende verificabile da dove arrivano. Scegli un processo con fonti identificabili, controlla i permessi e misura retrieval e generazione come parti distinte.
Quando una risposta non ha una fonte adeguata, il sistema dovrebbe dirlo o indirizzare la richiesta a una persona. È una scelta meno spettacolare di una risposta sempre pronta, ma più adatta a costruire fiducia attorno ai documenti da cui dipende il lavoro quotidiano.