ROC-AUC vs PR-AUC: когда что использовать

ROC-AUC и PR-AUC — две метрики, которые постоянно путают.
И чаще всего выбирают не ту.

Разберём на пальцах 👇

📈 Что такое ROC-кривая

ROC-кривая показывает:

👉 TPR (Recall) — сколько положительных нашли
👉 FPR — сколько отрицательных ошибочно посчитали положительными

Насколько хорошо модель отделяет классы.

ROC-AUC — площадь под этой кривой.

📊 Что такое PR-кривая

PR-кривая показывает:

👉 Precision — насколько точны предсказания
👉 Recall — сколько положительных нашли

Насколько хорошо модель находит редкий класс без мусора.

PR-AUC — площадь под этой кривой.

⚔️ Главная разница

👉 ROC-AUC → разделимость классов
👉 PR-AUC → качество положительных предсказаний

🚨 Где все ошибаются

Используют ROC-AUC при сильном дисбалансе классов.

Почему это плохо?

👉 FPR считается по огромному количеству негативов
👉 даже плохая модель может выглядеть «хорошо»

ROC-AUC становится слишком оптимистичной.

📉 Когда нужен PR-AUC

Если у тебя:

👉 fraud detection
👉 churn prediction
👉 medical diagnosis
👉 rare event detection

👉 используй PR-AUC

Потому что тебе важно:

👉 находить редкий класс
👉 не засыпать всё false positive

📈 Когда подходит ROC-AUC

Если:

👉 классы более-менее сбалансированы
👉 важна общая separability
👉 задача — в целом отличать классы

👉 тогда ROC-AUC ок

🧠 Интуитивный пример

Представь:

👉 1% — мошенники
👉 99% — нормальные

Модель говорит «всё ок» почти всегда:

👉 ROC-AUC может быть высоким
👉 PR-AUC будет низким

Потому что модель не ловит мошенников.

💥 Главный инсайт

ROC-AUC отвечает на вопрос:

Модель в принципе различает классы?

PR-AUC отвечает на вопрос:

Насколько полезны её положительные предсказания?

В одном предложении

Если класс редкий — PR-AUC важнее ROC-AUC.
Если баланс нормальный — можно использовать ROC-AUC.

ML-модели становятся помощниками в принятии решений на рекламных платформах

Технический директор рекламной платформы Т-Банка Василий Разумных рассказал, как работает система, в которой модели используются не только для предсказания кликабельности. По его словам, ML-модели определяют, что показывать конкретному человеку в определенный момент времени. На смену ручной сегментации приходит ML-таргетинг: система сама находит нужную для цели аудиторию. Скоринговая модель помогает в ранжировании: она учитывает экономическую эффективность, вероятность действия и репутацию рекламодателя.

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

Ошибки при train/test split

Train/test split — кажется самой простой частью ML.
Но именно здесь чаще всего ломают всю модель.

И самое опасное — ты можешь даже не заметить

Data Leakage — тихий убийца моделей

Ты случайно «подсматриваешь» в тест.

Примеры:

👉 нормализация на всём датасете до split
👉 target encoding на всех данных
👉 feature, напрямую связанная с таргетом

Модель показывает космический скор,
а в проде — провал.

Случайный split там, где нельзя

Ты делаешь random split…
но данные зависимы.

Примеры:

👉 временные ряды
👉 пользователи (один и тот же user в train и test)
👉 сессии

Модель узнаёт данные, а не обобщает.

Игнорирование времени

В задачах с временем:

👉 ❌ случайный split
👉 ✅ train = прошлое, test = будущее

Иначе ты:

👉 обучаешься на будущем
👉 предсказываешь прошлое

Это не ML. Это читерство.

4️⃣ Дисбаланс классов в split

Ты сделал split и получил:

👉 train: 5% positive
👉 test: 1% positive

Метрики начинают врать.
Решение:

👉 stratified split

Слишком маленький test

Test = 50 объектов
Accuracy = 90%

Звучит круто.
Но это статистический шум.

Маленький test = ненадёжная оценка.

Тест используется как валидация

Классическая ошибка:

👉 обучился
👉 посмотрел на test
👉 подкрутил модель
👉 снова посмотрел

Это уже не test. Это validation 2.0.

Дубликаты в train и test

Если один и тот же объект попал в обе выборки:

Модель просто запоминает.
Особенно критично:

👉 CV
👉 e-commerce
👉 табличные данные с ID

Неправильный split в CV

Cross-validation тоже можно сломать:

