Evalml: Para alguns objetivos em que a linha de base era 0, "pct melhor que a linha de base" é nan

Criado em 20 nov. 2020  ·  9Comentários  ·  Fonte: alteryx/evalml

{'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.

enhancement

Comentários muito úteis

Como. :-)

Todos 9 comentários

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:

  1. Não calcule a diferença absoluta para objetivos limitados em [0, 1], a divisão por 0 é Nan. Comportamento atual.
  2. Não calcule a diferença absoluta para objetivos limitados em [0, 1], a divisão por 0 é inf.
  3. Calcular diferenças absolutas para objetivos limitados em [0, 1], divisão por 0 é Nan.
  4. Calcular diferenças absolutas para objetivos limitados em [0, 1], a divisão por 0 é inf.

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:

  • Use a diferença relativa para objetivos sem limites (MSE, perda de log, etc.)
  • Use diferença absoluta para objetivos com limites [0, 1] (AUC, R2, etc)
  • Teremos que lidar com casos extremos como correlação de Pearson ([-1, 1])
  • Retorna 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:

Esta página foi útil?
0 / 5 - 0 avaliações