Cos'è la Retrieval-Augmented Generation e perché usarla?
La Retrieval-Augmented Generation (RAG) è un pattern in cui recuperi documenti rilevanti da un archivio di conoscenza esterno al momento della query e li passi a un modello linguistico come contesto, così risponde da quelle prove invece che dai soli dati di addestramento. La usi quando le risposte devono riflettere informazioni attuali, private o di dominio, quando servono citazioni, o quando ri-addestrare il modello è troppo lento o costoso. La RAG riduce anche le allucinazioni perché al modello viene detto di ancorare la risposta ai passaggi forniti.
Quando dovrei usare la RAG invece del fine-tuning?
Usa la RAG quando la conoscenza cambia spesso, deve essere citata o è privata, perché puoi aggiornare un indice in pochi secondi senza toccare il modello. Usa il fine-tuning quando devi cambiare lo stile, il formato o il comportamento del modello su un compito piuttosto che i fatti, poiché il fine-tuning insegna come rispondere, non cosa è vero ora. I due sono complementari: un modello fine-tuned può comunque recuperare fatti via RAG, e molti sistemi in produzione fanno entrambe le cose.
Quanto dovrebbero essere grandi i miei chunk?
Non esiste una dimensione universale, ma un punto di partenza comune è circa 200-500 token (circa 300-600 caratteri per passaggio in molti corpus) con un piccolo overlap così il contesto non viene tagliato a metà di un'idea. Chunk più grandi conservano più contesto ma diluiscono la rilevanza e sprecano la finestra di contesto; chunk più piccoli sono precisi ma possono perdere il significato circostante. La dimensione giusta dipende dai tuoi documenti e dal modello, quindi trattala come un parametro da regolare contro il tuo eval set anziché come una regola fissa.
Perché combinare ricerca per parole chiave e ricerca vettoriale?
La ricerca vettoriale (semantica) trova passaggi per significato anche quando la formulazione differisce, ma può sfumare identificatori esatti, codici e termini rari; la ricerca lessicale come BM25 centra quelle corrispondenze esatte ma manca le parafrasi. Combinarle come ricerca ibrida e fondere i risultati (di solito con la Reciprocal Rank Fusion) supera in genere ciascun metodo da solo, perché ognuno copre il punto cieco dell'altro. È uno dei miglioramenti a più alta resa e a più basso rischio che puoi apportare a un retriever.
Cos'è il re-ranking e mi serve?
Il re-ranking è un secondo passaggio che ri-assegna punteggi al tuo insieme iniziale di candidati con un modello più accurato ma più lento, di solito un cross-encoder che legge query e ogni passaggio insieme, poi tiene solo i migliori per il generatore. Ti serve quando il retrieval di prima fase restituisce risultati grosso modo rilevanti ma mal ordinati, cosa comune con top-k più alti. Migliora sensibilmente la precisione in cima alla lista, al costo di latenza aggiuntiva, quindi recupera una rete più ampia (ad esempio top-50) e fai re-rank fino a top-5.
Come impedisco al mio sistema RAG di allucinare?
Nella RAG l'allucinazione viene di solito da un retrieval debole o da un prompt che lascia al modello la possibilità di ripiegare sulla memoria, quindi attacca entrambi. Migliora il retrieval (ricerca ibrida, re-ranking, chunking migliore) così che le prove giuste siano effettivamente presenti, e usa un prompt di grounding che istruisca il modello a rispondere solo dal contesto fornito e a dire "il contesto non copre questo" quando non può. Poi misura la faithfulness su un eval set, così le regressioni vengono colte prima del rilascio anziché dagli utenti.
Come valuto una pipeline RAG?
Costruisci un golden set di domande, ciascuna con una risposta di riferimento e i contesti che la supportano, poi valuta la pipeline su metriche di retrieval e di generazione separatamente. Il retrieval si misura con context recall e context precision (abbiamo recuperato i passaggi giusti?) e la generazione con faithfulness e answer relevancy (il modello ha risposto correttamente da essi?). Framework come RAGAS, promptfoo e DeepEval automatizzano tutto ciò, e dovresti integrarlo in CI così che una soglia di qualità blocchi i merge difettosi.
Perché il mio sistema RAG recupera chunk irrilevanti?
Le cause più comuni sono un chunking scadente (passaggi che mescolano più argomenti o sono tagliati a metà), un embedding della query che non corrisponde a come sono formulati i documenti, o filtri di metadati mancanti che lasciano entrare contenuto non correlato. Diagnostica ispezionando i chunk effettivamente recuperati per le domande che falliscono, non leggendo solo la risposta finale. Le correzioni includono chunking consapevole della struttura, query expansion o HyDE per query brevi, aggiungere ricerca ibrida e filtrare per fonte, lingua o data.
Quanti chunk dovrei inviare al modello (quale top-k)?
Top-k bilancia recall contro rumore e costo: troppo pochi e perdi prove di supporto, troppi e seppellisci la risposta nel disordine sprecando token. Un pattern comune è recuperare un ampio insieme di candidati, fare re-rank e poi passare al generatore solo i primi 3-8 passaggi. Regola il k finale sul tuo eval set, osservando faithfulness e answer relevancy invece di tirare a indovinare.
Cos'è la prompt injection e come mi difendo nella RAG?
La prompt injection è quando istruzioni malevole nascoste in documenti recuperati o input dell'utente ingannano il modello facendogli ignorare il suo system prompt o compiere azioni indesiderate, ed è particolarmente pericolosa nella RAG perché il testo non fidato entra nel prompt come contesto. Difenditi trattando il contenuto recuperato come dati anziché comandi, sanificando e delimitando chiaramente il contesto, limitando tool e privilegi del modello e validando gli output prima di agire. Non lasciare mai che il solo testo recuperato autorizzi un'azione sensibile.
Quale vector database dovrei scegliere?
Scegli in base a scala, stack esistente e propensione operativa più che ai soli benchmark. Se usi già PostgreSQL, pgvector tiene tutto in un solo database ed è ottimo fino a milioni di vettori; Qdrant, Weaviate e Milvus sono pensati per carichi molto grandi o ad alto throughput; Redis con RediSearch si adatta a usi a bassa latenza vicini al caching; servizi gestiti come Pinecone tolgono operatività al costo di lock-in. La maggior parte dei team dovrebbe partire dall'opzione più semplice che basti e migrare solo quando emerge un limite reale.
Come mantengo aggiornato il mio indice RAG quando i documenti cambiano?
Rendi l'ingestion incrementale e idempotente, così rieseguirla aggiorna solo ciò che è cambiato, con chiave un id documento stabile e un hash di contenuto o una versione. Rileva i cambiamenti alla fonte (webhook, change feed o diff schedulati), ri-suddividi e ri-embedda solo i documenti interessati, ed elimina i chunk del contenuto rimosso. Abbina ciò all'invalidazione della cache legata alle stesse chiavi, così embedding e risultati di retrieval stale non restano.
La RAG può rispondere a domande multi-step o multi-documento?
La RAG a colpo singolo, che recupera una volta e risponde, fallisce spesso su domande che richiedono fatti-ponte sparsi tra documenti. Per quelle, usa RAG multi-hop o agentic, dove il modello recupera, legge, riformula e recupera di nuovo in un loop limitato, oppure decomponi la domanda in sotto-domande e unisci le loro prove. Il GraphRAG aiuta quando la domanda richiede struttura o relazioni a livello di intero corpus anziché passaggi isolati. Il compromesso è maggiore latenza e complessità, quindi riservalo a query che ne hanno davvero bisogno.
Quali metriche contano per un servizio RAG in produzione?
Tieni sotto controllo qualità e operatività insieme. Per la qualità, monitora faithfulness, answer relevancy e recall/precision del retrieval su un eval continuo e su traffico reale campionato; per l'operatività, osserva latenza p95, costo per query, tassi di errore di retrieval e generazione e la percentuale di risposte "non lo so". Un tasso di "nessuna risposta" in crescita o un recall in calo segnalano spesso contenuto stale o insufficiente prima che gli utenti se ne lamentino.
Come riduco costo e latenza di un sistema RAG?
Fai caching in modo aggressivo: riusa gli embedding per testo invariato, metti in cache i risultati di retrieval per query ripetute e usa il prompt/KV caching per riusare un prefisso di grounding stabile tra le chiamate. Recupera un top-k più piccolo e ri-rankato così invii meno token al generatore, scegli un modello di embedding dimensionato alle tue esigenze di accuratezza e seleziona un indice ANN regolato sul tuo target di latenza. Misura costo e latenza p95 per query così che ogni ottimizzazione sia verificata anziché presunta.
Mi serve sempre un vector database per la RAG?
No. Per corpus piccoli o statici, un indice in memoria o persino il coseno a forza bruta su poche migliaia di vettori è semplice e abbastanza veloce, e un database relazionale con full-text search può servire una RAG solo lessicale. Un vector store dedicato serve quando il corpus cresce al punto in cui la ricerca dei vicini approssimata e il filtraggio per metadati su larga scala contano per la latenza. Parti dalla cosa più semplice che soddisfi i tuoi target di recall e latenza e aggiungi infrastruttura solo quando un limite reale lo impone.