Evalml: No permitir recuperación como objetivo automático

Creo que la precisión y la exactitud están bien en el sentido de que no te darán un modelo trivial.

no necesariamente queremos eliminar la recuperación como objetivo, simplemente no debería optimizarse contra ella en la búsqueda automática. por ejemplo, es posible que desee optimizar para f1, pero luego veo mi puntaje de recuperación al lado

@kmax12 sí, claro, no queremos eliminar el código que calcula la recuperación, y queremos seguir admitiendo la recuperación informática como una puntuación en una canalización, pero queremos rechazarlo como un objetivo de optimización admitido en automl.

Esto me recuerda la discusión en curso sobre los métodos de información/trazado de clasificación binaria para ROC y matriz de confusión (#427, #365). Esas no son métricas para las que podemos optimizar en automl, y tampoco son puntajes de un solo número, pero bajo nuestra API, la forma más fácil de definirlos fue agregarlos como instancias de ObjectiveBase .

Actualmente tenemos una serie de cosas que se pueden calcular usando canalizaciones:

1. predicciones
2. Puntuaciones de funciones objetivas para automl
3. Métricas de puntuación, después de automl
4. Trazado de datos (ejemplo de clasificación binaria: curva ROC, matriz de confusión)
5. Importancia de las características

Creo que hasta la fecha hemos estado tratando de usar ObjectiveBase para representar 2, 3 y 4. En otras palabras, nos falta una API clara para definir métodos de puntuación y métodos de trazado, aparte del proceso automático. .

Creo que el siguiente paso aquí debería ser diseñar esas API. Parece que ya lo archivé como #392. Actualizaré este ticket para que se bloquee en eso.

Para el rediseño de la API de objetivos en este momento, hemos movido ROC y Confusion Matrix a PlotMetrics en su lugar (se usó menos diseño, esta fue la forma más fácil de separar estos dos del resto de los objetivos sin romper cosas). También agregamos can_optimize_threshold como un atributo para BinaryClassificationObjective , por lo que si se llama a fit() con un objetivo con can_optimize_threshold=True , optimizamos para ese objetivo; de lo contrario, optimizamos para Exactitud. ¿Pensamientos sobre esto y cómo esto podría alinearse con algunas de las preguntas planteadas aquí? ¿No estaría claro si un usuario llamó fit en Recall pero en su lugar optimizamos para Accuracy?

@angela97lin sí, creo que sacar ROC/confusión de ObjectiveBase fue un paso positivo. Creo que #392 debería seguir yendo más allá. Continuemos la conversación sobre cómo actualizar la API en el n.º 392. De esa manera, este problema puede rastrear la recuperación de actualizaciones una vez que hayamos tomado una decisión sobre cómo manejar este asunto de manera más general.

También creo que la optimización del umbral de clasificación binaria es un tema aparte y, afortunadamente, ¡uno que su trabajo en curso en el n.° 346 está manejando al 100 %!

Resumiendo la discusión anterior con @eccabay y @jeremyliweishih : Las opciones para apoyar esto son:

• Elimine los objetivos de recuperación por completo.
• Elimine las entradas para los objetivos de recuperación en objectives/utils.py OPTIONS y confirme que no permite esos objetivos en automl.