RAG Archives - Fabio Lalli

1 Marzo 20261 Marzo 2026TECH & BUSINESS

LocalAI: la guida per costruire un ecosistema di AI privata, dagli LLM agli agenti con memoria

Per mesi ho visto ripetersi la stessa scena: entusiasmo enorme sull’AI generativa, proof-of-concept ovunque, e poi, quando arriva il momento di portare l’AI dentro processi reali, una domanda che taglia corto: “Dove vivono i dati?”. Subito dopo ne arriva un’altra: “Quanto ci costerà davvero?”. E subito dopo la terza: “Cosa succede se domani cambia un pricing, un accesso, una policy, un modello?”.

È da questa triade (dati, costi, dipendenza) che nasce l’idea della guida su LocalAI. Non come esercizio tecnico, ma come scelta di architettura. E, in fondo, come scelta culturale: riportare l’intelligenza sotto il controllo di chi la usa.

“Guida completa a LocalAI, LocalAGI e LocalRecall” è pensata per costruire un ecosistema di Intelligenza Artificiale privato su hardware consumer: dal server di inferenza agli agenti autonomi, passando per la memoria. Ho provato a scrivere la risorsa che avrei voluto avere io: un percorso unico, pratico, con un filo logico, capace di trasformare pezzi sparsi in una stack coerente.

Il punto di partenza è LocalAI: un server di inferenza che espone API compatibili con OpenAI e permette di eseguire modelli (testo, immagini, audio, embeddings) sul proprio hardware. La compatibilità non è un dettaglio: significa poter “sganciare” un’app dal cloud e reindirizzarla in locale con modifiche minime.

Ma un sistema utile non è solo un modello che risponde. Serve memoria, serve contesto, serve recupero delle informazioni, serve continuità. Per questo la guida si estende a LocalRecall: lo strato di memoria che implementa RAG (retrieval-augmented generation), cioè la capacità di interrogare una base di conoscenza esterna e alimentare il modello con informazioni pertinenti, riducendo errori e allucinazioni e aumentando la qualità delle risposte.

E poi c’è l’ultimo salto: dagli LLM agli agenti. Qui entra LocalAGI, pensato per creare e orchestrare agenti autonomi (anche in modalità no-code/low-code), collegandoli al “cervello” (LocalAI) e alla “memoria” (LocalRecall). Quando questa triade funziona, non stai più giocando con una chat: stai costruendo un sistema capace di fare piani, eseguire task, usare strumenti, ricordare, migliorare.

La struttura del libro riflette questa progressione, perché l’AI locale non è un singolo componente: è un’architettura. Nella prima parte si costruiscono le fondamenta (installazione, modelli, backend, funzionalità principali e ottimizzazioni, con attenzione alla sicurezza). Nella seconda si costruisce la memoria (LocalRecall e le scelte di storage, dalla semplicità alla scalabilità). Nella terza si costruisce l’intelligenza attiva (LocalAGI e la logica agentica). E nella quarta si scende su casi d’uso e appendici operative.

Un aspetto che ho voluto rendere esplicito è che “locale” non significa “romantico”. Significa pragmatico:

Privacy: i dati non devono lasciare la macchina, quando non è necessario.
Costi: sposti spesa da OPEX variabile (token) a CAPEX + energia, rendendo il budget più prevedibile.
Personalizzazione: puoi scegliere modelli, configurazioni, pipeline, senza vendor lock-in.
Resilienza: puoi far funzionare parti del sistema anche offline o in rete chiusa.

E poi c’è una parola che spesso manca nel dibattito: responsabilità. Avere controllo significa anche doversi occupare di sicurezza: proteggere endpoint, chiavi, accessi, permessi, logging. La guida insiste su questo perché l’AI locale non è “auto-magicamente” sicura: è solo più governabile, se la governi.

Per chi è questa guida?

