Come implementare RAG: architettura, chunking, database vettoriali e valutazione

Che cosa significa implementare RAG e come funziona?

Implementare RAG significa collegare un large language model alla vostra conoscenza, così risponde a partire dai vostri documenti invece che dalla memoria. Al momento della richiesta il sistema cerca nei contenuti indicizzati, seleziona i passaggi più pertinenti, li inserisce nel prompt e chiede al modello di rispondere con citazioni.

Un'architettura RAG di produzione ha due pipeline:

1. Pipeline di ingestione: collegare le fonti, fare il parsing dei file, ripulire il testo, suddividerlo in chunk, creare gli embedding, memorizzare i chunk con metadati e regole di accesso e mantenere tutto sincronizzato.
2. Pipeline di query: comprendere la domanda, eseguire la ricerca ibrida, riordinare i risultati, comporre il prompt, generare la risposta, allegare le citazioni e registrare tutto per la valutazione.

La maggior parte dei fallimenti RAG nasce dalla prima pipeline, non dal modello. Se una tabella viene interpretata come rumore o una policy viene divisa a metà, nessun modello può recuperare la risposta. Questa guida percorre ogni fase come la affrontiamo in Lytvynov Production. Per il lato della consegna, consultate i nostri servizi di sviluppo RAG.

Come fare ingestione e parsing dei documenti?

L'ingestione deve trasformare ogni fonte in testo pulito con struttura e metadati: titolo, intestazioni, URL di origine, autore, date, tipo di documento, lingua e chi è autorizzato a leggerlo. Dedicate tempo vero a questa fase, perché la qualità del parsing fissa il limite massimo della qualità delle risposte.

Fonti comuni e ciò di cui hanno bisogno:

• PDF e file Office: parsing che tiene conto del layout e conserva intestazioni, elenchi e tabelle; OCR per le pagine scansionate.
• Wiki e help center (Confluence, Notion, Zendesk, Intercom): connettori API che recuperano anche permessi e date di aggiornamento.
• Ticket, chat ed email: ricostruzione dei thread, deduplicazione delle risposte citate e rimozione delle firme.
• Database e cataloghi prodotti: convertire i record in brevi testi leggibili oppure interrogarli direttamente con tool invece di trasformarli in embedding.

Normalizzare molti formati disordinati in un'unica tabella pulita è spesso la parte più difficile. Nel progetto AI Grief Companion abbiamo scritto parser per dieci formati di esportazione delle chat (WhatsApp, Messenger, Instagram, Discord, iMessage da un backup di iPhone, SMS Android e altri) e li abbiamo normalizzati tutti in un'unica tabella dei messaggi prima di eseguire qualsiasi passaggio AI. La stessa lezione vale per i dati aziendali: investite prima in un unico modello normalizzato. La nostra piattaforma di calendario sportivo mostra la stessa disciplina al di fuori dell'AI, con un motore di parsing che unifica i dati di centinaia di calendari esterni.

Quale strategia di chunking usare?

Suddividete prima in base alla struttura del documento e poi in base alla dimensione. Dividete su intestazioni, sezioni, voci di elenco o thread di messaggi, poi limitate i chunk a una dimensione che contenga un'idea completa, tipicamente 200-800 token con una piccola sovrapposizione.

Aggiungete contesto a ogni chunk: anteponete il titolo del documento e il percorso della sezione ("Policy di rimborso > Clienti UE > Beni digitali"), così il chunk ha senso da solo. Questo singolo passaggio migliora spesso il retrieval più del cambio di modello di embedding.

Come scegliere un modello di embedding?

Scegliete un modello di embedding che gestisca le vostre lingue e il vocabolario del vostro settore, poi testate due o tre candidati sul vostro golden set. Le API di embedding ospitate di OpenAI e di altri sono una scelta predefinita sensata; i modelli di embedding open-weight sono una buona scelta quando i dati devono restare nella vostra infrastruttura.

Registrate il modello di embedding e la sua versione insieme a ogni vettore memorizzato. Cambiare modello in seguito significa ricalcolare gli embedding dell'intero corpus, quindi pianificatelo come un normale job in background, non come un'emergenza. Per i contenuti multilingue verificate che una domanda in una lingua recuperi documenti scritti in un'altra, se i vostri utenti ne hanno bisogno.

Quale database vettoriale usare per il RAG?

Usate il database che il vostro team sa gestire bene. Per la maggior parte dei sistemi RAG aziendali sotto le decine di milioni di chunk, la qualità del retrieval dipende molto più da chunking, ricerca ibrida e reranking che dalla scelta del vector store.

La nostra scelta predefinita per i clienti SaaS su PostgreSQL è pgvector, perché permessi e ID dei tenant stanno accanto ai vettori e c'è un sistema in meno da mettere in sicurezza. Passiamo a un motore dedicato quando la scala o le esigenze di filtro lo giustificano.

Perché usare ricerca ibrida e reranking?

La ricerca ibrida combina la ricerca per parole chiave (BM25) con la ricerca vettoriale, perché ciascuna trova cose che l'altra non trova. La ricerca vettoriale comprende le parafrasi; la ricerca per parole chiave intercetta codici prodotto esatti, messaggi di errore, nomi e acronimi. Un reranker riordina poi i candidati combinati in base alla reale pertinenza rispetto alla domanda.

Un flusso di query tipico: riscrivere la domanda dell'utente come query di ricerca autonoma (risolvendo "esso" e "quello" dalla conversazione), eseguire in parallelo ricerca per parole chiave e vettoriale con i filtri sui permessi, unire i risultati (la reciprocal rank fusion è un metodo semplice), riordinare i primi 30-50 candidati con un cross-encoder o un'API di reranking e mantenere i primi 5-10 per il prompt. In un progetto RAG il reranking offre di solito uno dei maggiori guadagni di qualità per ora di lavoro ingegneristico.

