{'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のスレッドに添付しました。
リプロデューサー
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( F1
、 MCCBinary
、 Precision
)の目標でスコア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つの可能な結果につながります。
私は0で割ったときにNaNを返すことを好みますが、NaNを見たときのユーザーの直感的な反応は、automlで何かが壊れたと想定することでした。 infを返すと、何も壊れていないこと、およびパイプラインが実際にベースラインよりも優れていることが明確になると思います。
それはオプション2と4を残します。
「パーセント向上」のために2つの異なる計算を行うと、パイプラインごとに実際に計算されている内容をユーザーに伝えることが難しくなると思います。 そうは言っても、私たちのベースラインパイプラインは、特に不均衡な問題(モードを予測するだけ)で、多くの目標(R2、F1、MCC)に対して0をスコアリングするように設計されています。 これにより、すべてのパイプラインがベースラインよりも「無限に」優れているため、「パーセント向上」機能はほとんどの現実的な問題にはあまり役立ちません。
オプション4は55%、オプション2は45%傾いていると思いますが、変更を加える前に他の視点を聞きたいと思います。
今日のスタンドアップでは、「ベースラインよりも優れたpct」の動作を更新する時期を決定しました。 上記のオプション2と4を使用します。
nan
inf
返します@freddyaboultonこれは私たちが議論したものと一致しますか?
好き。 :-)
さらに:私はその決定に同意します。 IMO、メトリックが[通常は少なくとも] 0..1の場合、数学的にはそうではありませんが、0から0.2に変更すると、20%の改善のように感じられます。 ある意味で、これは数量のlog
を取るすべての数式を思い出させますが、最初に1を追加して、0のlog
を受け取らないようにします。:slightly_smiling_face:
最も参考になるコメント
好き。 :-)