Per chi sviluppa e vuole un’alternativa seria al cloud. Per chi fa IT e deve ragionare su TCO e compliance. Per chi costruisce prodotti e vuole embedded AI senza consegnare tutto a terzi. Ma anche per chi, semplicemente, vuole capire la stack: cosa sono i backend di inferenza, perché esistono gli embeddings, come si fa RAG, come si orchestrano agenti, e quali trade-off stai accettando quando dici “usiamo un LLM”.

Nella Nota dell’Autore ho scritto una cosa che per me è centrale: questi strumenti non sono solo strumenti tecnici. Rappresentano una filosofia, accessibilità, trasparenza, controllo, e un invito a contribuire a un ecosistema open-source che sta accelerando a vista d’occhio. La guida è un punto di partenza, non un punto di arrivo. Ma è il punto di partenza che mancava: chiaro, pratico, completo.

30 Luglio 20257 Agosto 2025AI & GENAI

Context Engineering: la nuova frontiera nel design dei sistemi AI

Negli ultimi anni abbiamo assistito all’ascesa fulminea del prompt engineering, l’arte di “parlare bene” a un modello linguistico per fargli fare ciò che vogliamo. Per un periodo sembrava quasi una magia esoterica: bastava scrivere istruzioni creative in linguaggio naturale e l’AI avrebbe fatto il resto.

Col passare del tempo i limiti di questo approccio sono emersi chiaramente. Un singolo prompt, per quanto brillante, non può compensare la mancanza di una struttura solida attorno al modello.

Oggi, chi sviluppa applicazioni basate su LLM (Large Language Model) sa che il vero campo di gioco è un altro: il contesto.

Progettare (bene) il contesto è infatti l’unico modo per costruire prodotti AI robusti e scalabili. È qui che entra in scena il Context Engineering, una disciplina emergente che rappresenta la nuova frontiera nel design dei sistemi basati su AI.

Dal Prompt Engineering al Context Engineering

Solo due righe per ricordarci brevemente da dove siamo partiti. Nel 2023 il prompt engineering ha avuto il suo momento di gloria: erano di dominio pubblico annunci di lavoro per prompt engineer con stipendi da capogiro, e spopolavano corsi su come “parlare con ChatGPT”. Chiunque poteva improvvisarsi prompt engineer digitando richieste ingegnose in una chat e vantarsi delle risposte ottenute. Si parlava persino di vibe coding, un misto di intuito e tentativi ripetuti sul playground di ChatGPT, come se programmare si riducesse a trovare la “vibrazione” giusta con il modello. Questo approccio funzionava, ma solo finché i casi d’uso rimanevano esercizi da hackathon o demo poco più che giocattoli.

Quando però si è passati a costruire veri prodotti basati su LLM, in contesti reali e su scala enterprise, i limiti del semplice prompt engineering sono diventati evidenti. Le applicazioni AI complesse, come agenti autonomi che svolgono compiti nel mondo reale, o piattaforme aziendali che integrano modelli generativi, non possono basarsi sul copywriting creativo delle prompt. Non basta più scrivere istruzioni eleganti: serve un cambio di paradigma. È qui che nasce il concetto di context engineering, un’evoluzione che sposta l’attenzione dalla formulazione della domanda (prompt) alla progettazione di tutto ciò che il modello deve “sapere” e avere a disposizione per fornire risposte utili e affidabili.

In altre parole, il context engineering supera il prompt engineering perché non si limita a cosa chiedere al modello, ma governa come e con quali informazioni glielo si chiede. Un famoso esperto ha riassunto questa differenza così: “Prompt engineering è ciò che fai dentro la finestra di contesto; context engineering è decidere cosa riempie quella finestra”. Mentre il prompt engineer cerca di azzeccare la frase perfetta da inserire in un prompt box, il context engineer progetta l’intero “mondo” in cui il modello opera. Se il prompt engineering è l’arte di scrivere un’istruzione brillante, il context engineering è l’ingegneria che stabilisce cosa succede prima e dopo quell’istruzione, cosa il modello dovrà ricordare, quali dati recuperare, quali strumenti utilizzare e come incastonare il tutto nel flusso logico dell’applicazione.

