Retrieval-Augmented Generation 2.0: Qualità, sicurezza e struttura dei costi

Molte iniziative nel campo della Retrieval-Augmented Generation (RAG) rimangono bloccate nello stadio della "demo wow": offrono risposte impressionanti, ma mancano di metriche di qualità chiaramente definite, garanzie di sicurezza affidabili e una struttura di costi sostenibile per il funzionamento. RAG 2.0 non intende più il retrieval come una semplice interrogazione di database, ma come un processo orchestrato, misurabile e a prova di revisione.

RAG 2.0 unisce orchestrazione integrata, Evals, guardrail e governance con KPI chiari, per piattaforme verificabili e stabili in produzione.

In sostanza, si tratta di stabilire la connessione tra ricerca semantica e sintesi di risposta generativa come un'architettura pronta per la produzione, con responsabilità chiare e un impatto verificabile sui reparti specialistici.

I moderni sistemi RAG richiedono molto più che la ricerca semantica e gli embedding. La prontezza per la produzione si ottiene solo attraverso una pianificazione precisa delle query, una valutazione sistematica e robusti meccanismi di controllo. Integrati da governance dei vettori, vera capacità multilingue, KPI chiaramente definiti e profili di costo e latenza ottimizzati, si crea un'architettura che non solo risponde in modo affidabile, ma può anche essere gestita in modo verificabile, controllabile e dimostrabilmente sicuro.

1) Perché le architetture RAG classiche falliscono

Nella pratica, le implementazioni "RAG 1.0" falliscono ripetutamente a causa di tre sfide centrali:

• Drift: Le basi di conoscenza sottostanti sono dinamiche; gli indici devono essere continuamente aggiornati, e l'allineamento degli embedding può essere compromesso da nuove versioni del modello. Di conseguenza, la comparabilità dei risultati perde progressivamente affidabilità nel tempo.
• Allucinazioni: Senza chiare prove di attribuzione e cicli di valutazione continui (Evals), le risposte, sebbene fluide, spesso non sono fattualmente affidabili o verificabili.
• Access Control: I database vettoriali spesso supportano solo namespace a granularità grossolana. Manca di solito un controllo degli accessi a granularità fine, basato su ruoli o attributi, a livello di documento o di chunk.

Esempio pratico (banca, direttive interne)

Un team indicizza migliaia di documenti di conformità interni in formato PDF. Dopo il passaggio a un nuovo modello di embedding, vengono reindicizzati solo i documenti appena aggiunti; i vecchi embedding rimangono invariati. Gli esperti di settore ricevono quindi risposte contraddittorie perché il sistema mescola versioni di direttive obsolete e attuali. Inoltre, la ricerca mostra frammenti di direttive per le quali l'utente non ha l'autorizzazione, un grave scostamento tra Identity and Access Management (IAM) e il processo di retrieval.

2) Architettura di RAG 2.0: Orchestrazione, Chunking, Evals e Osservabilità

Orchestrazione del retrieval

Al processo di ricerca vero e proprio viene anteposto un Planner, che identifica l'intenzione effettiva dell'utente (Intent), esegue i Query-Rewrites (sinonimi, termini di dominio), separa le sotto-query per specifiche strutture di dati (tabelle, FAQ, testo libero) e seleziona dinamicamente il numero ottimale di risultati (Top-k). I risultati vengono fusi tramite Reranking (ad esempio, utilizzando Cross-Encoder). Per query numeriche o basate su tabelle, viene attivato specificamente un Tabular-Retriever, mentre le domande su date o versioni considerano esclusivamente stati di conoscenza validi.

Chunking sensibile alla struttura

Invece di un approccio generico "one-size-fits-all", vengono impiegate strategie di chunking sensibili alla struttura:

• Chunking basato su titoli per la coerenza logica
• Finestre con sovrapposizione per garantire il contesto della frase
• Percorsi speciali per la conservazione intatta delle strutture di tabella (conservazione celle/righe) e delle immagini (layer OCR separato)

Essenziale è una disciplina rigorosa dei metadati dei chunk: ogni chunk deve contenere metadati come versione, periodo di validità, lingua e classificazione (ad esempio, "PII=sì/no"). Senza questi metadati, né la governance né una verificabilità affidabile sono possibili.

Evals come parte integrante del ciclo

Le valutazioni avvengono su due livelli:

• Offline-Evals con Gold-Sets verificano Contextual Precision/Recall, Faithfulness/Attribution e la rilevanza delle risposte. Inoltre, vengono simulate attacchi, ad esempio tramite Red-Team-Prompts come Prompt-Injection o varianti Jailbreak.
• Misurazioni online rilevano il tasso di Groundedness (percentuale di risposte comprovabili), il tasso di clic sulle citazioni (Citation Click-Through), la latenza p95, il costo per 100 query e la frequenza di attivazione dei Guardrail.

Tutte le metriche vengono protocollate per versione del prompt e versione del modello, al fine di garantire una tracciabilità completa del livello di qualità nel tempo.

Osservabilità e tracce di audit

Ogni esecuzione RAG genera un set completo di artefatti di audit:

• Il prompt utente pseudonimizzato
• Il piano di query eseguito
• Gli hit del retriever con ID e versioni dei documenti associati
• La versione del modello e del prompt utilizzati
• Le decisioni dei guardrail
• I costi e i tempi di latenza sostenuti

Questa catena continua costituisce la base per la riproducibilità, l'analisi sistematica degli errori (Post-Mortem) e la necessaria prova di conformità nei confronti di revisori interni ed esterni.

Governance dei vettori e cancellazione dei dati

Gli embedding possono essere considerati dati (indirettamente) personali se è possibile una ricostruzione o una derivazione di conclusioni. RAG 2.0 implementa quindi obbligatoriamente:

• Crittografia dei dati a riposo (at rest) e durante la trasmissione (in transit)
• Namespace per tenant per una stretta separazione dei clienti
• Meccanismi Time-to-Live (TTL) e Tombstoning per garantire il diritto alla cancellazione
• Protocolli di tutti i job di (re-)embedding
• Monitor di deriva che controllano gli spostamenti nella distribuzione degli embedding o nel valore di recall

I job di reindicizzazione sono sempre versionati e tracciabili in modo trasparente. In questo modo è sempre possibile spiegare su quale base dati sia stato ottenuto un determinato risultato.

3) Sicurezza e conformità nel contesto UE: Filtri PII, retrieval consapevole dei ruoli e auditabilità

Catena di filtri PII/PHI

Una catena di filtri multistadio per Personally Identifiable Information (PII) e Protected Health Information (PHI) viene applicata sia prima che dopo il retrieval. Le immissioni dell'utente vengono controllate per PII e mascherate se necessario. I passaggi dei risultati vengono riclassificati prima dell'iniezione nell'LLM. I policy-gate impediscono che fonti con una classe di protezione più alta confluiscano in chat con una classificazione inferiore.

Data: 08.12.2025