Cosa sono CAG e RAG, e quando scegliere l'uno o l'altra?

CAG (Cache-Augmented Generation) e RAG (Retrieval-Augmented Generation) sono due architetture alternative per collegare un LLM a una base di conoscenza aziendale. La RAG recupera i documenti rilevanti da un database vettoriale a ogni domanda e li passa al modello insieme al quesito. La CAG salta il recupero: carica l'intera base di conoscenza nella finestra di contesto del modello una volta sola, ne memorizza lo stato computazionale interno (la KV cache dell'attenzione) e riusa quello stato a ogni domanda successiva, senza rileggere né recuperare nulla. Il concetto è stato formalizzato nel paper del 2024 "Don't Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks", che lo propone come sostituto della RAG per i casi in cui la base di conoscenza è abbastanza piccola da entrare nella finestra di contesto e cambia raramente.

Il compromesso reale, non quello da slide

La CAG non è una versione "migliore" della RAG, è la scelta giusta per un problema diverso. Elimina la latenza di recupero, gli errori di retrieval (documenti sbagliati o irrilevanti pescati dal database vettoriale) e la complessità operativa di mantenere un indice vettoriale, una strategia di chunking e una pipeline di reranking. In cambio paga due prezzi che la RAG non paga: la base di conoscenza deve stare per intero nella finestra di contesto del modello, e ogni aggiornamento dei dati richiede di ricostruire la cache da zero, non di aggiungere una riga a un indice. È lo stesso compromesso della prompt caching applicato a un caso specifico: lì si riusa la parte fissa di un prompt tra richieste generiche, qui si riusa l'intera base di conoscenza come se fosse quella parte fissa. La RAG resta l'unica scelta sensata quando i dati cambiano di continuo (ticket aperti in tempo reale, prezzi, disponibilità) o quando la base di conoscenza è troppo grande per qualunque finestra di contesto, anche quelle più ampie oggi disponibili.

Un esempio enterprise

Un ufficio legale interno vuole un assistente che risponda su un corpus di 200 policy aziendali, aggiornate forse due volte l'anno in occasione di una revisione contrattuale. Con la RAG, ogni domanda passa da un database vettoriale che può recuperare il paragrafo sbagliato se due policy usano un linguaggio simile su temi diversi, un problema di qualità del retrieval che nessuna quantità di tuning elimina del tutto. Con la CAG, le 200 policy vengono caricate una volta nella cache del modello: ogni domanda successiva risponde con la vista completa del corpus, senza il rischio che un frammento rilevante resti fuori dal recupero. Il costo è che, alla prossima revisione delle policy, l'intera cache va ricalcolata, un'operazione pianificata e non istantanea, accettabile perché l'aggiornamento è raro e programmato, non continuo.

Perché conta per chi decide

Il criterio da applicare prima di scegliere non è quale architettura sia più moderna, ma due domande sui dati: quanto sono grandi, e quanto spesso cambiano. Una base di conoscenza piccola e stabile (policy interne, documentazione di prodotto tra una release e l'altra, contratti quadro) è il terreno naturale della CAG, con un guadagno diretto in semplicità operativa e costo di esercizio, perché elimina un intero sottosistema (il database vettoriale) da manutenere. Una base di conoscenza grande o che cambia ogni giorno resta terreno della RAG. Le due tecniche non si escludono nemmeno a vicenda in scala: alcuni sistemi usano la CAG per il nucleo di conoscenza stabile e la RAG per i dati che cambiano, invece di forzare tutto dentro un'unica architettura.