RAG: cos’è e come creare una chatbot AI che risponde sui documenti aziendali

Un modello AI generico non conosce automaticamente procedure interne, manuali aggiornati, listini o policy della tua organizzazione. Caricare un PDF in una chat può essere utile per un’analisi occasionale, ma non costruisce da solo un sistema condiviso, aggiornabile e controllato.

Il RAG affronta questo problema recuperando, prima della risposta, i passaggi pertinenti da una knowledge base e fornendoli al modello come contesto. Il risultato dipende però soprattutto dalla qualità dei documenti, dal recupero delle fonti e dall’architettura dei permessi.

RAG: cos’è, come funziona e quando serve davvero

RAG significa Retrieval-Augmented Generation, cioè generazione aumentata dal recupero di informazioni. Il concetto è stato formalizzato nel lavoro di ricerca Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks del 2020.

Un sistema RAG non “insegna” stabilmente i documenti al modello. Quando riceve una domanda, cerca le fonti rilevanti nella knowledge base, le aggiunge al contesto della richiesta e genera la risposta. Per aggiornare un’informazione si modifica o sostituisce il documento indicizzato, senza dover riaddestrare il modello.

È utile quando le informazioni sono private, cambiano nel tempo, sono numerose o devono essere consultate da utenti con autorizzazioni differenti. Esempi concreti sono il supporto clienti su resi e garanzie, l’assistenza IT interna, procedure HR, documentazione API, cataloghi prodotto, changelog e materiali di onboarding.

Dalla domanda alla risposta con fonti

1. I documenti vengono importati ed estratti in testo.
2. Il testo viene diviso in porzioni coerenti, chiamate chunk.
3. I chunk vengono indicizzati, spesso tramite embedding: rappresentazioni numeriche utili alla ricerca semantica.
4. L’utente pone una domanda.
5. Il sistema recupera i passaggi più pertinenti e può applicare filtri, per esempio su lingua, versione o categoria.
6. Domanda e fonti recuperate vengono inviate al modello linguistico.
7. Il modello genera la risposta; l’applicazione può mostrare documento, sezione, pagina o link di provenienza quando questi dati sono disponibili.

Se un utente chiede i termini di rimborso, il sistema dovrebbe recuperare il paragrafo della policy in vigore, sintetizzarlo in modo fedele e rendere verificabile la fonte. Se non trova una base documentale sufficiente, dovrebbe dichiararlo anziché completare la risposta con informazioni non presenti nei documenti.

Chat con file, contesto lungo, RAG e fine-tuning

 
RAG e fine-tuning possono convivere: il RAG porta conoscenza aggiornata nel contesto, mentre il fine-tuning può contribuire a rendere più costanti tono, struttura o comportamento dell’output.

Preparare i documenti: fonti, chunk, metadati e versioni

Per un MVP scegli un solo processo, documenti con un proprietario identificabile, una versione valida e un set di domande reali con cui testarli. FAQ, manuali, procedure operative, policy, documentazione tecnica, schede prodotto e changelog sono candidati adatti perché hanno un obiettivo consultabile e, idealmente, una data di validità.

Un PDF scansionato male, un documento a colonne, una tabella complessa o note a piè di pagina estratte nell’ordine sbagliato possono produrre testo incompleto o confuso. Il RAG non corregge automaticamente un’estrazione errata: controlla sempre un campione del testo prima dell’indicizzazione.

Vanno inoltre gestiti documenti obsoleti, duplicati e regole in conflitto. Se una policy del 2024 e una del 2026 restano entrambe ricercabili senza un criterio di versione, la chatbot può citare una regola superata. Ogni fonte dovrebbe quindi avere un proprietario e un processo di aggiornamento, archiviazione o rimozione.

Dividere un documento in chunk consente di cercare un passaggio specifico invece di inviare ogni volta l’intero file al modello. Le divisioni devono rispettare il significato: una FAQ dovrebbe mantenere insieme domanda e risposta; un manuale dovrebbe conservare titolo e gerarchia della sezione; una policy dovrebbe preservare articolo, paragrafo e data di efficacia.

Chunk troppo grandi mescolano temi diversi e aumentano il contesto inviato al modello. Chunk troppo piccoli possono separare condizioni, eccezioni e riferimenti indispensabili. Non esiste una dimensione universale: controlla visivamente i segmenti prodotti su documenti reali.

Se la piattaforma lo consente, conserva per ogni documento o segmento almeno titolo, origine, pagina o sezione, versione, data di validità, lingua, categoria, proprietario e classificazione della riservatezza. Queste informazioni aiutano sia le citazioni sia la selezione delle fonti corrette.

La ricerca vettoriale è utile per domande formulate liberamente e con parole diverse da quelle presenti nei documenti. Per codici prodotto, sigle, numeri di versione o riferimenti contrattuali può essere utile valutare una ricerca ibrida, che combina ricerca semantica e keyword. Non è un requisito automatico: va verificata sul corpus e sulle query effettive.

Quale percorso scegliere

Dify è una piattaforma applicativa con funzioni integrate per knowledge base e retrieval. Flowise e n8n sono invece strumenti di costruzione e orchestrazione di flussi: possono essere impiegati per un RAG, ma richiedono di configurare esplicitamente i componenti necessari, come loader, splitter, embedding e vector store.

Per validare un caso d’uso ristretto, una piattaforma no-code o low-code riduce il lavoro iniziale. Per integrazioni complesse, filtri avanzati, multitenancy o requisiti specifici di deployment può diventare necessario uno stack gestito o personalizzato. In entrambi i casi, considera i costi di estrazione o OCR, embedding, storage, query, token, reranking, hosting, log, backup, re-indicizzazione e revisione umana delle fonti.

