Обзор статьи "Как генеративное искусственное интеллект улучшает управление цепями поставок"

Джоаннес Верморель

В январе-феврале 2025 года Harvard Business Review опубликовал статью под названием Как генеративное искусственное интеллект улучшает управление цепями поставок¹ авторства Ишая Менахе (Microsoft), Дживана Патури (Microsoft), Дэвида Симчи-Леви (профессор MIT) и Тома Линтона (McKinsey). Как следует из названия, статья приводит ряд примеров, предположительно иллюстрирующих, как LLM (большие языковые модели) могут способствовать управлению цепями поставок. Учитывая список элитных организаций (Microsoft, McKinsey, MIT и даже Harvard), участвующих в публикации этой статьи, можно было бы ожидать глубоких исследовательских взглядов, которые тщательно аргументируют, как блестящая технология - LLM - будет способствовать улучшению цепей поставок.

Вместо этого мы получаем посредственный вклад. Более точно: это ленивый, гиперболический и глубоко заблуждающийся материал, который случайно использует модное технологическое словосочетание. Вся предпосылка статьи может быть суммирована как LLM может как генерировать, так и объяснять код, имеющий отношение к цепям поставок. Авторы принимают то, что я обычно называю гаджетоидным подходом к теме. Гаджетоидный подход состоит в том, что при обнаружении новой технологии быстро присоединяют ее к существующей системе. Это обычно делается без учета ограничений самой технологии или изменений, которые будут внесены в систему. В результате этот подход неизменно приводит к созданию гаджетов - забавных инструментов ограниченного интереса и без какой-либо деловой ценности.

Различным организациям, участвующим в этом:

• Microsoft: у вас есть много талантливых инженеров. Вам нужно придерживаться более высоких стандартов.

• McKinsey: не направляйте потенциальных клиентов в направления, которые обязательно окажутся пустой тратой времени и денег.

• MIT и Harvard: вы должны быть голосами разума и не усиливать ерунду технических поставщиков.

Давайте сразу проясним, что хотя я согласен с тем, что LLM могут использоваться для улучшения цепей поставок, LLM также могут быть полной отвлекающей фигней - в зависимости от того, как подходится к этому делу. Этот момент является фундаментальной проблемой, которая преследует рассматриваемую статью. Также страдает от этой проблемы тесно связанная статья от Microsoft²; хотя ради ясности, мой обзор будет сосредоточен на статье Harvard.

Прежде чем затронуть ядро технологического бессмыслицы, давайте отметим заметную этическую проблему. Эта статья - не более чем тонко замаскированная реклама Microsoft Cloud Supply Chain. Microsoft, конечно, вправе рекламировать свои услуги так, как считает нужным, но привлечение как Harvard (через публикацию), так и MIT (через соавторство) к рекламному материалу вызывает у меня неприятные ощущения. По крайней мере, статья должна указывать на то, что соавторы имеют явные конфликты интересов. Академия не должна одобрять скрытую рекламную деятельность технических поставщиков, независимо от их масштаба и влияния.

Отказ от ответственности: Внимательный читатель уже понял, что у меня тоже есть конфликт интересов. Да, я владею компанией по разработке программного обеспечения для управления цепями поставок и, таким образом, имею личный интерес в опровержении глупостей, которые распространяют Microsoft, McKinsey, MIT и Harvard. Мои карты теперь на столе.

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

Планировщики также отслеживают изменения в плане спроса, называемые дрейфом спроса, ежемесячно, чтобы убедиться, что пересмотренный план соответствует всем требованиям клиентов и вписывается в бюджетные рекомендации […] Теперь все это делает технология на основе LLM. Она автоматически генерирует отчет по электронной почте, в котором указывается, кто сделал каждое изменение и по какой причине.

Вкратце, LLM-ы могут автоматизировать работу сотрудников. Однако есть две очевидные возражения. Во-первых, для выполнения такого рода политики, связанной с ролями, LLM-ы совершенно не нужны. Достаточно простого языка программирования и нескольких императивных операторов. Кроме того, все равно потребуется программное обеспечение для доступа к данным и отправки электронной почты. В таких ситуациях LLM-ы гарантированно представляют собой огромную инженерную сложность, не приносящую осязаемых преимуществ. Действительно, LLM-ы очень медленные и очень дорогостоящие; примерно на 10 порядков хуже простого списка правил. Они являются инструментом, который следует использовать в крайнем случае, когда все остальное не сработало. В данном случае это явно не так.

