Tag: inferenza

Certe domande nascono per caso, durante una call tecnica o nel mezzo di una demo. “Ma se il modello avesse già tutto in memoria, servirebbe ancora il retrieval?”

È cominciata così, tra una riflessione sul design di un assistant interno e l’analisi delle performance di risposta. Da lì, il passo è stato breve: fare un po’ di ricerca, testare e confrontare due approcci che stanno ridefinendo il modo in cui i modelli conversano con la conoscenza.

RAG (Retrieval-Augmented Generation) e CAG (Cache-Augmented Generation). Due strategie diverse per un obiettivo comune: aumentare la capacità dei modelli generativi di rispondere meglio, più velocemente, con più contesto. Una cerca, l’altra ricorda. Una si connette al mondo, l’altra se lo carica dentro.

Da un lato, RAG arricchisce dinamicamente le risposte di un modello cercando informazioni esterne al volo. Immaginiamolo come un instancabile bibliotecario digitale: ad ogni domanda, va a consultare un archivio vastissimo e riporta i documenti più pertinenti da fornire al modello. Dall’altro, CAG pre-carica il sapere necessario prima ancora che la domanda venga posta. È più simile a uno studente preparato che, avendo studiato e memorizzato tutto in anticipo, può rispondere all’istante senza sfogliare manuali durante l’esame.

Ho fatto un po’ di approfondiremo sul funzionamento di entrambi gli approcci, confrontandone vantaggi e limitiper capire come RAG e CAG possano essere usati in modo complementare, persino combinati, per ottenere il meglio da entrambi. Pronti a immergervi in questo viaggio tra retrieval e cache?

Procediamo con ordine, iniziando dalle basi.

Cos’è RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) è un paradigma in cui un modello di linguaggio estende la propria conoscenza ricercando informazioni aggiuntive al momento della generazione della risposta. Il flusso tipico di RAG coinvolge diversi step:

• Embedding della query: la domanda dell’utente viene convertita in una rappresentazione vettoriale (embedding), catturandone il significato semantico.

• Ricerca nel database vettoriale: questo vettore di query viene usato per cercare similarità all’interno di un database di conoscenza pre-indicizzato (spesso un vector store contenente documenti rappresentati a loro volta come vettori). Si identificano così i documenti più rilevanti rispetto alla query. In pratica, il sistema fa una ricerca semantica: non cerca solo parole chiave, ma contenuti dal significato affine alla domanda.

• Recupero dei documenti pertinenti: i migliori risultati di questa ricerca – tipicamente alcuni paragrafi o frammenti di documenti – vengono recuperati. Per migliorare la qualità, spesso si applicano algoritmi di re-ranking (riordinamento) per filtrare e ordinare i documenti in base alla loro effettiva rilevanza. Questo riduce il “rumore” e assicura che il modello riceva solo informazioni utili, mitigando il rischio di allucinazioni (ovvero dettagli inventati dovuti a contesto fuorviante).

• Costruzione del prompt con contesto: i documenti recuperati vengono poi aggiunti al prompt del modello, tipicamente formulando qualcosa come: “Ecco alcuni contenuti rilevanti: [documenti]. Ora rispondi alla domanda: [query utente]”. In questo modo, il modello dispone di conoscenza fresca e mirata mentre genera la sua risposta.

• Generazione della risposta: il modello di linguaggio (LLM) elabora il prompt aumentato dal contesto e produce una risposta che integra sia le informazioni apprese durante l’addestramento sia i dettagli pertinenti appena recuperati. In altre parole, RAG fa sì che l’LLM abbia sempre informazioni aggiornate e contestuali: il modello funge da “cervello”, mentre il modulo di retrieval funge da “memoria esterna” a cui attingere all’occorrenza.

Questo processo permette ai sistemi RAG di essere dinamici e aggiornati. Se domandiamo a un assistente RAG qualcosa su un evento accaduto dopo il periodo di addestramento del modello, esso può cercare in tempo reale tra le fonti più recenti e includerle nella risposta. In tal senso, RAG “collega” il modello a un motore di ricerca specializzato. I risultati sono spesso impressionanti: risposte contestualizzate e ricche di dettagli puntuali.

