Fixer le jeu d'évaluation et les règles de comparaison avant de comparer des modèles

Contexte et recommandation

Le jeu d'évaluation doit être fixé avant toute comparaison de modèles. Cela signifie enregistrer les divisions, les sous-ensembles, les poids, les métriques et leurs directions dans un fichier ou une configuration. La bibliothèque Hugging Face Evaluate fournit des outils pour charger des métriques et les calculer de manière cohérente, tandis que le paramètre de scoring de scikit-learn définit les règles d'évaluation pour la sélection de modèles. Les deux soutiennent une évaluation reproductible lorsque les règles sont écrites. La recommandation est de créer une spécification d'évaluation qui indique exactement quels exemples sont utilisés, quelles métriques sont calculées et comment les résultats sont agrégés. Sans cela, deux exécutions ou deux auteurs peuvent produire des chiffres différents qui ne sont pas comparables. La spécification doit inclure l'ordre d'agrégation, comme une moyenne pondérée sur les sous-ensembles, et la règle selon laquelle les modèles sont comparés sur les mêmes divisions. Cela empêche les changements accidentels dans le prétraitement ou l'ordre des données de modifier la conclusion. L'objectif est de rendre l'expérience reproductible et la comparaison transparente.

La spécification d'évaluation doit être stockée dans un fichier tel que YAML ou JSON afin qu'elle puisse être versionnée et réutilisée. Le fichier doit lister les divisions, les sous-ensembles, les poids, les métriques et les règles de comparaison. Par exemple, une expérience de classification pourrait utiliser deux sous-ensembles, A et B, avec des poids de 0,6 et 0,4, et deux métriques, précision et rappel, toutes deux maximisées. La règle de comparaison stipule que les mêmes divisions sont utilisées, que chaque sous-ensemble est rapporté séparément et que l'agrégat est une moyenne pondérée. Ce fichier devient la source unique de vérité pour l'expérience. Lorsque deux modèles sont exécutés, ils lisent tous deux la même spécification, donc les résultats sont directement comparables. Le rapport doit inclure les scores par sous-ensemble et l'agrégat, et non seulement l'agrégat. Ainsi, un modèle qui gagne en moyenne peut être vu perdre sur un sous-ensemble critique. La spécification enregistre également les directions des métriques, telles que la précision et le rappel à maximiser, afin que l'agrégation ait du sens.

La bibliothèque Hugging Face Evaluate et l'API de scoring de scikit-learn sont des outils pratiques pour ce flux de travail. Evaluate permet de charger des métriques et de les calculer sur des jeux de données de manière cohérente. Le paramètre de scoring de scikit-learn définit les règles d'évaluation des modèles pour la validation croisée et la recherche de paramètres. Les deux bibliothèques soutiennent l'idée que l'évaluation est un ensemble de règles, et pas seulement un nombre unique. L'essentiel est d'enregistrer les règles dans un fichier ou une configuration afin que les mêmes entrées produisent toujours les mêmes sorties. C'est particulièrement important lorsque plusieurs auteurs ou plusieurs exécutions sont impliqués. La spécification doit être partagée avec l'équipe et utilisée comme base pour le rapport final. Le rapport doit montrer les chiffres bruts par sous-ensemble, l'agrégat et les règles de comparaison. Cela rend l'expérience auditable et les conclusions défendables.

L'exemple dans la tâche montre deux classificateurs avec une précision de 0,91 contre 0,89, mais sur le sous-ensemble B, le rappel chute de 0,78 à 0,62. Si seul l'agrégat est rapporté, la perte est invisible. Avec la spécification fixée, le rapport montre à la fois l'agrégat et la ventilation par sous-ensemble, rendant la comparaison transparente et défendable. Le même principe s'applique à tout domaine où plusieurs sous-ensembles ou métriques sont utilisés. Le jeu d'évaluation doit être fixé, les règles doivent être enregistrées et le rapport doit montrer la ventilation. Cela empêche l'erreur courante de choisir un modèle basé sur un nombre unique qui cache des échecs importants. La spécification doit être créée avant le début de l'expérience, et non après que les résultats sont connus. Cela garantit que la comparaison est équitable et que les conclusions sont basées sur des règles pré-enregistrées.

eval_spec:
  splits: [train, validation, test]
  subsets:
    A: {weight: 0.6}
    B: {weight: 0.4}
  metrics:
    accuracy:
      direction: maximize
    recall:
      direction: maximize
  comparison:
    same_splits: true
    report_per_subset: true
    aggregate: weighted_average

Justification et compromis

Une seule métrique finale simplifie le classement mais masque la distribution des erreurs entre les sous-groupes, les horizons et les types d'erreurs.

Le compromis est clair : enregistrer les règles nécessite un effort supplémentaire au départ, mais un agrégat unique peut inverser le classement lorsqu'un sous-ensemble critique est considéré. Écrire un fichier de spécification prend quelques minutes ; découvrir après le déploiement qu'un modèle échoue sur un sous-groupe minoritaire prend des semaines. L'asymétrie des coûts favorise la spécification.

