Evalml: Pour certains objectifs où la ligne de base était de 0, "pct mieux que la ligne de base" est nan

Reproducteur

import evalml
import pandas as pd
X = pd.read_csv('~/Downloads/fraud_500_data.csv').drop(['id', 'expiration_date'], axis=1)
y = X.pop('fraud')
automl = evalml.automl.AutoMLSearch(problem_type="binary", objective="f1")
automl.search(X, y)
# note that all percent_better_than_baseline values are nan in the rankings table
print(automl.rankings)
# can also check the scores of any pipeline other than the baseline pipeline, which should have id 0
print(automl.results['pipeline_results'][1]['percent_better_than_baseline_all_objectives'])

Le jeu de données est ici

@dsherry @rpeck Il s'agit d'un comportement attendu car le pipeline de référence obtient un score de 0 sur les objectifs avec NaN ( F1 , MCCBinary , Precision ). Il y a eu des discussions sur la définition de la division par 0 pour qu'elle soit soit infinie, soit aucune dans cette méthode, mais nous n'avons jamais décidé que celles-ci étaient meilleures que NaN, car si la ligne de base obtient le pire score possible sur n'importe quel objectif, alors en comparant "pourcentage mieux" sur ce l'objectif ne fait pas grand-chose et cela peut être transmis avec Aucun, NaN ou l'infini.

Cela étant dit, il peut y avoir d'autres raisons de choisir l'une de ces options plutôt que NaN !

@freddyaboulton Ah, c'est logique ! Je vais modifier le test pour ignorer tout objectif où la ligne de base est 0. Merci !

Merci @freddyaboulton ! @rpeck désolé de ne pas avoir compris quand vous m'en avez parlé hier.

Laissant cette question ouverte à la discussion : devrions-nous changer le comportement dans ce cas ?

@freddyaboulton donc F1, MCCBinary et Precision sont toutes des métriques où plus est meilleur et sont délimitées dans la plage [-1, 1] (corr) ou [0, 1]. Pourrions-nous modifier l'impl d'amélioration du pct pour calculer la différence absolue à partir de 0 et l'utiliser comme amélioration du pct ? Et si c'est ce que nous faisons actuellement, je ne m'attendrais pas à ce qu'une ligne de base de 0 produise une amélioration de nan pct pour ces mesures.

@dsherry Nous avons proposé de calculer la différence absolue pour les objectifs délimités par [0, 1] dans la phase de conception, mais nous avons décidé qu'avoir deux calculs différents serait déroutant. Cela étant dit, nous devrions peut-être reconsidérer cela étant donné que le pipeline de base est presque conçu pour marquer 0 sur ces objectifs lol. Il convient de noter que lorsque nous avons pris cette décision pour la première fois, nous ne calculions que le pourcentage de mieux pour l'objectif principal (qui n'est pas l'un de ces objectifs limités, à l'exception de la régression).

Même si nous calculons la différence absolue, nous pouvons envisager de modifier le comportement de division par 0 Nan/None/inf. Un cas intéressant à considérer est R2 , puisque dans la plupart des cas c'est [0, 1] mais c'est techniquement (-inf, 1). Donc, calculer la différence absolue n'est peut-être pas mathématiquement valable mais puisque c'est l'objectif par défaut pour la régression , nous devrions nous attendre à voir de nombreuses lignes de base avec un score de 0.

Donc, pour résumer, il y a deux changements indépendants que nous pouvons faire, conduisant à quatre résultats possibles :

1. Ne calculez pas la différence absolue pour les objectifs bornés dans [0, 1], la division par 0 est Nan. Comportement actuel.
2. Ne calculez pas la différence absolue pour les objectifs bornés dans [0, 1], la division par 0 est inf.
3. Calculer les différences absolues pour les objectifs bornés dans [0, 1], la division par 0 est Nan.
4. Calculer les différences absolues pour les objectifs bornés dans [0, 1], la division par 0 est inf.

Bien que je préfère renvoyer NaN lorsque nous divisons par 0, la réaction instinctive des utilisateurs lorsqu'ils voient NaN a été de supposer que quelque chose s'est cassé dans automl. Je pense que le retour de l'inf indiquerait plus clairement que rien ne s'est cassé et que le pipeline est en fait meilleur que la ligne de base.

Cela laisse les options 2 et 4.

Je pense que le fait d'avoir deux calculs différents pour "pourcentage de mieux" rendra plus difficile la communication aux utilisateurs de ce qui est réellement calculé pour chaque pipeline. Cela étant dit, nos pipelines de base sont conçus pour marquer 0 pour de nombreux objectifs (R2, F1, MCC) en particulier dans les problèmes déséquilibrés (nous prédisons simplement le mode). Cela rend la fonctionnalité "pourcentage meilleur" peu utile pour la plupart des problèmes réalistes, car tous les pipelines seront "infiniment" meilleurs que la ligne de base.

Je pense que je penche à 55% pour l'option 4 et à 45% pour l'option 2 mais j'aimerais avoir d'autres avis avant de faire ce changement !

En stand-up aujourd'hui, nous avons décidé qu'il était temps de mettre à jour le comportement "pct mieux que la ligne de base". Nous allons avec les options 2 et 4 ci-dessus :

• Utiliser la différence relative pour les objectifs sans limites (MSE, perte de log, etc.)
• Utiliser la différence absolue pour les objectifs avec des bornes [0, 1] (AUC, R2, etc.)
• Nous devrons gérer des cas extrêmes comme la corrélation de Pearson ([-1, 1])
• Renvoie inf plutôt que nan s'il y a une erreur de division par 0

@freddyaboulton est-ce que cela correspond à ce dont nous avons discuté ?

Comme. :-)

En outre : je suis d'accord avec la décision. IMO, si une métrique est [généralement, au moins] 0..1, alors passer de 0 à 0,2 _ressemble à une amélioration de 20%, même si mathématiquement ce n'est pas le cas. D'une certaine manière, cela me rappelle toutes ces formules qui prennent le log d'une quantité, mais elles ajoutent d'abord 1 pour ne pas prendre le log de 0. :slightly_smiling_face: