Evalml: Повторно включить настройку порога двоичной классификации по умолчанию

Я бы хотел попробовать на следующей неделе. Я исследовал несколько разных методов кэширования и протестировал некоторые вещи локально.

Мы не должны этого делать, пока у нас не будет MVP для тестирования производительности.

Теперь, когда у нас есть MVP для тестов производительности, мы должны это сделать! Это появилось как часть # 1024.

@ angela97lin спасибо! Да, безусловно.

Следующим шагом будет создание сравнения производительности до и после для некоторых из наших задач двоичной классификации.

Дополнительные соображения

• Потеря журнала (цель по умолчанию для класса бункера) и AUC при этом не должны изменяться, потому что они не зависят от пороговых значений. Но другие показатели, такие как F1, определенно должны улучшиться. Было бы неплохо взглянуть на несколько.
• Время подойдет. Вопрос в том, насколько плохой удар? Я бы ожидал увеличения не более чем на 10-20%.
• Мы могли бы поэкспериментировать с изменением размера разбиения порогового выбора. Это может улучшить точность удержания, предотвращая переоснащение / недостаточную подгонку. Увеличение размера разделения настройки порога также уменьшит размер разделения обучения, что приведет к более быстрому подгонке.

Будущая работа

• В настоящее время у нас нет никаких гарантий относительно размера данных. Однако это относится к обучающей выборке в целом, поэтому мы должны подать отдельную проблему.

В первоначальной записи в апреле я сказал

нам нужно будет кэшировать вывод прогноза, который в настоящее время вычисляется в счетах.

Я считаю, что это больше не применимо, могу проигнорировать. Этот комментарий был оставлен до того, как мы реорганизовали score . Плюс мы делаем оптимизацию порога на отдельном сплите, поэтому кешировать нечего. @freddyaboulton К вашему сведению

@dsherry @ angela97lin я собрал несколько первых разделов анализа документ здесь . Можете ли вы сообщить мне, что вы думаете (читайте только до раздела "Эксперименты" - все остальное остается заполнителем)?

@freddyaboulton Я только что оставил несколько комментариев. Мы обязательно должны посмотреть на потерю журнала, которая должна показать, что нет изменений, по крайней мере, в первом пакете. Однако я думаю, что мы также должны попытаться оптимизировать для F1 или чего-то еще, что чувствительно к порогу, чтобы мы могли увидеть эффект включения настройки.

@freddyaboulton, извините, меня

@freddyaboulton К вашему сведению, так как вы разместили документ, я переместил эту проблему в In Progress

@dsherry @ angela97lin Я закончил анализ файла "datasets_small_0.yaml".

Короче говоря, производительность действительно снизилась после настройки порога - может ли это быть из-за того, что мы не используем стратифицированное разбиение для настройки порога?

@freddyaboulton о, да, это могло быть.

Я просмотрел ваш документ и оставил комментарии. Мне нравятся новые графики и статистика. Мы должны найти способы добавить их обратно в looking_glass/analysis/ чтобы мы могли их повторно использовать. Но не настойчиво.

Некоторые варианты, которые приходят в голову совершенно неожиданно:

• Использовать стратифицированное разбиение для оптимизационного разделения порога
• Установите минимальное количество строк для оптимизационного разделения порога. Если это недостижимо, может быть предупреждено и не установлено пороговое значение, или может возникнуть ошибка
• Для небольших наборов данных используйте все обучающие данные в качестве порогового оптимизационного разделения и рискуйте переобучением.

Я думаю, нам следует сначала попробовать переключиться на стратифицированную выборку и посмотреть, что это даст.

Еще одна вещь, которую можно попробовать, - это переключить размер разделения с 80% тренировки 20% оптимизации порога на 50% тренировки 50% оптимизации порога. Я немного сомневаюсь, что это сработает, но это легко попробовать, и было бы интересно посмотреть.

Поскольку @jeremyliweishih набирает номер 1049, @freddyaboulton , возможно, вы захотите передать это ему. Я дам вам двоим понять это :)

@freddyaboulton, ты же не работаешь над этим, верно? Может @jeremyliweishih это

@jeremyliweishih @dsherry Примите, пожалуйста! Первоначальный анализ показал, что простое включение настройки не улучшает результаты. Может помочь использование другой стратегии разделения данных!

Вернемся к Dev Backlog и займемся этим после дополнительной работы по разделению данных.

@ bchen1116 и я обсудили, и мы считаем, что это необходимо для # 973