RAG, CAG e KAG: come scegliere l’accesso alla conoscenza

Un team vuole usare un assistente AI per consultare la documentazione del proprio software. All’inizio gli chiede come attivare una funzione. Poi arriva una domanda più impegnativa: «Possiamo dismettere API 2 senza interrompere le integrazioni ancora in uso?».

Il manuale più recente può spiegare benissimo la nuova funzione e ignorare un vecchio connettore ancora attivo. Un assistente che recupera soltanto quel manuale ha materiale pertinente, ma non ha ancora gli elementi per decidere una dismissione.

È da questa differenza che partirei per scegliere fra RAG, CAG e KAG. Recuperare testi, riutilizzare un corpus nel contesto e interrogare relazioni risolvono problemi diversi. La scelta dipende da quali informazioni servono alla risposta e da come le manterremo aggiornate.

Un piccolo inventario, due domande

Usiamo un esempio di un servizio software con esportazioni e integrazioni. Questi sono i dati disponibili:

Alla domanda «Che cosa serve per attivare Export 5?» possiamo ricostruire il percorso Export 5 → API 3 → Auth 2 e trovare le istruzioni corrispondenti.

Alla domanda «Possiamo spegnere API 2?» la riga decisiva è quella del connettore storico. Finché resta attivo, la risposta è no. Se non conosciamo la copertura dell’inventario, l’assenza di altri connettori nei risultati non autorizza a concludere che non esistano.

Il primo lavoro è trovare e collegare informazioni pertinenti. Il secondo richiede anche sapere quanto possiamo fidarci dell’elenco delle dipendenze. Aggiungere un grafo a dati incompleti conserva il problema sotto una forma diversa.

RAG: scegliere che cosa leggere a ogni domanda

Retrieval-Augmented Generation significa recuperare informazioni esterne e fornirle al modello mentre prepara la risposta. In una pipeline documentale, i testi vengono suddivisi in passaggi, spesso chiamati chunk, e resi ricercabili. Alla domanda dell’utente, il sistema seleziona i passaggi utili e li inserisce nel contesto: il materiale che il modello può usare in quella richiesta. È il meccanismo di base introdotto dal paper RAG.

Il recupero può cercare parole e identificatori, confrontare rappresentazioni numeriche del significato — gli embedding — oppure combinare i due approcci. Per una sigla esatta come API 2, la ricerca lessicale è una baseline sensata. Per una domanda formulata con termini diversi dal manuale, quella semantica può aiutare.

Nel nostro esempio, una ricerca su Export 5 dovrebbe trovare il manuale della versione corretta e la specifica di API 3. Un sistema può fare più ricerche successive per completare la catena. I permessi dell’utente e la versione del software devono guidare la selezione dei documenti.

Sceglierei questa strada come primo confronto quando i documenti sono numerosi, cambiano spesso o ogni persona può leggerne soltanto una parte. La selezione riduce il materiale da inviare al modello, ma diventa anche un punto da controllare: se manca il connettore storico, la risposta sulla dismissione può essere sbagliata.

Ho dedicato al recupero del documento errato un laboratorio RAG separato. Qui la domanda viene prima: il risultato atteso è una spiegazione trovata nei testi, un elenco completo o una verifica delle dipendenze?

CAG: preparare il corpus prima delle domande

Nel paper di Cache-Augmented Generation, CAG carica in anticipo un insieme circoscritto di documenti nel contesto del modello e ne riutilizza lo stato di elaborazione. La domanda viene aggiunta a quel contesto già preparato, senza un recupero documentale per ciascuna richiesta.

La KV cache conserva i vettori key e value calcolati durante l’elaborazione dei token. Riutilizzarli evita di rifare parte del lavoro sul prefisso già letto; i nuovi token continuano comunque a usare il contesto precedente. La memoria occupata cresce con la sequenza. È stato di inferenza, distinto dai pesi appresi dal modello: caricare un manuale in cache non significa addestrarlo. La spiegazione di Hugging Face chiarisce questo meccanismo.

CAG merita una prova quando molte domande riguardano lo stesso corpus, abbastanza piccolo da entrare nel contesto disponibile e abbastanza stabile da essere riutilizzato. Per esempio, la documentazione di una singola versione destinata a un gruppo con gli stessi diritti di accesso.

La cache non aumenta lo spazio di contesto e non rende gratuito leggere un corpus lungo. Nelle tabelle del paper, il vantaggio cambia con il dataset e con la baseline: su HotpotQA-large, la pipeline RAG che recupera cinque passaggi con BM25, una ricerca lessicale, ottiene un BERTScore superiore a CAG. BERTScore misura la somiglianza semantica con una risposta di riferimento. Sono confronti su corpus selezionati e Llama 3.1 8B, utili per progettare una prova, non per prevedere il risultato su una knowledge base aziendale.

CAG e prompt caching sono scelte differenti

Il prompt caching offerto da un provider può riutilizzare un prefisso ripetuto anche in una pipeline RAG: istruzioni stabili prima, documenti recuperati dopo. Le condizioni di riuso dipendono dall’implementazione; per esempio, la documentazione di Anthropic descrive corrispondenza del prefisso e durata della cache.

CAG decide di precaricare il corpus. Il caching del prefisso ottimizza il riuso di una parte del prompt. Nel confronto economico includerei anche un RAG con il caching disponibile, altrimenti rischiamo di attribuire all’architettura il vantaggio di un’ottimizzazione condivisa.

