Dal Prompt Chaining al Tree of Thoughts

Qualche giorno fa ho scritto un approfondimento, partendo dal post di Nicola, sul tema del Prompt Chaining. Il post ha riscosso un discreto interesse come approccio e ha generato diverse discussioni su approcci e vantaggi. Tra queste interazioni ci sono stati due commenti in cui è emerso l’interesse per diversi approcci al prompting e ai diversi contesti in cui c’è bisogno di uno o altro approccio.

Il Prompt Engineering, tema interessante ma eccessivamente abusato in termini di narrativa, non è altro che “l’arte” di formulare richieste efficaci ai modelli di intelligenza artificiale (AI) al fine di ottenere risultati utili e pertinenti. Negli ultimi tempi sono emersi diversi approcci avanzati per guidare i modelli linguistici generativi (Large Language Models, LLM) in modo più strategico, ottimizzato e finalizzato ad uno scopo preciso.

Uno di questi è il Prompt Chaining, di cui ho parlato nel mio articolo , in cui l’output di ciascun prompt diventa l’input del successivo. Questo consente di scomporre compiti complessi in passi più piccoli e gestibili, migliorando efficacia e accuratezza delle risposte del modello. Come scrivevo, il prompt chaining “non è solo una tecnica per istruire meglio l’AI, ma può diventare una vera e propria architettura cognitiva”, un modo per strutturare il pensiero delle macchine in modo simile al nostro. In altri termini, si passa da un’interazione estemporanea a una strategia conversazionale articolata in più fasi.

Il prompt chaining è parte di una più ampia famiglia di tecniche di prompt engineering sviluppate per migliorare il dialogo con i modelli AI. In questo approfondimento ho dato maggiore dettaglio alle principali tecniche – dal zero-shot e few-shot prompting, al chain-of-thought e al framework ReAct, fino a metodologie differenti come il self-consistency, Tree of Thoughts e RAG (Retrieval-Augmented Generation).

Per ognuna troverete i principi di funzionamento, i contesti di applicazione più efficaci, i vantaggi e i limiti, includendo esempi o scenari d’uso pratici quando utili. L’obiettivo è fornire una panoramica tecnica ma accessibile a un pubblico eterogeneo di utilizzatori dell’AI (su diversi tool), condividendo spunti applicativi e indicando come queste tecniche possano contribuire a un’adozione più consapevole e proficua dell’intelligenza artificiale nelle organizzazioni.

Prompt Chaining (Catena di Prompt)

Cos’è e principi di base: Il Prompt Chaining consiste nel concatenare più prompt in sequenza, in modo che ogni fase guidi la successiva. Invece di porre al modello una singola richiesta molto complessa, si suddivide il compito in sotto-obiettivi: il modello produce un risultato parziale che viene poi utilizzato in un prompt successivo, e così via. Questa tecnica si basa sul principio della decomposizione del problema: affrontare un “elefante” un pezzo alla volta (parafrasando il detto, “tagliare l’elefante a pezzi e ragionare per passi”). Ad esempio, anziché chiedere direttamente “Scrivi un rapporto completo sull’andamento del mercato AI nel 2025”, si può procedere per passi: prima chiedere una scaletta dei punti chiave, poi far approfondire ogni punto, infine richiedere una sintesi finale. Ogni prompt nella catena si concentra su un sotto-compito specifico mantenendo il contesto generale, e guida il modello passo dopo passo. In questo modo l’AI “pianifica” internamente la soluzione, similmente a un flusso di lavoro umano strutturato.

Contesti di utilizzo efficaci: il prompt chaining è efficace quando il compito richiesto al modello è complesso, lungo o richiede diverse fasi logiche. Nella progettazione di contenuti articolati (es. corsi, documentazione, white paper), questa tecnica permette di mantenere coerenza e approfondimento senza sovraccaricare il modello con un’unica richiesta monolitica. In ambito educativo o formativo, ad esempio, si può usare un approccio “a catena” per sviluppare un corso: prima generare un elenco di moduli, poi i dettagli di ciascun modulo, poi esercizi per ogni modulo, ecc. Anche per analisi strategiche o problem solving multi-step, il chaining consente all’AI di seguire un ragionamento articolato invece di tentare di dedurre tutto in un solo passaggio. Questa metodologia trova applicazione ogniqualvolta si desideri avere maggiore controllo sul processo con cui l’AI arriva a una risposta, suddividendolo in tappe verificabili.

Vantaggi: scomponendo il problema, il prompt chaining riduce l’ambiguità e distribuisce lo sforzo cognitivo del modello su più interazioni. Ne derivano output più accurati e coerenti, poiché il modello può concentrarsi su un obiettivo specifico ad ogni passo. L’approccio iterativo consente di mantenere il contesto lungo tutta la conversazione e di raffinare progressivamente la risposta. Inoltre, ogni fase intermedia offre all’utente umano l’opportunità di correggere la rotta o aggiungere istruzioni, portando a un maggiore controllo sul risultato finale. Un ulteriore beneficio è legato all’ottimizzazione delle risorse: invece di generare un lungo testo potenzialmente ridondante o fuori fuoco, l’AI produce contenuti modulari più gestibili, ottimizzando l’uso della finestra di contesto (token) e riducendo il rischio di output incoerenti dovuti a contesti troppo lunghi.

Limiti: Il prompt chaining richiede una certa pianificazione e abilità nel disegnare la sequenza di prompt. È un processo più laborioso e dispendioso in termini di tempo e di chiamate al modello rispetto a un singolo prompt: ogni passo aggiuntivo comporta un’interazione separata (con relativo costo, se si utilizza un API a pagamento, e latenza). Inoltre, l’utente deve assicurarsi che il contesto venga passato correttamente da un prompt all’altro (ad esempio riassumendo brevemente le informazioni rilevanti nel prompt successivo, se la memoria del modello è limitata). Un rischio è l’errore propagato: se un passaggio intermedio genera un’informazione errata o fuorviante, questa potrebbe propagarsi nelle fasi successive. Mitigare questo rischio richiede intervento umano (controllo degli output intermedi) o strategie per ripristinare il corretto contesto in corsa. Infine, come tutte le tecniche iterative, il chaining può portare a output eccessivamente prolissi se ogni passo non è ben focalizzato, è importante definire chiaramente gli obiettivi di ciascun sottoprompt.

Esempio pratico: Un esempio semplice di prompt chaining è la generazione di un articolo complesso. Invece di chiedere direttamente all’AI l’intero articolo, si può procedere così:

  1. Prompt 1: “Elenca i principali trend del mercato AI nel 2025 di cui parlare in un articolo.”Output: lista di trend (es. adozione di LLM nelle imprese, regolamentazione AI, nuovi modelli open-source, ecc.).

  2. Prompt 2: “Per ciascun trend identificato, forniscimi un breve paragrafo di spiegazione.”Output: paragrafi esplicativi per ogni punto della lista.

  3. Prompt 3: “Scrivi un’introduzione generale all’articolo che presenti l’argomento e i trend che saranno discussi.”Output: introduzione coesa menzionando i trend.

  4. Prompt 4: “Unisci il tutto in un articolo completo, assicurandoti che i paragrafi seguano l’ordine dei trend presentati e aggiungi una conclusione.”Output: articolo finale strutturato e approfondito.

