🤖 machine learning

Benchmarking Web API Integration Code Generation

Cet article présente WAPIIBench, un ensemble de données et un pipeline d'évaluation révélant que les modèles de langage de grande taille open-source actuels éprouvent des difficultés significatives à générer du code d'intégration d'API web correct, atteignant moins de 40 % de succès en raison de problèmes tels que des points de terminaison hallucinés et une utilisation incorrecte des arguments.

Auteurs originaux : Daniel Maninger, Leon Chemnitz, Amir Molzam Sharifloo, Jannis Brugger, Mira Mezini

Publié 2026-07-07

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Daniel Maninger, Leon Chemnitz, Amir Molzam Sharifloo, Jannis Brugger, Mira Mezini

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayez d'apprendre à un robot très intelligent et très cultivé comment commander un plat spécifique sur un menu de restaurant immense et complexe. Le menu n'est pas seulement une liste de plats ; c'est un ensemble strict de règles sur la façon d'écrire votre commande, les boutons sur lesquels appuyer et les ingrédients exacts à lister. Si vous faites ne serait-ce qu'une seule erreur de détail, la cuisine rejettera la commande.

Ce document porte sur l'évaluation de la capacité de ces « robots » (qui sont en réalité des modèles de langage étendus, ou LLM — la même technologie derrière les chatbots IA) à écrire le code nécessaire pour envoyer ces commandes à de véritables services web (comme Google Calendar, Slack ou Asana).

Voici une décomposition de ce que les chercheurs ont fait et de ce qu'ils ont trouvé, en utilisant des analogies simples :

Le Problème : La « Magie » n'est pas encore de la magie

Les développeurs utilisent des « API Web » pour faire communiquer différents logiciels entre eux. C'est comme assembler des blocs Lego. Habituellement, les humains doivent écrire les instructions pour emboîter ces blocs. L'espoir était que l'IA puisse faire cela automatiquement.

Les chercheurs se sont posé la question suivante : L'IA peut-elle regarder une requête simple telle que « Ajouter un nouvel événement à mon calendrier » et écrire le code parfait, sans erreur, pour que cela se produise ?

L'Expérience : Construire un « examen du permis de conduire » pour l'IA

Pour le découvrir, l'équipe a construit un test spécial appelé WAPIIBench. Considérez cela comme un examen du permis de conduire pour le code de l'IA.

Le Parcours : Ils ont créé 395 « scénarios de conduite » spécifiques utilisant quatre services réels populaires (Asana, Google Calendar, Google Sheets et Slack).
Les Règles : Ils ont utilisé les « manuels du conducteur » officiels (spécifications OpenAPI) pour ces services afin de savoir exactement à quoi ressemble une commande correcte.
Le Test : Ils ont donné une instruction à l'IA (ex : « Créer un nouveau calendrier ») et lui ont demandé d'écrire le code.
La Vérification : Au lieu de simplement lire le code pour voir s'il semble correct, ils ont réellement essayé de l'exécuter dans un bac à sable (sandbox) sûr et contrôlé. Si le code tentait d'envoyer une commande à une adresse inexistante ou utilisait les mauvais ingrédients, le test échouait.

Les Résultats : L'IA se perd souvent

Les résultats ont été un peu décevants pour ceux qui espéraient une automatisation instantanée.

Le Score : Même les meilleurs modèles d'IA open-source n'ont réussi que 30 % à 40 % des tâches de manière totalement correcte. Le meilleur modèle commercial (GPT-4o) a fait mieux, atteignant environ 60-77 %, mais cela signifie qu'il échoue encore près d'un tiers du temps.
Les « Hallucinations » : C'est le problème majeur. L'IA invente souvent des choses.
- Fausses Adresses : L'IA inventait des adresses URL qui n'existent pas (comme dire à un chauffeur de taxi d'aller au « 123 Rue de la Fausse Adresse » alors que le restaurant est en fait au « 456 Rue Principale »). Cela s'est produit dans jusqu'à 39 % des cas.
- Mauvais Ingrédients : L'IA incluait des paramètres (ingrédients) que le service n'acceptait pas, ou en oubliait certains qui étaient requis.
Succès Partiel : L'IA était douée pour se souvenir de la forme générale du code (comme savoir qu'elle doit utiliser la méthode POST, ce qui revient à savoir qu'il faut « passer une commande » plutôt que d'en « annuler une »). Mais lorsqu'il s'agissait des détails spécifiques de où l'envoyer et de ce qu'il faut dire exactement, elle avait du mal à assembler les pièces correctement.