Dans l'exemple, le modèle X a une précision de 0,91 et le modèle Y a une précision de 0,89. Sur le sous-ensemble B, le rappel chute de 0,78 pour le modèle Y à 0,62 pour le modèle X. Si l'agrégat est une moyenne pondérée de la précision sur les sous-ensembles A et B avec des poids de 0,6 et 0,4, le modèle X obtient un score global de 0,91 tandis que le modèle Y obtient 0,89. La différence d'agrégat n'est que de 0,02, mais l'écart de rappel sur le sous-ensemble B est de 0,16, une inversion que le nombre unique dissimule.

La spécification fixe force le rapport à mettre en évidence à la fois l'agrégat et la ventilation par sous-ensemble. Sans la spécification, un analyste pourrait choisir le modèle X basé sur l'agrégat plus élevé et manquer l'échec de rappel sur le sous-ensemble B. Avec la spécification, la comparaison est transparente et l'échec est visible avant le déploiement.

# Evaluation spec used for model comparison
spec = {
    "splits": ["train", "validation", "test"],
    "subsets": {"A": 0.6, "B": 0.4},
    "metrics": {"accuracy": "maximize", "recall": "maximize"},
    "aggregate": "weighted_average"
}

# Example: compare two models on the same splits with per-subset reporting
# Model X: accuracy 0.91, recall on subset B 0.62
# Model Y: accuracy 0.89, recall on subset B 0.78
# The aggregate alone hides the subset B failure for Model X

# The same spec is used for both models so the comparison is fair
# Report per-subset scores and the weighted aggregate
# This prevents a high aggregate from hiding a low score on a critical subset

Illustration concrète

Considérez deux classificateurs évalués sur un jeu de données divisé en sous-ensemble A (60 pour cent des exemples) et sous-ensemble B (40 pour cent des exemples). Le modèle X atteint une précision de 0,91 sur A et 0,90 sur B. Le modèle Y atteint une précision de 0,88 sur A et 0,90 sur B. La précision agrégée pondérée est de 0,6 fois 0,91 plus 0,4 fois 0,90 égale 0,906 pour le modèle X, et de 0,6 fois 0,88 plus 0,4 fois 0,90 égale 0,888 pour le modèle Y. Le modèle X gagne par 0,018 sur l'agrégat.

Examinez maintenant le rappel spécifiquement sur le sous-ensemble B. Le modèle X a un rappel de 0,62 sur B tandis que le modèle Y a un rappel de 0,78 sur B. L'écart est de 0,16, bien supérieur à la différence de précision agrégée de 0,018. Si le sous-ensemble B représente un groupe minoritaire critique où les positifs manqués ont un coût élevé, l'avantage apparent du modèle X est illusoire.

La spécification fixe indique que le rappel sur le sous-ensemble B doit être rapporté séparément et que la règle de comparaison exige une visibilité par sous-ensemble. Lorsque le rapport est généré à partir de la spécification, l'agrégat et le rappel par sous-ensemble apparaissent côte à côte. Le lecteur voit que le modèle X gagne sur la précision agrégée mais perd considérablement sur le rappel du sous-ensemble B, et peut prendre une décision éclairée plutôt que de faire confiance à un nombre unique.

Cet exemple résolu montre pourquoi la spécification compte opérationnellement. Sans elle, l'analyste calcule un nombre de précision unique, voit 0,91 contre 0,89, et sélectionne le modèle X. Avec elle, le même analyste est tenu de montrer la ventilation, et l'échec de rappel sur le sous-ensemble B devient impossible à négliger.

eval_spec:
  splits: [train, validation, test]
  subsets:
    A: {weight: 0.6}
    B: {weight: 0.4}
  metrics:
    accuracy:
      direction: maximize
    recall:
      direction: maximize
  comparison:
    same_splits: true
    report_per_subset: true
    aggregate: weighted_average

# Model X: accuracy 0.91, recall on subset B 0.62
# Model Y: accuracy 0.89, recall on subset B 0.78
# Aggregate alone hides the subset B failure for Model X
# The report must show per-subset scores and the weighted aggregate

Limites d'applicabilité

Cette approche ne remplace pas un jeu de test final séparé lorsque les hyperparamètres sont ajustés. Elle ne fournit pas par elle-même la signification statistique ; un test formel est nécessaire pour les différences petites ou bruitées. Les résultats restent comparables uniquement si le jeu d'évaluation et les règles restent inchangés, car changer les divisions ou les poids nécessite une nouvelle comparaison. Elle n'élimine pas non plus la nécessité de choisir la stratégie de validation, telle que la validation croisée ou les divisions chronologiques, basée sur le type de données. La méthode suppose que plusieurs sous-ensembles ou métriques existent et que la décision est basée sur la comparaison de modèles. Elle ne peut garantir qu'un agrégat pondéré est le bon objectif commercial, et elle n'aligne pas les espaces d'embedding ni n'établit la vérité terrain de pertinence sans encodeurs appariés et étiquettes de référence indépendantes.

L'approche est la plus utile lorsque le jeu d'évaluation contient des sous-groupes distincts avec des coûts opérationnels différents, lorsque plusieurs auteurs ou équipes doivent reproduire les résultats, et lorsque le seuil de décision est suffisamment proche pour qu'un nombre unique puisse inverser le classement.

eval_spec:
  splits: [train, validation, test]
  subsets:
    A: {weight: 0.6}
    B: {weight: 0.4}
  metrics:
    accuracy:
      direction: maximize
    recall:
      direction: maximize
  comparison:
    same_splits: true
    report_per_subset: true
    aggregate: weighted_average