👉 leakage между фолдами
👉 группы не учитываются
👉 time-series перемешаны

Используй:

👉 GroupKFold
👉 TimeSeriesSplit

Главный инсайт

Train/test split — это не про «разделить данные».

Это про симуляцию реального мира.
Если split не отражает прод —
все метрики бесполезны.

В одном предложении

Плохой split может сделать плохую модель «идеальной» —
до момента, когда она выйдет в прод.

Feature Engineering важнее выбора модели

Самый непопулярный факт в ML:
модель — это не главное.

Можно часами выбирать между:
XGBoost
LightGBM
CatBoost
…и получить +1% к качеству.

А можно поменять фичи — и получить +20%.

Разберёмся, почему так 👇

Модель учится только на том, что ты ей дал

Garbage in → garbage out

Если признаки:
- шумные
- нерелевантные
- плохо отражают задачу

👉 никакая модель не спасёт

Даже самая большая.

Пример из жизни

Задача: предсказать отток клиентов

Фичи:
- возраст
- город
- тариф

Модель: ок, но слабый результат

Добавили:
- время с последнего действия
- частоту использования
- изменение активности

👉 резкий рост качества

Почему?
Потому что фичи начали отражать реальное поведение

Feature Engineering = внедрение знаний о задаче

Модель не знает:
- бизнес
- контекст
- причинно-следственные связи

Зато ты знаешь.
И когда ты создаёшь фичи —
ты “вшиваешь” это знание в данные.

Модель vs Фичи

Что меняем → эффект

Модель → +1–5%
Гиперпараметры → +1–3%
Feature Engineering → +10–50%

Где FE особенно решает

- Табличные данные
- Маленькие датасеты
- Бизнес-задачи

👉 там, где нет миллионов примеров, фичи — это всё

Когда модель важнее
- CV (изображения)
- NLP (тексты)
- Speech

👉 там фичи учатся автоматически

Почему все игнорируют FE

Потому что:
- это сложно
- это долго
- нет “магической кнопки”
- требует понимания данных

Гораздо проще:
“давай попробуем ещё одну модель”

Главный инсайт

ML — это не соревнование моделей.
Это соревнование представлений данных.

В одном предложении

Лучший способ улучшить модель —
👉 перестать тюнить модель и начать тюнить данные

Data Leakage: как незаметно сломать модель

Самая коварная ошибка в ML — это не плохая модель.
Это data leakage.

Потому что:

👉 модель показывает идеальные метрики
👉 ты радуешься
👉 выкатываешь в прод
👉 всё разваливается

И ты не понимаешь почему.

Что такое Data Leakage

Data leakage — это ситуация, когда модель
получает доступ к информации из будущего или из target’а,
которой не будет в реальном использовании.

Модель читерит, а не учится.

Почему это так опасно

Потому что leakage:

👉 не очевиден
👉 не даёт ошибок
👉 сильно улучшает метрики

Чем лучше скор — тем подозрительнее.

Классические примеры leakage

1. Нормализация до split

Сделали scaling на всём датасете,
а потом разбили на train/test.

Модель уже «видела» test.

2. Target encoding на всех данных

Посчитали средний target по категории
используя весь датасет.

В train попала информация из test.

3. Фичи из будущего

Пример:

👉 предсказываем отток
👉 используем действия после момента предсказания

Модель знает будущее.

4. Дубликаты

Один и тот же объект:

👉 в train
👉 и в test

Модель просто запоминает.

5. Неправильный split

Временные ряды:

👉 случайный split

Модель обучается на будущем.

Как понять, что у тебя leakage

Сигналы:

👉 слишком высокий score
👉 огромный разрыв между offline и продом
👉 модель «слишком уверена»
👉 странно важные фичи

Если выглядит слишком хорошо — скорее всего, так и есть.

Как защититься

1. Делай split до любых преобразований

Сначала:
👉 train / test

Потом:
👉 scaling
👉 encoding
👉 feature engineering

2. Следи за временем

👉 train = прошлое
👉 test = будущее

3. Используй pipeline

Все трансформации:
👉 обучаются только на train
👉 применяются к test

4. Проверяй фичи

Задай вопрос:

Эта информация доступна в момент предсказания?

Если нет — удаляй.

5. Делай sanity check

👉 обучись на случайных данных
👉 убери подозрительные фичи

Если качество не падает — что-то не так.

Главный инсайт

Data leakage — это не баг.
Это иллюзия качества.

В одном предложении

