Il RAG (Retrieval-Augmented Generation) è la tecnica che permette a un modello AI come Claude o GPT-4o di rispondere alle domande usando i tuoi documenti aziendali specifici — manuali, FAQ, catalogo prodotti, storico clienti — senza che questi dati siano stati inclusi nel training originale del modello. È la base tecnica di qualsiasi assistente AI aziendale davvero utile: senza RAG, il modello risponde solo con ciò che sa in generale; con RAG, risponde con ciò che sa la tua azienda.
Perché i LLM da soli non bastano per un uso aziendale
Un modello come GPT-4o o Claude Sonnet è addestrato su miliardi di testi pubblici, ma non conosce il tuo listino prezzi aggiornato, le tue procedure interne, i contratti con i fornitori o la knowledge base del supporto clienti. Se chiedi a ChatGPT "qual è la politica di reso della nostra azienda?", inventerà una risposta plausibile ma sbagliata — il fenomeno noto come allucinazione. Il RAG risolve questo problema: invece di rispondere da memoria, il modello cerca prima nei tuoi documenti e poi formula la risposta basandosi sulle informazioni trovate.
Il problema dell'allucinazione nei modelli AI non è un bug destinato ad essere risolto con modelli più grandi: è una caratteristica strutturale di come i modelli linguistici generano testo. Un LLM, di fronte a una domanda per cui non ha informazioni specifiche, genera comunque una risposta coerente e plausibile perché è addestrato a farlo. Il RAG cambia l'architettura del sistema in modo che il modello abbia sempre informazioni verificabili su cui basare la risposta — riducendo drasticamente le allucinazioni nei domini specifici aziendali.
Come funziona il RAG: i tre passi fondamentali
Il processo RAG si articola in tre fasi. Fase 1 — Indicizzazione: i tuoi documenti (PDF, Word, pagine web, database) vengono suddivisi in chunk di testo e convertiti in vettori numerici (embedding) che rappresentano il significato semantico di ogni chunk. Questi vettori vengono salvati in un database vettoriale (es. Pinecone, Weaviate, Chroma). Fase 2 — Retrieval: quando arriva una domanda, la domanda stessa viene convertita in un vettore e il sistema cerca nel database i chunk più simili semanticamente (non per parola chiave, ma per significato). Fase 3 — Generation: i chunk trovati vengono passati al modello LLM insieme alla domanda, e il modello genera una risposta basata su queste informazioni contestuali.
Un aspetto fondamentale spesso sottovalutato è la qualità della fase di chunking. Come si dividono i documenti in chunk ha un impatto enorme sulla qualità del retrieval. Chunk troppo piccoli perdono il contesto; chunk troppo grandi includono informazioni irrilevanti che "diluiscono" la risposta del modello. Il chunking ottimale varia per tipo di documento: per una FAQ, ogni coppia domanda-risposta è un chunk ideale; per un manuale tecnico, un'intera sezione con titolo e sottoparagrafi è più utile di singoli paragrafi. Nei sistemi RAG che costruiamo, la strategia di chunking è personalizzata per ogni tipo di documento nel corpus.
Embedding e database vettoriali: cosa sono in pratica
Un embedding è una rappresentazione numerica del significato di un testo: frasi simili semanticamente producono vettori numericamente vicini nello spazio multidimensionale. Questo permette al retrieval di trovare il chunk "La restituzione del prodotto è possibile entro 30 giorni dall'acquisto" anche se la domanda è "posso restituire quello che ho comprato?". I database vettoriali sono ottimizzati per questa ricerca per similarità.
I più usati nei progetti che seguiamo sono Pinecone (cloud-hosted, semplice, ottimo per iniziare), Qdrant (open source, performante, self-hosted), e pgvector (estensione per PostgreSQL, ideale se hai già un DB Postgres nel tuo stack). Per la maggior parte delle PMI, Pinecone è il punto di partenza migliore per la semplicità operativa; per chi ha requisiti di data residency europea o vuole massimizzare il controllo sui costi, Qdrant su cloud EU o pgvector su un PostgreSQL esistente sono le alternative preferite.
RAG vs fine-tuning: quale scegliere
Il fine-tuning è l'alternativa al RAG: si addestra ulteriormente il modello su dati specifici dell'azienda. Ma il fine-tuning è costoso (migliaia di euro per un training completo), non si aggiorna automaticamente con nuovi dati, e non è trasparente (il modello "dimentica" le fonti usate). Il RAG invece è aggiornabile in tempo reale (aggiungi un documento e il sistema lo usa subito), trasparente (può citare la fonte del chunk usato), e molto meno costoso da mantenere. Per il 95% delle use case aziendali, il RAG è la scelta giusta.
L'unico scenario dove il fine-tuning ha senso per una PMI è quando si vuole modificare il comportamento base del modello (es. farlo rispondere sempre in un certo stile o formato specifico del brand) piuttosto che dargli accesso a dati specifici. In questo caso, il fine-tuning e il RAG non sono alternativi ma complementari: si fa fine-tuning per il comportamento e si usa RAG per i dati. Ma questa combinazione richiede risorse tecniche avanzate e un volume di use case che raramente si giustifica per una PMI.
Tipi di documenti adatti al RAG
I documenti più adatti al RAG sono: FAQ aziendali (testo strutturato, risposte chiare), manuali tecnici e di prodotto, cataloghi con descrizioni e specifiche, procedure operative standard, storico di ticket di supporto (domande + risposte), articoli del blog aziendale, schede prodotto e-commerce, contratti e policy (per uso interno). I documenti meno adatti sono: fogli Excel con dati non contestualizzati, scansioni di documenti non OCR, database relazionali complessi (meglio una pipeline dedicata), e contenuti troppo brevi o fragmentati.
Un pattern che emerge nei progetti RAG è l'importanza della qualità dei documenti sorgente. Un sistema RAG costruito su documenti incompleti, obsoleti o mal strutturati produrrà risposte di qualità mediocre indipendentemente dalla qualità del modello AI e del database vettoriale. Prima di avviare qualsiasi progetto RAG, proponiamo sempre un audit della knowledge base: quanti documenti ci sono, come sono aggiornati, come sono strutturati, chi li mantiene. Spesso questa fase rivela gap importanti che vale la pena risolvere prima di automatizzare.
Quanto costa costruire un sistema RAG
Un sistema RAG di base per una PMI — con caricamento di documenti, database vettoriale e interfaccia chatbot — può costare tra 2.000 e 8.000€ di sviluppo, a seconda della complessità dei documenti e del grado di integrazione con i sistemi esistenti. I costi operativi mensili includono i token API del modello (LLM), il database vettoriale (da gratuito per volumi bassi a 70-200€/mese per volumi enterprise) e l'hosting dell'applicazione. Nella nostra AI agency costruiamo sistemi RAG custom per PMI di ogni settore, con deployment su cloud o on-premise.
Un breakdown più dettagliato dei costi: indicizzazione iniziale dei documenti (una tantum, dipende dal volume, tipicamente 500-2.000€ per corpora da 100-500 documenti), interfaccia chatbot (da 1.000€ per un widget semplice a 5.000€+ per interfacce avanzate con gestione utenti e analytics), integrazione con sistemi esterni (variabile, da 1.000€ a 8.000€ a seconda dei sistemi coinvolti). I costi operativi mensili: database vettoriale Pinecone Starter (gratuito fino a 100k vettori, poi da 70$/mese), API LLM (variabile, mediamente 50-200€/mese per una PMI con uso moderato).
Casi d'uso RAG più comuni nelle PMI italiane
I casi d'uso che abbiamo implementato più frequentemente: assistente FAQ per il sito web (risponde a domande dei clienti usando il catalogo e le policy), supporto tecnico interno (risponde ai dipendenti usando i manuali), onboarding assistito per nuovi dipendenti (risponde alle domande sulle procedure usando l'handbook aziendale), ricerca intelligente nel catalogo prodotti per l'e-commerce.
Un caso che ha prodotto ROI eccezionale: un'azienda di distribuzione con un catalogo da 8.000 prodotti e un team di 5 agenti commerciali. Prima del RAG, ogni agente dedicava 2-3 ore al giorno a rispondere a domande tecniche dei clienti (compatibilità prodotti, disponibilità, specifiche tecniche). Con il sistema RAG sul catalogo completo, l'agente fa la domanda al chatbot e ottiene la risposta con riferimento alla scheda tecnica in 5-10 secondi. Risparmio per agente: 1,5-2 ore/giorno. Moltiplicato per 5 agenti e 22 giorni lavorativi al mese: oltre 200 ore/mese di produttività recuperata. Contattaci per capire quale si adatta meglio alla tua realtà.
