Deux scores IA sont-ils réellement comparables ?
Avant de comparer deux scores IA, vérifiez la tâche, les données, le scénario et le niveau de qualité exigé. Un graphique commun ne rend pas comparables des mesures obtenues dans des conditions différentes.
Lorsqu'une annonce exprime un progrès en pourcentage, retrouvez également le résultat de référence et les règles utilisées pour calculer l'écart.
Le score le plus élevé peut répondre à une autre question
Un résultat de débit indique un volume de travail effectué dans certaines conditions. Un résultat de latence décrit un délai selon un autre dispositif. Les placer dans un classement commun ne les rend pas équivalents. Avant le nom du système, lisez ce que l'axe mesure et la condition de qualité associée.
La présentation officielle de MLPerf Inference distingue des scénarios, des objectifs de qualité, des divisions et des catégories de disponibilité. La division Closed vise une comparaison avec le même modèle que la référence ; Open permet davantage de variations, notamment un autre modèle ou un réentraînement. Ces informations changent la lecture d'un résultat.
| Différence repérée | Pourquoi elle compte |
|---|---|
| Scénario différent | Le profil de requêtes et la mesure ne décrivent pas le même usage |
| Objectif de qualité différent | Un gain de vitesse peut accompagner une exigence différente |
| Division différente | Les libertés autorisées dans l'implémentation ne sont pas identiques |
| Nombre d'accélérateurs différent | Le résultat porte sur une autre configuration de système |
| Disponibilité différente | Un résultat expérimental ne décrit pas forcément une offre achetable |
La catégorie de disponibilité mérite sa propre lecture. Un système annoncé comme disponible, en préversion ou destiné à la recherche n'a pas la même signification pour une équipe qui doit commander et exploiter une solution. Le benchmark peut être valide sans répondre au calendrier d'achat.
Refaire le raisonnement qui produit un pourcentage
Voici un calcul illustratif, sans lien avec un matériel réel : un débit passe de 100 à 150 tâches par seconde dans des conditions identiques. L'augmentation est de 50 %. Le nombre 150 représente 150 % de la valeur de départ ; ce n'est pas une hausse de 150 %. Vérifier le dénominateur suffit parfois à repérer une présentation ambiguë.
L'exactitude du calcul ne règle toutefois pas la comparabilité. Si la nouvelle mesure utilise davantage de machines, une autre tâche ou une contrainte de qualité différente, le pourcentage ne décrit plus seulement l'amélioration du système annoncé. Il faut expliquer ce qui a changé.
Recherchez donc la ligne de résultat détaillée et la configuration, pas seulement la diapositive. Le nombre de composants, le logiciel utilisé et les conditions publiées permettent de situer le score. Lorsque l'information manque, laissez la comparaison ouverte plutôt que d'inventer une normalisation par appareil ou par coût.
Choisir un résultat pertinent pour votre propre charge
Un benchmark peut être rigoureux et peu représentatif de votre application. Une équipe qui traite des demandes interactives ne décide pas nécessairement sur le seul débit maximal. Une autre peut accepter un délai plus long pour un traitement différé. Écrivez le besoin opérationnel avant de choisir la métrique.
La bonne question devient alors : quelles parties de notre usage ce protocole représente-t-il, et lesquelles restent à essayer ? Le résultat publié sert à réduire l'incertitude sur un périmètre précis. Le pilote interne examine ce qui manque, avec des entrées et critères documentés.
Remonter du graphique au protocole
Cherchez le document qui définit la mesure, puis le résultat détaillé. Une diapositive commerciale peut servir de point d'entrée ; elle ne remplace pas ces deux éléments.
Les benchmarks MLPerf Inference organisent leurs résultats selon des règles, des scénarios et des catégories. Une comparaison doit respecter ces dimensions plutôt que rapprocher les valeurs les plus avantageuses.
Classer les écarts au lieu de les effacer
Lorsqu'une condition diffère, trois conclusions sont possibles. Les résultats sont directement comparables dans le périmètre défini ; ils ne le sont qu'avec une réserve explicite ; ou les informations disponibles ne permettent pas de conclure.
Ne « corrigez » pas un résultat en inventant un coefficient de normalisation. Une transformation exige une justification méthodologique et des données suffisantes. Sans cela, elle ajoute une précision apparente.
Le NIST présente l'évaluation de l'IA comme un travail de mesure lié aux propriétés et aux contextes étudiés. Cela encourage à formuler la question avant de choisir le chiffre qui doit y répondre.
Cette vérification précède l'évaluation de l'intérêt d'un système IA pour un usage : il faut d'abord savoir si les résultats mesurent la même chose.
Notre méthodologie éditoriale sépare les faits confirmés, l'analyse et les points à surveiller. Appliquez cette distinction à la comparaison : si une condition décisive manque, laissez la conclusion ouverte jusqu'à obtenir le protocole ou le résultat détaillé.