Italiano
RAG vs. CAG vs. Agentic RAG: cosa deve sapere ogni CTO prima di scegliere nel 2026

RAG vs. CAG vs. Agentic RAG: cosa deve sapere ogni CTO prima di scegliere nel 2026

La domanda vera non è quale architettura di retrieval sia migliore, ma quanto è grande, dinamico e a rischio il vostro sapere aziendale, e quanta autonomia serve al sistema.

La decisione architetturale più costosa che un CTO può prendere nel 2026 non è la scelta del modello di IA, è il modo in cui quel modello accede al sapere aziendale.

Tre pattern si sono affermati: Retrieval-Augmented Generation (RAG), Cache-Augmented Generation (CAG) e Agentic RAG. I vendor li presentano come intercambiabili. Non lo sono. Ognuno risponde in modo diverso alle stesse quattro domande: quanto è grande la vostra base di conoscenza, con che frequenza cambia, cosa succede quando l'IA sbaglia e quanto deve essere autonomo il sistema?

I tre approcci, senza marketing

RAG è il pattern mainstream. Arriva una query, un layer di retrieval (ricerca ibrida lessicale + vettoriale, fusione via Reciprocal Rank Fusion) estrae i chunk più rilevanti dall'indice, il LLM condiziona la risposta su quei chunk. Azure AI Search, Vertex RAG Engine di Google e AWS Bedrock Knowledge Bases ne implementano varianti. Enhanced RAG aggiunge query rewriting, reranker e filtri sui metadati, la pipeline resta lineare e prevedibile.

CAG capovolge l'equazione. Invece di recuperare per ogni query, precaricate un corpus curato nel contesto del modello e preriscaldate la cache key-value. La latenza online scende quasi a zero perché ogni query riutilizza lo stato precaricato. Il rovescio: funziona solo se la base è piccola, stabile e sta nel budget di attenzione effettivo.

Agentic RAG lascia il controllo al LLM. Il modello decide quando recuperare, se recuperare di nuovo, quali tool chiamare e quando la risposta è abbastanza buona. È il pattern degli assistenti di ricerca e degli agenti back-office autonomi.

Cosa mostrano davvero i dati del 2026

Un confronto empirico di gennaio 2026 contraddice la maggior parte delle pitch dei vendor: Agentic non è universalmente migliore. In un setting finanziario Agentic raggiunge 97,7 / 98,8 recall/F1 battendo di poco Enhanced (95,1 / 95,7). Cambiate dominio e Agentic crolla a 49,3 / 64,6 mentre Enhanced regge a 84,4 / 87,9. Peggio sui costi: Agentic RAG ha prodotto fino a 3,6× il costo in token e tool-call di Enhanced per lo stesso carico.

Un readiness harness di marzo 2026 rende concreti i trade-off operativi. Aumentare la profondità di retrieval (k = 3 vs k = 10) guadagna 7–12 punti percentuali di Hit@k sui BEIR slice ma triplica il costo per run (≈ 0,007 a ≈ 0,020 USD). Aggiungere un reranker cambia tutto: su SciFact con k = 5, BM25 da solo massimizza Hit@k ma BM25 + reranker dà la migliore faithfulness e la p95 latency più bassa. La lezione: "modello più grande" non è una strategia. Su FiQA un modello più piccolo batte uno più grande in faithfulness, mentre il grande paga 9 secondi di p95.

Per CAG, benchmark pubblici dei vendor (dicembre 2025) riportano un BERTScore di 0,776 su HotPotQA, indicativo, non universale. Un segnale che CAG è praticabile per corpus piccoli e stabili, non una promessa.

Un framework decisionale per CTO

Prima di scegliere, fissate quattro punti:

  • Profilo di conoscenza, dimensione, frequenza di aggiornamento, ripetizione delle query, struttura.
  • Profilo di task, QA single-turn, reasoning multi-hop o workflow guidati da tool? Agentic si ripaga solo se il task richiede davvero iterazione.
  • Profilo di rischio, data residency, key management, obblighi di audit e raggio d'impatto di una citazione allucinata o di un tool call non supervisionato.
  • Profilo operativo, trace OpenTelemetry, harness di valutazione, CI gate per pipeline IA. Senza di essi Agentic RAG non è osservabile.

Tradotto per caso d'uso:

  • Customer support, Enhanced RAG di default. CAG interessante se FAQ/policy è stabile e piccolo. Agentic solo per workflow diagnostici cross-sistema.
  • Knowledge management interno, RAG con hybrid search e filtri sui metadati stringenti. CAG per manuali stabili isolati. Agentic per assistenti di ricerca con verifica.
  • Code generation, RAG code-aware con regole di scope. Agentic solo se servono refactoring autonomi, generazione test o flussi PR, con costo messo a budget.
  • Agent back-office autonomi, Agentic RAG per definizione, ma solo con guardrail duri: cap di budget, stop condition, human-in-the-loop sulle decisioni materiali e verifica claim-level.

Il layer di governance che nessuna architettura porta con sé

Ogni pattern sopra presume che qualcun altro si occupi di ciò che interessa ai regolatori: chi ha visto quali dati, la risposta era ancorata a fonti autorizzate, il tool call è rimasto entro policy, la catena sarà auditabile tra sei mesi. Non lo fanno. I vendor RAG forniscono retrieval e indicizzazione. I framework CAG gestiscono il contesto. I framework agentici orchestrano. Nessuno fornisce governance.

Sotto l'EU AI Act l'onere della prova è sull'azienda che implementa, non sul fornitore del modello. Ogni query RAG, ogni contesto in cache e ogni tool call agentico deve essere loggato, attribuibile, sottoposto a policy e replay-able. Aggiungerlo dopo è stato l'errore più costoso del 2026.

Qualunque pattern scegliate, progettate prima l'audit trail. hegyon.ai fornisce il layer di governance tra le vostre persone, i vostri dati e i vostri modelli, enforcement delle policy, redaction dei PII, audit log completo e routing di modelli, così che la scelta architetturale resti una questione di performance e non di compliance.

Ospitato in Svizzera o on-premise. I vostri dati, le vostre regole.

← Torna a tutti gli articoli