Если модель слишком хороша —
сначала проверь leakage, а потом радуйся.

Роскошный максимум: получить приглашение в команду SberAds за один день! 😉

Сделать это можно на One Day Offer* для Data Analyst**, который пройдёт уже 25 апреля. Сбер ждёт специалистов, которые готовы:

✔️ создавать и улучшать модели для real-time аукционов
✔️ трансформировать SberAds — вывести на пик эффективности, качества и релевантности рекламы
✔️ стать частью команды из 8000+ коллег (это вау! 🤩)

Занимай место в проекте мечты!

* One Day Offer — предложение о работе за один день.
** Data Analyst — аналитик данных.

Большие данные требуют порядка, а платформа — инструментов, которые этот порядок поддерживают. Такой вывод можно сделать после митапа YTsaurus, посвященного трехлетию выхода платформы в опенсорс.

Максим Бабенко — руководитель команды, преподаватель ШАДа и ВШЭ, кандидат физико-математических наук — рассказал о развитии платформы и её возможностях для ML. В Яндексе YTsaurus активно используется как основная инфраструктура для запуска GPU-вычислений. Все обучение моделей и batch-инференс делается при помощи YTsaurus.

Команда активно развивает платформу, появились разные вспомогательные инструменты и микросервисы, за последний год вышло много обновлений.

🤔Как создать автономного ИИ-агента для анализа трендов и поиска точек роста?

📅6 мая в 20:00 приглашаем на открытый вебинар курса «Разработка ИИ-агентов» с Артёмом Ревой.

На занятии разберём, как с помощью LangGraph выстраивать сценарий работы агента с несколькими этапами анализа, подключать протокол взаимодействия моделей (MCP) в среде разработки Cursor и расширять возможности интеллектуального помощника.

Покажем, как собрать агента для работы с Google Trends: находить аномалии, сравнивать запросы и выявлять перспективные темы. Вы узнаете, как превращать сырые данные в понятные рекомендации и использовать их для выбора направлений с высоким потенциалом роста.

💡Участие бесплатное — регистрируйтесь: https://vk.cc/cXdK5S

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru, erid: 2VtzqvE1tfh

Random Forest vs Gradient Boosting — реальное сравнение

Самый частый вопрос в табличных данных:
что выбрать — Random Forest или Gradient Boosting?

Ответ, который никто не любит:
зависит от задачи.

Но давай разберёмся по-честному, без мифов.

Что такое Random Forest

Это ансамбль деревьев, где:

👉 каждое дерево обучается независимо
👉 используются случайные подвыборки данных и фич

Идея: уменьшить variance за счёт усреднения.

Что такое Gradient Boosting

Это ансамбль деревьев, где:

👉 каждое следующее дерево исправляет ошибки предыдущего
👉 обучение идёт последовательно

Идея: минимизировать ошибку шаг за шагом.

Главное отличие

👉 Random Forest → деревья независимы
👉 Gradient Boosting → деревья зависят друг от друга

👉 RF = параллель
👉 GB = последовательность

Качество модели

В большинстве задач:

👉 Gradient Boosting выигрывает

Почему:

👉 лучше улавливает сложные зависимости
👉 оптимизирует ошибку напрямую

Поэтому:

👉 XGBoost
👉 LightGBM
👉 CatBoost

Стали стандартом индустрии.

Переобучение

Random Forest:

👉 устойчив к переобучению
👉 работает «из коробки»

Gradient Boosting:

👉 легко переобучается
👉 требует настройки

GB мощнее, но опаснее.

Скорость

Обучение:

👉 RF → быстрее и параллелится
👉 GB → медленнее (последовательность)

Инференс:

👉 часто сопоставим

Чувствительность к данным

Random Forest:

👉 менее чувствителен к шуму
👉 проще в использовании

Gradient Boosting:

👉 чувствителен к:
👉 шуму
👉 выбросам
👉 плохим фичам

Зато раскрывает хороший feature engineering.

Когда выбирать Random Forest

👉 нужен быстрый baseline
👉 мало времени на тюнинг
👉 данные шумные
👉 нужна стабильность

«Запустил и работает».

Когда выбирать Gradient Boosting

👉 нужна максимальная точность
👉 есть время на тюнинг
👉 данные относительно чистые
👉 важен результат

«Выжать максимум».

Главный инсайт

Random Forest — надёжный середняк.
Gradient Boosting — инструмент для победы.

В одном предложении

Хочешь быстро и стабильно → Random Forest.
Хочешь максимум качества → Gradient Boosting.