Une comparaison de modèles commence par une tâche précise : quelle était notre demande, et le résultat a-t-il répondu à nos exigences ? Nous testons les modèles d’IA sur GlobalGPT à l’aide de l’interface de ligne de commande (CLI) de GlobalGPT. Les exceptions sont répertoriées dans l’article correspondant.
L'IA vérifie les résultats pour détecter d'éventuelles erreurs et s'assurer qu'ils respectent les consignes. Lorsque les résultats satisfont à ces contrôles, nous comparons la rapidité, le prix et l'utilisation des jetons, le cas échéant. Les auteurs évaluent également des critères subjectifs, tels que le style rédactionnel et l'attrait visuel. L'évaluation audio est entièrement réalisée par l'IA à l'aide de Gemini 3.6 Flash.
Nous sommes les Équipe d'évaluation GlobalGPT, qui fait partie de GlobalGPT. Cette méthodologie couvre les tests que nous publions sur le blog lors du lancement de nouveaux modèles, ainsi que les comparaisons entre modèles. Les rapports de recherche basés sur les données des utilisateurs de GlobalGPT expliquent leurs propres ensembles de données et leurs méthodes d'analyse.
Notre environnement de test : GlobalGPT CLI
L'interface CLI GlobalGPT constitue notre environnement de test par défaut. Tout test utilisant une interface, une route API ou un outil de programmation natif différent doit être interprété dans ce contexte. Les noms des modèles, les paramètres disponibles, les outils et les droits d'accès peuvent varier d'un environnement à l'autre.
Le modèle qui génère un résultat et l'IA qui l'évalue ont des rôles différents. Le jugement d'un évaluateur constitue une indication sur le résultat fourni ; il ne permet pas de déterminer le fonctionnement interne du modèle testé.
Conception des tâches : consignes, données d'entrée et exigences
Nous confions aux modèles des tâches concrètes assorties d'exigences clairement définies. Une tâche d'écriture peut par exemple consister à rédiger un résumé en s'appuyant uniquement sur des notes fournies. Une tâche de programmation peut consister à créer une fonction capable de gérer une entrée vide. Une tâche liée à l'image peut consister à rédiger le texte exact qui figurera sur une affiche.
À titre de comparaison, la consigne et les données d'entrée définissent ce que l'on demande à chaque modèle de faire. Les différences au niveau des formats pris en charge, des paramètres ou des outils disponibles ont leur importance lors de l'interprétation des résultats. Une comparaison de consignes fixes et un tutoriel permettant d'améliorer une consigne au fil de plusieurs essais apportent des réponses à des questions différentes.
Évaluation des résultats : erreurs, instructions et efficacité
Erreurs et respect rapide des consignes
L'IA évalue si le résultat est conforme à la tâche et s'il contient des erreurs identifiables. Les vérifications pertinentes peuvent porter sur des calculs erronés, des affirmations non étayées, des champs manquants ou le non-respect d'un format requis.
Le résultat « réussi » signifie qu'aucune erreur n'a été détectée par les contrôles effectués. Cela ne garantit pas que le résultat soit exempt de toute erreur possible. Les évaluateurs basés sur l'IA peuvent passer à côté d'erreurs ou émettre des jugements erronés.
Les éléments attestant de la mise en œuvre constituent une partie distincte de l'évaluation. Dans notre Test du plan de codage de Kimi, le code généré a fait l'objet de cinq vérifications locales. La lecture du code, le fait de demander à un modèle d'examiner sa propre réponse et l'exécution de tests fournissent des éléments de preuve différents.
Vitesse, prix et utilisation des jetons
Une fois qu'un résultat répond aux exigences de la tâche, c'est l'efficacité qui permet de distinguer les options valables. Une réponse rapide qui omet un calcul obligatoire n'a pas accompli la même tâche qu'une réponse correcte.
| Mesure | Comment le lire |
|---|---|
| L'heure | Vérifiez la fenêtre de mesure. Le délai entre la demande et l'achèvement inclut le trajet et le traitement associés ; il ne s'agit pas nécessairement de la latence du modèle côté fournisseur. |
| Utilisation des jetons | Utilisez les catégories fournies par le service. L'absence de données relatives aux entrées, aux sorties, au cache ou aux jetons de raisonnement ne signifie pas pour autant que l'utilisation est nulle. |
| Coût | Il convient de distinguer les débits ou crédits GlobalGPT enregistrés des estimations basées sur les tarifs des API des prestataires. Les frais d'abonnement constituent un autre indicateur. |
| Création de médias | Tenez compte des paramètres de production ainsi que des crédits applicables ou des frais liés à la production. Le nombre de jetons peut ne pas être disponible ou ne pas être pertinent. |
Une estimation de prix doit s'appuyer sur une base de calcul clairement indiquée. Les crédits ne peuvent pas être convertis en dollars sans une règle de conversion vérifiée, et le fait qu'un champ de réponse ait une valeur nulle ne suffit pas à lui seul à établir qu'une demande était gratuite.
Évaluation par l'auteur pour les tâches subjectives
Les auteurs comparent également les résultats lorsque les préférences influent sur l'utilité. Dans le cas de textes ou d'images, cela peut consister à déterminer quel résultat présente un langage plus clair, une mise en page plus lisible ou une composition mieux adaptée au cahier des charges.
Notre Comparaison entre Seedream 5.0 Pro et GPT Image 2 présente des images appariées correspondant à des tâches spécifiques. Le texte et la mise en page visibles permettent aux lecteurs d'examiner ces éléments parallèlement aux préférences de l'auteur. Une préférence esthétique reste distincte d'une exigence vérifiée de manière objective.
Évaluation audio de l'IA avec Gemini 3.6 Flash
Nos évaluations audio sont entièrement réalisées par l'IA. Nous utilisons le logiciel Gemini 3.6 Flash pour analyser le signal audio réel. Il s’agit d’évaluations réalisées par l’IA, et non des résultats obtenus par un panel d’écoute humain.
L'évaluation dépend de la tâche : parole, langage, événements sonores, synchronisation ou structure musicale. Notre Test de Seed Audio 1.0 comprend des enregistrements audio générés et une analyse par IA du contenu, des événements, de la chronologie et des artefacts.
Les propriétés d'un fichier, telles que le format et la durée, sont indépendantes de l'appréciation du contenu. La présence d'une piste audio ne prouve pas que les mots ou les sons mentionnés soient corrects. Toute partition publiée doit être consultée en parallèle des critères d'évaluation et de l'enregistrement audio qu'elle décrit.
Comment interpréter les dates des tests, les paramètres et les résultats obtenus
C'est dans l'article lui-même que doivent figurer les résultats détaillés des tests. Voici quelques éléments de contexte utiles :
- La date du test, l'identifiant du modèle et l'environnement.
- La tâche, les consignes, les supports fournis et le résultat attendu.
- Paramètres disponibles, nombre de tentatives et modifications correspondantes.
- L'évaluateur, les vérifications effectuées et les raisons justifiant d'éventuelles préférences de l'auteur.
- Résultats concrets ou extraits, captures d'écran ou fichiers multimédias, ainsi que les données disponibles concernant le calendrier, l'utilisation et les coûts.
Les données varient d'un article à l'autre et d'un test ancien à l'autre. Les mesures manquantes ne peuvent pas être reconstituées en tant que faits observés. La section « Blog & Guides » d'une page de collection de modèles renvoie aux analyses pertinentes et à cette méthodologie ; les consignes complètes et les résultats figurent toujours dans les articles du blog.
Interprétation des nouvelles tentatives, des requêtes ayant échoué et des révisions
Un premier résultat, un résultat sélectionné et une nouvelle tentative transmettent des informations différentes aux lecteurs. L’historique des tentatives de l’article est important : il inclut les échecs techniques, les réponses vides, les réponses tronquées, ainsi que les modifications apportées aux consignes ou aux paramètres.
Une requête menée à bien peut tout de même renvoyer une réponse inutilisable. Une requête ayant échoué peut révéler un problème au niveau de l’itinéraire testé sans pour autant mettre en évidence une faiblesse générale du modèle. Nos articles s’appuient sur des portées de test variées ; il n’existe pas de nombre universel d’itérations ni de procédure de test à l’aveugle derrière chaque résultat.
Ce que les résultats des tâches peuvent et ne peuvent pas vous révéler
Un résultat permet de tirer une conclusion concernant la tâche testée, le modèle, la date et l'environnement. De petits ensembles de tâches et des mesures de temps individuelles ne permettent pas d'établir un classement universel des performances. Si un seul des deux modèles a été testé dans le cadre d'une comparaison, ces données ne permettent pas de désigner un vainqueur entre les deux modèles.
Les spécifications officielles, les tests de performance externes, les essais antérieurs et les résultats présentés dans l’article lui-même constituent autant d’éléments de preuve. Tout score dépend de l’échelle utilisée, de la pondération appliquée et des exclusions prises en compte. Les lecteurs doivent pouvoir établir un lien entre la conclusion tirée et les éléments de preuve, y compris les résultats partiels ou infructueux.
En quoi les mises à jour d'articles diffèrent-elles de la revalidation des modèles ?
Nous examinons généralement les articles toutes les deux à quatre semaines, comme indiqué dans notre Normes éditoriales. Une vérification du contenu ne signifie pas que tous les tests de modèle ont été réexécutés.
La mise à jour d'un prix, la correction de l'évaluation d'un résultat existant et la génération d'un nouveau résultat sont des actions distinctes. Les résultats historiques restent liés à leur contexte de test d'origine ; le simple fait qu'un article ait été mis à jour à une date plus récente ne suffit pas à en faire de nouveaux résultats de test.