Quelques Twists Surprenants

Plus gros n'est pas forcément mieux : Parfois, un modèle d'IA de taille moyenne a moins bien performé qu'un modèle minuscule et qu'un modèle énorme. C'est comme un étudiant qui a trop étudié pour le mauvais examen et qui finit par être confus.
Mémoire vs Compréhension : L'IA semblait avoir « mémorisé » des parties des manuels lors de son entraînement. Elle connaissait certaines URL et noms d'arguments, mais ne pouvait pas les combiner de manière fiable pour résoudre un nouveau problème spécifique. C'était comme un étudiant qui avait mémorisé les réponses de l'examen de mathématiques de l'année dernière, mais qui était incapable de résoudre les problèmes de cette année.
L'astuce du « Texte à trous » : Lorsque les chercheurs ont donné l'adresse correcte (URL) à l'IA et lui ont simplement demandé de remplir le reste, l'IA a bien mieux réussi. Cela suggère que l'IA sait suivre des instructions si elle n'a pas à deviner la destination en premier.

L'Essentiel

Le document conclut que, bien que l'IA devienne douée pour écrire du code, elle n'est pas encore assez fiable pour connecter automatiquement des systèmes logiciels sans supervision humaine. Si vous laissez une IA écrire du code pour connecter vos applications professionnelles à Internet dès maintenant, elle enverra probablement vos données au mauvais endroit ou brisera la connexion environ 60 % à 70 % du temps.

Les chercheurs affirment que nous avons besoin de meilleurs contrôles de sécurité et de nouvelles façons d'aider l'IA à « consulter » les règles en temps réel (plutôt que de compter sur sa mémoire) avant de pouvoir lui faire confiance pour construire ces connexions de manière autonome.

Résumé technique : Évaluation de la génération de code d'intégration d'API Web

Énoncé du problème

L'intégration d'API Web est une composante fondamentale de l'infrastructure logicielle moderne, pourtant, écrire le code correct pour invoquer ces API reste une tâche complexe et fastidieuse pour les développeurs. Bien que les modèles de langage de grande taille (LLM) aient démontré un potentiel significatif dans l'automatisation du développement logiciel, leur efficacité spécifique dans la génération de code d'invocation d'API Web reste largement inexplorée. Contrairement aux appels de fonctions locales, les invocations d'API Web impliquent une syntaxe complexe, incluant des méthodes HTTP spécifiques, des URL paramétrées, des corps de requête, des en-têtes et des paramètres de requête, souvent documentés dans des spécifications externes (par exemple, OpenAPI) qui ne sont pas toujours accessibles dans la fenêtre de contexte du modèle.

La question de recherche centrale est la suivante : Quelle est la justesse du code d'invocation d'API Web généré par les LLM, et quels types d'erreurs sont couramment présents dans ce code ?

Méthodologie

Pour répondre à cette question, les auteurs introduisent WAPIIBench, un nouveau jeu de données et un pipeline d'évaluation conçu pour évaluer systématiquement les capacités des LLM dans ce domaine.

1. Création du jeu de données (WAPIIBench)

Le jeu de données se compose de 395 paires tâche-configuration dérivées de quatre API réelles respectant la norme OpenAPI : Asana, Google Calendar, Google Sheets et Slack Web.

Synthèse : Contrairement au sourcing à partir de dépôts existants (qui manquent souvent de descriptions de tâches sans ambiguïté), les auteurs ont synthétisé les tâches en utilisant Gemini 1.5 Pro. Le modèle a reçu les spécifications OpenAPI complètes ainsi que des instructions détaillées pour générer une description de tâche en langage naturel ( $t$ ) et une configuration de requête de vérité terrain correspondante ( $c$ ).
Validation : Les données générées ont subi une curation automatisée et manuelle rigoureuse pour garantir que chaque tâche possède une configuration unique et soluble, et que les arguments reflètent correctement la tâche.
Structure : Chaque échantillon représente un point de terminaison (endpoint) d'API, capturant la méthode HTTP, l'URL et les arguments (corps, en-têtes, paramètres de requête).

2. Pipeline d'évaluation

L'évaluation suit un processus en quatre étapes :

