RAG vs fine-tuning per chatbot di dominio: come scegliere

Quale problema risolviamo con un chatbot specifico per il dominio?

Un chatbot specifico per il dominio risponde a domande usando la conoscenza interna della tua organizzazione, non fatti generici presi da Internet. Pensa a politiche HR, manuali di prodotto, regole di pricing, playbook di supporto, SOP e guide interne su come fare le cose.

La maggior parte dei team non cerca di “insegnare tutto” a un modello. Vogliono risposte rapide e coerenti a domande di ogni giorno come “Qual è la nostra regola di rimborso per i piani annuali?” o “Quale modulo uso per una richiesta a un fornitore?” senza dover scavare tra cartelle e PDF.

La difficoltà principale è la fiducia. Un modello generale può sembrare sicuro anche quando sbaglia. Se la tua policy dice “7 giorni lavorativi” e il modello risponde “10 giorni di calendario”, la risposta può essere ben formulata ma causare danni reali: approvazioni errate, risposte sbagliate a clienti o problemi di conformità.

La frequenza con cui cambiano i documenti è tanto importante quanto la precisione. Se i documenti vengono aggiornati settimanalmente, il chatbot deve riflettere il nuovo contenuto rapidamente e in modo affidabile, altrimenti diventa una fonte di indicazioni obsolete. Se i documenti cambiano ogni anno, puoi permetterti un ciclo di aggiornamento più lento, ma il chatbot deve comunque dire la verità perché le persone si fidano di ciò che dice.

Confrontando RAG e fine-tuning per chatbot di dominio, l’obiettivo è pratico: risposte utili radicate nei tuoi documenti, con fonti chiare o citazioni, e una risposta sicura quando il chatbot non è sicuro.

Una buona dichiarazione del problema copre cinque aspetti: quali documenti il bot può usare (e quali deve evitare), i tipi di domanda più comuni, com’è una “buona” risposta (corretta, breve, include una fonte), com’è una “cattiva” risposta (congetture sicure, regole obsolete) e cosa fare quando manca l’evidenza (fare una domanda di chiarimento o dire che non lo sa).

RAG e fine-tuning in parole semplici

RAG e fine-tuning sono due modi diversi per far comportare bene un chatbot in azienda.

Retrieval augmented generation (RAG) è come dare al chatbot un compito a libro aperto. Quando un utente fa una domanda, il sistema cerca nei tuoi documenti (politiche, manuali, ticket, FAQ). Poi passa i frammenti più rilevanti al modello e gli chiede di rispondere usando quel materiale. Il modello non sta memorizzando i tuoi documenti: li legge al momento della risposta.

Il fine-tuning è come allenare il modello con esempi finché non assimila il comportamento desiderato. Fornisci molte coppie input-output (domande e risposte ideali, tono, formato, regole da non dire). I pesi del modello cambiano, quindi risponde in modo più coerente anche quando non viene fornito un documento.

Un modello mentale semplice:

• RAG mantiene la conoscenza aggiornata estraendo dai documenti correnti.
• Il fine-tuning rende il comportamento coerente: stile, regole e pattern decisionali.

Entrambi possono fallire, ma in modo diverso.

Con RAG, il punto debole è il retrieval. Se la ricerca prende la pagina sbagliata, un testo obsoleto o troppo poco contesto, il modello può comunque produrre una risposta sicura, ma basata su una prova errata.

Con il fine-tuning, il punto debole è la sovrageneralizzazione. Il modello può imparare pattern dagli esempi e applicarli quando invece dovrebbe fare una domanda chiarificatrice o dire “non lo so”. Il fine-tuning inoltre non tiene il passo con cambi frequenti dei documenti a meno che non lo riaddestri costantemente.

Un esempio concreto: se la tua policy di viaggio cambia da “approvazione del manager oltre $500” a “oltre $300”, RAG può rispondere correttamente lo stesso giorno se recupera la policy aggiornata. Un modello fine-tuned potrebbe continuare a ripetere il numero vecchio a meno di essere riaddestrato e verificato.

