La contamination des benchmarks désigne une situation où les questions ou les réponses utilisées pour une évaluation se sont déjà retrouvées dans les données d'entraînement avant l'entraînement du modèle. Le modèle ne résout pas les problèmes sur le moment : il répond de mémoire. Son score paraît élevé, mais cela ne prouve pas qu'il maîtrise vraiment la compétence.
Comment la contamination se produit
La voie la plus fréquente est directe : un benchmark public est collecté dans les corpus d'entraînement. Une fois les questions publiées, des robots peuvent les récupérer sur des pages web, des articles, des dépôts de code et des forums de questions-réponses, et elles finissent dans le modèle avec d'énormes quantités d'autres textes. La deuxième voie est une fuite indirecte : les questions sont reformulées, traduites ou découpées en messages de discussion, les réponses se cachant dans des explications, de sorte que le modèle mémorise la même question sous une autre forme. La troisième voie apparaît pendant l'évaluation elle-même : le même ensemble de questions est utilisé encore et encore pour régler les paramètres et choisir les modèles, et le score est lentement ajusté vers le haut jusqu'à ce que le benchmark cesse de jouer son rôle d'arbitre.
Un score gonflé ne signifie pas que la capacité est fausse
La contamination des benchmarks est facilement interprétée à tort comme de la triche du modèle. Dans la plupart des cas, c'est un problème de pipeline de données, et non un modèle qui apprend délibérément les réponses par cœur. Le vrai problème est que le sens du score change : il ne mesure plus la généralisation, mais la part du test que le modèle a mémorisée. Un modèle qui obtient un très bon score sur un ensemble de questions de mathématiques peut chuter nettement sur un ensemble similaire nouvellement publié qu'il n'a jamais vu. Inversement, un score modeste ne signifie pas que le modèle est inutile ; certains modèles performants n'ont simplement jamais rencontré le style de questions de ce benchmark.
Quatre questions à poser avant de faire confiance à un score
Premièrement, quelle est la nouveauté des questions : le benchmark a-t-il été publié récemment et a-t-il été dédupliqué par rapport aux données d'entraînement ? Deuxièmement, l'évaluation est-elle transparente : la méthode de déduplication est-elle expliquée et les contrôles de contamination sont-ils publiés ? Troisièmement, existe-t-il plus d'une source de preuve : la même capacité se maintient-elle sur des benchmarks de sources différentes et sous des formats différents ? Quatrièmement, regardez les tâches réelles : essayez le modèle sur un petit morceau d'un flux de travail réel et observez son comportement sur des données qu'il n'a jamais vues. Cela en dit plus qu'un simple classement.
Deux malentendus fréquents
Un malentendu consiste à assimiler l'optimisation pour un benchmark à la contamination. Optimiser le format d'un benchmark ou choisir le meilleur prompt est une préparation légitime ; seules des données d'entraînement contenant le test lui-même constituent une contamination. Le second malentendu est de croire que cela ne concerne que les modèles ouverts. Les modèles fermés sont confrontés au même problème avec les questions de benchmark présentes dans les corpus publics ; la seule différence est qu'il est plus difficile pour des tiers de vérifier leurs données d'entraînement. Quand vous lisez l'annonce d'un modèle, lisez toujours le score avec la méthode d'évaluation. Un seul chiffre, à lui seul, ne dit pas grand-chose.
