Budget-Aware Tool-Use Enables Effective Agent Scaling

Di /
stato della ricerca deep learning

Guida a “Budget-Aware Tool-Use”: di cosa parla il paper e perché è interessante

Il paper studia come far scalare in modo efficace agenti LLM che usano tool esterni (per esempio web search e browser) quando esiste un budget esplicito di tool-call, cioè un numero massimo di chiamate ai tool per ogni domanda. Gli autori mostrano che semplicemente dare più budget di tool-call non basta: gli agenti standard non sono “consapevoli del budget”, smettono di cercare troppo presto e raggiungono un plateau di performance. Per risolvere questo problema introducono due contributi principali: un plug-in chiamato Budget Tracker e un framework più completo chiamato BATS (Budget-Aware Test-time Scaling), entrambi progettati per rendere l’agente consapevole delle risorse che sta consumando e spingerlo a usarle in modo strategico. Su benchmark di web search difficili, questi metodi ottengono curve costo-prestazioni più favorevoli, cioè più accuratezza a parità (o con meno) costo di token e tool-call rispetto alle baseline.

Per la parte pratica: il paper è disponibile su arXiv, ma non viene indicato un repository GitHub ufficiale né un dataset nuovo dedicato; gli esperimenti usano benchmark pubblici come BrowseComp, BrowseComp-ZH e HLE-Search. Paper: https://arxiv.org/abs/2511.17006.

Indice

Come funziona Budget-Aware Tool-Use e il framework BATS

Il setup considerato è un web search agent basato su LLM che segue un loop in stile ReAct: alterna passi di “pensiero” interno in linguaggio naturale e azioni esterne tramite due tool, Search (query a un motore di ricerca) e Browse (scaricare il contenuto di una pagina). L’agente riceve per ogni domanda un budget massimo di chiamate per ciascun tool, e gli autori distinguono chiaramente tra budget (limite massimo di chiamate possibili) e costo effettivo (tool-call e token realmente consumati). Per confrontare in modo equo politiche diverse, definiscono una metrica di costo unificata che combina il costo economico dei token usati dal modello e quello delle chiamate ai tool, usando i prezzi dei provider di API.

Il primo contributo è Budget Tracker, un modulo leggero a livello di prompt che inserisce nel contesto dell’agente, a ogni iterazione, uno “stato di budget” con quante chiamate sono già state fatte e quante ne restano per ogni tool, insieme ad alcune linee guida di uso del budget. Questo non richiede training aggiuntivo: basta modificare le prompt, ma l’effetto è che il modello inizia a condizionare il proprio ragionamento sulla quantità di risorse rimaste, decidendo se continuare a esplorare, cambiare strategia o chiudere la risposta.

Il secondo contributo è BATS, un framework completo di agent orchestration che integra Budget Tracker con due moduli espliciti: budget-aware planning e budget-aware self-verification. Nel planning, l’agente decompone la domanda in indizi di tipo “exploration” (espandere lo spazio di candidati) e “verification” (controllare proprietà specifiche), e costruisce un piano ad albero che tiene traccia di quali passi sono stati completati, falliti o ancora aperti, evitando ricerche ridondanti. Nel self-verification, quando l’agente propone una risposta, un modulo di verifica controlla sistematicamente se ogni vincolo della domanda è soddisfatto, contraddetto o ancora non verificabile, e decide se marcare la risposta come SUCCESS, continuare a scavare (CONTINUE) o cambiare direzione (PIVOT) in base anche al budget rimasto. Quando decide di continuare o pivotare, il verificatore comprime la traiettoria passata in un riassunto compatto per risparmiare contesto, mantenendo però le informazioni chiave per i passi successivi.

Risultati: cosa mostra il paper su performance e costi

Gli esperimenti usano tre benchmark di information-seeking QA che forzano l’uso di web search: BrowseComp (oltre mille domande complesse in inglese), BrowseComp-ZH (versione cinese, con poche centinaia di quesiti) e HLE-Search, un sottoinsieme di Human’s Last Exam focalizzato su domande che richiedono esplicitamente ricerca online. Gli autori confrontano diversi backbone (per esempio Gemini-2.5-Pro, Gemini-2.5-Flash e Claude-Sonnet-4) in versione “ReAct pura” contro le versioni con Budget Tracker e con BATS, usando lo stesso budget di tool-call per tutti.