Cosa si adatta meglio ai documenti aziendali che cambiano?

Se i documenti cambiano settimanalmente (o quotidianamente), il retrieval di solito rispecchia la realtà meglio dell’addestramento. Con RAG per documenti aziendali, mantieni il modello pressoché invariato e aggiorni invece il knowledge base. Questo permette al chatbot di riflettere nuove politiche, prezzi o note di prodotto non appena il contenuto sorgente cambia, senza aspettare un nuovo ciclo di training.

Il fine-tuning può funzionare quando la “verità” è stabile: un tono coerente, un insieme fisso di regole di prodotto o un compito ristretto. Ma se fai fine-tuning su contenuti che si spostano continuamente, rischi di insegnare risposte di ieri. Riaddestrare abbastanza spesso per stare al passo diventa costoso e facile da sbagliare.

Governance: aggiornamenti e responsabilità

Una domanda pratica è chi è responsabile degli aggiornamenti dei contenuti.

Con RAG, team non tecnici possono pubblicare o sostituire un documento e il bot può usarlo dopo la reindicizzazione. Molti team aggiungono un passaggio di approvazione così solo certi ruoli possono pubblicare le modifiche.

Con il fine-tuning, gli aggiornamenti di solito richiedono un workflow ML. Questo spesso significa ticket, attese e aggiornamenti meno frequenti.

Compliance e audit

Quando le persone chiedono “perché il bot ha detto questo?”, RAG ha un chiaro vantaggio: può citare i passaggi esatti usati. Questo aiuta con audit interni, revisioni del supporto clienti e argomenti regolamentati.

Il fine-tuning incorpora l’informazione nei pesi, quindi è più difficile mostrare una fonte specifica per una frase specifica.

Anche costi e sforzi hanno dinamiche diverse:

• RAG richiede lavoro iniziale per raccogliere i documenti, suddividerli in chunk, indicizzarli e mantenere l’ingestione affidabile.
• Il fine-tuning richiede lavoro iniziale per preparare i dati di training e valutarli, oltre a training ripetuti quando la conoscenza cambia.
• Quando gli aggiornamenti dei contenuti sono frequenti, RAG solitamente ha un costo continuativo inferiore.

Esempio: un chatbot HR che risponde da policy che cambiano ogni trimestre. Con RAG, HR può sostituire il PDF della policy e il bot comincia a usare il nuovo testo rapidamente, mostrando comunque il paragrafo su cui si è basato. AppMaster può aiutare a costruire il portale admin per caricare documenti approvati e registrare quali fonti sono state usate, senza scrivere l’intera applicazione da zero.

Quando usare RAG, quando il fine-tuning e quando combinarli

Se il tuo obiettivo è avere risposte affidabili che corrispondano a ciò che dicono i documenti aziendali oggi, inizia con retrieval augmented generation per documenti aziendali. Estrae i passaggi rilevanti al momento della domanda, così il bot può indicare la policy, la specifica o la SOP esatta che supporta la risposta.

RAG è il default migliore quando i contenuti cambiano spesso, quando devi mostrare da dove viene una risposta o quando documenti diversi sono gestiti da team diversi. Se HR aggiorna la policy con cadenza mensile, vuoi che il chatbot usi automaticamente la versione più recente, non quello che ha imparato settimane fa.

Il fine-tuning ha senso quando i documenti non sono il problema principale. È ideale per comportamenti stabili: una voce coerente, formattazione rigida (ad esempio rispondere sempre con un template), un migliore instradamento delle intenzioni o regole di rifiuto affidabili. Pensalo come insegnare all’assistente come comportarsi, non quale sia l’ultima versione del manuale.

Combinare entrambi è comune: RAG fornisce i fatti e un piccolo fine-tuning (o istruzioni di sistema forti) mantiene l’assistente coerente e prudente. Questo si adatta anche a team prodotto che integrano il chatbot in un’app, dove UX e tono devono restare gli stessi anche se la conoscenza cambia.

