Прогнозирование спроса: почему модель в ноутбуке ещё не продукт
Получить хороший прогноз на одном датасете - только половина работы. Бизнесу нужен процесс, который завтра снова возьмёт данные, запустит расчёт, переживёт ошибку и отдаст результат в понятном состоянии.
Между хорошей моделью и рабочим прогнозом есть большой зазор
В ML легко получить ощущение готовности слишком рано. Ноутбук запускается, график выглядит убедительно, метрика лучше baseline. Для исследования это отличный результат.
Production начинается с другого вопроса: что произойдёт завтра, когда появятся новые данные. Кто подготовит признаки, какой период попадёт в расчёт, где сохранится версия результата, что увидит пользователь, если одна модель упала.
Если на эти вопросы отвечает вручную автор ноутбука, у бизнеса пока есть эксперимент, а не сервис прогнозирования.
Самая важная часть прогноза часто находится до модели
Прогнозирование спроса чувствительно к тому, что именно считается целевой величиной и какой момент времени моделирует система. Ошибка в окне данных может дать прекрасную метрику за счёт информации из будущего.
Поэтому подготовка train/test выборок должна быть частью воспроизводимого pipeline, а не разовой ручной процедурой. То же касается признаков: их расчёт для обучения и для реального прогноза должен совпадать.
Чем меньше скрытых шагов между сырыми данными и моделью, тем проще потом объяснить странный результат.
Сначала прогноз должен победить простой baseline
Не каждая задача спроса требует сложного ML. Иногда вчерашнее значение, среднее по последним неделям или сезонное правило дают результат, который трудно улучшить настолько, чтобы оправдать систему вокруг модели.
Baseline полезен ещё и как диагностический инструмент. Если сложная модель внезапно начинает проигрывать простому правилу, это быстрый сигнал проверить данные, признаки и изменение поведения процесса.
Я бы не удалял baseline после запуска ML. Он остаётся хорошей контрольной точкой для мониторинга.
Расчёт лучше проектировать как повторяемый pipeline
В моём сервисе прогнозирования отдельные этапы готовят данные и признаки, формируют train/test выборки, запускают модели и собирают каскадный прогноз.
Такой конвейер можно запустить повторно с теми же параметрами и понять, на каком шаге возникла ошибка. Это гораздо полезнее одного большого метода «посчитать прогноз», внутри которого смешаны чтение данных, обучение, постобработка и запись результата.
Промежуточные результаты тоже имеют смысл, если помогают не пересчитывать дорогой шаг после локальной ошибки.
Один прогноз редко остаётся одним
В реальном продукте быстро появляются разные горизонты, точки расчёта или наборы параметров. Если результат хранится как один файл «forecast.csv», история и сравнение теряются.
В production-контуре результаты многоточечных расчётов сохраняются как отдельные сущности. Пользователь может понимать, какой запуск он видит и в каком состоянии находится новый.
Это важнее, чем кажется: без идентичности расчёта невозможно нормально обсуждать качество модели и воспроизводить проблему.
Тяжёлый ML не должен держать HTTP-запрос открытым
Обучение и прогноз могут занимать минуты или дольше. Если пользовательский запрос ждёт всё это синхронно, система получает таймауты, повторные клики и непонятное состояние.
В моём контуре тяжёлые задачи выполняет Celery. API создаёт задачу, а пользовательский интерфейс следит за её состоянием вместо ожидания одного долгого ответа.
Это одновременно упрощает повторы после ошибки и позволяет ограничивать ресурсы воркеров отдельно от обычного веб-приложения.
Прогресс нужен не ради полоски загрузки
Если расчёт долгий, пользователю недостаточно статуса «выполняется». Полезно понимать, дошла ли система до подготовки данных, обучения, каскадного расчёта или сохранения результата.
Сервис отдаёт live-прогресс через WebSocket. Это интерфейсная функция, но её польза операционная: зависший этап становится видимым, а пользователь меньше склонен запускать дублирующий расчёт.
Хороший progress отражает реальные этапы pipeline, а не искусственно увеличивает процент каждую секунду.
Мониторить нужно не только метрику модели
ML-сервис может перестать работать при той же точности модели: закончилась память у worker, очередь не обрабатывается, источник данных не обновился. Поэтому production monitoring шире model monitoring.
В проекте Prometheus фиксирует состояние воркеров. Отдельно имеет смысл следить за длительностью этапов, количеством ошибок, свежестью данных и долей успешных запусков.
А качество самого прогноза оценивается позже, когда появляется факт. Эти два контура мониторинга не заменяют друг друга.
Когда прогнозирование не стоит начинать с ML
Если история короткая, правила бизнеса постоянно меняются или целевая величина определяется вручную задним числом, сложная модель только замаскирует качество исходного процесса.
Сначала полезнее получить стабильный набор данных и baseline. Иногда этого уже достаточно для решения. Иногда становится видно, какие дополнительные признаки действительно нужны.
ML хорошо работает там, где есть повторяемый сигнал и понятный способ проверить прогноз фактом.
Как я бы доводил прогноз до production
Я бы разделил работу на два параллельных результата: качество прогноза и надёжность запуска. Модель может ещё улучшаться, пока сам pipeline уже учится воспроизводимо получать данные, считать baseline, сохранять результат и показывать состояние.
Так к моменту появления сильной модели вокруг неё уже существует продуктовый контур, а не набор инфраструктурных задач, которые внезапно открылись перед релизом.
- Зафиксировать target и временные окна.
- Собрать воспроизводимую подготовку train/test.
- Сравнить модель с простым baseline.
- Разделить pipeline на наблюдаемые этапы.
- Вынести тяжёлые расчёты в фоновые workers.
- Хранить идентичность и историю запусков.
- Мониторить данные, pipeline и качество прогноза отдельно.
Вопросы
Какие данные нужны для прогнозирования спроса?
История целевой величины и признаки, которые известны на момент будущего прогноза. Конкретный набор зависит от бизнеса и горизонта прогнозирования.
Почему нельзя просто запускать ML-модель по расписанию?
Можно для простого сценария, но production-сервису ещё нужны воспроизводимая подготовка данных, контроль ошибок, хранение результатов, состояние запуска и мониторинг.
Зачем нужен baseline?
Чтобы понимать, даёт ли сложная модель реальную пользу и быстро замечать деградацию данных или pipeline.
Как показывать пользователю долгий ML-расчёт?
Запускать его фоновой задачей и отдавать состояние и реальные этапы прогресса через polling или WebSocket.
Что мониторить в ML production?
Свежесть и качество данных, состояние очередей и workers, ошибки и длительность pipeline, успешность запусков, а после появления факта - качество самого прогноза.