Ad ogni step, l’utente può controllare e affinare i risultati (ad esempio, aggiungendo un trend dimenticato, o correggendo un paragrafo poco chiaro) prima di passare allo step successivo. Questo processo in catena assicura che il risultato finale sia più organico e accurato rispetto a una singola generazione “one-shot”.

Zero-Shot Prompting

Cos’è e principi di base: Lo Zero-Shot Prompting si riferisce alla capacità di un modello di linguaggio di eseguire un compito senza che gli siano forniti esempi espliciti nella richiesta. In pratica, al modello viene data solo un’istruzione o domanda, confidando nelle conoscenze generali apprese durante l’addestramento per produrre la risposta corretta. Si parla di “zero-shot” (zero esempi) perché il prompt non include alcuna dimostrazione o caso specifico. Ad esempio, se vogliamo che il modello traduca una frase, in zero-shot è sufficiente scrivere: “Traduci in inglese: Oggi piove a dirotto.” senza fornire esempi di traduzione. Il modello tenterà comunque di eseguire il compito basandosi sulle sue conoscenze pregresse della lingua. Questo approccio sfrutta la generalizzazione del modello: i grandi modelli hanno visto talmente tanti dati durante l’addestramento che spesso possono dedurre come svolgere un compito nuovo solo dalla descrizione testuale del compito stesso.

Contesti di utilizzo efficaci: Il zero-shot è la modalità più immediata di interazione e risulta efficace quando:

  • Il compito è semplice o comune, ad esempio traduzione, risposta a domande di cultura generale, riassunto di un testo breve, classificazione di sentiment di una frase, ecc., per cui il modello possiede già esperienza implicita. Ad esempio, un LLM può classificare il sentimento di “Questo film è uno spreco di tempo” come negativo anche senza esempi, perché ha appreso dal corpus cosa significa esprimere un giudizio negativo.

  • Si dispone di poco contesto o dati da fornire al modello. In scenari in cui l’utente non ha esempi concreti da inserire, sfruttare la conoscenza intrinseca del modello è l’unica opzione.

  • Rapidità e versatilità sono prioritarie: il zero-shot permette di ottenere una risposta immediata senza preparare prompt complessi, ed è adatto in applicazioni in tempo reale o prototipazione veloce. Ad esempio, per avere una risposta rapida a “Chi era il presidente degli USA nel 1990?” un prompt zero-shot diretto può bastare.

Vantaggi: I punti di forza del zero-shot prompting includono la semplicità e l’efficienza. Non è necessario preparare esempi o dati di riferimento, il che fa risparmiare tempo e risorse, rendendo questo approccio subito applicabile in molti contesti. Inoltre, mostra la versatilità del modello: con un’unica configurazione di addestramento, l’LLM può affrontare un’ampia gamma di compiti senza ulteriori interventi. In ambito operativo ciò significa poter rispondere a richieste diverse (dalla scrittura creativa al coding) semplicemente cambiando l’istruzione, senza dover riprogrammarlo. Un altro vantaggio è che si evita di biasare il modello con esempi potenzialmente fuorvianti: talvolta fornire esempi può indurre il modello a riprodurli pedissequamente; in zero-shot il modello genera ex novo basandosi solo sull’obiettivo descritto.

Limiti: Lo zero-shot spesso soffre di minore accuratezza o specificità rispetto ad approcci con esempi. La mancanza di esempi di riferimento può portare il modello a interpretare la richiesta in modo diverso da quanto l’utente intendeva, soprattutto se il prompt non è perfettamente chiaro. C’è una forte dipendenza dalla formulazione del prompt: una leggera ambiguità può condurre l’AI fuori strada, non avendo esempi cui ancorarsi. Inoltre, in compiti più complessi o di nicchia, il modello potrebbe fornire risposte superficiali o sbagliate, poiché senza esempi non ha indicazioni su come strutturare la soluzione. In sintesi, la qualità dell’output è variabile: alcuni LLM molto avanzati (es. GPT-4) riescono sorprendentemente a fare ragionamenti zero-shot, ma modelli meno sofisticati potrebbero fallire senza qualche guida aggiuntiva.

Esempio pratico: Un utilizzo tipico del zero-shot è porre domande dirette al modello. Ad esempio: “Spiega la differenza tra energia rinnovabile ed energia non rinnovabile.”  Senza fornire esempi, il modello dovrà attingere alla sua conoscenza generale per articolare una spiegazione. Se il modello ha una buona base, risponderà elencando cosa sono le energie rinnovabili (solare, eolica, ecc.) e non rinnovabili (combustibili fossili, nucleare tradizionale), evidenziando vantaggi e svantaggi, tutto basandosi sulla singola istruzione ricevuta. Se la domanda fosse più vaga (“Parlami dell’energia.”), il rischio zero-shot è di ottenere una risposta generica o non centrata sull’aspetto desiderato. Per questo, anche in zero-shot, spesso si cerca di rendere il prompt chiaro e specifico, ad esempio aggiungendo “in modo conciso e focalizzato sugli aspetti ambientali”. In assenza di esempi, ogni parola nel prompt conta per orientare la risposta.

Few-Shot Prompting

Cos’è e principi di base: Il Few-Shot Prompting è una tecnica in cui al modello vengono forniti uno o più esempi della richiesta all’interno del prompt, per guidarlo verso la risposta desiderata. In pratica, il prompt include sia l’istruzione sia alcune coppie di input-output di esempio (tipicamente 1 a 5 esempi, da cui “few”). Ad esempio, per insegnare al modello a rispondere con un certo stile, potremmo fornire due Q&A di esempio e poi porre una nuova domanda simile. Questo approccio sfrutta la capacità del modello di apprendimento contestuale: grazie agli esempi, l’LLM può dedurre il pattern di soluzione voluto e replicarlo per l’input nuovo. Il modello, in sostanza, viene “calibrato” sul momento tramite i prompt di esempio, senza necessitare di un addestramento esterno aggiuntivo.

Contesti di utilizzo efficaci: Il few-shot è indicato quando:

  • Il compito è specifico o poco comune e vogliamo mostrare al modello esattamente il formato o il ragionamento atteso. Ad esempio, per far generare titoli creativi in rima per articoli, potremmo dare 2–3 esempi di titoli in rima.

  • Si dispone di esempi rappresentativi della richiesta. In scenari aziendali, spesso si hanno storici o set di dati di riferimento (es. FAQ con domande e risposte). Includendone alcune nel prompt, il modello comprenderà meglio come deve rispondere in quello stile o dominio.

  • Precisione e coerenza sono critiche. Il few-shot può drasticamente migliorare la pertinenza delle risposte rispetto al zero-shot. In applicazioni come customer support automatizzato, fornire esempi di domande dei clienti e risposte appropriate può far sì che il modello risponda in modo più accurato ai nuovi quesiti dei clienti (es. mostrando il tono e il livello di dettaglio giusto).

