Les benchmarks mesurent mieux le doute des IA, pas seulement leurs réponses

Deux travaux attaquent le même problème par des côtés opposés. Ils ne sont pas parus le même jour. GitHub a publié ReviewBench, un benchmark ouvert pour la revue de code par IA, bâti sur l'analyse de 103,9 millions de pull requests de sa plateforme. De leur côté, des informaticiens de l'UC Riverside ont décrit une méthode pour repérer les caractéristiques internes qui font qu'un modèle de langage sonne sûr de lui alors qu'il se trompe.

Ni l'un ni l'autre n'est un lancement de produit. Tous deux tentent de répondre à une question que les acheteurs et les utilisateurs posent sans arrêt : quand un modèle affirme quelque chose, comment savoir s'il faut le croire ?

Ce que GitHub a construit

ReviewBench, annoncé sur le GitHub Blog, contient 219 pull requests publiques issues de 187 dépôts open source et de 19 langages. GitHub affirme que la répartition des langages et des tailles de dépôts correspond de près à ses distributions globales. Des ingénieurs seniors ont étiqueté à la main les vrais positifs de référence avant la publication. Le jeu de données est public.

Le benchmark note quatre métriques et classe chaque constat par gravité et par catégorie. Les équipes peuvent découper les résultats selon le type de revue qui les intéresse. GitHub indique que ce changement l'aide à comparer les réviseurs qui signalent beaucoup de problèmes à ceux qui restent discrets, et les taux de détection élevés aux petites suggestions.

Le chiffre important, c'est 103,9 millions. C'est le nombre de pull requests que GitHub a analysées pour caractériser les charges réelles de revue, et les 219 cas suivent cette distribution. GitHub a fait un ajustement volontaire. La taille des pull requests est pondérée vers le milieu et la queue de la distribution, ce qui réduit la surreprésentation des très gros changements. L'entreprise affirme aussi que son évaluation hors ligne de la revue de code Copilot anticipe désormais plus fidèlement la direction des expériences en production.

Ce qui reste inconnu, c'est le score de n'importe quel concurrent. GitHub invite les autres systèmes de revue de code à s'inscrire et à soumettre leurs résultats. Le billet ne publie ni classement ni chiffres d'un modèle de référence.

Pourquoi la confiance n'est pas l'exactitude

L'étude de l'UC Riverside, dirigée par le doctorant Het Patel, a regardé à l'intérieur de deux modèles à poids ouverts : Llama-3.1-8B de Meta, avec 8 000 000 000 de paramètres, et Gemma-2-9B de Google, avec 9 000 000 000 de paramètres. L'équipe a posé des questions à choix multiples et réparti les réponses en quatre catégories, correctes ou incorrectes croisées avec sûres ou incertaines.

À l'aide d'autoencodeurs parcimonieux, les chercheurs ont trouvé trois types de caractéristiques internes : certaines liées surtout à l'incertitude, d'autres surtout aux mauvaises réponses, d'autres mixtes. Supprimer les caractéristiques liées uniquement à l'incertitude a fait chuter brutalement la précision. Cela suggère que ces caractéristiques jouent un vrai rôle dans la production de bonnes réponses. Le texte de l'université indique que modifier certaines caractéristiques change le comportement du modèle sans réentraîner l'ensemble.

« L'hypothèse principale du domaine, c'est que lorsque le modèle est confiant, il a probablement raison, et que lorsqu'il doute, il a plus de chances de se tromper », a déclaré Patel. « Mais on voit souvent les contre-exemples, qui sont bien documentés. »

C'est la partie à retenir. Un score de confiance n'est pas un score de fiabilité, et un modèle qui met des réserves peut quand même avoir raison. Certaines équipes construisent des garde-fous qui bloquent les réponses sous un seuil de confiance. L'étude laisse entendre que ce seuil mesure le mauvais signal.

Des modèles plus petits, des promesses mesurées

Des exemples plus discrets de la même discipline sont apparus ailleurs. Un projet GitHub nommé Jeff-Code associe un modèle de décision de 800 000 000 de paramètres à Qwen 3.8-27B, avec 27 000 000 000 de paramètres, dans un agent de codage. Il annonce des tâches terminées 47 % plus vite (32 % de temps en moins) à taux de réussite égal. Les chiffres sont d'une précision inhabituelle : 62,4 % contre 62,8 % de réussite, soit un écart apparié de moins 0,2 point avec un intervalle à 95 % de moins 2,6 à plus 2,1, sur 1 242 tâches appariées.