Con Budget Tracker applicato a un semplice agente ReAct, l’accuratezza aumenta in modo consistente su tutti e tre i dataset e con tutti i modelli, a parità di budget massimo di tool-call. Per esempio, con Gemini-2.5-Pro su BrowseComp, il passaggio da ReAct standard a ReAct+Budget Tracker porta diversi punti percentuali di guadagno; inoltre, a volte la versione con Budget Tracker raggiunge risultati paragonabili a ReAct con dieci volte più budget, ma usando molte meno chiamate di ricerca e di browsing e un costo unificato sensibilmente inferiore. Questo mostra che la sola consapevolezza del budget induce un uso più disciplinato e informato dei tool, riducendo sprechi senza sacrificare performance.

Con il framework completo BATS, i risultati migliorano ulteriormente e in modo più marcato. Sotto un vincolo severo di 100 tool-call per tipo di tool, BATS con Gemini-2.5-Pro arriva a circa un quarto di domande corrette su BrowseComp, quasi la metà su BrowseComp-ZH e oltre un quarto su HLE-Search, superando nettamente la versione ReAct dello stesso modello e battendo diversi agenti di web search appositamente addestrati. Un punto importante è che BATS è training-free: sfrutta solo orchestrazione e prompt engineering, ma riesce comunque a spostare in avanti il fronte di Pareto costo-prestazioni rispetto sia alle strategie di sequential scaling (più passi di ragionamento di seguito) sia di parallel scaling (più traiettorie in parallelo con majority vote).

Gli autori studiano anche il comportamento di early stopping, cioè quando l’agente è libero di fermarsi prima di esaurire il budget se è già sicuro della risposta. In questo scenario, baseline come ReAct tendono a sottoutilizzare il tool di browsing e a saturare rapidamente la performance al crescere del budget, mentre BATS usa in modo più adattivo sia Search sia Browse e continua a migliorare l’accuratezza man mano che il budget disponibile cresce. Analisi di ablation mostrano infine che togliere il planning o il self-verification fa calare sensibilmente i risultati, confermando che entrambi i moduli contribuiscono in modo sostanziale.

Concetti chiave da capire prima di leggere il paper

  • Test-time scaling per agenti
    Il test-time scaling indica strategie per migliorare le prestazioni di un LLM aumentando il calcolo al momento dell’inferenza, per esempio generando più passi di ragionamento in sequenza (sequential scaling) o più traiettorie in parallelo (parallel scaling) e poi aggregandole. Il paper estende questo concetto agli tool-augmented agents, dove non si scala solo il numero di token generati (“thinking”) ma anche il numero di interazioni con l’ambiente esterno tramite tool (“acting”).

  • Tool-call budget vs costo unificato
    Il tool-call budget è il limite massimo di quante volte un agente può chiamare un certo tool durante la soluzione di una singola domanda; è un vincolo “hard” che non può essere sforato. Il costo unificato è invece una misura post-hoc di quanto è realmente costato risolvere quella domanda, combinando in un’unica scala il costo economico dei token e quello delle chiamate ai tool (ad esempio sulla base dei prezzi delle API).

  • Web search agent e loop ReAct
    Un web search agent è un LLM che, per rispondere a domande complesse, alterna ragionamento interno e azioni su tool di ricerca e browsing, seguendo uno schema ReAct (Reason+Act). A ogni iterazione il modello decide se formulare una nuova query di Search, approfondire una pagina via Browse o proporre una risposta finale, usando il contesto via via arricchito.

  • Budget awareness come segnale di controllo
    Senza indicazioni sul budget, gli agenti tendono a comportarsi come se le risorse fossero illimitate o, al contrario, a interrompere la ricerca troppo presto, ignorando eventuali tool-call ancora disponibili. Budget Tracker rende esplicito nel prompt quanto budget resta e fornisce linee guida su come comportarsi in diverse fasce di consumo, permettendo all’agente di pianificare e verificare le proprie azioni tenendo conto delle risorse.

  • Planning e self-verification in BATS
    Il planning di BATS decompone la domanda in indizi di “exploration” (trovare candidati, generare liste) e di “verification” (controllare proprietà specifiche), mantenendo un piano ad albero che guida l’uso dei tool e registra i passi già tentati. Il self-verification rilegge la traiettoria, valuta se ogni vincolo è soddisfatto, decide se continuare, pivotare o accettare la risposta e sintetizza il percorso passato in un riassunto compatto per non saturare il contesto.

