Google ha esteso Gemini Enterprise Agent Platform con un sistema multi-agente che orchestra il recupero di informazioni invece di fermarsi alla prima ricerca utile. Google Research ha pubblicato il framework Agentic RAG l’8 giugno, riportando un aumento di accuratezza fino al 34% sui dataset di factuality rispetto al RAG tradizionale, su query multi-hop tipiche dei workflow enterprise. Il RAG tradizionale risponde con quello che trova, l’Agentic RAG continua a cercare finché non ha abbastanza contesto, e questo cambia la geometria delle implementazioni aziendali in corso.
Il RAG classico, di cui Tom’s Hardware aveva già raccontato la portata strategica per le aziende italiane, fa una ricerca semantica, recupera i frammenti più simili alla domanda, e li passa al modello che genera una risposta. Quando l’informazione è sparsa su più sistemi (CRM, ERP, intranet, allegati email, knowledge base prodotto), la singola ricerca cattura solo una parte, e il modello risponde con dati parziali o dice di non sapere. L’Agentic RAG affronta il problema costruendo una catena di ricerche guidate da agenti specializzati, ciascuno con un ruolo preciso nella pipeline.
Tom’s Hardware ha già spiegato che l’AI aziendale deve andare oltre il RAG tradizionale proprio perché i meccanismi di prima generazione sono pensati per recuperare e sintetizzare, non per analizzare e aggregare grandi volumi documentali. Google riconosce esattamente questo limite e prova a superarlo. L’innovazione non sta nell’idea, sta nell’orchestrazione: comporre agenti specializzati in pipeline che si auto-valutano fa la differenza.
Come funziona la pipeline multi-agente
Il sistema include quattro componenti principali, ciascuno con un compito separato.
- Query planner: decompone la domanda complessa in sotto-richieste atomiche. La query “qual è stato il margine del prodotto X nell’ultimo trimestre rispetto allo stesso trimestre dell’anno scorso, e quali clienti hanno contribuito di più al ricavo” diventa quattro o cinque richieste più piccole;
- Routing agent: assegna ogni sotto-richiesta alla fonte dati più adatta (database SQL per i numeri, knowledge base per la documentazione di prodotto, file system per i contratti firmati, API esterne per benchmark di mercato);
- Sufficient context agent: il pezzo nuovo del sistema. Valuta se le informazioni raccolte sono sufficienti a rispondere con accuratezza, oppure se serve un’altra iterazione di ricerca. È questo agente che alza l’accuratezza, perché toglie al modello la pressione di rispondere quando i dati sono incompleti;
- Synthesis agent: aggrega i risultati in una risposta coerente, con citazioni delle fonti che l’hanno alimentata. Ogni paragrafo è riconducibile alla sorgente specifica, e questo è cruciale per audit di compliance e governance.
La feature è in public preview su Gemini Enterprise Agent Platform. Il dato di accuratezza si riferisce a query multi-hop tipiche dei workflow enterprise, dove il salto tra una fonte e l’altra è esattamente quello che il RAG di prima generazione fatica a fare.
La risposta sbagliata costa cara. La risposta che continua a cercare costa il tempo del retrieval.
Il problema della memoria che Google indirizza in parte
Una difficoltà specifica resta sul tavolo. Tom’s Hardware ha già raccontato che il milione di token di context window è un miraggio, l’AI è ancora smemorata: a un certo punto del flusso, anche un sistema multi-agente perde traccia delle decisioni intermedie e produce risposte incoerenti con le proprie premesse. L’Agentic RAG di Google attenua il problema con il sufficient context agent, ma non lo risolve completamente. Per workflow lunghi e con molti passaggi intermedi, la combinazione di RAG agentico e knowledge graph esplicito resta superiore a qualsiasi sistema basato solo su context window grande.
Cosa cambia per chi sta progettando RAG in azienda
Molte aziende italiane hanno cominciato a costruire RAG interni per knowledge management, supporto clienti, ricerca contrattuale, supporto al middle management nei processi di analisi. La maggior parte di questi progetti ha incontrato gli stessi due limiti: le risposte sono buone su domande semplici e diventano povere o sbagliate su domande complesse che attraversano più fonti dati. L’Agentic RAG di Google indirizza esattamente questo limite, e i vendor italiani di knowledge management dovranno reagire o perdere quote di mercato nei prossimi sei-dodici mesi.
Tom’s Hardware ha già spiegato che la scelta del modello giusto per il compito vale più della potenza assoluta. Il principio si estende all’architettura: un sistema multi-agente con modello base intermedio batte un sistema mono-agente con modello frontier, perché la pianificazione delle ricerche compensa i limiti di ragionamento del singolo modello, e perché i costi di compute scalano meglio quando il lavoro è suddiviso tra agenti specializzati ciascuno con scopo limitato.
Per chi valuta vendor di knowledge management AI, la novità ha tre conseguenze tecniche e contrattuali distinte. Primo: i sistemi RAG di prima generazione, basati su singola ricerca + LLM, perdono terreno e andranno aggiornati nei prossimi 12 mesi. Chi ha già firmato contratti pluriennali su soluzioni di prima generazione dovrà negoziare upgrade gratuiti o rinegoziare le condizioni. Secondo: vendor diversi adotteranno architetture agentiche con denominazioni diverse (Agentic RAG, GraphRAG, Cross-Corpus Retrieval, MCP Orchestrator), ma la sostanza è simile e va valutata sul terreno della precisione misurata, non del nome commerciale. Terzo: il costo per query sale, perché il sistema multi-agente fa più chiamate al modello, e i contratti devono essere ridiscussi su volumi attesi con clausole di tetto di spesa mensile.
C’è un punto di governance che molte aziende sottovalutano. Un sistema agentico che fa ricerche autonome su database aziendali è, di fatto, un dipendente con accesso a dati sensibili. Tom’s Hardware ha già raccontato che gli agenti AI vanno trattati come dipendenti ad alto rischio, con identità propria, permessi minimi, log immutabili delle azioni, possibilità di revoca immediata. L’Agentic RAG di Google supporta questi controlli tramite IAM di Google Cloud, ma serve disciplina per usarli davvero.
Tom’s Hardware ha anche segnalato che l’agente AI non ha una forma, ha dei percorsi: è il workflow che lo definisce, non il modello sottostante. Per chi acquista oggi un sistema Agentic RAG, la domanda da fare al vendor non è “quale modello usate” ma “quali percorsi sono possibili e quali sono vietati per default nella vostra configurazione”. È una conversazione di sicurezza, non di feature commerciali.
La sovranità sui dati passa anche dalle architetture di retrieval, non solo dai modelli.
L’alternativa europea esiste, ma con limiti
Per chi vuole restare in casa europea, esistono alternative al framework Google. Mistral francese, Cohere canadese e progetti open source come LangGraph permettono di costruire architetture multi-agente equivalenti, anche se senza l’integrazione nativa di Gemini Enterprise. La scelta dipende dalla disponibilità interna di competenze di ingegneria AI: comprare la suite Google integrata costa di più ma elimina lo sviluppo, costruire con tool open richiede team capaci di gestire orchestrazione e debugging, ma garantisce indipendenza e portabilità tra provider cloud.
Le PMI italiane senza un team AI interno solido pagheranno comunque il Google. Le aziende mid-market e gli atenei con competenze di sviluppo possono valutare lo stack open source, ottenendo risparmi del 40-60% sul costo totale di gestione, ma allungando i tempi di go-live di sei-dodici mesi. La scelta non è banale, e va condotta su un proof of concept reale con dati aziendali, non su demo del vendor.
L’argomento controfattuale
Si potrebbe ribaltare la lettura della mossa Google. L’Agentic RAG è il modo per rendere ancora più dipendenti i clienti enterprise dalla suite Gemini, in un momento in cui le alternative open stanno maturando rapidamente. L’osservazione regge per chi pesa con cura il fattore vendor lock-in, e suggerisce di tenere almeno un proof of concept parallelo su stack open source che possa diventare alternativa se i prezzi enterprise di Google dovessero salire troppo nei prossimi rinnovi contrattuali. Il rischio non è ipotetico: in passato Google ha più volte cambiato unilateralmente le condizioni dei propri servizi enterprise, e la traiettoria recente di Gemini Enterprise suggerisce che la pressione sui margini arriverà anche qui.
La risposta corretta non è “non comprare Google”, è “comprare Google con un piano B documentato”. Il vendor lock-in più rischioso è quello che il cliente non vede e non misura, e l’unico antidoto sistematico è mantenere un’architettura interna che permetta di sostituire i pezzi quando il prezzo non torna più.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Davide Greco
Source link
