Sbagliando s’impara: un proverbio sempreverde, che trova un suo significato anche nell’uso che facciamo quotidianamente dei Large Language Model (LLM). Fin dai primi utilizzi di GPT, siamo stati travolti da emozioni contrastanti, uno strumento dalle potenzialità immense, ma con allo stesso tempo grandi limiti, dalla conoscenza fissata a uno specifico momento nel passato a una incapacità di compiere azioni all’infuori del produrre testo.
Indice degli argomenti:
Il motore di tutto: l’esplorazione
Un po’ come un bambino alle prese con un nuovo gioco, un po’ come presi da una sorta di impazienza ci siamo messi a testa bassa a testare l’uso di LLM in tantissimi contesti.
OpenAI ha rilasciato un paper dal titolo “How People Use ChatGPT” [1] , in cui si dice che l’adoption a livello mondiale è arrivata al 10% della popolazione, un numero veramente notevole. Inoltre, è molto interessante il fatto che la percentuale di utilizzo maggiore è relativa a “non-work usage”. Questo articolo ci fornisce una prova su quanto l’uso di LLM stia diventando pervasivo all’interno della nostra società, non solo in ambito lavorativo ma anche nella vita comune.
L’uso intenso abilita l’esplorazione, la quale ha permesso in poco tempo di superare tanti dei limiti iniziali degli LLM, l’in-context-learning, ad esempio, ha abilitato la capability dell’imparare da esempi forniti. La RAG (Retrieval Augmented Generation) né è stata una naturale evoluzione, e ha permesso ai modelli di accedere a conoscenza sempre nuova e mai vista prima.
Un grande limite: il modello deve fare tutto in un singolo step
Immaginiamo di trovarci di fronte a un task di questo tipo: calcolare l’età cumulativa delle città più vecchie di ogni regione d’Italia [2]. Un LLM con un prompt avanzato, così come sistemi RAG, tenderanno a fallire task di questo tipo; in linea generale il limite è dettato dal fatto che task complessi richiedono di essere suddivisi ed eseguiti per step. Una prima idea in questo senso è stata la CoT (Chain of Thought), in cui tramite esempi si cerca di instillare un ragionamento logico al modello nei confronti di un problema, lo si guida negli step da fare per arrivare alla conclusione. Indiscutibilmente una buona idea, che però prevede di avere tutte le informazioni subito disponibili, e sappiamo che spesso non è così; il reasoning non è sempre sufficiente, servono azioni, serve abilitare il modello all’interazione con l’ambiente in cui si trova.
È qui che si forma il concetto di agenti, dagli “action agents” in grado di decidere quali azioni compiere in un certo ambiente [3] ai più famosi ReAct (Reason + Act) Agents [4], che combinano i concetti di Chain of Thought con quello del compiere azioni. Si abilita quindi il modello all’uso di una serie di tools o funzioni in grado di svolgere compiti ben precisi in modo deterministico e tramite la CoT si istruisce il modello sul come usarli al meglio.
Il futuro è agentico?
Il paragrafo precedente sembra indicare una direzione ben precisa, gli agenti e tutte le loro declinazioni ci apriranno le porte del futuro, eppure, al di fuori di tanti sensazionalismi, online si trovano report e articoli riguardo i fallimenti di progetti AI, e in particolare di AI generativa nelle aziende.
Per prendere un esempio concreto, nel report “The GenAI Divide: State of AI in Business 2025” realizzato dal MIT [5], si cita addirittura una percentuale di fallimento dei progetti pilot vicina al 95%, fallimento inteso come incapacità di produrre ritorno facilmente misurabile.
Il report non si ferma alla percentuale, ma cerca anche di dare una spiegazione a questi risultati: il problema principale non sta nella tecnologia, ma piuttosto nella modalità di adozione, spesso è la mancanza di una adeguata strategia a dettare il fallimento.
La storia in qualche modo si ripete sempre, così come per i progetti più legati al machine learning, anche per i progetti di AI Generativa i tasselli principali per arrivare al successo sono sempre legati a questi punti fondamentali:
- Definire in modo chiaro gli obiettivi che si vogliono raggiungere, che può voler dire anche non usare un modello generativo. Partire dal problema dunque.
- Stabilire chiare metriche con cui valutare la buona riuscita di un progetto, non per forza il ritorno deve essere solo economico (e.g. più customer satisfaction, miglioramenti operativi di certi processi, ecc.)
- Assicurarsi che i dati con cui si vuole lavorare siano puliti e di facilmente integrabili (l’avrete già letta questa frase, si ripete sempre perché è vera)
- Settare le aspettative sull’effettivo output che si potrà ottenere
- Esplorare e sbagliare per poi ritentare.
Come costruire agenti efficaci
Fin qui abbiamo compreso come gli agenti siano in grado di abilitare i Language Model alla risoluzione di task complessi, allo stesso modo però abbiamo anche detto che gran parte dei progetti pilot non va a buon fine. Dopo un primo momento di hype, anche in questa fase si è iniziato ad osservare i comportamenti degli agenti in vari task e contesti, e con questa esplorazione sono emersi diversi spunti interessanti, dal famoso blog di Anthropic dal titolo “Building Effective Agents” [6] al whitepaper di Google [7], per finire con la guida di OpenAI [8].
Insomma, tutti i più importanti player hanno detto la loro sul cosa significhi agente, e su quali best practice adottare al fine di ottenere buoni risultati.
Sembrerà banale, ma i punti cruciali che emergono sono sempre votati alla semplificazione:
- Non è sempre necessario usare agenti, intesi come sistemi in grado di pianificare autonomamente la risoluzione di un task, al contrario, in tanti casi, workflow ben definiti e controllabili sono sufficienti.
- Usare librerie di alto livello può permettere di raggiungere facilmente Mvp, ma in molti casi i layer di astrazione aggiuntivi rendono difficile comprendere i casi di fallimento. Dunque, un vantaggio iniziale può diventare uno svantaggio domani, implementare “from scratch” o limitarsi a librerie esterne solo quando necessario è preferibile.
- Dare importanza al monitoring, ovvero tenere traccia del flusso che ha portato l’agente a risolvere un task, dai tools invocati, alle osservazioni fatte dall’LLM. Capire quando non va, aiuta a migliorare prompt e flusso.
Perché i sistemi multi-agent falliscono?
Questo paragrafo è preso dal titolo di un paper di Berkeley, che parte da una frase emblematica: “Successful systems all work alike, each failing system has its own problems.”
Il discorso si complica, siamo partiti a inizio articolo parlando dei limiti di un singolo prompt e un singolo LLM, per arrivare qui a sistemi di agenti che devono comunicare e interagire tra loro per risolvere task complessi e potenzialmente lunghi.
Di nuovo siamo presi dalla foga di sfruttare in ogni salsa i nostri nuovi agenti o workflow facendoli lavorare assieme, ma nonostante un adoption crescente, nella ricerca si osserva come il guadagno in termini di performance rimanga minimale comparato ai sistemi single agent, oltre al fatto che le percentuali di failure rate sono elevate. L’importanza di questo paper sta nel fatto che si propone di redigere una tassonomia delle varie failure modes, magari non completa ancora ma sicuramente fondamentale come strumento di analisi e debugging.
La ricerca mostra che il 41% delle failure arriva da errori legati al fatto che gli agenti non comprendono a fondo il task, il 37% da “inter-agent misalignment”, ovvero da problemi di comunicazione tra i vari agenti (e.g. fallimenti nel chiedere chiarimenti, mismatch tra reasoning e azioni intraprese, reset di conversazioni, input sbagliati, ecc.); infine, un 21% è legato al verification gaps, ovvero mancano controlli sul fatto che il lavoro sia effettivamente terminato.
Pensandoci a fondo, non è forse ciò che succede anche nei progetti assegnati a un gruppo di persone, che sia al lavoro o che sia a scuola, quante volte vi è capitato che qualcuno non comprendesse a fondo il task, o una parte di esso, o ancora, quante volte non ci si è capiti e si è fatto in due lo stesso lavoro.
Al di là della indiscutibile difficoltà del fare funzionare assieme sistemi multi-agente, spesso il vero problema è il come noi persone cerchiamo di traslare problemi in codice.
Quale direzione stiamo prendendo
Nel paragrafo precedente si sono individuati 3 categorie principali di failures, nel primo caso sulla “specification trap” il tratto fondamentale su cui focalizzarsi è quello di trattare le specifiche in modo molto preciso, anche usando schema ben definiti se necessario (e.g. Json Schema). Per quanto riguarda il problema di inter-agent misalignment, strumenti come il Model Context Protocolo (MCP,) e l’Agent2Agent Protocol (A2A) stanno andando nella direzione dell’ottenere uno standard de facto nelle comunicazioni tra agenti e tools, e tra agenti in un sistema multi-agent (potenzialmente distribuito).
Tanti punti critici sono ancora in fase di esplorazione, ma questa stessa esplorazione sta guidando l’evoluzione di questi strumenti.
Conclusioni
Il percorso tracciato finora ci mostra come ogni passo avanti apra nuove possibilità, nuovi task da poter affrontare e auspicabilmente risolvere, ma porti con sé nuove forme di fallimento: saperle riconoscere e studiarle a fondo è condizione necessaria per trasformare l’hype in valore concreto.
Link e riferimenti
[1] – https://www.nber.org/papers/w34255
[3] – arxiv.org/pdf/2204.01691.pdf
[4] – https://arxiv.org/abs/2210.03629
[5] – https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/
[6] – https://www.anthropic.com/engineering/building-effective-agents
[7] – https://www.kaggle.com/whitepaper-agent-companion
[8] – https://share.google/TzF9xPvPVyfyyvYlu
[9] – https://github.com/multi-agent-systems-failure-taxonomy/MAST