Segnali rapidi per scegliere:

• Scegli RAG quando le risposte devono restare aggiornate, citare il testo esatto o includere fonti dai documenti più recenti.
• Scegli il fine-tuning quando ti serve uno stile fisso, formati di output ripetuti o regole più rigide di fare/non-fare.
• Combina quando vuoi risposte ancorate ai documenti più tono coerente e comportamenti di rifiuto più sicuri.
• Ripensa il piano se stai continuamente riaddestrando per stare al passo con nuovi documenti o se il retrieval fallisce spesso perché i contenuti sono disordinati o male chunkati.

Un modo semplice per individuare l’approccio sbagliato è il dolore di manutenzione. Se ogni aggiornamento di policy scatena una richiesta di retraining del modello, stai usando il fine-tuning per risolvere un problema di freschezza dei documenti. Se RAG restituisce la pagina corretta ma il bot risponde comunque in modo rischioso, probabilmente servono più guardrail (a volte il fine-tuning aiuta).

Se costruisci questo in uno strumento reale (ad esempio in AppMaster), un approccio pratico è partire da RAG, poi aggiungere fine-tuning solo per comportamenti che puoi testare e misurare chiaramente.

Passo dopo passo: impostare una baseline affidabile (prima della scelta del modello)

La maggior parte dei fallimenti dei chatbot deriva da documenti disordinati e obiettivi poco chiari, non dal modello.

Inizia con un inventario dei documenti: cosa hai, dove si trova e chi può approvare le modifiche. Registra tipo e formato (PDF, wiki, ticket, fogli di calcolo), il proprietario e la fonte di verità, la frequenza di aggiornamento, le regole di accesso e dove tendono ad apparire duplicati.

Poi definisci il lavoro del chatbot in termini semplici. Scegli 20–50 domande reali che deve saper rispondere bene (per esempio: “Come richiedo un rimborso?” o “Qual è l’escalation on-call?”). Definisci anche cosa deve rifiutare, come consulenze legali, decisioni HR o qualsiasi cosa fuori dai documenti approvati. Un rifiuto è un successo se previene una risposta sbagliata.

Poi pulisci e forma i documenti in modo che le risposte siano facili da ancorare. Rimuovi duplicati, conserva una versione corrente e etichetta chiaramente le versioni più vecchie. Aggiungi titoli chiari, date e intestazioni di sezione così il chatbot può indicare la parte precisa che supporta la risposta. Se una policy cambia spesso, tieni una singola pagina aggiornata invece di molte copie.

Infine, stabilisci un contratto di output. Richiedi una risposta breve, una citazione alla sezione sorgente usata e un’azione successiva quando serve (per esempio: “Apri un ticket con Finance”). Se lo integri in uno strumento interno con AppMaster, aiuta mantenere l’interfaccia coerente: risposta prima, poi la citazione, poi il pulsante di azione. Questa struttura rende i problemi evidenti durante i test e riduce le risposte confidentemente sbagliate.

Come valutare la qualità senza indovinare

Inizia con un piccolo test offline. Raccogli 30–100 domande reali che le persone già pongono in ticket, email e thread di chat. Mantieni la formulazione originale, includi alcune domande vaghe e alcune facilmente equivocabili. Questo ti dà un modo stabile per confrontare RAG e fine-tuning per chatbot di dominio.

Per ogni domanda, scrivi una breve risposta attesa in linguaggio semplice, più la sezione esatta del documento che la supporta. Se al chatbot è permesso dire “Non lo so”, includi casi in cui quello è il comportamento corretto.

Valuta le risposte con poche dimensioni semplici

Tieni la scheda di valutazione abbastanza piccola da usarla davvero. Questi quattro controlli coprono la maggior parte dei fallimenti di business:

• Correttezza: è fattualmente giusta, senza dettagli inventati?
• Completezza: copre i punti chiave necessari per agire?
• Qualità della citazione: le citazioni o i riferimenti supportano davvero l’affermazione?
• Chiarezza: è leggibile e specifica, o vaga e prolissa?

