Evalml: Não permitir o recall como um objetivo de automl

Acho que precisão e exatidão são boas no sentido de que não lhe darão um modelo trivial.

não queremos necessariamente excluir o recall como objetivo, ele apenas não deve otimizar em relação a ele na pesquisa automática. por exemplo, talvez eu queira otimizar para f1, mas veja minha pontuação de recall ao lado dela

@kmax12 sim, certo, não queremos excluir o código que calcula o recall e ainda queremos dar suporte ao recall de computação como uma pontuação em um pipeline, mas queremos desativá-lo como um objetivo de otimização compatível em automl.

Isso me lembra da discussão em andamento em torno dos métodos de plotagem/informação de classificação binária para ROC e matriz de confusão (#427, #365). Essas não são métricas para as quais podemos otimizar no automl e também não são pontuações de número único, mas em nossa API, a maneira mais fácil de defini-las era adicioná-las como instâncias de ObjectiveBase .

Atualmente, temos várias coisas que podem ser calculadas usando pipelines:

1. Previsões
2. Pontuações de função objetiva para automl
3. Métricas de pontuação, após automl
4. Dados de plotagem (exemplo para classificação binária: curva ROC, matriz de confusão)
5. Importâncias do recurso

Acho que até agora estamos tentando usar ObjectiveBase para representar 2, 3 e 4. Em outras palavras, estamos perdendo uma API clara para definir métodos de pontuação e métodos de plotagem, separados do processo automl .

Acho que o próximo passo aqui deve ser projetar essas APIs. Parece que já arquivei isso como #392. Vou atualizar este ticket para ser bloqueado por isso.

Para o retrabalho da API de objetivos agora, movemos o ROC e a Matriz de Confusão para PlotMetrics (menos design foi para isso, essa foi a maneira mais fácil de separar esses dois do resto dos objetivos sem quebrar coisas). Também adicionamos can_optimize_threshold como um atributo para BinaryClassificationObjective , portanto, se fit() for chamado com um objetivo com can_optimize_threshold=True , otimizamos para esse objetivo, caso contrário, otimizamos para Precisão. Pensamentos sobre isso e como isso pode se alinhar com algumas das questões levantadas aqui? Não ficaria claro se um usuário chamasse fit no Recall, mas, em vez disso, otimizamos para Precisão?

@angela97lin sim, acho que tirar ROC/confusion de ObjectiveBase foi um passo positivo! Eu acho que o #392 deve seguir indo mais longe. Vamos continuar a conversa sobre como atualizar a API no nº 392. Dessa forma, esse problema pode rastrear o recall de atualização assim que tomarmos uma decisão sobre como lidar com essas coisas de maneira mais geral.

Também acho que a otimização do limite de classificação binária é um assunto separado e, felizmente, um que seu trabalho em andamento no #346 está lidando com 100%!

Resumindo a discussão com @eccabay e @jeremyliweishih anteriormente: As opções para apoiar isso são:

• Exclua completamente os objetivos de recall.
• Exclua as entradas para os objetivos de recall em objectives/utils.py OPTIONS e confirme que não permite esses objetivos em automl.