RAG però non è privo di sfide e possibili problematiche. Ogni ricerca introduce una certa latenza, poiché bisogna eseguire query sul database esterno, aspettare i risultati e comporre il prompt​: la qualità finale dipende in larga misura da ciò che viene recuperato. Se il modulo di retrieval sbaglia mira (ad esempio selezionando un documento non pertinente o obsoleto), anche la risposta del modello ne risente. Gestire un sistema RAG significa mantenere sia il modello linguistico sia l’infrastruttura di ricerca: un’architettura più complessa, con componenti da indicizzare, aggiornare e monitorare​.

Cos’è CAG (Cache-Augmented Generation)

Cache-Augmented Generation (CAG) è un approccio recente che cerca di semplificare e velocizzare l’integrazione di conoscenza nei modelli linguistici, sfruttando i loro contesti estesi e una sorta di “memoria interna” cache. L’idea di fondo è: perché andare a cercare informazioni ogni volta (come fa RAG) se possiamo caricare tutto in anticipo?. Con CAG, si mette “in cache” la conoscenza rilevante, in modo che il modello ce l’abbia già a disposizione al momento del bisogno.

Ecco come funziona, per step:

• Pre-caricamento del contesto: prima che l’utente ponga una domanda, si raccolgono tutti i documenti e le informazioni che potrebbero servire a rispondere in un dato dominio. Questa collezione di conoscenza (chiamiamola D) viene curata e ridotta a una dimensione gestibile, in modo che possa rientrare nella finestra di contesto del modello. Ad esempio, se stiamo costruendo un assistente per il supporto clienti di una certa azienda, potremmo raccogliere il manuale dei prodotti, le FAQ e le linee guida di assistenza. L’insieme D deve essere sufficientemente ristretto e rilevante (non includiamo tutto Wikipedia, ma solo ciò che serve per le query previste) e statico (cioè non cambia di continuo).

• Creazione della cache KV (Key-Value): i documenti pre-caricati vengono forniti al modello in un’unica grande sessione di inferenza. In pratica, si effettua una chiamata all’LLM passando tutto il testo di D (formattato opportunamente, ad esempio come contesto in un prompt di sistema). Il modello processa questo lungo contesto e, così facendo, costruisce delle rappresentazioni interne – i cosiddetti Key-Value pairs (KV) dell’attenzione trasformazionale – che catturano lo stato di conoscenza derivato da D. Queste KV, che sono essenzialmente i “ricordi compressi” del modello su D, vengono salvate come cache. È come se avessimo congelato lo stato mentale del modello dopo aver “letto” tutti i documenti rilevanti.

• Utilizzo della cache in inferenza: a questo punto il sistema è pronto a rispondere alle domande. Quando l’utente pone una query Q, non c’è bisogno di effettuare una ricerca esterna. Si prende la domanda, la si inserisce nel modello insieme alla cache precomputata, e si avvia la generazione​. Tecnicamente, il modello riceve Q come input successivo ai documenti D già elaborati (la cache funge da contesto persistente). Poiché il modello ha “in mente” tutta la conoscenza caricata, può rispondere immediatamente attingendo a quella base di conoscenza interna. La latenza si riduce drasticamente: l’LLM deve solo concentrarsi sul reasoning (ragionamento) e la formulazione della risposta, non sull’assimilazione di nuovi dati in quel momento.

• Reset/aggiornamento della cache: col passare del tempo o dopo diverse domande, la cache potrebbe crescere (ad esempio includendo anche le query già poste come parte del contesto interno). CAG prevede meccanismi per resettare o aggiornare la cache quando serve. Ad esempio, si può troncare la cache per rimuovere i turni di domanda-risposta passati e fare spazio a nuove query, senza dover ricaricare da zero tutti i documenti statici. Se cambia la base di conoscenza (D), bisognerà rigenerare una nuova cache aggiornata – operazione comunque eseguita di rado, ad esempio caricando il nuovo manuale se esce una versione aggiornata.

In poche parole CAG elimina completamente la fase di retrieval dinamico. Il modello opera come se sapesse già tutto ciò che gli serve, perché glielo abbiamo già fatto leggere in anticipo. Questo approccio è diventato praticabile grazie ai recenti LLM capaci di gestire contesti lunghissimi (si pensi ai modelli con finestre di 32K, 100K o persino milioni di token). Questi contesti estesi permettono di inserire decine e decine di pagine di conoscenza direttamente nel prompt. Ad esempio, Llama 3.1 70B supporta fino a 64K token e modelli come Claude 2 arrivano a 200K – abbastanza per contenere documentazione aziendale, log di supporto o database di FAQ in un colpo solo.

