Evalml: 不允许召回作为自动目标

我认为精度和准确性很好，因为它们不会给你一个微不足道的模型。

我们不一定要删除召回作为目标，它只是不应该在 automl 搜索中针对它进行优化。 例如，我可能想针对 f1 进行优化，然后在旁边查看我的召回分数

@kmax12是的，对，我们不想删除计​​算召回的代码，我们仍然希望支持计算召回作为管道上的分数，但我们确实希望禁止它作为 automl 中支持的优化目标。

这让我想起了关于 ROC 和混淆矩阵的二元分类绘图/信息方法的持续讨论（#427、#365）。 这些不是我们可以在 automl 中优化的指标，它们也不是单数分数，但在我们的 API 下，定义它们的最简单方法是将它们添加为ObjectiveBase的实例。

我们目前有许多可以使用管道计算的东西：

1. 预测
2. automl 的目标函数分数
3. 评分指标，在 automl 之后
4. 绘制数据（二元分类示例：ROC 曲线、混淆矩阵）
5. 特征重要性

我认为迄今为止我们一直在尝试使用ObjectiveBase来表示 2、3 和 4。换句话说，我们缺少一个明确的 API 来定义评分方法和绘图方法，与 automl 过程分开.

我认为下一步应该是设计这些 API。 看起来我已经将其归档为＃392。 我会更新这张票以阻止它。

对于现在的目标 API 返工，我们已将 ROC 和混淆矩阵移至PlotMetrics （减少了设计，这是将这两者与其他目标分开的最简单方法，无需破坏东西）。 我们还添加了can_optimize_threshold作为BinaryClassificationObjective的属性，因此如果使用can_optimize_threshold=True的目标调用 fit() 则我们针对该目标进行优化，否则我们针对准确性。 对此的想法以及这如何与这里提出的一些问题保持一致？ 如果用户在 Recall 上调用fit而是我们针对准确性进行了优化，是否会不清楚？

@angela97lin是的，我认为将 ROC/confusion 从ObjectiveBase中移除是积极的一步！ 我认为#392 应该更进一步。 让我们继续讨论如何在 #392 上更新 API。 这样，一旦我们决定如何更普遍地处理这些东西，这个问题就可以跟踪更新召回。

此外，我认为二元分类阈值优化是一个单独的主题，值得庆幸的是，您在 #346 中正在进行的工作正在处理 100%！

总结之前与@eccabay和@jeremyliweishih的讨论：支持这一点的选项是：

• 完全删除召回目标。
• 删除objectives/utils.py OPTIONS中召回目标的条目，并确认在 automl 中不允许这些目标。