Génération de code : Les LLM sont chargés de compléter un code de départ (JavaScript utilisant la bibliothèque Axios) basé sur une description de tâche. Deux configurations ont été testées :
- Complétion complète (Full Completion) : Le modèle doit générer la méthode HTTP, l'URL et tous les arguments.
- Complétion d'arguments (Argument Completion) : Le modèle se voit fournir la méthode et l'URL correctes et doit uniquement générer les arguments.
Exécution du code : Le code généré est exécuté dans un environnement contrôlé et isolé (Mock) qui intercepte les requêtes sortantes. Cette approche privilégie la justesse fonctionnelle plutôt que la similitude syntaxique, capturant la configuration de requête réelle ( $c'$ ) envoyée par le code.
Analyse de la justesse : La configuration capturée ( $c'$ ) est comparée à la vérité terrain ( $c$ ) et validée par rapport à la spécification de l'API ( $s$ ).
Métriques : L'étude utilise des métriques fines, notamment :
- Implémentations correctes : Pourcentage de code exécutable correspondant à la vérité terrain.
- Implémentations illégales : Code violant la spécification de l'API.
- Précision de l'URL/de la méthode : Justesse des points de terminaison et des méthodes HTTP.
- Précision/Rappel des arguments : Exactitude des noms et des valeurs des paramètres.

3. Modèles évalués

Le benchmark a évalué 21 modèles LLM open-source de pointe (incluant StarCoder, DeepSeek-Coder, Qwen-Coder, Code Llama et Llama 3.1) aux côtés de modèles commerciaux (GPT-4o et GPT-4o mini) pour établir des bases de référence de performance.

Résultats clés

Les expériences révèlent que générer du code d'invocation d'API Web correct est un défi de taille pour les LLM actuels, même pour les modèles open-source les plus performants.

Justesse globale : Aucun des modèles open-source évalués n'a résolu plus de 40 % des tâches.
- Dans la configuration de Complétion complète, le meilleur modèle open-source (Code Llama 70B) a atteint 30 % de justesse, tandis que GPT-4o a atteint 60 %.
- Dans la configuration de Complétion d'arguments (où le point de terminaison est connu), Code Llama 70B s'est amélioré à 40 %, et GPT-4o a atteint 77 %.
Types d'erreurs :
- Hallucinations d'endpoints : Un mode de défaillance primaire est la génération d'URLs incorrectes ou inexistantes. Jusqu'à 39 % des URLs étaient illégales dans la configuration de complétion complète.
- Erreurs d'arguments : Les modèles hallucinent fréquemment des noms de paramètres (jusqu'à 31 % d'arguments illégaux) ou omettent des arguments requis.
- Échecs d'exécution : Plusieurs modèles (par exemple, Qwen2.5-Coder, Llama 3.1) ont produit du code non exécutable dans la configuration de complétion complète en raison d'erreurs de syntaxe ou de refus de compléter le code, entraînant des métriques de justesse de 0 % pour ces modèles.
Comportement des modèles :
- Les modèles performent généralement bien pour prédire les méthodes HTTP (GET/POST) mais peinent avec la nature non restreinte des URLs et des arguments.
- Les modèles plus larges ne surpassent pas toujours les plus petits ; dans certaines familles, les variantes de taille moyenne ont moins bien performé que leurs homologues plus petites ou plus grandes.
- La performance varie considérablement selon les API, ce qui est probablement corrélé à la prévalence de certaines API dans les données d'entraînement des modèles.

Signification et contributions

L'article apporte trois contributions principales au domaine du génie logiciel et de l'IA :

Jeu de données WAPIIBench : Le premier jeu de données de ce type contenant près de 400 paires de tâches d'invocation d'API Web et de résultats attendus à travers quatre API réelles, spécifiquement conçu pour une analyse de justesse basée sur l'exécution.
Pipeline d'évaluation Open-Source : Un nouveau pipeline sûr et automatisé pour évaluer les modèles de génération de code sur des tâches d'API Web en utilisant des métriques fines qui distinguent la justesse syntaxique, la conformité à la spécification et le succès fonctionnel.
Aperçus empiriques : L'étude fournit la première preuve systématique que si les LLM possèdent certaines connaissances mémorisées des spécifications d'API, ils peinent à synthétiser ces connaissances en invocations correctes et conformes aux spécifications sans contexte externe. Le taux élevé d'hallucinations d'endpoints et d'arguments souligne une lacune critique dans la fiabilité actuelle des modèles pour l'intégration d'API de niveau production.

Les auteurs concluent que bien que les LLM soient prometteurs, des limitations importantes subsistent. Ils soulignent la nécessité d'intégrer des techniques d'assurance qualité (telles que la génération augmentée par récupération, le réglage fin ou le décodage contraint) dans les flux de travail de génération de code pilotés par l'IA pour garantir la justesse et la fiabilité du code d'intégration d'API Web. Le benchmark sert de fondation pour de futures recherches visant à améliorer ces capacités.