Во-вторых, вышеупомянутая ненужная работа совершенно излишня. Компания должна устранить этот класс бессмысленных задач[^бюрократии]. Бюрократии уже достаточно плохи, но технократии еще хуже. Привлечение чрезмерно сложных технологий на вечеринку гарантирует, что бюрократия будет еще более закреплена в своих дисфункциональных методах. Моя компания, Lokad, уже более десяти лет устраняет эту работу с помощью рефакторинга и не требует ничего такого сложного и дорогостоящего, как LLM-ы.

В этих контрактах указываются детали цены, уплачиваемой OEM, требования к качеству, сроки поставки и меры устойчивости, которые должны принимать поставщики, чтобы обеспечить поставку. После того, как LLM получил данные из тысяч контрактов, один OEM смог определить снижение цены, на которое он имел право за превышение определенного порога объема.

Хотя правда, что компании регулярно не соблюдают некоторые контрактные условия с поставщиками, которые могли бы принести им пользу, определение соответствующих контрактных условий является лишь микроскопической частью задачи - скажем, 1% или возможно даже меньше. Более того, это можно сделать с помощью инструмента, такого как ChatGPT, без какой-либо подготовки. Достаточно составить запрос и многократно отправить все PDF-файлы через пользовательский интерфейс. Этот род мелочей относится к записи в LinkedIn под названием “10 вещей, которые я сделал с помощью ChatGPT сегодня”, а не к публикации Гарвардско-Массачусетского технологического института.

Теперь реальная проблема двоякая: инструментация и отношения. На стороне инструментации, административные шаги по выдаче заказов и платежам в большинстве компаний, управляющих чем-то, что можно назвать “цепочкой поставок”, в значительной степени автоматизированы. Таким образом, если нет обширной поддерживающей инструментации, работа с крайними случаями будет усложнена и затянется.

Более того, с точки зрения отношений, если контрактное условие было игнорировано в течение многих лет, то наивно думать, что компания может активировать это условие без последствий. В большинстве случаев поставщик уже учел эту небрежность клиента в своих ценах, и занудство по поводу мелких контрактных условий будет отвечено тем же - или, возможно, повышением цены.

Более общим образом, скидки и снижение цен должны управляться как часть обычных транзакционных бизнес-систем. Это не ракетная наука, а простая старая CRUD³. Еще раз, привлечение LLM там, где достаточно нескольких императивных правил, является технологическим бессмыслицей.

LLM позволяет планировщикам задавать детальные вопросы. Вот несколько примеров: “Каковы будут дополнительные транспортные расходы, если общий спрос на продукцию увеличится на 15%?” […] Вот как LLM может точно и эффективно отвечать на такие вопросы. Многие задачи оптимизации записываются в виде математических программ […] LLM […] преобразует человеческий запрос в математический код, который является небольшим изменением исходной математической модели, используемой для составления плана.

Это мечтательное мышление. До сих пор процент компаний, пользующихся “единым монолитным кодовым базисом” для получения своих решений по цепочке поставок, практически нулевой (подробнее об этом ниже). Вместо этого у компаний есть огромное количество электронных таблиц. В отличие от красивой картины, которую рисуют авторы, нет “математических программ”, с которыми можно взаимодействовать для LLM. Хотя LLM, концептуально, могли бы редактировать и улучшать грязную кучу полуустаревших электронных таблиц, до тех пор, пока не будет доказано обратное, это чистая домыслы. Даже передовые LLM будут испытывать трудности с редактированием одной большой электронной таблицы - пассивное дублирование кода, которое сопровождает электронные таблицы, совсем не подходит для LLM, но разобраться с сотнями, а то и тысячами таблиц - это чистая научная фантастика на данный момент.

Тем не менее, есть несколько компаний, которые получают выгоду от единого монолитного кодового базиса, управляющего процессами принятия решений в цепочке поставок - а именно клиенты Lokad. Если бы авторы, как и мы, имели хоть какой-то опыт в этой области, они бы знали, что эти кодовые базисы имеют значительный размер; обычно десятки тысяч строк кода, несмотря на то, что мы используем DSL (язык, специфичный для предметной области)⁴, посвященный цепочке поставок. Кстати, этот DSL в 10 раз более лаконичен, чем Python или Java для таких задач. К сожалению, нет никаких сокращений: для любого интересующего решения существует десятки таблиц, охватывающих сотни полей, которые участвуют в расчете. Хотя можно представить, что дальнейшие улучшения нашего DSL могут сократить количество строк кода, эти кодовые базисы никогда не будут маленькими.

Опять же, LLM, концептуально, могли бы редактировать и улучшать сложный кодовой базис под руководством неспециалиста. Однако мы снова находимся в области научной фантастики. LLM уже доказали свою эффективность как инструменты продуктивности для опытных программистов. Другими словами, если вы уже умеете программировать, LLM могут помочь вам программировать быстрее. Но это не то, что говорят авторы статьи. Их предложение заключается именно в том, что LLM могут использоваться для того, чтобы непрофессиональные участники вносили технические вклады. Исходя из текущего состояния искусства LLM, это предложение неизбежно ложно, за исключением ограниченных песочниц, которые не отражают огромной сложности реальных цепочек поставок в мире.

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