Vantaggi: Aggiungendo pochi esempi nel prompt, il modello si adatta rapidamente al contesto specifico, producendo risposte più accurate e contestuali. Si ottiene spesso una maggiore precisione perché il modello replica la logica o lo stile mostrato negli esempi. Il few-shot permette anche una certa flessibilità: con un piccolo insieme di dati di esempio, si “sposta” l’LLM su un dominio o task desiderato senza bisogno di costosi re-training o fine-tuning esterni. È come fornire un mini-brief al modello: in base a pochi casi, capisce meglio cosa fare. Inoltre, gli esempi aiutano a ridurre ambiguità ed errori: se la domanda da risolvere può essere interpretata in modi diversi, mostrare un esempio toglie dubbi su quale interpretazione sia corretta (il modello tenderà a imitare la soluzione data nell’esempio).

Limiti: Il principale costo del few-shot è la necessità di curare esempi di qualità. Preparare gli esempi pertinenti richiede tempo e competenza sul problema. Inoltre, inserire esempi nel prompt consuma spazio nella finestra di contesto del modello, limitando la lunghezza della richiesta o della risposta possibile (soprattutto con modelli con contesto ridotto). C’è poi la questione della varietà: se gli esempi forniti non coprono sufficientemente i diversi casi, il modello potrebbe generalizzare male. In alcuni casi può addirittura overfittare sugli esempi: ad esempio, se diamo 3 esempi tutti con la stessa risposta, il modello potrebbe rispondere sempre quella (anche quando non dovrebbe). È dunque cruciale che gli esempi siano rappresentativi e diversificati. Un altro limite è che il modello potrebbe copiare parti dell’esempio nella risposta (soprattutto se l’input nuovo assomiglia molto a un esempio): questo può introdurre errori se l’output dell’esempio non si applica esattamente al nuovo caso. In sintesi, il few-shot bilancia un miglioramento di performance con un aumento di complessità nella progettazione del prompt.

Esempio pratico: Poniamo di voler usare l’AI per classificare recensioni di prodotti come positive o negative. In zero-shot potremmo dire: “Etichetta la seguente recensione come positiva o negativa: ‘Il prodotto funziona malissimo, sono molto deluso’.” Il modello potrebbe capire, ma con few-shot faremo meglio. Costruiamo il prompt con esempi:

  1. Prompt: Recensione: “Questo gadget è fantastico! Ha superato le mie aspettative.” Sentiment: Positivo. Recensione: “Purtroppo il dispositivo si è rotto dopo un giorno. Che spreco di soldi.” Sentiment: Negativo. Ora etichetta la seguente recensione “Il prodotto funziona malissimo, sono molto deluso.”

Fornendo questi esempi, l’AI apprende dal contesto come svolgere il compito: vede il formato Recensione -> Sentiment e i criteri (nel primo caso entusiasmo = Positivo, nel secondo caso problema grave = Negativo). Di conseguenza risponderà molto probabilmente “Negativo” per la recensione data, con maggiore affidabilità rispetto a zero-shot. Questo paradigma few-shot simula in miniatura quello che sarebbe un addestramento supervisionato, ma avviene interamente nel prompt.

Chain-of-Thought (CoT) Prompting

Cos’è e principi di base: Il Chain-of-Thought (CoT) prompting è una tecnica avanzata in cui si induce il modello a svolgere un ragionamento passo-passo esplicito per arrivare alla soluzione. Invece di limitarsi a fornire direttamente la risposta finale, al modello viene richiesto (in modo implicito o esplicito) di “pensare a voce alta”, elencando la sequenza logica di deduzioni o calcoli che conducono alla risposta. In pratica, il prompt incoraggia il modello a suddividere il problema complesso in passaggi intermedi risolvibili individualmente. Ciò può avvenire tramite istruzioni come “mostra il ragionamento” o con esempi di soluzione in cui viene illustrato il processo (“Prima fai questo calcolo, poi quest’altro, infine…”). L’idea alla base è che i LLM, se guidati a articolare un chain of thought, possano raggiungere una comprensione più profonda del problema e quindi risposte più corrette, simili a come un umano risolverebbe mostrando i calcoli su carta.

Contesti di utilizzo efficaci: Il CoT è particolarmente potente in compiti che richiedono logica, calcoli o multi-step reasoning:

  • Problemi matematici o aritmetici a più operazioni: ad esempio, risolvere problemi di testo (“se Maria ha 5 mele e ne compra altre 3, quante mele ha?”) chiedendo al modello di procedere per passaggi (conta mele iniziali, aggiungi nuove mele, ecc.).

  • Puzzle o problemi di logica (indovinelli, sillogismi, deduzioni): far esplicitare al modello le informazioni date e i passi per arrivare alla conclusione aiuta ad evitare salti logici errati.

  • Domande di common sense o implicazioni: es. “Un pallone bucato può rimbalzare?” – inducendo il ragionamento (“Un pallone bucato perde aria, senza aria non può rimbalzare, quindi no”) si aumenta la probabilità di correttezza su questioni non banali.

  • Pianificazione e scenari complessi: ad esempio chiedere al modello di elaborare una strategia marketing strutturata: col CoT si può ottenere che elenchi prima analisi, poi obiettivi, poi tattiche in ordine logico. In generale, il chain-of-thought è ideale in qualunque contesto dove una soluzione deve emergere da più step concatenati, permettendo al modello di “concentrarsi” su un passo alla volta.

Vantaggi: Far esprimere al modello una catena di pensieri porta diversi benefici. Innanzitutto migliora la coerenza logica dell’output: le risposte risultano più strutturate e fondate, soprattutto su problemi complessi che altrimenti il modello potrebbe affrontare in modo superficiale. Il CoT aiuta il modello a comprendere meglio la natura del problema, perché nel generare il ragionamento intermedio esso stesso “riscopre” i sotto-obiettivi necessari. Ciò conduce in genere ad una maggiore accuratezza finale. Un altro vantaggio cruciale è la trasparenza: vedere il ragionamento passo-passo fornisce agli utenti umani insight sul perché il modello arriva a una certa risposta, rendendo più facile individuare eventuali errori o passi poco convincenti. Questo aumenta la fiducia e consente di intervenire, se necessario, su uno specifico passo (ad esempio correggendo un calcolo intermedio sbagliato). Inoltre, la tecnica CoT ha dimostrato di estendere le capacità dei modelli sui task di ragionamento: ricerche hanno mostrato che LLM di media dimensione, se istruiti a fare chain-of-thought, possono risolvere problemi che altrimenti sbaglierebbero, raggiungendo performance paragonabili a modelli più grandi non-CoT.

