Gorilla : quand le modèle doit choisir la bonne fonction, pas la bonne phrase

Le problème que Gorilla attaque vraiment

Un LLM généraliste à qui l'on demande d'appeler une API produit souvent deux erreurs distinctes. Il peut inventer une fonction qui n'existe pas, ou produire un nom plausible mais mal orthographié, avec des arguments mal nommés. Le README formule l'objectif ainsi : étant donné une requête en langage naturel, Gorilla produit l'API sémantiquement et syntaxiquement correcte à invoquer. Le dépôt revendique avoir été le premier à démontrer l'invocation de plus de 1 600 appels d'API avec réduction de l'hallucination. Le public visé est précis : équipes qui construisent une couche d'appel d'outils au-dessus d'un modèle, et chercheurs qui doivent comparer des modèles sur cette tâche. Le dépôt ne s'adresse pas à quelqu'un qui veut un agent complet avec mémoire et boucle de raisonnement. Il fournit la brique de sélection d'outil, plus un appareil de mesure.

Deux projets dans un seul dépôt

La confusion la plus fréquente vient de là. Le dépôt contient d'un côté du code d'inférence pour exécuter les modèles affinés Gorilla (répertoire gorilla/inference) et du code d'évaluation pour reproduire les résultats de l'article (gorilla/eval), avec APIBench comme jeu de données d'API. De l'autre côté, il héberge le Berkeley Function Calling Leaderboard, abrégé BFCL, avec son propre répertoire berkeley-function-call-leaderboard et son propre CHANGELOG. Ces deux ensembles n'ont pas le même rythme. Les modèles Gorilla publiés remontent à 2023, avec une mention de modèles sous licence Apache 2.0 commercialisables datée du 6 juin 2023. Le leaderboard, lui, a reçu BFCL V2 en août 2024, V3 en septembre 2024, V4 Agentic en juillet 2025, et la version v1.3 des mises à jour du leaderboard est datée du 17 juillet 2025. Lire le dépôt comme un produit unique mène à surestimer la fraîcheur des modèles.

Le mécanisme : affiner sur des paires requête et appel

D'après l'article cité et la description du dépôt, l'approche consiste à affiner un LLM sur des paires qui associent une requête en langage naturel à l'appel d'API correspondant, en s'appuyant sur APIBench comme corpus d'API. La sortie attendue est un appel structuré, pas une réponse rédigée. Le dépôt fournit une interface en ligne de commande pour dialoguer avec Gorilla, documentée dans inference/README.md, ainsi que des modèles publiés sur Hugging Face sous l'organisation gorilla-llm, par exemple gorilla-7b-hf-delta-v0. Le README mentionne aussi des versions Torch Hub et TensorFlow Hub. Le point à retenir sur l'architecture : rien dans le matériel fourni ne décrit un moteur d'exécution qui appellerait réellement l'API à votre place. Gorilla produit l'appel. L'exécution, la gestion des erreurs et la réessai restent à votre charge, sauf à considérer GoEx, présenté en avril 2024 comme un runtime pour les actions générées par LLM, avec validation après exécution, annulation et confinement des dégâts. GoEx a son propre répertoire et son propre article, ce qui en fait un composant adjacent plutôt qu'une partie du coeur de Gorilla.

Le BFCL comme outil de décision, pas comme vitrine

L'intérêt pratique du BFCL est de rendre la comparaison reproductible. Le leaderboard a introduit des métriques de coût et de latence en avril 2024, puis des catégories multi-tours et multi-étapes avec V3, décrites comme un système d'évaluation fondé sur des états pour tester des flux complexes, des fonctions séquentielles et des états de service. V2 Live a ajouté des données fournies par des entreprises et des scénarios réels. V4 Agentic cible la recherche web avec raisonnement multi-sauts et reprise après erreur, la gestion de mémoire d'agent et la sensibilité au format. Ce dernier point mérite attention : si la performance d'un modèle varie selon la formulation du prompt, alors un score unique sur un format donné ne prédit pas son comportement dans votre application. Le BFCL est donc plus utile exécuté sur vos propres définitions de fonctions que consulté comme un classement général. Le README renvoie à un blog dédié sur la sensibilité au format, ce qui indique que les auteurs considèrent ce facteur comme un résultat en soi.

Ce qu'il faut pour démarrer, et ce que la documentation ne dit pas

