VAKRA: ragionamento, uso degli strumenti e modalità di fallimento degli agenti AI

Nel panorama in rapida evoluzione dell'intelligenza artificiale, la capacità degli agenti di ragionare in modo autonomo e di utilizzare strumenti complessi è diventata una pietra angolare per il loro impiego in contesti reali. Recentemente, è stato introdotto VAKRA, un benchmark innovativo basato su strumenti ed eseguibile, progettato specificamente per valutare con precisione quanto gli agenti di intelligenza artificiale siano efficaci nel ragionare e nell'agire all'interno di ambienti che emulano scenari aziendali. Questo nuovo approccio rappresenta un significativo passo avanti rispetto ai benchmark tradizionali, i quali spesso si concentrano su test di abilità isolate, senza considerare l'interconnessione necessaria per risolvere problemi più complessi.

A differenza dei suoi predecessori, VAKRA non si limita a misurare competenze singole, ma si concentra sul ragionamento compositivo, ovvero la capacità di combinare più abilità e conoscenze per navigare attraverso API e documenti. La valutazione viene condotta utilizzando tracce di esecuzione complete, consentendo di accertare se gli agenti siano in grado di completare in modo affidabile flussi di lavoro multi-step. Questo è cruciale per replicare la complessità dei compiti che un agente AI dovrebbe affrontare in un ambiente aziendale.

L'ambiente VAKRA è stato progettato per essere estremamente realistico ed eseguibile, offrendo agli agenti la possibilità di interagire con oltre 8.000 API ospitate localmente. Queste API sono supportate da database reali e abbracciano un'ampia gamma di 62 domini differenti, ciascuno accompagnato da collezioni di documenti allineate al dominio. I compiti assegnati agli agenti possono richiedere catene di ragionamento che vanno da 3 a 7 passaggi, le quali combinano l'interazione strutturata con le API e il recupero non strutturato di informazioni, il tutto sotto vincoli di utilizzo degli strumenti espressi in linguaggio naturale. Tuttavia, le osservazioni iniziali indicano che i modelli attuali mostrano prestazioni scarse su VAKRA. Questo dato ha spinto a un'analisi più approfondita dei dettagli del dataset e delle modalità di fallimento riscontrate nei diversi compiti, che verranno esplorate in dettaglio in questo articolo.

Analisi Dettagliata del Dataset VAKRA

Il benchmark VAKRA è strutturato attorno a quattro compiti principali, ciascuno ideato per testare un diverso insieme di capacità degli agenti AI, affrontando le sfide che vanno dalla manipolazione di dati di base al ragionamento multi-sorgente e multi-turno.

Capacità 1: Interazione con strumenti di manipolazione dati

Questa prima capacità comprende 2.077 istanze di test distribuite su 54 domini. Per completare questi compiti, gli agenti devono utilizzare strumenti provenienti dalle collezioni SLOT-BIRD e SEL-BIRD (Elder et al., 2026). È importante notare che l'universo degli strumenti in SLOT-BIRD e SEL-BIRD è stato ampliato rispetto alla configurazione originale presentata in Elder et al., includendo un numero maggiore di domini. Ogni dominio è limitato a una singola collezione di strumenti e i compiti richiedono l'incatenamento di un numero variabile di chiamate agli strumenti, da 1 a 12, per arrivare alla risposta finale.

Ogni istanza di test è associata a una sorgente di dati in formato JSON, da cui deve essere derivata la risposta. I server MCP che supportano questo compito includono uno strumento speciale denominato get_data(tool_universe_id=id), il quale deve essere richiamato all'inizio di ogni istanza. Questo strumento ha diverse funzioni critiche: inizializza la sorgente di dati, restituisce un'anteprima leggera dei dati (come mostrato nella Figura 3), e memorizza il dataset completo lato server per prevenire trasferimenti di dati di grandi dimensioni, evitando così l'inefficienza del protocollo MCP per masse di dati voluminose. Inoltre, la chiamata a get_data configura il server MCP per esporre il set di strumenti appropriato basato sull'tool_universe_id e allinea la sorgente dati con il database specifico del dominio per l'istanza.

