Tag: inferenza

AI & GENAI, TECH & BUSINESS

Baseten a 13 miliardi e il paradosso dell’inferenza a basso costo

Il 18 giugno il Wall Street Journal ha scritto che Baseten sta chiudendo un round da 1,5 miliardi di dollari, con una valutazione che arriva fino a 13. Quattro giorni dopo l’azienda lo ha confermato: Series F, guidato da Altimeter, Conviction e Spark Capital. A gennaio la stessa Baseten valeva 5 miliardi, a settembre 2025 ne valeva poco più di due. Sei volte tanto in nove mesi, per una società che non costruisce modelli e non vende intelligenza propria, ma si occupa di farli girare bene una volta che qualcun altro li ha addestrati.

Ecco quello che mi ha fermato, e non è la cifra. Il capitale si sta spostando dalla parte spettacolare dell’AI, l’addestramento dei modelli, a quella operativa, l’inferenza: il lavoro ripetitivo e poco fotogenico di rispondere, milioni di volte al giorno, a chi fa una domanda. La scommessa di Baseten è che lì, sul costo di quel lavoro, ci sia il margine. La domanda che mi porto dietro è un’altra: una valutazione da 13 miliardi su un’infrastruttura che vende risparmio è il segno che il mercato sta maturando, o l’ennesima curva troppo ripida di una corsa all’oro?

L’inferenza è il livello meno glamour dello stack

Nessuno apre una demo vantandosi della latenza. L’addestramento ha preso quasi tutta l’attenzione degli ultimi anni perché era spettacolare, cluster enormi, GPU introvabili, miliardi bruciati per tirare su un modello più grande del precedente. Poi il modello esce, arriva il primo cliente vero, e la bolletta comincia a contare. L’inferenza è quel momento lì, quando il modello smette di essere una promessa e deve produrre una risposta utile, in fretta, a un costo che regga. È lo strato in cui l’intelligenza tocca davvero la persona, ed è lo stesso strato in cui un’azienda scopre se i conti tornano. In Pelle Digitale ho provato a raccontare proprio questa frontiera, la pellicola sottile dove la tecnologia diventa esperienza per chi la usa. Baseten vive lì, prende modelli, spesso open source, e li serve su una rete multi-cloud che oggi processa più di un miliardo di chiamate al giorno, distribuite su 87 cluster e 18 cloud diversi.

Da 2,15 a 13 miliardi in nove mesi

La cadenza degli aumenti è da capogiro. Series D a settembre 2025, valutazione 2,15 miliardi. Series E a gennaio, 5 miliardi, con dentro anche Nvidia. A maggio si parlava già di un round vicino al miliardo a una pre-money di 11. A giugno il round si gonfia a 1,5 miliardi fino a 13. Il fatturato segue una traiettoria altrettanto verticale, dal run-rate annualizzato di circa 200 milioni a 600 nell’arco di un trimestre, una crescita che molti raccontano come ventiplicata anno su anno. Tra gli investitori storici ci sono Greylock, IVP, CapitalG e la stessa Nvidia, che a gennaio aveva messo 150 milioni. Resta che a 13 miliardi parliamo di un multiplo sui ricavi vicino a 22 volte, e un multiplo del genere racconta molto più le aspettative sul futuro che i conti di oggi.

Il prezzo per task conta più del prezzo per token

La tesi di chi mette i soldi è abbastanza diretta. I modelli open source sono diventati buoni abbastanza da rendere superfluo, per molti casi d’uso, pagare il sovrapprezzo di un modello proprietario. Alcuni clienti di Baseten, da Cursor a Mercor a OpenEvidence, dichiarano di spendere circa un terzo di quanto costerebbe loro un’API chiusa. Se quel dato regge, l’unità della competizione cambia: non è più il modello migliore a fare la differenza, è la capacità di consegnarlo veloce e a basso costo. Ne avevo scritto la settimana scorsa a proposito della guerra dei prezzi dell’AI certificata dal Wall Street Journal, dove i volumi corrono verso il basso costo mentre la spesa resta alla frontiera. Baseten è l’altra faccia di quella dinamica, il venditore di pale e picconi per chi non vuole restare incastrato dentro un solo fornitore. Together AI, Fireworks, Modal Labs giocano la stessa partita, e Fireworks starebbe trattando un round a 15 miliardi. Il fondatore Tuhin Srivastava la riassume così: se il cloud è stato la base della generazione precedente di grandi aziende tecnologiche, l’inferenza è la base della prossima. Intanto Baseten ha firmato un accordo di collaborazione con AWS e ha comprato Parsed, una startup di post-training, segno che vuole presidiare tutto il ciclo di vita del modello, non solo il momento della risposta.

