Questions de test : pourquoi les données « réservées » sont importantes

Définition

Un modèle affiné a lu vos réponses d'entraînement de nombreuses fois. Posez-lui à nouveau l'une de ces questions et il pourra reproduire la réponse presque mot pour mot. Cela ressemble à de la compétence, mais c'est de la mémorisation : cela ne vous dit rien sur la façon dont le modèle gérera le prochain client, dont il n'a jamais vu la question.

L'ensemble de test est la solution, et l'une des règles les plus anciennes de l'apprentissage automatique : gardez certains exemples complètement à l'écart de l'entraînement, et n'évaluez le modèle que sur ceux-ci. Les grands modèles de langage rendent cette règle encore plus importante. Des études sur des bancs d'essai publics ont révélé à plusieurs reprises que des modèles avaient vu des éléments de test pendant l'entraînement et avaient obtenu de meilleurs scores de ce fait — un problème connu sous le nom de contamination des données ou fuite.

Fonctionnement

dataset has ≥ 10 conversations?   no  →  no test set
                                  yes →  test = 10% of conversations (at least 3)
                                         random, but fixed for this prep

each assistant reply in a test conversation  →  one question
  asked with the conversation up to that point
  reference answer = the reply itself
reply identical to a training reply          →  dropped

1. Mises de côté en premier. Avant que la validation ne soit séparée ou que quoi que ce soit ne soit écrit pour l'entraînement, la préparation des données sélectionne 10 % des conversations, au moins 3. Les jeux de données de moins de 10 conversations n'ont pas d'ensemble de test.
2. Aléatoires, mais figées par préparation. La sélection est aléatoire, elle n'est donc pas biaisée vers des conversations faciles ou difficiles, et elle reste la même pour cette préparation, de sorte qu'une nouvelle évaluation pose les mêmes questions.
3. Une question par réponse. Chaque réponse de l'assistant dans une conversation de test devient une question, posée avec l'historique de la conversation jusqu'à ce point. La réponse elle-même sert de réponse de référence.
4. Aucune copie cachée. Une réponse de test identique mot pour mot à une réponse d'entraînement — la même réponse standard dans une autre conversation — est écartée, car le modèle l'a effectivement déjà vue.
5. Ne sortent jamais. Les conversations de test ne figurent ni dans le fichier d'entraînement ni dans le fichier de validation, et elles ne sont jamais envoyées au fournisseur.

Pourquoi la validation n'est pas un test rigoureux

Les conversations de validation ne servent pas à l'apprentissage, alors pourquoi ne pas évaluer sur celles-ci ? Parce que le fournisseur reçoit le fichier de validation et l'utilise pendant l'entraînement, pour calculer la perte de validation et surveiller l'exécution. Les données ne sont plus entre vos mains, et chaque décision prise en observant ces chiffres — quelle exécution conserver, combien d'époques — ajuste un peu le résultat vers ces questions particulières. La validation est un bon second avis ; ce n'est pas un examen à l'aveugle.

D'où Evaluate tire ses questions

Evaluate prend la première source existante, dans cet ordre. Un résultat sur un échantillon d'entraînement est une limite supérieure : si le modèle affiné ne gagne pas même sur les questions qu'il a apprises, il ne gagnera pas sur de nouvelles questions ; s'il gagne, vous ne savez toujours pas dans quelle mesure.

Bonnes pratiques

• Laissez-lui de la marge. Un jeu de test de 29 questions est utile mais restreint : à cette taille, un taux de réussite de 60 % reste compatible avec une absence d'amélioration. Plus de conversations dans le jeu de données signifient plus de questions de test et un verdict plus solide.
• Excluez les conversations de test des entraînements ultérieurs. Si vous les copiez dans un autre jeu de données et vous entraînez dessus, le modèle suivant les aura vues et son évaluation sera artificiellement flatteuse.
• Comparez ce qui est comparable. Une nouvelle préparation extrait son propre jeu de test. Lorsque vous comparez des modèles, utilisez les questions de test d'une seule préparation pour tous.
• Prenez les avertissements au sérieux. Une évaluation sur un échantillon d'entraînement est signalée comme telle pour une bonne raison : considérez-la comme une vérification de cohérence, et non comme un résultat.

Sources des questions

Erreurs courantes

• Évaluer sur des questions d'entraînement et interpréter le résultat comme une performance en conditions réelles.
• Considérer les résultats de validation comme étant aussi rigoureux que les résultats de tests mis de côté.
• Copier des conversations de test dans un jeu de données d'entraînement ultérieur, de sorte que le modèle suivant les ait déjà vues.
• Considérer une poignée de questions de test comme un verdict : les petits ensembles de test nécessitent un écart important pour être significatifs.
• Comparer des modèles qui ont chacun été évalués sur l'ensemble de test d'une préparation différente.

Références et lectures complémentaires

Les sources externes s'ouvrent dans un nouvel onglet.

1. 01Training, validation, and test data sets↗Wikipedia · en.wikipedia.orgLa division en trois parties, et pourquoi le jeu de test n'est utilisé qu'à la fin.
2. 02Leakage (machine learning)↗Wikipedia · en.wikipedia.orgComment les informations des données de test s'infiltrent dans l'entraînement et gonflent les scores.
3. 03NLP Evaluation in trouble: On the Need to Measure LLM Data Contamination for each Benchmark↗Sainz et al., 2023 · arXiv · arxiv.orgPourquoi la contamination rend les résultats d'évaluation peu fiables, et pourquoi elle doit être vérifiée.
4. 04Time Travel in LLMs: Tracing Data Contamination in Large Language Models↗Golchin & Surdeanu, 2023 · arXiv · arxiv.orgDétecter lorsqu'un modèle a mémorisé des exemples de test, en lui demandant de les compléter.

Concepts associés