🏢 Ситуация
Модель прогноза спроса для «СуперМегаРитейла» побила все бейзлайны. Виктор:
«Поздравляю, самое лёгкое позади. Теперь — то, что отличает систему от модели: обучающие пайплайны, честный эксперимент, интеграция в процессы закупок, мониторинг и ответ на вопрос "кто чинит в 3 часа ночи". Допиши design doc до конца — это твой экзамен на настоящего мидла с прицелом на сеньора.»
🎯 Ваша задача
- Разделить training pipeline и inference pipeline; понять роль feature store.
- Спроектировать A/B-эксперимент и отчёт о результатах (debrief).
- Построить мониторинг четырёх уровней и различать типы дрейфа.
- Спроектировать fallback'и, release cycle и владение системой.
📚 Теория
Training pipeline ≠ inference pipeline
Обучение и инференс — разные системы с разными требованиями:
| Training | Inference | |
|---|---|---|
| Запуск | по расписанию/триггеру | 24/7 или батчем к дедлайну заказа |
| Требования | воспроизводимость, дешёвая переигровка | латентность, надёжность, fallback |
| Опасность | тихая деградация данных | падение сервиса в час пик |
Их общая точка — признаки: они обязаны считаться одинаково там и там (иначе training/serving skew). Отсюда feature store или, минимум, общая библиотека фичей + логирование фактических признаков инференса.
Пайплайн обучения должен быть тестируемым: юнит-тесты на трансформации, property-based тесты («прогноз ≥ 0», «сумма долей = 1»), smoke-обучение на сэмпле в CI.
A/B-тест системы и debrief
Дизайн эксперимента для прогноза спроса нетривиален: юнит рандомизации — не пользователь, а магазин (спилловеры внутри магазина). Ключевые решения из книги:
- метрики решения (списания, out-of-stock, маржа) и guardrail-метрики — фиксируются до старта;
- сплит-стратегия: стратификация магазинов по размеру/региону; проверка A/A-тестом;
- когда A/B невозможен (мало магазинов) — switchback (чередование периодов) или synthetic control;
- debrief-документ после эксперимента: что ждали, что получили, решение, выученные уроки. Отрицательный результат с внятным debrief — тоже актив компании.
Мониторинг: четыре уровня и типы дрейфа
Книга делит мониторинг ML-системы на уровни: входные данные → модель → выход модели → принятие решений. Плюс обычное здоровье сервиса (латентность, ошибки).
Словарь, который спрашивают на собеседованиях:
- Data drift (ковариантный сдвиг): изменилось распределение входов, зависимость та же. Модель «не видела таких примеров».
- Concept drift: изменилась сама зависимость вход → выход, даже при тех же входах.
- Output drift: сдвиг распределения предсказаний — дешёвый ранний индикатор обоих.
- Training-serving skew: признаки в проде считаются иначе, чем при обучении, — не дрейф, а баг, но симптомы похожи.
Реакции: переобучить на свежем, перестроить модель, включить fallback. Чтобы понять частоту переобучения — «тест на старение»: обучите модель на данных до T и измерьте деградацию качества по мере удаления от T.
Интеграция: API, релизы, fallback'и
- API проектируется от потребителя: закупкам нужен не «скор», а рекомендованный заказ с интервалом и флагом уверенности.
- Release cycle: shadow → canary (50 магазинов) → полная раскатка; версия модели в каждом ответе; откат конфигом.
- Overrides: бизнес должен уметь переопределить прогноз (промо, локальные события) — и эти переопределения логируются как данные.
- Fallback-иерархия: модель → предыдущая версия → seasonal naive → ручной заказ. Система деградирует плавно, а не падает.