Agentic AI e il problema nella fase finale: perché l'affidabilità delle chiamate agli strumenti è più complessa di quanto sembri

Quando si tratta di IA basata sugli agenti, quasi tutta l’attenzione si concentra sulle capacità di ragionamento dell'agente. Il modello può definire il piano corretto, suddividere un obiettivo in passaggi e decidere cosa fare dopo. Molta meno attenzione viene dedicata all'ultimo passaggio del processo: eseguire effettivamente l'azione decisa dal modello. Quest’ultima fase viene data per scontata, nonostante sia il passaggio che causa frequentemente arresti silenziosi nei sistemi agentici in produzione.

A cosa serve effettivamente il tool calling

Grazie alle chiamate agli strumenti il tuo agente può fare di più. C’è differenza tra un modello in grado solo di descrivere cosa farebbe e un modello che agisce concretamente, ad esempio interrogando un database, aprendo un ticket, eseguendo un calcolo, chiamando un altro servizio e restituendo un risultato effettivo anziché un'ipotesi. Per un agente, il tool calling non è una funzionalità tra le tante, ma l'intero meccanismo attraverso cui il ragionamento diventa azione. 

Questo lo rende anche soggetto a errori. L'output di ogni passaggio alimenta l'input del passaggio successivo. Pertanto, un agente che pianifica cinque passaggi e riesce a eseguirne in modo affidabile solo tre è utile tanto quanto uno che non ha alcun accesso agli strumenti. 
 

Il problema della formattazione 

Ogni modello richiama gli strumenti in modo leggermente diverso. Se la chiamata allo strumento non è formattata in modo esatto, l'intera risposta può fallire del tutto. 
 

# Modello A: Tag in stile XML che racchiude un payload JSON
<tool_call>{"name": "get_weather", "arguments": {"city": "Boston"}}</tool_call>

# Modello B: JSON semplice, nome di campo diverso per lo stesso concetto 
{"tool_calls": [{"function": {"name": "get_weather", "parameters": {"city": "Boston"}}}]} 

# Modello C: un token speciale seguito da una stringa in stile chiamata di funzione 
[TOOL_CALL] get_weather(city="Boston")

Fig. 1: Tag in stile XML che racchiudono JSON, JSON puro e chiamata allo strumento in stile funzione.

Alcuni modelli utilizzano tag o token specifici per contrassegnare la chiamata, mentre altri richiedono una struttura JSON e nomi di campo particolari. Un parser deve sapere in anticipo quale struttura produrrà un determinato modello. Ciò risulta più complesso con i modelli che combinano il testo della catena di pensiero con la chiamata effettiva allo strumento: la parte della risposta necessaria per la chiamata si trova proprio accanto al testo di ragionamento che non deve essere analizzato come istruzione.

Perché questo problema colpisce i sistemi agentici più della chat

In un singolo scambio via chat, una chiamata a uno strumento analizzata male produce una risposta errata. In un agente che esegue un'attività in più passaggi, rappresenta invece la prima tessera del domino. Il piano per il passaggio successivo dipende da ciò che è successo nel passaggio precedente. Cosa il modello intendesse fare non importa, mentre conta come la chiamata allo strumento è stata effettivamente analizzata ed eseguita. Se sbagli un passaggio lungo il percorso, tutti gli elementi downstream ragionano sulla base di un mondo che non corrisponde alla realtà, senza alcun segnale evidente di errore.

Questo effetto a catena è il vero problema dell'ultimo miglio. Tutti questi errori comuni provocano guasti silenziosi.

• Stile dei tag errato: un parser ottimizzato per lo stile dei tag di un modello non rileverà la chiamata allo strumento proveniente da un modello che non utilizza affatto tag. La chiamata non parte mai e il piano dell'agente perde silenziosamente un passaggio.
• Etichette non corrispondenti: un parser che attende l'etichetta "arguments" non si bloccherà necessariamente su un payload che utilizza invece l'etichetta "parameters". Può semplicemente trasmettere in modo silenzioso un set di valori vuoto o errato: lo strumento viene quindi eseguito con l'input sbagliato e l'agente prosegue come se il passaggio fosse riuscito.
• Carichi di chiamate variabili: un parser configurato per attendersi una sola chiamata allo strumento per risposta può acquisire la prima chiamata in una risposta a chiamate multiple e scartare silenziosamente le altre; così un agente che ha richiesto tre elementi ne riceve solo uno.
• Ragionamento combinato con la chiamata: quando un modello intreccia il ragionamento con la chiamata allo strumento e il parser non traccia correttamente questa distinzione, può estrarre argomenti dal testo di ragionamento anziché dalla chiamata effettiva. Il passaggio successivo del piano dell'agente riceverà valori che non intendeva inviare.

Un agente non si avvale di una persona che controlla costantemente ogni passaggio, verificando che ciascuna chiamata allo strumento sia corretta prima di procedere. È proprio questo lo scopo di un agente. È anche il motivo esatto per cui un errore silenzioso nell'ultima fase è molto più costoso qui che in qualsiasi altro punto del sistema. Nulla impedisce a un errore di innescare una reazione a catena disastrosa, costruendo con attenzione un piano in più passaggi che si rivela poi errato.

Perché continuano a verificarsi errori silenziosi, anche dopo una corretta esecuzione

Sostituisci il modello con uno diverso per motivi di costi o di prestazioni, e un agente che funzionava perfettamente può iniziare a non chiamare gli strumenti in modo silenzioso, oppure a chiamarli con dati errati. Molto probabilmente nei log non appare alcun errore evidente, perché non si è verificato alcun arresto anomalo. Ha semplicemente eseguito in modo silenzioso l'azione sbagliata, o nessuna azione, anziché comportarsi secondo i piani.

Un aggiornamento di un modello che stai già utilizzando può portare alla stessa conseguenza: basta una modifica minima al modo in cui il modello formatta le chiamate agli strumenti e un parser programmato rigidamente sulla vecchia struttura si interrompe nel momento in cui l'aggiornamento viene distribuito. L'errore può manifestarsi come se provenisse da tutt'altra parte, nascosto dietro tre o quattro passaggi dell'agente eseguiti successivamente.

Cosa deve fare il serving al riguardo

Ogni motore di serving deve saper leggere il formato di chiamata allo strumento prodotto da ciascun modello ed essere abbastanza intelligente da non bloccarsi in caso di variazione della versione del modello. Il tuo motore di serving dovrebbe essere in grado di:

• riconoscere e analizzare correttamente il formato nativo di chiamata allo strumento di ciascuna famiglia di modelli, incluse le varianti basate su tag, su JSON e su token speciali;
• normalizzare le differenze nei nomi dei campi (argomenti, parametri e simili) anziché presupporre una struttura unica;
• gestire chiamate multiple agli strumenti in una singola risposta, non solo la prima;
• separare il testo di ragionamento dalla chiamata effettiva allo strumento prima di estrarre gli argomenti;
• mantenere la correttezza tra i cambi di versione del modello, in modo che un aggiornamento del modello upstream non interrompa silenziosamente una pipeline che dipende da esso.

Sono tutti requisiti necessari per i sistemi agentici. È la differenza tra un agente che continua a funzionare al passo con l'evoluzione dei modelli e un agente che smette silenziosamente di fare ciò che dovrebbe in seguito all’aggiornamento di una dipendenza.

In che modo il tuo team gestisce l'affidabilità delle chiamate agli strumenti nelle pipeline agentiche? Raccontaci la tua esperienza. Dai un'occhiata alle novità e alle progetti futuri per Red Hat AI.