Prototipo pratico: una chatbot RAG con Dify

Questa procedura serve a validare il comportamento di un MVP. Interfaccia, nomi delle opzioni e modelli disponibili possono cambiare tra versioni e piani di Dify: verifica le impostazioni nella documentazione sul retrieval di Dify. Usa esclusivamente dati fittizi, pubblici o autorizzati.

1. Prepara un dataset e le domande di test

Raccogli da 10 a 20 documenti relativi a un solo dominio, per esempio il supporto e-commerce: FAQ su spedizioni e resi, manuale di assistenza, policy di rimborso, listino versionato e changelog.

Prepara anche 20-30 domande reali. Inserisci casi che mettano alla prova il sistema: una policy superata, documenti con regole incoerenti, una scansione difficile, un codice prodotto da cercare esattamente e una domanda senza risposta nei file. Per ogni domanda annota quale documento dovrebbe essere recuperato.

2. Configura il modello e crea la knowledge base

In Dify configura prima un provider di modelli e le relative credenziali, quindi seleziona un modello chat disponibile nel tuo spazio di lavoro. Crea una knowledge base e importa i file di prova. Al termine dell’importazione, esamina l’anteprima del testo estratto: cerca pagine mancanti, titoli confusi, righe di tabella spezzate e testo fuori ordine. Correggi o escludi le fonti non leggibili.

Nella configurazione dell’indicizzazione scegli un metodo di segmentazione compatibile con i file e verifica i chunk generati. Mantieni unite le coppie domanda-risposta delle FAQ, i titoli con il contenuto successivo e le righe delle tabelle quando rappresentano una relazione necessaria. Se l’istanza consente di impostare modalità di retrieval, numero di risultati, soglia di rilevanza o reranking, trattali come parametri da testare sulle domande preparate, non come valori validi per ogni archivio.

3. Crea la chatflow e collega il nodo di retrieval

Crea un’applicazione basata su chatflow. Aggiungi il nodo Knowledge Retrieval, seleziona la knowledge base creata e passa l’output del recupero al nodo LLM che genera la risposta. Nelle istruzioni del modello inserisci regole semplici e verificabili:

• rispondi usando le fonti recuperate;
• non presentare come certa un’informazione assente dalle fonti;
• quando i riferimenti sono disponibili, indica documento e sezione o pagina;
• se le fonti non bastano, chiedi chiarimenti o dichiara di non poter rispondere.

Abilita nell’app le opzioni di citazione o attribuzione delle fonti, se presenti nella versione in uso, e verifica nell’anteprima della chat che il riferimento visualizzato corrisponda effettivamente al passaggio recuperato. Una citazione non rende corretta una risposta: rende possibile controllarla.

Le istruzioni del modello devono inoltre chiarire che il testo contenuto nei documenti è materiale da consultare, non istruzioni da eseguire. Un file potrebbe contenere frasi manipolative, per esempio richieste di ignorare regole precedenti o mostrare dati riservati.

4. Testa il flusso prima di pubblicarlo

Usa il pannello di anteprima della chatflow e sottoponi una alla volta le domande preparate. Per ogni test registra sia il comportamento del retrieval sia quello della risposta:

 
Se il documento corretto non compare tra i primi risultati, il problema è nel retrieval, nei documenti o nella loro segmentazione. Se invece la fonte è corretta ma la risposta la interpreta male, intervieni sulle istruzioni, sul modello o sulla quantità di contesto inviata. Modifica un parametro per volta e ripeti gli stessi test.

Permessi, privacy e sicurezza

I metadati descrivono i documenti e possono essere usati come filtri, ma non costituiscono da soli un controllo di accesso. Per contenuti riservati, l’autorizzazione deve essere applicata e verificata dall’architettura dell’applicazione o dalla piattaforma prima che un documento venga restituito al modello. Non basta ordinare al modello di non divulgare una fonte: un utente non autorizzato non dovrebbe poterla recuperare né riceverla nel contesto.

Un MVP Dify non va quindi considerato automaticamente idoneo a documenti HR, contratti, ticket personali o basi con ruoli differenziati. Prima di usare dati personali o riservati, verifica con il team competente quali dati vengono inviati a provider e servizi collegati, finalità del trattamento, minimizzazione, tempi di conservazione, regione, cancellazione, log e backup. I principi del GDPR includono, tra gli altri, limitazione della finalità, minimizzazione, esattezza, limitazione della conservazione e sicurezza del trattamento.

Le fonti recuperate sono input non fidati. La prompt injection indiretta può essere presente nei documenti e il RAG non la elimina. Limita le azioni eseguibili dalla chatbot, separa dati e istruzioni, valida input e output lato server e conserva log adeguati al rischio e alle policy applicabili. OWASP include la prompt injection tra i principali rischi delle applicazioni basate su modelli linguistici.

Il passo successivo

Pubblica il prototipo solo per un caso d’uso ristretto e a basso rischio, come FAQ, manuali di prodotto o procedure interne non riservate. Misura quante domande recuperano la fonte corretta, quante risposte richiedono un’escalation e quali documenti mancano. In seguito potrai estendere corpus, utenti e integrazioni sulla base di problemi osservati, non di supposizioni.

Per chi vuole portare funzionalità AI in un sito, può essere utile approfondire anche gli strumenti e i plugin dedicati all’AI per WordPress. L’integrazione sul sito viene dopo aver reso affidabile la knowledge base che alimenta la chat.

Fonti

• Lewis et al. (2020), Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Dify Docs, Knowledge Retrieval
• Microsoft Learn, valutazione dei sistemi RAG
• Qdrant Docs, Hybrid Search
• OWASP GenAI, LLM01: Prompt Injection
• Commissione europea, principi del GDPR