RAG in Produzione: 5 Lezioni dal Mio Chatbot AI

Quando ho deciso di implementare un chatbot AI su marcoventurelli.com, l'obiettivo era semplice: un assistente che rispondesse in modo accurato su servizi, contatti, listini e contenuti del sito, senza inventare nulla. Il classico caso d'uso per Retrieval-Augmented Generation.

La teoria sembrava lineare. Prendi i tuoi contenuti, trasformali in embedding vettoriali, li metti in un vector database, e quando arriva una domanda il sistema recupera i frammenti più rilevanti e li passa all'LLM come contesto. In pratica, ogni fase nasconde trappole che non trovi nei tutorial.

Queste sono le 5 lezioni più importanti che ho imparato portando il sistema dalla prototipazione al deploy.

La prima versione del mio sistema usava un chunking meccanico: spezzavo ogni pagina in blocchi da 500 token con overlap di 50. I risultati erano mediocri. Il chatbot recuperava frammenti che contenevano la keyword ma non il contesto necessario per rispondere.

Il problema è che un blocco di 500 token preso a metà di una sezione su un servizio non contiene né il nome del servizio né il prezzo — informazioni che stavano nel paragrafo precedente o in quello successivo.

La soluzione è stata passare a un chunking semantico: ogni blocco corrisponde a un'unità logica di contenuto (un servizio completo, una FAQ con domanda e risposta, una sezione della pagina chi-sono). Ho preferito chunk più grandi e autocontenuti rispetto a tanti piccoli frammenti orfani.

Dopo settimane a ottimizzare embedding, retrieval e ranking, mi sono reso conto che la qualità delle risposte dipendeva per il 60% dal prompt di sistema. Il retrieval può trovare i documenti perfetti, ma se il prompt non dice all'LLM come usarli, il risultato sarà generico o allucinato.

Il prompt del mio chatbot include istruzioni specifiche su diversi aspetti: il tono da usare (professionale ma accessibile), come gestire domande fuori scope (ammettere di non sapere piuttosto che inventare), quando suggerire di contattare direttamente via email, e come citare i servizi con i prezzi corretti dal listino.

Cosa funziona nel prompt di sistema

Le istruzioni più efficaci che ho trovato sono quelle che definiscono cosa il chatbot non deve fare. Dire "non inventare prezzi se non li trovi nel contesto" è più potente di dire "rispondi accuratamente". Definire i confini è più importante che definire il comportamento ideale.

Un altro pattern che ha migliorato sensibilmente la qualità è stato fornire all'LLM un "fallback" strutturato: quando il contesto recuperato non contiene la risposta, il chatbot deve rispondere con una formula specifica che include il contatto email e il numero di telefono. Questo ha eliminato il problema delle risposte vaghe.

L'istinto iniziale è stato impostare il retrieval su top-k=10: recupera 10 documenti e passali tutti al contesto. La logica sembra solida — più contesto fornisci, più informazioni ha l'LLM per rispondere.

Nella pratica, il contrario. Con 10 documenti nel contesto, l'LLM mescolava informazioni da chunk diversi, confondeva servizi simili tra loro, e le risposte diventavano più lunghe ma meno precise. L'LLM cercava di "usare" tutto il contesto fornito, anche le parti irrilevanti.

Ho ottenuto risultati nettamente migliori con top-k=3 combinato con un filtro di soglia sulla similarità. Se nessun documento supera una soglia minima di rilevanza, il sistema restituisce il fallback invece di forzare una risposta con contesto di bassa qualità.

Uno dei problemi più sottovalutati nei sistemi RAG è la valutazione della qualità. Come fai a sapere se il tuo chatbot sta rispondendo bene?

Ho creato un set di 30 domande di test che coprono i casi più comuni: domande sui servizi, sui prezzi, sugli orari, domande generiche, domande fuori scope, e domande ambigue. Per ognuna ho definito la risposta attesa — non parola per parola, ma i concetti chiave che devono essere presenti.

Quello che ho scoperto è che le metriche automatiche (BLEU, ROUGE, cosine similarity con la risposta attesa) catturano solo una parte della qualità. Un chatbot può dare una risposta con alta similarità semantica alla risposta attesa ma con un tono completamente sbagliato, o includere informazioni corrette ma in un ordine confuso.

La revisione manuale periodica resta insostituibile. Ogni settimana controllo un campione di conversazioni reali e cerco pattern di errore. I problemi più frequenti non sono allucinazioni (il sistema di fallback le previene), ma risposte tecnicamente corrette ma poco utili — troppo generiche, troppo lunghe, o che non rispondono alla vera intenzione dell'utente.

L'errore più comune quando si implementa un sistema RAG è trattarlo come un progetto con una data di fine. Costruisci il knowledge base, fai il deploy, e passi ad altro.

La realtà è che il knowledge base ha bisogno di manutenzione continua. Ho aggiornato i listini, aggiunto nuovi servizi, pubblicato un nuovo libro, lanciato un'app iOS. Ogni volta che il sito cambia, il chatbot risponde con informazioni obsolete fino a quando non aggiorno i chunk corrispondenti.

La soluzione che ho adottato è un processo semplice: ogni volta che modifico una pagina del sito, aggiorno anche il chunk corrispondente nel knowledge base e rigenero gli embedding. Non è automatizzato al 100% — ci sono tool che lo fanno, ma per un knowledge base di questa dimensione il controllo manuale sulla qualità dei chunk vale più del tempo risparmiato.

Cosa ho capito sulla manutenzione

Il vero costo di un sistema RAG non è nel setup iniziale. È nel mantenimento nel tempo. Se non hai un processo di aggiornamento, dopo 6 mesi avrai un chatbot che risponde con informazioni vecchie — che è peggio di un chatbot che dice "non lo so".

In sintesi

Implementare RAG in produzione è un problema di ingegneria, non di modelli. Il modello LLM è una commodity — la differenza la fanno il chunking, il prompt di sistema, la strategia di retrieval, la valutazione, e la manutenzione del knowledge base.

Se stai valutando un sistema RAG per la tua azienda, il mio consiglio è di partire dal contenuto: definisci prima cosa deve sapere il chatbot, come devono essere strutturate le informazioni, e chi si occuperà di tenerle aggiornate. La tecnologia viene dopo.

Se vuoi approfondire l'implementazione di chatbot AI per il business, ne parlo in modo più strutturato nel mio libro.

Chatbot per il Business

Come trasformare l'Intelligenza Artificiale in valore per la tua azienda. Strategie concrete per implementare chatbot AI, automatizzare processi e generare nuove opportunità.

Acquista su Amazon