Artificial Analysis détecte des pertes de qualité sur 24 des 103 endpoints d'API testés

Le nom du modèle dans les paramètres de l'API ne garantit pas encore la qualité attendue. Un agent peut choisir correctement l'outil, mais le fournisseur transmettra ses arguments dans un format incorrect. Ou bien le modèle dépensera toute la réponse disponible en raisonnement sans jamais arriver au résultat. Pour l'utilisateur, les deux cas se ressemblent : le produit n'a pas accompli la tâche.

Artificial Analysis a mis à jour l'Endpoint Accuracy Index en version 1.1. Sur les 103 endpoints serveur testés, 24 se sont révélés statistiquement inférieurs au déploiement de référence du modèle correspondant. Cela représente environ 23 % de l'échantillon. La conclusion pratique pour les équipes : lors du choix d'une API, il faut tester le fournisseur concret, même si le modèle lui-même a déjà réussi vos tests.

Où la qualité se perd

Un cas révélateur est celui de GLM-5.3 Flash. Pour deux endpoints, la réponse maximale est limitée à environ 32 mille tokens. Environ la moitié des réponses aux questions difficiles de HLE-250 butaient sur ce plafond avant d'obtenir un résultat. La part de réponses correctes s'est établie à 22,3 % et 28,5 %, alors que le déploiement de référence atteignait 55,4 %.

Il existe aussi des limitations moins visibles. Deux autres endpoints du même modèle produisaient environ 30 % de tokens de raisonnement en moins, sans troncature apparente de la réponse. Leurs résultats sur HLE-250 sont de 48,4 % et 48,6 %. Cette seule observation ne permet pas d'établir la cause interne, mais pour le développeur la différence est importante : des réglages demandés identiques n'ont pas produit un comportement identique.

Avec les outils, le problème peut être très terre à terre. Imaginez un service de réservation où l'identifiant de commande doit arriver sous forme de chaîne. Deux endpoints de Muse Spark Open renvoyaient ces arguments sous forme de nombres. Dans un scénario à plusieurs étapes, cela suffit pour que l'appel ne respecte plus le contrat de l'outil. Sur le test BFCL-500, ils ont obtenu 49,9 % et 50,7 %, contre 59,1 % pour la référence.

D'autres défaillances relevées comprenaient des noms de paramètres corrompus, des objets sous forme de chaînes JSON et la réutilisation d'identifiants d'appels d'outils. Sur un endpoint de Kimi K3, les requêtes étaient interrompues au bout d'environ dix minutes : environ 9 % des tâches HLE-250 se terminaient sans réponse du modèle.

Ce que mesure l'indice

Chaque endpoint passe trois vérifications : appels d'outils, questions scientifiques complexes et recherche d'informations dans un contexte long d'environ 100 mille tokens en entrée. Le résultat de chaque vérification est divisé par celui de l'exécution de référence, exprimé en pourcentage, puis moyenné avec des poids égaux.

C'est pourquoi une valeur d'indice de 100 % correspond au niveau de la référence, et non à une exactitude de 100 % des réponses. Une valeur supérieure à 100 % ne prouve pas non plus la supériorité du fournisseur : il faut regarder l'intervalle d'incertitude. Les auteurs considèrent qu'un endpoint est en retrait lorsque tout son intervalle de confiance à 95 % se situe sous 100 %.

Dans la version 1.1, le nombre de répétitions dans la vérification du contexte long est passé de 10 à 25, les clés de réponse de deux questions ont été corrigées et le modèle de vérification des correspondances a été mis à jour. Sur l'échantillon global, l'erreur moyenne de cette vérification est passée de ±4,7 à ±2,6 points de pourcentage. Les résultats de versions différentes ne sont pas directement comparables.

Pour autant, attribuer toutes les pertes à la quantification serait une erreur. Les trois endpoints de GLM-5.3 Flash avec des poids FP4 se sont révélés statistiquement au niveau de la référence FP8. Quant à DeepSeek V4.1 Flash 1017, ses 22 endpoints testés correspondaient tous à la référence dans la limite de l'incertitude.

Que vérifier avant de connecter une API

Pour une équipe, l'indice est utile comme filtre avant ses propres essais. Vérifiez la longueur maximale de réponse, le délai d'expiration de la requête, la fermeture correcte du flux et les types réels des arguments d'outils. Ensuite, faites tourner plusieurs tâches caractéristiques du produit de bout en bout : de la requête de l'utilisateur à la dernière action de l'agent. La vérification d'une réponse isolée ne montrera pas ce qui cassera au troisième appel d'outil.

Les limites de l'étude sont importantes. Trois tests ne décrivent pas toutes les charges de travail, et l'absence de retard statistiquement significatif ne garantit pas une égalité complète. Les mesures ont été réalisées du 8 octobre au 4 novembre 2026 ; les paramètres des fournisseurs ont pu changer depuis. Le prix et la latence restent des critères importants, mais la qualité d'un endpoint précis peut désormais être vérifiée séparément — et intégrée à la procédure de changement de fournisseur.