Evalml: ベースラインが0であった一部の目標では、「ベースラインよりも優れたpct」はnanです。

作成日 2020年11月20日  ·  9コメント  ·  ソース: 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}

この問題をevalmlで再現するJupyterノートブックを作成し、それと関連するデータファイルをSlackのスレッドに添付しました。

enhancement

最も参考になるコメント

好き。 :-)

全てのコメント9件

リプロデューサー

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'])

データセットはこちら

@dsherry @rpeckこれは、ベースラインパイプラインがNaN( F1MCCBinaryPrecision )の目標でスコア0を取得するため、予想される動作です。 この方法で0による除算を無限大またはなしに設定することについての議論がありましたが、ベースラインが任意の目的で可能な限り最悪のスコアを獲得した場合、その「パーセントがより良い」と比較するため、NaNよりも優れているとは判断していません。目的はあまり効果がなく、None、NaN、または無限大で伝達できます。

そうは言っても、NaNよりもこれらのオプションの1つを選ぶ理由は他にもあるかもしれません!

@freddyaboultonああ、理にかなっています! ベースラインが0の目的をスキップするようにテストを変更します。ありがとうございます。

ありがとう@freddyaboulton@rpeck申し訳ありませんが、昨日あなたが私にそれについて尋ねていたとき、私はこれを捕まえませんでした。

この問題を開いたままにして、議論します。この場合の動作を変更する必要がありますか?

@freddyaboultonなので、F1、MCCBinary、Precisionはすべてメトリックであり、大きい方が優れており、[-1、1](corr)または[0、1]の範囲に制限されます。 pct Improvement implを変更して、0からの絶対差を計算し、それをpct改善として使用できますか? そして、それが現在私たちが行っていることである場合、ベースライン0がこれらのメトリックのnan pctの改善をもたらすとは思わないでしょう。

@dsherry設計段階で、[0、1]で囲まれた目的の絶対差を計算することを提案しましたが、2つの異なる計算を行うと混乱する可能性があると判断しました。 そうは言っても、ベースラインパイプラインがこれらの目標で0を獲得するようにほぼ設計されていることを考えると、おそらく再考する必要があります。 注目に値するのは、最初にその決定を行ったとき、主要な目的(回帰を除いてこれらの制限された目的の1つではない)のパーセントをより適切に計算していたことだけです。

絶対差を計算する場合でも、Nan / None / infの0による除算の動作を変更することを検討することをお勧めします。 考慮すべき興味深いケースの1つは、 R2です。これは、ほとんどの場合[0、1]ですが、技術的には(-inf、1]であるためです。したがって、絶対差の計算は数学的には適切ではないかもしれませんが、回帰のデフォルトの目的であるためです。 、スコアが0のベースラインがたくさんあることを期待する必要があります。

要約すると、2つの独立した変更を行うことができ、4つの可能な結果につながります。

  1. [0、1]で囲まれた目的の絶対差を計算しないでください。0で割ると、Nanになります。 現在の動作。
  2. [0、1]で囲まれた目的の絶対差を計算しないでください。0による除算はinfです。
  3. [0、1]で囲まれた目的の絶対差を計算します。0で割ると、Nanになります。
  4. [0、1]で囲まれた目的の絶対差を計算します。0で割ると、infになります。

私は0で割ったときにNaNを返すことを好みますが、NaNを見たときのユーザーの直感的な反応は、automlで何かが壊れたと想定することでした。 infを返すと、何も壊れていないこと、およびパイプラインが実際にベースラインよりも優れていることが明確になると思います。

それはオプション2と4を残します。

「パーセント向上」のために2つの異なる計算を行うと、パイプラインごとに実際に計算されている内容をユーザーに伝えることが難しくなると思います。 そうは言っても、私たちのベースラインパイプラインは、特に不均衡な問題(モードを予測するだけ)で、多くの目標(R2、F1、MCC)に対して0をスコアリングするように設計されています。 これにより、すべてのパイプラインがベースラインよりも「無限に」優れているため、「パーセント向上」機能はほとんどの現実的な問題にはあまり役立ちません。

オプション4は55%、オプション2は45%傾いていると思いますが、変更を加える前に他の視点を聞きたいと思います。

今日のスタンドアップでは、「ベースラインよりも優れたpct」の動作を更新する時期を決定しました。 上記のオプション2と4を使用します。

  • 範囲のない目標(MSE、対数損失など)に相対差を使用する
  • [0、1]の範囲を持つ目的(AUC、R2など)には絶対差を使用します
  • ピアソン相関([-1、1])のようなエッジケースを処理する必要があります
  • ゼロ除算エラーが発生した場合は、 nan inf返します

@freddyaboultonこれは私たちが議論したものと一致しますか?

好き。 :-)

さらに:私はその決定に同意します。 IMO、メトリックが[通常は少なくとも] 0..1の場合、数学的にはそうではありませんが、0から0.2に変更すると、20%の改善のように感じられます。 ある意味で、これは数量のlogを取るすべての数式を思い出させますが、最初に1を追加して、0のlogを受け取らないようにします。:slightly_smiling_face:

このページは役に立ちましたか?
0 / 5 - 0 評価