RAG per l'impresa: come integrare LLM con i dati aziendali

La Retrieval-Augmented Generation (RAG) è oggi il pattern dominante per costruire applicazioni basate su LLM che debbano rispondere su dati propri (documentazione tecnica, manuali, knowledge base, contratti). L'idea è semplice: invece di "addestrare" il modello sui propri documenti, si recupera il contesto rilevante al momento della domanda e lo si fornisce in input al modello assieme alla query.

Questo articolo riassume cosa serve sapere per impostare un progetto RAG basandosi sulle fonti tecniche di riferimento.

Fonti: paper originale Lewis et al., 2020 — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020 (arXiv:2005.11401), documentazione pgvector, OWASP Top 10 for LLM Applications.

1. Origine: il paper di Lewis et al. (2020)

Il termine RAG è stato coniato in un paper di Patrick Lewis e colleghi (Facebook AI Research, ora Meta AI) presentato a NeurIPS 2020. Il contributo originale combinava:

• un retriever denso (DPR — Dense Passage Retrieval) che recupera passaggi rilevanti da un corpus indicizzato;
• un generatore seq2seq (BART) che produce la risposta condizionato sui passaggi recuperati.

Il paper introduce due varianti — RAG-Sequence (un singolo set di documenti per l'intera generazione) e RAG-Token (decisione di retrieval token per token) — e dimostra miglioramenti su task knowledge-intensive (open-domain QA, fact verification).

Il pattern moderno adottato dall'industria è una semplificazione/evoluzione di quell'idea: il retriever recupera un top-k di chunk e l'LLM (generalmente un modello istruito) genera la risposta usando quel contesto.

2. Architettura tipica

Un sistema RAG enterprise tipico è composto da quattro fasi:

2.1 Ingestion

I documenti sorgente (PDF, HTML, Markdown, file Office) vengono:

1. estratti in testo (con strumenti tipo Apache Tika, Unstructured, parser PDF dedicati);
2. divisi in chunk (fixed-size, semantici, o ricorsivi). Le dimensioni tipiche sono 200–1000 token con overlap del 10–20%;
3. arricchiti con metadati (sorgente, data, autore, lingua, sezione).

2.2 Embedding e indicizzazione

Ogni chunk viene trasformato in un vettore di embedding tramite un modello dedicato (es. famiglia text-embedding-3 di OpenAI, modelli open come bge, e5, gte). Il vettore è memorizzato in un vector store che supporti ricerca per similarità (tipicamente coseno o prodotto interno).

Database con estensione vettoriale ampiamente adottati:

• pgvector (estensione PostgreSQL): integrazione nativa col DB relazionale, indici HNSW o IVFFlat. Documentazione: github.com/pgvector/pgvector.
• vector store dedicati (es. Qdrant, Weaviate, Milvus, Pinecone) — scelte motivate quando la scala e i requisiti di latenza superano quanto pgvector offre comodamente.

2.3 Retrieval

Alla query dell'utente:

1. si calcola l'embedding della query con lo stesso modello usato in ingestion;
2. si recuperano i top-k chunk più simili;
3. opzionalmente si applica un re-ranker (modello cross-encoder) sui top-k per migliorare la precisione, riducendo il set finale ai top-n effettivamente passati al modello;
4. si combinano spesso ricerca densa (vettoriale) e lessicale (BM25): il pattern è chiamato hybrid search.

2.4 Generation

I chunk selezionati sono inseriti nel prompt del modello, tipicamente con istruzioni esplicite:

"Rispondi solo sulla base dei seguenti documenti. Se l'informazione non è presente, dichiaralo. Cita la fonte tra parentesi quadre."

Vincolare il modello alla citazione delle fonti riduce le allucinazioni e rende la risposta verificabile.

3. Valutazione

Un sistema RAG è valutato lungo due assi distinti:

• Qualità del retrieval: i chunk pertinenti sono effettivamente nel top-k? Metriche standard di information retrieval: Recall@k, MRR (Mean Reciprocal Rank), NDCG.
• Qualità della risposta: la risposta è corretta, completa, fondata sui chunk recuperati? Si misurano faithfulness (la risposta è derivabile dal contesto?) e answer relevance (la risposta risponde alla domanda?).

Per la valutazione automatica esistono framework open source come RAGAS (Retrieval-Augmented Generation Assessment) che propongono metriche standardizzate. La valutazione manuale su un set rappresentativo di domande resta comunque imprescindibile.

4. Rischi di sicurezza (OWASP LLM Top 10)

L'OWASP Top 10 for LLM Applications elenca i rischi più rilevanti per chi mette in produzione applicazioni basate su LLM. I più direttamente pertinenti a un sistema RAG:

• LLM01: Prompt Injection — un documento malevolo nel corpus può contenere istruzioni nascoste che dirottano il comportamento del modello quando viene recuperato come contesto. Mitigazioni: sanitizzazione dei contenuti, system prompt rigorosi, separazione chiara tra dati e istruzioni.
• LLM02: Insecure Output Handling — la risposta del modello può contenere contenuti dannosi se viene rendered in HTML, eseguita come codice o inviata a sistemi a valle senza validazione.
• LLM06: Sensitive Information Disclosure — il retrieval può portare in risposta documenti riservati a utenti che non hanno il diritto di vederli. Il vector store non è un sistema di autorizzazioni: i permessi vanno applicati al livello di filtro nel retrieval (es. metadata filter per tenant/utente/ruolo) e/o nella query SQL sottostante.
• LLM08: Excessive Agency — se l'output del modello pilota azioni (chiamate API, scritture su sistemi), occorre confinare i tool e richiedere conferma umana per le azioni sensibili.

Riferimento ufficiale: owasp.org/www-project-top-10-for-large-language-model-applications.

5. Limiti realistici

RAG funziona bene quando:

• la conoscenza è testuale, densa e frammentabile in unità autoconsistenti;
• le risposte si basano su estrazione e sintesi di passaggi, non su ragionamento multi-hop complesso;
• il corpus è gestito (versionato, aggiornato, deduplicato).

Funziona meno bene quando:

• la risposta richiede aggregazioni numeriche (per quelle servono query strutturate, non retrieval);
• la conoscenza è in tabelle complesse o diagrammi (servono pipeline di parsing dedicate);
• il dominio richiede ragionamento multi-step su molti documenti contemporaneamente.

In questi casi la soluzione raramente è "più RAG"; spesso serve combinare RAG con tool use strutturato (es. interrogazioni SQL su un DB), agenti, o approcci ibridi.

6. Riferimenti

• Lewis et al., 2020 — paper originale: arXiv:2005.11401
• pgvector — documentazione: github.com/pgvector/pgvector
• OWASP Top 10 for LLM Applications: owasp.org/www-project-top-10-for-large-language-model-applications
• BM25 — algoritmo di ricerca lessicale: descrizione di riferimento in Manning, Raghavan, Schütze — Introduction to Information Retrieval, Cambridge University Press, 2008.

Articolo a finalità informative. I prodotti commerciali eventualmente menzionati sono citati come esempi rappresentativi della categoria.