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

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

СтадияКомпонентЧто делает
ForecastDatabricks MMFChronos-2 прогнозирует 7-дневный спрос по каждому SKU
DetectDatabricks Genie AgentВыявляет SKU во всплеске: среднее за 7 дней ≥ 1,5× среднего за 14 дней, база ≥ 1
DecideAmazon QuickСверяет всплеск с наличием в Amazon S3 Tables и выбирает самого дешёвого поставщика
ActAmazon Quick FlowsРазмещает заказ через Supplier Order API или открывает тикет на ручную проверку

Решение разбито на четыре стадии. Databricks Many Model Forecasting подаёт модель Chronos-2 и прогнозирует 7-дневный спрос по каждому SKU. Затем Databricks Genie Agent выявляет позиции во всплеске: всплеском считается средний спрос за следующие 7 дней как минимум в 1,5 раза выше среднего за предыдущие 14 дней, и только для SKU, у которых средний за предыдущие 14 дней не ниже 1 — этот порог отсекает шум по низкообъёмным позициям. На третьей стадии Amazon Quick сверяет каждый всплеснувший SKU с живой доступностью поставщиков в Amazon S3 Tables и выбирает самого дешёвого поставщика, способного покрыть потребность. На четвёртой Amazon Quick Flows размещает обычный заказ через Supplier Order API или открывает тикет на ручную проверку, если ни один поставщик в одиночку не закрывает всплеск.

Architecture diagram of the detect, decide, act loop connecting Databricks forecasting to Amazon Quick order automation
Architecture diagram of the detect, decide, act loop connecting Databricks forecasting to Amazon Quick order automation · Источник: AWS Machine Learning Blog

Ключевая деталь архитектуры — Amazon Quick стоит посередине и остаётся единственным компонентом, который касается обоих миров. Он достаёт прогноз через Databricks Genie Agent по протоколу Model Context Protocol, забирает фид поставщиков из S3 Tables и вызывает Order API через OpenAPI-коннектор. Сопоставление идёт по общему ключу retailer_product_id в момент принятия решения, а не через копирование всех данных в единое хранилище. Databricks производит аналитику, Amazon Quick действует на её основе.

Для воспроизведения нужны Databricks CLI 0.299.0 и выше, AWS CLI 2.36.2 и выше, jq 1.7 и uv либо Python 3.11 для загрузчика фида поставщиков. Используются подкоманды create-flow, create-data-source и create-space в aws quicksight. Два условия на уровне аккаунта ограничивают работу в консоли: пользователю Amazon Quick нужна роль Author или Author Pro — обычное место Enterprise без роли Author не позволяет создавать Quick Flows и коннекторы MCP и OpenAPI, — а учётной записи Databricks нужно право CREATE CATALOG на метахранилище либо администратор, который заранее создаст каталог mmf. Все команды и скрипты читают параметры аккаунта из файла.supply-chain-automation-env, который создаётся один раз.

Два скрипта закрывают все шаги, автоматизируемые через CLI: setup_databricks.sh отвечает за ноутбуки, Genie Agent и OAuth-приложение, setup_aws.sh — за Order API, фид в S3, аккаунт Quick, источник данных, пространство и поток. Оба останавливаются на четырёх шагах, доступных только в консоли: два коннектора действий, выдача доступа к S3 Tables и датасет. Что остаётся неопределённым: в материале нет данных о стоимости решения, задержках на реальном каталоге и о том, как система ведёт себя при конфликте поставщиков или сбое Order API. Экономический эффект — сокращение дефицита ходовых позиций — заявлен логикой схемы, но не измерен на конкретном ритейлере.