Gorilla : Comment le Retrieval-Aware Training réduit les hallucinations d'API des LLM de 78 % à 11 %

Lecture de l'article sur Gorilla (Patil et al., 2023, arXiv:2305.15334, NeurIPS 2024) car il se situe à la jonction de deux problèmes que je rencontre sans cesse : comment faire en sorte qu'un agent LLM appelle le bon outil avec les bons arguments, et comment maintenir cette capacité alors que les API évoluent ? Les réponses ici sont pratiques et les chiffres sont étonnamment probants — mais les hypothèses intégrées à l'évaluation méritent un examen plus approfondi qu'elles n'en reçoivent habituellement.

L'article

Gorilla, par Shishir G. Patil, Tianjun Zhang, Xin Wang et Joseph E. Gonzalez de l'UC Berkeley, s'attaque à un mode d'échec concret : les LLM de pointe hallucinent les appels d'API. Lorsqu'on leur demande d'écrire du code qui invoque une fonction de bibliothèque spécifique, GPT-4 (à la mi-2023) génère fréquemment des signatures de fonction d'apparence plausible mais erronées, des modèles inexistants ou des noms d'arguments obsolètes. Gorilla est un modèle basé sur LLaMA de 7 milliards de paramètres, affiné spécifiquement pour générer des appels d'API précis, entraîné avec une technique que les auteurs appellent Retriever-Aware Training (RAT). L'idée est simple : pendant l'entraînement, le modèle reçoit la documentation de l'API récupérée à côté de la requête de l'utilisateur, formatée comme suit : « Utilisez cette documentation d'API pour référence : <retrieved_API_doc_JSON> ». Cela apprend au modèle à la fois à lire la documentation et à faire confiance au contexte récupéré plutôt qu'à sa mémoire paramétrique — une propriété qui porte ses fruits au moment de l'inférence lorsque la documentation a changé.

L'ensemble de données d'évaluation, APIBench, couvre 925 API du HuggingFace Model Hub, 95 API de TorchHub et 696 API de TensorFlow Hub, avec dix requêtes de suivi d'instructions synthétiques générées par API via self-instruct. La métrique d'évaluation est la correspondance de sous-arbre AST (Abstract Syntax Tree) — l'appel d'API généré est analysé et vérifié pour sa correction fonctionnelle — ce qui permet également, pour la première fois dans ce cadre, une mesure rigoureuse du taux d'hallucination.

Idées clés

• Le RAT rend la documentation lisible au moment de l'inférence. En s'entraînant sur des prompts incluant la documentation récupérée, Gorilla apprend à s'en remettre au texte récupéré plutôt qu'à se souvenir des détails de l'API à partir de ses poids. Cela signifie que le modèle reste à jour à mesure que les API évoluent sans nouvel entraînement.
• Précision zero-shot : Gorilla 59–84 %, GPT-4 18–39 %. Sur TorchHub, Gorilla atteint 59,13 % contre 38,70 % pour GPT-4. Sur HuggingFace, c'est 71,68 % contre 19,80 %. Sur TensorFlow Hub, 83,79 % contre 18,20 %. La marge est la plus grande là où l'espace API est le plus diversifié.
• La réduction des hallucinations est le point saillant. Le taux d'hallucination de Gorilla est de 6,98 % sur TorchHub, 10,95 % sur HuggingFace et 5,40 % sur TensorFlow Hub. Les taux de GPT-4 vont de 36,55 % à 78,65 % sur les mêmes jeux de données.
• Le moteur de recherche oracle est le plafond. Avec le document de référence récupéré (mode oracle), la précision atteint 67–94 %. C'est le meilleur cas théorique pour tout système basé sur le RAG, et l'écart entre Gorilla zero-shot et ce plafond représente la marge de progression possible pour le moteur de recherche.
• Les moteurs de recherche réels sont insuffisants. Le passage de l'oracle à GPT-Index au moment de l'évaluation dégrade la précision de 29,20 % ; BM25 la dégrade de 52,27 %. La robustesse du modèle au bruit de recherche est réelle, mais pas illimitée.
• L'évaluation AST se généralise. L'approche de correspondance de sous-arbre mesure si l'appel généré est fonctionnellement correct, et pas seulement syntaxiquement similaire. C'est la bonne métrique pour toute tâche où la sortie est du code qui sera réellement exécuté.

Ce qui tient la route — et ce qui ne la tient pas

