The Pulse
Secondo Apple, la ricerca degli strumenti dovrebbe cambiare in base alla complessità del compito
I ricercatori di Apple hanno confrontato due metodi con cui gli agenti di IA possono trovare le API e hanno scoperto che il metodo migliore dipende dal numero di strumenti richiesti: uno o più di uno. Lo studio ha messo alla prova entrambi
AI.info Team · Scritto con l’IA ·
Il confronto condotto dai ricercatori di Apple tra due metodi con cui gli agenti di IA possono trovare gli strumenti ruota attorno a una semplice distinzione: se un compito richieda una sola API o più di una. In uno studio presentato ad arXiv il 13 ottobre, riferiscono che la ricerca diretta a partire dalla richiesta dell’utente funziona meglio quando serve un solo strumento, mentre chiedere prima a un modello linguistico di delineare le capacità necessarie aiuta quando ne servono diversi. Lo studio, accettato per l’Industry Track di EMNLP 2026, mette alla prova entrambi gli approcci su quasi 47.000 endpoint API.
Due percorsi in un registro di 46.984 API
Il primo metodo, Retrieve-then-Plan (RtP), trasforma la richiesta dell’utente in un embedding e usa una ricerca dei vicini più prossimi per restituire le descrizioni delle API corrispondenti. L’agente pianifica quindi sulla base di quei risultati. L’alternativa, Plan-then-Retrieve (PtR), chiede prima a un modello di abbozzare degli «Abstract Tool Stubs»: firme di funzione ipotetiche che descrivono le capacità di cui il compito potrebbe aver bisogno. Il sistema usa questi stub per cercare nel registro, poi fornisce gli strumenti corrispondenti al pianificatore.
Il team di Apple ha valutato i metodi su ToolBench, usando 46.984 endpoint API unici distribuiti in 50 categorie. Il set di test distingueva tra richieste che richiedevano un solo strumento (G1), richieste che ne richiedevano più di uno all’interno di una categoria (G2) e richieste che ne richiedevano più di uno in categorie diverse (G3). Il confronto principale prevedeva un limite di cinque risultati per il recupero; i ricercatori hanno anche variato tale limite da uno a 20 e testato registri di dimensioni comprese tra 1.000 e 47.000 API.
La ricerca diretta prevale quando serve un solo strumento
Sulle 200 richieste G1 che richiedevano un solo strumento, RtP ha registrato una recall di 0,372, contro 0,289 per PtR, e un tasso di superamento più alto: 0,884 contro 0,840. Secondo gli autori, il recupero diretto è avvantaggiato quando una richiesta contiene il nome riconoscibile di un’API o di un marchio. In questi casi, la fase di pianificazione può perdere un indizio utile sostituendo il nome specifico con una descrizione più generale.
Il risultato si ribalta sulle 200 richieste G2 che richiedevano più strumenti. PtR ha raggiunto una recall di 0,188, contro 0,143 per RtP, e un tasso di superamento di 0,855 contro 0,747. Scomporre una richiesta in stub che descrivono le capacità necessarie permette di effettuare ricerche separate per le sue diverse componenti, mentre un unico embedding della richiesta potrebbe non rappresentarle tutte.
Per le 100 richieste G3 che coinvolgevano più categorie, la recall di PtR è stata più alta — 0,172 contro 0,160 — ma la differenza non era statisticamente significativa. Il suo tasso di superamento è stato di 0,820, contro 0,732 per RtP. Lo studio avverte che il campione più piccolo di G3 conferisce a quel confronto sulla recall una minore potenza statistica.
I nomi di strumenti inventati possono aiutare, o trarre in inganno
Gli stub di PtR non corrispondono necessariamente ad API reali. Il modello inventa nomi e descrizioni plausibili per gli strumenti, e i ricercatori ne individuano un effetto ambivalente: gli stub generici possono eliminare gli indizi forniti dai nomi propri che aiutano RtP nei compiti semplici, ma possono anche scomporre le richieste complesse in singole esigenze funzionali. Secondo lo studio, solo il 40,6% degli stub G1 e il 24,8% degli stub G3 corrispondeva a un’API pertinente.
«Nel loro insieme, questi risultati confermano che l’inversione dipende dalle caratteristiche strutturali del rapporto tra richieste e registro, anziché soltanto dall’ampiezza della ricerca.»
Mingfei Zhang e coautori, autori dello studio
Il quadro è rimasto lo stesso al variare del numero massimo di risultati recuperati e delle dimensioni del registro, nonché in una replica condotta usando gpt-oss-120b insieme a Gemini 2.5 Flash. Questa coerenza sostiene il risultato centrale dello studio, ma la valutazione degli autori ha dei limiti: usa le traiettorie API di riferimento di ToolBench come indicatore indiretto della qualità del recupero, anziché eseguire le API. Lo studio non valuta la correttezza dei parametri né la qualità delle risposte finali degli agenti.
Una chiamata aggiuntiva al modello ha un costo misurabile
PtR aggiunge una chiamata per individuare gli strumenti prima del recupero e della pianificazione. L’analisi dello studio stima il costo aggiuntivo in token tra circa il 75% e il 104%; la chiamata sequenziale aggiunge inoltre un passaggio di andata e ritorno prima che il pianificatore possa iniziare. Secondo lo studio, questo costo penalizza le richieste che richiedono un solo strumento, ma dà risultati positivi per quelle che ne richiedono più di uno.
I ricercatori propongono di indirizzare le richieste verso l’uno o l’altro metodo: RtP per i compiti che richiedono un solo strumento e PtR per quelli che ne richiedono più di uno. Secondo la loro analisi, questa combinazione riduce il totale dei token usati per l’inferenza di circa il 16% — pari a circa il 36% del costo aggiuntivo della chiamata di PtR per individuare gli strumenti — senza ridurre la qualità del recupero rispetto alla scelta sistematica del metodo migliore per ciascun sottoinsieme. Un possibile segnale per decidere quale metodo usare è il punteggio di similarità del primo risultato di RtP, già calcolato; lo studio rimanda a lavori futuri la verifica empirica di un classificatore per questa scelta.