Время разбирать кейсы из прошлого поста 😔
Ниже скрыты разгадки…
🙂 Кейс 1 (про ранжирование)
Самая главная проблема: задача была про ранжирование, а модель обучалась как обычный классификатор.
Хоть такой подход и имеет место быть, стоит помнить, что ROC-AUC и LogLoss оценивают качество вероятностей - но не обязательно отражают качество порядка объектов. В ранжировании важно, какие статьи окажутся выше других, а не только насколько хорошо модель предсказывает вероятность клика в среднем.
Поэтому в первую очередь необходимо попробовать ранжирующие функции потерь (например, pairwise и listwise подходы), и на валидации оценить метрики ранжирования (NDCG, MAP, Precision@k).
Идеи взять более сложный алгоритм, учитывать популярность, временные факторы и т.п. также могут дополнительно улучшить модель:)
🙂 Кейс 2 (про калибровку вероятностей)
Почему так произошло? Идейно калибровка не меняет порядок объектов, а лишь монотонно преобразует вероятности, изменяя их распределение.
ROC-AUC как раз зависит только от порядка предсказаний и не зависит от порога - поэтому он почти не изменился. А вот Recall напрямую связан с порогом - и видимо, его старое значение перестало быть оптимальным.
Чтобы это исправить, достаточно просто переподобрать порог классификатора.
🙂 Кейс 3 (прогноз возврата товара)
Проблема кроется во фразе: “Команда обучила модель на данных за последнюю неделю…” Если таргет - возврат товара, то он, как правило, происходит через некоторое время после покупки. Поэтому если обучаться только на “самых свежих” данных, то для многих заказов возврат ещё просто не успел произойти - соответственно, такие покупки помечаются как returned = 0.
В качестве решения необходимо по историческим данным рассчитать типичную задержку между событием и таргетом и на её основе выбрать подходящий диапазон данных - чтобы обучаться только на заказах, для которых уже прошло достаточно времени, чтобы возврат мог произойти.
🐳 В следующий раз разбираем NLP и CV 🐳
Хороших выходных!
#карьера@data_easy
#classic_ml@data_easy