F3. Почему высокий ROC-AUC не приносит денег

Четыре этажа метрик

В ML-продукте одновременно работают четыре слоя измерений, и свалить их в одну кучу — верный способ обмануть самого себя:

1. Offline — как модель отвечает на старых, уже известных данных, ещё до выхода в свет: ROC-AUC, precision, recall и прочие цифры «на бумаге» (что за буквы — разложим ниже)
2. Online — как та же модель ведёт себя на живом трафике: кликают ли по подсказкам, доходят ли до покупки, сколько секунд занимает ответ, какую долю рекомендаций люди принимают
3. Business — то, ради чего всё затевалось: выручка, маржа, удержание клиентов, потери от мошенников, отток
4. Guardrail (ограничители) — то, что нельзя сломать по дороге к красивой цифре: скорость ответа, стоимость запроса, поток жалоб, доля по ошибке заблокированных честных клиентов

Про ROC-AUC достаточно запомнить одно: это число от 0.5 до 1, которое показывает, умеет ли модель ставить «нужные» случаи выше «ненужных». Ближе к 1 — сортирует чётко, ближе к 0.5 — по сути гадает наугад

Почему высокий ROC-AUC ещё не деньги

ROC-AUC отвечает ровно на один вопрос — насколько аккуратно модель раскладывает правильные случаи выше неправильных. И молчит обо всём остальном:

• на каком пороге вы отрежете «подозрительных» от «нормальных» и сколько ложных тревог это принесёт
• во сколько обходится ложная тревога по сравнению с упущенным случаем
• послушают ли вообще люди эту модель в живом интерфейсе

Цифру «на бумаге» легко поднять, не сдвинув бизнес ни на рубль — если порог выбран криво, интерфейс не доносит пользу или метрику с самого начала взяли не ту

Как связать метрики: дерево

Растите дерево сверху вниз — от денег к «бумажным» цифрам:

Business: срезать потери от мошенников на 15%
  └─ Online: ловим больше фрода в потоке и реже блокируем честных
       └─ Offline: recall по фроду, PR-AUC
            └─ Guardrail: решение быстрее 200 мс, жалоб не больше прежнего

Каждая «бумажная» цифра обязана вести к поведению в проде, а поведение — к деньгам. Цепочка рвётся — значит, метрику взяли зря

Пример: антифрод

• Accuracy (доля угаданных ответов) здесь откровенно врёт: если мошенники — всего 1% операций, модель «тут всё честно» набирает 99% accuracy и не ловит ни одного жулика
• По делу смотреть надо на другое: recall по фроду (какую часть мошенников поймали), precision (какая доля тревог оказалась не пустой), бизнес-цифру потери от мошенников и ограничитель долю ошибочных блокировок — чтобы под нож не попадали честные клиенты

Частые ошибки

• Гоняются за accuracy там, где один класс кратно перевешивает другой
• Приносят руководству «бумажную» цифру и подают её как уже заработанные деньги
• Забывают про ограничители — и вытягивают главную метрику ценой скорости, счёта за инференс или волны жалоб
• Не сшивают цепочку offline → online → business

Что спросить у команды

• У дата-сайентиста — «какую offline-метрику берём и почему именно она отражает нашу бизнес-цель»
• У аналитика — «как и за какой срок мы поймём, что в проде реально что-то изменилось»
• У бизнеса — «какая guardrail-метрика не имеет права просесть вообще ни при каких обстоятельствах»

🧠 Запомни: Offline → Online → Business → Guardrail. Цифра, не связанная со следующим этажом, — сирота: пользу модели она не докажет

Коротко

Метрика модели — не финишная черта, а одно звено цепи. Зрелый продакт всегда показывает дорогу от «бумажной» цифры к деньгам и стережёт ограничители, чтобы «улучшение» не обернулось убытком