🏢 Ситуация
Вы — уже Middle ML Engineer. Виктор приводит вас на встречу с крупным клиентом: сеть «СуперМегаРитейл» (2000 магазинов, 47 распределительных центров) хочет систему прогноза спроса.
«Datacore берёт этот контракт, а ты — ведущий инженер проекта. Но код мы не пишем ещё месяц. Сначала — design document. Джуны начинают с модели, мидлы — с вопроса "а есть ли вообще проблема и стоит ли она решения?". Прочитай Бабушкина и Кравченко — и принеси мне первую версию дизайн-дока.»
🎯 Ваша задача
- Отличать problem space от solution space и находить настоящую проблему.
- Оценивать риски и цену ошибки до старта проекта.
- Составить структуру design document и провести его ревью.
📚 Теория
Problem space vs solution space
Классическая ошибка инженера — прыгать в пространство решений («сделаем градиентный бустинг с лагами!»), не изучив пространство проблемы («что на самом деле болит у бизнеса и почему?»).
Вопросы problem space для «СуперМегаРитейла»:
- Как устроен текущий процесс заказа и поставки? Кто владелец процесса (логистика? закупки? магазины?)
- Сколько компания теряет на разрыве «поставили − продали»? (Оценка клиента: ~$800M в год.)
- Какая из двух ошибок больнее: затоварка (посчитать легко — списания) или out-of-stock (посчитать трудно: упущенные продажи + уход клиента к конкуренту)?
Цена ошибки — до модели, а не после
Прежде чем строить систему, выпишите, что случится, если модель ошибётся, и в обе стороны:
| Ошибка | Последствствие | Оценка |
|---|---|---|
| Прогноз завышен (overstock) | излишки, списание скоропорта | легко посчитать из данных |
| Прогноз занижен (out-of-stock) | пустая полка, потерянный клиент | трудно: A/B или экспертная оценка |
Асимметрия цены ошибок дальше определит и метрику, и лосс (квантильный!), и SLA системы.
Предварительное исследование: build vs buy и степень новизны
- Build vs buy: прогноз спроса — зрелый рынок, есть вендоры. Строим своё, если прогноз — ядро конкурентного преимущества, данные специфичны или вендор не влезает в ограничения.
- Декомпозиция: «прогноз спроса» — это не одна задача, а семейство: новые товары vs зрелые, промо vs регулярные продажи, скоропорт vs долгий срок хранения.
- Степень новизны: не изобретайте архитектуру, если задача решается индустриальным стандартом. Инновации — туда, где стандарт упирается.
Design document: зачем и какой
Design doc — это документ, в котором решение проектируется и критикуется до того, как станет кодом. Мифы, которые мешают его писать:
«Это для больших компаний»— стартапу дешевле поймать ошибку в документе, чем в проде.«Только для сложных проектов»— простой проект = короткий док.«Нужен шаблон»— важен не шаблон, а покрытие ключевых вопросов.«Каждый док должен закончиться системой»— вывод «не делать» — тоже успех дока (и очень дешёвый).
Скелет design doc для ML-системы:
- Проблема и цель — на языке бизнеса, с цифрами.
- Цели и антицели — что мы НЕ делаем, так же важно, как то, что делаем.
- Актуальность и причины — анализ текущего процесса, сколько теряем, кому ещё пригодится.
- Предыдущие попытки — что уже пробовали, почему не взлетело.
- Метрики и лоссы (модуль 22) · Данные · Валидация · Бейзлайны.
- Интеграция, мониторинг, владение (модуль 23).
- Риски и цена ошибки.