I benefici immediati sono evidenti: zero latenza di retrieval (non c’è attesa perché nulla viene cercato al momento), architettura semplificata (non serve un motore di ricerca interno né pipeline di indicizzazione), minori errori di contesto (si evitano problemi di selezione dei documenti, perché il contesto è predefinito e controllato)​. In scenari dove la base di conoscenza è relativamente stabile e circoscritta, CAG può risultare sorprendentemente efficace e coerente. Esperimenti e studi recenti hanno mostrato che, su certi benchmark di QA, CAG può eguagliare se non superare RAG in accuratezza, proprio perché elimina gli errori dovuti a retrieval sub-ottimali.

Il rovescio della medaglia è che CAG richiede che l’intero corpo della discussione stia nel contesto del modello e sia definito a priori. Se una query esula dal perimetro di quella conoscenza pre-caricata, il modello non potrà recuperare altro e potrebbe fallire (ad esempio, chiedendo qualcosa non contenuto nei documenti caricati, l’LLM finirà per inventare o ammettere di non sapere). Inoltre preparare la cache KV ha un costo computazionale non banale, anche se lo si fa solo una tantum. CAG brilla quindi in casi statici e ripetitivi, mentre è meno adatto in scenari dove i dati cambiano di continuo o la varietà di domande possibili è molto ampia rispetto al contesto pre-caricato.

Confronto tra RAG e CAG: vantaggi e svantaggi

Entrambi gli approcci presentano punti di forza e debolezze. La scelta dipende dal contesto d’uso e dai vincoli del progetto (dimensioni della conoscenza, necessità di aggiornamenti, requisiti di latenza, ecc.). Ecco un confronto diretto che aiuta a comprendere meglio quando conviene usare RAG o CAG.

• Gestione della conoscenza:

  • RAG: Recupera conoscenza in tempo reale da fonti esterne ampie. Ideale per attingere a database enormi o in continuo aggiornamento (es. notizie, documenti in evoluzione) senza doverli caricare integralmente nel modello. La conoscenza resta esterna al modello e viene integrata “on demand”.

  • CAG: Richiede di pre-selezionare e caricare in blocco tutti i dati rilevanti. Funziona meglio quando il dominio informativo è ben definito e limitato in dimensioni, così che tutto ciò che serve possa essere messo in cache nel modello. La conoscenza diventa parte del contesto interno del modello durante l’inferenza.

• Velocità e latenza:

  • RAG: Introduce una latenza aggiuntiva per via della fase di ricerca e recupero. Ogni domanda può richiedere centinaia di millisecondi (o più) solo per il retrieval, prima ancora di generare la risposta​. In applicazioni real-time questo può essere un collo di bottiglia, soprattutto se le query sono frequenti.

  • CAG: Offre risposte quasi istantanee poiché elimina completamente il passaggio di ricerca. In alcune implementazioni, CAG risulta decine di volte più veloce di RAG proprio grazie all’assenza di overhead di retrieval. È indicato per applicazioni dove la rapidità è critica e non si può attendere il risultato di una query esterna.

• Accuratezza e affidabilità:

  • RAG: La correttezza della risposta dipende dall’efficacia del motore di ricerca sottostante e dal ranking dei documenti. Se vengono recuperate informazioni non pertinenti o superate, il modello potrebbe fornire risposte scorrette o incoerenti con la query. C’è inoltre il rischio di mescolare contesti diversi se la query attiva documenti eterogenei (“frammentazione della conoscenza”).

  • CAG: Utilizza un contesto predefinito e validato, riducendo la probabilità di errori dovuti a informazioni irrilevanti. Le risposte tendono a essere più consistenti, perché il modello lavora su un blocco di conoscenza coeso e pensato ad hoc​. Di contro, se la base pre-caricata contiene inesattezze o manca di qualche informazione, tutti gli output ne risentiranno (il modello non può “uscire” da quella conoscenza).