Se usi retrieval aggiungi un controllo: ha preso il chunk giusto, e la risposta ha effettivamente usato quel chunk invece di ignorarlo?

Monitora i cambiamenti nel tempo, non impressioni isolate

Rendi la qualità un’abitudine:

• Esegui lo stesso set di test dopo ogni modifica a prompt, retrieval o modello.
• Tieni una singola scheda di valutazione e registra i totali per data.
• Tagga i fallimenti (mancanza di dettaglio di policy, numero sbagliato, documento obsoleto, formulazione poco chiara).
• Rivedi prima le peggiori 5 domande e risolvi la causa principale.

Esempio: se un chatbot HR risponde correttamente su un beneficio ma cita un PDF obsoleto, il tuo punteggio deve scendere. Questo ti dice cosa correggere: freschezza del documento, chunking o filtri di retrieval, non lo stile di scrittura del modello.

Se lo costruisci in un’app (per esempio in AppMaster), archivia domande di test e risultati insieme alle release così puoi individuare regressioni presto.

Prevenire risposte sicure ma sbagliate (hallucinations) nella pratica

Le risposte sicure ma sbagliate vengono di solito da tre luoghi: il modello non ha avuto il giusto contesto, ha avuto il contesto sbagliato o lo hai inavvertitamente incoraggiato a indovinare. Il rischio esiste sia in RAG sia nel fine-tuning, ma si manifesta in modo diverso. RAG fallisce quando il retrieval è debole; il fine-tuning fallisce quando il modello impara pattern e colma i vuoti con testo plausibile.

La soluzione più efficace è richiedere evidenza. Tratta ogni risposta come un piccolo report: se il testo di supporto non è nelle sorgenti fornite, il bot non dovrebbe affermarlo. In pratica, l’app dovrebbe passare gli snippet recuperati nel prompt e richiedere al modello di usare solo quegli snippet.

Aggiungi regole chiare di rifiuto e escalation così il bot ha un fallback sicuro. Un buon chatbot non è quello che risponde a tutto; è quello che sa quando non può rispondere.

• Se le fonti non menzionano l’argomento, dire “Non ho abbastanza informazioni nei documenti per rispondere.”
• Se la domanda è poco chiara, fare una domanda chiarificatrice.
• Se la risposta incide su soldi, accessi o conformità, instradare a un umano o aprire un ticket.
• Se i documenti sono in conflitto, evidenziare il conflitto e chiedere quale policy o versione si applica.

I vincoli riducono anche le congetture e rendono gli errori più facili da individuare. Per risposte in stile policy, richiedi nome del documento e data, e cita 1–2 righe chiave che giustifichino la risposta.

Esempio: un dipendente chiede “Qual è il limite di rimborso più recente per i viaggi?” Se lo snippet recuperato è dell’anno scorso, il bot dovrebbe mostrare quella data e rifiutarsi di dichiarare un “limite più recente” senza una fonte più aggiornata.

Se lo implementi in AppMaster, rendi le regole parte del Business Process: passo di retrieval, controllo delle evidenze, poi o risposta con citazioni o escalation. In questo modo il comportamento di sicurezza è coerente, non opzionale.

Errori comuni e trappole da evitare

La maggior parte dei fallimenti dei chatbot non dipende dal modello. Derivano da documenti disordinati, retrieval debole o scelte di training che spingono il sistema a sembrare sicuro quando dovrebbe rallentare. L’affidabilità è prima di tutto un problema di dati e processi.

Un problema comune in RAG è il chunking che ignora il significato. Se i chunk sono troppo piccoli perdi contesto (chi, quando, eccezioni). Se sono troppo grandi, il retrieval estrae testi non correlati e la risposta diventa un mix di dettagli a metà. Un test semplice: leggendo un chunk da solo, ha ancora senso e contiene una regola completa?