Da questa prospettiva, il prompt engineering diventa un sottoinsieme del context engineering. Non sono due pratiche in competizione, ma livelli diversi dello stesso gioco: il prompt giusto è importante, ma da solo conta poco se viene “annegato” in mezzo a migliaia di token di contesto irrilevante o mal strutturato. Ecco perché oggi le competenze richieste vanno oltre la semplice capacità di promptare: servono figure in grado di curare, gestire e ottimizzare tutto il contesto fornito ai modelli AI.

Cosa si intende per Context Engineering?

Il termine Context Engineering definisce la disciplina di progettare e costruire sistemi dinamici che forniscono al modello AI le informazioni giuste, nel formato giusto, al momento giusto, in modo che possa svolgere un compito nel modo migliore possibile. Per comprendere appieno questo concetto, dobbiamo ampliare la nozione di “contesto”.

Non parliamo più di un singolo prompt statico, ma di tutto ciò che il modello vede prima di generare una risposta. Il contesto è un ecosistema informativo completo, che può includere vari elementi tra cui:

Istruzioni di sistema (o system prompt): regole e linee guida iniziali che definiscono il comportamento dell’AI (es. stile di risposta, persona da impersonare, vincoli da rispettare).
Prompt utente: la domanda o richiesta immediata posta dall’utente.
Stato e memoria a breve termine: lo storico della conversazione corrente (prompt e risposte recenti) che l’AI ricorda durante l’interazione.
Memoria a lungo termine: conoscenza persistente accumulata in sessioni precedenti, ad esempio preferenze dell’utente, dati contestuali importanti o riassunti di conversazioni passate.
Informazioni esterne recuperate: dati aggiuntivi ottenuti al volo da fonti esterne (Retrieval-Augmented Generation), come documenti aziendali, database, risultati di ricerche o API, rilevanti per la richiesta corrente.
Strumenti disponibili: funzionalità che l’AI può invocare (ad esempio chiamate a calcolatori, servizi esterni, funzioni specifiche) per eseguire compiti o reperire informazioni.
Formato di output atteso: indicazioni sul formato con cui il modello deve restituire la risposta (ad esempio uno schema JSON, un elenco puntato, un tono formale vs informale, ecc.).

Come si vede, il contesto è molto più di un semplice prompt: è l’insieme di tutti i fattori che influenzano le decisioni del modello. Fare context engineering significa dunque costruire e gestire attivamente questo ecosistema informativo, anziché lasciare il modello da solo con una breve istruzione sperando che “indovini” ciò che deve fare. Non basta “mettere più roba nel prompt” indiscriminatamente; occorre fornire all’AI esattamente i dati e gli strumenti di cui ha bisogno, eliminando il superfluo.

Un “context engineer” (ammesso che abbia senso un etichetta del genere) svolge diversi compiti chiave:

Curare le informazioni: decidere quali documenti, dati o conoscenze fornire al modello per uno specifico task, selezionando solo quelle rilevanti (garbage in, garbage out!).
Strutturare il flusso: organizzare il contesto in un ordine logico ottimale – ad esempio predisponendo prima le istruzioni di sistema, poi eventuali dati recuperati, quindi il prompt utente – così che l’AI riceva un input contestuale chiaro e prioritizzato.
Comprimere e sintetizzare: riassumere o suddividere informazioni troppo estese per rientrare nei limiti di token della finestra di contesto, preservando però i dettagli cruciali. Ciò implica progettare memorie riassuntive e tecniche di chunking dei dati per non sforare i limiti senza perdere contenuto importante.
Integrare strumenti: fornire al modello accesso a funzioni esterne (tool API) quando necessario, e far sì che i risultati di questi tool vengano riportati nel contesto in formati facilmente digeribili dall’AI. Ad esempio, se l’LLM deve fare calcoli o ricerche sul web, il context engineer predispone queste possibilità e inserisce le risposte ottenute nel contesto in forma sintetica.
Definire protocolli chiari: stabilire formati di input/output strutturati (come risposte in JSON, markdown, DSL personalizzati) che il modello possa interpretare senza ambiguità. Questa “impalcatura” aiuta l’AI a capire esattamente come presentare i risultati.
Monitorare ed ottimizzare: valutare le prestazioni dell’AI in base al contesto fornito, identificando problemi come context dilution (contesto irrilevante che distrae il modello) o informazioni mancanti, e iterare di conseguenza. In altre parole, il context engineer si assicura che l’AI non “perda il filo” e che i suoi output restino pertinenti man mano che le interazioni proseguono.

