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 , поэтому, если fit() вызывается с целью с can_optimize_threshold=True , мы оптимизируем для этой цели, в противном случае мы оптимизируем для Точность. Что вы думаете по этому поводу и как это может совпасть с некоторыми поднятыми здесь вопросами? Будет ли неясно, если пользователь назовет fit при отзыве, но вместо этого мы оптимизируем его для точности?

@ angela97lin да, я думаю, что удаление ROC / путаницы из ObjectiveBase было положительным шагом! Я думаю, что № 392 должен идти дальше. Вместо этого продолжим разговор о том, как обновить API на #392. Таким образом, эта проблема может просто отслеживать отзыв обновлений после того, как мы приняли решение о том, как обращаться с этим материалом в более общем плане.

Также я думаю, что оптимизация порога бинарной классификации — это отдельная тема, и, к счастью, ваша текущая работа в #346 справляется на 100%!

Подводя итог обсуждению с @eccabay и @jeremyliweishih ранее: варианты поддержки:

• Полностью удалите цели отзыва.
• Удалите записи для целей отзыва в objectives/utils.py OPTIONS и подтвердите, что запрещает эти цели в automl.