Автономный цикл пополнения: Databricks MMF, Genie Agent и Amazon Quick

Узкое место сместилось от прогноза к действию

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

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

Решение AWS замыкает этот разрыв в цикл из четырёх стадий — прогноз (Forecast), детект (Detect), решение (Decide) и действие (Act): Databricks отвечает за прогноз, а Amazon Quick повторяет последние три стадии по расписанию.

Авторы подчёркивают, что закрытый цикл сам по себе важнее отдельной модели прогнозирования: прогноз может улучшаться, а контур «предсказание — действие» остаётся рабочим активом.

Прогноз на Databricks

Прогноз строит Databricks Many Model Forecasting (MMF), который отдаёт Chronos-2 для предсказания 7-дневного спроса по каждому SKU.

Chronos-2 — фундаментальная модель прогнозирования Amazon, спроектированная под произвольные задачи: одиночные ряды, множественные совместно меняющиеся ряды и ряды с внешними факторами, причём в режиме zero-shot, без дополнительного обучения.

Блог опирается на пример fresh_retail_net из акселератора MMF, где Chronos-2 даёт zero-shot прогноз по всему каталогу.

Ноутбуки 01 и 02 берутся из этого акселератора, причём второй считается на serverless GPU с ускорителем A10, который ноутбук настраивает сам; именно они формируют таблицы прогноза.

Детект всплеска через Databricks Genie Agent

Стадию детекта выполняет Databricks Genie Agent: он возвращает SKU, у которых среднее за следующие 7 дней не меньше чем в 1,5 раза превышает среднее за предыдущие 14 дней.

Чтобы в выборку не попадала низкообъёмная мелочь, задан явный числовой порог: средние продажи за предыдущие 14 дней должны быть не меньше 1.

Агент описывается файлом genie/genie_space.json, где перечислены шесть таблиц, инструкции по детекту всплесков и закреплённый пример запроса, который делает ответ про всплески детерминированным.

После прогона ноутбуков каталог mmf содержит шесть объектов, к которым обращается агент: daily_sales_raw и demand_train из ноутбука 01, представления scoring_output_mv и evaluation_metrics_mv из ноутбука 04, а также product_dim и location_dim из ноутбука 03.

Порядок запуска важен: ноутбук 04 создаёт представление, к которому обращается проверочная ячейка ноутбука 03.

Решение и заказ в Amazon Quick

Amazon Quick стоит в середине схемы и остаётся единственным компонентом, который касается обеих сторон сразу.

Прогноз Quick получает от Databricks Genie Agent по Model Context Protocol, фид поставщиков читает из Amazon S3 Tables, а заказы отправляет через коннектор OpenAPI, соединяя данные по общему ключу товара в момент решения, а не копируя всё в одно хранилище.

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

Рутинный заказ уходит через Supplier Order API методом POST /orders, а исключение превращается в тикет на ручной разбор через POST /tickets.

Под капотом Supplier Order API — Amazon API Gateway перед AWS Lambda и Amazon DynamoDB, а ключ API хранится в AWS Secrets Manager.

Поток собран из шага Detect Demand Surges, цикла SKU Processing со шагами Lookup Suppliers, Select Best Supplier, Submit Order, Raise Ticket и Generate SKU Summary, а завершает его шаг Generate Consolidated Report.

Фид поставщиков живёт отдельно от прогнозов в Amazon S3 Tables на Apache Iceberg: загрузчик строит синтетический каталог поставщиков по публичным ключам товаров FreshRetailNet-50K и создаёт по три поставщика на товар и город в пределах 7-дневного окна.

Вывод загрузчика детерминирован: каждый прогон даёт один и тот же фид из 63 861 строки.

Один набор поставщиков специально оставлен недозаполненным, чтобы всплеск, который не может закрыть ни один поставщик, действительно упирался в ручной разбор.

Amazon Quick Sight читает фид поставщиков в режиме Direct Query, поэтому каждый прогон видит последние данные, а не кэшированную копию SPICE.

Что нужно для развёртывания