Due prezzi nello stesso round

C’è un dettaglio nella struttura del round che dice più della cifra. È diviso in due fasce, alcuni investitori entrano a una valutazione di 11 miliardi, altri pagano 13. È un meccanismo diventato comune nei mega-round del 2026, serve a sbandierare il numero più alto tenendo dentro chi vuole un prezzo d’ingresso più cauto. Lo si può leggere in due modi. Come ingegneria finanziaria che gonfia il titolo, oppure come fotografia fedele di quanto sia diventato difficile mettere d’accordo investitori con appetiti di rischio diversi sullo stesso asset. Tra i nomi del round c’è Wellington Management, un gestore di lungo periodo, non esattamente la firma che ti aspetti quando si parla di schiuma speculativa. La sua presenza è la texture che complica la storia comoda della bolla. A 13 miliardi Baseten viene prezzata come un pezzo della macchina che i team di AI non possono permettersi di sbagliare, più che come un fornitore qualsiasi seduto tra i cloud e i modelli.

Una corsa all’oro è sempre una bolla?

Quindici anni fa scrivevo di un’altra ondata di valutazioni che sembravano slegate dai fondamentali, quella dei social network e delle prime startup mobile, e mi chiedevo se i numeri avessero senso. Molti di quei numeri non lo avevano, alcune di quelle aziende sono sparite, altre sono diventate l’infrastruttura su cui viviamo adesso. La storia della tecnologia raramente sceglie tra bolla e rivoluzione, di solito fa le due cose insieme, gonfia troppo e nello stesso movimento costruisce qualcosa che resta. L’inferenza ha però una caratteristica che la distingue dalla speculazione pura, assomiglia più a una bolletta che a una puntata, torna ogni volta che un utente fa una domanda, a prescindere dall’umore del mercato. Questo non mette al riparo Baseten dal rischio che gli iperscalari, Amazon su tutti, decidano di tirare l’inferenza dentro le proprie piattaforme e schiaccino i margini dello specialista. Spiega però perché un asset manager prudente sceglie di entrare adesso.

Il test vero arriva dopo, quando i soldi saranno atterrati e i clienti dovranno decidere, bolletta alla mano, se affidarsi a Baseten costa davvero meno che cavarsela da soli. A quel punto sapremo se quei 13 miliardi erano la misura di un’infrastruttura diventata essenziale o il prezzo di una puntata fatta nel momento più caldo del ciclo. Per adesso l’unica cosa certa è dove il mercato sta mettendo i soldi veri.

Fonti: TechCrunch, AI inference startup Baseten reportedly raising $1.5B; Baseten, Raises $1.5 Billion to Power the Next Era of AI Inference (comunicato ufficiale). Dati sul round riportati in origine dal Wall Street Journal.

AI & GENAI, TECH & BUSINESS

Model router: come funziona il middleware che smista le richieste AI

Tra l’applicazione e i modelli è comparsa una casella che diciotto mesi fa non esisteva. Si chiama model router, intercetta ogni richiesta e decide quale modello deve rispondere prima che la richiesta parta, e nel giro di pochi mesi ha sviluppato un mercato suo, con prodotti commerciali, progetti open source e paper accademici che se la contendono.

Il 2 luglio scrivevo che il router viene prima del modello, riprendendo un’osservazione di Tomasz Tunguz: la logica di instradamento, non il modello scelto per ultimo, determina costi, latenza e chi resta padrone dell’infrastruttura. Quel pezzo era la tesi. Questo è la mappa: come quella casella si costruisce dentro, chi la vende già pronta, e il vincolo che quasi nessuno disegna nel diagramma.

Regole scritte a mano, regole imparate

Le architetture di model router in circolazione si riducono a quattro famiglie, e conoscerle serve perché ognuna sposta il compromesso tra costo, latenza e qualità in un punto diverso.

