F3. Почему высокий ROC-AUC не приносит денег
Четыре этажа измерений в ML-продукте и способ связать их в одну цепочку, чтобы улучшение метрики модели превращалось в результат для бизнеса, а не оставалось красивым числом.
- ✓Понимать разницу между offline, online, business и guardrail метриками
- ✓Видеть, почему ROC-AUC сам по себе не равен выручке
- ✓Строить связь «метрика модели → бизнес-эффект»
Четыре этажа измерений
В ML-продукте одновременно работают четыре слоя метрик, и главный источник самообмана — свалить их в одну кучу, а потом рассуждать про «качество модели» вообще
Offline-метрики отвечают на вопрос, как модель справляется с историческими данными, которых она не видела при обучении. Это лабораторный замер: он делается до выхода к людям, стоит дёшево, повторяется сколько угодно раз. К этому этажу относятся ROC-AUC, precision, recall и прочие числа, которые команда приносит в первую очередь
Online-метрики показывают, что происходит с моделью на живом трафике. Пользуются ли люди её подсказками, доходят ли до покупки, за сколько миллисекунд приходит ответ, какую долю рекомендаций принимают. Здесь впервые появляется поведение живого человека, а оно способно обнулить любую лабораторную победу
Бизнес-метрики — то, ради чего всё затевалось: выручка, маржа, удержание, потери от мошенничества, стоимость обслуживания обращения, отток
Guardrail-метрики, или ограничители, — то, что запрещено ломать по дороге к красивой цифре. Скорость ответа, стоимость одного запроса, поток жалоб, доля честных клиентов, заблокированных по ошибке. Их особенность в том, что улучшать их не нужно, а вот просесть им нельзя, и именно за ними следят при выкате
Логика такая: offline-метрики нужны, чтобы отбирать гипотезы; online — чтобы принимать решение о запуске; бизнес-метрики — чтобы понимать, зачем всё это; ограничители — чтобы улучшение одного не обернулось поломкой другого
Что вообще показывает ROC-AUC
Раз это самое частое число в разговорах о моделях, стоит понять его смысл без формул. Модель, решающая «мошенник или нет», выдаёт не ответ, а оценку — насколько операция похожа на мошенническую. ROC-AUC измеряет, насколько аккуратно модель упорядочивает случаи: если взять случайную мошенническую операцию и случайную честную, какова вероятность, что мошенническая получит оценку выше
Отсюда и шкала. Значение 0.5 означает, что модель раскладывает случаи не лучше монетки. Значение 1.0 — что все мошеннические операции получили оценку выше любой честной. Реальные модели живут между этими полюсами, и в разных областях «хорошо» выглядит по-разному: 0.7 для предсказания оттока — приличный результат, 0.7 для медицинской диагностики — повод не выпускать модель к людям
Почему это число не превращается в деньги само
ROC-AUC отвечает ровно на один вопрос — про упорядочивание. И молчит обо всём, от чего зависит результат в продукте
Он ничего не говорит о пороге. Оценку модели нужно превратить в действие: заблокировать операцию или пропустить, позвонить клиенту или нет. Граница, по которой это решается, называется порогом, и именно она определяет, сколько будет ложных тревог. Одна и та же модель с одним и тем же ROC-AUC при разных порогах даёт совершенно разный продукт
Он ничего не говорит о цене разных ошибок. Пропустить мошенника и заблокировать честного клиента — это два разных убытка, часто различающиеся в десятки раз. Метрика, которая складывает их в одно число, скрывает от вас самое важное решение
И он ничего не говорит о том, послушают ли модель люди. Подсказка, которую оператор игнорирует, потому что она приходит слишком поздно или занимает полэкрана, имеет нулевой эффект при любой лабораторной точности
Отсюда неприятный вывод, полезный для трезвости: лабораторную метрику вполне можно поднять, не сдвинув бизнес ни на рубль. Если порог выбран неудачно, интерфейс не доносит пользу или метрику с самого начала взяли не ту
Дерево метрик: как связать этажи
Лечится это одной дисциплиной — деревом метрик. Оно растится сверху вниз, от денег к лабораторным числам, и каждый уровень объясняет, почему существует следующий
Business: снизить потери от мошенничества на 15%
└─ Online: доля пойманного фрода в потоке растёт,
доля ошибочных блокировок не растёт
└─ Offline: recall по фроду при фиксированном precision, PR-AUC
└─ Guardrail: решение быстрее 200 мс, поток жалоб не выше текущего
Читать это нужно снизу вверх как проверку связности: каждое лабораторное число обязано вести к наблюдаемому поведению в проде, а поведение — к деньгам. Если для какой-то метрики такую цепочку не построить, её взяли зря и она будет только отвлекать
Пример: антифрод
Разберём цепочку на живом случае, потому что именно здесь метрики обманывают особенно охотно
Предположим, мошеннические операции составляют один процент от всех. Модель, которая всегда отвечает «всё честно», получает accuracy (долю верных ответов) в 99% и при этом не приносит никакой пользы: она не поймала ни одного мошенника. Это классическая ловушка редких событий, и она — главная причина, по которой accuracy в антифроде не используют
Что смотрят вместо неё. Recall по фроду — какую долю настоящих мошеннических операций система поймала. Precision — какая доля сработавших тревог оказалась не пустой; именно это число определяет, сколько лишней работы упало на службу проверки. Потери от мошенничества в рублях — бизнес-метрика, ради которой всё делается. И доля ошибочных блокировок честных клиентов как ограничитель, потому что раздражённый клиент, которому не дали заплатить, уходит и рассказывает об этом другим
Обратите внимание, как связаны последние два числа: подняв recall, вы почти всегда поднимете и число ложных тревог. Это не дефект модели, а естественный компромисс, и решение, где остановиться, — продуктовое
Где здесь чаще всего ошибаются
Гоняются за accuracy там, где один класс кратно перевешивает другой. Приносят руководству лабораторную цифру и подают её как уже заработанные деньги. Забывают про ограничители и вытягивают главную метрику ценой скорости, счёта за вычисления или волны жалоб. И не сшивают цепочку от offline к бизнесу, из-за чего через полгода никто не может объяснить, что дала команде вся эта работа
О чём спросить команду
У дата-сайентиста — какую offline-метрику берём и почему именно она отражает бизнес-цель. У аналитика — как и за какой срок мы поймём, что в проде действительно что-то изменилось. У бизнеса — какая ограничивающая метрика не имеет права просесть ни при каких обстоятельствах, потому что именно её и придётся защищать при выкате
Итог
Метрика модели — не финишная черта, а одно звено цепи. Профессиональный разговор о качестве всегда содержит четыре этажа: лабораторный замер, поведение в проде, деньги и ограничители. Продакт отвечает за то, чтобы цепочка была построена и не рвалась, иначе улучшение метрики останется частным успехом команды, никак не связанным с судьбой продукта
Модель антифрода показала точность 99.5% на тесте. Команда довольна. Через месяц после запуска бизнес сообщает: резкий рост обращений в поддержку с жалобами «заблокировали мою карту».
Что пошло не так? Как это могло произойти при точности 99.5%?
Так эту тему спрашивают на интервью на AI/ML Product Manager. Нажми на вопрос, чтобы увидеть эталонный ответ.