RAG su documenti aziendali: come costruire una knowledge base che funziona davvero

Il RAG (Retrieval Augmented Generation) è la tecnologia alla base dei chatbot aziendali su documenti. L'idea è semplice: invece di chiedere al modello AI di ricordare tutto dal suo training, gli forniamo i documenti rilevanti al momento della domanda — e lui risponde basandosi su quelli. La differenza tra un sistema RAG che funziona e uno che delude quasi sempre sta nelle scelte implementative, non nel modello scelto.

Come funziona il RAG in un contesto aziendale

Il processo si divide in due fasi distinte: l'indicizzazione (fatta una volta, aggiornata quando cambiano i documenti) e il retrieval+generazione (fatto ad ogni domanda).

Fase 1 — Indicizzazione: i documenti vengono letti, spezzati in chunk, trasformati in vettori numerici (embedding) e salvati in un database vettoriale. Questo è il lavoro "pesante" che si fa una volta.

Fase 2 — Query: quando l'utente fa una domanda, anche quella viene trasformata in vettore, vengono cercati i chunk più simili nel database, e quei chunk vengono passati al modello LLM insieme alla domanda originale. Il modello risponde basandosi su quei testi specifici.

Il chunking: dove si vince o si perde

Il chunking — come si spezzano i documenti — è la decisione più impattante sull'intero sistema. Chunk troppo piccoli perdono il contesto; chunk troppo grandi includono informazioni irrilevanti che confondono il modello.

Chunking per tipo di documento

Manuali tecnici e procedure: chunk per sezione/paragrafo numerato, con overlap del 10–15%. Un capitolo di un manuale ha senso come unità — non la singola frase. Target: 400–600 token per chunk.

Schede prodotto e listini: ogni prodotto/SKU è un chunk. Includere sempre: codice, nome, specifiche chiave, prezzo, note. Non spezzare mai una scheda prodotto a metà.

Contratti e documenti legali: chunking per clausola o articolo, con metadato del documento di riferimento. È fondamentale che il sistema sappia da quale contratto viene ogni risposta.

Email e comunicazioni: una email = un chunk. Includere mittente, data e oggetto come metadato — aiutano enormemente il retrieval.

Gli embedding: quale modello scegliere

Per l'italiano, i modelli di embedding generici addestrati solo su inglese perdono qualità. Le opzioni consigliate per un sistema on-premise:

multilingual-e5-large (Microsoft): ottimo bilanciamento qualità/dimensione, ottimo supporto italiano. È la nostra scelta di default per la maggior parte dei progetti.

nomic-embed-text: embedding di alta qualità, contesto lungo (8.192 token), ottimo per documenti lunghi. Gira interamente on-premise.

paraphrase-multilingual-mpnet (Sentence Transformers): più leggero, adatto quando le risorse computazionali sono limitate.

Il database vettoriale: Chroma, Qdrant o pgvector?

Chroma: semplicissimo da configurare, ottimo per progetti pilota fino a ~500K documenti. Perfetto per iniziare e per team senza esperienza DevOps.

Qdrant: più scalabile, ottimo per volumi grandi, ha filtri avanzati sui metadati. Lo scegliamo quando la knowledge base supera 1 milione di chunk o quando i filtri (es. "cerca solo nei documenti del 2024") sono critici.

pgvector (PostgreSQL): se l'azienda ha già PostgreSQL in produzione, pgvector aggiunge la ricerca vettoriale senza introdurre un nuovo componente infrastrutturale. Ottimo per chi vuole minimizzare la complessità operativa.

Il retrieval: le ottimizzazioni che fanno la differenza

Il retrieval naive (prendi i k chunk più vicini) funziona, ma spesso non abbastanza bene. Le ottimizzazioni che migliorano sensibilmente i risultati:

Hybrid search: combinare ricerca vettoriale con BM25 (ricerca full-text classica). La ricerca vettoriale trova contenuti semanticamente simili; BM25 trova le corrispondenze esatte di termini tecnici, codici prodotto, nomi propri. La combinazione supera entrambe da sole.

Re-ranking: dopo aver recuperato 20 chunk, usare un cross-encoder per riordinarli per rilevanza effettiva prima di passarli al modello. Migliora la qualità delle risposte del 15–25% sul nostro benchmark interno.

Query expansion: generare varianti della domanda originale (sinonimi, formulazioni alternative) e fare retrieval su tutte. Utile quando gli utenti usano termini diversi da quelli nei documenti.

I problemi comuni e come evitarli

Allucinazioni: il modello risponde con informazioni inventate invece di dire "non lo so". Soluzione: nel prompt di sistema, istruire esplicitamente il modello a rispondere "Non ho trovato questa informazione nella documentazione disponibile" se i chunk recuperati non contengono la risposta. Monitorare il tasso di risposte "non trovato" — se è troppo alto, il problema è nel chunking o nel retrieval, non nel modello.

Risposte da documenti sbagliati: quando ci sono più versioni dello stesso documento, il sistema recupera quella vecchia. Soluzione: gestire le versioni con metadati espliciti e filtrare per data di aggiornamento nel retrieval.

Risposte incomplete: la risposta è corretta ma parziale perché l'informazione era spezzata su chunk diversi. Soluzione: aumentare il context window recuperato (più chunk) o usare chunking gerarchico.

Cosa misurare per capire se funziona

Prima del go-live, costruire un set di 50–100 domande di test con risposte attese. Misurare: accuratezza (risposta corretta?), completezza (risposta completa?), citazione fonte (il sistema indica da dove ha preso l'informazione?). Target realistico per un sistema ben configurato: 85–92% di accuracy su domande coperte dalla documentazione.