Предвзятый обзор Deep Inventory Management
В конце 2022 года команда из Amazon опубликовала исследование, связанное с цепочками поставок, под названием Deep Inventory Management1. В этой статье представлена техника оптимизации запасов (в дальнейшем именуемая DIM), которая использует как методы обучения с подкреплением, так и глубокое обучение. В статье утверждается, что данная техника успешно применялась для более чем 10,000 SKU в реальных условиях. Эта статья интересна по многим аспектам и отчасти напоминает то, чем занимается Lokad с 2018 года. Далее я обсуждаю, что, на мой взгляд, являются достоинствами и недостатками техники DIM с конкретной точки зрения Lokad, поскольку мы исследовали похожие направления в последние несколько лет.

Функция цели и ограничения (стр.27, Приложение A), из "Deep Inventory Management", ноябрь 2022
Моё первое наблюдение состоит в том, что эта статья вызывает доверие, и поэтому я склонен поддерживать её выводы. Общая конструкция статьи очень созвучна моим собственным экспериментам и наблюдениям. Действительно, большинство публикаций по цепочкам поставок — это просто ерунда — по той или иной причине. Цепочки поставок сталкиваются с серьёзным эпистемическим разложением,2 и глубокий скептицизм должен быть позицией по умолчанию при столкновении с любой, якобы «лучшей», методикой решения проблемы цепочки поставок.
Самый заметный вклад техники DIM заключается в полном отказе от этапа прогнозирования в пользу непосредственной оптимизации запасов. Классический подход к оптимизации запасов состоит в разбиении проблемы на два этапа. Сначала прогнозируется спрос, затем оптимизируется решение по запасам. Lokad всё ещё придерживается этого поэтапного процесса (по уважительным причинам, см. наградная функция 3). Однако DIM объединяет эти два этапа посредством подхода, называемого дифференцируемыми симуляторами.
Объединение этапов «обучения» и «оптимизации» представляет собой перспективное направление не только для цепочек поставок, но и для информатики в целом. За последние два десятилетия наблюдается постепенное сближение между обучением и оптимизацией с алгоритмической точки зрения. Фактически, основная методика обучения, используемая Lokad, имеет в своей основе алгоритм оптимизации. И наоборот, недавний прорыв Lokad в области стохастической оптимизации (неопубликованный) базировался на алгоритме обучения.
Я представляю будущее, в котором автономное прогнозирование будет признано устаревшей практикой, полностью заменённой новыми техниками, объединяющими перспективы «обучения» и «оптимизации». Lokad уже давно движется по этому пути. Фактически, с тех пор как мы перешли на вероятностное прогнозирование в 2015 году, экспортирование сырых прогнозов из Lokad считалось непрактичным, сводя процесс для клиента к одноступенчатому. Однако двуступенчатый процесс всё ещё существует внутри Lokad, поскольку остаются глубокие, ещё не решённые проблемы, мешающие унификации.
Теперь давайте обсудим мои взгляды на недостатки техники DIM.
Моя первая критика заключается в том, что использование глубокого обучения в DIM оставляет желать лучшего.
Из раздела Фичеризация (Приложение B) очевидно, что основной задачей «глубокой» модели является прогнозирование будущего спроса в период поставки — то есть изменяющегося спроса, накопленного за изменяющимся сроком поставки.
(Неявно вероятностная) оценка спроса в период поставки не является «сложной» задачей, требующей глубокого обучения, по крайней мере, в условиях, представленных этой командой из Amazon. Фактически, я полагаю, что всё эмпирическое улучшение является следствием более качественной оценки спроса в период поставки. Кроме того, я бы предположил, что сопоставимая, если не лучшая, оценка спроса в период поставки может быть получена с помощью базовой параметрической вероятностной модели, как это было сделано в конкурсе M54. Это полностью исключило бы необходимость глубокого обучения, оставив лишь часть решения на основе «поверхностного» дифференцируемого программирования.
Если отложить оценку спроса в период поставки, DIM мало что может предложить. Действительно, в условиях, описанных в статье, все SKU обрабатываются почти изолированно, при наличии слишком мягких общекорпоративных ограничений — а именно ограничений по общему объёму, общему капиталу и общему количеству единиц. Решение этих ограничений можно выполнить достаточно легко, сортируя единицы для повторного заказа5 по убыванию их доходности в долларах — или, возможно, их доходности на единицу — если узким местом является истинный барьер, представленный хаотичным складским хранением, используемым Amazon.
Что касается ограничений, корпоративные лимиты являются тривиальными и для их решения не требуются сложные методики. Глубокое обучение действительно могло бы блеснуть, если бы авторам удалось решить проблему с жесткими ограничениями, которые присутствуют в цепочках поставок. Например, Минимальные объемы заказа на уровне поставщика, полные загрузки грузовиков, ценовые скидки от поставщиков, скоропортящиеся товары и т.д. — всё это проблемы, которые нельзя решить примитивной техникой, такой как приоритизация, о которой я упоминал выше. Для таких жестких ограничений глубокое обучение действительно могло бы проявить себя как универсальный стохастический оптимизатор – при условии, что кому-то удастся это сделать. Однако DIM полностью игнорирует эти вопросы, и совершенно неясно, можно ли расширить DIM для работы с подобными проблемами. На мой взгляд, это невозможно.
Надо отдать должное авторам: межпродуктовые ограничения упоминаются в самой последней строке их заключения как интересное направление для исследований. Хотя я и разделяю это мнение, оно недостаточно выразительно. Невозможность учесть эти вездесущие ограничения в цепочках поставок является немедленным препятствием. Специалисты по цепочкам поставок вернутся к своим таблицам менее чем за месяц. Приблизительно правильное лучше, чем совершенно неправильное.
Более того, возникает целая куча проблем с действиями с вещественными значениями, то есть с дробными количествами заказа, которые генерирует DIM – см. уравнение (1) и Предположение 1 (страница 12). Действительно, в цепочках поставок невозможно пополнить запасы 0.123 единицы товара — это либо 0, либо 1. Тем не менее, авторы обходят этот вопрос. Техника DIM выдаёт дробные количества и требует, чтобы функция вознаграждения была «хорошо устроенной». На практике очевидно, что этот подход не будет работать хорошо, если функция вознаграждения не является строго монотонной по отношению к заказанному количеству.
Таким образом, мы сталкиваемся с нежелательной особенностью (дробными заказами) и нежелательным требованием (монотонности функции вознаграждения), сочетание которых является краеугольным камнем предлагаемого дифференцируемого симулятора. Однако в цепочках поставок действует закон малых чисел6. Современные задачи управления запасами доминируются за счёт своей дискретной природы. По крайней мере, этот аспект следовало бы выделить как серьёзное ограничение DIM — тему для дальнейших исследований.
Смешение градиентов и дискретных политик является фундаментальной проблемой стохастической оптимизации, а не только предлагаемыми дифференцируемыми симуляторами. Действительно, стохастический градиентный спуск (SGD) работает с вещественными параметрами, и, как таковой, неочевидно, как оптимизировать политики, управляющие по своей сути дискретными решениями.
Работа в принципиально дискретных пространствах с использованием градиентных методов, безусловно, возможна, как блестяще продемонстрировали большие языковые модели (LLM), но это требует целого набора хитростей. Пока эквивалентные приёмы не будут найдены для тех ситуаций, с которыми сталкиваются цепочки поставок, дифференцируемые симуляторы остаются перспективной идеей, а не готовым к производству решением.
Моя вторая критика заключается в том, что существует масса крайних случаев, о которых даже не упоминают авторы DIM.
В частности, авторы остаются чрезвычайно расплывчаты в том, как они отобрали (…предвзятый выбор) свои 10,000 SKU. Действительно, когда я проводил эксперименты в Lokad в 2018 и 2019 годах, я использовал поразительно похожие стратегии фичеризации (Приложение B) для моделей глубокого обучения, применяемых в Lokad.
Основываясь на этих экспериментах, я предполагаю, что:
- Новые и недавние продукты будут работать неэффективно, поскольку масштабирование, подразумеваемое уравнениями (13), (30) и (31), будет вести себя нестабильно при недостатке исторических данных.
- Медленно продающиеся товары столкнутся с неадекватными корректировками их прошлых дефицитов товара, так как техника предполагает наличие «разумного» откорректированного спроса (что не имеет места для медленно продающихся товаров).
- Прерывистые продукты (неопубликованные или недоступные в течение длительных периодов, например, более 2 месяцев) также столкнутся с проблемами из-за предполагаемого корректированного спроса.
- SKU конкурентов, где покупатели активно выбирают самую низкую цену, будут недооценены, поскольку модель не может отразить резкое влияние, когда SKU обгоняют конкурентов по цене.
Такие крайние случаи составляют, собственно, основную проблему цепочек поставок. В статье заманчиво выбирать только те SKU, которые ведут себя стабильно: не слишком новые, не слишком медленные, не слишком хаотичные, не прерывистые и т.д. Однако, если приходится прибегать к сложным техникам, то сосредоточение на простых SKU оказывается несколько бессмысленным. Хотя экономическая эффективность может быть достигнута для этих SKU, абсолютный выигрыш невелик (в лучшем случае скромен) — именно потому, что эти SKU и так ведут себя стабильно. Основная масса неэффективности в цепочках поставок заключается в крайних значениях, а не в среднем.
Прямое решение проблем с некорректно ведущими себя SKU — именно то, где от глубокого обучения можно ожидать спасения. Увы, DIM делает наоборот и решает задачи для стабильно ведущихся SKU, для которых можно использовать значительно менее сложные техники с минимальными или отсутствующими негативными последствиями.
Моя третья критика заключается в том, что у DIM несколько запутанная техническая архитектура.
Это, пожалуй, одна из самых недооценённых проблем в сообществе специалистов по цепям поставок. Сложность — враг надёжности и эффективности. Хотя глубокое обучение великолепно, немногие компании могут позволить себе инженеров, необходимых для эксплуатации системы типа DIM. Это не похоже на ChatGPT, где все инженерные хитрости распределяются между всей клиентской базой поставщика программного обеспечения. Здесь, учитывая количество специфики, входящей в DIM, каждая клиентская компания вынуждена нести полные эксплуатационные затраты, связанные с их собственной инстанцией решения.
Что касается аппаратной части, у нас имеется виртуальная машина EC2 p3.16xlarge7, в настоящее время оценённая в 17k USD в месяц на AWS. Для 10,000 SKU это… дорого.
У Lokad много клиентов, которые управляют миллионами SKU, и большинство из них имеют оборот менее 1 млрд USD. Хотя возможно немного уменьшить размер этой виртуальной машины и отключать её, когда она не используется, в Lokad мы выяснили, что такие опции редко подходят для производственных условий.
Например, облачные вычислительные платформы сталкиваются с собственными дефицитами: иногда виртуальная машина, предназначенная для немедленного запуска, появляется в сети спустя часы. Также никогда не следует предполагать, что эти модели можно просто «предобучить» — наступит день, например, в следующий вторник, когда всю систему придётся переобучать с нуля по неотложным причинам8. Более того, производственная система должна предусматривать не только избыточность, но и дополнительные окружения (тестирование, предпроизводство и т.д.).
Что касается программного обеспечения, необходимость в чем-то вроде Plasma Object Store является типичным примером неизбежных осложнений, сопряжённых с глубоким обучением. Допустим, обучающий набор данных, содержащий 80,000 SKU еженедельно, агрегированных за всего 104 недели, должен весить менее 100 МБ (если данные представлены разумно).
Хотя авторы DIM искусно расплывчаты, ссылаясь на «большое количество данных» (страница 32), очевидно, что стратегия фичеризации увеличивает исходный объём данных в 3 порядка (примерно в 1000 раз). Учтите, что EC2 p3.16xlarge обладает не менее чем 488 ГБ RAM, чего должно хватить для обработки набора данных весом 100 МБ (примерно 100 ГБ после учёта увеличения объёма)… Знаю по опыту: и там, и тут сталкивались с подобной проблемой.
Например, реалистичный набор данных по цепочкам поставок обычно превышает 1 терабайт после увеличения объёма данных — что требуется согласно подходу DIM. В этом случае типичный специалист по данным не сможет воспроизвести ошибку на локальной машине, так как у их рабочей станции всего 64 ГБ RAM. Кроме того, существует ещё вопрос о границе взаимодействия Python с Plasma, где могут возникать проблемы.
Помимо основных критических замечаний, существуют и второстепенные проблемы. Например, динамическое программирование9 — упоминаемое во введении и заключении как базовый метод и конкурент DIM — является просто слабой базой. Динамическое программирование — это древняя техника (начиная с 1950-х годов) и не отражает современные достижения в области объединения оптимизации и обучения.
Конечно, литература по цепочкам поставок в этом плане недостаточна, но это означает, что авторам приходится искать релевантные базовые методы за пределами их области исследований. Например, AlphaGo Zero10 является намного лучшей интеллектуальной базой, когда речь идёт о выдающемся применении глубокого обучения для оптимизации, особенно по сравнению с методами динамического программирования, которым почти 80 лет.
В заключение, вопреки тому, что может показаться по моей критике, эта статья лучше, чем большинство, и абсолютно заслуживает критического анализа. Дифференцируемое программирование — отличный инструмент для цепочек поставок. Lokad использует его уже много лет, но мы ещё не исчерпали всех возможностей, которые предоставляет эта программная парадигма.
Есть ещё многое, что можно исследовать, как демонстрирует DIM. Дифференцируемые симуляторы — это классная идея, и становится не так одиноко, когда такие технологические гиганты, как Amazon, бросают вызов основным догмам традиционной теории цепочек поставок — точно так же, как и мы. В Lokad у нас есть проект, который, так или иначе, совмещает montecarlo и autodiff11 таким образом, что они прекрасно вписываются в концепцию дифференцируемых симуляторов.
Следите за обновлениями!
-
Глубокое управление запасами, Dhruv Madeka, Kari Torkkola, Carson Eisenach, Anna Luo, Dean P. Foster, Sham M. Kakade, ноябрь 2022. ↩︎
-
Состязательный подход к исследованию рынка программного обеспечения, Лекция: Joannes Vermorel, март 2021. ↩︎
-
Награда за действие: фреймворк для оптимизации запасов, Gaëtan Delétoile, март 2021. ↩︎
-
Первое место на уровне SKU в соревновании по прогнозированию M5, Лекция: Joannes Vermorel, январь 2022. ↩︎
-
Распределение запасов в розничной сети на основе вероятностных прогнозов, Лекция: Joannes Vermorel, май 2022. ↩︎
-
Количественные принципы для цепочек поставок, Лекция: Joannes Vermorel, январь 2021. ↩︎
-
Мощный сервер, арендованный онлайн у Amazon, с 8 высокопроизводительными профессиональными GPU и примерно в 15 раз большим объёмом оперативной памяти, чем у типичной высокопроизводительной настольной рабочей станции. ↩︎
-
“SCO — не обычный программный продукт” в Ориентированной на продукт доставке для цепочек поставок, Лекция: Joannes Vermorel, декабрь 2020. ↩︎
-
Динамическое программирование следовало бы назвать «структурированной мемоизацией». Будучи низкоуровневой алгоритмической техникой, оно по-прежнему актуально, но эта техника даже не относится к той же области, что и обучение с подкреплением. Структурированная мемоизация как техника принадлежит к базовым, фундаментальным алгоритмическим приёмам, таким как сбалансированные деревья или разрежённые матрицы. ↩︎
-
Овладение шахматами и сёги через самообучение с использованием общего алгоритма обучения с подкреплением, David Silver, Thomas Hubert, Julian Schrittwieser, Ioannis Antonoglou, Matthew Lai, Arthur Guez, Marc Lanctot, Laurent Sifre, Dharshan Kumaran, Thore Graepel, Timothy Lillicrap, Karen Simonyan, Demis Hassabis, декабрь 2017. ↩︎
-
Оба блока, montecarlo и autodiff, являются специальными программными блоками в Envision, поддерживающими случайные и дифференцируемые процессы соответственно. Сочетание этих двух блоков по сути даёт нечто, очень близкое к строительным блокам, которые требуются для дифференцируемого симулятора. ↩︎