Limiti: L’uso di chain-of-thought richiede solitamente prompt più complessi e aumenta la lunghezza delle risposte, quindi può rallentare il tempo di risposta e consumare più token. C’è un overhead computazionale nel generare tutti i passi intermedi. Inoltre, la formulazione del prompt CoT deve essere accurata: non tutti i modelli seguono l’istruzione di fare ragionamenti espliciti di default. Spesso si utilizzano frasi trigger (ad es. “Reason step by step:”) o esempi formattati in modo da indurre il comportamento. Se il prompt è mal concepito, l’LLM potrebbe elencare passi poco utili o addirittura allucinare ragionamenti sbagliati. Un altro aspetto è che CoT, pur migliorando la logicità, non garantisce infallibilità: il modello potrebbe comunque compiere errori in uno step, e questi errori comprometteranno la risposta finale (garbage in, garbage out). In alcuni casi, soprattutto con modelli più piccoli, abbiamo visto ragionamenti fittizi , il modello produce un chain-of-thought che sembra coerente ma porta comunque a una risposta errata. Infine, non tutti i problemi richiedono CoT: per domande semplici, forzare un ragionamento dettagliato può essere inefficiente. Bisogna dunque decidere caso per caso se vale la pena attivare questa modalità.

Esempio pratico: Consideriamo un problema matematico a parole: “In una fattoria ci sono 3 galline e 2 mucche. Quante zampe ci sono in totale?”. Un approccio chain-of-thought potrebbe essere innescato da un prompt come: “Rispondi passo-passo: prima calcola le zampe delle galline, poi delle mucche, e somma.”. Il modello allora potrebbe produrre:

  • “Ogni gallina ha 2 zampe. Ce ne sono 3, quindi 3×2 = 6 zampe di gallina. Ogni mucca ha 4 zampe. Ce ne sono 2, quindi 2×4 = 8 zampe di mucca. In totale le zampe sono 6 + 8 = 14.”Risposta: 14.

Qui vediamo il chain-of-thought esplicito. Senza questa guida, il modello potrebbe semplicemente dare una risposta (si spera 14), ma non mostrando il calcolo sarebbe difficile capire se l’ha ottenuta per via corretta o per fortuna. Con CoT, anche se il numero finale fosse sbagliato, l’utente può vedere dove il ragionamento ha fallito (ad esempio, se avesse calcolato male 3×2). Nell’uso pratico, CoT è risultato determinante per migliorare task di matematica, logica e persino comprensione di testi complessi, al punto che è diventata una delle tecniche standard per sfruttare al meglio i LLM in scenari di reasoning avanzato.

ReAct (Reasoning + Acting)

Cos’è e principi di base: ReAct è un paradigma che unisce il ragionamento (Reasoning) tipico del chain-of-thought con la capacità di agire (Acting) nell’ambiente esterno. Proposto da Yao. nel 2022, il framework ReAct prevede che il modello generi sia tracce di ragionamento verbale sia azioni specifiche per il task in modo intercalato. In pratica, durante l’elaborazione, l’LLM alterna pensieri e azioni: i pensieri sono passi di ragionamento interni, le azioni sono operazioni compiute all’esterno, come effettuare una ricerca, interrogare una base di conoscenza, eseguire un calcolo o chiamare un’API. Questa interazione avviene ciclicamente: il modello pensa -> compie un’azione -> ottiene un’osservazione dall’ambiente -> continua a pensare in base a quella nuova informazione, e così via. L’idea chiave è che combinando ragionamento e azione, l’AI possa iterare verso la soluzione integrando conoscenze esterne e aggiornando il proprio piano man mano.

Contesti di utilizzo efficaci: ReAct si rivela potente in scenari in cui il modello da solo non ha tutte le informazioni o capacità per completare il compito e deve interagire con strumenti o dati esterni. Ad esempio:

  • Question answering su conoscenze aggiornate: se chiediamo “Chi è l’attuale CEO di <una certa azienda>?”, un LLM addestrato su dati vecchi potrebbe non sapere la risposta. Un agente ReAct potrebbe eseguire un’azione di ricerca sul web, leggere la pagina trovata (osservazione), poi rispondere in base alle info aggiornate.

  • Risoluzione di problemi che richiedono calcoli o simulazioni: es. chiedere “Qual è la radice quadrata di 1048576?” – invece di far affidamento sulle sue capacità matematiche (che possono essere limitate o soggette a errori), il modello ReAct potrebbe invocare una calcolatrice esterna come azione, ottenere il risultato e poi comunicarlo.

  • Interazione con ambienti o database: in un contesto di assistente personale, l’AI potrebbe dover controllare il calendario, inviare email, o eseguire azioni nel mondo reale. ReAct fornisce un quadro per farlo: il modello decide un’azione (ad es. “Apri calendario”), l’ambiente restituisce l’esito (“Calendario aperto, prossimi eventi…”), il modello ragiona e decide la prossima mossa.

  • Task di decision-making complessi: ad esempio nella risoluzione di un mistero o di un gioco di avventura testuale, l’agente ReAct può pianificare (ragionamento) e testare mosse (azione) esplorando attivamente il problema.

Vantaggi: Il principale vantaggio di ReAct è che supera i limiti di conoscenza chiusa del modello, permettendo accesso a informazioni aggiornate o specifiche durante la generazione. Questo riduce drasticamente il fenomeno delle allucinazioni: se il modello può verificare fatti tramite azioni (es. cercare su Wikipedia), è meno incline a inventare risposte. ReAct inoltre migliora l’accuratezza fattuale e l’affidabilità delle risposte, come dimostrato da esperimenti che hanno visto l’agente ReAct superare approcci puramente basati su ragionamento o su azione isolate. Un altro benefit è la trasparenza e controllabilità: poiché il modello elenca i suoi pensieri e azioni, un osservatore umano può seguire passo passo il processo e intervenire se necessario (ad esempio, interrompere l’esecuzione di un’azione non voluta). In ambito applicativo, ReAct apre la strada a LLM “agenti” in grado di compiere operazioni utili: molti sistemi pratici (come i plugin di ChatGPT, o framework tipo LangChain) adottano proprio questo paradigma per far sì che l’AI consulti documenti, esegua codice o chiami servizi in base alla richiesta dell’utente. In sintesi, ReAct aumenta la capacità di problem solving del modello combinando il meglio di due mondi: il ragionamento interno e l’interazione con l’esterno.

Limiti: Implementare ReAct è complesso. Richiede definire una sorta di protocollo che il modello segua nei prompt, ad esempio una sintassi per distinguere Thought (pensiero) e Action e Observation (risultato dell’azione). Non tutti i modelli seguono facilmente questo schema – in genere si usano LLM molto obbedienti e capienti, e prompt di contesto con esempi di formato ReAct. C’è poi il tema della sicurezza: dare a un modello la possibilità di agire (eseguire codice, cercare online) comporta rischi; bisogna porre limiti sulle azioni possibili onde evitare comportamenti indesiderati. Un altro limite è la dipendenza dalla qualità degli strumenti esterni: se il sistema di ricerca fornisce risultati sbagliati o se un’API chiamata fallisce, l’agente potrebbe andare in stallo o prendere decisioni errate. Inoltre, orchestrare ragionamenti e azioni iterativamente può essere costoso in termini computazionali – ogni ciclo ragionamento/azione equivale a più chiamate modello + costi delle operazioni esterne. Vi è anche una maggiore possibilità di bug logici: l’agente potrebbe entrare in loop (continuare a cercare senza mai rispondere) o tentare azioni non supportate se il prompt non lo vincola bene. Infine, leggere e interpretare le osservazioni (ad esempio il contenuto di una pagina web) è vincolato alla finestra di contesto: bisogna spesso riassumere o filtrare i dati esterni prima di reinserirli nel prompt successivo.