La più semplice è quella euristica: regole fisse, parole chiave, lunghezza del prompt. Se la richiesta contiene una query SQL, va dritta a un modello da codice, senza che nessun classificatore si accenda. Costa niente e si spiega in una riga, e si rompe appena il traffico esce dai casi previsti da chi ha scritto le regole.

Il gradino successivo è il router appreso, un classificatore leggero, di solito su embedding, che predice quale modello renderà meglio su quella richiesta in base a valutazioni storiche. Qui la qualità del model router dipende interamente dalla qualità dei dati di valutazione con cui è stato addestrato, e questa dipendenza pesa più di qualunque scelta di algoritmo.

Poi ci sono le cascate, che rovesciano la logica: si prova prima il modello economico, un validatore controlla la risposta, e solo se il controllo fallisce la richiesta sale al modello più potente. E infine gli ensemble, dove più modelli lavorano in parallelo sulla stessa richiesta e un giudice algoritmico sintetizza o sceglie. La cascata ottimizza il costo accettando qualche giro in più di latenza, l’ensemble ottimizza la qualità accettando di pagare ogni risposta tre o quattro volte.

Il model router diventa un prodotto da scaffale

Fino a poco fa questa casella la scrivevi in casa. Adesso la compri. OpenRouter ha portato in produzione a giugno Fusion, la versione a scaffale dell’ensemble: la tua richiesta va a un pannello di modelli in parallelo e un giudice fonde le risposte. Sul benchmark di deep research DRACO di Perplexity, un pannello economico composto da Gemini 3 Flash, Kimi K2.6 e DeepSeek V4 Pro ha segnato 64,7%, sopra GPT-5.5 da solo (60,0%) e Opus 4.8 da solo (58,8%), a circa metà del costo della configurazione di punta. Il dato che trovo più istruttivo è un altro, sepolto nello stesso annuncio: fondere Opus 4.8 con sé stesso alza il punteggio da 58,8 a 65,5. È la sintesi a produrre valore, non solo la diversità dei modelli.

Sul versante dei router appresi, Not Diamond vende l’addestramento su misura: carichi i tuoi prompt, i modelli provati e i punteggi delle tue valutazioni, e ne esce un router calibrato sui tuoi criteri, comprese le regole di formattazione o le convenzioni di codice che nessun benchmark pubblico misura. Il prodotto, in pratica, è la trasformazione dei tuoi dati di valutazione in una politica di instradamento.

La via che resta in casa

Chi non vuole un intermediario tra sé e i modelli, per latenza o per riservatezza dei dati, ha alternative open source che nell’ultimo semestre sono maturate in fretta.

NadirClaw è un proxy locale compatibile con l’API OpenAI che parte da un’osservazione empirica: nelle sessioni di sviluppo assistito, il 60-70% dei prompt sono operazioni semplici, letture di file, formattazioni, domande brevi, e non hanno bisogno di un modello premium. Un classificatore su embedding decide in una decina di millisecondi, un motore di ottimizzazione sfronda schemi di strumenti gonfi e array ridondanti prima dell’invio, tagliando il peso in token dal 30 al 70%, e sui benchmark RouterArena il profilo a cascata predefinito segna 0,7358 riducendo la spesa API fino al 70%. Gira sulla tua macchina, con le tue chiavi, e nessuna piattaforma di mezzo può cambiarti le condizioni.

Il fronte accademico spinge un passo oltre. Agent-as-a-Router, il paper dietro il framework ACRouter, parte da una diagnosi precisa: i router statici falliscono per deficit di informazione, decidono una volta e non imparano mai dal risultato. La risposta è un ciclo continuo in cui un orchestratore leggero instrada la richiesta usando lo storico di prestazioni conservato in una memoria interna, e un verificatore valuta l’esito con metriche oggettive, i test unitari sul codice generato per esempio, riscrivendo il risultato nella memoria come esperienza. Il router accumula esperienza fondata sull’esecuzione reale, ed è la stessa architettura del ciclo notturno che descrivevo nel pezzo di luglio, formalizzata e messa alla prova contro modelli di frontiera.

Per chi lavora con l’inferenza dentro il perimetro aziendale, ed è il terreno su cui costruiamo LocalAI, questa famiglia di strumenti è quella che conta: il routing self-hosted è ciò che rende sostenibile l’ibrido, i modelli locali per la maggioranza del traffico, il cloud per ciò che lo giustifica davvero.

Funziona dove il risultato si può misurare

