Evalml: Vuelva a habilitar el ajuste del umbral de clasificación binaria de forma predeterminada

Me gustaría intentarlo la semana que viene. He estado investigando un par de métodos diferentes para hacer el almacenamiento en caché y he probado algunas cosas localmente.

No deberíamos hacer esto hasta que tengamos un MVP de prueba de rendimiento

Ahora que tenemos el MVP de las pruebas de rendimiento, ¡deberíamos hacer esto! Esto surgió como parte del # 1024.

@ angela97lin ¡ gracias! Sí definitivamente.

El siguiente paso es generar una comparación de rendimiento antes y después de algunos de nuestros problemas de clasificación binaria.

consideraciones adicionales

• La pérdida de registro (objetivo predeterminado para la clase bin) y el AUC no deben cambiarse en absoluto por esto, porque son independientes del umbral. Pero otras métricas como la F1 definitivamente deberían mejorar. Sería bueno ver algunos.
• El tiempo de ajuste se verá afectado. La pregunta es, ¿qué tan malo es el éxito? No esperaría un aumento superior al 10-20%.
• Podríamos experimentar barriendo el tamaño de la división de selección de umbral. Esto podría mejorar la precisión de retención al evitar el sobreajuste / desajuste. Aumentar el tamaño de división de ajuste de umbral también disminuiría el tamaño de división de entrenamiento, lo que conduce a un tiempo de ajuste más rápido

Trabajo futuro

• Actualmente no tenemos ninguna protección para esto en torno al tamaño de los datos. Sin embargo, esto se aplica al conjunto de entrenamiento en general, por lo que deberíamos presentar un problema por separado.

En el artículo original de abril, dije

tendríamos que almacenar en caché la salida de la predicción, que actualmente se calcula en puntuación.

Creo que eso ya no se aplica, puedo ignorarlo. Ese comentario quedó de antes de que refactorizáramos score . Además, realizamos la optimización del umbral en una división separada, por lo que no hay nada que almacenar en caché. @freddyaboulton FYI

@dsherry @ angela97lin Reuní las primeras secciones del documento de análisis aquí . ¿Puedes hacerme saber lo que piensas (solo lee hasta la sección Experimentos; todo lo demás sigue siendo un marcador de posición)?

@freddyaboulton Acabo de dejar algunos comentarios. Definitivamente deberíamos mirar la pérdida de registro, que debería mostrar que no hay cambios al menos en el primer lote. Sin embargo, creo que también deberíamos intentar optimizar para F1 o algo más que sea sensible al umbral, para que podamos ver el efecto de habilitar el ajuste.

@freddyaboulton lo siento, me confundieron las parcelas que quedaron de la plantilla y no vi tu comentario sobre solo leer la primera parte 🤦‍♂️ Me gusta lo que tienes

@freddyaboulton FYI desde que publicó un documento, moví este problema a En progreso

@dsherry @ angela97lin Terminé mi análisis en el archivo "datasets_small_0.yaml".

En resumen, el rendimiento en realidad disminuyó después de ajustar el umbral, ¿podría deberse a que no estamos usando una división estratificada para ajustar el umbral?

@freddyaboulton ooh, sí, podría ser.

Revisé tu documento y dejé comentarios. Me gustan los nuevos gráficos y estadísticas. Deberíamos encontrar formas de volver a agregarlos a looking_glass/analysis/ para poder reutilizarlos. Sin embargo, no presionando.

Algunas opciones que vienen a la mente desde arriba:

• Utilice la división estratificada para la división de optimización de umbral
• Aplique un número mínimo de filas para la división de optimización de umbral. Si esto es inalcanzable, podría advertir y no establecer ningún umbral, o podría producir un error
• Para conjuntos de datos más pequeños, use todos los datos de entrenamiento como la división de optimización del umbral y corra el riesgo de sobreajuste

Creo que primero deberíamos intentar cambiar al muestreo estratificado y ver qué hace.

Otra cosa que se puede probar sería cambiar el tamaño de la división de 80% de entrenamiento con 20% de optimización de umbral a 50% de entrenamiento con 50% de optimización de umbral. Dudo un poco que esto funcione bien, pero es fácil de probar y sería interesante de ver.

Dado que @jeremyliweishih está recogiendo el número 1049, @freddyaboulton es posible que desee entregarle esto. Dejaré que ustedes dos lo averigüen :)

@freddyaboulton, no estás trabajando en esto, ¿verdad? ¿ Puede tomarlo

@jeremyliweishih @dsherry ¡ Por favor,

Volviendo a Dev Backlog y seguiremos adelante con esto después de más trabajo de división de datos.

@ bchen1116 y yo discutimos, y creemos que esto es necesario para # 973