Evalml: Réactiver le réglage du seuil de classification binaire par défaut

Créé le 15 avr. 2020  ·  17Commentaires  ·  Source: alteryx/evalml

Nous avons ajouté cette fonctionnalité sur la branche de fonctionnalité #346, puis l'avons supprimée dans #606 car elle recalculait predict et ralentissait l'automl.

Nous devrions le réactiver par défaut. Pour ce faire, nous devons mettre en cache la sortie de prédiction, qui est actuellement calculée dans le score. La solution à long terme est de mémoriser les prédictions avec un cache (#466), mais à court terme, nous devrions pouvoir faire quelque chose.

Cela concerne également le #579, qui suit le nettoyage du code en double entre les méthodes score classes de pipeline.

enhancement

Tous les 17 commentaires

J'aimerais essayer ça la semaine prochaine. J'ai fait des recherches sur différentes méthodes de mise en cache et j'ai testé certaines choses localement.

Nous ne devrions pas le faire avant d'avoir un MVP de test de performance

Maintenant que nous avons le MVP des tests de performances, nous devrions le faire ! Cela fait partie du #1024.

@angela97lin merci ! Oui définitivement.

L'étape suivante consiste à générer une comparaison des performances avant vs après sur certains de nos problèmes de classification binaire.

Considérations supplémentaires

  • La perte de journal (objectif par défaut pour la classe bin) et l'AUC ne devraient pas du tout être modifiés par cela, car ils sont indépendants du seuil. Mais d'autres métriques comme la F1 devraient certainement s'améliorer. Ce serait bien d'en regarder quelques-uns.
  • Le temps d'ajustement en prendra un coup. La question est, à quel point un coup est-il mauvais ? Je ne m'attendrais pas à une augmentation supérieure à 10-20%.
  • Nous pourrions expérimenter en balayant la taille de la division de sélection de seuil. Cela pourrait améliorer la précision de la rétention en empêchant le sur-ajustement/le sous-ajustement. L'augmentation de la taille de division du réglage du seuil réduirait également la taille de division de l'entraînement, ce qui conduit à un temps d'ajustement plus rapide

Travail futur

  • Nous n'avons actuellement aucune garantie pour cela concernant la taille des données. Cela s'applique cependant à l'ensemble de formation en général, nous devrions donc déposer un problème séparé.

Dans l'article original d'avril, j'ai dit

nous devrions mettre en cache la sortie de prédiction, qui est actuellement calculée dans le score.

Je crois que cela ne s'applique plus, peut ignorer. Ce commentaire a été laissé avant la refactorisation de score . De plus, nous effectuons l'optimisation du seuil sur une division distincte, il n'y a donc rien à mettre en cache. @freddyaboulton Pour info

@dsherry @angela97lin J'ai rassemblé les premières sections du document d'analyse ici . Pouvez-vous me dire ce que vous en pensez (lisez uniquement jusqu'à la section Expériences - tout le reste est toujours un espace réservé) ?

@freddyaboulton Je viens de laisser quelques commentaires. Nous devrions certainement examiner la perte de journaux, qui devrait montrer qu'il n'y a aucun changement au moins dans le premier lot. Cependant, je pense que nous devrions également essayer d'optimiser pour F1 ou quelque chose d'autre qui est sensible au seuil, afin que nous puissions voir l'effet de l'activation du réglage.

@freddyaboulton désolé, j'ai été confus par les tracés qui ont été laissés par le modèle, et je n'ai pas vu votre commentaire sur la lecture de la première partie seulement 🤦‍♂️ J'aime ce que vous avez

@freddyaboulton Pour info depuis que vous avez posté un doc, j'ai déplacé ce problème vers En cours

@dsherry @angela97lin J'ai terminé mon analyse sur le fichier "datasets_small_0.yaml".

En bref, les performances ont en fait diminué après le réglage du seuil - serait-ce parce que nous n'utilisons pas de division stratifiée pour régler le seuil ?

@freddyaboulton ooh, oui, cela pourrait être.

J'ai revu votre doc et laissé des commentaires. J'aime les nouveaux graphiques et statistiques. Nous devrions trouver des moyens de les rajouter dans looking_glass/analysis/ afin de pouvoir les réutiliser. Sans appuyer cependant.

Quelques options qui viennent à l'esprit :

  • Utiliser la division stratifiée pour la division d'optimisation de seuil
  • Appliquez un nombre minimum de lignes pour la division d'optimisation de seuil. Si cela est impossible, peut avertir et ne définir aucun seuil, ou peut générer une erreur
  • Pour les ensembles de données plus petits, utilisez l'intégralité des données d'entraînement comme division d'optimisation du seuil et risquez le surapprentissage

Je pense que nous devrions d'abord essayer de passer à l'échantillonnage stratifié et voir ce que cela fait.

Une autre chose à essayer serait de faire passer la taille de division de 80 % d'optimisation du seuil d'entraînement à 20 % à une optimisation de seuil de 50 % d'entraînement à 50 %. Je doute un peu que cela ferait bien, mais c'est facile à essayer et ce serait intéressant à voir.

Étant donné que @jeremyliweishih récupère le #1049 , @freddyaboulton, vous voudrez peut-être lui remettre cela. Je vous laisse le découvrir :)

@freddyaboulton, vous ne travaillez pas là-dessus, n'est-ce pas ? @jeremyliweishih peut-

@jeremyliweishih @dsherry S'il

Je reviens au Dev Backlog et suivra cela après plus de travail de fractionnement des données.

@bchen1116 et moi avons discuté, et nous pensons que cela est nécessaire pour #973

Cette page vous a été utile?
0 / 5 - 0 notes