Tutte queste architetture, dalla cascata al ciclo di ACRouter, si reggono su un presupposto che i diagrammi non mostrano: che esista un segnale oggettivo per dire se una risposta è buona. Il codice passa i test o non li passa, il JSON rispetta lo schema o non lo rispetta, la stringa si estrae o no. Dove il segnale è binario, il validatore della cascata sa quando scalare, il verificatore sa cosa scrivere in memoria, e il router impara.

Dove il segnale non c’è, tutto l’impianto si affloscia. Valutare un testo di marketing, un brainstorming aperto, una sintesi il cui pregio è il taglio e non la correttezza: su questi compiti la verifica automatica è debole, e un model router che non sa distinguere una risposta buona da una mediocre instrada alla cieca, con in più il pedaggio di latenza che le catene a cascata e i cicli di validazione si portano dietro per costruzione. Il router aggiunge un premio di complessità allo stack, e non ripara la logica applicativa rotta o il prompting fatto male: sposta i compiti giusti sui modelli giusti, a condizione che qualcuno gli abbia insegnato a riconoscerli.

Il registro dei prompt vale più del modello

Resta la parte che riguarda chi decide, non chi implementa. Il panorama dei modelli cambia ogni settimana, i prezzi per token continuano a scendere, e qualunque scelta di modello fatta oggi sarà rivedibile tra un trimestre. Le due cose che invece restano, e si apprezzano nel tempo, sono i dataset di valutazione interni e lo storico dei prompt con i loro esiti. Sono il carburante di ogni model router appreso, di ogni cascata calibrata, di ogni memoria alla ACRouter, e nessun fornitore può venderteli perché descrivono il tuo lavoro, non il suo.

L’avevo scritto parlando del vantaggio che si accumula in memoria, e il routing ne è la dimostrazione infrastrutturale: un’organizzazione che non registra cosa ha chiesto ai modelli e come è andata non potrà mai instradare bene, con nessuno strumento, comprato o costruito. Il processo di valutazione viene prima del router, come il router viene prima del modello. E mentre l’AI bill shock spinge tutti a cercare la casella magica che abbatte il conto, i dati che servirebbero ad addestrare il vostro model router si stanno raccogliendo adesso, oppure non si stanno raccogliendo affatto. Chi li registra oggi, tra un anno instraderà sulla propria esperienza. Gli altri affitteranno quella di qualcun altro.

Riferimenti: OpenRouter, Surpassing Frontier Performance with Fusion; Zhou et al., Agent-as-a-Router: Agentic Model Routing for Coding Tasks (arXiv); NadirClaw su GitHub; Not Diamond.

AI & GENAI, TECH & BUSINESS

AI bill shock: la bolletta dei token è arrivata, come previsto

Il conto è arrivato, e ha pure un nome. Da mesi, tra le chiamate con i clienti e i pezzi che scrivo, ripeto la stessa cosa: il costo dei token non è un dettaglio da smanettoni, è la prossima voce che finisce sul tavolo del CFO. A marzo lo scrivevo su AI4Business, parlando di governo economico dei token come disciplina ancora da costruire. A maggio, qui sul blog, mettevo per iscritto che sarebbe arrivato sotto forma di budget esplosi a fine mese.

Questa settimana CorCom lo ha chiamato AI bill shock, riprendendo un’analisi di Analysys Mason: la spesa a consumo per modelli generativi, Api e agenti autonomi rende i budget aziendali sempre meno prevedibili, al punto da riportare sul tavolo di molti CIO l’idea di possedere un pezzo della propria infrastruttura invece di affittarla sempre. I numeri sotto contano più del titolo. Il budget è solo la parte più visibile: sotto ci sono i dati, la compliance, il controllo dell’infrastruttura su cui gira la tua azienda.

300 aziende, un balzo del 500%

Tra aprile e maggio circa 300 aziende hanno sollevato la questione dei costi legati ai token durante le chiamate agli investitori sui risultati trimestrali, contro le 93 dello stesso periodo dell’anno precedente. Lo racconta AI4Business citando Paul Roetzer e Mike Kaput del Marketing AI Institute. La Royal Bank of Canada ha visto il proprio consumo di token salire del 500% in sei mesi. Cisco descrive i propri volumi come fuori da ogni norma conosciuta.