Le projet indique aussi où il échoue. Aucun gain de vitesse net sur Terminal-Bench 2.0 (0,96x) ni sur SkillsBench (0,91x). Désactiver la réflexion à chaque tour allait plus vite mais coûtait 7,6 points. Un seuil moins prudent à 0,7 coûtait 4,5 points.

Reflection a de son côté présenté Beam, un modèle à poids ouverts de 501 000 000 000 de paramètres dont 23 000 000 000 sont actifs, et publié en même temps un large tableau de benchmarks. Beam obtient 80,9 sur SWE-bench Verified et 97,8 sur AIME 2 026. L'entreprise affirme atteindre des résultats comparables à GLM-5.2 avec 3 à 4 fois moins de calcul d'inférence. Le modèle est encore en red-teaming final ; les poids, un rapport technique et une fiche de modèle sont promis plus tard ce mois-ci.

Le tableau de benchmarks d'un fournisseur n'est pas une preuve neutre, et les réserves de Reflection comptent. Son indice AA Omniscience est marqué comme portant sur la partition publique seulement, avec ses propres résultats. Reste que l'affirmation d'efficacité est du genre vérifiable une fois les poids livrés.

Là où les chiffres sont empruntés

Les noms de benchmarks connus circulent vite, et pas toujours intacts. Le modèle de décision d1 de Liquid AI est comparé à GPT-6.1 Sol et à Claude Opus 5.5 sur six applications. L'entreprise affirme qu'il égale ou dépasse GPT-6.1 Sol sur quatre d'entre elles et coûte 19 à 200 fois moins. Elle annonce 85 % à 97 % de précision pour trier les pièces bonnes et défectueuses dans une démonstration d'inspection visuelle. Elle précise que le modèle n'a jamais été entraîné pour cette tâche.

Interfaze a publié un tableau de benchmarks pour son modèle Interfaze 1.1 Lite. Le tableau va de GPQA Diamond (85,9, contre 92,4 pour Interfaze) au taux d'erreur de mots en reconnaissance vocale sur VoxPopuli. C'est une comparaison de fournisseur, pas un audit tiers.

En dehors des vendeurs de modèles, Veris a publié un benchmark d'agents vocaux plus intéressant par ce qu'il mesure. Sur VAmoS Pro Bench, un téléviseur allumé derrière l'appelant a fait chuter le taux global de tâches accomplies de 38,7 % à 8,6 %. Neuf des quatorze piles vocales ont terminé moins de 5 % des appels avec télévision. La meilleure pile, Phonic, atteint 57,5 % de tâches accomplies à 1,42 seconde de latence ; la dernière, une cascade Pipecat, atteint 17,3 %.

Veris est franche sur les limites. Le tableau est un seul examen, bâti sur les politiques d'un seul service public, avec des appelants simulés. C'est une affirmation plus étroite qu'un classement général de capacités, et Veris la présente comme telle.

Le vieux débat en dessous

Rien de tout cela ne tranche la question de fond. L'article de David Chalmers sur la possibilité qu'un grand modèle de langage soit conscient, révisé en 2 024, soutient que les modèles actuels n'ont ni traitement récurrent, ni espace de travail global, ni agentivité unifiée. Il conclut qu'il est peu probable que les modèles d'aujourd'hui soient conscients, mais que leurs successeurs pourraient l'être.

C'est du contexte, pas de l'actualité, et cela ne dit rien de la capacité d'un réviseur de code à repérer un bug. Mais cela explique pourquoi le problème de la confiance est difficile. Un modèle qui produit un texte fluide et assuré n'a pas de faculté séparée pour savoir qu'il se trompe. Les travaux de l'UC Riverside suggèrent qu'un tel signal peut être trouvé et ajusté. Ceux de GitHub suggèrent qu'il peut être noté.

Ce que ni l'un ni l'autre ne fournit, c'est un chiffre unique qu'un acheteur puisse inscrire dans un document d'achat. ReviewBench n'a pas encore de résultats de concurrents publiés. La méthode de l'UC Riverside a été montrée sur deux modèles à poids ouverts, pas sur les systèmes fermés que la plupart des entreprises utilisent. Les poids de Beam ne sont pas sortis. Tant que ces écarts ne sont pas comblés, la réponse honnête à « ce modèle est-il fiable » reste un ensemble de mesures étroites, chacune avec un périmètre annoncé.