• Complessità del sistema:

  • RAG: Richiede un’architettura più articolata. Bisogna predisporre un indice (ad es. un database vettoriale), gestire l’aggiornamento dei documenti, implementare meccanismi di ricerca e ranking, oltre a orchestrare il tutto con il modello generativo​. Questa complessità si traduce in maggiori costi di sviluppo e manutenzione: c’è più che un semplice LLM da tenere in funzione.

  • CAG: Snellisce l’architettura eliminando del tutto il modulo di retrieval. Servono certamente risorse computazionali robuste per gestire contesti estesi, ma la pipeline concettuale è più lineare (carica contesto una tantum → genera risposte)​. Meno componenti significa anche meno punti di guasto: ad esempio, un sistema CAG non rischia errori dovuti a un indice non aggiornato o a una chiamata API esterna fallita.

• Casi d’uso ideali:

  • RAG: È la scelta obbligata quando la base di conoscenza è enorme, volatile o in costante crescita – pensiamo a motori di ricerca web, assistenti su contenuti di attualità, o knowledge base aziendali con migliaia di documenti che cambiano ogni giorno. RAG eccelle anche quando il modello deve poter rispondere a domande completamente nuove attingendo da fonti eterogenee non prevedibili a priori. In breve, ogni volta che non possiamo caricare tutto il sapere dentro il modello, RAG viene in nostro soccorso.

  • CAG: Brilla in scenari con conoscenza delimitata e relativamente stabile. Ad esempio, un chatbot di supporto per un prodotto specifico, dove l’insieme di possibili domande è noto e coperto da un manuale di poche centinaia di pagine; oppure un assistant interno che deve fare riferimento a un corpus statico (policy aziendali, procedure interne, manuali tecnici) che viene aggiornato raramente. In tali casi, pre-caricare queste informazioni e tenerle in cache consente risposte rapidissime e affidabili, senza l’onere di mantenere un sistema di ricerca complesso.

Praticamente non c’è un “vincitore” assoluto: RAG e CAG sono due strumenti diversi per esigenze diverse. Anzi possono (ed in molti casi devono) persino lavorare insieme in architetture ibride.

Esempi pratici d’uso

Per concretizzare le differenze che ho descritto (e nemmeno tutte), ho buttato giù alcuni esempi di applicazione su cui ultimamente ho lavorato differenziando l’utilizzo di RAG o CAG (o entrambi) e come possano essere utilizzati.

• Chatbot su knowledge base statiche: un assistente virtuale per le FAQ di un sito web o il manuale di un elettrodomestico. Le domande degli utenti rientrano tipicamente in un ambito ristretto (il dominio del prodotto). Qui CAG è una scelta eccellente: il manuale e le FAQ possono essere caricati interamente nel contesto del modello, che fornirà risposte immediate e precise senza dover cercare altrove. La coerenza è alta, perché il modello risponde solo in base a informazioni ufficiali pre-caricate, eliminando deviazioni. Se però la knowledge base è in continuo aggiornamento, si potrebbe adottare un approccio ibrido: rigenerare la cache CAG ogni giorno con le nuove informazioni, o integrare una componente RAG per gestire eventuali domande fuori scope.

• Assistenti interni aziendali: un assistente AI che aiuta i dipendenti a reperire procedure, policy HR, linee guida legali, ecc. In un’azienda grande, questi documenti possono essere numerosi e aggiornati periodicamente. Si può adottare RAG per mantenere l’assistente sempre aggiornato: ogni volta che un dipendente chiede qualcosa, l’LLM recupera gli ultimi documenti rilevanti dal repository aziendale (intranet, database documentale) e formula la risposta. Ciò garantisce che anche se ieri è uscita una nuova procedura, oggi l’assistente la possa già citare. In aziende più piccole, o per ambiti specifici (es. documentazione di onboarding), CAG può invece fornire maggiore velocità: caricando in anticipo tutto il manuale dipendente e le policy, l’assistente risponde in un lampo, risultando molto reattivo nelle conversazioni.

• Code assistant (assistenti per programmatori): un assistente AI che aiuta a scrivere codice o risolvere bug. Deve poter accedere a documentazione API, esempi di codice, e magari al codice base del progetto. Due strategie emergono: con RAG, l’assistente potrebbe effettuare ricerche nel repository del codice per trovare le funzioni o i file pertinenti alla domanda (es. “cerca dove è definita questa classe e includi quel snippet come contesto”). Oppure cercare nella documentazione ufficiale online per fornire dettagli sull’uso di una libreria. Con CAG, se il progetto è di dimensioni moderate, si potrebbe precaricare l’intero codice (o i componenti chiave) nella finestra di contesto: l’LLM avrebbe così “letto” tutto il codice base e potrebbe ragionare sulle domande del programmatore conoscendo già l’architettura del software. In pratica, diventerebbe un collega sviluppatore che conosce a memoria il codice. In casi reali, una combinazione è ideale: RAG per cercare informazioni su librerie esterne o porzioni di codice molto grandi, e CAG per mantenere in cache i file fondamentali con cui l’assistente interagisce continuamente.