Amazon, Walmart, Uber, Cisco e Meta, secondo quanto riportato dal Financial Times e ripreso sempre da AI4Business, hanno già introdotto tetti di spesa o indicazioni più severe su quando vale davvero la pena accendere un modello. Uber ha fissato un tetto di 1.500 dollari al mese per dipendente dopo aver esaurito, già ad aprile, l’intero budget AI previsto per il 2026. Amazon ha spento la classifica interna che misurava quanto i dipendenti usassero l’AI, dopo aver scoperto che alcuni ingegneri facevano girare bot autonomi solo per scalare la graduatoria: è il fenomeno che va sotto il nome di tokenmaxxing, la corsa alla vanità mascherata da adozione.

A Workato, azienda da 1.300 dipendenti, la spesa è aumentata di sette volte in un solo giorno quando Anthropic ha spostato l’azienda su un pricing basato sui token, a maggio. Goldman Sachs Research stima che l’uso degli agenti possa moltiplicare per 24 il consumo di token entro il 2030. E sul mercato aperto dei modelli, secondo i dati di OpenRouter ripresi dal Financial Times, i modelli cinesi hanno già superato quelli americani per consumo di token: quando il prezzo diventa il primo criterio di scelta, a vincere è chi costa meno, non chi segna il punteggio più alto sui benchmark.

Il token non misura il lavoro fatto

Più del volume, a ingannare è la natura della metrica. I fornitori fanno pagare i token di output da due a cinque volte più di quelli di input, perché generare una risposta costa computazionalmente più che leggerla: il modello prevede una parola alla volta, in sequenza, mentre l’input lo processa in un solo passaggio. Due flussi di lavoro che sembrano identici per volume possono avere costi molto diversi a seconda di quanto testo producono rispetto a quanto ne ricevono, e quasi nessuna azienda, quando firma il contratto, ci pensa davvero. Un prompt di 1.500 parole, quasi 2mila token, che produce una sintesi di 600 parole, circa 800 token, costa già un paio di centesimi con un modello come Claude 3.5 Sonnet: sembra nulla, finché non lo moltiplichi per centinaia di richieste al giorno e per ogni team che nel frattempo ha acceso un proprio agente senza dirlo a nessuno.

Gli agenti aggravano la cosa, perché a ogni passaggio ritrasmettono l’intero contesto della conversazione: alla decima fase di un compito, il modello rilegge integralmente le prime nove. AI4Business fa un esempio concreto, quello di un assistente per il servizio clienti che accede a una base di conoscenza di 20mila token: per mille richieste al giorno, genera 20 milioni di token quotidiani solo per rileggere sempre gli stessi dati, circa 60 dollari al giorno spesi prima ancora di rispondere a un cliente vero. Se l’agente si blocca in un loop, o richiama più volte lo stesso strumento, il conto sale prima che qualcuno se ne accorga.

L’AI bill shock non è un problema di cassa

Affidare l’inferenza a un fornitore esterno porta con sé più di un conto a consumo: la sua politica dei prezzi, i suoi limiti di utilizzo, le sue scelte su dove vivono i tuoi dati, la sua libertà di cambiare le regole senza preavviso. Il pricing può cambiare le regole da un mese all’altro, come è successo a Workato quando Anthropic l’ha spostata su un modello a consumo. Un fornitore può introdurre un tetto di utilizzo che scopri solo quando lo tocchi, a metà di una sessione di lavoro, come raccontano diversi utenti citati da AI4Business. Un governo può spegnere l’accesso a un modello, come abbiamo visto succedere quest’anno. E quando arriva un audit di conformità, la domanda su dove sia passato un dato aziendale durante l’inferenza, su quale server, sotto quale giurisdizione, spesso non ha una risposta scritta da nessuna parte.

Bain, in un sondaggio su 951 aziende pubblicato a giugno, trova che quasi il 40% di chi ha misurato i risparmi da AI è rimasto sotto il 10%, contro un obiettivo dichiarato dell’11-20%. Michael Heric, uno degli autori della ricerca, spiega che per molte aziende il business case si ferma alla spesa in token e non arriva mai a contare i costi di data engineering, di governance, di conformità che le girano intorno. Il 90%, nonostante tutto, aumenta comunque il budget per l’anno prossimo, prova che nessuno ha ancora imparato a misurare il ritorno dell’AI con lo stesso rigore con cui ne misura il costo.

