Прогноз живёт в таблице, а не в системе
Планировщик строит план в собственном файле, потому что модель отдаёт результат письмом или выгрузкой. Данные расходятся, и через два месяца никто не понимает, какая версия плана актуальна.
Предиктивная аналитика
Прогноз, на который можно опереться в ежедневной работе
Строим модели на ваших данных и доводим их до продакшена: от постановки бизнес-метрики и расчёта признаков на момент прогноза до контроля дрейфа, регламента переобучения и проверки эффекта на реальном процессе.
Или сразу: +7 (962) 368-39-51 Telegram
WAPE
качество считаем на отложенном периоде
бэктест
проверка по скользящему окну истории
дрейф
контроль деградации модели в проде
A/B
эффект измеряем, а не предполагаем
Почему прогнозы не доходят до продакшена
Мы почти всегда видим одну и ту же картину: хороший прототип в ноутбуке аналитика, который через месяц перестаёт использоваться.
Признаки, которых не будет в момент прогноза
В обучение попадают поля, известные только после закрытия периода: итоговая сумма заказа, факт отгрузки, финальный статус сделки. На офлайновой валидации метрика отличная, в проде модель предсказывает шум.
Истории не хватает или она грязная
В заказах остались тестовые записи, дубли из-за повторной интеграции, отмены без причины, а глубина истории — один сезон. По таким данным нельзя отделить сезонность от тренда.
Модель деградирует молча
Ассортимент, цены, промо и поведение клиентов меняются, распределение признаков уезжает. Точность падает постепенно, и заметить это можно только по журналу предсказаний и фактическим исходам.
Нет ответственного за переобучение
Прототип собрал подрядчик или ушедший аналитик, код остался в четырёх ноутбуках без версий данных и параметров. Воспроизвести результат уже невозможно, а обновлять некому.
Эффект никто не считал
Задача звучала как «нужна нейросеть для прогноза продаж», а не как «сократить излишки на складе на 15%». Без базовой линии и замера после внедрения проект невозможно ни защитить, ни закрыть.
Что входит в работу над моделью
Можно взять весь цикл или отдельный этап: например, вытащить уже существующий прототип в продакшен и поставить мониторинг.
Постановка задачи и метрики
Переводим бизнес-пожелание в измеримую задачу прогнозирования с горизонтом, гранулярностью и критерием приёмки.
- Что именно прогнозируем: SKU на складе, отток по клиенту, вероятность оплаты по счёту
- Горизонт и частота: день, неделя, месяц; батч ночью или по запросу
- Базовая линия: текущий процесс планирования или наивный прогноз
- Критерий приёмки: WAPE или MAPE по группе, а не средняя точность по всей выборке
Данные и признаки
Собираем обучающую выборку из ваших систем и строим признаки так, как они будут выглядеть в момент прогноза.
- Витрины из PostgreSQL, ClickHouse или объектного хранилища
- Признаки на прошлый момент времени без утечки будущего
- Календарные эффекты: праздники, промо, дни выплат, сезонность
- Feature store или переиспользуемый SQL-слой, чтобы обучение и инференс считали одно и то же
Модели и честная валидация
Идём от простого к сложному и оставляем модель сложности, которая действительно оправдана качеством.
- Baseline: сезонный наивный прогноз, среднее по последним неделям
- Градиентный бустинг: CatBoost и LightGBM с категориальными признаками
- Временные ряды: SARIMAX, Prophet, модели с иерархией SKU и складов
- Бэктест по скользящему окну: обучаемся на прошлом, проверяем на будущем
Продакшен и сопровождение
Превращаем модель в сервис с версиями, логами и понятным регламентом обновления.
- Батч-расчёт в Airflow или сервис инференса на FastAPI
- Версионирование моделей, данных и параметров, воспроизводимость результата
- Мониторинг дрейфа признаков и качества по факту исхода периода
- Регламент переобучения и проверка эффекта через A/B или пилот на группе
Как проходит проект прогнозирования
Первые недели уходят на данные и базовую линию: именно здесь становится понятно, даст ли модель ощутимый выигрыш.
-
01 1–2 недели
Постановка и аудит данных
Фиксируем объект прогноза, горизонт и метрику приёмки. Проверяем глубину и качество истории, ищем утечки будущего в признаках.
-
02 2–4 недели
Базовая линия и прототип
Считаем baseline, собираем первый набор признаков, сравниваем несколько семейств моделей на бэктесте. Показываем ожидаемый выигрыш в измеримых единицах.
-
03 3–6 недель
Внедрение в процесс
Выводим расчёт в расписание, отдаём прогноз в систему планирования или дашборд, обучаем пользователей и фиксируем регламент переобучения.
-
04 ежемесячно
Мониторинг и развитие
Следим за дрейфом и точностью, разбираем провалы по группам товаров, добавляем признаки и модели для новых задач.
Где предиктивная аналитика даёт эффект быстрее всего
Быстрее всего окупаются задачи, где прогноз встроен в регулярный процесс и решение принимается часто: планирование закупок и запасов, прогноз отгрузок по складам, управление промо, скоринг в продажах, прогноз оттока в подписочных продуктах, прогноз нагрузки на инфраструктуру и персонал контакт-центра.
Общий признак таких задач — наличие истории в ваших системах, повторяющегося цикла и стоимости ошибки в обе стороны: и излишек запаса, и упущенная продажа считаются в деньгах. Там, где цена ошибки не определена, прогноз остаётся красивой картинкой на дашборде.
Почему точность 94% в ноутбуке превращается в 68% в продакшене
Три причины встречаются чаще всего. Первая — утечка данных: в признаки попадает информация, доступная только после наступления прогнозируемого периода. Вторая — разные определения признака при обучении и при инференсе: в обучении агрегат считался по финальным данным, в проде доступны только загруженные на текущий момент. Третья — несоответствие распределений: модель обучалась на периоде с другим ассортиментом и без крупной промо-акции.
Мы закрываем это технически: признаки считаются на момент прогноза, валидация идёт по времени, а не случайным разбиением, а метрика качества фиксируется по группам объектов, а не одной усреднённой цифрой. Отдельно ведём журнал предсказаний, чтобы сравнить прогноз с фактом, когда период закроется.
Как мы измеряем эффект от модели
До внедрения фиксируем базовую линию: как показатель планировался раньше и какую ошибку давал текущий процесс. После внедрения сравниваем на одинаковых периодах — это самый простой и убедительный аргумент для руководства.
Когда возможно, запускаем пилот на части объектов: например, прогноз применяется для двух категорий товаров или одного региона, остальные работают по-старому. Так эффект отделяется от сезонности и рыночных изменений. Для задач с быстрым откликом используем A/B-тест, для задач со сменными периодами — сравнение по историческим отрезкам с одинаковым профилем.
Частые вопросы
Для недельного прогноза спроса с учётом годовой сезонности желательно два-три полных года истории: иначе сезонность нельзя отделить от тренда. Для задач оттока обычно достаточно 6–12 месяцев наблюдений с датами ухода клиентов. Если история короче, мы начинаем с более простой модели и базовой линии, фиксируем журнал предсказаний и наращиваем качество по мере накопления данных.
Прототип с базовой линией и оценкой выигрыша на исторических данных — обычно три-шесть недель. Полноценное внедрение в процесс планирования с мониторингом и регламентом переобучения занимает ещё один-два месяца. Если данные уже собраны в хранилище и есть витрина, сроки сокращаются примерно на треть.
На табличных данных с признаками, которые мы формируем для планирования и оттока, бустинг почти всегда как минимум не хуже, а обучается быстрее и объясняется понятнее. Нейросетевые архитектуры дают выигрыш на последовательностях событий, текстах и изображениях. Мы выбираем модель по результату бэктеста и по стоимости эксплуатации, а не по названию метода.
Мы передаём не только модель, но и весь контур: код обучения и расчёта в вашем репозитории, зафиксированные версии зависимостей, описание признаков, инструкцию по переобучению и дашборд качества. Дальше возможны два режима — ваша команда сопровождает самостоятельно, а мы остаёмся на консультациях, либо мы берём мониторинг, переобучение и развитие моделей на себя по соглашению об уровне сервиса.
Data Science: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Есть задача, которую нужно прогнозировать?
Расскажите, какой показатель планируете и какие данные есть в системах, — оценим реалистичность прогноза и сроки.