La collezione SLOT-BIRD offre un set globale di 7 strumenti per la manipolazione generica dei dati, ispirati a sistemi ben noti come Tableau e Google Analytics. Questi strumenti permettono operazioni fondamentali come il filtraggio e l'ordinamento. La collezione SEL-BIRD estende SLOT-BIRD introducendo strumenti più specializzati. Alcuni di questi sono condivisi con SLOT-BIRD, mentre altri sono derivati dall'appiattimento di argomenti categorici in funzioni separate. Ad esempio, una funzione come sort_data con l'argomento ascending:bool = False può diventare sort_data_ascending e sort_data_descending. Inoltre, la funzione generica retrieve_data di SLOT-BIRD viene sostituita con "getter" specifici per le query, dove ogni chiave nei dati di una data istanza ha una funzione get associata (ad esempio, get_KEY_NAME), per una media di 4 funzioni get per istanza.

Capacità 2: Interazione con API REST e vincoli di dimensione degli strumenti

Questa seconda capacità comprende 1.597 istanze distribuite su 17 domini, richiedendo l'uso di strumenti da una collezione REST-BIRD ampliata (Elder et al.). Questi strumenti utilizzano interfacce in stile endpoint che forniscono endpoint altamente specifici e allineati alle query, incapsulando la maggior parte dei calcoli. Sono serviti come API REST in esecuzione su un server FastAPI, il quale è a sua volta incapsulato dal server MCP. Questo compito richiede la selezione delle API corrette dal set di strumenti specifico del dominio (come mostrato nell'esempio nella Figura 1). Ogni dominio contiene un minimo di 6 fino a un massimo di 328 strumenti, con una media di 116 strumenti. Similmente al compito precedente, lo strumento get_data configura il server MCP per esporre solo le API specifiche del dominio pertinenti.

Una restrizione importante deriva dalla specifica API di OpenAI, che limita l'input dell'elenco degli strumenti a una lunghezza massima di 128 strumenti. Questa limitazione impone al costruttore di un agente che utilizza questa API di gestire direttamente la lunghezza dell'elenco degli strumenti tramite un meccanismo di shortlisting. Negli agenti di base inclusi nel repository del progetto, una semplice capacità di shortlisting gestisce questa sfida, selezionando solo gli strumenti più rilevanti per il compito specifico, garantendo così la conformità ai limiti imposti e l'efficienza nell'elaborazione.

Capacità 3: Ragionamento Multi-Hop