LocalAI lavora esattamente in questa direzione: porta l’inferenza dentro il perimetro dell’azienda invece di affittarla ogni mese da qualcun altro. I costi non spariscono: cambia chi li governa. Sai dove vivono i dati, sai quanto costa davvero un carico di lavoro perché lo possiedi, e nessuno può cambiarti il prezzo o il tetto di utilizzo a metà mese.

Dall’opex che non controlli al capex che scegli

Analysys Mason legge lo spostamento come l’ennesimo giro di un ciclo che l’informatica ha già visto: dal mainframe centralizzato ai minicomputer distribuiti, dal PC in rete al cloud che ricentralizza tutto, e ora l’AI che riapre la stessa domanda. Comprare calcolo come servizio o possederne una parte? Per chi ha volumi di inferenza stabili, la risposta pratica passa quasi sempre dall’ibrido: hardware proprio per i compiti che non hanno bisogno di un modello di frontiera, server dedicati o cloud privato per il resto, il cloud pubblico riservato a ciò che lo giustifica davvero.

Il TCO a tre anni tra cloud e on-premise, calcolato sui prezzi reali di Claude, GPT, Gemini e DeepSeek, conferma la stessa cosa: nella maggior parte degli scenari aziendali italiani l’on-premise vince con margine quando i volumi sono prevedibili, mentre il cloud resta la scelta giusta per i picchi occasionali e per chi parte da zero. La maggior parte del traffico di un’azienda, del resto, non ha bisogno del modello più caro: ha bisogno di un sistema che decida bene dove instradarlo. Quella logica di instradamento, non il modello scelto per ultimo, è ciò che decide chi resta padrone della propria infrastruttura.

Decide il board, non il reparto IT

Il sondaggio di Bain lo conferma da un altro lato: le aziende che centrano i risparmi attesi sono quelle che hanno trattato l’accesso ai dati, la governance e il ridisegno dei processi come materia da consiglio di amministrazione, non da reparto IT. Vale lo stesso per il bill shock. Un alert di budget o un tetto di spesa imposto dall’alto sposta il sintomo, non la causa.

La prima domanda, in questi casi, non riguarda mai il modello. Riguarda dove vivono i dati, chi decide quanto vale un’ora di inferenza, cosa succede se domani il fornitore cambia le regole: non cambia molto se l’azienda ha cinquanta o cinquemila dipendenti, cambia solo quanto in fretta un budget fuori controllo diventa un problema di tutti, non solo di chi ha acceso l’ultimo agente.

La bolletta continuerà a salire, per tutti. La differenza, da qui in avanti, la fa chi ha già deciso come governarla e chi la scoprirà solo a budget già bruciato.

Fonti: CorCom su Analysys Mason; AI4Business, “La crisi dei token che spaventa i budget aziendali”; AI4Business, “AI, le aziende frenano”; Bain & Company, Automation and AI Pathfinder Survey 2026.

AI & GENAI, TECH & BUSINESS

Il router prima del modello

Il 1° luglio Tomasz Tunguz di Theory Ventures ha scritto una cosa semplice che quasi nessuno applica: la maggior parte dei team che costruisce agenti sceglie il modello per primo. Sbaglia ordine, e lo sbaglia sistematicamente, perché il modello è la decisione più visibile e quindi quella su cui si concentra tutta l’attenzione, mentre il pezzo che davvero determina costo e latenza resta invisibile: il router, cioè il codice che decide chi risponde a ogni singola richiesta.

Tunguz lo racconta riferendosi al modo in cui Coinbase ha dimezzato la spesa in AI mentre il consumo di token cresceva, non frenando gli ingegneri con alert di budget ma cambiando i default di instradamento. È un’osservazione operativa, non una teoria, e tocca qualcosa che seguo da mesi lavorando con LocalAI: la sovranità computazionale si gioca sull’architettura, molto più che sulla scelta del modello.

Tre problemi diversi, non uno

Classificatore, router e selettore vengono trattati come sinonimi, e non lo sono. Il classificatore riconosce l’intento: trasforma una richiesta grezza dell’utente in un’operazione concreta, riassumere un repository, scrivere una risposta, lanciare una migrazione. Il router legge quell’etichetta insieme a poche feature, complessità, dimensione del contesto, storico di successo, e decide su quale livello far girare l’operazione. Il selettore, infine, sceglie il modello più economico dentro quel livello che rispetta una soglia di confidenza.

