Contamination de référence : pourquoi un ensemble de tests privé ne suffit pas

Une taxonomie récente élargit la question

Une prépublication d’août 2026 organise la contamination autour des atténuations qu’elle peut vaincre, y compris l’exposition acquise lors de l’évaluation. Il signale également des limites dans la fiabilité de certaines parties de son instrument d’information. Sa contribution est un moyen de poser des questions plus pointues, et non un détecteur prouvant qu’un indice de référence n’est pas contaminé.

Preuve : Contamination de référence : une taxonomie organisée par une atténuation vaincue [1]

Tracez comment les informations d'évaluation peuvent atteindre le système

Répertoriez les endroits où le matériel de test peut apparaître : invites, documents récupérés, exemples succincts, notes de développeur, données de réglage fin, conversations partagées et outils. Un cas peut rester en dehors de la formation du modèle tout en étant incorporé à l’invite de l’application après un débogage répété. Cela change ce que signifie le succès de l'affaire.

Pour les systèmes Web, déterminez également si une question test mène directement à sa réponse publiée. Cela peut être légitime pour une tâche de récupération et invalide pour une revendication de capacité à livre fermé. Le même comportement peut être acceptable ou contaminant selon le contrat d'évaluation.

Utilisez des contrôles qui correspondent à la revendication prévue

Rubrex recommande de conserver des ensembles de développement, de régression et de décision séparés. Une défaillance connue appartient aux tests de régression même après que les ingénieurs l'ont constatée. Un ensemble retenu a un objectif différent : mesurer le transfert au-delà de ces correctifs. N'effacez pas la valeur de régression simplement parce qu'un cas n'est plus secret.

Limitez l'accès à l'ensemble de décisions, enregistrez le moment où il a été exposé et gelez les règles de notation avant d'exécuter la comparaison finale. Si les outils sont autorisés, enregistrez leurs limites d’accès. Les nouvelles questions doivent être examinées pour vérifier leur similarité avec les exemples précédents et les indices accidentels dans les identifiants ou les documents de référence.

Exemple illustratif : l’escalade mémorisée

Une équipe corrige un assistant après une escalade de support et ajoute l'interaction exacte à son invite à titre d'exemple. L'évaluation suivante réussit cette interaction. Il s’agit d’un résultat de régression utile, mais cela ne prouve pas que l’assistant traite des cas inconnus du même type.

Créez des cas distincts qui appliquent la même règle sous-jacente avec des preuves, des formulations et des conditions aux limites différentes. Conservez la remontée d'origine, étiquetez son exposition et signalez les cas de généralisation séparément. Une distinction transparente est plus utile qu’un pourcentage de réussite plus élevé.

Inclure un enregistrement d'exposition à côté du score

Un enregistrement compact doit décrire l'origine de l'ensemble de données, qui a vu les cas, comment l'application a été réglée, si les outils ont pu récupérer le matériel associé et ce qui reste inconnu. Attachez-le à l'exécution, car l'exposition peut changer entre les exécutions. Un label de référence ne décrit pas à lui seul les conditions dans lesquelles une note a été obtenue.

• Nommez la fonctionnalité ou la revendication de flux de travail que le test est censé prendre en charge.
• Enregistrez l'entraînement connu ou l'exposition au réglage, le cas échéant.
• Expliquez la récupération et les autorisations réseau pendant l'évaluation.
• Gardez l'ensemble de décisions finales séparé des commentaires de débogage de routine.

Questions courantes