Le matériel fourni donne peu de commandes exactes. On sait que l'interface de dialogue avec Gorilla est documentée dans inference/README.md et que le code d'évaluation vit dans gorilla/eval. Le leaderboard possède son propre répertoire, berkeley-function-call-leaderboard, avec un CHANGELOG.md à sa racine. Pour le reste, il faut ouvrir les fichiers. C'est une limite réelle du dépôt vu de l'extérieur : un lecteur qui cherche une séquence d'installation copiable dans le README principal n'en trouvera pas ici. La licence Apache-2.0 couvre le dépôt, et le README indique que les modèles Gorilla sont publiés sous cette même licence avec usage commercial possible depuis juin 2023. Cela ne dit rien du statut des données APIBench ni des contributions communautaires via le guide APIZoo, ni des conditions propres à chaque API référencée. Vérifiez ces points séparément avant un usage en production.

Les cas où Gorilla n'est pas le bon outil

Trois situations ressortent du matériel. D'abord, si vous avez besoin d'un agent qui planifie, exécute, observe le résultat et recommence, le dépôt ne fournit pas cette boucle dans son coeur : GoEx existe, mais comme projet distinct avec son propre article et son propre répertoire, et le README ne présente pas de chemin d'intégration unifié. Ensuite, si votre besoin est de suivre l'état d'un service entre plusieurs appels, l'évaluation V3 du BFCL teste précisément cette capacité, mais le fait que le benchmark ait dû ajouter un système fondé sur des états suggère que les modèles évalués ne la géraient pas de façon fiable auparavant. Enfin, si vous cherchez un modèle récent, les modèles Gorilla publiés datent de 2023. Le dépôt a continué de vivre par son leaderboard, pas par de nouvelles versions de modèles. Utiliser Gorilla aujourd'hui, c'est probablement utiliser le BFCL pour évaluer un modèle plus récent, pas déployer le modèle Gorilla lui-même.

Comparer avec une approche sans affinage

L'alternative directe est de s'appuyer sur les schémas d'outils natifs d'un fournisseur de modèle, où les définitions de fonctions sont passées dans la requête et le modèle renvoie un appel structuré, sans affinage préalable. La différence d'approche est nette : Gorilla déplace le travail en amont, dans un affinage sur un corpus d'API, tandis que l'approche par schéma déplace le travail dans le prompt à chaque appel. La première suppose de collecter et maintenir des données d'entraînement représentatives de vos fonctions. La seconde coûte des tokens à chaque requête et dépend de la qualité du schéma fourni. Le BFCL existe justement parce que la seconde approche n'est pas uniformément fiable : le classement compare des modèles sur des catégories comme les appels multiples, le parallélisme et l'abstention, ce qui suppose que ces comportements varient d'un modèle à l'autre. Si votre catalogue de fonctions change souvent, l'affinage devient un coût récurrent, alors qu'un schéma se modifie dans le code.

Coût de maintenance et horizon du dépôt

Le dépôt n'est pas archivé et le dernier push est daté du 13 avril 2026. Les versions publiées concernent exclusivement le leaderboard : v1.1 en août 2024, v1.2 en janvier 2025, v1.3 en juillet 2025. Aucune version ne porte sur les modèles. Cette asymétrie est le principal signal de maintenance : le BFCL est un projet actif avec un changelog suivi, les modèles sont un artefact de recherche de 2023. Pour un utilisateur, cela signifie que la partie évaluation demande un suivi des mises à jour de catégories et de jeux de données, tandis que la partie inférence est stable par inertie. Le README mentionne environ 500 000 requêtes servies depuis la sortie initiale, chiffre d'usage et non de qualité. Sur le plan juridique, Apache-2.0 autorise l'usage commercial du code et des modèles selon le README, mais l'origine des données APIBench et les conditions des API tierces référencées ne sont pas détaillées dans le matériel fourni. Ce n'est pas un avis juridique : faites vérifier la chaîne de provenance des données si vous entraînez sur APIBench.

Conclusion éditoriale

Adoptez Gorilla si votre problème est la sélection et la syntaxe d'appels d'API par un LLM, et si vous acceptez de faire tourner le BFCL vous-même pour obtenir un chiffre comparable sur vos propres fonctions. Passez votre chemin si vous cherchez un orchestrateur d'agents prêt à l'emploi : le dépôt ne le fournit pas. Avant tout engagement, vérifiez le contenu réel du répertoire berkeley-function-call-leaderboard et l'état de la recette d'affinage, car les modèles publiés datent de 2023 alors que le leaderboard a continué d'évoluer jusqu'à la version v1.3 de juillet 2025.

Sources officielles

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. ShishirPatil/gorilla on GitHub