Tutto questo ha un unico scopo finale: mettere il modello nella condizione di generare l’output corretto in modo plausibile e affidabile. Il context engineering, dunque, è un approccio ingegneristico completo alla progettazione di sistemi AI: non si limita a come formulare le istruzioni, ma si occupa di costruire l’intera architettura informativa e funzionale che sostiene l’intelligenza artificiale.

Una metafora efficace è quella proposta da alcuni esperti: se il prompt engineering è come fare la domanda giusta a un esperto, il context engineering è come preparare la biblioteca perfetta per quell’esperto, scegliendo in anticipo i libri e gli strumenti che potrà consultare mentre risponde. Ecco perché viene definito la “nuova architettura invisibile” dei software AI-ready: lavora dietro le quinte, ma determina in larga parte il successo di un sistema AI.

Perché il Context Engineering è fondamentale (e il prompt da solo non basta)

Man mano che i modelli di AI diventano più capaci, il fattore determinante per ottenere risultati utili non è tanto “spremere” maggiore intelligenza dal modello stesso, quanto assicurarsi che il modello abbia tutto il necessario per funzionare al meglio. In altri termini, la qualità del risultato dipende in gran parte dalla qualità del contesto fornito. Lo si è visto chiaramente con i nuovi agenti AI: nella maggior parte dei casi in cui un agente basato su LLM fallisce o produce output scadenti, la colpa non è di un’improvvisa stupidità del modello, ma di un contesto inadeguato o mal costruito.

Pensiamoci: un LLM non può “leggere nel pensiero”. Se omettiamo dal contesto informazioni cruciali per il task, il modello semplicemente non saprà ciò che non gli abbiamo detto. Allo stesso modo, se gli passiamo informazioni superflue o disorganizzate, rischiamo di confonderlo: prompt eccellenti sepolti sotto montagne di dettagli irrilevanti non daranno comunque buoni risultati. Formato e pertinenza contano quanto il contenuto: inviare dati non strutturati o errori di formattazione nel contesto può portare l’AI a fraintendere la richiesta o a ignorare istruzioni importanti.

Le risposte sbagliate o allucinazioni di un modello sono spesso sintomi di questi problemi di contesto, non difetti intrinseci del motore di AI. Ad esempio, molte aziende che sperimentavano con chatbot interni hanno scoperto che gli insuccessi non dipendevano dal fatto che “il modello GPT non è abbastanza smart”, bensì dal fatto che non avevano progettato bene il contesto attorno al modello. Magari fornivano troppe informazioni non rilevanti (diluzione del contesto), oppure troppo poche informazioni (lacune contestuali), oppure ancora presentavano i dati in modo confuso e poco machine-friendly.

Alcune domande utili da porsi in caso di output insoddisfacenti sono proprio: Abbiamo passato al modello tutte le informazioni necessarie, senza lasciarne indietro di fondamentali? Oppure lo abbiamo sommerso di testo inutile che ne ha “annacquato” la concentrazione? Abbiamo formattato i dati in modo chiaro e strutturato, o solo in prosa libera difficile da interpretare? Stiamo gestendo correttamente la memoria delle interazioni precedenti?. Spesso, analizzando questi aspetti, ci si accorge che l’errore è a monte: non è l’AI a non funzionare, ma il sistema intorno ad essa che non le ha fornito il giusto contesto.