Весь набор инструментов укладывается в локальный терминал: 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, иначе потоки и коннекторы не создать, а учётной записи Databricks нужно право CREATE CATALOG на metastore либо администратор, который заранее создаст каталог mmf.

Все команды и скрипты читают параметры аккаунта из одного файла.supply-chain-automation-env, который создаётся один раз и подгружается в оболочку.

CLI-часть закрывают два скрипта: setup_databricks.sh отвечает за ноутбуки, Genie Agent и OAuth-приложение, setup_aws.sh — за Supplier Order API, фид в S3, аккаунт Quick, источник данных, пространство и поток.

Оба скрипта останавливаются на четырёх шагах, доступных только в консоли: два экшн-коннектора, выдача доступа к S3 Tables и создание датасета.

Для связи Quick с Genie Agent регистрируется конфиденциальное OAuth-приложение Databricks на уровне аккаунта, и его client secret показывается только один раз.

Демонстрационный эндпоинт Supplier Order API по умолчанию принимает записи без аутентификации, поэтому для чего-то большего, чем контролируемая демонстрация, стек разворачивают с параметром RequireApiKey=true.

Основная регулярная статья расходов — редакция Amazon Quick Enterprise с помесячной оплатой за пользователя, тогда как остальные ресурсы тарифицируются по использованию и для демонстрационных объёмов стоят немного.

Что показал прогон

На приложенных демонстрационных данных один прогон даёт шесть SKU со всплеском, пять рутинных заказов и один тикет-исключение, причём авторы отдельно оговаривают, что это счётчики конкретного датасета, а не показатель производительности.

Исключением стал товар 122 в регионе Northeast — тот самый SKU, который фид намеренно снабжает недостаточно: ни один поставщик не покрывает его 7-дневный спрос, поэтому поток поднимает тикет вместо заказа.

Рутинные заказы ушли по товарам 261, 191, 299_300, 450_300 и 4.

Результат проверяется чтением таблиц DynamoDB с заказами и тикетами, а повторяющееся расписание добавляет новую партию на каждом интервале — после проверки его следует отключить, чтобы заказы не продолжали размещаться.

Почему цикл можно оставить включённым

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

Второе — закрепить запрос всплеска: Genie пересобирает SQL под каждый вопрос, что удобно человеку, но неприемлемо для задания по расписанию, поэтому определение агента фиксирует запрос и числовой порог, и шесть SKU возвращаются как шесть при каждом запуске.

Третье — дозировать автономность по типу решения: предсказуемое большинство заказывается само, а нерешаемые позиции уходят человеку по одному и тому же правилу для каждой позиции.

Четвёртое — не привязывать конструкцию к одной модели: Chronos-2 даёт нужный вероятностный прогноз сегодня, но дальше по потоку ничего под него не завязано, поэтому схема стареет вместе с улучшением моделей, а не устаревает вместе с ними.

Авторы отмечают, что шаблон обобщается за пределы ритейла: он применим всюду, где прогноз из одной системы нужно сверить с операционными данными из другой и на этом основании действовать.

Ограничения и уборка

Воспроизводимость обеспечивает сопровождающий репозиторий aws-samples: в нём лежат конфигурация Genie Agent, определение потока и скрипт удаления.

Разбор опирается на синтетический фид поставщиков и демонстрационный Supplier Order API, а не на промышленные интеграции: сам блог описывает рабочий стенд, в котором значения аккаунта нужно подставить свои.

Для удаления служит cleanup.sh, который в безопасном порядке снимает поток, пространство, датасет, источник данных и коннекторы Quick, Genie Agent, SQL-хранилище и каталог mmf в Databricks, стек Supplier Order API вместе с Lambda, таблицами DynamoDB и секретом, а также бакет S3 Tables.

Ресурсы уровня аккаунта — подписку Quick и OAuth-приложение Databricks — скрипт оставляет на месте, потому что они могут использоваться другой работой, и их удаление требует отдельного подтверждения.

Перед разборкой расписание потока отключают, чтобы он не размещал новые заказы во время удаления ресурсов.