Un’altra trappola frequente è il mescolamento di versioni. I team indicizzano policy di mesi diversi, poi il bot recupera passaggi conflittuali e ne sceglie uno a caso. Considera la freschezza del documento come una feature: etichetta le fonti con date, proprietari e stato (bozza vs approvato), e rimuovi o declassa i contenuti obsoleti.

L’errore più dannoso è forzare una risposta quando non è stato recuperato nulla di rilevante. Se il retrieval è vuoto o a bassa confidenza, il bot dovrebbe dire che non trova supporto e fare una domanda chiarificatrice o instradare a un umano. Altrimenti crei nonsense sicuri.

Il fine-tuning ha il suo rischio: sovra-addestrarsi su un set ristretto di Q&A. Il bot inizia a ripetere le tue frasi di training, diventa fragile e può perdere capacità di ragionamento di base o abilità linguistiche generali.

Segnali di allarme durante i test:

• Le risposte non citano testo sorgente o citano la sezione sbagliata.
• La stessa domanda ottiene risposte diverse a seconda della formulazione.
• Domande di policy ottengono risposte definitive quando i documenti tacciono.
• Dopo il fine-tuning, il bot fatica con domande semplici di uso quotidiano.

Esempio: se la tua policy di viaggio è cambiata la scorsa settimana ma entrambe le versioni sono indicizzate, il bot può approvare con sicurezza una spesa che ora non è più consentita. Non è un problema del modello; è un problema di controllo dei contenuti.

Checklist rapida prima del rilascio

Prima di lanciare un chatbot di dominio agli utenti reali, trattalo come qualsiasi altro strumento aziendale: deve essere prevedibile, testabile e sicuro quando non è sicuro.

Usa questa checklist come gate finale:

• Ogni risposta in stile policy è ancorata. Per affermazioni tipo “Puoi scorporare questa spesa” o “L’SLA è 99.9%”, il bot dovrebbe mostrare da dove l’ha presa (nome del documento + intestazione della sezione, o un estratto). Se non può indicare una fonte, non dovrebbe presentare l’affermazione come fatto.
• Fa domande quando la richiesta è ambigua. Se la richiesta dell’utente può significare due cose diverse, chiede una domanda chiarificatrice breve invece di indovinare.
• Sa dire “Non lo so” in modo pulito. Quando il retrieval ritorna testi deboli o nulla, rifiuta cortesemente, spiega cosa manca e suggerisce cosa fornire (documento, nome della policy, data, team).
• Gli aggiornamenti ai documenti cambiano le risposte rapidamente. Modifica una frase in un documento chiave e verifica che la risposta del bot cambi dopo la reindicizzazione. Se continua a ripetere la vecchia risposta, la pipeline di aggiornamento non è affidabile.
• Puoi rivedere i fallimenti. Registra la domanda dell’utente, gli snippet recuperati, la risposta finale e se gli utenti hanno cliccato “utile/non utile”. Questo rende il lavoro di qualità possibile senza indovinare.

Un test concreto: scegli 20 domande reali da ticket o chat interne, incluse quelle con eccezioni. Eseguile prima del lancio, poi ripetile dopo aver aggiornato una policy. Se il bot non riesce a ancorare le risposte, fare domande chiarificatrici e rifiutare quando mancano le fonti, non è pronto per la produzione.

Se trasformi il bot in un’app reale (per esempio, un portale interno), rendi le fonti facili da vedere e mantieni un pulsante “segnala un problema” vicino a ogni risposta.

Scenario di esempio: un chatbot per documenti interni aggiornati frequentemente

Il tuo team HR ha policy e documenti di onboarding che cambiano ogni mese: regole PTO, limiti di rimborso, date di iscrizione ai benefit e passaggi di onboarding. Le persone continuano a fare le stesse domande in chat, e le risposte devono corrispondere alla versione più recente dei documenti, non a ciò che era vero lo scorso trimestre.

Opzione A: solo RAG, ottimizzato per la freschezza

