🏢 Ситуация
Design doc для «СуперМегаРитейла» одобрен. Лена:
«Теперь наполняем его инженерным содержанием. Четыре раздела, которые в книге называют "ранней стадией": метрики и лоссы, датасет, схема валидации, бейзлайны. Каждый — с обоснованием, почему именно так. Помни: ошибка на этой стадии стоит месяцы, потому что всё, что дальше, строится на этих решениях.»
🎯 Ваша задача
- Построить иерархию метрик: от лосса до бизнес-метрики.
- Спроектировать датасет и понять, «сколько данных достаточно».
- Выбрать схему валидации (включая нетривиальные: nested, adversarial).
- Построить лестницу бейзлайнов и понять, зачем нужен константный.
📚 Теория
Иерархия метрик
Одна метрика не описывает систему. В зрелом design doc метрики выстроены в пирамиду — от того, что оптимизирует градиент, до того, что видит CFO:
Правила пирамиды:
- Лосс ≠ метрика: лосс должен быть дифференцируемым и «дружить» с метрикой. Если бизнесу больнее недопрогноз — берём квантильный лосс, а не MSE.
- Consistency-метрики: стабильность прогноза между запусками и версиями — бизнес ненавидит, когда заказ на среду меняется на 40% после ночного пересчёта.
- Связку офлайн ↔ онлайн проверяют экспериментами: если рост офлайн-метрики не двигает онлайн — пирамида порвана, чинить её важнее, чем улучшать модель.
Датасет: сколько данных достаточно?
Разделы дока про данные: источники, ETL, фильтрация, разметка, метаданные.
- Кривая обучения по объёму данных (sample-wise learning curve) — главный инструмент ответа на «хватит ли данных»: обучите модель на 10%, 25%, 50%, 100% выборки и посмотрите на тренд качества. Выходит на плато → данных достаточно; растёт → данные ценнее новых фич.
- Проблема курицы и яйца: для рекомендаций нужны логи, а логи появятся после запуска рекомендаций. Решение — запуск простой версии (правила/популярное) ради сбора данных.
- Здоровый пайплайн данных: идемпотентность, проверки схемы, алерты на объёмы, воспроизводимость снапшотов.
Схемы валидации: стандартные и нетривиальные
| Схема | Когда |
|---|---|
| Holdout | много данных, быстрые итерации |
| K-fold CV | мало данных, нужна оценка разброса |
| Time-series (rolling) | всё со временем — как наш прогноз спроса |
| Nested CV | одновременно тюним гиперпараметры и честно оцениваем качество: внутренний цикл тюнит, внешний — меряет |
| Adversarial validation | проверка «train похож на test?»: обучаем классификатор отличать train от test. AUC ≈ 0.5 — выборки из одного мира; AUC → 1 — распределения разные, ваша валидация врёт |
Adversarial validation — недооценённый приём: он же показывает, какие признаки отличают train от prod (топ-фичи классификатора) — это будущие источники дрейфа.
Лестница бейзлайнов
- Константный бейзлайн (средняя/медиана для регрессии, мажоритарный класс для классификации, случайный порядок для ранжирования) — это санити-чек и точка отсчёта. Провести две недели над моделью и проиграть константе — классика, от которой спасает 5-минутный бейзлайн, построенный в день №1.
- Когда бейзлайн не нужен (по книге): цена ошибки экстремальна (медицина — там fallback на человека), решение уже проверено в бою, или вы перестраиваете работающую систему (старая версия и есть бейзлайн).
- Complexity bias — когнитивная ловушка «сложное = хорошее». Лестница бейзлайнов — организационное лекарство от неё.