Согласование прогнозов: почему общий спрос не равен сумме каналов
Общий прогноз может расходиться с суммой каналов, когда прогнозы этих уровней строят независимо и не задают ограничения на суммы. Согласование прогнозов приводит их к одному правилу: прогноз бренда равен сумме каналов, каждый канал — сумме его товаров. Это условие согласованности, а не обещание большей точности; принцип описан в учебнике по прогнозированию.
Откуда берётся расхождение
В иерархии «бренд → канал → товар» прогнозы можно строить отдельно для каждого узла. Независимые прогнозы необязательно складываются в общий итог. Согласование, или forecast reconciliation, задаёт ограничения на суммы и преобразует прогнозы так, чтобы ограничения выполнялись. Принцип согласования.
Возьмём один условный бренд и прогноз спроса за ноябрь в штуках. WB и Ozon — названия учебных веток, не подключённые площадки. Верхний независимый прогноз — 120 штук, каналы — 40 и 60. Из их суммы получается 100, значит расхождение с верхним уровнем — 20 штук. Все числа придуманы редакцией и записаны в исходном CSV.
Бренд: независимый прогноз 120
├─ WB: 40
│ ├─ SKU A: 25
│ └─ SKU B: 15
└─ Ozon: 60
├─ SKU A: 20
└─ SKU B: 40Схема показывает основной сценарий из учебных данных. Товар A может продаваться в обоих каналах: это разные листья дерева. Общий итог считаем по парам «канал + товар», а не по уникальному названию SKU.
Что сохраняет bottom-up
Bottom-up, или «снизу вверх», сохраняет прогнозы нижнего уровня и складывает их для вышестоящих узлов. В этом способе независимый верхний прогноз не используется для итоговой суммы. Описание bottom-up.
В нашем примере прогнозы товаров дают WB 25 + 15 = 40, Ozon 20 + 40 = 60, бренд 40 + 60 = 100. Мы получили согласованное дерево, заменив верхние 120 на 100. Это изменение способа расчёта, а не найденные или потерянные заказы. Результат bottom-up.
Что сохраняет top-down
Top-down, или «сверху вниз», сохраняет верхний прогноз и распределяет его по нижним узлам с выбранными долями. Сами доли — отдельная часть метода: учебник различает способы их получения. Описание top-down.
Для учебного расчёта выберем доли из исходного CSV: WB — 40/100 = 40%, Ozon — 60/100 = 60%. Тогда верхние 120 распределятся как 48 и 72. Внутри каждого канала сохраним исходное соотношение товаров. Мы выбрали эти доли для примера; это не исторические продажи и не настройка библиотеки. Код расчёта.
| Узел | Независимый прогноз, шт. | Bottom-up, шт. | Учебный top-down, шт. |
|---|---|---|---|
| Бренд | 120 | 100 | 120 |
| WB | 40 | 40 | 48 |
| WB → A | 25 | 25 | 30 |
| WB → B | 15 | 15 | 18 |
| Ozon | 60 | 60 | 72 |
| Ozon → A | 20 | 20 | 24 |
| Ozon → B | 40 | 40 | 48 |
Все строки таблицы: независимые прогнозы — входные данные, два согласованных варианта — расчёт редакции.
Оба варианта согласованы. Равенство сумм не подсказывает, какому уровню доверять. Если на верхнем уровне закреплён коммерческий план, отдельно обозначьте его как план: его распределение ещё не превращает план в прогноз спроса.
Если есть собственный магазин
Это отдельный, расширенный сценарий. Добавим магазин с прогнозом 20 штук: товар A — 5, B — 15. Общая сумма листьев теперь 120, а независимый прогноз бренда в этом сценарии зададим 144. Расхождение — 24, bottom-up даст 120. Исходные 120 верхнего уровня основного примера сюда не переносим. Расширенные входные данные.
Доли каналов теперь считаются от новой суммы: 40/120, 60/120 и 20/120. Распределение верхних 144 даст 48, 72 и 24 штуки. У магазина товары получат 6 и 18. Равенство сумм сохранено в новом составе дерева; старые доли 40%/60% для него не подходят. Расширенный результат.
Как заметить двойной учёт
Для такого дерева зафиксируйте период, единицу и смысл целевой величины, затем проверьте листья по ключу «канал + SKU». В нашем скрипте повтор той же пары внутри одного сценария вызывает ошибку. Один SKU в разных каналах допускается; прогнозы за разные периоды или в разных единицах внутри сценария отклоняются. Проверка входов.
Не складывайте агрегаты с листьями. Если в основном примере прибавить бренд, каналы и товары одной колонкой, получится 120 + 100 + 100 = 320. Это сумма нескольких уровней, не спрос. Такая ошибка может остаться даже при идеально согласованных прогнозах, если неверно собрать отчёт. Арифметический контрпример.
Почему согласованность не доказывает точность
Представим два возможных фактических итога для основного примера. Если спрос оказался 100, у bottom-up ошибка верхнего уровня равна нулю, у выбранного top-down — 20. Если спрос оказался 120, соотношение меняется: ошибки 20 и 0. Оба дерева согласованы в обоих случаях. Это вымышленные исходы для сравнения абсолютной ошибки, не результат испытания на продажах. Проверка контрпримера.
Чтобы выбрать метод для работы, сравните его с исходными прогнозами на периодах после окончания обучающей выборки. Ошибки нужно смотреть на тех уровнях, где принимаются решения: ровная сумма бренда не отвечает на вопрос, какой товар нужен каждому каналу. Оценку точности и сравнение методов рассматривает учебник.
Если у вас только один прогноз без разбиения по уровням, согласовывать его не с чем. Если отчёт уже получен суммированием одного набора нижних прогнозов, отдельное исправление сумм также не требуется. Сначала проверьте состав дерева и двойной учёт, а к выбору метода переходите при независимых прогнозах разных уровней. Правило суммирования.
Для простого bottom-up достаточно прогнозов листьев и карты их принадлежности каналам: следующий шаг — суммирование по этой карте. Сравнить методы для рабочего отчёта сложнее: нужны временные ряды, прогнозы на отложенных периодах и оценка ошибок по уровням. Это отдельная аналитическая проверка, её не заменяет запуск учебного скрипта. Расчёт и сравнение методов.
Как повторить расчёт
Скачайте учебный пакет и распакуйте. Внутри — входной CSV, два скрипта, результаты и описание. Только стандартная библиотека Python, без установки пакетов и доступа к облачному сервису.
Создайте итоговую таблицу для двух способов и обоих сценариев. Ожидаемые числа — в готовом результате.
python3 reference.pyЗапустите проверку ручных ожиданий и намеренно испорченных входов. Ожидаемый итог — 39 из 39, как в журнале проверки.
python3 verify.py
В редакционном прогоне успешно прошли 39 из 39 проверок: суммы, распределение, сохранение верхнего итога и отказы на неверные входы. Это проверка арифметики, не обучение модели и не испытание HierarchicalForecast или TimeGPT. Происхождение данных и границы проверки описаны в записи расчёта; результаты — в журнале проверки.
Источники
- Forecasting: Principles and Practice — согласование и оценка прогнозов; проверено в дату в шапке.
- HierarchicalForecast — описания bottom-up и top-down; проверено в дату в шапке. Библиотеку не запускали, коммерческий доступ не проверяли.
- Учебный пакет редакции — вымышленные входы, код, результаты и проверки.
Редакция Кометы · Как работает редакция