Esempio pratico: Un caso concreto di ReAct è un assistente QA con accesso al web. Supponiamo l’utente chieda: “Quanti astronauti sono attualmente sulla Stazione Spaziale Internazionale?”. Un semplice LLM addestrato fino al 2021 non ha questa informazione aggiornata. Un agente ReAct potrebbe operare così:

  • Thought: “La domanda richiede un dato aggiornato. Devo cercarlo online.”

  • Action: Search("numero astronauti attualmente ISS")

  • Observation: (il sistema di ricerca restituisce un risultato: una pagina Wikipedia o news con l’informazione).

  • Thought: “Ho trovato un risultato che sembra pertinente, ora lo leggo.”

  • Action: Open(URL_pagina)

  • Observation: (testo della pagina: “… attualmente sulla ISS ci sono 7 astronauti …”).

  • Thought: “Ora ho l’informazione, posso formulare la risposta.”

  • Final Answer: “Al momento attuale, ci sono 7 astronauti a bordo della ISS.”

Durante questo processo, l’AI ha ragionato sui passi necessari e utilizzato strumenti (search e open web) per colmare le sue lacune di conoscenza. Tutto ciò avviene in pochi secondi e l’utente finale vede solo la risposta corretta con eventualmente la fonte. Questo esempio illustra come ReAct renda l’AI proattiva e affidabile per domande altrimenti fuori portata per un modello statico.

Nota: poichè mi è stato chiesto in aula, anche se il processo sembra simile al comportamento di ChatGPT 4o , parliamo di cose diverse:

  • ReAct = paradigma di prompting (schema per orchestrare ragionamenti + azioni).
  • ChatGPT-4o = modello multimodale, che può integrare o ispirarsi a logiche ReAct ma non è basato su di esso.

Self-Consistency

Cos’è e principi di base: La Self-Consistency è una tecnica avanzata che mira a migliorare la correttezza delle risposte del modello attraverso un approccio di aggregazione statistica dei ragionamenti. Proposta da Wang (2022), nasce come metodo per sostituire il tradizionale greedy decoding usato nel chain-of-thought con qualcosa di più robusto. In pratica, invece di generare una singola catena di ragionamento (che potrebbe essere fallace), si fa in modo che il modello ne generi molteplici varianti indipendenti, quindi si osservano le diverse risposte finali e si sceglie quella più comune – presumendo che sia la più correttapromptingguide.ailearnprompting.org. È un po’ come porre la stessa domanda a tanti “cloni” del modello e poi fare una votazione di maggioranza sulle risposte. L’idea è che il modello, seguendo vie diverse di pensiero grazie alla casualità nel processo di generazione, potrebbe arrivare a risposte differenti; tuttavia, se c’è una risposta oggettivamente corretta, è probabile che molte di quelle catene di pensiero convergano su di essa, rendendola la risposta più frequente.

Contesti di utilizzo efficaci: La self-consistency si applica in particolare a compiti con una sola risposta corretta ben definita, dove piccoli errori nel ragionamento possono portare a risposte sbagliate. Ad esempio:

  • Problemi di matematica e aritmetica: un LLM anche con chain-of-thought può occasionalmente errare un calcolo. Facendogli risolvere lo stesso problema più volte (con variazioni stocastiche nel generare i passaggi), possiamo mitigare l’errore scegliendo il risultato più frequente, che statisticamente sarà quello giusto nella maggioranza dei casi.

  • Logica e common sense: domande vero/falso, causali o di completamento logico dove il modello potrebbe indecidersi. Esempio: “Se ieri era lunedì, che giorno sarà domani?”. Alcune catene di ragionamento difettose potrebbero dare risposte errate, ma la maggior parte convergerà su mercoledì. La self-consistency prende quel consenso.

  • QA a risposta chiusa: domande di conoscenza generale con risposta univoca. Se il modello è incerto può produrre risposte diverse (soprattutto con temperature più alte), ma con self-consistency possiamo filtrare il rumore.

  • Situazioni in cui si valuta la affidabilità: la tecnica permette di assegnare una sorta di “confidence” alla risposta scelta (data appunto dalla percentuale di catene di pensiero che l’hanno prodotta). Questo può essere utile per sapere quando il modello è incerto (es. se c’è spaccatura tra due risposte, forse serve intervento umano).

Vantaggi: La self-consistency ha mostrato un netto aumento delle prestazioni del chain-of-thought su molti task di ragionamento complesso. Aggregando i risultati di molteplici chain, si elimina l’influenza di ragionamenti outlier o casuali: l’effetto è simile a quello di una committee di esperti che discutono, dove l’errore di uno può essere compensato dal corretto ragionamento di altri. In pratica, si riduce la varianza delle risposte del modello, ottenendo output più stabili e corretti. Sulle domande aritmetiche e di logica, questo metodo ha portato a risolvere correttamente problemi che un singolo CoT spesso sbagliava. Un altro beneficio è che non richiede modifiche all’addestramento del modello: è una tecnica di decoding, quindi applicabile in post-processing a qualunque LLM. Inoltre, fornisce una misura di sicurezza: se tutte le 10 catene di ragionamento danno risposte diverse, chiaramente il modello non è affidabile su quella query – informazione utile per decidere di non fidarsi o di riformulare la domanda.

Limiti: La self-consistency aumenta il costo computazionale in modo lineare con il numero di ragionamenti generati: se facciamo 10 “shot” di ragionamento per ogni domanda, stiamo usando 10 volte il modello. Questo la rende onerosa in situazioni di produzione a larga scala, salvo ottimizzazioni. Inoltre, scegliere la risposta più frequente funziona bene quando effettivamente c’è una risposta dominante corretta; ma se la domanda è ambigua o aperta, il concetto di risposta “consistente” perde significato. Ad esempio, su una domanda aperta (es. “Qual è un buon titolo per un romanzo di fantascienza?”), le risposte potranno essere tutte diverse e non ce n’è una “migliore” oggettivamente – in questi casi la self-consistency non si applica (o potrebbe addirittura essere controproducente scegliendo una risposta generica). Va notato poi che la qualità delle catene di pensiero iniziali è fondamentale: se il modello ha forti bias o lacune e tende a sbagliare sistematicamente un certo tipo di problema, generare più ragionamenti non aiuterà (tutti convergeranno sulla risposta sbagliata!). Quindi la self-consistency aiuta soprattutto quando il modello ha competenza sufficiente ma può incorrere in errori casuali. Infine, tecnicamente serve poter campionare diverse risposte: ciò implica impostare una temperatura di generazione > 0 e magari usare nucleus sampling per ottenere sufficiente diversità nelle chain – parametri che vanno tarati con cura per bilanciare diversità e qualità.