Ecco perché il context engineering è così importante: sposta l’attenzione dal modello al sistema. Invece di chiedersi “come aggiustiamo il modello perché risponda meglio?”, ci si chiede “come possiamo arricchire e ottimizzare il contesto perché il modello abbia tutte le carte in regola per rispondere bene?”. Questa mentalità data-driven fa sì che la responsabilità della qualità dell’output ricada in larga misura sul progettista del sistema, non sul modello in sé. Del resto, quando un LLM ben addestrato sbaglia, nella maggior parte dei casi è perché gli mancava un’informazione o un chiarimento che avremmo potuto dargli. Fornire “le informazioni giuste, nel momento giusto” all’AI non è più facoltativo: è diventato il requisito base per passare dalle demo giocattolo a applicazioni AI realmente funzionanti.

Un nuovo paradigma tecnico e architetturale

Il passaggio dal prompt engineering al context engineering non è solo un cambio di tecnica, ma un’evoluzione dell’architettura dei sistemi AI. Nel paradigma tradizionale immaginavamo una pipeline semplice: input dell’utente (frontend) → prompt elaborato → modello (backend) → output. Ora questa linearità si rompe: tra l’input iniziale e la chiamata al modello entra in gioco un sistema articolato di recupero, trasformazione e orchestrazione dei dati. Invece di un prompt fisso, abbiamo un processo dinamico che costruisce il contesto ad hoc per ogni richiesta.

Possiamo riassumere così le caratteristiche di questo nuovo paradigma architetturale:

Si supera la rigida divisione frontend/prompt/backend: il contesto diventa una sorta di livello applicativo intermedio che amalgama componenti di front-end (es. input utente, interfaccia) e di back-end (modello AI, database) in un flusso unico.
La qualità dell’output viene elevata a responsabilità di sistema: non confidiamo più ciecamente che “il modello farà bene”, ma predisponiamo l’architettura in modo da minimizzare le possibilità di errore del modello. In pratica, l’enfasi passa dal migliorare il cervello dell’AI al migliorare il suo “ambiente cognitivo”.
Cambia la mentalità di progettazione per sviluppatori e leader tecnologici: anziché sperare in qualche magia generativa o prompt perfetto, si ragiona in termini di orchestrazione, di flussi di informazioni e step logici che assicurino robustezza. Ad esempio, un CTO o un AI Lead oggi deve chiedersi come strutturare i dati aziendali perché alimentino efficacemente il modello, come mantenere lo stato di conversazione, quali strumenti integrare, ecc., costruendo un vero sistema cognitivo e non solo un’interfaccia domande-e-risposte.

Dal punto di vista pratico, questa evoluzione ha portato allo sviluppo di nuovi framework e tool specifici per implementare il context engineering. Librerie come LangChain, e più di recente framework come LangGraph, forniscono astrazioni per gestire memorie conversazionali, richiamare strumenti esterni, concatenare chiamate a modelli e controllare con precisione cosa viene passato nella finestra di contesto.

Questi strumenti aiutano i team a costruire agenti LLM più affidabili, dando la possibilità di possedere (cioè determinare esattamente) ogni parte del contesto e del flusso prima che l’LLM produca una risposta. Si tratta di un cambio di prospettiva radicale: l’obiettivo non è più ottenere una singola risposta sensazionale dal modello in condizioni ideali, ma garantire performance consistenti, ripetibili e governabilidel sistema AI nel suo complesso. In altre parole, non basta che l’AI sappia generare testo, deve farlo in produzionesotto vincoli di affidabilità, sicurezza e coerenza. Per riuscirci, ogni componente del contesto dev’essere progettato con rigore ingegneristico.

Va sottolineato che questo nuovo paradigma è multidisciplinare per natura. Il context engineering attinge all’ingegneria del software classica (architettura di sistemi, API, gestione dello stato), ma anche al knowledge management (organizzare informazioni e conoscenza aziendale) e alla UX writing (per modellare il tono e lo stile delle interazioni). Richiede cioè di connettere mondi diversi: quello dei dati e della tecnologia con quello dei processi aziendali e dei contenuti. Nel prossimo paragrafo vedremo come ciò impatta le organizzazioni e la cultura aziendale.

Implicazioni strategiche, organizzative e culturali