Confonderli è comodo mentre si scrive il primo prototipo, e costa caro dopo: la scelta del modello finisce sepolta dentro il prompt, e diventa impossibile testare due modelli diversi sulla stessa operazione senza riscrivere mezzo sistema. È lo stesso errore di livello che ho descritto parlando dello stack verticale dell’AI: confondere i piani porta a decisioni prese al piano sbagliato.

Il locale è gratis, l’asincrono è economico, il tempo reale costa

E infatti è questa la parte che mi ha fatto fermare a rileggere. Il calcolo locale ha un costo marginale prossimo allo zero, il batch asincrono costa due ordini di grandezza meno dell’inferenza in tempo reale, e la parte di lavoro che ha davvero bisogno di una risposta immediata è sorprendentemente piccola, una volta che il sistema può accodare.

Una bozza di risposta, un riassunto di repository, un memo di due diligence, la valutazione notturna di un batch di tracce: nessuno di questi compiti pretende un secondo di risposta. Pretende di essere fatto bene, non subito.

Ho visto questa stessa dinamica dentro LocalAI, dove la maggioranza del traffico non tecnico regge tranquillamente su modelli piccoli fatti girare in locale, con il cloud che entra in scena solo quando il compito lo richiede davvero. Non è un compromesso al ribasso, è disegno.

Un ciclo che impara mentre dorme

Ecco, e qui il design descritto da Tunguz aggiunge un doppio ritmo di feedback che vale la pena isolare. Un predittore sincrono annota ogni richiesta in ingresso con cinque segnali di rischio, dal contesto di repository mancante alle catene di dipendenze troppo lunghe, fino alle scritture che possono avere conseguenze pesanti se sbagliate, e intercetta così i compiti già noti come difficili prima che falliscano.

Poi, ogni notte, un valutatore batch rilegge le tracce del giorno e aggiorna i pesi del router, mentre il costo di quella valutazione resta vicino allo zero perché gira anch’esso in modalità asincrona. Ed è lì che il sistema scopre i modi di fallire che il predittore non aveva ancora imparato a riconoscere.

Mi sembra la versione infrastrutturale di qualcosa che scrivo da tempo a proposito del vantaggio che un’organizzazione accumula in memoria, non in modello: un sistema che non ha un meccanismo per far rientrare l’esperienza di ieri nelle decisioni di oggi accumula lo stesso tipo di debito, che si parli di persone o di router. L’ho scritto anche a proposito del tokenmaxxing: quel che resta dopo la spesa pesa più del numero speso, che si tratti di token o di traffico instradato.

Da dove si comincia davvero

Nei progetti dove entro a lavorare sull’adozione dell’AI, il primo intervento quasi mai tocca il modello. Tocca l’inventario dei segnali di fallimento: quali richieste arrivano senza contesto sufficiente, quali toccano dati sensibili, quali scritture, se sbagliate, costano care da correggere. Prima si rende visibile quel rischio, poi si decide dove instradarlo.

È un lavoro lento e poco fotogenico rispetto a scegliere l’ultimo modello uscito, e proprio per questo tende a restare indietro nella lista delle priorità. Ma un router costruito senza quella mappa dei rischi impara a fatica, perché non sa cosa sta effettivamente evitando di rompere. Il ciclo notturno di cui scrive Tunguz funziona solo se qualcuno, all’inizio, ha scritto a mano la prima versione grezza di quella mappa.

Chi possiede la logica di instradamento

Se il novanta per cento del traffico può girare su modelli piccoli e locali, la dipendenza da un singolo fornitore cloud smette di essere un fatto tecnico e diventa una scelta di governance, quasi sempre presa per default e non per decisione consapevole.

Progettare intorno al routing, non intorno al modello, sposta il controllo esattamente lì: chi scrive la logica che manda il traffico da una parte o dall’altra decide, di fatto, chi resta padrone dell’infrastruttura. Nella maggior parte delle aziende che conosco quella logica non la possiede nessuno davvero: cresce dentro il notebook di un ingegnere, non dentro un comitato di governance. Ed è lì, non nel modello scelto per ultimo, che si decide chi dipende da chi.

Spunto: Tomasz Tunguz, General Partner at Theory Ventures.

TECH & 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.

AI & 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.