RAG o CAG: la scelta operativa prima dell'architettura

Quando un team vuole costruire un assistente AI sui propri documenti, la prima proposta è quasi sempre la stessa: facciamo un RAG. Indicizzazione, vector store, retrieval, risposta con fonti. È diventato il riflesso automatico per qualsiasi domanda su conoscenza aziendale.

Il riflesso è comprensibile, ma non sempre corretto. Un sistema RAG aggiunge componenti, stati intermedi e punti di fallimento. Può recuperare il documento sbagliato, perdere contesto, restituire chunk corretti ma insufficienti, introdurre latenza e rendere più difficile capire perché il modello ha risposto in un certo modo.

Il punto non è scegliere una sigla più moderna. È capire che tipo di conoscenza stiamo usando e che comportamento ci aspettiamo dal sistema.

Quando il retrieval ha senso

Il RAG resta una buona scelta quando la base di conoscenza è grande, cambia spesso o deve essere interrogata in modo granulare. Se hai migliaia di documenti, policy che cambiano, ticket, contratti, knowledge base operative o contenuti con ownership distribuita, non vuoi caricare tutto nel prompt ogni volta. Vuoi recuperare il sottoinsieme più rilevante al momento della domanda.

Le documentazioni di OpenAI File Search e LlamaIndex descrivono bene questa logica: il modello non viene addestrato sui tuoi dati, ma riceve materiale pertinente a runtime. È un pattern potente, soprattutto quando serve mantenere il sistema aggiornato senza riaddestrare nulla.

Il costo nascosto è la qualità del retrieval. Se i chunk sono deboli, i metadati poveri o le query ambigue, il modello può sembrare intelligente mentre sta ragionando su materiale incompleto. Per questo molte “allucinazioni” non nascono dalla generazione, ma da un recupero dati fragile. Ne ho scritto anche parlando di retrieval failures.

Per questo un’implementazione RAG ha bisogno anche di un retrieval contract. Il contratto definisce perimetro delle fonti, freschezza, fallback e ownership prima che il modello inizi a rispondere con tono sicuro.

Quando il contesto può stare vicino al modello

Il CAG, cache-augmented generation, parte da un’osservazione diversa: se la conoscenza è limitata, stabile e gestibile dentro una finestra di contesto ampia, forse non serve recuperare a ogni richiesta. Il paper “Don’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks” propone proprio questa alternativa: precaricare le risorse rilevanti e usare cache di contesto o stato inferenziale per ridurre complessità e latenza.

Anche Anthropic, nel suo articolo su Contextual Retrieval, nota che per knowledge base sotto una certa dimensione può essere più semplice inserire tutto nel prompt, specialmente quando il prompt caching rende più sostenibile riusare lo stesso contesto. Google descrive un principio simile nella documentazione su Gemini context caching: quando si passano spesso gli stessi token, la cache può ridurre costo e tempo.

Questa strada funziona bene per manuali piccoli, procedure interne stabili, contratti standard, brief di progetto, policy operative o set di documenti che non cambiano ogni giorno. Non elimina il bisogno di governance. Lo sposta: bisogna sapere quale versione del contesto è caricata, quando scade, chi la aggiorna e quali domande sono fuori perimetro.

La scelta vera è manutenzione contro variabilità

La domanda pratica non è “RAG o CAG?”. È: quanto cambia la conoscenza, quanto è grande, quanto è costoso sbagliare retrieval, quanto serve spiegare la risposta e chi manterrà il sistema tra tre mesi?

Se la conoscenza cambia spesso, il RAG permette aggiornamenti più modulari. Se la conoscenza è compatta e stabile, il CAG può togliere componenti inutili. Se il dominio ha rischi alti, serve comunque un layer di valutazione, log e fallback umano. Nessuna architettura rende affidabile un sistema che nessuno misura.

Per una startup o un team operativo, partire semplice è spesso la decisione migliore. Un assistente su cinque documenti non ha bisogno di una piattaforma RAG complessa. Un assistente su migliaia di procedure, invece, non può vivere solo di prompt lunghi.

La maturità sta nel non innamorarsi della pipeline. Sta nel scegliere il pezzo minimo di architettura che rende il sistema verificabile, aggiornabile e utile nel lavoro quotidiano.

La decisione si può rivedere. Partire da CAG su cinque documenti stabili non impedisce di passare a RAG quando il corpus cresce. Partire da RAG su una knowledge base variabile non elimina il bisogno di cache per il contesto stabile. La scelta matura è quella che il team può mantenere senza trasformare la qualità delle risposte in un atto di fede.