L'affirmation centrale tient bon : le fine-tuning sur des prompts augmentés de documentation améliore considérablement la précision des appels d'API et réduit les hallucinations. La méthodologie d'évaluation AST est véritablement novatrice et nettement meilleure que la correspondance de chaînes de caractères ou l'évaluation humaine à grande échelle. Le RAT est une idée propre et reproductible.

Ce dont je doute, c'est de la portée du benchmark. Les trois jeux de données — HuggingFace, TorchHub, TensorFlow Hub — sont des registres de modèles de ML avec une structure d'API très régulière : vous chargez un modèle par son nom, éventuellement avec quelques arguments par mots-clés, et appelez une méthode de type predict. Les instructions sont générées de manière synthétique, ce qui signifie que la distribution de test est étroitement liée à la distribution d'entraînement. Un modèle optimisé sur la documentation d'API de ML entraîné via self-instruct, évalué sur des requêtes self-instruct pour les API de ML, n'est pas testé sur la complexité qui apparaît réellement en production : requêtes ambiguës, flux de travail en plusieurs étapes, coercition de type d'argument, authentification, limites de débit ou récupération d'erreur.

La dégradation due à la recherche est également plus importante que ne le suggère la présentation de l'article. Une baisse de précision de 52 % avec la recherche BM25 est catastrophique. Si le moteur de recherche que vous déployez en production ressemble plus à BM25 qu'à un oracle, les gains s'évaporent. Les auteurs reconnaissent cet écart mais ne proposent pas de piste pour le combler.

Enfin, le modèle lui-même est un fine-tune de LLaMA 7B. La comparaison avec GPT-4 zero-shot est frappante mais n'est pas tout à fait juste : GPT-4 n'a pas été entraîné à utiliser de la documentation récupérée. Un GPT-4 augmenté par RAG avec un prompt système conçu pour lire les docs d'API comblerait presque certainement l'écart de manière considérable.

Pourquoi cela est important pour l'IA en finance

Le modèle RAT est directement applicable aux agents d'écriture Beancount. Un agent Beancount doit invoquer des commandes CLI (bean-query, bean-report), des API Python (beancount.loader, beancount.core) et le service FastAPI beancount-ledger — chacun avec une sémantique d'arguments spécifique qui est documentée mais pas nécessairement présente dans les données d'entraînement du modèle. L'approche Gorilla préconise de : récupérer l'extrait de documentation pertinent au moment de l'inférence, l'injecter dans le contexte et entraîner le modèle à le lire et à le suivre.

Les chiffres sur l'hallucination sont le signal le plus utile pour un contexte financier. Un taux d'hallucination de 10 % sur des noms de modèles de ML est agaçant. Un taux d'hallucination de 10 % sur des appels de mutation de grand livre — mauvais noms de comptes, mauvais codes de devises, signes débit/crédit inversés — est un problème d'exactitude. Cela implique que même un agent entraîné à la manière de Gorilla a besoin d'un validateur au moment de l'exécution avant qu'une écriture ne soit validée, ce qui est cohérent avec ce que CRITIC (LOG-012) a montré sur la critique interactive par les outils. Le constat de dégradation de la recherche renforce cela : si la recherche en conditions réelles réduit la précision de moitié, le filet de sécurité ne peut pas reposer sur la seule qualité de la recherche.

La méthodologie d'évaluation AST se transpose naturellement. Les transactions Beancount ont une structure analysable, et vérifier les directives générées par rapport à un schéma à l'aide de la correspondance AST est exactement le type de validateur léger qui pourrait s'exécuter dans un hook de pré-commit ou une boucle d'agent.

Que lire ensuite

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789) — étend le problème de l'appel d'API à 16 000 API REST réelles avec des chaînes d'utilisation d'outils en plusieurs étapes ; répond directement à la limitation de Gorilla qui n'évalue que les invocations de registres ML à appel unique.
• The Berkeley Function Calling Leaderboard (BFCL) (OpenReview:2GmDdhBdDk, poster NeurIPS 2024) — l'évolution directe de Gorilla vers un classement dynamique suivant l'amélioration des modèles de pointe dans l'appel de fonctions au fil du temps ; la V3 ajoute des interactions multi-tours, la V4 ajoute la recherche web agentique.
• API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs — évalue les LLM sur 73 API à travers un éventail plus large de domaines incluant la finance et les services web, avec une utilisation d'outils multi-tours ; un complément utile à la focalisation plus étroite d'APIBench sur le ML.