Esempio pratico: Immaginiamo di sottoporre al modello un piccolo indovinello matematico: “Quando avevo 8 anni, mio fratello ne aveva la metà. Ora che ho 14 anni, quanti anni ha mio fratello?”. Molti LLM tendono a rispondere frettolosamente “7” (sbagliato) se non ragionano bene. Con self-consistency, faremmo generare al modello magari 5 diverse spiegazioni/soluzioni. Esempio di possibili catene:

  1. “Fratello aveva 4 quando io 8. La differenza età è 4. Ora ho 14, fratello 10.” → Risposta: 10.

  2. “Differenza di 4 anni. A 14 anni, fratello 14-4=10.” → Risposta: 10.

  3. “Io 8, lui 4. Gap 4. Io 14, lui 14-4=10.” → Risposta: 10.

  4. “Se fratello metà di 8, aveva 4. Ora 14 e fratello 4+ (14-8)=10.” → Risposta: 10.

  5. “Fratello età attuale? Forse 7.” → Risposta: 7.

Notiamo che 4 catene su 5 danno risposta 10, una dà 7. Facendo majority voting, la risposta consistente è 10 (che è quella corretta). In questo modo abbiamo evitato l’errore della catena #5. In effetti, studi hanno osservato che la majority vote di più catene aumenta notevolmente l’accuratezza in problemi aritmetici e di logica rispetto a singola risposta CoT. Naturalmente, è importante che ogni catena sia indipendente: tipicamente si ottiene ciò ripetendo la query con un diverso seed stocastico o fondendo la richiesta in prompt diversi (variazioni nell’esposizione del problema per stimolare percorsi differenti). La self-consistency incarna un principio semplice: più voci possono essere meglio di una, quando si tratta di affidarsi a un AI per ragionare.

Tree of Thoughts (ToT)

Cos’è e principi di base: Il Tree-of-Thoughts (ToT) è un framework di prompting che generalizza l’idea del chain-of-thought espandendola in forma di albero decisionale. Invece di sviluppare un singolo percorso lineare di ragionamento, il modello esplora più possibili ramificazioni di pensiero da uno stesso stato, un po’ come valutare diverse strade per risolvere un problema. Questo simula strategie cognitive umane in cui, di fronte a un problema complesso, consideriamo varie ipotesi o sottosoluzioni parallele prima di impegnarci in una. Nel prompting ToT, ad ogni step il modello può generare diversi “pensieri” alternativi (nodi figli), costruendo così un albero di stati. Si definiscono criteri per valutare i pensieri (ad esempio tramite una funzione di valutazione o chiedendo al modello di dare un punteggio a ciascuno) e una politica per esplorare l’albero (in profondità, in ampiezza, con tagli potati dei rami meno promettenti). Questo approccio incorpora anche meccanismi come il lookahead (guardare avanti alcuni passi per stimare dove porta un certo ramo) e la già citata self-consistency per valutare l’affidabilità di un ramo tramite generazioni multiple. In breve, ToT è ispirato alle tecniche di ricerca AI classiche (come gli algoritmi di tree search) applicate all’ambito generativo: il prompt engineering diventa orchestrazione di un search tree di pensieri.

Contesti di utilizzo efficaci: Il Tree-of-Thoughts è indicato per problemi di deliberate problem solving, ovvero situazioni in cui:

  • Il percorso verso la soluzione non è unico o scontato e potrebbe richiedere di provare varie strade. Ad esempio, puzzle complessi, labirinti logici, giochi tipo scacchi o enigmi di pianificazione.

  • È possibile valutare parzialmente una soluzione prima di completarla. Ad esempio, nella scrittura creativa ramificata: generare diversi possibili proseguimenti di una storia e poi scegliere quello più interessante per continuare la narrazione.

  • Decision making con branching: scenari in cui ad ogni decisione ne conseguono altre (tipo choose your own adventure). Un sistema ToT può esplorare diverse sequenze di decisioni e identificare l’outcome ottimale secondo un certo criterio.

  • Problemi che beneficiano di tentativi ed errori: in un chain-of-thought lineare, un errore incorrerebbe e bloccherebbe il risultato; in ToT, se un ramo fallisce, se ne possono percorrere altri. Ad esempio, risolvere un rompicapo dove bisogna combinare mosse diverse: l’AI può provare un certo ordine di mosse (ramo A) e se porta a un vicolo cieco, tornare indietro e provare un ordine diverso (ramo B).

Vantaggi: Il ToT aumenta notevolmente la capacità esplorativa del modello. Invece di vincolarsi a un singolo ragionamento che potrebbe essere subottimale, l’AI può considerare molteplici alternative, aumentando la probabilità di trovare una soluzione corretta o creativa. Questo porta ad una maggiore efficacia nei compiti di problem solving generali. Inoltre, consente di implementare comportamenti di backtracking: se un certo filone di pensiero non funziona, l’agente può tornare a un nodo precedente e percorrere un altro ramo, un po’ come farebbe un programmatore nel debug di un algoritmo o una persona nel risolvere un puzzle. Il risultato finale è che il modello con ToT può risolvere problemi che richiedono tentativi multipli, laddove un CoT lineare fallirebbe se il primo tentativo è errato. Un altro beneficio è la possibilità di inserire heuristiche di valutazione: ad esempio, per ogni stato intermedio si può far valutare al modello quanto è vicino alla soluzione o se le condizioni necessarie sono ancora soddisfatte. Queste euristiche guidano la ricerca nell’albero in modo più intelligente, concentrando gli sforzi sui rami promettenti. In letteratura si è visto che ToT può combinare con successo ragionamento e ricerca strutturata, portando l’AI più vicina a un processo deliberativo umano nel risolvere problemi complessi. La possibilità di lookahead e di rivedere decisioni rende le soluzioni più ottimizzate e ponderate.

Limiti: Il rovescio della medaglia è la complessità computazionale: un’esplorazione combinatoriale di pensieri cresce esponenzialmente se non limitata. Bisogna definire attentamente il branching factor (quanti pensieri alternativi generare per step) e la depth massima dell’albero, altrimenti si rischia un’esplosione di possibilità ingestibili. Anche con euristiche, il costo può essere molto elevato per problemi appena un po’ più grandi. Un altro limite è che orchestrare un ToT richiede un controllo fine che oggi non è nativamente supportato dai modelli: tipicamente si devono scrivere script esterni che interfacciano col modello generando e valutando i nodi. Questo è più complesso di un semplice prompt singolo o di un chain-of-thought lineare. Inoltre, la qualità dipende fortemente da come viene progettata la funzione di valutazione dei rami: se la valutazione è sbagliata, il modello potrebbe scartare il ramo giusto e seguire quelli sbagliati (analogia: local minima in una ricerca). Dal punto di vista dell’usabilità, ToT rende il comportamento dell’AI meno prevedibile in termini di tempo di risposta (potrebbe finire molto presto se trova subito un ottimo ramo, oppure esplorare a lungo se indecisa). Infine, per alcuni task creativi troppo aperti, la struttura ad albero può essere eccessiva: conviene in problemi con un obiettivo chiaro da raggiungere, meno in quelli dove non c’è un “goal” definito. In sintesi, il ToT è molto potente ma va applicato con criterio a problemi che ne giustificano la complessità e laddove altre tecniche più semplici (CoT, self-consistency) non bastano.

