Comment évaluer les modèles ouverts : les benchmarks qui importent

Chaque sortie de modèle vient avec les scores de benchmark. MMLU, HumanEval, GSM8K, HellaSwag — la soupe alphabétique d’évaluation. Mais quels benchmarks prédisent vraiment la performance du monde réel ? Et lesquels sont autant gamés qu’ils sont devenus insignifiants ? Connaître la différence te sauve de déployer les modèles qui regardent bien sur le papier et échouent en production.

Les benchmarks core qui valent la peine d’être surveillés

MMLU (Massive Multitask Language Understanding) teste la connaissance large sur 57 sujets. Cela reste utile comme une jauge brute de la connaissance générale, bien que les scores au-dessus de 80% deviennent de plus en plus non fiables dû à la contamination de données. La variante MMLU-Pro ajoute des questions plus difficiles et des options à choix multiple pour réduire le gaming.

HumanEval et MBPP mesurent la capacité de génération de code. HumanEval demande aux modèles d’écrire des fonctions Python à partir de docstrings. MBPP teste des problèmes de programmation plus simples. Ceux-ci correspondent bien avec l’utilité réelle de coding, bien qu’ils testent seulement Python et des problèmes relativement directs. EvalPlus étend HumanEval avec des cas de test additionnels qui attrapent les modèles qui passent les tests originaux par chance.

GSM8K teste les problèmes de mots math grade-école. Malgré le framing simple, cela mesure effectivement le raisonnement multi-étapes. Les modèles qui scorent bien sur GSM8K tendent à gérer le raisonnement logique dans d’autres domaines aussi. MATH étend ceci aux mathématiques au niveau compétition pour les modèles poussant la frontière.

MT-Bench utilise GPT-4 comme juge pour évaluer la qualité de conversation multi-tour. C’est imparfait — le juge a ses propres biais — mais cela capture les aspects de qualité que les métriques automatisées manquent : la cohérence sur les tours, le suivi d’instructions, et le flux de dialogue naturel.

Benchmarks pour être sceptique

HellaSwag était autrefois difficile. Maintenant la plupart des modèles scorent au-dessus de 85%, comprimant le signal utile dans une bande étroite. Cela différencie toujours faible d’adéquat, mais cela te dit rien sur la différence entre bon et excellent.

ARC (AI2 Reasoning Challenge) souffre du même effet de plafond. ARC-Easy et ARC-Challenge ont été tous deux saturés par les modèles actuels. Quand les scores de benchmark se groupent entre 90-95%, les différences sont dans les marges de bruit.

TruthfulQA avait l’intention de mesurer l’honnêteté et l’exactitude factuelle. En pratique, les modèles apprennent les motifs spécifiques de réponses véridiques vs. trompeuses dans le benchmark sans devenir vraiment plus véridiques en général. Les scores TruthfulQA élevés ne prédisent pas fiablement moins d’hallucinations dans l’usage réel.

Le problème de la contamination

La plus grande menace à la validité de benchmark est la contamination de données. Quand les questions de benchmark apparaissent dans les données d’entraînement, les modèles scorent plus haut sans être plus intelligents. Cela arrive plus souvent que la communauté le reconnaît. Les benchmarks populaires se grattent dans les web crawls, qui deviennent inclus dans les sets d’entraînement.

Une contamination est accidentelle — les données de benchmark étaient sur internet, et internet est dans le set d’entraînement. Une est délibérée — les créateurs de modèles incluent les données adjacentes aux benchmarks pour gonfler les scores. De chaque façon, les scores contaminés ne prédisent pas la performance du monde réel.

La défense contre la contamination est la création continuelle de nouveaux benchmarks. Les ensembles d’évaluation privés qui n’ont jamais été publiés en ligne, les problèmes générés dynamiquement, et les plateformes d’évaluation en direct où les questions changent régulièrement. Le système d’évaluation ELO de Chatbot Arena, basé sur les préférences humaines aveugles, est actuellement la plus résistante à la contamination.

Construire ta propre évaluation

Les benchmarks publics te disent sur la capacité générale. Ils ne te disent pas si un modèle fonctionne pour ton cas d’usage spécifique. L’évaluation la plus importante est celle que tu construis toi-même.

Commence avec 50-100 exemples qui représentent ta charge de travail réelle. Les requêtes clients réelles, les vrais documents à traiter, le vrai code à examiner — quel que soit ton application gère. Grade les sorties du modèle sur les critères qui importent pour ton cas d’usage : exactitude, formatage, ton, complétude.

Utilise LLM-as-judge pour l’évaluation scalable. Aie un modèle plus fort (ou le même modèle avec une rubrique détaillée) score les sorties sur les dimensions spécifiques. Ceci n’est pas parfait, mais c’est assez fiable pour comparer les modèles et tracker la qualité au fil du temps. La clé est la consistance — le même juge, la même rubrique, le même test set sur toutes les évaluations.

A/B testing avec les vrais utilisateurs est le gold standard quand c’est faisable. Déploie deux modèles côte à côte, laisse les utilisateurs interagir avec les deux (sans connaître lequel c’est lequel), et mesure les taux de préférence et la complétude de la tâche. Ceci capture tout ce que les benchmarks manquent : l’expérience utilisateur, la qualité perçue, et l’utilité pratique.

La leçon méta

Aucun single benchmark raconte l’histoire complète. Les modèles qui scorent le plus haut sur les benchmarks publics ne sont pas toujours les meilleurs en production. Les modèles qui gagnent les classements de Chatbot Arena ne sont pas toujours les plus cost-efficaces. Les modèles qui passent ton évaluation personnalisée ne sont pas toujours les plus rapides.

L’évaluation de modèle efficace est multidimensionnelle. Qualité, vitesse, coût, sécurité, fiabilité sous charge — ceux-ci importent tous, et ils se compensent mutuellement. La meilleure stratégie d’évaluation mesure ce qui importe pour ton contexte spécifique et ignore le reste.

Pour les cadres et outils pour évaluer les modèles ouverts, visite Laeka Research.