Il context engineering non è solo un’evoluzione tecnica: rappresenta anche un cambiamento culturale nel modo in cui le aziende e i team approcciano i progetti di intelligenza artificiale. Tradizionalmente, lo sviluppo di software vedeva ruoli ben distinti – sviluppatori che scrivono codice, analisti che definiscono requisiti, esperti di dominio separati dai tecnici.

Con i sistemi AI basati su LLM, questi confini iniziano a sfumare. Progettare il contesto di un’applicazione AI significa infatti, come osserva il professor Ethan Mollick della Wharton, dover: tradurre processi aziendali in flussi di dati strutturati; riflettere la cultura interna (il tono, il linguaggio, le aspettative) nel contesto fornito al modello; codificare la conoscenza tacita e il know-how operativo dell’organizzazione in forma fruibile dall’AI.

In altre parole, fare context engineering in un’azienda equivale in parte a fare knowledge management avanzato. Occorre mappare il sapere dell’organizzazione (documenti, policy, procedure, FAQ, ecc.), capire cosa serve davvero al modello nei vari scenari d’uso, e strutturare queste conoscenze in modo che l’AI possa utilizzarle efficacemente. Ciò può significare creare nuove basi di conoscenza, ontologie, database di vettori per il semantic search, pipeline di retrievaldedicate. Significa anche farsi domande sulla cultura aziendale: ad esempio, vogliamo che il nostro assistente AI interno adotti un tono informale e creativo, oppure formale e conservativo? Quali valori e best practice interne vanno integrate come istruzioni comportamentali nel contesto? Tutto questo va deciso e codificato a monte, affinché il modello operi in linea con l’identità dell’azienda.

Le implicazioni organizzative sono dunque profonde. I team di sviluppo AI devono diventare interfunzionali: coinvolgere non solo ingegneri del machine learning, ma anche esperti del dominio specifico, data engineer, magari linguisti computazionali e figure di knowledge curator. È una sfida che richiede collaborazione stretta tra chi conosce la tecnologia LLM e chi conosce il contesto di business. Inoltre, la leadership aziendale (CTO, CPO, responsabili innovazione) deve sposare questa visione: investire nella preparazione dei dati e dei contesti prima ancora che nel modello in sé. Non a caso, si sente dire che “nel mondo degli LLM, il contesto è la nuova interfaccia utente”. Progettare queste nuove interfacce – invisibili all’utente finale ma cruciali dietro le quinte – vuol dire in ultima analisi disegnare l’identità operativa dell’azienda nell’era dell’AI.

Dal punto di vista strategico, le aziende che sapranno eccellere nel context engineering avranno un chiaro vantaggio competitivo. Significa poter costruire assistenti virtuali che non allucinano risposte, perché hanno sempre i dati aggiornati e verificati a portata di mano. Significa offrire ai clienti esperienze AI personalizzate e coerenti con il brand, perché il modello “respira” la cultura aziendale che è stata immessa nel suo contesto. E significa poter scalare soluzioni AI in nuovi ambiti in modo più rapido, perché una volta creata l’architettura di contesto, quella diventa un asset riutilizzabile e adattabile a diversi casi d’uso. Non è un caso che alcuni commentatori sostengano che il context engineering sarà la competenza più importante per gli AI engineer d’ora in avanti. È un nuovo campo su cui costruire metodologie, strumenti e best practice, un po’ come lo è stato il DevOps per il software tradizionale. Sta già emergendo una comunità di pratica attorno a questi temi, segno di una trasformazione culturale in atto nel settore tecnologico.

Dal playground alla produzione: professionalizzare l’AI

Un effetto tangibile di questa evoluzione è il passaggio da un approccio ludico-sperimentale con l’AI (tipico dei primi tempi di ChatGPT) a un approccio ingegneristico e strategico. Quello che inizialmente era quasi un gioco di intuito – provare prompt su prompt finché “sembra funzionare” – oggi non è più sufficiente né appropriato per applicazioni in produzione. Il cosiddetto “vibe coding”, ormai usato in tono ironico, ha mostrato i suoi limiti: l’intuizione non scala, e sistemi basati su semplici prompt tweakati a mano risultano fragili, imprevedibili e difficili da manutenere.