Con una configurazione RAG, il bot cerca prima nella knowledge base HR corrente e poi risponde usando solo ciò che ha recuperato. L’importante è rendere “mostra il tuo lavoro” il comportamento predefinito.

Un flusso semplice che funziona di solito:

• Indicizza i documenti HR su una pianificazione (o ad ogni aggiornamento approvato) e conserva titolo documento, sezione e data di ultimo aggiornamento.
• Rispondi con citazioni brevi (doc + sezione) e una nota “ultimo aggiornamento” quando rilevante.
• Aggiungi regole di rifiuto: se non viene recuperato nulla di rilevante, il bot dice che non lo sa e suggerisce chi contattare.
• Instrada argomenti sensibili (licenziamento, controversie legali) a un umano per default.

Questo rimane accurato man mano che i documenti cambiano perché non stai incorporando testo vecchio nel modello.

Opzione B: light fine-tune per il formato, sempre ancorato a RAG

Se vuoi tono coerente e risposte strutturate (ad esempio: “Idoneità”, “Passaggi”, “Eccezioni”, “Escalation a HR”), puoi fare un leggero fine-tuning su un piccolo set di risposte approvate. Il bot continua a usare RAG per i fatti.

La regola rimane ferma: il fine-tuning insegna come rispondere, non quale sia la policy.

Dopo 2–4 settimane, il successo si vede in meno escalation HR per domande di base, maggiore accuratezza nei controlli a campione e meno risposte sicure e sbagliate. Puoi misurarlo tracciando la copertura delle citazioni (risposte che includono fonti), la frequenza di rifiuti per mancanza di info e un audit settimanale di campioni da parte di HR.

I team spesso costruiscono questo come strumento interno così HR può aggiornare contenuti, rivedere risposte e aggiustare regole senza aspettare l’ingegneria. AppMaster è una delle opzioni per costruire quell’app completa (backend, web app e mobile) con ruoli e workflow admin.

Prossimi passi: pilota e trasformare il chatbot in un prodotto reale

Tratta il chatbot come un piccolo prodotto. Parti con un team (per esempio support clienti), un insieme di documenti (l’ultimo playbook e le politiche di supporto) e un chiaro ciclo di feedback. Questo mantiene lo scope limitato e rende i problemi di qualità evidenti.

Un piano pilota misurabile:

• Scegli 30–50 domande reali dai log di chat o dai ticket del team.
• Definisci “buono”: risposta corretta, cita il documento giusto e dice “Non lo so” quando serve.
• Esegui un pilota di 2–3 settimane con un piccolo gruppo e raccogli pollici su/giù più commenti brevi.
• Rivedi i fallimenti due volte a settimana e correggi la causa (documenti mancanti, chunking errato, policy poco chiara, prompt deboli).
• Espandi solo dopo aver raggiunto una soglia di qualità di cui ti fidi.

Per passare dal pilota al “reale” servono funzionalità di base attorno al modello. Le persone faranno domande sensibili e devi poter tracciare cosa è successo quando il bot sbaglia.

Costruisci l’essenziale presto: autenticazione e ruoli (chi può accedere a quali set di documenti), logging e audit trail (domanda, snippet recuperati, risposta, feedback utente), una UI admin semplice per gestire sorgenti documentali e vedere i pattern di fallimento, e una via di fallback sicura (handoff a un umano o apertura ticket quando la confidenza è bassa).

Qui entra in gioco una piattaforma no-code come AppMaster (appmaster.io): puoi consegnare l’app attorno al modello—backend, pannello admin e ruoli—mantenendo la logica del chatbot modulare. Questo rende più semplice cambiare approccio in futuro, sia che rimani su retrieval augmented generation per documenti aziendali sia che aggiunga fine-tuning per compiti specifici.

Dopo il pilota, aggiungi un nuovo set di documenti alla volta. Mantieni lo stesso set di valutazione, misura di nuovo e solo allora apri l’accesso ad altri team. Espansione lenta batte confusione veloce e riduce le risposte sicure e sbagliate prima che diventino un problema di fiducia.