RAG enterprise: come evitare allucinazioni su dataset aziendali

Il problema che nessuno vuole ammettere

Un cliente nel settore assicurativo ha deployato un chatbot interno basato su GPT-4 per rispondere a domande sui contratti. Dopo tre settimane, un operatore ha notato che il sistema citava clausole inesistenti con sicurezza assoluta. Il danno reputazionale interno è stato significativo. Il costo del rollback, superiore a quello dell'implementazione.

Questo non è un caso isolato. Il 67% dei progetti RAG enterprise fallisce o viene ridimensionato entro sei mesi dal go-live, secondo dati aggregati da Gartner e survey interne di consulenza. Il motivo quasi sempre non è il modello: è l'architettura di retrieval.

---

Cos'è realmente il problema delle allucinazioni in contesto RAG

L'allucinazione in un sistema RAG enterprise ha una causa precisa: il modello riceve contesto insufficiente, ambiguo o errato, e colma i gap con inferenze non ancorate ai dati reali.

I tre pattern più frequenti:

1. Chunk retrieval scorretto I documenti vengono spezzati in chunk fissi (es. 512 token) senza rispettare la struttura semantica. Un paragrafo sulle penali contrattuali viene separato dall'intestazione del contratto. Il retriever recupera il chunk sulle penali, ma il modello non sa a quale contratto si riferisce.

2. Score di similarità troppo permissivi Il retriever restituisce documenti con cosine similarity di 0.62 quando la soglia minima accettabile per testo legale o normativo dovrebbe essere ≥ 0.80. Il modello lavora con contesto irrilevante e compensa inventando.

3. Mancanza di grounding verification Nessun layer verifica che le affermazioni del modello siano tracciabili ai chunk recuperati. Il modello può citare dati non presenti nel contesto e nessun componente lo intercetta.

---

L'architettura corretta per RAG enterprise

Chunking semantico, non fisso

Abbandonare il chunking a dimensione fissa. Usare chunking basato su struttura del documento:

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,
    chunk_overlap=150,
    separators=["\n\n", "\n", ". ", " "],
    length_function=len
)

Meglio ancora, per documenti strutturati (contratti, manuali tecnici, normative), implementare un parser gerarchico che mantenga il breadcrumb contestuale: ogni chunk porta con sé metadati sul documento padre, la sezione, il numero di articolo.

chunk_metadata = {
    "source": "contratto_fornitura_2024_v3.pdf",
    "section": "Articolo 7 - Penali",
    "page": 12,
    "doc_type": "legal",
    "last_updated": "2024-03-15"
}

Questo metadato viene recuperato insieme al chunk e incluso nel prompt. Il modello sa sempre da dove viene l'informazione.

Retrieval a due stadi con re-ranking

Un singolo retriever vettoriale non è sufficiente per dataset enterprise complessi. L'approccio corretto:

Stage 1 — Candidate retrieval: recupero ampio con vector search (top-k = 20, soglia bassa)
Stage 2 — Re-ranking: un cross-encoder (es. cross-encoder/ms-marco-MiniLM-L-6-v2) ri-valuta la rilevanza dei 20 candidati e seleziona i top-5 realmente pertinenti alla query

from sentence_transformers import CrossEncoder

re_ranker = CrossEncoder('cross-encoder/ms-marco-MiniLM-L-6-v2')
scores = re_ranker.predict([(query, chunk) for chunk in candidate_chunks])
top_chunks = [candidate_chunks[i] for i in sorted(range(len(scores)), key=lambda x: scores[x], reverse=True)[:5]]

Il re-ranker riduce drasticamente il rumore nel contesto passato al modello.

Soglie di confidenza esplicite

Definire soglie minime per tipo di documento:

| Tipo documento | Soglia cosine similarity minima | |---|---| | Normativa / compliance | 0.82 | | Contratti | 0.80 | | Knowledge base tecnica | 0.75 | | FAQ interne | 0.70 |

Se nessun chunk supera la soglia, il sistema deve rispondere con un fallback esplicito: "Non ho trovato informazioni sufficientemente rilevanti nel dataset aziendale per rispondere a questa domanda." — non un'invenzione.

Grounding verification layer

L'ultimo strato difensivo: un componente che verifica post-generazione che ogni affermazione fattuale della risposta sia tracciabile ai chunk forniti come contesto.

Approcci praticabili:

NLI-based: usare un modello di Natural Language Inference (es. facebook/bart-large-mnli) per verificare che la risposta sia entailed dal contesto
Citation forcing: forzare il modello a citare il chunk sorgente per ogni affermazione tramite prompt strutturato
Confidence scoring: chiedere al modello di auto-valutare la sua certezza su una scala 1-5 prima di restituire la risposta

System prompt (estratto):
"Per ogni affermazione fattuale nella tua risposta, indica tra parentesi quadre il numero del chunk sorgente [chunk_N]. Se non riesci a trovare supporto nei chunk forniti, scrivi esplicitamente: INFORMAZIONE NON DISPONIBILE NEL DATASET."

---

Monitoring in produzione

Un sistema RAG senza monitoring è cieco. Le metriche minime da tracciare:

Retrieval recall@5: quante delle risposte rilevanti sono nei top-5 chunk recuperati
Answer faithfulness: rapporto tra affermazioni nella risposta ancorate al contesto vs. totali (tool: RAGAS)
Fallback rate: percentuale di query che non superano la soglia di confidenza — un valore >15% segnala problemi nella copertura del dataset
Latenza per stage: separare la latenza di retrieval da quella di generation per identificare i colli di bottiglia

# Esempio di valutazione con RAGAS
ragas evaluate \
  --dataset ./eval_dataset.json \
  --metrics faithfulness,answer_relevancy,context_recall

---

Take-away operativo

Il chunking fisso è la causa numero uno di allucinazioni nei RAG aziendali. Sostituirlo con chunking semantico gerarchico con metadati contestuali.
Implementare retrieval a due stadi. Un solo vettore embeddings non è sufficiente per dataset enterprise.
Definire soglie di confidenza per tipo di documento. Il fallback esplicito è meglio di una risposta inventata.
Aggiungere un grounding verification layer prima di restituire la risposta all'utente.
Misurare faithfulness con RAGAS o strumenti equivalenti. Senza metriche, non esiste qualità.

Un sistema RAG ben costruito non elimina ogni rischio di errore, ma rende ogni errore tracciabile e correggibile. È la differenza tra un prototipo e un sistema enterprise.

---

Evviva Group supporta partner IT nella progettazione e implementazione di architetture RAG per uso enterprise. Se stai valutando un deployment simile, possiamo confrontarci.