00:00:00 История создания Lokad и первые годы
00:02:31 Заблуждения о оптимизации цепей поставок
00:04:31 Существующие теории управления цепями поставок не работали
00:06:32 Парадокс неудач прогнозирования
00:08:33 Как “прогнозирование ничего” победило конкурентов
00:10:25 Вызов отказа от устоявшихся идей
00:12:00 Переход к вероятностному прогнозированию
00:14:07 Важность экстремальных сценариев спроса
00:16:32 Сложность интеграции данных предприятия
00:20:55 Почему модели цепей поставок на бумаге терпят неудачу
00:27:30 Проблемы инженерии в принятии предприятием искусственного интеллекта
00:35:00 Влияние COVID-19 на цепи поставок
00:42:49 LLM основаны на тексте, а не на математике
00:50:25 Параллельная эволюция финансовой отрасли
01:09:00 Вопросы и заключительные замечания
Резюме
Жоан Верморель, генеральный директор и основатель Lokad, выступил с лекцией на французском языке, поделившись своим путешествием в управлении цепями поставок. Верморель вспомнил о создании Lokad после окончания École Normale Supérieure и смене акцента с биоинформатики на вызовы цепей поставок. Он обсудил развитие Envision, языка программирования Lokad, и эволюцию компании с 2007 года. Верморель критиковал традиционные теории управления цепями поставок, сравнивая их с астрологией, и подчеркнул важность вызова консенсуса. Он выделил успех Lokad с вероятностными методами и влияние COVID-19 на роботизацию цепей поставок. Верморель предсказал устаревание традиционных ролей и побудил студентов к революции в отрасли.
Расширенное резюме
На лекции, прочитанной студентам на французском языке, Жоан Верморель, генеральный директор и основатель Lokad, поделился своим путешествием и идеями в мире управления цепями поставок и эволюции своей компании. Верморель начал с представления себя и вспоминания о происхождении Lokad, компании, которую он основал сразу после окончания École Normale Supérieure. Изначально Верморель пытался заняться диссертацией в области биоинформатики, но вскоре понял, что область уже насыщена талантливыми людьми. Случайно он наткнулся на вызовы управления цепями поставок, которые стали его новым фокусом.
Vermorel выразил свое удивление и восторг от того, что студенты из Центральной школы используют Envision, язык программирования, который он создал для оптимизации цепочки поставок. Он вспомнил разработку Envision, отметив, что первый компилятор, который он написал, был быстро заменен более совершенной версией, созданной Виктором Николе, техническим директором Lokad. Envision с тех пор значительно развился, и компания теперь на пороге выпуска версии 6.
Путешествие Lokad началось в 2007 году, а официально компания была основана в 2008 году. Однако Envision не был представлен до 2013 года, через пять лет после создания Lokad. Vermorel пояснил, что решение создать новый язык программирования пришло после исчерпания всех других альтернатив. Изначально он считал, что цепочка поставок - это устоявшаяся область с десятилетиями литературы и множеством конкурентов, таких как SAP, Oracle, IBM и Microsoft. Он думал, что ключ к успеху заключается в переупаковке существующих теорий цепочки поставок в веб-приложения, используя переход от клиент-серверных приложений к облачным решениям.
Несмотря на свою первоначальную уверенность, Vermorel вскоре обнаружил, что устоявшиеся теории и модели не работают так, как ожидалось. Он вспомнил особенно абсурдный опыт 2011 года, когда Lokad выиграл бенчмарк, представив нулевые прогнозы, которые превзошли конкурентов на 20% в точности. Этот опыт заставил Vermorel задать вопрос о действительности традиционных теорий цепочки поставок, сравнив их с астрологией, а не астрономией.
Vermorel подчеркнул важность вызова консенсуса в науке, отметив, что история полна примеров широко принятых, но в конечном итоге неверных убеждений. Он пришел к выводу, что хотя сама цепочка поставок является легитимной областью, классические теории, лежащие в ее основе, были ошибочными. Это осознание побудило его исследовать альтернативные подходы, такие как субъективные прогнозы и квантильные предсказания, которые оказались более эффективными.
Подход Lokad эволюционировал в сторону принятия вероятностных и программных методов, отходя от традиционных моделей, которые не справлялись с сложностями реальных проблем цепочки поставок. Vermorel подчеркнул важность наличия надежного языка программирования, адаптированного к этим вызовам, критикуя использование языков общего назначения, таких как Python, которые часто приводили к неудачным инициативам из-за различных технических проблем.
В лекции также затронули влияние пандемии COVID-19, которая ускорила роботизацию цепочек поставок. Vermorel отметил, что решения Lokad оказались эффективными на больших масштабах, управляя запасами на миллиарды евро с минимальным вмешательством человека. Этот сдвиг отражает переход в финансовой отрасли, где торговля стала в основном алгоритмической.
Vermorel обсудил будущее управления цепочками поставок, предсказывая, что традиционные роли менеджеров запасов и специалистов по прогнозированию спроса станут устаревшими по мере того, как все больше компаний примут автоматизированные процессы принятия решений. Он призвал студентов быть проактивными в том, чтобы стать двигателями этой революции, а не просто наблюдать за ней.
В ответ на вопросы студентов Vermorel пояснил, что компании с сильным технологическим уклоном могут внедрить решения Lokad внутрь, в то время как другие, вероятно, будут продолжать внешнюю поддержку этих услуг. Он также затронул ограничения больших языковых моделей (LLM) типа ChatGPT, отметив их недостаток обучения и памяти.
Vermorel завершил, отразив иррациональность рынков и упорство неудачных проектов в отрасли цепочки поставок. Он поделился анекдотами о конкурентах, которые повторно привлекали значительные средства, несмотря на прошлые неудачи, подчеркивая хаотичную природу рынка. Несмотря на эти вызовы, Vermorel выразил гордость за достижения Lokad и неожиданный успех Envision среди студентов престижных учебных заведений, таких как Центральная школа. Он пригласил студентов рассмотреть возможность присоединиться к Lokad, подчеркивая непрерывные усилия компании по найму.
Полный текст
Оригинальная речь на французском была переведена на английский.
Жоанн Верморель: Позвольте мне представиться: я Жоанн Верморель, основатель Lokad. Я создал компанию, когда закончил школу. Я учился в Эколь Нормаль Сюперьер, начал докторскую программу по биоинформатике, но в конце концов, столько людей занимались интересными вещами в области биоинформатики, что им, вероятно, не понадобилась я. И случайно я столкнулся с этими проблемами цепочки поставок. Мне очень приятно видеть, что вы сегодня использовали Envision. Для меня это довольно необычно оказаться перед студентами Центрального университета и говорить на этом языке. Это то, о чем я и не мечтал, когда создавал Envision, что было около двенадцати лет назад.
Я написал первый компилятор Envision, затем Виктор Николе—технический директор Lokad—выбросил его и быстро написал второй компилятор, который был намного лучше. И сейчас вы в основном используете версию 5, в то время как версия 6 собирается быть выпущенной. Язык сильно эволюционировал. Но то, над чем вы работали—то, что вы видели—вовсе не было тем, с чего начиналась Lokad. Это пришло довольно поздно, на самом деле. Lokad—это проект, который начался в 2007 году и был официально зарегистрирован в 2008 году, в то время как Envision появился примерно в 2013 году. Так что когда появился Envision, компании уже было около пяти лет.
Идея создания языка пришла после того, как мы исчерпали все другие альтернативы; это не был план видения основателя с самого начала—просто все остальное, что мы пытались, не сработало.
Чтобы дать вам представление о том, что такого удивительного в цепочке поставок: когда я запустил Lokad в 2008 году, мое мнение было, что цепочка поставок—это устоявшаяся область. Ведь есть 60 или 70 лет литературы по этому вопросу, буквально миллионы статей. Если вы введете “управление цепочкой поставок” на Amazon, вы получите—я проверил—около 10 000 книг, доступных в настоящее время по этой теме. За десятилетия было опубликовано еще много книг, но эти 10 000—те, которые сейчас еще продаются. Это очень документированная область.
Когда я начал, я видел крупных конкурентов с крупными именами: SAP, Oracle, IBM, даже Microsoft—ведущие игроки в цепочке поставок. Если сложить общий доход ваших конкурентов, это полтриллиона долларов. Это значительная сумма. Мое первоначальное предположение—полностью ошибочное, как оказалось—было в том, что я могу взять устоявшиеся теории цепочки поставок и просто переупаковать их в веб-приложение. Был 2008 год, и вся предприятийское программное обеспечение переходило от так называемых “толстых клиентских” приложений, которые устанавливаются на ваш ПК, к “тонким клиентам”, то есть веб-приложениям. Так появилась возможность перестроить программное обеспечение цепочки поставок как веб-приложение, возможно, с облачным хостингом. Lokad перешел в облако очень рано. Это могло дать нам преимущество перед крупными компаниями, которые все еще использовали устаревшие, более тяжелые клиентские системы. И поскольку буквально существуют целые книги, объясняющие, как оптимизировать цепочки поставок—как MIT-руководство, руководство Стэнфорда, руководство Калтеха—я их прочитал, все эти 1000-страничные тома, написанные двумя или тремя профессорами со всеми уравнениями.
Затем я закодировал эти подходы—и ничего не сработало. Интересно, что это не помешало Lokad расти или иметь клиентов. Может показаться, что для того чтобы заработать деньги как стартапу, вам нужен продукт, который действительно работает, но в предприятийском программном обеспечении вы можете продать что-то, что вообще не работает, и все равно найти клиентов. Это может показаться странным, но так оно и есть. Реальность в том, что если у компании есть большая проблема, которую она хочет решить, есть бюджет, чтобы попытаться ее решить. Этот бюджет может быть не очень большим—особенно если ваш продукт на самом деле не работает—но для стартапа эти суммы могут показаться очень крупными. Если гигант, например, Carrefour, выставляет на стол 100 000 евро “просто чтобы посмотреть”, это ничто для Carrefour, но для маленькой компании это много.
Используя эту асимметрию, я начал и попытался реализовать эти стандартные теории цепочки поставок: временные ряды прогнозирования, расчет резервного запаса, оптимизация уровня обслуживания и т. д. Ничего не сработало; совсем ничего. Мы вели эти довольно шизофренические дискуссии с клиентами: они говорили: “Вы, должно быть, неправильно закодировали формулу резервного запаса”, и мы возвращались, буквально брали значения из таблиц в учебниках, перепроверяли параметры - и все было точно так, как заявлено. Таким образом, теория была реализована правильно, но результат был абсолютно бессмысленным.
Я думаю, что апогеем бессмыслицы стало лето 2011 года. Мы участвовали в крупном запросе предложений с полдюжиной поставщиков программного обеспечения, половина из них европейцы, другая половина американцы. Lokad был среди европейцев. Как я помню, дело касалось десяти супермаркетов, 5 000 SKU на супермаркет, с необходимостью прогнозирования на несколько дней вперед, потому что эти супермаркеты пополнялись может быть два или три раза в неделю. Клиент использовал критерий ошибки обратного тестирования на ежедневные прогнозы уровня продукции для каждого магазина - в основном абсолютная ошибка между прогнозом и фактическим. Lokad оказался победителем в этом тесте - с точностью лучше на 20%, абсолютно разгромив конкурентов. Мой секретный метод? Я отправил назад нули. Ноль на все. Благодаря моему “нулевому прогнозу” я также обогнал всех в скорости расчета: возвращение нулей происходит очень быстро. И я получил точность прогнозирования лучше на 20% чем у других. Еще лучше, если вы прогнозируете нулевой спрос, вы не будете пополнять магазин, поэтому через две недели магазин опустеет, что соответствует вашему прогнозу на 100%. Я был королем статистики.
Очевидно, что это была полная ерунда. Но если рассмотреть подход, рекомендуемый всеми учебниками по цепочке поставок и стандартным процессом клиента, это приводило к полному абсурду. Вывод, который я сделал из этого, был довольно тревожным. У нас была прибыльная, растущая компания, но мне пришлось осознать, что я мог просто наткнуться на какую-то схему. Вы можете начать что-то, зарабатывать деньги, но это чистая ерунда. Возможно, сначала вы просто слишком неопытны, чтобы это осознать. Но как только вы осознаете, продолжаете ли вы? Когда вы заканчиваете учебу и понимаете, что делаете ерунду, продолжаете ли? Это вызвало глубокие вопросы. Может ли цепочка поставок быть просто астрологией - как та, что предсказывает будущее, а не астрономией?
В конечном итоге я пришел к выводу, что цепочка поставок как область реальна, но стандартная теория цепочки поставок в основном является астрологией. В этом была проблема. Очень трудно принять, что 70 лет исследований, миллион статей, тысячи профессоров могут быть неправы. Представьте себе интеллектуальную высокомерие, необходимую для этого. Если вы обратитесь к четырем разным врачам, каждый из которых скажет вам один и тот же диагноз, на каком этапе вы скажете, что они все неправы, а вы правы? Но наука не работает на консенсусе. Тысяча человек может согласиться на чем-то и все равно быть неправыми. История науки полна примеров: крайне широкий консенсус по идеям, которые оказались безумными. Некоторые, изучающие историю науки, даже говорят, что половина того, во что верит общество в данный момент, неверно; сложно понять, какая именно половина.
Поэтому Lokad пришел к такому выводу из анализа: традиционный способ был бессмысленным. Нам нужно было искать что-то другое. Нашим большим прорывом стало начало 2012 года, когда мы стали использовать смещенные прогнозы с помощью так называемых квантильных прогнозов. В то время у моих клиентов было по 50 человек, работающих полный рабочий день только над устранением смещения. И они спрашивали меня: “Зачем вам нужен смещенный прогноз, если мы платим людям за его устранение?” Они были довольно встревожены, потому что новый метод добавлял так много смещения, что они никогда не смогли бы устранить его вручную. Но если я назову это “квантильным прогнозированием”, это звучит более научно, чем “смещенное прогнозирование”. На самом деле квантильный прогноз - это просто смещенный прогноз.
Мы попробовали этот подход с нашим первым клиентом в сфере электронной коммерции. Однажды мы перешли от абсурдных результатов - например, прогнозирования нуля для всего - к чему-то среднему, но хотя бы в какой-то мере разумному. Это может не показаться удивительным, но переход от полной абсурдности к просто среднему был большим шагом вперед.
Это привело нас к пересмотру всех предположений цепочки поставок, найденных в учебниках, - подвергая сомнению каждое основание, которое оказалось очень хрупким, в основном неверным. Квантильное прогнозирование - это просто простая версия этого. Это статистический инструмент, который специально смотрит на крайние случаи. Экономически, в цепочке поставок, крайние случаи - это те места, где теряются деньги: неожиданно высокий спрос, который создает дефицит товара, неожиданно низкий спрос, который создает избыток товара, неожиданно долгие сроки поставки, которые разрушают ваши планы и т. д. Не средняя часть распределения действительно вам вредит; это хвосты. Квантильный прогноз - это инструмент, который фокусируется на этих крайних случаях. Улучшенная версия - это вероятностное прогнозирование - над чем вы работали, - где вы получаете полное вероятностное распределение. В 2012 году мы начали с квантильных прогнозов, потому что это было проще с точки зрения математики, статистики и вычислений. Обработка вероятностного распределения по миллионам артикулов намного сложнее, чем генерация одного прогнозного числа на артикул.
Тем временем Envision - который изначально был разработан для совершенно другой цели, внутреннего проекта под кодовым названием “Priceforge” для ценообразования - оказался идеальным для реализации нового подхода. До этого идея Lokad заключалась в создании стандартного программного обеспечения для цепочки поставок с меню, кнопками и опциями, как это typично для корпоративного программного обеспечения. Но это был хаос с точки зрения поставщика программного обеспечения: по мере добавления большего функционала, сопоставление данных из среды клиента с вашими структурами данных становится инженерным кошмаром.
Почему? Потому что архитектуры данных клиентов всегда уникальны. У одного клиента ERP может быть 10 000 таблиц, каждая с 50 полями, многие не задокументированы, используются в необычных способах. Фактически, у них может быть два или три ERP-системы, плюс WMS, плюс платформа электронной коммерции… Экосистема сложна. Ни у двух компаний нет одинаковых определений данных. Даже что-то кажущееся простым, как “дата заказа”, может иметь 20 различных определений: дата создания записи, дата подтверждения заказа клиентом, дата вашего подтверждения, дата авторизации провайдера платежей, дата отгрузки заказа и так далее. Умножьте это на тысячу других потенциальных полей данных.
Если вы создаете “классическое” программное обеспечение с установленными определениями для продукта, артикула, вариантов, поставщика, местоположения и т. д., эти определения редко соответствуют реальности клиента. Даже в одежде, например, одна компания может определять варианты исключительно как цвет и размер, в то время как другая может также включать состав ткани. Или в продуктовом секторе “срок годности” может означать день, когда его абсолютно нельзя продавать, или день, когда его нельзя выставлять в магазине. Существует бесконечное количество тонкостей.
Поэтому стандартные теории цепочки поставок оказались недостаточными. Нам нужно было что-то новое: программный подход. Об этом никогда не упоминают учебники по цепочке поставок. Готовые модели не помогают, потому что реальный мир никогда не соответствует этим моделям идеально. Всегда есть что-то — минимальное количество заказа, ограничения срока годности, ограничения по расписанию доставки. Ограничения каждой компании уникальны. Поэтому мы поняли, что решение должно быть программным, а не статической формулой. Тогда вопрос стал: какая правильная программная парадигма для цепочки поставок?
В 2012 году люди могли бы сказать: “Почему бы просто не использовать Python?” Действительно, тогда именно это делали все мои американские клиенты в сфере электронной коммерции. Почти все инициативы по науке о данных, которые я видел в то время, потерпели неудачу из-за Python (или могли бы быть Java, C# или позже Julia — это та же проблема). Сценарий был следующий: за три недели команда по науке о данных создает впечатляющий прототип для какой-то проблемы цепочки поставок. Затем они хотят запустить его в производство, и через год он все еще не запущен; руководство теряет терпение, отменяет проект, и все.
Почему это не удалось? Смерть от тысячи порезов: NullReferenceException, OutOfQuotaException, проблемы с параллельностью, несовместимые пакеты, нарушения безопасности, шифровальщики в вашей среде и так далее. Ничто из этого не связано непосредственно с самой проблемой цепочки поставок. Основная проблема заключается в том, что если вы используете язык общего назначения в большой производственной среде, ваша поверхность атаки для проблем огромна. Например, если вы можете писать в файловую систему из своего кода, вы можете случайно повредить среду, на которой работает ваш код — легко сделать, если вы обрабатываете гигабайты данных параллельно. Может быть, файл заблокирован одним процессом, или диск заполнен, и так далее. Эти вещи неизбежно происходят ночью, когда никого нет рядом, чтобы исправить это на месте. Затем, на утро, клиент бешено раздражен, потому что ожидал, что система завершится в 2 часа ночи, но она упала в полночь.
В демонстрациях по науке о данных обычно есть сиделка, запускающая скрипт, поэтому если он упадет, они его исправят. Но автоматизация реальной цепочки поставок должна работать без присмотра каждый день. Даже время выполнения может колебаться от 20 минут до двух часов, что нарушает производство. Вот в чем была проблема в 2012 году: эти инициативы по науке о данных терпели неудачу в производстве из-за широкой сложности языков общего назначения, а не из-за логики цепочки поставок самой по себе.
Все это привело Lokad к пониманию того, что нам нужна программная среда, которая была бы безопасной и достаточно специализированной для обработки крупномасштабных ежедневных операций без хрупкого присмотра. Плюс, как только мы поняли, что нам также нужно делать продвинутый прогнозирование (вероятностное, квантильное и т. д.), Envision был создан для обработки этих рабочих процессов как граждан первого класса. Например, если вам нужно дифференцируемое программирование для машинного обучения, в языке общего назначения вы встраиваете другой “мини-язык” типа PyTorch для этого. Затем у вас есть Python плюс кусок кода PyTorch, и легко допустить ошибки, потому что ваш код PyTorch по сути является некомпилированной строкой. То же самое касается смешивания SQL-запросов внутри вашего кода Python. Все это строки, поэтому вы обнаруживаете свои опечатки только во время выполнения. Envision, с другой стороны, может рассматривать эти функции как встроенные возможности с проверками компиляции.
Подход Lokad развивался параллельно с такими достижениями, как глубокое обучение, где у вас больше нет просто библиотеки готовых моделей, а вы составляете свою собственную модель программно. TensorFlow в основном является языком для построения вычислительных графов. Вы не застреваете с “каталогом” моделей; вы создаете структуры. Envision также может встроить эти идеи. Например, недавно мы работали над стохастической оптимизацией. Кто-нибудь здесь знает, что это такое? Это математическая оптимизация функции, результат которой неопределен, например, принятие решения о том, сколько единиц закупить, когда будущий спрос неизвестен. Это классическая проблема цепочки поставок. Вы видели более простые версии с минимальными ограничениями, но у реальных компаний есть куча ограничений: минимальные заказы, заполнение контейнеров, ограничения категорий или сложные календари. Кроме того, ваша функция затрат/выгоды неопределена. Поэтому это продвинутые программные концепции.
В целом, Envision продолжал добавлять функции. На сегодняшний день мы также на пороге еще одной революции: большие языковые модели (LLM). Вам, вероятно, знаком ChatGPT. Может быть, некоторые из вас используют его для выполнения домашних заданий. (Я вас не оцениваю, так что можете признаться!) Или даже платите за профессиональную версию. Интересная часть для нас заключается в том, что у Lokad есть культура письма, что довольно необычно для компании по цепочке поставок. Мы полагаемся на текст на двух уровнях. Во-первых, у нас есть сам код Envision, который буквально кодирует “что” мы делаем. Мы не хотим процесс, который генерирует рекомендуемые заказы в Excel, а затем кто-то их вручную изменяет. Наша цель - чтобы окончательные цифры генерировались автоматически без ручных изменений. И если изменения нужны - иногда они нужны, в начале - эти изменения фиксируются в рабочем процессе, чтобы мы могли обсудить с клиентом: “Почему вы изменили то, что было сгенерировано? Что мы можем изменить, чтобы ручные правки больше не были нужны?” Или иногда мы видим, что правки на самом деле не были полезными, поэтому мы также можем учесть этот опыт.
Затем у нас есть второй текстовый артефакт, JPM или Совместное Руководство по Процессам, который объясняет “почему”. Это наш справочный документ для передачи и для предоставления клиенту общего представления о инициативе простым языком - без необходимости читать код Envision напрямую. Таким образом, у нас есть слой кода, описывающий “что”, и отдельный слой документов, объясняющих “почему”.
Это довольно хорошо сочетается с LLM, потому что LLM обрабатывают текст. Они не очень хороши с сырыми числовыми данными. Если вы загрузите огромную таблицу в ChatGPT, вы не получите осмысленной регрессии. ChatGPT может только сгенерировать кусок кода Python, который выполнит регрессию. Сами LLM - это просто гигантские модели предсказания следующего токена; они не предназначены для арифметики. Отсюда и шутки о том, что ChatGPT не справляется с базовой математикой. Но если вы питаете их кодом или инструкциями на основе текста, они довольно хорошо справляются с манипуляциями и генерацией.
И вот где стоит Lokad: у нас есть продвинутые автоматизации цепочки поставок, которые могут работать месяцами без человеческого вмешательства - что было доказано во время блокировок 2020-2021 годов, когда многие из наших клиентов отправили своих белых воротничков домой. Тем временем цепочка поставок все еще должна была функционировать, потому что работники синего воротничка на складах и грузовиках были все еще активны. Lokad уже в значительной степени функционировал удаленно, поэтому наши ученые по цепочке поставок могли продолжать работать из дома. Это был настоящий стресс-тест: увидеть, как наши рецепты будут работать без ежедневного наблюдения. В некоторых случаях у крупных клиентов буквально не было сотен планировщиков, менеджеров или аналитиков, которые вдруг исчезли, но их цепочка поставок все равно должна была функционировать.
И для нас это сработало удивительно хорошо. Ни один из наших клиентов не умер от этого - никто не исчез. Это заставляет задаться вопросом: если вы можете управлять своей цепочкой поставок в течение 12 или 14 месяцев без 500 белых воротничков, вам действительно нужны они вообще? Это был эксперимент, который мы никогда не могли бы провести иначе, так как компании обычно боятся полностью доверять автоматизированной системе. Но блокировки эффективно заставили их полагаться на автоматизацию, доказывая, что мы можем управлять массовыми цепочками поставок с минимальным или даже без ручного вмешательства. Конечно, мы продолжаем обсуждать способы улучшения числовых рецептов; это не нулевое сотрудничество. Но вы больше не видите большие команды, ежедневно вносящие изменения в Excel для каждого SKU в каждом магазине.
Итак, если я пытаюсь понять, куда движется мир цепочек поставок: для меня это напоминает сдвиг, который произошел в финансах 20 лет назад, когда торговля стала электронной. Люди-трейдеры, которые когда-то читали утреннюю газету, решали покупать или продавать акции вручную - это было заменено квантами с крупными автоматизированными портфелями. Я вижу ту же трансформацию происходящей в цепочке поставок. Мы решили эту старую мечту - механизацию принятия решений в цепочке поставок. Это была первоначальная амбиция операционного исследования (предшественника цепочки поставок) в 1940-х, 50-х и 60-х годах. Со временем “операционное исследование” стало своей собственной поддисциплиной, сосредотачиваясь на решателях, но если посмотреть на раннее видение, это именно то, чего хочет цепочка поставок: математика, числовая оптимизация, распределение ресурсов. Мы достигли версии этого в Lokad почти десять лет назад. Блокировки были нашим реальным доказательством того, что это работает в масштабе, даже более года без прямого наблюдения.
Несколько наших клиентов сегодня позволяют системе работать полностью самостоятельно. Например, мы можем привести Cdiscount, крупного французского розничного торговца: мы автоматически управляем инвентарем магазина для них, без ручного вмешательства. Это не прекращает текущих обсуждений о том, как улучшить рецепты, но ежедневный подход “плюс или минус единицы” закончился. Это закончилось в 2020 году, и до сих пор работает.
В результате я думаю, что мы находимся в конце эпохи, в которой есть что-то вроде пяти миллионов человек по всему миру, чья работа заключается в том, чтобы проходить через тысячу SKU в день в Excel, чтобы решить, нужно ли им заказывать больше, производить больше, перемещать инвентарь, изменять цены и так далее. Все виды должностей - менеджер инвентаря, планировщик спроса, планировщик поставок, менеджер категорий, S&OP аналитик - сводятся к одной и той же ежедневной рутине: проходить через кусок SKU. С большими бюджетами это может быть 100 SKU на человека; с меньшими бюджетами, возможно, 5 000 SKU на человека. В любом случае, я считаю, что это подходит к концу.
Почему сейчас? Потому что десятилетиями никто не мог автоматизировать все эти решения. Но как только определенное количество компаний продемонстрирует, что это можно сделать, другие последуют. Очень дорого содержать большие ручные плановые команды, плюс сложно стратегически повернуть, когда вам нужно переобучить сотни планировщиков в разных странах, каждый из которых привык делать одну и ту же ежедневную рутину с таблицей Excel в течение 20 лет. Изменить это очень медленно. Но как только вы сможете перейти к чисто программному подходу, вы сможете быстро перенаправиться.
Вот что приходит: тот же сдвиг, который мы видели в банковской сфере. Раньше люди торговали вручную весь день; сейчас это в основном автоматизировано. Я вижу ту же механизацию на пути для цепочки поставок, и я верю, что это станет стандартной практикой намного раньше, чем вы уйдете на пенсию - если вы уйдете на пенсию после 61 года работы, или как изменятся законы. Вы все равно столкнетесь с многими компаниями, застрявшими в старых методах, но эта революция уже идет.
Итак, мое сообщение заключается в том, что вы можете либо быть активным двигателем этого изменения, либо просто пассажиром. Учитывая, что вы студенты Центрального, у вас, вероятно, есть потенциал быть активными участниками, а не просто наблюдателями.
Хорошо, может быть, мы перейдем к вопросам. Я навязал вам 50-минутный монолог, так что если у вас есть какие-либо вопросы по всему этому, пожалуйста, задавайте.
Студент: Да, это означает, что эти компании станут зависимыми от решений, подобных Lokad, или они могут разрабатывать подобные технологии внутри?
Joannes Vermorel: Оба варианта возможны. Если это компания, разбирающаяся в технологиях, например, очень крупный игрок в сфере электронной коммерции, то иногда они отправляют команды на обучение к нам, с идеей внедрения практик, которые использует Lokad. Если компания имеет сильную технологическую культуру и уже много разрабатывает внутри себя, то они, конечно, могут это сделать. Но если их культура заключается в том, что “Мы передаем все слишком сложное на аутсорсинг”, то, вероятно, они будут аутсорсить. В целом, я думаю, что большинство выберет специализированных поставщиков, будь то Lokad или другие. Конечно, у меня есть предвзятость - я хотел бы верить, что Lokad будет среди этих решений - но в любом случае, я убежден, что революция происходит, одним способом или другим.
Студент: Вы сказали, что LLM не заменят инженеров, только тех, кто не использует LLM. Какой фактор ограничивает ИИ, чтобы он не мог заменить тех инженеров, которые сами используют LLM? Другими словами, что мешает ИИ превзойти инженеров, которые сами используют ИИ?
Joannes Vermorel: Если бы я знал окончательный ответ, это было бы стоило тысячи миллиардов долларов. На протяжении десятилетий было много прорывов в области искусственного интеллекта, каждый раз раскрывая какой-то аспект того, что такое интеллект, что мы полностью не понимали. Снова и снова мы понимаем, что мы ошибались в том, что составляет “настоящий” интеллект.
Например, если бы вы спросили в 1940 году, что показывает превосходство интеллекта, они могли бы сказать: “Тот, кто может диагонализировать матрицу”. В École Polytechnique даже был отдел по диагонализации матриц, считавшийся вершиной интеллектуального достижения. Теперь простой компьютерный алгоритм может диагонализировать матрицу; мы не видим в этом ничего умного.
У нас было двадцать таких эпизодов в истории ИИ, каждый раз обнаруживая, что то, что мы считали “интеллектом”, им не является. У LLM сейчас есть некоторые явные недостатки - например, они фактически ничего не учатся в процессе использования. Они статичные модели. Вы даете им подсказку, они дают вам продолжение, и все. Если вы снова дадите ту же подсказку, вы получите то же самое продолжение. Они не учатся из разговора. Вы можете провести донастройку, да, но это внешний процесс. На повседневной основе нет памяти или постоянного улучшения. Человек, выполняющий упражнение, учится чему-то; LLM этого не делает. Вы можете запустить один и тот же сценарий 200 раз, и он не накапливает знаний.
Еще одним странным аспектом является огромное количество данных, необходимых LLM. Ребенок учится говорить примерно за три года, с максимум 1 000 часов прослушивания. LLM, по-видимому, должен прочитать весь интернет - миллиарды токенов. Или рассмотрим самоуправляемые автомобили: они проезжают миллионы виртуальных или реальных миль, чтобы научиться делать то, что человек осваивает за 20 часов уроков. Почему для “интеллекта” требуется так много данных?
Так что мы чувствуем, что чего-то фундаментального не хватает, но мы не знаем точно, что. Может быть, следующая итерация LLM или совершенно новый подход исправит эти недостатки, но мы не уверены, будет ли это завтра или через 20 или 50 лет. Некоторые люди, такие как Ян Лекун, говорят, что мы должны отказаться от всего подхода LLM и сделать что-то другое. Я не так уверен; может быть, мы можем настроить LLM для решения проблем. Поскольку у кого нет решения, мы просто не знаем.
В любом случае, это глубокие ограничения, которые мешают LLM полностью заменить человека, даже в относительно простых работах. Так что да, LLM заменят инженеров, которые выберут не использовать их; но они не обязательно заменят инженеров, которые используют их - эти люди останутся необходимыми.
Студент: Ранее вы упомянули, что Lokad оставалась прибыльной, даже если продукт сначала не работал. Как это возможно? Получали ли вы финансирование или субсидии? Или вы предоставляли другие услуги?
Joannes Vermorel: Нет, никаких субсидий или внешнего финансирования. Позвольте мне объяснить: рынок цепочки поставок немного сумасшедший. Типичные бизнес-планы конкурентов с 1980-х годов выглядят так: Шаг 1, собрать много денег - десятки миллионов. Шаг 2, захватить долю рынка, сосредоточившись на какой-то отрасли, например, авиации, на два или три года. Шаг 3, нанять 200 продавцов, захватить 20% рынка, а затем в конечном итоге развалиться. Промыть и повторить.
Мы видим это постоянно. Даже гиганты, такие как Nike, чуть не обанкротились в 2004 году из-за известного сбоя программного обеспечения цепочки поставок у одного из наших конкурентов. “Катастрофа Nike” задокументирована на их странице в Википедии. Они в основном испортили девять месяцев производства Nike. Тем временем тот же поставщик испортил многих клиентов, был приобретен, и покупатель в конечном итоге заплатил $250 миллионов в качестве компенсации. Мой опыт показывает, что в корпоративном программном обеспечении, даже если вы средненький, вас обычно не судят, поэтому эти ребята должны были быть по-настоящему ужасными. Но несмотря на такую репутацию, они просто начали новую компанию - те же люди - и собрали еще полмиллиарда долларов. Рынок никогда не учится.
Многие из наших клиентов фактически обращаются к нам после полудюжины катастрофических попыток проектов цепочки поставок с различными поставщиками. Автоматизация цепочки поставок - это старая мечта; базовые данные были цифровизированы с 80-х или 90-х годов, поэтому они пытались десятилетиями. Нормально, что у крупных компаний есть стопка неудачных проектов в их шкафу.
В такой среде мы работаем. Здесь огромная инерция. Люди забывают. Потребность остается, поэтому они пытаются снова и снова. Рынок может выглядеть рациональным с расстояния, но медленно решает эти проблемы - особенно в такой непрозрачной области, как корпоративное программное обеспечение. Вы даже можете иметь катастрофическую реализацию, и все равно клиент может предоставить вам блестящий кейс-стади, потому что менеджер, выбравший ваш продукт, не хочет быть обвиненным. Так что, иронично, катастрофу можно представить как успех в маркетинговой истории. Вот насколько это может быть запутанным.
Joannes Vermorel: Есть ли еще вопросы? Все ли, что я описал, кажется вам нормальным, рациональным - то, что вы ожидали от бизнес-мира?
Ладно. Ну, в любом случае, спасибо всем за время, которое вы потратили на написание сценариев Envision. Мне действительно приятно видеть, как студенты Центрального приступают к работе с Envision. Я действительно никогда не представлял, когда написал первый компилятор более десяти лет назад, что однажды увижу студентов Центрального, работающих с ним. Тогда это была рискованная ставка; в нашем бизнес-плане не было предусмотрено привлечение вас к работе с Envision, но я рад, что это произошло. И если Реми или Базиль еще не сказали вам: Lokad нанимает, так что знайте!