Авторы продолжают развивать научную фантастику. Это утверждение технически неразличимо от “LLM может выпускать патчи для репозитория кода на GitHub на основе заявок, поданных неспециалистами”. Было бы замечательно, если бы это было возможно, но современные LLM далеки от того, чтобы надежно выполнять такого рода серьезные запросы. При представлении примеров использования новой технологии крайне важно точно передать ограничения этой технологии. Четыре соавтора, кажется, полностью не знают о современном состоянии искусства LLM, но у меня есть подозрение, что это не так. Вместо этого мы получаем информационный мусор от людей, которые отлично понимают, что они делают - что, безусловно, гораздо хуже.

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

Определение, является ли время выполнения заказа аномальным, абсолютно не входит в компетенцию LLM. Однако LLM могут быть попрошены написать код для выполнения этого анализа. Мы возвращаемся к публикации в LinkedIn “Топ-10 вещей, которые я сделал с ChatGPT сегодня”. Почему бы не обновить логику заказа там, где используется информация о времени выполнения заказа? Именно это авторы предлагают позже в статье.

Мы предвидим, что в ближайшие годы технология на основе LLM будет поддерживать сценарии принятия решений от начала до конца.

Если под “поддержкой” авторы подразумевали “повышение производительности программистов” - программистов, ответственных за кодирование принятия решений от начала до конца, - то это уже возможно - фактически, Lokad занимается этим уже некоторое время. Однако, если мы исключим человеческих программистов из этой картины, то эта фраза становится ближе к “мы предвидим, что в ближайшие годы технологии на основе LLM достигнут ИИ общего назначения (AGI)”.

Авторы, упорно придерживаясь модного словосочетания “Gen AI”, полностью игнорируют возможные ограничения LLM. Вот что авторы предлагают в своем заключительном разделе “Преодоление барьеров”:

Принятие и обучение. Для оптимизации цепей поставок с использованием LLM требуется очень точный язык […] Каждая интерпретация приводит к разным решениям.

Нет, это абсолютно неверно - если только “очень точный язык” понимать как “язык программирования” (поскольку они действительно очень точные). Чтобы оптимизировать цепь поставок с использованием LLM, вам нужен человеческий инженер, способный делать программирование полностью самостоятельно, хотя и медленнее. В ближайшем будущем никакое количество обучения, кроме овладения программированием, не сделает пользователей способными выполнять оптимизацию цепи поставок с поддержкой LLM.

Сказать генеральному директору или директору цепи поставок, что ему просто нужно обучить свою команду использовать “точный язык”, - это полная заблуждение. Тренировочные семинары, которые могли бы возникнуть из этой точки зрения, гарантированно будут полной пустой тратой времени для всех заинтересованных сторон.

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

Хотя LLM по своей природе являются вероятностными, эта проблема затмевается семантической неопределенностью, которая проникает в системы цепей поставок. Другими словами, LLM очень вероятно даст вам правильный ответ на неправильную проблему. Опыт Lokad показывает, что часто единственный способ проверить, является ли данная реализация (управляющая принятием решения в цепи поставок) правильной, - это провести ограниченное экспериментальное тестирование⁵. Обратная связь из реального мира не является вариантом. Знания нельзя создать из воздуха - даже LLM уровня AGI все равно столкнутся с этим препятствием.

Здесь авторы попадают в ловушку “заполнения пробелов”. Они делают правильное, но тривиальное заявление о природе LLM, даже не пытаясь выяснить, является ли проблема ключевой или нет. Если бы авторы действительно управляли реальными цепями поставок с использованием LLM, они бы поняли, как и мы, что эта проблема является маленькой проблемой в длинном списке гораздо более серьезных и влиятельных проблем.

В заключение, здесь применим закон Брандолини: Количество энергии, необходимое для опровержения чушки, в десять раз больше, чем для ее производства. Эта статья настолько плоха, что могла быть написана ChatGPT - и, возможно, была написана им, насколько я знаю. Основываясь на моих поверхностных наблюдениях, каждый день производится десятки одинаково плохих статей о Gen-AI и SCM. Известность авторов побудила меня написать этот обзор. Однако, это не первый случай, когда продавец обещает революционизировать область, не имея ничего существенного для предложения. Тем не менее, один и тот же продавец делает это дважды⁶ два года подряд в одной и той же области, что может быть чрезмерным. Впрочем, академия должна хотя бы попытаться проявить критическое мышление, а не с радостью прыгать в вагон модных словосочетаний.