• Knowledge base dinamiche (news, ricerche scientifiche, ecc.): per assistenti personali che ti aggiornano sulle notizie quotidiane, o un sistema che risponde a domande su ricerche scientifiche recentissime, la conoscenza è troppo ampia e in costante rinnovo. Qui RAG è praticamente d’obbligo. Un assistant sulle news userà RAG per cercare gli articoli del giorno relativi alla domanda posta (es. “ultimi sviluppi del mercato X”) e offrirà un riassunto pescando da più fonti. Un sistema CAG in questo scenario rischierebbe di essere obsoleto non appena la cache viene caricata, a meno di aggiornarla ogni minuto (cosa impraticabile). D’altro canto, RAG ben progettati possono includere tecniche di re-ranking e filtri temporali per assicurare che le fonti recuperate siano rilevanti e recenti. L’utente finale ottiene così risposte attuali e dettagliate, con la consapevolezza delle fonti utilizzate.

Modelli ibridi e tecniche emergenti

È chiaro che RAG e CAG non si escludono a vicenda, come ho detto, anzi possono essere usati in tandem per sfruttare il meglio di ciascuno. Immaginiamo, per esempio (già descritto brevemente sopra), un assistente intelligente per una grande azienda: il volume di conoscenza totale intranet, documenti, wiki, ecc.) è enorme, ma un singolo dipartimento ha una documentazione specifica più limitata. Un approccio ibrido potrebbe funzionare così: il sistema usa RAG per fare una prima selezione di documenti rilevanti tra migliaia (es. cerca tutte le policy attinenti alla domanda dell’utente), poi prende questi risultati (diciamo i top 5 documenti trovati) e li pre-carica in un contesto esteso facendone una sorta di mini-cache CAG per quel turno di conversazione. In seguito, l’LLM risponde sfruttando questa cache locale, magari permettendo anche domande di follow-up senza dover rifare la ricerca da zero. In pratica, RAG fornisce il perimetro del sapere e CAG offre il ragionamento veloce all’interno di quel perimetro. Questo può essere utile anche per il multi-hop reasoning: se per rispondere a una domanda servono informazioni provenienti da diversi documenti, RAG li recupera tutti e CAG – avendoli in memoria contemporaneamente – può sintetizzare una risposta unitaria, cosa difficile se le fonti fossero usate una alla volta.

Un altro ambito di complementarità è la gestione sessione in chatbot conversazionali. Un sistema potrebbe usare RAG per recuperare conoscenza all’avvio di una conversazione o al primo quesito su un certo argomento; dopodiché le informazioni chiave vengono mantenute nel contesto (cache) per i turni successivi, evitando ulteriori query a meno che non si cambi argomento. Questo approccio misto riduce le chiamate di retrieval e quindi la latenza, senza rinunciare alla flessibilità di attingere a nuovi dati quando necessario.

Oltre alla combinazione RAG+CAG, vale la pena menzionare alcune tecniche emergenti che rafforzano questi sistemi:

• Re-ranking avanzato: Già citato in ambito RAG, il re-ranking si sta evolvendo con modelli di apprendimento dedicati (es. cross-encoder neurali) che ordinano i documenti non solo per somiglianza con la query ma per effettiva probabilità di contenere la risposta. Questo migliora drasticamente la qualità del contesto fornito al modello generativo. Un RAG con un buon re-ranking può permettersi di recuperare più documenti (per sicurezza) sapendo poi filtrare quelli utili. Anche in sistemi ibridi, un re-ranking può selezionare quali documenti passare alla fase CAG.