Quiz su Budget-Aware Tool-Use (domande e risposte)

Gli autori osservano che agenti standard basati su ReAct tendono a raggiungere rapidamente un “tetto” di performance: anche se si aumenta il numero massimo di chiamate consentite, l’agente spesso smette di cercare quando pensa di avere una risposta o quando si sente “bloccato”. Senza un segnale esplicito di budget, il modello non sa che ha ancora margine per esplorare strade alternative o approfondire, e quindi non sfrutta il budget aggiuntivo.

Che differenza c’è tra Budget Tracker e BATS?

Budget Tracker è un plug-in molto semplice: aggiunge allo schema ReAct un blocco di testo che mostra il consumo di budget in tempo reale e include raccomandazioni generali su come comportarsi a seconda di quanto budget resta. BATS, invece, è un framework più strutturato che incorpora Budget Tracker ma aggiunge anche moduli espliciti di planning e self-verification, orchestrando l’intero processo di ricerca, esplorazione di traiettorie multiple e scelta della risposta finale sotto vincoli di budget.

Quali tipi di indizi usa il planning di BATS e perché sono importanti?

Nel planning, BATS separa gli indizi nella domanda in due categorie: exploration (indizi che servono ad allargare lo spazio di possibili risposte, come trovare tutti i candidati rilevanti) e verification (indizi che servono a controllare proprietà specifiche di candidati già trovati). Questa distinzione aiuta a decidere come allocare il budget: puntare troppo presto solo sulla verifica rischia di sprecare risorse su candidati sbagliati, mentre una buona bilancia tra esplorazione ampia e verifiche mirate consente di usare i tool-call in modo più efficiente.

Perché gli autori introducono una metrica di costo unificata invece di guardare solo al numero di tool-call?

Guardare solo al numero di tool-call non cattura il costo totale dell’esecuzione, perché ogni chiamata genera anche token aggiuntivi che il modello deve elaborare, con un impatto economico non trascurabile. La metrica di costo unificata somma il costo dei token (input, output e cache-hit) e delle chiamate ai tool sulla base dei prezzi reali dei provider, permettendo di confrontare in modo trasparente politiche diverse in termini di costo-prestazioni.

In cosa BATS differisce dagli agenti di web search addestrati specificamente su dati di browsing?

Molti agenti di web search allo stato dell’arte ottengono buoni risultati grazie a training supervisionato o reinforcement learning su grandi collezioni di traiettorie di browsing, ottimizzando il modello per il compito di ricerca. BATS, al contrario, non richiede alcun training aggiuntivo: usa modelli generali (come Gemini-2.5-Pro o Claude-Sonnet-4) e migliora le prestazioni solo tramite orchestrazione budget-aware, ma riesce comunque a competere e talvolta a superare agenti specializzati sotto gli stessi vincoli di budget.

Studi correlati e letture consigliate

Il lavoro si basa e si collega a una lunga linea di ricerca su test-time scaling per LLM, dove strategie come sequential scaling (più passi di riflessione e auto-correzione in sequenza) e parallel scaling (più traiettorie indipendenti con majority vote o best-of-N) hanno dimostrato di migliorare ragionamento e coding al costo di più calcolo. Studi più recenti esplorano anche approcci “ibridi” che combinano componenti sequenziali e parallele, così come metodi per limitare il costo test-time imponendo vincoli su token, FLOPs o numero di traiettorie.

Nel dominio specifico dei web search agents, il framework ReAct è un punto di partenza classico per alternare ragionamento e azioni su tool, mentre numerosi lavori costruiscono dataset di traiettorie di browsing e addestrano modelli dedicati come ASearcher, WebSailor, DeepDive, WebExplorer o sistemi industriali tipo OpenAI Deep Research. Altri lavori, come MiroThinker e AgentTTS, analizzano come scalare l’uso interattivo dei tool o ottimizzare il mix tra dimensione del modello e numero di campioni sotto un budget di FLOPs, mentre sistemi come SLIM studiano come gestire il contesto in agenti di lunga durata. Il contributo di questo paper è spostare il focus su budget di tool-call espliciti e su come progettare orchestrazioni e segnali di budget-awareness che permettano agli agenti di sfruttare al meglio risorse limitate in scenari di tool-use realistici.

Torna in alto