EN DIRECT
Des documents judiciaires révèlent des propos internes accablants sur le scraping de contenu par l'IA19/09/26|L'armée américaine évite de justesse un incident après un rapport de renseignement halluciné par une IA18/09/26|Une étude révèle que les biais de genre des GPT ne disparaissent pas, ils se transforment17/09/26 · OpenAI|Des modifications d'architecture permettraient de casser les lois d'échelle classiques16/09/26|OpenAI publie un cadre pour signaler les cas de désalignement de ses modèles16/09/26 · OpenAI|NVIDIA dévoile les premiers résultats MLPerf de sa plateforme Vera Rubin NVL7216/09/26 · NVIDIA|OpenAI élargit la publicité dans ChatGPT avec des « Sponsored Agents »16/09/26 · OpenAI|OpenAI se lance dans la publicité avec des « Sponsored Agents »16/09/26 · OpenAI|Google DeepMind lance Gemini 3.8 Live et sa variante à raisonnement étendu15/09/26 · Google DeepMind|L'investissement massif dans les infrastructures IA fait-il courir un risque de bulle ?15/09/26|Une faille dans la surveillance du raisonnement des modèles de langage14/09/26|Stellar Colosseum : un système multi-agents pour la recherche mathématique de long terme14/09/26|Des documents judiciaires révèlent des propos internes accablants sur le scraping de contenu par l'IA19/09/26|L'armée américaine évite de justesse un incident après un rapport de renseignement halluciné par une IA18/09/26|Une étude révèle que les biais de genre des GPT ne disparaissent pas, ils se transforment17/09/26 · OpenAI|Des modifications d'architecture permettraient de casser les lois d'échelle classiques16/09/26|OpenAI publie un cadre pour signaler les cas de désalignement de ses modèles16/09/26 · OpenAI|NVIDIA dévoile les premiers résultats MLPerf de sa plateforme Vera Rubin NVL7216/09/26 · NVIDIA|OpenAI élargit la publicité dans ChatGPT avec des « Sponsored Agents »16/09/26 · OpenAI|OpenAI se lance dans la publicité avec des « Sponsored Agents »16/09/26 · OpenAI|Google DeepMind lance Gemini 3.8 Live et sa variante à raisonnement étendu15/09/26 · Google DeepMind|L'investissement massif dans les infrastructures IA fait-il courir un risque de bulle ?15/09/26|Une faille dans la surveillance du raisonnement des modèles de langage14/09/26|Stellar Colosseum : un système multi-agents pour la recherche mathématique de long terme14/09/26|
Recherche

Un protocole propose d'évaluer les systèmes IA en entreprise via leur chaîne de service, pas leur nom de modèle

Des chercheurs présentent IB2, un protocole d'évaluation qui prend en compte la chaîne de service complète (poids, précision, contrat de sortie, harnais) plutôt que le simple identifiant du modèle, révélant des écarts de performance significatifs selon la configuration de déploiement.

9 septembre 20264 min de lecturePublié pararXiv

Un nouvel article publié sur arXiv pointe une faille méthodologique dans la manière dont les benchmarks actuels évaluent les modèles d'IA destinés aux entreprises. Selon les auteurs, les 18 benchmarks audités notent tous un identifiant de modèle générique, alors que la capacité réellement utilisable dépend d'un ensemble de facteurs conjoints : les poids du modèle, la route de service utilisée, la précision numérique, le contrat de sortie attendu et le harnais d'exécution. Cette confusion serait, selon eux, une source d'erreur de mesure systématique.

Pour y remédier, l'équipe propose un protocole baptisé IB2, structuré en trois volets. D'abord, une vérification préalable en aveugle qui s'assure qu'une route de service donnée peut effectivement exécuter le contrat d'évaluation avant de lui soumettre la moindre tâche. Ensuite, une règle de notation qui intègre les échecs dans le score sans pour autant valoriser des capacités non supportées. Enfin, un mécanisme d'arbitrage structurellement aveugle aux scores obtenus. L'instanciation de référence du protocole comprend 128 tâches verrouillées et 987 assertions couvrant des travaux sur documents, tableurs, graphiques, outils et bases de données — mais ce corpus reste scellé, les auteurs insistant sur le fait que c'est la procédure elle-même, et non le jeu de données, qui constitue l'apport principal.

Appliqué à onze systèmes, le protocole met en évidence plusieurs constats. D'abord, la disponibilité réelle d'une capacité est mesurable et parfois instable : deux exécutions complètes sur les mêmes poids ont échoué à des critères distincts de la porte de validation finale, tandis qu'une troisième l'a franchie avant une nouvelle exécution — des limites que l'identifiant de modèle affiché ne révélait à aucun moment. Ensuite, le pouvoir discriminant des benchmarks n'est pas uniforme : quatre suites sur sept saturent dans une bande resserrée de six systèmes, l'essentiel de l'écart provenant des tâches de bases de données gouvernées et des jointures multi-onglets.

Le résultat sans doute le plus frappant concerne l'impact du choix de la route de service sur les résultats : pour une même révision déclarée du modèle et une même précision, le score est passé de 77,38 à 82,54, avec un intervalle apparié de [0,11 ; 10,60]. Les auteurs précisent toutefois que les deux configurations diffèrent par le mode d'accès, la génération du harnais et l'analyseur d'appels d'outils côté service — la génération du harnais relevant d'ailleurs de leur propre évaluateur, non du point de terminaison testé. Enfin, ils notent que l'exclusion des réponses en échec des dénominateurs modifie l'ordre des classements, ce qui illustre combien la manière de comptabiliser la fiabilité peut changer une conclusion sans changer son énoncé apparent.

Tags
benchmarkingllm-evaluationenterprise-aimethodologyreliability

À lire aussi