Evalml: Interdire le rappel en tant qu'objectif automatique

Je pense que la précision et l'exactitude sont bonnes dans le sens où elles ne vous donneront pas un modèle trivial.

nous ne voulons pas nécessairement supprimer le rappel en tant qu'objectif, il ne devrait tout simplement pas être optimisé par rapport à lui dans la recherche automatique. par exemple, je pourrais vouloir optimiser pour f1, mais ensuite voir mon score de rappel à côté de celui-ci

@ kmax12 ouais, d'accord, nous ne voulons pas supprimer le code qui calcule le rappel, et nous voulons toujours prendre en charge le rappel informatique en tant que score sur un pipeline, mais nous voulons l'interdire en tant qu'objectif d'optimisation pris en charge dans automl.

Cela me rappelle la discussion en cours autour des méthodes de traçage/d'information de classification binaire pour le ROC et la matrice de confusion (#427, #365). Ce ne sont pas des métriques que nous pouvons optimiser dans automl, et ce ne sont pas non plus des scores à un seul chiffre, mais sous notre API, le moyen le plus simple de les définir était de les ajouter en tant qu'instances de ObjectiveBase .

Nous avons actuellement un certain nombre de choses qui peuvent être calculées à l'aide de pipelines :

1. Prédictions
2. Scores de fonction objectif pour automl
3. Métriques de notation, après automl
4. Tracé des données (exemple de classification binaire : courbe ROC, matrice de confusion)
5. Importance des fonctionnalités

Je pense qu'à ce jour, nous avons essayé d'utiliser ObjectiveBase pour représenter 2, 3 et 4. En d'autres termes, il nous manque une API claire pour définir les méthodes de notation et les méthodes de traçage, distinctes du processus automl .

Je pense que la prochaine étape ici devrait être de concevoir ces API. On dirait que j'ai déjà classé cela sous le numéro 392. Je mettrai à jour ce ticket pour être bloqué à ce sujet.

Pour la refonte de l'API des objectifs en ce moment, nous avons déplacé ROC et Confusion Matrix vers PlotMetrics la place (moins de conception a été consacrée à cela, c'était simplement le moyen le plus simple de séparer ces deux du reste des objectifs sans casser des choses). Nous avons également ajouté can_optimize_threshold comme attribut pour BinaryClassificationObjective , donc si fit() est appelé avec un objectif avec can_optimize_threshold=True alors nous optimisons pour cet objectif, sinon nous optimisons pour Précision. Des réflexions à ce sujet et comment cela pourrait-il s'aligner sur certaines des questions soulevées ici ? Serait-il difficile de savoir si un utilisateur a appelé fit sur Recall mais que nous avons plutôt optimisé pour Accuracy ?

@angela97lin oui, je pense que retirer ROC/confusion de ObjectiveBase était une étape positive ! Je pense que #392 devrait aller plus loin. Continuons la conversation sur la façon de mettre à jour l'API sur #392 à la place. De cette façon, ce problème peut simplement suivre le rappel de mise à jour une fois que nous avons pris une décision sur la façon de gérer ces éléments de manière plus générale.

De plus, je pense que l'optimisation du seuil de classification binaire est un sujet distinct, et heureusement, votre travail en cours dans #346 gère 100 % !

Résumant la discussion avec @eccabay et @jeremyliweishih plus tôt : Les options pour soutenir ceci sont :

• Supprimez entièrement les objectifs de rappel.
• Supprimez les entrées pour les objectifs de rappel dans objectives/utils.py OPTIONS et confirmez que cela interdit ces objectifs dans automl.