Метрики на валидации красивые а в проде модель сыпется, почему

[Marina_DevOps]

Классическая боль: roc-auc 0.94 на валидации, выкатили скоринг в прод, через две недели бизнес орёт что точность на глаз процентов 60. Антифрод-задача, градиентный бустинг (catboost), сплит по времени делал, лик вроде искал. Где обычно прячется засада между офлайн-метрикой и реальностью? Уже неделю не сплю.

[geek_semyon]

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

[tommee]

лик вроде искал

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

[coder_vlad]

+1 к лагу разметки. сам обжигался

[corvet]

data drift банально. covid, санкции, новый эквайринг подключили, поведение юзеров поехало. модель учили на одном распределении, прод другое. поставь мониторинг psi по топ фичам, увидишь где разъехалось.

[burg0809]

роняешь модель на 60% и неделю не спишь, а в логи прода смотрел? может там фичи половина в null прилетает потому что фиче-сервис не успевает и ты на дефолтах скоришь. это чаще причина чем хитрый лик.

[Krs1958]

@автор давай по порядку, я такие разборы делал не раз. первое и главное, разведи две вещи: упала метрика модели или упала метрика которую видит бизнес. это разные вещи. бизнес часто меряет precision на пороге который ты не оптимизировал, плюс смотрит на абсолют а не на ранжирование. твой auc 0.94 это про ранжирование, а в проде кто-то выставил порог 0.5 и режет по нему, хотя оптимальный порог по твоей выборке скажем 0.83. уже отсюда вылезает половина расхождения. второе, обязательно собери prod-vs-train сравнение распределений по каждой фиче, не на глаз а ks-тестом или psi, psi выше 0.25 по фиче это красный флаг. третье, проверь train serving skew, то есть одинаково ли ты считаешь фичи в обучении и в инференсе. очень частая дичь: в трейне фича посчитана в pandas по всему датафрейму, а в проде на лету по одной транзакции, и где-то разная обработка пропусков, разный таймзон, разное округление. собери сотню реальных prod-запросов, прогони их же через train-пайплайн и сравни фичи поштучно, расхождения вылезут моментально. и да, лаг разметки про который выше писали реальная штука, свежий прод просто ещё не дозрел чтобы по нему честно мерять. дай проду 45 дней отлежаться и померь на дозревших метках, тогда поймёшь настоящую деградацию.

[valru]

в трейне фича посчитана в pandas по всему датафрейму, а в проде на лету по одной транзакции

вот это топ-1 причина по моему опыту, train serving skew у всех кто не вынес расчёт фич в единый сервис. мы пока не сделали общую либу для фич, ловили это каждый релиз.