Evalml: automlの目的としてのリコールを禁止する

簡単なモデルが得られないという意味で、精度と精度は問題ないと思います。

必ずしも目的としてリコールを削除する必要はありません。automl検索でリコールに対して最適化する必要はありません。 たとえば、f1を最適化したいのですが、その横にリコールスコアが表示されます。

@ kmax12ええ、そうです、リコールを計算するコードを削除したくありません。パイプラインのスコアとしてリコールの計算をサポートしたいのですが、automlでサポートされている最適化の目的としてそれを禁止したいと思います。

これは、ROCと混同行列（＃427、＃365）の二項分類プロット/情報メソッドに関する進行中の議論を思い出させます。 これらはautomlで最適化できるメトリックではなく、単一の数値スコアでもありませんが、APIでは、これらを定義する最も簡単な方法は、 ObjectiveBaseのインスタンスとして追加することでした。

現在、パイプラインを使用して計算できるものがいくつかあります。

1. 予測
2. automlの目的関数スコア
3. automl後のスコアリングメトリック
4. データのプロット（二項分類の例：ROC曲線、混同行列）
5. 機能の重要性

これまで、2、3、および4を表すためにObjectiveBaseを使用しようとしてきたと思います。つまり、automlプロセスとは別に、スコアリングメソッドとプロットメソッドを定義するための明確なAPIがありません。 。

ここでの次のステップは、これらのAPIを設計することだと思います。 すでに＃392として提出したようです。 このチケットを更新して、その上でブロックします。

目標APIの現在のリワークでは、代わりにROCと混同行列をPlotMetricsに移動しました（これには設計が少なく、これは、これら2つを残りの目標から分離する最も簡単な方法でした。物事を壊す）。 BinaryClassificationObjectiveの属性としてcan_optimize_thresholdも追加したので、fit（）がcan_optimize_threshold=Trueの目的で呼び出された場合は、その目的に合わせて最適化します。それ以外の場合は、正確さ。 これについての考えと、これがここで提起された質問のいくつかとどのように一致する可能性がありますか？ ユーザーがリコールでfitを呼び出したのかどうかは不明ですが、代わりに精度を最適化しましたか？

@ angela97linはい、ROC /混乱をObjectiveBaseから移動することは前向きな一歩だったと思います！ ＃392はさらに進んでいくべきだと思います。 代わりに、＃392でAPIを更新する方法についての会話を続けましょう。 そうすれば、この問題は、このようなものをより一般的に処理する方法について決定した後、更新のリコールを追跡することができます。

また、二項分類のしきい値の最適化は別のテーマだと思います。ありがたいことに、＃346で進行中の作業が100％処理されています。

以前の@eccabayおよび@jeremyliweishihとの議論の要約：これをサポートするためのオプションは次のとおりです。

• リコール目標を完全に削除します。
• objectives/utils.py OPTIONSのリコール目標のエントリを削除し、automlでそれらの目標が許可されていないことを確認します。