> RAG: come trasformare
i tuoi documenti aziendali
in un assistente AI
Cos'è una pipeline RAG, come funziona nel dettaglio, e perché il 70% delle implementazioni fallisce ancora prima di andare in produzione. Senza slide, senza acronimi vuoti.
Il caso d'uso che mi viene chiesto più spesso: "voglio che i miei dipendenti possano fare domande ai documenti aziendali in linguaggio naturale". Contratto, manuale operativo, knowledge base interna, storico dei ticket. Qualsiasi testo. RAG è la risposta tecnica a questo problema, ma la maggior parte delle implementazioni che vedo non funziona come previsto.
Questo articolo ti spiega perché, e come si fa correttamente.
# Cos'è RAG (senza il solito acronimo inutile)
I modelli LLM come GPT-4 o Claude rispondono in base alla conoscenza che hanno appreso durante il training. Non sanno nulla del tuo contratto firmato ieri, del tuo manuale aggiornato la settimana scorsa, delle email dei tuoi clienti.
RAG — Retrieval-Augmented Generation — risolve questo problema. Prima della generazione della risposta, il sistema cerca nei tuoi documenti i pezzi di testo più rilevanti alla domanda. Poi li passa al modello come contesto. Il modello risponde basandosi su quella documentazione specifica, non sulla sua conoscenza generica.
Il risultato: un assistente AI che sa cosa c'è scritto nel contratto con il fornitore, qual è la procedura aziendale per le note spese, o quale bug è stato risolto nella versione 3.2 del software.
# Le tre fasi critiche
1. Preprocessing dei documenti (la fase più sottovalutata)
Il 70% dei fallimenti RAG avviene qui, non nel modello. Un PDF di un contratto scansionato con OCR pessimo, un Word con tabelle annidate male, un HTML con menu di navigazione che inquina il testo — tutti questi problemi producono chunk (frammenti di testo) inutili o rumorosi. Il modello di embedding non può fare miracoli con spazzatura.
Un preprocessing corretto include: pulizia del testo, rimozione di header/footer ripetuti, riconoscimento della struttura semantica (sezioni, paragrafi, tabelle), chunking intelligente che rispetti i confini semantici naturali del documento invece di tagliare ogni N caratteri.
2. Embedding e vector store
Gli embedding trasformano il testo in vettori numerici che catturano il significato semantico. Due frasi con lo stesso significato ma parole diverse avranno vettori simili. Il vector store (Pinecone, Chroma, pgvector, Weaviate, Qdrant) permette di cercare per similarità semantica invece che per keyword.
Per la maggior parte dei casi aziendali italiani, pgvector su PostgreSQL è la scelta più sana: nessun servizio esterno aggiuntivo, query SQL standard, facile da backuppare. Weaviate o Qdrant sono più performanti su corpora molto grandi (milioni di documenti).
3. Retrieval e reranking
La ricerca di similarità restituisce i K chunk più vicini semanticamente alla domanda. Non sempre i più vicini semanticamente sono i più utili per rispondere. Il reranking (cross-encoder) riordina i risultati con un modello più lento ma più preciso. La differenza in qualità delle risposte è spesso significativa, specialmente su domande complesse o multi-parte.
Il problema più comune che vedo: chunk troppo piccoli (50-100 caratteri) o troppo grandi (interi documenti). Il chunking ottimale per la maggior parte dei documenti aziendali è 300-600 token con 50-100 token di overlap tra chunk adiacenti. Ma dipende dal tipo di documento — un manuale tecnico ha bisogno di chunk diversi rispetto a un contratto legale.
# Strumenti: cosa uso e perché
| Componente | Scelta tipica | Alternativa |
|---|---|---|
| Embedding | OpenAI text-embedding-3-small | Cohere, BGE-M3 (locale) |
| Vector store | pgvector (PostgreSQL) | Qdrant, Chroma, Pinecone |
| Reranker | Cohere Rerank | cross-encoder locale |
| LLM generazione | Claude Haiku / GPT-4o-mini | Claude Sonnet per casi complessi |
| Orchestrazione | Python custom | LangChain, LlamaIndex |
| PDF parsing | pdfplumber + pypdf | Docling, Unstructured |
Nota su LangChain e LlamaIndex: sono utili per prototipare, ma tendono ad aggiungere astrazione sopra astrazione. In produzione preferisco pipeline Python custom: meno magie, più controllo, meno surface di errori silenziosi.
# I 5 errori che fanno fallire le RAG in produzione
- Nessuna valutazione della qualità del retrieval. Come sai se i chunk restituiti sono quelli giusti? Senza un dataset di test con domande/risposte attese, stai andando a intuizione.
- Ignorare le domande che non trovano risposta. Un buon sistema RAG deve sapere quando non ha abbastanza informazioni per rispondere e dirlo esplicitamente, invece di allucinare.
- Documenti aggiornati ma embedding vecchi. Se aggiorni un documento nella knowledge base senza rigenerare gli embedding relativi, il sistema continuerà a rispondere con le informazioni vecchie.
- Prompt di sistema troppo vago. "Rispondi in base ai documenti" non basta. Il prompt deve definire il tono, come gestire l'incertezza, quando citare la fonte, cosa fare con domande fuori scope.
- Nessun logging delle query. Le domande degli utenti sono la fonte di miglioramento più preziosa. Se non le registri, non sai cosa funziona e cosa no.
# Quando RAG è la soluzione giusta
RAG è ideale quando:
- Hai documenti proprietari che il modello non conosce
- I documenti si aggiornano frequentemente
- Le risposte devono essere verificabili (con citazione della fonte)
- Il volume di documenti è troppo grande per stare nel contesto del modello
RAG non è la soluzione quando:
- Hai meno di 20-30 documenti piccoli: può bastare inserirli tutti nel contesto
- Le domande richiedono ragionamento multi-step su dati strutturati: meglio SQL + LLM
- I documenti cambiano in tempo reale: serve un'architettura con aggiornamento incrementale degli embedding
Puoi vedere un esempio di RAG che ho costruito per un cliente nel portfolio. Se hai un caso specifico da valutare, scrivimi — il primo incontro è gratuito.
// FAQ
Cos'è la RAG in intelligenza artificiale?
RAG (Retrieval-Augmented Generation) è una tecnica che combina ricerca semantica con generazione di testo. Prima di rispondere, il sistema cerca nei tuoi documenti i pezzi più rilevanti alla domanda e li passa come contesto al modello. Risultato: risposte basate sulla tua documentazione specifica, non sulla conoscenza generica del modello.
Quanto costa implementare una pipeline RAG?
Una pipeline RAG aziendale base costa tra 3.000 e 8.000 euro di sviluppo. I costi operativi mensili sono solitamente sotto i 30-50 euro per volumi medi (500-1.000 query/mese): database vettoriale (gratis con pgvector su server esistente), embedding OpenAI (~0,02$/1M token con text-embedding-3-small), LLM per le risposte (variabile). I costi esplodono se usi Pinecone e GPT-4 senza ottimizzazione.
Quali documenti si possono usare in una pipeline RAG?
Qualsiasi documento testuale: PDF (con o senza OCR), Word, Excel, PowerPoint, pagine web, database relazionali, email, Notion, Confluence, Slack. Il preprocessing è fondamentale: documenti mal strutturati o scansionati con OCR scarso producono risposte inaffidabili indipendentemente dalla qualità del modello.
RAG è diverso dal fine-tuning?
Sì, sono approcci complementari. Fine-tuning aggiorna i pesi del modello su esempi specifici — utile per addestrare uno stile di risposta o un dominio tecnico molto specifico. RAG aggiunge conoscenza esterna senza toccare il modello — utile per documenti che cambiano. In pratica il 90% dei casi aziendali si risolve con RAG, non con fine-tuning.
Vuoi costruire una RAG sui tuoi documenti?
Dimmi che tipo di documenti hai e cosa vuoi che il sistema sappia rispondere. Valuto la fattibilità e ti dico costi e tempi realistici. Gratis.