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 Языковые модели основаны на тексте, а не на математике
00:50:25 Параллельное развитие финансовой индустрии
01:09:00 Вопросы и ответы и заключительные замечания
Резюме
Joannes Vermorel, генеральный директор и основатель Lokad, прочитал лекцию на французском, поделившись своим опытом в управлении цепями поставок. Верморель рассказал о том, как основал Lokad после окончания École Normale Supérieure и перехода от биоинформатики к задачам управления цепями поставок. Он обсудил разработку Envision — языка программирования Lokad — и развитие компании с 2007 года. Верморель подверг критике традиционные теории управления цепями поставок, сравнив их с астрологией, и подчеркнул важность опровержения общепринятых взглядов. Он отметил успех Lokad при использовании вероятностных методов и влияние COVID-19 на роботизацию. Верморель предсказал устаревание традиционных ролей и призвал студентов вести революцию в отрасли.
Расширенное резюме
В лекции, проведённой на французском для студентов, Джуаннес Верморель, генеральный директор и основатель Lokad, поделился своим опытом и взглядами на мир управления цепями поставок и развитие своей компании. Верморель начал с того, что представился и рассказал об истоках Lokad — компании, которую он основал сразу после окончания École Normale Supérieure. Изначально Верморель пытался написать диссертацию по биоинформатике, но вскоре понял, что в этой области уже полно талантливых специалистов. Случайно он столкнулся с проблемами управления цепями поставок, которые стали его новым направлением.
Верморель выразил удивление и радость, увидев студентов из Centrale, использующих Envision — язык программирования, который он создал для оптимизации цепей поставок. Он рассказал о разработке Envision, отметив, что первый написанный им компилятор был быстро заменён лучшей версией, созданной Виктором Николе, техническим директором Lokad. С тех пор Envision значительно эволюционировал, и компания сейчас на грани выпуска версии 6.
Путь Lokad начался в 2007 году, а компания была официально основана в 2008. Однако Envision был представлен только в 2013 году, спустя пять лет после создания Lokad. Верморель объяснил, что решение о создании нового языка программирования было принято после исчерпания всех других вариантов. Изначально он считал, что управление цепями поставок — это устоявшаяся область с десятилетиями литературы и множеством конкурентов, таких как SAP, Oracle, IBM и Microsoft. Он думал, что ключ к успеху — это перепаковать существующие теории цепей поставок в веб-приложения, используя переход от клиент-серверных приложений к облачным решениям.
Несмотря на первоначальную уверенность, Верморель вскоре обнаружил, что установленные теории и модели не работают как ожидалось. Он рассказал о особенно абсурдном опыте в 2011 году, когда Lokad выиграл конкурс по тестированию, представив нулевые прогнозы, что превзошло конкурентов на 20% в точности. Этот опыт заставил Вермореля усомниться в правильности традиционных теорий управления цепями поставок, сравнив их скорее с астрологией, чем с астрономией.
Верморель подчеркнул важность оспаривания консенсуса в науке, отметив, что история полна примеров широко принятых, но в конечном итоге неверных убеждений. Он пришёл к выводу, что, хотя сама цепь поставок является легитимной областью, классические теории, лежащие в её основе, были ошибочны. Это осознание побудило его исследовать альтернативные подходы, такие как смещённые прогнозы и квантильные предсказания, которые оказались более эффективными.
Подход Lokad эволюционировал в сторону применения вероятностных и программных методов, отходя от традиционных моделей, которые не могли учитывать сложности реальных задач цепей поставок. Верморель подчеркнул важность наличия надёжного языка программирования, адаптированного к этим задачам, и раскритиковал использование универсальных языков, таких как Python, которые часто приводили к провалу инициатив из-за различных технических проблем.
Лекция также затронула влияние пандемии COVID-19, которая ускорила роботизацию цепей поставок. Верморель отметил, что решения Lokad оказались эффективными в крупных масштабах, управляя запасами на миллиарды евро при минимальном участии человека. Этот сдвиг отражает переход в финансовой индустрии, где торговля стала преимущественно алгоритмической.
Верморель обсудил будущее управления цепями поставок, предсказав, что традиционные роли менеджеров по запасам и специалистов по цепям поставок устареют, поскольку всё больше компаний перейдёт к автоматизированным процессам принятия решений. Он призвал студентов активно участвовать в этой революции, а не просто наблюдать за ней.
В ответ на вопросы студентов Верморель объяснил, что компании с высоким технологическим уклоном могут внедрить решения Lokad внутренне, в то время как другие, вероятно, продолжат аутсорсинг этих услуг. Он также коснулся ограничений крупных языковых моделей (LLM), таких как ChatGPT, отметив их неспособность к обучению и запоминанию.
Верморель закончил, размышляя о иррациональности рынков и продолжающихся неудачных проектах в индустрии цепей поставок. Он поделился анекдотами о конкурентах, которые неоднократно привлекали значительные средства, несмотря на предыдущие неудачи, подчёркивая хаотичную природу рынка. Несмотря на эти вызовы, Верморель выразил гордость достижениями Lokad и неожиданным успехом Envision среди студентов престижных учреждений, таких как Centrale. Он пригласил студентов рассмотреть возможность присоединения к Lokad, подчеркнув непрерывные усилия компании по найму сотрудников.
Полная транскрипция
Оригинальная речь на французском была переведена на английский.
Джуаннес Верморель: Позвольте представиться: я Джуаннес Верморель, основатель Lokad. Я создал компанию сразу после окончания школы. Я учился в École Normale Supérieure, начал аспирантуру по биоинформатике, но в конце концов столько людей занимались интересными вещами в биоинформатике, что, вероятно, они не нуждались во мне. И случайно я столкнулся с проблемами цепей поставок. Мне очень приятно видеть, что вы сегодня используете Envision. Для меня это нечто необычное — оказаться перед студентами Centrale и говорить об этом языке. Это то, о чём я и не мог мечтать, когда создавал 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 год, и всё enterprise software переходило от так называемых «толстых клиентских» приложений, которые устанавливаются на ПК, к «тонким клиентским», то есть веб-приложениям. Так появилась возможность перестроить программное обеспечение для цепей поставок как веб-приложение, возможно, с облачным хостингом. Lokad перешёл в облако очень рано. Это могло дать нам преимущество над крупными компаниями, которые всё ещё используют старые, более тяжёлые системы на базе клиента.
Затем я закодировал эти подходы — и ничего не сработало. Что интересно, это не помешало Lokad расти и находить клиентов. Можно подумать, что чтобы зарабатывать как стартап, нужен продукт, который действительно работает, но в enterprise software можно продавать то, что вообще не работает, и всё равно находить клиентов. Это может показаться странным, но такова реальность. Дело в том, что если у компании есть большая проблема, которую она хочет решить, существует бюджет для её решения. Этот бюджет может быть не огромным — особенно если ваш продукт не работает — но для стартапа такие суммы кажутся очень большими. Если такой гигант, как Carrefour, выставляет 100 000 евро «просто чтобы попробовать», это мелочь для Carrefour, но много для маленькой компании.
Итак, используя это неравенство, я начал и попытался реализовать эти стандартные теории управления цепями поставок: прогнозирование временных рядов, резервный запас, оптимизацию уровня сервиса и т.д. Ничего из этого не сработало; абсолютно ничего. У нас были довольно шизофренические обсуждения с клиентами: они говорили: «Вы, должно быть, неправильно реализовали формулу резервного запаса», и мы возвращались, буквально брали значения из таблиц учебников, перепроверяли параметры — и всё было именно так, как написано. Теория была реализована правильно, но итог был полнейшим абсурдом.
Думаю, вершина абсурда наступила летом 2011 года. Мы участвовали в большом тендере с полудюжиной поставщиков программного обеспечения, половина из которых были европейскими, а другая половина — американскими. Lokad был среди европейцев. Как я помню, речь шла о примерно десяти супермаркетах, по 5 000 SKU в каждом, с необходимостью прогнозирования на несколько дней вперёд, поскольку эти супермаркеты пополнялись, возможно, два или три раза в неделю. Клиент использовал критерий ошибки ретроспективного тестирования для ежедневных прогнозов на уровне продукта для каждого магазина — фактически абсолютную ошибку между прогнозом и фактическими данными. В конце концов, Lokad выиграл этот тест — с точностью на 20% лучше, чем у конкурентов. Мой секретный метод? Я отправил нули. Ноль для всего. Благодаря моему «нулевому прогнозу» я также превзошёл всех по скорости расчётов: возвращать нули чрезвычайно быстро. И я получил на 20% лучшие прогнозы по точности, чем остальные. Ещё лучше: если вы прогнозируете нулевой спрос, вы не пополняете магазин, так что через две недели магазин оказывается пустым, что соответствует вашему прогнозу на 100%. Я был королём статистики.
Очевидно, это был полный абсурд. Но если рассмотреть подход, рекомендуемый всеми учебниками по цепям поставок и стандартным процессом клиента, итог оказался тотальным абсурдом. Вывод, к которому я пришёл, был весьма тревожным. У нас была прибыльная, растущая компания, но я был вынужден осознать, что, возможно, я наткнулся на какую-то схему. Вы можете начать что-то, что приносит деньги, но это чистый абсурд. Может быть, сначала вы просто недостаточно опытны, чтобы это понять. Но как только вы осознаёте это, продолжаете ли вы? Когда вы заканчиваете учёбу и понимаете, что то, чем занимаетесь, — абсурд, будете ли вы продолжать? Это вызвало глубокие размышления. Может ли управление цепями поставок быть просто астрологией — именно предсказательной, а не астрономией?
В конце концов, я пришёл к выводу, что управление цепями поставок как область существует, но стандартная теория цепей поставок по сути является астрологией. Вот в чём была проблема. Очень сложно принять, что 70 лет исследований, более миллиона публикаций и тысячи профессоров могут все ошибаться. Представьте, какая интеллектуальная гордыня для этого нужна. Если вы посетите четырёх разных врачей, и каждый из них скажет, что у вас одно и то же заболевание, в какой момент вы решите, что все они ошибаются, а вы правы? Но наука не работает по принципу консенсуса. Тысяча людей могут прийти к одному мнению и всё равно ошибаться. История науки полна примеров: чрезвычайно широкого консенсуса по идеям, которые оказались безумными. Некоторые, кто изучает историю науки, даже говорят, что половина того, во что верит любое общество в определённое время, ошибочна; сложность заключается в том, чтобы понять, какая именно половина.
Таким образом, Lokad пришёл к выводу, основанному на результатах тестирования: традиционный подход оказался абсурдным. Нам пришлось искать что-то иное. Наш прорыв произошёл в начале 2012 года, когда мы стали применять предвзятые прогнозы, известные как квантильные прогнозы. В то время у меня были клиенты, нанимавшие 50 человек на полную ставку только для устранения смещения. И они спрашивали: «Почему, черт возьми, вам нужен предвзятый прогноз, если мы платим людям, чтобы исправлять его?» Их это сильно тревожило, ведь новый метод добавлял столько смещения, что его никогда нельзя было устранить вручную. Но если назвать его «квантильное прогнозирование», оно звучит более научно, чем «предвзятое прогнозирование». На самом деле же квантильный прогноз — это просто предвзятый прогноз.
Мы опробовали этот подход с нашим первым клиентом в сфере электронной коммерции. За одну ночь мы перестали получать абсурдные результаты — прогнозируя ноль по всем показателям — и перешли к чему-то посредственному, но хотя бы отчасти разумному. Это может показаться не впечатляющим, но переход от полной абсурдности к посредственности был огромным шагом вперёд.
Это, в свою очередь, заставило нас пересмотреть все предпосылки по цепочке поставок, изложенные в учебниках, — поставить под сомнение каждую основу, которая оказалась весьма шаткой, фактически неверной. Квантильное прогнозирование — лишь его упрощённая версия. Это статистический инструмент, который специально рассматривает крайние значения. Экономически в цепочке поставок деньги теряются именно на крайностях: внезапно высокий спрос, создающий дефицит товара, внезапно низкий спрос, приводящий к избытку запасов, а также неожиданно длинные сроки поставки, которые рушат ваши планы и т.д. Вас никогда не ранит средина распределения; проблема — в хвостах. Квантильный прогноз — это инструмент, сосредоточенный на этих крайностях. Улучшенная версия — это вероятностное прогнозирование, над которым вы работаете, — когда вы получаете полное вероятностное распределение. В 2012 году мы начали с квантильных прогнозов, потому что с математической, статистической и вычислительной точек зрения это было проще. Обработка вероятностного распределения для миллионов SKU существенно сложнее, чем генерация одного числа прогноза для каждого SKU.
Между тем, Envision — который изначально разрабатывался для совершенно другой задачи, как внутренний проект с кодовым названием «Priceforge» для ценообразования — оказался идеальным для реализации этого нового подхода. Ранее идея Lokad заключалась в создании стандартного программного обеспечения для цепей поставок с меню, кнопками и настройками, как это принято в корпоративном ПО. Но с точки зрения издателя программного обеспечения это был полный хаос: с добавлением новых функций сопоставление данных из клиентской среды с вашими структурами превращалось в инженерный кошмар.
Почему? Потому что архитектуры данных клиентов всегда уникальны. У одного клиента ERP может быть 10 000 таблиц, каждая с 50 полями, многие из которых не задокументированы и используются в необычных целях. Фактически, у них может быть два или три ERP, плюс WMS, плюс платформа электронной коммерции… Экосистема сложна. Ни у каких двух компаний определения данных не совпадают. Даже вроде бы простое понятие «дата заказа» может иметь 20 различных значений: дата создания записи, дата подтверждения заказа клиентом, дата вашего подтверждения, дата авторизации платежного провайдера, дата отгрузки заказа и так далее. Умножьте это на тысячу других возможных полей данных.
Если вы создаёте «классическое» программное обеспечение с фиксированными определениями для продукта, SKU, вариантов, поставщика, местоположения и так далее, эти определения редко соответствуют реальности клиента. Даже в индустрии одежды, например, одна компания может определять варианты исключительно по цвету и размеру, в то время как другая может учитывать и состав ткани. Или в продуктовом ритейле понятие «срок годности» может означать либо день, когда товар точно нельзя продавать, либо день, когда его нельзя выставлять в магазине. Существует бесконечное множество тонкостей.
Отсюда стало ясно, что стандартные теории цепей поставок оказались недостаточными. Нам понадобилось нечто новое: программный подход. Это то, о чем учебники по цепям поставок никогда не говорят. Готовые модели не помогают, потому что реальный мир никогда не соответствует им идеально. Всегда есть что-то — минимальное количество заказа, ограничения по сроку годности, ограничения по графику отгрузок. Ограничения каждой компании уникальны. Так что мы поняли, что решение должно быть программным, а не статической формулой. Вопрос тогда заключался в том, какая парадигма программирования подходит для цепочки поставок?
В 2012 году кто-то мог спросить: «Почему бы просто не использовать Python?» Действительно, в то время именно это делали все мои американские клиенты в сфере электронной коммерции. Почти каждая инициатива в области data science, которую я видел тогда, проваливалась из-за Python (или, возможно, Java, C# или позднее Julia — проблема оставалась той же). Схема была следующей: за три недели команда data science создаёт впечатляющий прототип для какой-либо задачи в цепи поставок. Затем они хотят перевести его в эксплуатацию, а через год он всё ещё не в продакшене; руководство теряет терпение, отменяет проект — и всё.
Почему он терпел неудачу? Из-за смерти от тысячи мелких сбоев: NullReferenceException, OutOfQuotaException, проблемы с конкурентностью, несовместимые пакеты, нарушения безопасности, атаки программ-вымогателей в вашей среде и так далее. Всё это не связано напрямую с задачей цепи поставок. Основная проблема в том, что если вы используете язык общего назначения в большом производственном окружении, площадь вашей уязвимости для ошибок становится огромной. Например, если ваш код может записывать данные в файловую систему, вы можете случайно нарушить работу системы, в которой он выполняется — что легко может случиться при параллельной обработке гигабайтов данных. Возможно, один файл заблокирован процессом, или диск переполнен, и так далее. Всё это неизбежно происходит посреди ночи, когда никого нет, кто смог бы немедленно устранить проблему. А утром клиент приходит в ярости, потому что ожидал, что система завершится в 2 часа ночи, а она рухнула в полночь.
В демонстрациях data science обычно присутствует «няня», запускающая скрипт, так что если он падает, её тут же починят. Но автоматизация цепей поставок в реальном мире должна работать автономно каждый день. Даже время выполнения может колебаться от 20 минут до двух часов, что нарушает работу системы. Это и было проблемой в 2012 году: инициативы в области data science проваливались в эксплуатации из-за общей сложности языков общего назначения, а не из-за логики цепей поставок.
Всё это привело Lokad к пониманию того, что нам нужна программная среда, достаточно безопасная и специализированная, чтобы справляться с крупномасштабными ежедневными операциями без хрупкого «нянчения». Плюс, как только мы поняли, что нам также необходимо продвинутое прогнозирование (вероятностное, квантильное и т. д.), Envision был настроен для работы с этими потоками как с полноценными элементами. Например, если вы хотите использовать дифференцируемое программирование для машинного обучения, в языке общего назначения вам приходится внедрять ещё один «мини-язык», такой как PyTorch. Тогда у вас получается Python плюс кусок кода PyTorch, и легко допустить ошибку, поскольку ваш код PyTorch по сути является некомпилированной строкой. То же самое происходит, если смешивать SQL-запросы внутри кода на Python. Всё это строки, и вы обнаружите опечатки только во время выполнения. Envision, с другой стороны, может рассматривать эти функции как встроенные с проверкой компиляции.
Подход Lokad развивался параллельно с достижениями, такими как глубокое обучение — когда у вас уже не просто библиотека готовых моделей, а вы программно составляете свою модель. TensorFlow по сути является языком для построения вычислительных графов. Вы не застряли с «каталогом» моделей; вы создаёте структуры. Envision может нативно включать эти идеи. Например, недавно мы работали над стохастической оптимизацией. Кто-нибудь из вас знает, что это такое? Это математическая оптимизация функции, исход которой неопределён — например, решение о том, сколько единиц закупать, когда будущий спрос неизвестен. Это классическая задача цепи поставок. Вы видели упрощённые версии с минимальными ограничениями, но в реальном бизнесе существует масса ограничений: минимальные заказы, уровень сервиса для контейнеров, ограничения по категориям или сложные календари. Кроме того, ваша функция затрат и выгод неопределённа. То есть это продвинутые программные концепции.
В общем, Envision продолжал добавлять новые функции. На сегодняшний день мы также на пороге новой революции: больших языковых моделей (LLMs). Вы, наверное, слышали о ChatGPT. Возможно, некоторые из вас используют его для выполнения домашних заданий. (Я вас не оцениваю, так что можете признаться!) Или даже платят за профессиональную версию. Интересно для нас то, что в Lokad сложилась культура письма, что довольно необычно для компании в сфере цепей поставок. Мы ориентируемся на текст на двух уровнях. Во-первых, у нас есть сам код Envision, который буквально кодирует «что» мы делаем. Мы не хотим, чтобы процесс генерировал рекомендованные заказы в Excel, а затем их кто-то вручную изменял. Наша цель — чтобы итоговые цифры генерировались автоматически без ручных корректировок. И если изменения необходимы — иногда они действительно требуются на начальном этапе — они фиксируются в рабочем процессе, чтобы мы могли обсудить с клиентом: «Почему вы изменили сгенерированное? Что можно изменить, чтобы ручное редактирование больше не требовалось?» Или порой оказывается, что правки вовсе не помогли, и мы можем учесть этот опыт.
Затем у нас есть второй текстовый артефакт — JPM или Joint Process Manual, который объясняет «почему». Это наш справочный документ для передачи дел и для предоставления клиенту общего обзора инициативы простым языком — без необходимости непосредственно читать код Envision. Таким образом, у нас есть слой кода, описывающий «что», и отдельный документ, объясняющий «почему».
Это отлично сочетается с 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 на человека. В любом случае, я уверен, что эта эпоха подходит к концу.
Почему сейчас? Потому что десятилетиями никто не мог автоматизировать все эти решения. Но как только определённое число компаний докажет, что это возможно, остальные последуют их примеру. Содержание больших команд ручного планирования крайне затратно, да и стратегически трудно менять направление, когда нужно переобучить сотни планировщиков в разных странах, привыкших на протяжении 20 лет к одной и той же ежедневной работе с таблицами. Изменения происходят очень медленно. Но как только вы перейдёте на полностью программный подход, можно быстро перенастраиваться.
Вот что нас ждёт: тот же сдвиг, что мы наблюдали в банковской сфере. Раньше люди торговали вручную весь день; теперь всё в основном автоматизировано. Я вижу, что в цепях поставок наступает та же механизация, и я уверен, что она станет стандартной практикой задолго до того, как вы уйдёте на пенсию — будь то после 61 года работы или в соответствии с изменениями в законодательстве. Возможно, вы всё ещё встретите множество компаний, застрявших на старых методах, но эта революция уже в процессе.
Так что мой посыл таков: вы можете либо активно участвовать в этом изменении, либо быть просто пассажиром. Учитывая, что вы — студенты Central, у вас, вероятно, есть потенциал быть не просто наблюдателями, а активными инициаторами перемен.
Ладно, возможно, мы можем перейти к вопросам. Я уже устроил вам 50-минутный монолог, так что если у вас есть вопросы по всему этому материалу, пожалуйста, спрашивайте.
Student: Да, означает ли это, что эти компании станут зависимыми от таких решений, как Lokad, или они смогут разрабатывать подобные технологии самостоятельно?
Joannes Vermorel: Обе возможности реалистичны. Если это технологически подкованная компания — например, очень крупный игрок в электронной коммерции — иногда они направляют свои команды на обучение у нас с целью перенять те практики, которые использует Lokad. Если в компании сильная технологическая культура и они уже многое разрабатывают внутри компании, то, безусловно, смогут справиться. Но если их менталитет таков: «Мы аутсорсим всё, что слишком сложно», тогда они, вероятно, будут аутсорсить. В целом, я думаю, большинство выберет специализированных поставщиков, будь то Lokad или кто-то другой. Конечно, я предвзят — я бы хотел верить, что Lokad будет среди этих решений — но в любом случае, я убеждён, что революция происходит, так или иначе.
Student: Вы сказали, что LLM не заменят инженеров, а только тех, кто не использует LLM. Какой фактор ограничивает ИИ так, что он не может заменить тех инженеров, которые используют LLM? Другими словами, что мешает ИИ превзойти инженеров, которые сами используют ИИ?
Joannes Vermorel: Если бы я знал окончательный ответ, это стоило бы тысячу миллиардов долларов. За десятилетия в искусственном интеллекте происходили множество прорывов, каждый раз раскрывая новый аспект того, что такое интеллект — то, что мы до конца не понимали. Снова и снова мы осознаём, что ошибались в своём представлении о том, что составляет «настоящий» интеллект.
Например, если бы вы спросили в 1940 году, что демонстрирует высший интеллект, вам могли бы ответить: «Тот, кто умеет диагонализировать матрицу». В École Polytechnique даже существовал факультет, посвящённый диагонализации матриц, который считал самую высокую интеллектуальную вершину. Сегодня простой компьютерный алгоритм может диагонализировать матрицу; и мы уже не воспринимаем это как признак интеллекта.
Мы пережили двадцать подобных эпизодов в истории ИИ, когда выяснялось, что то, что мы считали «интеллектом», на самом деле таковым не является. Большие языковые модели сейчас имеют некоторые явные недостатки — например, они на самом деле ничего не усваивают во время использования. Это статичные модели. Вы даёте им запрос — они выдают продолжение, и всё. Если вы повторите тот же запрос снова, получите то же самое продолжение. Они не учатся на основе диалога. Конечно, можно провести тонкую настройку, но это внешний процесс. Из дня в день у них нет ни памяти, ни накопления улучшений. Человек, выполняющий упражнение, чему-то учится; а LLM не учится. Вы можете воспроизвести тот же сценарий 200 раз, и он никак не накапливает знания.
Ещё один странный аспект — это огромное количество данных, которое требуются LLM. Ребёнок учится говорить примерно за три года, проведя, возможно, не более 1000 часов за прослушиванием. Видимо, LLM необходимо «прочитать» весь интернет — миллиарды токенов. Или рассмотрим самоуправляемые автомобили: они проезжают миллионы виртуальных или реальных миль, чтобы научиться тому, что человек осваивает за 20 часов уроков. Почему же для «интеллекта» требуется столько данных?
Так что мы чувствуем, что чего-то фундаментально не хватает, но точно не знаем чего. Возможно, следующая итерация LLM или совершенно новый подход исправят эти недостатки, но мы не уверены, будет ли это завтра или через 20 или 50 лет. Некоторые специалисты, такие как Янн Лекун, считают, что следует полностью отказаться от подхода LLM и попробовать что-то другое. Я не так уверен; может быть, мы сможем немного подправить LLM для решения этих проблем. Поскольку ни у кого пока нет окончательного решения, мы просто не знаем.
В любом случае, эти глубокие ограничения мешают LLM полностью заменить человека, даже в относительно простых задачах. Так что да, LLM заменят инженеров, которые решат их не использовать, но не обязательно заменят инженеров, которые их используют — такие специалисты останутся незаменимыми.
Student: Ранее вы упомянули, что Lokad оставался прибыльным, хотя продукт поначалу не работал. Как это было возможно? Получили ли вы финансирование или субсидии? Или вы предлагали другие услуги?
Joannes Vermorel: Нет, никаких субсидий или внешнего финансирования. Позвольте объяснить: рынок цепочки поставок несколько безумный. Типичные бизнес-планы конкурентов с 1980-х годов выглядят так: Шаг 1 — собрать кучу денег, десятки миллионов. Шаг 2 — захватить долю рынка, сосредоточившись на какой-нибудь вертикали, например, авиация, в течение двух-трёх лет. Шаг 3 — нанять 200 продавцов, занять 20% рынка, а затем в конечном итоге развалиться. И так по кругу.
Мы видим это постоянно. Даже такие гиганты, как Nike, чуть не обанкротились в 2004 году из-за широко известного фиаско программного обеспечения для цепочки поставок у одного из наших конкурентов. «Катастрофа Nike» задокументирована на их странице в Википедии. По сути, они испортили производство Nike на девять месяцев. Между тем, тот же поставщик испортил работу множества клиентов, был приобретён, а покупатель в итоге выплатил 250 миллионов долларов в качестве компенсации. По моему опыту, в корпоративном программном обеспечении вас обычно не судят, даже если вы посредственны, так что эти ребята, должно быть, действительно ужасны. Но несмотря на это, они просто открыли новую компанию — те же люди — и собрали ещё полмиллиарда долларов. Рынок никогда не учится.
Многие наши клиенты обращаются к нам после полудюжины катастрофических попыток реализовать проекты цепочки поставок с разными поставщиками. Автоматизация цепочки поставок — это давняя мечта; исходные данные оцифрованы с 80-х или 90-х, так что попытки идут десятилетиями. Это нормально, что у крупных компаний в архиве лежит множество провальных проектов.
Вот в таком окружении мы и работаем. Здесь существует огромная инерция. Люди забывают. Потребность остаётся, поэтому они пытаются снова и снова. Рынок может казаться рациональным издалека, но исправить эти проблемы так быстро трудно — особенно в такой непрозрачной области, как корпоративное программное обеспечение. Даже если у вас случается катастрофическая реализация, клиент может всё равно предоставить вам блестящий кейс, потому что менеджер, выбравший ваш продукт, не хочет, чтобы его упрекали. Таким образом, иронично, что неудача может быть представлена как успех в маркетинговом нарративе. Вот насколько всё может быть запутано.
Joannes Vermorel: Есть ли ещё вопросы? Всё ли, что я описал, кажется вам нормальным, рациональным — таким, каким вы ожидаете видеть бизнес-мир?
Ладно. В любом случае, огромное спасибо всем за то время, которое вы потратили на написание скриптов для Envision. Я искренне горжусь тем, что студенты Central засучили рукава и начали пользоваться Envision. Я действительно никогда не мог предположить, когда писал первый компилятор более десятка лет назад, что однажды увижу студентов Central, работающих с ним. Это был рискованный шаг в то время; в нашем бизнес-плане не предполагалось, что вы будете работать с Envision, но я рад, что это произошло. И, если Рэми или Базиль ещё не сказали вам: Lokad набирает сотрудников, просто чтобы вы знали!
