Evalml: Reative o ajuste de limite de classificação binária por padrão

Eu gostaria de dar uma chance na próxima semana. Tenho pesquisado alguns métodos diferentes para fazer cache e testei algumas coisas localmente.

Não devemos fazer isso até que tenhamos um MVP de teste de desempenho

Agora que temos o MVP dos testes de desempenho, devemos fazer isso! Isso surgiu como parte de # 1024.

@ angela97lin obrigada! Sim definitivamente.

O próximo passo é gerar uma comparação de desempenho antes e depois em alguns de nossos problemas de classificação binária.

Considerações adicionais

• A perda de log (objetivo padrão para a classe bin) e o AUC não devem ser alterados por isso, porque eles são independentes do limite. Mas outras métricas como F1 definitivamente devem melhorar. Seria bom olhar alguns.
• O tempo de ajuste vai demorar. A questão é: quão ruim foi um golpe? Eu esperaria um aumento não superior a 10-20%.
• Poderíamos experimentar varrer o tamanho da divisão de seleção de limite. Isso poderia melhorar a precisão de resistência, evitando overfitting / underfitting. Aumentar o tamanho da divisão de ajuste de limite também diminuiria o tamanho da divisão de treinamento, o que leva a um tempo de ajuste mais rápido

Trabalho futuro

• No momento, não temos nenhuma proteção para esse tamanho de dados. Isso se aplica ao conjunto de treinamento em geral, portanto, devemos registrar um problema separado.

No artigo original de abril, eu disse

teríamos que armazenar em cache a saída da previsão, que atualmente é calculada em pontuação.

Acredito que não se aplique mais, posso ignorar. Esse comentário foi deixado de antes de refatorarmos score . Além disso, fazemos a otimização de limite em uma divisão separada, portanto, não há nada para armazenar em cache. @freddyaboulton FYI

@dsherry @ angela97lin Eu reuni as primeiras seções do documento de análise aqui . Você pode me dizer o que você pensa (leia apenas até a seção Experimentos - todo o resto ainda é um espaço reservado)?

@freddyaboulton Acabei de deixar alguns comentários. Devemos definitivamente olhar para a perda de log, que deve mostrar que não há alteração pelo menos no primeiro lote. No entanto, acho que também devemos tentar otimizar para F1 ou outra coisa que seja sensível ao limite, para que possamos ver o efeito de habilitar o ajuste.

@freddyaboulton desculpe, fiquei confuso com os enredos que sobraram do template, e não vi seu comentário sobre apenas ler a primeira parte 🤦‍♂️ Gostei do que você tem

@freddyaboulton Para

@dsherry @ angela97lin Terminei minha análise no arquivo "datasets_small_0.yaml".

Resumindo, o desempenho realmente diminuiu depois de ajustar o limite - poderia ser porque não estamos usando uma divisão estratificada para ajustar o limite?

@freddyaboulton ooh, sim, pode ser.

Eu revisei seu documento e deixei comentários. Gosto dos novos gráficos e estatísticas. Devemos encontrar maneiras de adicioná-los de volta em looking_glass/analysis/ para que possamos reutilizá-los. Não pressionando, no entanto.

Algumas opções que vêm à mente:

• Use a divisão estratificada para a divisão de otimização de limite
• Imponha um número mínimo de linhas para a divisão de otimização de limite. Se isso for inatingível, pode avisar e não definir nenhum limite ou pode causar um erro
• Para conjuntos de dados menores, use todos os dados de treinamento como a divisão de otimização de limite e corrija o sobreajuste

Acho que devemos tentar mudar para a amostragem estratificada primeiro e ver o que isso faz.

Outra coisa a tentar seria mudar o tamanho da divisão de 80% de treinamento e 20% de otimização de limite para 50% de treinamento e 50% de otimização de limite. Eu meio que duvido que isso funcione bem, mas é fácil de tentar e seria interessante de ver.

Já que @jeremyliweishih está pegando o # 1049, @freddyaboulton , você pode passar isso para ele. Vou deixar vocês dois descobrirem :)

@freddyaboulton você não está trabalhando nisso, certo? @Jeremyliweishih pode

@jeremyliweishih @dsherry Por favor, pegue! A análise inicial mostrou que simplesmente ativar o ajuste não melhora as pontuações. Usar uma estratégia de divisão de dados diferente pode ajudar!

Voltando ao Dev Backlog e continuarei com isso depois de mais trabalho de divisão de dados.

@ bchen1116 e eu discutimos, e achamos que isso é necessário para # 973