Общение с вашей цепочкой поставок не решит проблему
Спустя несколько дней появляется новая демонстрация: вы вводите вопрос на простом английском — «Что, если спрос в Германии внезапно вырастет?», «Что, если мы закроем этот завод?», «Что, если мы поменяем поставщиков?» — и ассистент уверенно отвечает обновлённым планом, кратким объяснением и аккуратным списком следующих действий. Предложение неотразимо: цепочка поставок наконец становится разговорной. Планирование, наконец, становится беспрепятственным. Оптимизация, наконец, становится доступной.
В своей книге Введение в цепочку поставок (см. главу 6, особенно разделы, посвящённые «общему интеллекту» и наследию ОР) я утверждал, что цепочка поставок — это дисциплина, которая неоднократно принимает стильные интерфейсы за прогресс. Этот аргумент имеет особое значение сейчас, поскольку крупные языковые модели (LLM) позиционируются — как серьёзными исследователями, так и надёжными поставщиками — как недостающее звено, которое, наконец, свяжет математику с операциями и планирование с реальностью.
Что на самом деле разрабатывает сообщество
Сообщество операционных исследований последовательно требует от LLM одного: универсального переводчика между человеческими намерениями и математическими механизмами.
Серия соревнований NL4Opt на NeurIPS чётко определяет цель: повысить «доступность и удобство использования оптимизационных решателей», позволяя неспециалистам формулировать задачи на естественном языке, а затем генерируя артефакты моделирования (включая код для ЛП и ЦП), которые решатели могут использовать. Это не маргинальная идея; она формализуется в виде контрольных заданий, наборов данных, метрик оценки и конкурсных структур с призами.
OptLLM продвигает ту же идею с исследовательской стороны в рамках сквозного рабочего процесса: пользователь формулирует задачу оптимизации на естественном языке; система преобразует её в математические формулировки и программный код; затем она вызывает внешний решатель и посредством многораундового диалога уточняет модель. Другими словами: английский → математика → код → решатель → результаты → английский, при этом LLM организует весь цикл.
Глава INFORMS’ 2024 TutORials, подготовленная Вассеркругом, Буссиу и Суном, предлагает более широкий, ориентированный на практику взгляд: LLM могут ускорить создание и внедрение решений в области ОР/МС за счёт (i) сокращения времени разработки при одновременном повышении качества решений, (ii) извлечения структурированных данных из неструктурированного текста без создания специализированных моделей NLP (при этом они явно упоминают прогнозирование спроса как мотивирующий кейс) и (iii) обеспечения интерфейсов на естественном языке, чтобы бизнес-пользователи могли гибко взаимодействовать с аналитическими моделями. Глава примечательна не только оптимизмом, но и акцентом на ответственном использовании: LLM представлены как мощные инструменты, но инструменты, требующие управления и ответственности.
Тем временем направление «обучение оптимизации» также интегрирует LLM — не только в качестве «интерфейсов», но и как компоненты самой экосистемы решателей. Амбиция «фундаментальной модели» появилась в MILP: исследователи Microsoft предлагают обучать единую модель для различных классов MILP и представляют MILP‑Evolve — эволюционную систему на базе LLM, которая генерирует большие, разнообразные классы MILP-задач «с неограниченным числом экземпляров», поддерживая задачи типа обучения ветвлению и согласования экземпляров MILP с описаниями на естественном языке. Обзор 2025 года по LLM для эволюционной оптимизации идёт дальше и категоризирует появляющиеся парадигмы: LLM как самостоятельные оптимизаторы, LLM, встроенные в алгоритмы оптимизации, и LLM, применяемые на более высоком уровне для выбора и генерации алгоритмов — с явным указанием на «саморазвивающиеся агентские экосистемы» для оптимизации.
Со стороны планирования цепочек поставок предложения почти идеально созвучны с повесткой ОР — но с другим акцентом: не «сделать решатели доступными», а «сделать планировщиков быстрыми».
Статья MIT Sloan Executive Education 2025 года о LLM в планировании цепочек поставок является показательным примером. В ней описываются планировщики, задающие сложные гипотетические вопросы на естественном языке; LLM переводит запрос в математические корректировки и возвращает понятные человеку инсайты. Утверждается, что то, что ранее требовало «дней» постоянных консультаций с инженерами, может стать «минутами», и обещание распространяется на «реальное время» при возникновении сбоев: планировщики могут «динамически корректировать математические модели» без помощи IT-команд и повторно запускать оптимизацию для получения обновлённых планов, объясняемых простым языком. При этом в статье, почти в сторону, признаётся основная сложность: валидация — обеспечение того, чтобы корректировки, сгенерированные ИИ, соответствовали реальным бизнес-условиям — остаётся проблемой.
Симчи-Леви, Меллу, Менаш и Патхури (2025) явно выдвигают тезис о «демократизации»: планировщики и руководители в настоящее время тратят слишком много времени на понимание результатов, запуск сценариев и обновление моделей, поэтому LLM могут «демократизировать технологии цепочки поставок», облегчая понимание и взаимодействие «без участия человека», сокращая время принятия решений с «дней и недель» до «минут и часов».
Проект OptiGuide от Microsoft Research находится именно на этом пересечении ОР и планирования: он нацелен на «демократизацию процесса принятия решений» посредством сочетания оптимизации с генеративным ИИ и заявляет о промышленном применении для облачных планировщиков цепочек поставок, отвечающих на вопросы «что, если» и получающих действенные рекомендации.
Поставщики программного обеспечения, неудивительно, сошлись на одних и тех же темах: помощники, агенты, запросы на естественном языке и более быстрые решения.
SAP позиционирует Joule как генеративного ИИ-помощника, интегрированного в корпоративные приложения, включая цепочку поставок, а специализированные страницы SAP IBP подчёркивают разговорный доступ к документации по продукту (более удобный способ поиска и получения рекомендаций) и интеграцию Joule с SAP IBP. В примечаниях к релизу сообщества SAP для IBP упоминается интеграция Joule как инновация в этой линейке релизов.
Анонсы Oracle 2025 года подчёркивают «агентов ИИ», встроенных в Oracle Fusion Cloud Applications. Для цепочки поставок Oracle заявляет, что эти агенты автоматизируют процессы, оптимизируют планирование и выполнение, а также ускоряют принятие решений; они даже приводят в пример таких агентов, как советник по планированию по исключениям и заметкам, который суммирует оповещения и комментарии. Также в документации Oracle по готовности описывается агент «Советник по процессу планирования цепочки поставок», построенный на базе LLM + RAG, который отвечает на вопросы планировщиков о распределении обязанностей, ежедневных задачах и процессах эскалации, основываясь на корпоративных документах, загруженных клиентом.
Пресс‑релиз Blue Yonder ICON 2025 представляет «агентов ИИ» и «граф знаний цепочки поставок», утверждая, что агенты позволяют бизнесу «видеть, анализировать, принимать решения и действовать» с машинной скоростью, и что агентский ИИ пронизывает как планирование, так и выполнение.
Kinaxis описывает агентские и генеративные возможности ИИ, которые снижают барьеры для взаимодействия с данными цепочки поставок — запрос «цифрового двойника» на естественном языке и получение ответов — а в публичных материалах и независимых аналитических обзорах описывает многоагентную систему, предназначенную для уменьшения зависимости от IT и предоставления планировщикам возможности напрямую взаимодействовать с операционными данными.
Компания o9 придерживается той же концепции под другим брендингом: «Агенты GenAI» плюс корпоративный граф знаний, который развивается в «большую модель знаний», рассматриваемую как качественный скачок в продуктивности и экспертизе планировочных функций.
Над всем этим стоит Gartner, который задаёт терминологию для данной категории. В пресс‑релизе за август 2025 года Gartner прогнозирует быстрое распространение AI‑ассистентов и специализированных агентов ИИ в корпоративных приложениях, определяет «этапы» эволюции агентского ИИ и предупреждает, что распространённое заблуждение заключается в том, что помощников называют «агентами» — недоразумение, которое они называют «agentwashing».
Таким образом, да: ведётся реальная работа. Контрольные показатели, фреймворки, агентские архитектуры, интеграции и масса инженерных решений, ориентированных на производство. Вопрос не в том, можно ли подключить LLM к инструментам цепочки поставок — они уже интегрированы. Вопрос в том, решает ли это подключение реальные причины, по которым принятие решений в цепочке поставок остаётся упорно посредственным.
Почему я не убеждён, что интерфейс является узким местом
Сообщество операционных исследований права в одном: оптимизацию сложно выразить чётко. Сообщество планирования также не ошибается в одном: люди тратят время, переводя вопросы в таблицы, электронные письма, на встречи, в заявки и в случайные изменения моделей. LLM может снизить это трение. Он может сократить путь между «я задумался…» и «вот вычисленный ответ», как описывает статья MIT Sloan.
Но цепочки поставок не терпят неудач, потому что у планировщиков нет более быстрого способа задавать вопросы.
Десятилетиями существуют решатели, языки моделирования и академические достижения. Утверждение, заложенное в NL4Opt — «сделать решатели удобными для неспециалистов посредством естественного языка» — подразумевает, что главная проблема — неспособность пользователя правильно сформулировать задачу. Это утешающая история для исследователей, так как она превращает запутанную организационную неудачу в задачу перевода. Однако, в цепочке поставок это утверждение в значительной степени ложно.
То, что препятствует реальному принятию, заключается не в том, что люди не могут ввести ограничения. Проблема в том, что ограничения, цели и семантика данных регулярно оказываются неправильными — или, точнее, они ошибочны в экономически значимых аспектах. Вы можете сгенерировать горы кода для моделирования, и при этом оптимизировать чепуху.
Это не новая критика. Рассел Аффок ещё в 1979 году утверждал, что ОР стал «контекстно наивным» и что его применение всё больше ограничивается задачами, относительно нечувствительными к окружающей среде. Цепочки поставок — это противоположность нечувствительности к среде. Они характеризуются волатильностью, эффектами замещения, отсутствием данных, задержанной обратной связью и стимулами, которые изменяют поведение, как только вы начинаете «оптимизировать».
Повестка LLM в ОР склонна недооценивать жестокую асимметрию: составить модель проще, чем её проверить. OptLLM может генерировать формулировки и код, а затем проводить итерационный диалог. Но настоящая сложность заключается не в создании ещё одного математического объекта, а в том, чтобы удостовериться, что объект соответствует реальным экономическим компромиссам компании, операционным ограничениям и измерительной реальности. LLM может создать правдоподобное ограничение; он не может засвидетельствовать, что это ограничение действительно отражает то, что испытывает ваш склад в 3 часа ночи во время акции, с реальным расписанием персонала, реальными правилами упаковки, реальными правилами пополнения запасов и реальными режимами сбоев.
В планировании та же асимметрия становится ещё более опасной, потому что культурный рефлекс — доверять плану. Статья MIT Sloan отмечает, что планировщики могут «динамически корректировать математические модели» без участия IT. Симчи-Леви и соавторы представляют это как устранение необходимости в командах data science и технологических поставщиках. Это преподносится как расширение возможностей. Я же вижу в этом обход того самого трения, которое раньше предотвращало неконтролируемое отклонение модели.
Если изменение модели происходит легко, организация будет постоянно её менять. Не потому, что это рационально, а потому что это психологически удовлетворяет. Каждое нарушение порождает новое исключение. Каждый вопрос руководства вызывает новый сценарий. Каждая встреча приводит к новой настройке, чтобы удовлетворить чью-либо интуицию. Да, это ускоряет процессы, но также ускоряет и энтропию.
Поставщики, что неудивительно, склоняются к «агентам», которые суммируют, объясняют и направляют. Советник по планированию Oracle по сути является слоем LLM+RAG поверх политик и процедур: он отвечает на вопросы на основе документов, которые вы загружаете, и интегрирует этот чат-опыт в страницы рабочих процессов. Позиционирование Joule от SAP в IBP аналогичным образом подчёркивает разговорный поиск и ответы, основанные на документации. Это законные функции, повышающие продуктивность. Они могут сократить время, затрачиваемое на поиск нужного процессного документа. Но они не изменяют существенно качество решений. В лучшем случае это просто улучшенная система помощи.
Затем переходим к более грандиозной истории «агентского» характера. Blue Yonder анонсирует несколько агентов ИИ, интегрированных в процессы планирования и выполнения, с целью непрерывной оптимизации и принятия решений с машинной скоростью. Kinaxis описывает агентские рамки, агентов ИИ, которые в режиме реального времени мониторят и действуют, а также взаимодействие с цифровым двойником на естественном языке. Gartner предсказывает мир, наполненный такими решениями, при этом предупреждая, что большая часть того, что продаётся как агенты, на самом деле являются ассистентами — «agentwashing».
Ирония в том, что предупреждение Gartner не является второстепенным; это центральный факт. Большинство этих «агентов» — это обёртки. Они располагаются поверх существующих рабочих процессов, автоматизируют фрагменты взаимодействия и делают интерфейс удобнее. Они не исправляют экономическую логику принятия решений и не решают фундаментальные вопросы достоверности данных, неопределённости и стимулов. Они могут уменьшить задержку принятия решений в узком смысле – когда кто-то нажимает быстрее, – но не в том глубоком смысле, что компания совершает меньше ошибок.
Даже более существенные академические интеграции — LLM + оптимизация сетей с панелями управления и объяснениями с учётом ролей — рассматривают основную проблему как «преодоление разрыва» между выводами ОР и пониманием заинтересованных сторон путём перевода результатов на естественный язык и представления контекстуальных KPI. Опять же: полезно. Но это сохраняет исходное предположение: модель правильна; людям просто нужно её понять. А в цепочке поставок модель зачастую является самой проблемой.
Так что, когда я слышу «LLM демократизируют оптимизацию», я перевожу это как: «мы демократизируем создание псевдомоделей». Когда я слышу «LLM позволят планировщикам обновлять модели без участия IT», я перевожу это как: «мы ускорим процесс, в котором хрупкие модели патчатся, снимаются с патча и снова патчатся». И когда я слышу «агентский ИИ будет координировать сквозные рабочие процессы», я спрашиваю: координировать к какой цели, на каких семантических основаниях и с какой ответственностью?
Где LLM могут быть действительно полезны
Ничто из этого не является аргументом для игнорирования LLM. Это аргумент против притворства, что беседа может заменить компетентность.
Глава OR/MS TutORials правильно подчёркивает, что LLM могут ускорить создание приложений для принятия решений, помочь преобразовывать неструктурированный текст в структурированные сигналы и обеспечить слои взаимодействия на естественном языке — при этом настаивая на ответственном использовании. Именно здесь LLM блестяще работают: не как движок принятия решений, а как множитель продуктивности для инженеров и аналитиков, создающих настоящий движок принятия решений.
Если вы используете LLM для быстрой разработки вспомогательного кода, генерации тестов, составления черновиков документации, извлечения неструктурированных бизнес-правил из контрактов и стандартных операционных процедур в структурированные представления, вы улучшаете ту часть процесса, которая действительно является узким местом: медленная, дорогая и подверженная ошибкам инженерия данных и логики. Если вы используете LLM для помощи аудиторам, руководителям и операторам понять, почему было принято вычисленное решение — предоставляя объяснения, основанные на прослеживаемых доказательствах, вы можете повысить принятие без утраты контроля.
Даже концепцию «демократизации» можно переосмыслить продуктивно. Утверждение OptiGuide о том, что его решение используется в производстве для планировщиков облачных цепочек поставок, отвечающих на гипотетические вопросы, не является тривиальным. Но ценность заключается не в том, что планировщик может общаться с оптимизатором. Ценность заключается в том, что компания с надежной основой оптимизации может создать более безопасный и удобный интерфейс — тот, который предоставляет нужные рычаги и объяснения, а не позволяет кому-либо небрежно переписывать базовую математику.
И да, программа обучения решателей — базовые модели для MILP, обученное ветвление и так далее — может принести истинные алгоритмические улучшения. Но цепочка поставок извлечет пользу от этих улучшений только если остальная часть стека будет в хорошем состоянии: правильная семантика, экономические цели, надежное управление неопределенностью и цикл выполнения, который надежно превращает рекомендации в действия.
Другими словами, относитесь к LLM так, как вы относитесь к любому мощному, но несовершенному инструменту: как к ускорителю для людей, создающих системы, а не как к слою лака на сломанных процессах. Используйте их для снижения затрат на строгость, а не для обхода тщательности.
Цепочка поставок не страдает от избытка слов. Ей не хватает хороших решений. LLM великолепно генерируют слова. Они могут помочь нам быстрее создавать лучшие системы. Но если мы будем путать красноречие с правильностью, мы просто получим ошибки, преподнесенные в лучшем стиле — и с большей скоростью.