Al contrario, il salto di qualità si ottiene spostandosi “dal prompt al contesto, dal tool carino al prodotto solido”. Ciò significa dedicare in fase di progettazione lo stesso rigore che si avrebbe per qualsiasi altra architettura software mission-critical. In un’app AI matura, ogni componente del contesto è pensato, implementato e testato: ad esempio, si verifica che il sistema di retrieval recuperi effettivamente i documenti più rilevanti; si affinano i prompt di sistema con policy chiare; si implementano controlli (guardrails) per evitare che errori si propaghino; si monitora la performance del modello su conversazioni lunghe per calibrare i meccanismi di sommario della memoria, e così via. Tutto questo lavoro non è “visibile” all’utente finale, ma fa la differenza tra un’AI che impressiona in una demo e una che genera valore reale e consistente quando usata ogni giorno da migliaia di utenti.

Per i decision maker, adottare il context engineering significa anche ragionare in termini di strategia dei dati. Bisogna chiedersi: di quali dati disponiamo e come li rendiamo fruibili al nostro AI? Come garantiamo che siano aggiornati e puliti? Quali conoscenze chiave (ad esempio, normative, linee guida interne, tone of voice) dobbiamo infondere nel sistema? Questo ragionamento avvicina il mondo dell’AI a quello della gestione della conoscenza e dei processi aziendali. Progettare il contesto diventa un’attività che precede e indirizza lo sviluppo stesso del modello AI, spesso chiamata AI blueprint o sprint zero: prima di scrivere una riga di codice o di scegliere quale algoritmo utilizzare, si disegna l’ecosistema informativo entro cui l’AI dovrà operare. È qui che molte iniziative AI falliscono o hanno successo – una sorta di “trincea invisibile” dove si vince o si perde la sfida dell’intelligenza artificiale in azienda.

Infine, spostare l’attenzione sul contesto aiuta a demistificare l’AI. Ci ricorda che un LLM, per potente che sia, resta una macchina statistica che funziona in base ai dati che riceve in input. Pensare in termini di context engineering significa vedere l’AI non più come una scatola magica, ma come un componente che va integrato in un sistema più ampio e controllabile.

Come ho scritto “l’era del prompt engineering ci ha insegnato a parlare con l’AI; l’era del context engineering ci sta insegnando a pensare insieme all’AI”. In questa nuova era context-first, le frasi furbe contano meno della capacità di architettare sistemi intelligenti con le informazioni giuste al momento giusto. È un cambiamento di prospettiva notevole: dall’ottimizzazione delle singole frasi all’ottimizzazione della conoscenza e dei processi.

Il contesto prima di tutto

Il context engineering si presenta come la naturale evoluzione – e superamento – del prompt engineering. Dove prima ci si concentrava sul come chiedere qualcosa all’AI, ora l’attenzione è su cosa l’AI conosce e ha a disposizione quando gli viene posta una domanda, e come ottiene queste informazioni. Il contesto diventa la nuova interfaccia su cui progettare l’esperienza AI. Chi riesce a padroneggiare questa interfaccia invisibile – strutturandola, orchestrandola e mantenendola con cura – costruisce di fatto il “cuore” del sistema AI e ne determina il successo o il fallimento operativo.

Questa disciplina richiede un mix di competenze tecniche, strategiche e di dominio, e sta trasformando il modo in cui pensiamo l’implementazione dell’AI nelle organizzazioni. Il messaggio chiave è chiaro: prima di scegliere il modello da usare, bisogna progettare il contesto. Solo così un’intelligenza artificiale può davvero “fare bene il proprio lavoro” in modo ripetibile e affidabile. In un mondo in cui i modelli linguistici sono sempre più potenti e disponibili, la differenza la farà chi saprà alimentarli con il contesto migliore.

Su Gumroad il PDF completo di 78 pagine, sul Context Engineering, da acquistare e scaricare.

2 Maggio 20252 Maggio 2025AI & GENAI

RAG o CAG, Cercare o Ricordare, questo è il dilemma? No.

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.