Esempio pratico: Un esempio intuitivo può essere un gioco di labirinto testuale: il modello deve trovare l’uscita descrivendo passo a passo il percorso. Con un chain-of-thought tradizionale, l’AI potrebbe fare un tentativo lineare e se sbaglia strada arrivare a un vicolo cieco senza sapere come “tornare indietro”. Con Tree-of-Thoughts, invece, l’approccio sarebbe:

  • Stato iniziale: stanza di partenza.

  • Pensieri possibili: “vai a sinistra”, “vai a destra”, “vai avanti”.

    • Se “vai a sinistra” porta a un vicolo cieco (dopo qualche passo di esplorazione), quel ramo viene chiuso.

    • Si torna al nodo iniziale e si prova “vai a destra”.

  • Si esplorano così diversi percorsi come rami. Magari “vai a destra” -> “poi avanti” -> “poi sinistra” porta all’uscita. Il sistema lo individua come ramo di successo.

Durante la ricerca, il modello può avere una euristica: ad esempio, ogni volta che descrive la posizione attuale, può valutare se sembra più vicina all’uscita (magari l’uscita è descritta come “luce visibile” e solo in alcuni rami appare questo dettaglio). Usando questa valutazione, l’algoritmo può potare i rami che sembrano allontanarsi dall’uscita e approfondire quelli promettenti. In ambito accademico, Yao et al. (2023) hanno dimostrato che Tree-of-Thoughts può risolvere puzzle e problemi di pianificazione che i normali LLM faticano a completare, evidenziando come questa tecnica renda l’AI più vicina a un problema solver generale deliberativo. Anche se attualmente è una frontiera sperimentale, illustra il potenziale delle future interfacce di prompt engineering: non solo chat o singole richieste, ma vere e proprie esplorazioni guidate delle capacità del modello.

Retrieval-Augmented Generation (RAG)

Cos’è e principi di base: La Retrieval-Augmented Generation (RAG) è una tecnica che combina i modelli generativi con sistemi di recupero di informazioni esterne per migliorare accuratezza e attualità delle risposte. In un flusso RAG tipico, alla domanda dell’utente l’AI effettua prima una ricerca in una base di conoscenza (database, documenti, web, ecc.) per recuperare i contenuti più pertinenti, e poi genera la risposta condizionata su quei contenuti. In altre parole, il modello non si affida solo alla conoscenza immagazzinata nei propri parametri, ma la integra con informazioni fresche o specifiche prelevate al momento. Questa tecnica può essere vista come un “open book approach” in cui il modello ha un libro aperto (la knowledge base) da cui può consultare i fatti prima di rispondere, invece di rispondere “a memoria”. RAG non è un singolo algoritmo ma un’architettura: tipicamente coinvolge un componente di retriever (spesso un motore di ricerca semantica o un indice vettoriale) e un componente di reader/generator (l’LLM) che utilizza i risultati della ricerca per formulare l’output.

Contesti di utilizzo efficaci: RAG è indicato praticamente ogni volta che:

  • Si richiedono informazioni fattuali aggiornate o di dominio specifico che il modello potrebbe non conoscere di suo. Ad esempio domande su eventi accaduti dopo la data di addestramento del modello (es: “Chi ha vinto l’Oscar come miglior film nel 2024?”), o domande molto specialistiche (es: “Qual è la formula chimica del tal farmaco presente nel database X?”).

  • Document QA: l’utente vuole interrogare una collezione di documenti (manuali, contratti, articoli scientifici). Un sistema RAG può cercare nei documenti rilevanti e poi rispondere citando le parti trovate.

  • Chatbot aziendali su conoscenza interna: per costruire un assistente che risponde su policy aziendali, schede prodotto, dati interni, è impensabile addestrare ex-novo un modello su quei dati (troppo costoso e rischioso). RAG consente di mantenere un corpus di documenti aziendali e far sì che l’AI li consulti al volo per rispondere ai dipendenti o clienti con riferimenti precisi.

  • Assistenza decisionale: in cui vogliamo che l’AI fornisca non solo un’opinione, ma anche le fonti. Esempio: “Mi consigli un investimento azionario?” – un assistente RAG potrebbe recuperare gli ultimi dati di mercato e notizie sulle aziende prima di elaborare una risposta, così da essere fondato su evidenze.

Vantaggi: Il RAG migliora significativamente l’accuratezza e l’affidabilità delle risposte, perché le ancora su fonti reali. Questo riduce le allucinazioni: invece di inventare, il modello può dire cose come “Secondo <documento X> …” riportando contenuti veritieri. Un grande vantaggio è la capacità di aggiornamento: la knowledge base può essere costantemente aggiornata (pensiamo alle notizie del giorno, o ai dati di vendita settimanali) senza dover ri-addestrare il modello AI. Ciò risolve uno dei limiti principali degli LLM statici, ossia la loro conoscenza ferma alla data di training. Inoltre, RAG consente trasparenza e verificabilità: spesso i sistemi RAG forniscono le fonti a corredo della risposta (ad esempio citazioni o link ai documenti da cui hanno tratto l’informazione). Questo è fondamentale per la fiducia: l’utente può controllare e confermare se la risposta è supportata da fonti autorevoli. Dal punto di vista pratico, RAG è efficiente: evita di dover ingurgitare nel prompt una mole enorme di contesto (si recupera solo ciò che serve) e scala meglio, perché si può aumentare il knowledge store senza appesantire il modello stesso. Infine, RAG diminuisce il bisogno di training continuo dell’LLM su nuovi dati: l’azienda può mantenere un repository delle informazioni e l’LLM rimane generale, interrogando quel repository. Ciò comporta benefici economici (meno fine-tuning) e anche di sicurezza: i dati sensibili rimangono nel database e non necessariamente dentro i pesi del modello, riducendo il rischio che l’AI li “trapeli” in output inappropriati.

Limiti: Un sistema RAG è più complesso di un modello standalone: bisogna avere un buon modulo di retrieval. Se la ricerca fallisce (ad esempio non trova i documenti giusti o recupera testi irrilevanti), la generazione sarà scadente. Quindi, la qualità delle risposte dipende fortemente dalla qualità dei dati e dell’indicizzazione. Inoltre, l’LLM deve essere capace di integrare bene le informazioni recuperate: c’è il rischio che ignori le fonti (specialmente se non opportunamente istruito) e dia comunque una risposta di fantasia, oppure che le usi male (ad esempio citando un fatto fuori contesto). Bisogna quindi affinare i prompt in modo che il modello “legga e utilizzi” effettivamente i documenti forniti. Un’altra sfida è gestire informazioni contraddittorie: se il retriever pesca documenti discordanti, il modello potrebbe confondersi o dover decidere quale è corretto – cosa non banale. Sul piano computazionale, c’è un overhead dovuto al retrieval (che può implicare ricerca full-text o vettoriale su larga scala) e alla necessità di inserire i testi trovati nel prompt di generazione (consumando token). Per knowledge base piccole è trascurabile, ma su scala web o di grandi dataset ciò richiede infrastrutture robuste (motori di ricerca interni, embedding semantici, ecc.). Dal punto di vista dell’utente, RAG introduce una dipendenza: serve mantenere aggiornata e di qualità la base di conoscenza, il che comporta un lavoro continuo (ad esempio upload di nuovi documenti, pulizia di quelli obsoleti). In sintesi, RAG sposta parte del problema dall’AI ai dati: “garbage in, garbage out” rimane vero – se i documenti sono sbagliati o mancanti, l’AI non potrà fare miracoli.