Come comporre il prompt e aggiungere le citazioni?

Componete il prompt con sezioni chiare: regole di sistema, passaggi recuperati ciascuno etichettato con un ID di origine, la conversazione fino a quel momento e la domanda. Istruite il modello a rispondere solo a partire dai passaggi, a citare gli ID di origine per ogni affermazione e a dire chiaramente quando le fonti non contengono la risposta.

Dopo la generazione, validate le citazioni nel codice: ogni ID citato deve esistere nell'insieme recuperato, e le risposte senza citazioni per affermazioni fattuali possono essere segnalate o rigenerate. Mostrate le citazioni nell'interfaccia come link al documento e alla sezione originali. Gli utenti si fidano delle risposte che possono verificare, e i team di supporto possono correggere il documento di origine invece di discutere con l'AI. Per il quadro più ampio dell'integrazione (streaming, guardrail, costi), consultate la nostra guida su come integrare ChatGPT o Claude in un'applicazione.

Come gestire permessi e controllo degli accessi nel RAG?

Applicate i permessi al momento del retrieval, prima che qualsiasi passaggio arrivi al modello. Memorizzate i metadati di accesso (ID del tenant, team, ruolo, ACL del documento) con ogni chunk e applicateli come filtro nella query di ricerca per l'utente corrente.

Non affidatevi mai al prompt per nascondere contenuti ("non rivelare i documenti HR"), perché i modelli possono essere convinti a ignorare le istruzioni. Sincronizzate rapidamente le modifiche ai permessi dai sistemi di origine e rimuovete i chunk quando i documenti vengono eliminati. In un SaaS multi-tenant un filtro sul tenant in ogni query è obbligatorio, e aggiungiamo test automatici che provano a recuperare i dati di un altro tenant. I contenuti sensibili possono richiedere anche la cifratura a riposo; la piattaforma AI Grief Companion cifra ogni messaggio al momento dell'ingestione con AES-256-GCM per singolo messaggio e supporta la cancellazione di tutto con un clic.

Come valutare un sistema RAG?

Valutate retrieval e generazione separatamente, usando un golden set di domande reali. Senza un golden set ogni modifica è un'ipotesi, e i team finiscono per regolare i prompt sull'ultimo esempio di cui qualcuno si è lamentato.

• Golden set: 100-300 domande reali con risposte di riferimento e i documenti di origine che dovrebbero essere trovati. Includete domande la cui risposta non è presente nel corpus.
• Metriche di retrieval: recall at k (il passaggio corretto è comparso tra i primi k?) e qualità dell'ordinamento.
• Metriche di generazione: fedeltà (ogni affermazione è supportata dai passaggi recuperati?), pertinenza della risposta, completezza e accuratezza delle citazioni. Un secondo modello può valutarle con una rubrica, con persone che revisionano un campione.
• Segnali di produzione: pollici in giù, riformulazioni successive, escalation a un operatore umano e domande senza risposta.

Eseguite il set a ogni modifica di parsing, chunking, embedding, impostazioni di ricerca, prompt o modelli, e bloccate i rilasci che abbassano i punteggi.

Come mantenere aggiornato un indice RAG?

Mantenete l'indice aggiornato con una sincronizzazione incrementale: rilevate i documenti nuovi, modificati ed eliminati in ogni fonte e aggiornate solo i chunk interessati. Memorizzate per ogni documento un hash del contenuto e una data di aggiornamento, così i file invariati vengono saltati.

I webhook dai sistemi di origine offrono aggiornamenti quasi in tempo reale; i job pianificati (ogni ora o ogni notte) vanno bene per i contenuti che cambiano più lentamente. Aggiungete alla ricerca metadati di aggiornamento, così le versioni più recenti di una policy superano quelle più vecchie, e archiviate i documenti superati invece di lasciarli in concorrenza. Monitorate i job di sincronizzazione come qualsiasi altra pipeline di produzione, perché un errore di sincronizzazione silenzioso rende l'assistente sicuro di sé ma in errore sulle modifiche del mese scorso.

Quali sono gli errori RAG più comuni?

Gli errori più comuni sono errori di retrieval che sembrano errori del modello. Quando una risposta è sbagliata, verificate prima di tutto se il passaggio giusto è stato recuperato.

RAG, fine-tuning o contesto lungo: cosa scegliere?

Scegliete il RAG per la conoscenza, il fine-tuning per il comportamento e il contesto lungo per materiale piccolo e specifico di ogni richiesta. Sono complementari, non in concorrenza, e molti sistemi in produzione ne usano due insieme.

La piattaforma AI Grief Companion è un esempio reale di combinazione di approcci. Costruisce un profilo di personalità, un grafo dei fatti in Neo4j e la preparazione RAG dalla cronologia delle chat dell'utente, e addestra adapter LoRA (SFT e CPT su Qwen2.5-7B con QLoRA a 4 bit) per la voce di una persona specifica, con vLLM che carica l'adapter giusto al momento della richiesta. La chat usa la fase che è pronta, quindi una conversazione è possibile prima che l'addestramento finisca. Il fine-tuning gestisce come scrive la persona; il retrieval gestisce ciò che ha detto.

Come lavoriamo ai progetti RAG

In Lytvynov Production iniziamo i progetti RAG con una breve call di scoping: esaminiamo un campione dei vostri documenti reali e delle domande che gli utenti pongono, poi vi forniamo un preventivo fisso per lo sviluppo. La prima milestone costruisce un golden set e testa su di esso parsing e retrieval. Consegniamo poi per milestone, riportando i punteggi di valutazione a ciascuna. Se state pianificando un assistente della conoscenza o un chatbot AI sui dati aziendali, contattateci.