• Segmented summarization (riassunto segmentato): Quando si hanno testi lunghissimi, una strategia è segmentarli in parti più piccole, riassumere ciascuna parte separatamente, e infine combinare i riassunti. Questa tecnica è preziosa se la finestra di contesto del modello non è abbastanza grande da contenere tutto il testo originale. In un pipeline ibrido, si potrebbe usare un modulo RAG o un modulino di summarization per accorciare i documenti (pur mantenendo i concetti chiave) prima di caricarli nella cache CAG. Così, anche se un documento eccede i limiti, il sistema lo condensa e riesce comunque ad includerlo. Inoltre, la summarization segmentata aiuta a mantenere la coerenza: suddividendo per argomento, ci si assicura che ogni parte sia compresa bene dal modello, riducendo il rischio che informazioni importanti vadano perse o che il modello si confonda a causa di dettagli superflui. È una specie di divide et impera applicato alla comprensione di testi lunghi.

• Modelli ibridi neuro-simbotici: Uno scenario in esplorazione è combinare le capacità neurali dei LLM con strutture più simboliche o basi di conoscenza strutturate. Ad esempio, un sistema potrebbe usare RAG per interrogare una base di conoscenza grafica o un database SQL per informazioni factuali precise, mentre usa CAG per mantenere nel contesto altri dati testuali. Oppure, come proposto da alcuni ricercatori, utilizzare RAG per la conoscenza e un modello specializzato separato per la reasoning chain, orchestrando i due. Anche se andiamo oltre lo scopo di questo articolo, queste idee mostrano come RAG e CAG siano tasselli componibili in architetture più complesse, non silos isolati.

La complementarità tra RAG e CAG apre possibilità interessanti. Possiamo progettare sistemi su misura, scegliendo di volta in volta l’approccio più adatto o fondendoli in soluzioni multi-fase. Ad esempio, un assistant potrebbe usare RAG per “documentarsi” su un argomento e poi passare in modalità CAG per discussioni approfondite su quanto appreso, fornendo sia freschezza di informazioni che fluidità conversazionale.

Cercare o Ricordare, questo è un dilemma? No.

Il Retrieval-Augmented Generation e il Cache-Augmented Generation rappresentano due elementi interessanti di progettazione dei sistemi AI conversazionali e di question answering: da una parte la potenza di un modello linguistico connesso a un vasto mondo di informazioni esterne (RAG), dall’altra l’efficienza di un modello che porta con sé, nel proprio “zaino” contestuale, tutto il sapere necessario (CAG).

Questi approcci, lungi dall’essere mere sigle, incarnano a mio avviso filosofie diverse: cercare vs ricordare. RAG eccelle , come abbiamo visto, nel permettere ai modelli di restare aggiornati e versatili, ampliando continuamente i propri orizzonti tramite il retrieval. CAG, al contrario, trae forza dalla continuità interna, trasformando un LLM in una sorta di enciclopedia specialistica portatile, rapida e focalizzata. I loro vantaggi e svantaggi si bilanciano a vicenda – dove uno è debole, spesso l’altro è forte. Per questo, più che competere, RAG e CAG possono collaborare: uniti in architetture ibride, promettono sistemi AI capaci sia di imparare all’istante sia di rispondere in un lampo.

Ci deve implementare deve aver chiaro quindi il punto: non esiste una soluzione unica per l’generazione aumentata da AI. Bisogna valutare la natura dei dati e delle domande del proprio dominio, il processo e il risultato atteso. Se il vostro assistant deve sapere sempre l’ultima novità, RAG sarà il vostro alleato fedele. Se invece avete un tesoro di conoscenza ben delineato da sfruttare fino in fondo, CAG vi darà prestazioni sbalorditive. E se volete il meglio dei due mondi, sperimentate con approcci ibridi, re-ranking intelligente e tecniche di summarization – i mattoni ci sono, tocca a voi combinarli con creatività.

La sinergia tra recupero e memoria interna sta ridisegnando il modo in cui i modelli dialogano con la conoscenza. Siamo solo agli inizi di progetti di questo tipo. Proprio come un bravo artigiano digitale, possiamo ora scegliere se dare al nostro modello un potente motore di ricerca, una memoria enciclopedica pre-caricata, o magari entrambi. Il futuro dell’AI conversazionale sarà scritto da chi saprà orchestrare al meglio queste possibilità, creando esperienze utente sempre più fluide, informate e straordinariamente veloci. In fondo, che si tratti di sfogliare un libro al volo o di ricordare tutto a memoria, l’obiettivo finale è lo stesso: fornire all’utente la miglior risposta possibile, nel minor tempo possibile. RAG e CAG sono due strade diverse per raggiungere questa vetta – sta a noi decidere quale sentiero, o combinazione di sentieri, prendere.