Автоматизация пополнения запасов в розницу с помощью прогнозирования спроса и ИИ

Распределение товаров на основе ИИ-прогнозов: автоматизация через три облачных платформы

Главная проблема розничной торговли — не в самом прогнозе спроса. Модели вроде Chronos-2 уже могут предсказать потребность по тысячам товаров сразу без настройки под каждый SKU. Узкое место переместилось дальше: между готовым прогнозом и фактическим заказом проходят часы или дни. Прогноз сидит в одной системе, данные о поставщиках — в другой, доступ к системе заказов есть у третьих людей. AWS ML показал, как скрепить эти части в автоматический цикл, который работает без перерывов.

Решение строится в четыре этапа, разделённые между Databricks и Amazon QuickSight. Databricks вычисляет прогноз спроса с помощью Genie Agent — это специальный интеллектуальный агент, который находит скачки спроса в таблицах Chronos-2 прямым запросом. Параллельно Amazon QuickSight подтягивает эти же предсказания через канал Model Context Protocol, смотрит актуальные запасы у поставщиков (они хранятся отдельно в S3 Tables как Apache Iceberg), сопоставляет спрос со способностью поставить, а затем либо автоматически выставляет заказ через API, либо создаёт тикет исключения для человека. Система работает по расписанию, всё держится на трёх компонентах: Genie Agent для обнаружения скачков, OpenAPI коннектор для отправки заказов, и MCP коннектор для связи с прогнозами.

Развёртывание требует подготовки: нужно заполнить конфиг .supply-chain-automation-env, запустить два скрипта (setup_databricks.sh для ноутбуков и Genie, setup_aws.sh для остального), а затем выполнить четыре ручных шага в консоли Amazon QuickSight. На стороне Databricks создаются таблицы с прогнозами, регистрируется OAuth-приложение для безопасного доступа из QuickSight. На стороне AWS разворачивается имитационный Supplier Order API через Lambda и DynamoDB, создаётся аккаунт Amazon QuickSight, настраиваются два коннектора (к Genie Agent и к API заказов) и ещё один датасет из S3 Tables с информацией о поставщиках. Вся логика заложена в готовой конфигурации flow_definition.json, которая заполняется реальными ID ресурсов и публикуется как поток.

На тестовых данных система находит шесть товаров со скачком спроса: пять из них успешно выставляются как заказы, один (товар 122 из северо-востока) поднимается в исключение, потому что ни один поставщик не может его покрыть в полном объёме — это намеренная часть демо, чтобы показать, как работает эскалация на человека. За один проход через DynamoDB можно увидеть, какие заказы были выставлены и какие тикеты созданы. Когда поток настроен на расписание с галкой «Run with no confirmation», он автоматически отправляет типовые заказы без подтверждений.

Практический смысл для общепита и сетевых магазинов очевиден: сокращается разрыв между моментом, когда товар начнёт расходиться быстрее, и моментом, когда его придёт больше со склада или от поставщика. Менеджер не сидит каждый день с экселем, пересчитывая запасы — система сама узнаёт о скачке, сама проверяет, кто может поставить, и отправляет заказ. Человек вмешивается только если что-то необычное: один поставщик перегружен или товар попадается редко. Решение обойдётся примерно в стоимость лицензии Amazon QuickSight (месячная оплата за пользователя) плюс микрозатраты на вычисления. Однако издание не раскрывает точные цены и не называет сроки, за которые окупится автоматизация; кроме того, остаётся открытым вопрос, насколько хорошо система работает с российскими поставщиками и их API, и как она справляется, если товарные каталоги у разных систем различаются по названиям или кодам.