{'F1': nan,
'MCC Binary': nan,
'Log Loss Binary': 93.29789549298991,
'AUC': 58.36492736629537,
'Precision': nan,
'Balanced Accuracy Binary': 63.46659876071641,
'Accuracy Binary': 12.876088314169193}
Eu criei um notebook Jupyter que reproduz esse problema em evalml
e o anexei e o arquivo de dados associado a um thread no Slack.
Reprodutor
import evalml
import pandas as pd
X = pd.read_csv('~/Downloads/fraud_500_data.csv').drop(['id', 'expiration_date'], axis=1)
y = X.pop('fraud')
automl = evalml.automl.AutoMLSearch(problem_type="binary", objective="f1")
automl.search(X, y)
# note that all percent_better_than_baseline values are nan in the rankings table
print(automl.rankings)
# can also check the scores of any pipeline other than the baseline pipeline, which should have id 0
print(automl.results['pipeline_results'][1]['percent_better_than_baseline_all_objectives'])
O conjunto de dados está aqui
@dsherry @rpeck Esse é o comportamento esperado porque o pipeline de linha de base obtém uma pontuação de 0 nos objetivos com NaN ( F1
, MCCBinary
, Precision
). Houve discussões sobre definir a divisão por 0 como infinito ou Nenhum neste método, mas nunca decidimos que eles são melhores que NaN porque se a linha de base obtiver a pior pontuação possível em qualquer objetivo, comparar "porcentagem melhor" nisso objetivo não faz muito bem e isso pode ser transmitido com None, NaN ou infinito.
Dito isto, pode haver outras razões para escolher uma dessas opções em vez de NaN!
@freddyaboulton Ah, faz sentido! Vou alterar o teste para pular qualquer objetivo em que a linha de base seja 0. Obrigado!
Obrigado @freddyaboulton ! @rpeck desculpe, eu não entendi isso quando você estava me perguntando sobre isso ontem.
Deixando essa questão em aberto para discussão: devemos mudar o comportamento neste caso?
@freddyaboulton , então F1, MCCBinary e Precision são todas as métricas em que maior é melhor e são limitadas no intervalo [-1, 1] (corr) ou [0, 1]. Poderíamos alterar o impl de melhoria de pct para calcular a diferença absoluta de 0 e usar isso como a melhoria de pct? E se é isso que estamos fazendo atualmente, eu não esperaria que uma linha de base de 0 produzisse uma melhoria de nan
pct para essas métricas.
@dsherry Propusemos calcular a diferença absoluta para objetivos limitados por [0, 1] na fase de projeto, mas decidimos que ter dois cálculos diferentes seria confuso. Dito isto, talvez devêssemos reconsiderar isso, dado que o pipeline de linha de base é quase projetado para pontuar 0 nesses objetivos lol. Vale a pena notar que quando tomamos essa decisão pela primeira vez, estávamos apenas computando a porcentagem melhor para o objetivo principal (que não é um desses objetivos limitados, exceto para regressão).
Mesmo se formos calcular a diferença absoluta, podemos considerar alterar o comportamento de divisão por 0 de Nan/None/inf. Um caso interessante a considerar é R2
,já que na maioria dos casos é [0, 1], mas é tecnicamente (-inf, 1]. Portanto, calcular a diferença absoluta pode não ser matematicamente correto, mas como é o objetivo padrão para regressão , devemos esperar ver muitas linhas de base com pontuação 0.
Então, para resumir, há duas mudanças independentes que podemos fazer, levando a quatro resultados possíveis:
Embora eu prefira retornar NaN quando dividimos por 0, a reação instintiva dos usuários quando veem NaN foi supor que algo quebrou no automl. Acho que retornar inf deixaria mais claro que nada quebrou e que o pipeline é de fato melhor que a linha de base.
Isso deixa as opções 2 e 4.
Acho que ter dois cálculos diferentes para "por cento melhor" tornará mais difícil comunicar aos usuários o que realmente está sendo calculado para cada pipeline. Dito isto, nossos pipelines de linha de base são projetados para pontuar 0 para muitos objetivos (R2, F1, MCC), especialmente em problemas desequilibrados (apenas prevemos o modo). Isso torna o recurso "porcentagem melhor" não muito útil para problemas mais realistas, pois todos os pipelines serão "infinitamente" melhores que a linha de base.
Acho que estou inclinando 55% para a opção 4 e 45% para a opção 2, mas gostaria de ouvir outros pontos de vista antes de fazer essa mudança!
Em standup hoje, decidimos que é hora de atualizar o comportamento "pct melhor que a linha de base". Vamos com as opções 2 e 4 acima:
inf
em vez de nan
se houver um erro de divisão por 0@freddyaboulton isso combina com o que discutimos?
Como. :-)
Mais: concordo com a decisão. IMO, se uma métrica é [geralmente, pelo menos] 0..1, então ir de 0 a 0.2 _parece_ uma melhoria de 20%, mesmo que matematicamente não seja. De certa forma, isso me lembra todas aquelas fórmulas que tiram log
de uma quantidade, mas adicionam 1 primeiro para não tirar o log
de 0. :slightly_smiling_face:
Comentários muito úteis
Como. :-)