Esempio pratico: Un esempio comune è l’integrazione di GPT con Wikipedia. Immaginiamo una domanda: “Qual è la capitale più popolosa del mondo e qual è la sua popolazione?”. Un LLM standard potrebbe sapere che è Tokyo (metropoli) o Beijing a seconda di come interpreta, ma potrebbe confondersi o non avere dati precisi di popolazione. Un sistema RAG farebbe:

  1. Query di ricerca: estrarre le keyword “capitale più popolosa mondo popolazione” e cercare in Wikipedia (o in un indice apposito).

  2. Documenti recuperati: ad esempio la pagina “Tokyo” o una classifica di città per popolazione.

  3. Prompt generativo: fornire all’LLM un contesto tipo: “Usa le seguenti informazioni per rispondere: [estratto della pagina Tokyo con dati popolazione] [estratto pagina sulle megalopoli] Domanda: Qual è la capitale…?”.

  4. Risposta generata: “La capitale più popolosa del mondo è Tokyo, con una popolazione di circa 37 milioni di abitanti nella sua area metropolitana.” (L’AI include magari la citazione della fonte se configurato per farlo).

Notiamo che la risposta è ora grounded: l’AI non ha inventato il dato, l’ha preso dalla fonte. Ciò è verificabile e, salvo errore nella base, corretto. In questo caso RAG ha permesso al modello di superare un limite (i dati demografici esatti) recuperando l’informazione aggiornata. Sistemi come Bing Chat, il motore di ricerca di Bing con GPT-4, funzionano essenzialmente in questo modo: eseguono ricerche sul web e poi generano risposte combinando i risultati, citando le fonti. Anche in ambito enterprise, soluzioni di cognitive search e assistenti su documenti aziendali adottano RAG per garantire che l’AI dica cose supportate dai documenti forniti. In definitiva, RAG rappresenta un approccio pragmatico per unire la capacità generativa dei LLM con la precisione dei sistemi di ricerca, ottenendo il meglio da entrambi.

Ci sono prompt per tutto, ma non un prompt per tutti.

Le tecniche di prompt engineering, dal prompt chaining alle varianti zero-shot e few-shot, fino ai metodi di ragionamento avanzati come chain-of-thought, ReAct, self-consistency, tree-of-thoughts e all’integrazione con fonti esterne via RAG, mostrano che oggi abbiamo a disposizioen una sorta di cassetta degli attrezzi per ottenere il massimo dai modelli di intelligenza artificiale.

Ciascuna tecnica ha i propri punti di forza e i propri ambiti d’elezione, ma tutte condividono un principio fondamentale: guidare e strutturare l’interazione con l’AI in modo da allineare l’output agli obiettivi dell’utente. In un certo senso, il prompt engineering ci insegna che porre le giuste domande (e farlo nel modo giusto) è tanto importante quanto la potenza del modello stesso.

Dal punto di vista strategico, il ruolo del prompt engineering appare sempre più centrale per un’adozione consapevole dell’AI.

Senza tecniche adeguate, un modello generativo rischia di essere percepito come una “scatola magica” dalle risposte imprevedibili, il che ne limita la fiducia e l’utilità. Al contrario, approcci come il prompt chaining trasformano l’AI in un collaboratore logico, che segue processi trasparenti e verificabili, sui quali possiamo intervenire in itinere. Questo approccio aumenta la fiducia degli utenti e amplifica il valore dell’AI nell’operatività quotidiana, perché si passa da output grezzi a risultati più affidabili e raffinati.

In sostanza, il prompt engineering unisce il meglio del pensiero umano (analitico, strutturato, consapevole degli obiettivi) con la velocità e versatilità di calcolo dell’IA, offrendo il meglio di entrambi i mondi.

Per capitalizzare queste opportunità, diventa importante sviluppare nuove skill conversazionali e progettuali:

  • Conversazionali perché interagire con un’AI è un po’ come dialogare in un linguaggio speciale: saper formulare richieste precise, dare il giusto contesto, suddividere i problemi e persino “pensare” in termini utili per la macchina sono abilità da coltivare.
  • Progettuali perché occorre saper progettare i prompt e i flussi di prompt come si progettano soluzioni software: con logica, modularità, e attenzione all’utente finale. Figure professionali come il Prompt Engineer stanno emergendo proprio per colmare questo spazio, combinando competenze di linguistica, programmazione e design delle informazioni. Ma al di là dei ruoli dedicati (e considerato che non credo alle etichette) è auspicabile che un po’ tutti, dai manager ai creativi, sviluppino almeno in parte queste competenze.

L’adozione consapevole dell’AI significa infatti comprendere quando e come coinvolgere l’intelligenza artificiale nei processi decisionali e creativi, conoscendone i limiti (bias, allucinazioni, esigenze di contesto) e le potenzialità (velocità, capacità di sintesi, generazione di alternative). Il prompt engineering funge da interfaccia critica in questo rapporto uomo-macchina: è lo strumento che ci permette di tradurre gli obiettivi strategici in istruzioni operative per l’AI, e di incanalare l’output dell’AI in risultati di valore. Man mano che i modelli diverranno più potenti e diffusi, il prompt engineering evolverà di pari passo, potenzialmente automatizzando alcune parti (ad es. con sistemi che suggeriscono come formulare i prompt) ma richiedendo comunque una supervisione e una creatività umana nel definire problemi e interpretarne le soluzioni.

Investire del proprio tempo in sperimentazione di prompt e analisi, vuol dire investire in alfabetizzazione AI: imparare a “parlare” con le macchine intelligenti in modo efficace. Così come l’avvento dei computer ha reso importante saper programmare o utilizzare certi software, l’era dell’AI generativa renderà fondamentale saper orchestrare conversazioni e flussi con i modelli. Le aziende che svilupperanno per tempo queste capacità potranno sfruttare l’AI in modo più affidabile e innovativo, mentre gli individui che le coltiveranno diventeranno preziosi facilitatori tra tecnologia e business.

Guidare l’AI con consapevolezza e metodo è la chiave per integrarla come alleato nei nostri processi – un alleato veloce, instancabile e creativo, ma che necessita della giusta guida umana per dare il meglio di sé. In questo equilibrio di ruoli risiede il futuro di una collaborazione uomo-AI realmente efficace e fidata.

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.