Leggo l'articolo su Gorilla (Patil et al., 2023, arXiv:2305.15334, NeurIPS 2024) perché si trova all'incrocio di due problemi che incontro spesso: come fare in modo che un agente LLM chiami lo strumento giusto con gli argomenti giusti, e come mantenere questa capacità quando le API cambiano. Le risposte qui sono pratiche e i numeri sono sorprendentemente solidi — ma le ipotesi alla base della valutazione meritano più attenzione di quella che di solito ricevono.
L'articolo
Gorilla, di Shishir G. Patil, Tianjun Zhang, Xin Wang e Joseph E. Gonzalez presso la UC Berkeley, affronta una modalità di fallimento concreta: i LLM all'avanguardia allucinano le chiamate API. Quando viene chiesto di scrivere codice che invochi una funzione di libreria specifica, GPT-4 (a metà 2023) genera frequentemente firme di funzione plausibili ma errate, modelli inesistenti o nomi di argomenti deprecati. Gorilla è un modello basato su LLaMA da 7 miliardi di parametri, messo a punto specificamente per generare chiamate API accurate, addestrato con una tecnica che gli autori chiamano Addestramento Retriever-Aware (RAT). L'idea è semplice: durante l'addestramento, al modello viene mostrata la documentazione API recuperata insieme alla richiesta dell'utente, formattata come "Usa questa documentazione API come riferimento: <documentazione_API_recuperata_JSON>". Questo insegna al modello sia a leggere la documentazione sia a fidarsi del contesto recuperato piuttosto che della sua memoria parametrica — una proprietà che paga dividendi al momento dell'inferenza quando la documentazione è cambiata.
Il dataset di valutazione, APIBench, copre 925 API di HuggingFace Model Hub, 95 API di TorchHub e 696 API di TensorFlow Hub, con dieci richieste sintetiche di istruzioni generate per API tramite self-instruct. La metrica di valutazione è il confronto di sotto-alberi AST — la chiamata API generata viene analizzata e verificata per la correttezza funzionale — che consente anche, per la prima volta in questo contesto, una misurazione basata su principi del tasso di allucinazione.
Idee chiave
- RAT rende la documentazione leggibile al momento dell'inferenza. Addestrandosi su prompt che includono la documentazione recuperata, Gorilla impara a deferire al testo recuperato piuttosto che ricordare i dettagli dell'API dai pesi. Ciò significa che il modello rimane aggiornato man mano che le API evolvono senza necessità di riaddestramento.
- Accuratezza zero-shot: Gorilla 59–84%, GPT-4 18–39%. Su TorchHub, Gorilla raggiunge il 59.13% rispetto al 38.70% di GPT-4. Su HuggingFace, è il 71.68% contro il 19.80%. Su TensorFlow Hub, 83.79% contro 18.20%. Il margine è maggiore dove lo spazio API è più diversificato.
- La riduzione delle allucinazioni è il punto principale. Il tasso di allucinazione di Gorilla è del 6.98% su TorchHub, 10.95% su HuggingFace e 5.40% su TensorFlow Hub. I tassi di GPT-4 vanno dal 36.55% al 78.65% sugli stessi dataset.
- Il retriever oracle è il limite massimo. Con il documento di verità fondamentale recuperato (modalità oracle), l'accuratezza raggiunge il 67–94%. Questo è il caso teorico migliore per qualsiasi sistema basato su RAG e il divario da Gorilla zero-shot a questo limite massimo è lo spazio disponibile per il miglioramento del retriever.
- I retriever reali sono insufficienti. Passare dall'oracle a GPT-Index al momento della valutazione degrada l'accuratezza del 29.20%; BM25 la degrada del 52.27%. La robustezza del modello al rumore di recupero è reale, ma non illimitata.
- La valutazione AST generalizza. L'approccio di confronto di sotto-alberi misura se la chiamata generata è funzionalmente corretta, non solo sintatticamente simile. Questa è la metrica giusta per qualsiasi attività in cui l'output è codice che verrà effettivamente eseguito.
Cosa regge — e cosa no
L'affermazione principale regge: la messa a punto su prompt aumentati con documentazione migliora drasticamente l'accuratezza delle chiamate API e riduce le allucinazioni. La metodologia di valutazione AST è genuinamente innovativa e chiaramente migliore del confronto di stringhe o della valutazione umana su larga scala. RAT è un'idea pulita e riproducibile.
Ciò di cui sono scettico è la portata del benchmark. Tutti e tre i dataset — HuggingFace, TorchHub, TensorFlow Hub — sono registri di modelli ML con una struttura API molto regolare: carichi un modello per nome, possibilmente con alcuni argomenti chiave, e chiami un metodo simile a predict. Le istruzioni sono generate sinteticamente, il che significa che la distribuzione dei test è strettamente correlata alla distribuzione dell'addestramento. Un modello ottimizzato sulla documentazione API ML addestrato tramite self-instruct, valutato su query self-instruct per API ML, non viene testato sulla difficoltà che effettivamente si presenta in produzione: richieste ambigue, flussi di lavoro multi-step, coercizione del tipo di argomento, autenticazione, limiti di tariffa o recupero da errori.
Anche il degrado del recupero è maggiore di quanto suggerisca la cornice dell'articolo. Un calo di accuratezza del 52% con il recupero BM25 è catastrofico. Se il retriever che distribuisci in produzione assomiglia più a BM25 che a un oracle, i guadagni svaniscono. Gli autori riconoscono questo divario ma non offrono una via per colmarlo.
Infine, il modello stesso è una messa a punto di LLaMA da 7B. Il confronto con GPT-4 zero-shot è sorprendente, ma non è del tutto equo: GPT-4 non è stato addestrato per utilizzare la documentazione recuperata. Un GPT-4 aumentato con RAG con un prompt di sistema progettato per leggere la documentazione API chiuderebbe quasi certamente il divario in modo considerevole.
Perché questo è importante per l'AI finanziaria
Lo schema RAT è direttamente applicabile agli agenti di scrittura Beancount. Un agente Beancount deve invocare comandi CLI (bean-query, bean-report), API Python (beancount.loader, beancount.core) e il servizio FastAPI beancount-ledger — ciascuno con specifiche semantiche di argomento documentate ma non necessariamente presenti nei dati di addestramento del modello. L'approccio Gorilla dice: recupera il frammento di documentazione pertinente al momento dell'inferenza, inietta nel contesto e addestra il modello a leggerlo e seguirlo.
I numeri sulle allucinazioni sono il segnale più utile per un contesto finanziario. Un tasso di allucinazione del 10% sui nomi dei modelli ML è fastidioso. Un tasso di allucinazione del 10% sulle chiamate di mutazione del libro mastro — nomi di conto errati, codici valuta errati, segni di debito/credito invertiti — è un problema di correttezza. L'implicazione è che anche un agente addestrato in stile Gorilla necessita di un validatore a tempo di esecuzione prima che qualsiasi scrittura venga impegnata, in linea con quanto mostrato da CRITIC (LOG-012) sulla critica interattiva con strumenti. Il risultato del degrado del recupero rafforza questo punto: se il recupero nel mondo reale dimezza l'accuratezza, la rete di sicurezza non può essere solo la qualità del recupero.
La metodologia di valutazione AST si traduce naturalmente. Le transazioni Beancount hanno una struttura analizzabile e la verifica delle direttive generate rispetto a uno schema utilizzando il confronto AST è esattamente il tipo di validatore leggero che potrebbe essere eseguito in un hook pre-commit o in un ciclo dell'agente.
Cosa leggere dopo
- ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789) — estende il problema della chiamata API a 16.000 API REST reali con catene di utilizzo di strumenti multi-step; affronta direttamente la limitazione di Gorilla di valutare solo invocazioni di registri ML a chiamata singola
- The Berkeley Function Calling Leaderboard (BFCL) (OpenReview:2GmDdhBdDk, poster NeurIPS 2024) — l'evoluzione diretta di Gorilla in una classifica live che tiene traccia di come i modelli all'avanguardia migliorano nella chiamata di funzioni nel tempo; V3 aggiunge interazioni multi-turno, V4 aggiunge ricerca web agentica
- API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs — valuta i LLM su 73 API in una gamma più ampia di domini, tra cui finanza e servizi web, con uso di strumenti multi-turno; un utile complemento al focus più ristretto di APIBench sull'ML