KAG: rendere esplicite le relazioni

Un knowledge graph rappresenta entità e relazioni: Export 5 usa API 3; API 3 richiede Auth 2. Le etichette hanno un significato definito e i nodi identificano gli elementi, comprese le loro versioni.

Knowledge Augmented Generation, nel lavoro KAG di OpenSPG, è un framework specifico che collega questa rappresentazione ai passaggi dei documenti. Un planner traduce la domanda in operazioni; un solver le esegue, combinando recupero sul grafo, ricerca testuale e operazioni come ordinamenti o calcoli. KAG continua quindi a recuperare informazioni.

Per rispondere su Export 5, il percorso diventa leggibile: trova la funzione, segui la relazione verso API 3, poi quella verso Auth 2 e recupera i testi che spiegano i requisiti. Per la dismissione di API 2, si cercano invece gli elementi che ne dipendono ancora.

Questa struttura può essere utile quando le domande attraversano molti documenti e le relazioni contano più della somiglianza fra frasi. Il lavoro aggiuntivo comprende definire lo schema, riconoscere la stessa entità in testi diversi e conservare il legame con le fonti. Anche il piano generato può contenere errori: il paper ne discute alcuni insieme ai costi delle chiamate intermedie.

Prima di estrarre un nuovo grafo, però, guarderei l’inventario esistente. Se componenti, versioni e dipendenze sono già in un database attendibile, una query SQL o un’API di dominio può fornire la catena direttamente. L’assistente può usarne il risultato per spiegarla. Ricostruire dagli stessi dati un secondo inventario introduce un altro oggetto da sincronizzare.

GraphRAG e LightRAG: altri impieghi del grafo

La Global Search di Microsoft GraphRAG affronta soprattutto domande sull’insieme dei documenti. Prepara sintesi di comunità, cioè gruppi di entità collegate, e le usa per costruire una risposta complessiva. Può aiutare a cercare problemi ricorrenti nei rapporti di assistenza; non è lo stesso compito di elencare tutti i componenti che usano API 2.

LightRAG combina recupero di entità e relazioni con ricerca vettoriale. È un’altra architettura da confrontare se le domande giustificano quel lavoro di preparazione. KAG, GraphRAG e LightRAG adottano meccanismi differenti: scegliere “un grafo” lascia ancora aperta una parte importante del progetto.

Il costo emerge anche quando cambia qualcosa

Nel caso CAG, quante domande riutilizzano lo stesso corpus prima che diventi vecchio? Una documentazione preparata una volta e consultata spesso ha un’economia diversa da una cache ricostruita dopo ogni modifica.

Per confrontare i costi fisserei lo stesso periodo e lo stesso insieme di richieste. Sommerei, in euro, preparazione, aggiornamenti, esecuzione delle richieste e infrastruttura necessaria a conservare la cache. Per RAG includerei indicizzazione e recupero; per il grafo, estrazione e manutenzione dei dati derivati. Il totale del periodo è confrontabile fra le alternative; per ottenere il costo medio per richiesta, dividerei ogni totale per il medesimo numero di richieste. Registrerei anche quante domande riutilizzano ciascuno stato valido del corpus prima di una modifica, scadenza o revoca.

Una revoca di accesso rende visibile il problema. Se un documento è già dentro una cache condivisa, nasconderne il collegamento nell’interfaccia lascia ancora il contenuto disponibile al modello. Anche una sintesi o una relazione estratta può conservarne informazioni. L’autorizzazione deve valere sul materiale effettivamente usato per rispondere, oltre che sui file mostrati all’utente. Il security trimming documentato da Microsoft mostra il ruolo dei filtri applicati alle query; identità e autorizzazione restano responsabilità dell’applicazione.

Per una prova iniziale preparerei questa scheda:

Per la prova di omissione conserverei l’inventario completo come riferimento e fornirei al sistema una vista priva del connettore, senza dichiararlo dismesso. La risposta attesa è «informazioni insufficienti per autorizzare il ritiro», finché manca una fonte che attesti la copertura dell’inventario.

Per la revoca, oltre alla risposta leggerei le tracce di esecuzione: identificativi dei documenti selezionati, versione del corpus o della cache, relazioni e sintesi fornite al modello. Questo permette di controllare quali dati sono rimasti disponibili, senza registrare nei log il loro contenuto riservato.

Terrei fisse le domande e partirei dalla soluzione più semplice adatta ai dati: query sull’inventario, oppure recupero documentale. Aggiungerei CAG o il grafo dove quella baseline incontra un limite preciso. In questo modo la prova può anche concludersi mantenendo l’architettura iniziale.

Quali progetti open source valutare

Il confronto dei repository è aggiornato al 24 ottobre 2026 e considera licenze, release, documentazione e interventi recenti. Per un’adozione guarderei anche chi mantiene le integrazioni e come si aggiornano i dati: il numero di stelle dice poco su questi due aspetti.

Haystack e LlamaIndex sono i primi candidati che valuterei per costruire la baseline documentale. LightRAG entra nel confronto se le relazioni migliorano davvero le risposte richieste. Gli altri repository restano utili per capire e sperimentare i metodi, con impegni di manutenzione differenti.

Nel nostro esempio API 2 serve ancora al connettore storico. È quel vincolo che l’assistente deve portare alla luce, con la sua fonte, prima che il team pianifichi la dismissione.