Il segmento di Capacità 3 del benchmark presenta 869 istanze di test, attinte da 38 domini tematici. Queste istanze si basano nuovamente sulla collezione di API REST-BIRD, ma aggiungono la sfida del ragionamento multi-hop (fare riferimento all'esempio nella Figura 1). Le domande multi-hop richiedono che vengano estratte e combinate più informazioni di supporto per raggiungere una risposta. Le istanze in questa sezione richiedono tra uno e cinque "salti" logici per rispondere a una query. La distribuzione dei tipi di domande per le query all'interno del dataset di test è illustrata nella Figura 4, fornendo una visione chiara della complessità richiesta in termini di concatenazione logica per risolvere i problemi.

Capacità 4: Ragionamento Multi-Hop e Multi-Sorgente

La Capacità 4 include 644 istanze attraverso 41 domini ed è anch'essa costruita sulla collezione di API REST-BIRD. La Figura 4 mostra una distribuzione di salti ibridi per le query di test senza politiche. Contiene le query più complesse, caratterizzate da:

• Multi-Sorgente: Questo segmento aggiunge indici di documenti per ogni dominio. Le query in questa capacità possono richiedere informazioni sia da questi indici di documenti che da chiamate API. Similmente alla Capacità 3, anche questo compito presenta query Multi-Hop. La sorgente di informazioni richiesta si applica a livello di "hop"; ad esempio, una domanda potrebbe comportare tre "salti" logici con sorgenti come: API - RAG (Recupero Documentale) - API. Per garantire un ragionamento corretto, le sorgenti vengono decontaminate durante la generazione dei dati, ovvero le informazioni necessarie per un dato "hop" sono disponibili in una sola sorgente. Ad esempio, se un "hop" deve essere risolto utilizzando le API, l'indice dei documenti viene costruito rimuovendo i documenti che probabilmente contengono le informazioni necessarie per rispondere alla domanda, assicurando che l'agente debba scegliere la sorgente corretta.
• Multi-Turn: Questo segmento del dataset aggiunge anche conversazioni multi-turno all'impostazione. Ogni istanza è un dialogo con più turni. I dati vengono rilasciati come coppie contesto-risposta, dove il contesto codifica la cronologia del dialogo corrente e l'agente è responsabile solo di rispondere al turno attuale, simulando scenari di conversazione più naturali e complessi.
• Politiche di utilizzo degli strumenti: Un sottoinsieme di queste istanze include politiche di utilizzo degli strumenti che l'agente è tenuto a seguire. Queste politiche prendono la forma di istruzioni in testo semplice sulle fonti di conoscenza a cui l'agente è autorizzato ad accedere e in quali circostanze. Ad esempio, una politica potrebbe specificare:
  • "L'agente deve prioritizzare l'uso degli strumenti dell'API prima di accedere a qualsiasi documento."
  • "Se una query riguarda informazioni finanziarie, l'agente deve consultare solo i documenti approvati del dipartimento finanziario."
  • "Per le domande sulla privacy, l'agente non deve mai accedere a dati personali identificabili tramite API esterne."

  L'agente di base nel repository del progetto impone l'adesione a queste politiche attraverso una semplice aggiunta al prompt: "You are a helpful assistant with access to tools.\n Tool Usage Constraint: {additional_instructions}.". Naturalmente, i costruttori di agenti sono liberi di scegliere qualsiasi meccanismo di applicazione dei vincoli che ritengano più efficace.

Framework di Valutazione Centrato sull'Esecuzione

VAKRA valuta gli agenti in ambienti ricchi di strumenti, dove il successo dipende sia dalla capacità di eseguire flussi di lavoro coerenti e multi-step sia dalla correttezza della risposta finale. Per raggiungere questo obiettivo, è stato introdotto un framework di valutazione centrato sull'esecuzione che valuta non solo gli output finali, ma anche l'intera traiettoria di esecuzione degli strumenti. Questa traiettoria comprende le chiamate agli strumenti, gli input forniti e i risultati intermedi, offrendo una visione granulare del processo decisionale dell'agente.

Il Valutatore VAKRA opera su due input chiave per ogni campione: una risposta finale prevista e la corrispondente traiettoria di chiamate agli strumenti. Le chiamate agli strumenti dalla traiettoria prevista vengono eseguite nello stesso ambiente della verità di base per verificare gli output intermedi degli strumenti, garantendo che ogni passaggio dell'esecuzione sia verificabile e accurato.

La valutazione segue una pipeline a cascata (Figura 6), dove le fasi successive sono condizionate dal successo delle fasi precedenti, creando un processo di valutazione rigoroso e progressivo:

• Controllo preliminare dell'esecuzione: Verifica che l'agente abbia chiamato correttamente almeno un tool e che le chiamate siano sintatticamente valide.
• Correttezza delle chiamate ai tool: Valuta se i tool chiamati sono appropriati per il task e se gli argomenti forniti sono validi.
• Coerenza dell'output: Controlla se gli output dei tool eseguiti corrispondono alle aspettative e supportano la risposta finale.
• Accuratezza della risposta finale: Confronta la risposta finale generata dall'agente con la risposta di verità.

Confronto della Sequenza di Strumenti

Dato l'ambiente eseguibile, gli agenti hanno la libertà di esplorare l'ambiente e, talvolta, possono restituire la risposta invocando un set di API diverso da quelle identificate come verità di base. Per supportare invocazioni di strumenti e percorsi di ragionamento alternativi ma comunque validi, la correttezza viene valutata eseguendo ogni strumento previsto e confrontando il set di risposte degli strumenti con quelle della verità di base, piuttosto che imporre una corrispondenza rigorosa a livello di singolo passaggio. Questo approccio riconosce che ci possono essere diversi modi validi per arrivare alla stessa conclusione.

Nello specifico, viene eseguito un controllo programmatico iniziale, verificando che tutte le informazioni presenti nelle risposte degli strumenti della verità di base siano recuperate dalle risposte degli strumenti previsti. Questo controllo è cruciale per assicurare che, anche se il percorso è diverso, l'agente abbia comunque accesso e utilizzi tutte le informazioni necessarie per risolvere il compito, evidenziando l'importanza della completezza e dell'accuratezza delle informazioni recuperate, indipendentemente dalla precisa sequenza di operazioni che l'agente ha scelto di intraprendere.