00:00:00 Введение в интервью
00:01:01 Влияние искусственного интеллекта на традиционные рабочие места
00:04:36 Автоматизация искусственного интеллекта в управлении цепями поставок
00:09:08 Необходимость единой системы в 2012 году
00:10:30 Внедрение решений в системы
00:13:08 Избегание проблемы галлюцинаций в искусственном интеллекте
00:16:11 Влияние и задержки из-за отставания в IT
00:20:04 Сравнение настроек Lokad и других поставщиков
00:23:06 Обсуждение галлюцинаций и конфабуляций LLM
00:30:38 Подчеркивание прогресса перед совершенством в искусственном интеллекте
00:33:00 Получение недостающей информации и оценка ETA заказа
00:36:17 Количественные задачи и LLM в управлении цепями поставок
00:38:28 Будущее AI Pilots в управлении цепями поставок
00:41:18 Значимость разговоров и автоматизация низкоприоритетных задач
00:44:57 Использование AI Pilots для сокращения отставания
00:49:00 AI Pilot против копилота и сценарий блокировки
00:53:36 Скептицизм по отношению к разговорному искусственному интеллекту и анализу процессов
00:57:18 Понимание деловой реальности и замена процессов искусственным интеллектом
01:00:12 Проблемы открытого исходного кода Envision
01:06:21 Подход искусственного интеллекта к устранению узких мест и управлению цепями поставок
01:09:17 Неэффективность устных команд и автоматизация заказов
01:14:12 Ученый по управлению цепями поставок в качестве копилота для AI Pilot
01:17:32 Проверка правильности данных и автоматизация проверок с помощью LLM
01:20:15 Создание дружественной среды для git в Envision
01:21:14 Бесплатные ресурсы для изучения Envision
Резюме
В диалоге между генеральным директором Lokad Джоаннесом Верморелем и руководителем по коммуникации Конором Доэрти обсуждается влияние искусственного интеллекта на управление цепями поставок. Верморель подчеркивает прогресс в области искусственного интеллекта и больших языковых моделей, которые революционизировали автоматизацию задач. Он представляет AI Pilots, предложение от Lokad, которое автоматизирует принятие решений и административные задачи с помощью собственного языка программирования Lokad - Envision. Верморель также обсуждает потенциал искусственного интеллекта для автоматизации задач, связанных с мастер-данными, и сравнивает подход Lokad с конкурентами. Он предсказывает, что AI Pilots станут нормой в управлении цепями поставок, приводя к значительному повышению производительности. Беседа завершается сессией вопросов и ответов.
Расширенное резюме
В недавнем разговоре между Конором Доэрти, руководителем по коммуникации в Lokad, и Жоаннесом Верморелем, генеральным директором и основателем Lokad, дуэт погрузился в трансформационную роль искусственного интеллекта (ИИ) в управлении цепями поставок. Обсуждение, продолжение предыдущего разговора о влиянии ИИ на занятость, сосредоточилось на потенциале ИИ как самостоятельного пилота для принятия решений в цепях поставок.
Верморель начал с подчеркивания вехового достижения генеративного ИИ и моделей большого языка (LLM) в 2023 году. Он объяснил, что эти достижения революционизировали автоматизацию задач, связанных с текстом, таких как чтение электронных писем или категоризация жалоб. Год 2023 был особенно значимым, поскольку он принес существенное снижение операционных затрат на техники обработки естественного языка для компаний. Верморель предсказал, что это приведет к автоматизации многих внутренних служебных функций, причем операции в цепях поставок будут на переднем плане.
Затем Верморель представил AI Pilots, предложение от Lokad, которое автоматизирует процесс принятия решений и обрабатывает рутинные административные задачи. Он подчеркнул уникальный подход Lokad, при котором один специалист по цепям поставок может полностью владеть инициативой. Это облегчается собственным языком программирования Lokad, Envision, посвященным предиктивной оптимизации цепей поставок. Однако Верморель признал, что ранее Lokad испытывала трудности с поиском данных и работой с различными диалектами SQL.
Верморель объяснил, что появление GPT-4 позволило Lokad автоматизировать составление SQL-запросов. Эти запросы затем могут быть проверены специалистом по цепям поставок и протестированы для обеспечения точности. Это развитие, в сочетании с безопасным облачным подключением, позволяет команде специалистов по цепям поставок Lokad самостоятельно работать с данными клиентов, тем самым сокращая задержки.
Верморель также подчеркнул потенциал LLM в автоматизации многих задач, связанных с мастер-данными, включая их исследование, мониторинг и улучшение. Он сравнил подход Lokad с подходом конкурентов, отметив, что в инициативе Lokad обычно задействовано меньше людей, причем каждый человек обладает компетенцией во всей цепочке. По его мнению, это является резким контрастом по сравнению с конкурентами, которые часто задействуют гораздо больше людей в инициативе, включая менеджеров проектов, консультантов, дизайнеров пользовательского интерфейса, администраторов баз данных, специалистов по сетям и программистов.
Затем разговор перешел к роли специалистов по цепям поставок в проверке или мониторинге скриптов, созданных LLM. Верморель признал, что LLM иногда может давать неточные или “галлюцинационные” результаты, но они обычно имеют правильное направление и могут быть исправлены с помощью нескольких итераций через обратную связь. Он предположил, что хотя LLM могут допускать ошибки, они все равно могут предоставить много ценности, и их уровень ложных срабатываний и ложных отрицаний можно измерить.
Верморель дал дальнейшее объяснение повседневной оркестрации между специалистом по цепям поставок, пилотом ИИ и клиентом. Пилот ИИ, созданный специалистом по цепям поставок, управляет ежедневной операционной деятельностью цепи поставок, управляя мелочами подготовки данных и принятия решений о заказах. Клиент в этой схеме сравнивается с капитаном, который дает общие стратегические указания.
Что касается выводов для практиков в области цепей поставок и исполнительных команд, Верморель предсказал, что через десять лет пилоты ИИ станут нормой в управлении цепями поставок (УЦП). Он считает, что это приведет к значительному повышению производительности, с потенциальным сокращением численности персонала на предыдущие функции на 90%. Он призвал практиков в области цепей поставок уделять больше времени стратегическому мышлению и глубоким разговорам с поставщиками и клиентами.
Разговор завершился сессией вопросов и ответов, где Верморель ответил на вопросы по ряду тем, включая роль пилотов ИИ в сокращении отставания в области информационных технологий, разницу между пилотом ИИ и копилотом, важность анализа процессов перед внедрением модели ИИ, планы Lokad по открытию исходного кода Envision и то, как ИИ решает случайные узкие места. Он также подтвердил, что Lokad работает над копилотом Lokad и планирует сделать Envision более дружественным к GitHub.
Полный текст
Конор Доэрти: Добро пожаловать на прямую трансляцию Lokad. Меня зовут Конор. Я руководитель отдела коммуникации в Lokad. И в студии со мной основатель Lokad, Жоанн Верморель.
Тема сегодняшней передачи - как ИИ может выступать в качестве самостоятельного пилота для принятия решений в сфере поставок. Вы можете задавать свои вопросы в любое время в чате YouTube, и мы ответим на них примерно через 30-35 минут.
Итак, Жоанн, пилоты ИИ в сфере поставок. Мне кажется, что эта беседа является продолжением той, которую мы вели, думаю, около четырех недель назад, где мы говорили о влиянии ИИ на занятость и будущее традиционных профессий по сравнению с ИИ в сфере поставок.
Так что, прежде чем мы перейдем к конкретике пилотов ИИ, не могли бы вы, для тех, кто не видел этого, дать краткое напоминание, краткое изложение нашей точки зрения на традиционные профессии по сравнению с ИИ в сфере поставок?
Жоанн Верморель: Краткое напоминание заключается в том, что в 2023 году был достигнут важный этап. Этот этап - это генеративный ИИ и, более конкретно, большие языковые модели (LLM). С точки зрения чисто научных исследований, это просто продолжение почти четырех-пяти десятилетий непрерывного совершенствования в области машинного обучения. Если посмотреть на это с научной точки зрения, 2023 год - это просто год, как и все остальные, с долгой последовательностью прогресса. И в последние два десятилетия прогресс шел достаточно быстро.
Теперь, в 2023 году, на рынок выходит упакованный генеративный ИИ для изображений и, что более важно, для текста. И есть один продукт, который популяризировал это - это ChatGPT от OpenAI. Что это означает? Это означает, что у вас есть универсальная шаблонная машина, устойчивая к шуму, особенно для этих больших языковых моделей.
Это означает, что все этапы корпоративного программного обеспечения, я говорю в контексте работников, как офисных работников в корпоративных средах, означает, что все этапы, которые раньше не могли быть автоматизированы, потому что нам приходилось иметь дело с текстом в любой форме, означает прочитать электронное письмо, извлечь ссылку или цену из электронного письма или количество или классифицировать тип жалобы или запроса от партнера или поставщика клиента из электронного письма, определить, является ли метка товара бессмысленной, например, если описание товара отсутствует, хорошо, у нас проблема, все эти вещи раньше были сложно сделать. Они могли быть сделаны другими способами, но их нельзя было легко автоматизировать.
Если мы вернемся, скажем, пять лет назад, то анализ текста уже был вещью. Уже было возможно создавать классификаторы текста и использовать все виды техник обработки естественного языка, но они были дорогими. 2023 год стал вехой, потому что все эти проблемы, связанные с уровнем упаковки, которого удалось достичь с помощью в основном GPT-4, обслуживаемого через API, означало, что все эти техники обработки естественного языка имели свою операционную стоимость для компаний, сокращенную в 100 раз, если не в 1000 раз. Что означает, что не только стоимость, но и время, необходимое для настройки всего этого.
Итак, главный вывод, и это мое предсказание, заключается в том, что многие служебные функции в компаниях, которые являются внутренними функциями, которые получают некоторые данные и производят выходные данные для других подразделений, будут автоматизированы. Цепочка поставок находится на передовой, потому что это не совсем функция, связанная с обслуживанием клиентов. Это в значительной степени внутренняя функция, важная, но внутренняя. И поэтому случаи, когда большие языковые модели стали недостающим звеном для полной автоматизации практически всех рутинных операций в цепях поставок, стали возможными.
Lokad уже десять лет автоматизирует квантитативный анализ и процесс принятия квантитативных решений, но есть много монотонных операций, которые предшествуют и много монотонных операций, которые следуют, и именно они могут быть автоматизированы благодаря большим языковым моделям, и быстро и недорого.
Conor Doherty: Ну, спасибо. У нас уже есть видео, где мы говорили, я думаю, около полутора часов на эту тему, поэтому я не буду уделять этому больше времени сегодня, но это задает тон для остальной беседы. Я любезно приглашаю всех, кто хочет услышать больше об этом, ознакомиться с предыдущим видео. Теперь, по этому поводу, ИИ-пилоты, как они вписываются во всё, что вы только что сказали? Что это такое? Что они делают на самом деле?
Joannes Vermorel: ИИ, в общем, использовался последние два десятилетия постоянно поставщиками как рекламный слоган и общий термин для того, чтобы бросить то, что у них было. Поэтому, когда я говорю об ИИ-пилотах, это в значительной степени предложение от Lokad. Это эволюция предложения, это, вероятно, самое большое предложение, которое у нас было за последние годы. И в чем разница? Ну, разница заключается в том, что ИИ-пилот - это программное обеспечение, то есть серия числовых рецептов, которые не только выполняют процесс принятия решений, то есть чисто квантитативный аспект цепи поставок, то есть буквально определение того, сколько заказывать, куда распределять запасы, если нужно повысить или понизить цены, точно как планировать производство со всеми шагами и т.д.
То, что мы уже делали, плюс все, что предшествует и следует после в терминах монотонных административных задач, которые в основном являются управлением мастер-данными перед анализом данных, а затем выполнением решения, которое может включать неструктурированные каналы, такие как электронная почта, например, где вы хотите отправить письмо поставщику с просьбой ускорить что-то или, наоборот, отложить заказ.
И суть этого предложения, очевидно, заключается в использовании больших языковых моделей, которые Lokad не изобрел, которые мы активно используем уже 14 месяцев, немного больше. И ключевое понимание в работе Lokad заключается в том, что должен быть один ученый по цепи поставок, который способен полностью владеть инициативой.
Для очень крупных компаний у нас может быть несколько человек в команде, но, в отличие от большинства наших конкурентов, они обычно не специализируются. Так что это не значит, что мы берем команду из трех человек: г-н База данных, г-н Алгоритмы и г-н UI и UX пользовательский опыт. Это абсолютно не то, как работает Lokad. Ученый по цепи поставок способен делать все от начала до конца.
И вот почему Lokad разработала свою собственную технологию, свой собственный язык программирования, специализированный язык программирования с названием Envision, посвященный предиктивной оптимизации цепей поставок. Может показаться очень странным придумать собственный язык программирования, но суть в том, что мы, и это решение я принял в 2012 году, действительно нуждались в чем-то едином, чтобы один человек мог делать всю работу от начала до конца.
Еще несколько лет назад это означало получение исходных данных о транзакциях из ERP-систем, CRM-систем, EDI и всех этих транзакционных систем, дополнение их набором электронных таблиц для всех структурированных данных, которые, к сожалению, являются частью теневой IT, а не обычной IT, а затем создание числовых рецептов принятия решений. И это была ответственность ученого по цепи поставок делать все это, затем создавать всю инструментацию, включая панели инструментов и отчеты, чтобы убедиться в правильности чисел, но также убедить наших собственных клиентов в правильности того, что мы делаем, плюс все инструменты для мониторинга качества решений со временем, плюс инфраструктура для получения данных из систем, а также для повторного внедрения решений в системы.
Такова была область деятельности Lokad, и было две вещи, которые мы не могли сделать. Во-первых, мы должны были быть получателем данных, мы не могли искать данные сами. И когда я говорю “искать”, Supply Chain Scientist мог запрашивать данные, мы не просили IT-подразделения наших собственных клиентов выполнять какие-либо сложные преобразования, это было просто выгрузка таблиц, в основном, вы знаете, выбрать все из таблицы, бам, вы делаете это раз в день и готово. Так что это были простые выгрузки, но все же, это было в основном IT-подразделение наших клиентов, которое это делало.
От Специалистов по цепочке поставок не ожидалось, что они будут искать в прикладном ландшафте наших клиентов данные, необходимые для инициативы. Причина этого была очень проста: существует около 20 SQL-диалектов, таких как Oracle SQL, Microsoft SQL Server T-SQL, MySQL, PostgreSQL, DB2 от IBM и т. д. Так что существует около 20 SQL-диалектов. Еще несколько лет назад Специалист по цепочке поставок столкнулся бы с огромными трудностями, потому что даже если то, что этот человек хотел сделать, было крайне простым, например, просто выгрузить одну таблицу, проблема заключалась в том, что этот человек потратил бы буквально десятки часов на поиск в Интернете, чтобы составить тривиальные запросы, и каждый раз, когда возникало сообщение об ошибке, снова этот человек, даже если он в целом был знаком с SQL-базами данных, это было, я бы сказал, огромным препятствием - иметь дело с диалектами системы, которые вы не знали.
В 2023 году проблема решена с помощью ChatGPT. ChatGPT, как помощник программиста, не очень хорош для создания сложных приложений, но когда речь идет о создании простых SQL-запросов в десятках диалектов, он работает очень быстро. Специалист по цепочке поставок будет запрашивать составление SQL-запроса. Этот человек также умный и будет проверять запрос, чтобы убедиться, что он отражает намерение. Здесь речь идет только о преодолении препятствия в поиске синтаксиса, но как только у вас есть правильный синтаксис, представленный вам, все становится понятным.
Если вы хотите проверить это самостоятельно, просто попросите ChatGPT провести вас по настройке git на вашей машине и созданию репозитория git или чего-либо еще, и вы увидите, какой высококачественный ответ вы можете получить.
Это действительно переломный момент, потому что это означает, что внезапно Lokad, которая обучает Специалистов по цепочке поставок, может взять на себя ответственность за поиск данных. И я знаю, что у нас есть, благодаря ChatGPT, инструментарий, чтобы мы не обязывали себя искать данные. Это переломный момент. Вместо того, чтобы просить IT прислать нам данные, мы можем просто добавить IP-адрес в белый список, а затем установить очень безопасное облачное соединение и позволить команде Специалистов по цепочке поставок искать свои собственные данные.
Почему это так важно? Реальность в том, что даже если Lokad требуется всего несколько дней работы для определенной инициативы, мы говорим о, возможно, 10-20 днях работы для значительной инициативы, чтобы получить 20-50 таблиц, нам просто нужно выгрузить таблицу, без пересечений, без сложной фильтрации, это очень просто, однако проблема заключается в том, что у многих наших клиентов есть собственные IT-подразделения, у которых есть огромные задолженности. Я имею в виду буквально годы задержек, и когда у вас есть, скажем, три года задержек, даже если Lokad просит только 10 дней, это 10 дней плюс три года задержек, поэтому даже если мы не находимся в самом конце очереди, если мы находимся просто посередине очереди, то эти 10 дней работы от IT могут занять год, чтобы быть выполненными, и это, я бы сказал, было нашим разочарованием, что большинство задержек, с которыми мы сталкивались, были вызваны не неумением или медлительностью IT, а тем, что у них было так много задолженностей, что им было очень сложно выделить эти 10 дней.
Итак, здесь мы говорим о том, что вместо запроса 10-20 дней работы мы говорим о том, что это может занять менее дня работы, что-то вроде всего нескольких часов, просто чтобы открыть очень безопасный, ограниченный доступ к нескольким системам, которые нам нужны. А затем сами Специалисты по цепочке поставок будут исследовать таблицу, настраивать логику извлечения данных и убедиться, что извлечение данных действительно, я бы сказал, легкое.
Так мы можем сделать, обычно, путем мониторинга производительности. Когда производительность базы данных падает, это означает, что в базе данных происходит много действий, и, следовательно, вы обычно хотите снять нагрузку и отложить процесс извлечения данных. Потому что обычно в Lokad нам нужно обновлять данные ежедневно, но это не супер срочно. Я имею в виду, опять же, это зависит. Есть ситуации, когда у нас очень плотный график, но очень часто, что касается цепочек поставок, если мы откладываем извлечение на 30 минут только потому, что сейчас происходит всплеск активности в этой базе данных, это не проблема.
Первый блок обязательств - это самостоятельное получение данных и, таким образом, устранение основной причины задержки и значительное ускорение инициатив. Опять же, эти задержки очень часто становились основной причиной задержки всей инициативы Lokad для перехода в производство, просто ожидая, чтобы IT могло выделить эти дни.
Второй блок обязательств - это улучшение мастер-данных. И здесь, снова, в прошлом, когда вы сталкиваетесь с каталогом, где есть, скажем, 100 000 описаний продуктов, некоторые из них являются мусором, знаете, может быть 1%. Это много работы, чтобы пройти через эти 100 000 ссылок, определить описания или метки продуктов, которые неверны, или иногда это может быть просто цена, которая полностью несовместима с описанием. Если там написано “винт”, а цена составляет 20 000 долларов, это, вероятно, не просто винт, это, вероятно, что-то другое и т. д. Было много базовых проверок на здравый смысл, которые кажутся очевидными и простыми, но их было очень сложно автоматизировать, и часто не было альтернативы, кроме как просматривать записи, чтобы найти вещи, которые были действительно плохими.
С помощью LLM и, возможно, LLM, который также способен обрабатывать изображения, вы можете делать много вещей, когда речь идет о исследовании, мониторинге и улучшении всего, что связано с мастер-данными. В конкретном случае Lokad, это часть мастер-данных, которая необходима для пилотирования цепочек поставок.
Conor Doherty: Ну, здесь многое есть, спасибо. У меня есть много вопросов, на которые я хочу получить ответ. Я сделаю небольшой шаг назад, потому что, если я могу сжать все это, что вы описываете, и поправьте меня, если я не прав, один Специалист по цепочке поставок с доступом к одному хорошему LLM может сделать огромную работу. Работу, которая до этого момента занимала бы много времени и включала бы множество людей. Теперь, в нестандартной настройке Lokad, сколько больше людей было бы вовлечено? Сколько больше пальцев было бы в пироге? И тогда вы можете говорить об эффективности этого, но просто в терминах численности, в чем разница между Специалистами по цепочке поставок с LLM и, например, S&OP?
Joannes Vermorel: Наши клиенты обычно удивляются тому факту, что даже большая инициатива требует всего двух или трех человек, и всегда одни и те же. У нас есть Lokad, и я очень горжусь тем, что Lokad, как работодатель, удается удерживать людей на довольно долгое время. Так что итоговый результат обычно составляет 1% от начала до конца. Если у нас есть несколько человек, это снова для обеспечения избыточности. Один день вы фокусируетесь на этой части конвейера, а я делаю другую часть конвейера, а на следующий день мы меняемся. Не так, чтобы люди не специализировались, каждый человек обладает компетенцией по всему конвейеру. Есть некоторые вариации, и некоторые люди имеют некоторую особую специализацию, но все же, в целом, люди могут действительно заменять друг друга.
Наши конкуренты совершенно иные. Даже небольшая инициатива включает буквально полдюжины человек. У вас будет менеджер проекта, который просто координирует других ребят, затем у вас есть консультант, дизайнер пользовательского опыта, конфигуратор, администратор баз данных, специалист по сетям и, возможно, программист, инженер по программному обеспечению для неосновных настроек. Опять же, Lokad - это программная платформа, в то время как у большинства наших конкурентов их платформы не являются программными. Поэтому, когда вам нужно что-то, что похоже на программное поведение, вам нужно иметь полноценного программиста, который буквально реализует недостающие элементы с помощью языка общего назначения, такого как Java или Python. Так что Lokad действительно не такая. Я бы сказал, что у наших конкурентов, по умолчанию, их дюжина. Инициативы S&OP могут включать в себя несколько десятков человек, но это не обязательно много разных навыков, это в основном разные люди из разных отделов, и очень часто это не связано с IT.
Итак, Lokad будет, когда я говорю о одном человеке по сравнению с дюжиной, я сравниваю это с нашими конкурентами, которые продают APS, продвинутые системы планирования или системы оптимизации запасов, такого рода корпоративное программное обеспечение.
Конор Доэрти: Спасибо. И вернемся к другому моменту, о котором вы упомянули в начале, когда говорили о Supply Chain Scientists, вы привели пример различных диалектов SQL и того, что Supply Chain Scientist, который может или не может владеть этим конкретным диалектом клиента, будет проверять или контролировать скрипты, которые были автоматически сгенерированы, потому что LLM иногда начинает фантазировать.
Что касается этого, LLM очень часто фантазирует. Опять же, это улучшается, но вы можете спросить LLM с помощью текста: “Найди это скрытое слово, видишь его?” и он скажет “да”, но его там нет. Я знаю, что его там нет, вы знаете, что его там нет. Как можно обеспечить безопасность и контроль качества при использовании LLM в автоматизированном режиме?
Жоанн Верморель: Фантазии, или конфабуляции, как я предпочитаю их называть, действительно возникают, когда вы используете LLM в качестве базы знаний обо всем. Если вы используете LLM, как базу знаний обо всем, то это происходит. Если вы просите медицинские статьи и говорите: “Дайте мне список статей об этой патологии”, он даст вам что-то, что направленно верно. Авторы часто существуют, они публиковали, у них есть материалы, которые были в этой области, они публиковали статьи, которые были в том же духе, но не совсем. Это снова похоже на то, как если бы вы просили ученого вспомнить что-то на ходу.
Это очень сложно, вы бы сказали, и если вы скажете, что вам нужно это сделать, они, вероятно, придумают что-то, что наполовину правдоподобно, с правильными именами коллег или исследователей, правильными полуправильными названиями, вот такие вещи. Так что это ситуация, когда возникают конфабуляции, но вы как бы просите об этом. Я имею в виду, вы просите LLM вести себя как база данных обо всем, поэтому это очень сложно, у вас возникнут такие проблемы.
То же самое с диалектами SQL, вы попробуйте это и получите что-то, это будет приблизительно верно. Если вы спросите: “Я хочу прочитать таблицу”, он сделает “select star from table” и так далее. Он не даст вам, когда вы попросите, скажем, с GPT-4, прочитать таблицу, он не даст вам “drop table”. Он может дать вам синтаксис, который немного неадекватен, поэтому вы проверяете свой SQL-запрос и получаете сообщение об ошибке, а затем делаете небольшую корректировку и все работает. Но видите ли, это все равно направленно верно. Если вы попросите прочитать базу данных, он не создаст команду, которая удаляет таблицу или изменяет права доступа к базе данных.
То же самое, когда вы просите вымышленные знания. Например, если вы спросите: “Хорошо, у меня есть промышленный компрессор мощностью 20 киловатт, какова его цена?” Если вы спросите GPT, он, возможно, скажет что-то вроде 10 000 долларов. Это просто приблизительная оценка. Это буквально выдумано. Это может быть правдоподобно, но это правильно? Вероятно, нет, и это зависит от сотен вариантов, потому что существует так много разных компрессоров для различных ситуаций.
Итак, основная идея заключается в том, что конфабуляции не происходят случайно. Есть определенные виды задач, где они происходят намного чаще. Поэтому я бы сказал, что когда вы просите это, когда вы используете LLM как базу данных для всего, тогда лучше дважды проверить. Это может быть чрезвычайно полезно, оно дает вам, например, для диалектов SQL, это даст вам подсказку о том, какие ключевые слова следует использовать, как выглядит синтаксис, и оно может сделать небольшую ошибку, пропустить запятую или что-то еще, но после нескольких итераций вы получите правильный результат. Особенно потому, что после того, как у вас есть SQL-запрос, вы можете его протестировать на базе данных, вы увидите результат и сможете проверить его, так что у вас есть мгновенная обратная связь для проверки.
Если вы хотите обнаружить, скажем, странные ярлыки продуктов, ярлыки продуктов, которые выглядят подозрительно, например, отсутствует описание продукта, это ваш ярлык продукта, хорошо, это явно неправильно. Но вы можете иметь все виды ошибок. Например, вы можете иметь ярлык продукта, который говорит “tournevis cruciforme”, это на французском, и проблема в том, что это просто на французском, это отвертка с крестообразной головкой, я думаю. И снова, вы можете задавать вопросы, но в какой-то момент это несовершенно, это субъективное решение. Человек тоже может сделать ошибку, поэтому нельзя ожидать, что LLM будет оракулом, способным правильно ответить на каждый вопрос. В какой-то момент, если вы выполняете задачу, такую как проверка 100 000 продуктов вашего каталога на аномалии в ярлыках, у LLM будут ложные срабатывания и ложные отрицательные результаты, как и у человека. Но интересно то, что вы можете измерить уровень ложных срабатываний и ложных отрицательных результатов, а затем решить, стоит ли это того или нет. И очень часто вы получаете нечто довольно хорошее, что дает вам много ценности, даже если оно все еще делает некоторые ошибки.
Conor Doherty: Прогресс, а не совершенство.
Joannes Vermorel: Именно. Если вы можете сократить на 90% проблемы с мастер-данными с помощью чего-то очень дешевого и можете повторно выполнить это буквально за несколько часов без присмотра, это очень хорошо.
Conor Doherty: Есть также стоимость времени, которое не было потрачено на это вручную, и вы могли бы сделать что-то еще, что создает или добавляет ценность. Так что снова, есть прямые и косвенные факторы создания ценности.
Joannes Vermorel: Плюс, реальность заключается в том, что когда вы выполняете очень повторяющуюся задачу в течение одного часа, у вас может быть определенный уровень качества. Когда вы делаете это в течение 100 часов, на 67-м часу, я имею в виду, люди обычно не являются постоянными машинами для выполнения задач. Через несколько часов концентрация снижается, и количество ложных срабатываний и ложных отрицательных результатов, вероятно, возрастает, даже при достаточно добросовестном сотруднике.
Conor Doherty: Спасибо. И я хочу помнить о том, что у нас действительно есть несколько вопросов от аудитории, которые фактически касаются того, о чем я собирался спросить, поэтому я пропущу некоторые вещи, но они будут рассмотрены в вопросах аудитории. Но одна последняя мысль здесь, когда вы говорите о Supply Chain Scientists, AI Pilot и мы вернемся к этому позже в вопросах, но как на самом деле работает оркестрация между клиентом, Supply Chain Scientist, AI Pilot? Имеет ли клиент доступ, взаимодействует ли он с LLM?
Joannes Vermorel: Обычно мы видим, что все числовые рецепты, составленные Supply Chain Scientists, являются AI Pilot. Это то, что управляет цепью поставок ежедневно. Это происходит без присутствия человека, и оно генерирует решения. Теперь, с помощью LLM, оно обрабатывает мелочи подготовки данных и принимает решения по закупкам. Например, предварительное решение будет состоять в запросе у поставщиков их MQS. Вам нужно получить эту информацию, она отсутствует или неактуальна, вам нужно это изменить. LLM может помочь вам с этим. Пост-решение будет состоять в отправке электронной почты с запросом о предполагаемом времени прибытия заказов, если у вас нет EDI или моста, или запросе ускорить или отложить заказ. Это та мелочь, которая происходит после того, как Lokad может сгенерировать решение о запросе на ускорение заказа, но не делает мелочи, которая заключается только в составлении электронной почты и ее отправке.
Все это в основном AI Pilot, и это большой числовой рецепт, который выполняет процесс от начала до конца. Все это реализуется Supply Chain Scientist. Таким образом, это расширение области деятельности для Lokad. Supply Chain Scientist на самом деле является вторым пилотом. И когда я говорю “пилот”, я действительно имею в виду автоматического пилота в самолете. Кстати, в настоящее время самые сложные маневры на самолете выполняются на автопилоте. Когда у вас есть очень страшные аэропорты, например, старый аэропорт Гонконга, с новым, который намного проще, но у них есть аэропорт, буквально находящийся посреди небоскребов, тогда автопилот для этих маневров является обязательным. Так что это делается, это полностью машина, люди просто наблюдают.
Здесь Supply Chain Scientist разрабатывает числовые рецепты, и они являются вторым пилотом. Они принимают решения, они в основном навигируют, чтобы направлять вещи, а затем они разрабатывают план и план курса для пилота. Но в основном Supply Chain Scientist играет роль второго пилота, определяет направления, думает вперед и обеспечивает плавную работу пилота. Но в основном все частотные корректировки делает пилот, а не второй пилот. А клиент будет играть роль капитана.
Знаете, немного похоже на старый телесериал “Звездный путь”, где капитан сидит на стуле и дает высокоуровневые инструкции экипажу. Так что клиент в этой схеме определяет стратегию и общие направления. Затем роль Supply Chain Scientist заключается в том, чтобы реализовать это, а роль пилота - просто выполнить все микрокорректировки, которые необходимы или все ежедневные решения, которые необходимы для цепи поставок, а затем выполнить саму цепь поставок.
Conor Doherty: И это также, чтобы быть ясным, потому что мы не говорили об этом, но это дополнение ко всем автоматизированным количественным задачам, которые уже выполняются. Они выполняются уже много лет. Так что, если кто-то слушает и думает: “О, это просто качественные задачи”, мы говорим о полном цикле. Да, количественные задачи, такие как факторинг экономических факторов, генерация распределения, закупки, ценообразование, уже также осуществляются с помощью искусственного интеллекта и автоматизации.
Так что Supply Chain Scientist контролирует оба этих типа консолей, количественные и качественные.
Joannes Vermorel: Именно. И причина, по которой Lokad наконец-то приняла этот ключевой термин ИИ, это потому, что мы теперь добавляем, вносим в смесь LLM. У нас уже было машинное обучение с дифференцируемым программированием и стохастической оптимизацией, но теперь мы добавляем LLM сверху. И это буквально очень полный набор инструментов.
Эффект заключается в том, что для клиентов поставочных цепей, которые могут работать без присмотра в течение недель. Люди удивляются, насколько долго можно работать без присмотра, когда у вас есть эти экономические стимулы. Красота в том, что вам не нужно делать какие-либо микро-корректировки. Например, корректировки прогноза для большинства наших клиентов полностью отсутствуют. И большая часть других корректировок также выполняется полностью автоматически, такие как введение новых продуктов, вывод из ассортимента старых продуктов, введение новых поставщиков и вывод из ассортимента неэффективных поставщиков.
Так что все это является своего рода делом обычным, и когда рецепты выполняются правильно, они уже требуют не так много вмешательств. Но с этим ИИ-пилотом, который включает LLM, добавление нового поставщика в смесь, все эти вещи могут быть еще менее ручными, чем раньше.
Conor Doherty: Хорошо, Жоанн, спасибо. Мы уже идем около 40 минут. У нас есть вопросы, так что я перейду к ним сейчас. Но прежде чем мы это сделаем, в качестве своего рода итога или завершающей мысли, снова в контексте гораздо более крупной беседы, которую мы провели месяц назад и которую мы ведем сегодня, каковы основные выводы для практика поставочной цепи и, скажем, исполнительных команд, которые надзирают за средним, обычным практиком поставочной цепи? Какой призыв к действию или вывод для них?
Joannes Vermorel: Я считаю, что через десять лет эта концепция ИИ-пилотов, возможно, под другим названием, станет нормой. Возможно, это станет нормой, и люди будут просто говорить “поставочная цепь”, а не “ИИ-пилоты для поставочной цепи”. И будет ясно, что в поставочной цепи есть эти ИИ-пилоты. Точно так же, как когда вы говорите о компьютере, вы не говорите, что у вас есть ЦПУ, у вас есть память, это предполагается, что у вас есть ЦПУ в вашем компьютере, поэтому вы даже не упоминаете это.
Мое мнение заключается в том, что примерно через десять лет эти функции будут широко автоматизированы, и Lokad, с помощью этих ИИ-пилотов, предлагает пакетное решение, которое просто делает это с помощью Supply Chain Scientist. Для наших клиентов это означает, что практика поставочной цепи меняется по своей природе. Это означает, что у них есть эти ИИ-пилоты, которые могут освободить много пропускной способности. И мы уже освобождали пропускную способность для процесса принятия решений или сложных вычислений. Но теперь мы также освобождаем время, которое раньше тратилось на мониторинг списка SKU, списка поставщиков, списка клиентов, чтобы поддерживать актуальные, чистые и здравомыслящие мастер-данные. Все это также исчезает и устраняет необходимость в таких ручных вмешательствах, которые очень часто не имели даже действительно количественного характера. Вам приходилось исправлять ярлык, исправлять запись, удалять дубликат или что-то в этом роде. Все это, снова же, Lokad позаботится об этом.
Итак, основной вывод состоит в том, что это огромное повышение производительности. Я думаю, что с некоторыми клиентами мы буквально достигаем 90% сокращения штатного расписания для рутинных задач. Реальность в том, что теперь у вас есть больше времени, и вы на самом деле делаете то, что гораздо сложнее автоматизировать, и я считаю, что это приносит больше ценности. Когда вы думаете о стратегии, вы тратите гораздо больше времени на размышления о вариантах, над чем следует работать, вместо того, чтобы снова тратить время на электронные таблицы.
Так что потратите много времени на размышления о сложных проблемах, затем общайтесь с поставщиками и клиентами, чтобы провести глубокие беседы, чтобы вы могли организовать свою собственную поставочную цепочку, чтобы удовлетворить поставщика и, таким образом, он будет готов предложить вам лучшие цены, у вас будет лучшее качество, лучшая надежность и т. д. Если вы организуете себя так, чтобы соответствовать потребностям ваших поставщиков, это может показаться немного противоположным, где “О, поставщики, я - клиент, они должны приспосабливаться ко мне”. Но если вы можете лучше удовлетворить потребности своих поставщиков, это совместная работа, и у вас может быть большая надежность и лучшие цены.
И вы можете проделать то же самое с вашим клиентом, потому что здесь должно происходить то же самое сотрудничество. И снова, для этого требуется много разумных обсуждений, и это то, что сейчас выходит за рамки возможностей этих LLM. Поэтому я считаю, что в Lokad мы можем автоматизировать задачи, которые нам нравятся, низкую стоимость и монотонные административные задачи, и позволить людям заниматься высокоуровневыми полустратегическими вещами. Я говорю полустратегическими, потому что вы будете общаться с одним клиентом за раз, а затем разрабатывать стратегию, которая заключается в том, чтобы подвести итоги всего этого, создать видение, а затем поддерживать руководство поставочной цепочкой, чтобы у них была очень четкая, обоснованная стратегия для их компании.
Conor Doherty: Итак, еще раз, чтобы привести два примера, чтобы представить это, низкоуровневые решения, просмотр электронной таблицы Excel и говорить: “О, здесь написано, что это должно быть черное”, автоматическая корректировка, это тривиально, это монотонно, это не стоит вашего времени. “Следует ли мне открыть склад в Гамбурге?” Стратегический.
Joannes Vermorel: Да, это стратегический вопрос. Плюс проблема в том, что есть так много вариантов. Вы можете сказать, склад, должен ли я покупать, арендовать, какие виды контрактов, какая степень механизации, нужно ли мне заключать контракт на оборудование, чтобы я мог его вернуть, следует ли мне арендовать оборудование или нет. Я имею в виду, есть сотни вопросов, и очень часто все эти вопросы, я имею в виду, когда люди должны тратить 99% своей умственной энергии на административные задачи, у них не остается времени на эти большие вопросы.
Видите ли, если бы я применил закон Паркинсона, люди бы сказали, я видел много компаний, где если бы я посчитал общее количество минут, потраченных на что-то вроде ABC-классов, это время составляет каждый год мы говорим о человеко-летах, вложенных в ABC-классы. И когда дело доходит до решения о новом складе, мы говорим о неделях времени. Но вы видите дисбаланс, когда люди тратят буквально годы человеческого времени на нечто абсолютно бессмысленное, как ABC-классы. И когда дело доходит до инвестиции в 50 миллионов евро для открытия склада, это буквально недели времени, и затем бац, принимается решение. Вы видите, это должно быть наоборот.
Conor Doherty: Хорошо, спасибо за это. На этой ноте я перейду к вопросам аудитории. Большое спасибо. Продолжайте задавать вопросы, пока я не остановлюсь. Итак, Джоаннес, вопрос от Массимо. Можете ли вы подробнее рассказать о том, как ИТ может использовать пилотные проекты ИИ для сокращения отставания и почему вы считаете, что этот подход следует предложить?
Joannes Vermorel: Пилотные проекты ИИ не предназначены для сокращения отставания в ИТ. Они предназначены для справления с тем фактом, что в ИТ накопилось множество отставаний за годы. Так что наш план в Lokad не заключается в сокращении отставания в ИТ. Это требует переосмысления ИТ, как это сделала Amazon. Об этом можно было бы рассказать в другой эпизоде. Я бы сказал, поищите меморандум Джеффа Безоса 2002 года о API в Amazon. Главное заключается в том, что все отделы в современной компании нуждаются в огромном количестве программного обеспечения. Каждое подразделение - маркетинг, финансы, бухгалтерия, цепочка поставок, продажи - все они хотят получить огромное количество программных инструментов, и все это ложится на плечи ИТ. ИТ не справляется с этим.
Итак, моя точка зрения заключается в том, что в Lokad мы являемся специалистами в области цепочки поставок. Мы не собираемся решать все задачи в области маркетинга, продаж, бухгалтерии и т. д. Мы говорим, что с помощью LLM мы можем освободить ИТ от заботы о Lokad. Главное заключается в том, что мы переходим от необходимости, скажем, 10-20 дней работы ИТ для запуска инициативы Количественной цепочки поставок, создания конвейера, до всего лишь нескольких часов. Так что мы не решаем проблему отставания. ИТ делает то, что ИТ делает. Они также могут получить выгоду от LLM, но в их случае ситуации намного более разнообразны и сложны.
Так что мое предложение заключается не в том, что LLM на самом деле может помочь ИТ сократить свои отставания. Это просто способ для Lokad, в этом конкретном случае, сказать: “Вместо того, чтобы добавить 20 дней к отставанию, мы просто добавляем примерно четыре часа, и мы закончили”. Вот как мы справляемся с отставанием. И более общим образом, решение проблемы многолетнего отставания заключается в том, что каждое подразделение должно внутренне освоить большую часть программного обеспечения. Вы видите, что многолетнее отставание заключается в том, что компании в целом требуется слишком много от ИТ. В каждом подразделении должны быть цифровые практики - маркетинг, продажи, бухгалтерия и т. д. Вы не должны просить ИТ решать все эти проблемы за вас. У вас должны быть цифровые эксперты в каждой области, чтобы делать это. И это именно суть этого меморандума 2002 года, если я не путаю, Джеффа Безоса его команде. Это очень известный меморандум. Вы можете набрать “известный меморандум Безоса”, потому что он говорил, в сущности, “У вас есть две недели, чтобы разработать план, чтобы каждое подразделение могло предоставить все свои данные, чтобы у нас не было такого рода изоляции и игр на власть в компании, в Amazon”.
И Безос заключал: “Каждый менеджер, у которого через две недели не будет плана на моем столе, будет уволен или что-то в этом роде”.
Conor Doherty: Хорошо, спасибо. Следующий комментарий, и это вопрос, который я не задавал, потому что я видел, что он упоминается в комментариях, поэтому он сформулирован как комментарий, но примите его как вопрос. Это от Джесси. “Один ученый по цепочке поставок плюс один LLM все равно звучит как сопилот. Так что снова разграничьте пилотный проект ИИ и сопилота”.
Joannes Vermorel: Причина, по которой мы говорим, что это пилотный проект, заключается в том, что у нас есть клиенты, где в течение нескольких недель все решения генерируются и затем выполняются без присмотра. И когда я говорю без присмотра, я действительно имею в виду это. Во время блокировок 2020 года у нас даже была компания, где в течение 14 месяцев все белые воротнички буквально сидели дома, не работали, получали зарплату от государства, потому что государство давало субсидии в Европе. Несколько государств давали субсидии, чтобы в основном сидеть дома и не работать. И вот такая была ситуация. Так что у нас было это, и когда у вас есть цепочка поставок, которая работает практически без присмотра в течение 14 месяцев, я называю это пилотным проектом, а не сопилотом. Если никто не контролирует числа, генерируемые системой, я действительно считаю это пилотным проектом.
Но тогда мы не использовали LLM. И это была ситуация, когда данные были чистыми, и не было необходимости в значительном улучшении управления этими основными данными. И это был клиент, у которого была очень высокая зрелость в интеграции EDI и тому подобное. Так что то, что требовалось до и после, было очень ограничено.
В любом случае, вернемся к вопросу о сопилоте. Большинство конкурентов Lokad говорят, что они делают сопилота. И, действительно, это совершенно другая вещь. Lokad, ученый по цепям поставок, использует язык программирования. Так что, когда мы используем LLM, это для генерации, чтобы помочь нам создавать части программы. Вот для этого мы его используем.
Итак, LLM используется для генерации фрагментов программ, которые могут быть диалектами SQL или чем-то еще. Затем мы проектируем пилот, и затем пилот работает без присмотра.
Наши конкуренты, особенно те, кто говорит, что они собираются привнести разговорный ИИ, разговорный пользовательский интерфейс на рынок, делают совершенно другое. Они обычно используют метод извлечения и дополнения (RAG). Так что они составляют подсказку. Это буквально все наши конкуренты, которые говорят, что они сейчас делают ИИ с LLM в сфере цепей поставок. Они составляют, скажем, десяток подсказок, соответствующих различным сценариям. Затем после подсказки они внедряют данные, полученные из базы данных, например, базовую описательную статистику. Таким образом, они внедряют несколько десятков чисел, средние продажи за последнюю неделю, последний месяц, последний год и так далее, базовую статистику, соответствующую сценарию. Затем они добавляют дополнительный запрос от пользователя, и затем LLM завершает ответ.
Видите ли, LLM сводится только к завершению текста. Так что вы составляете текст, и он его завершает. А метод извлечения и дополнения, часть извлечения заключается только в извлечении некоторых чисел из базы данных, а затем составлении. Но суть в том, что, хорошо, теперь у вас есть что-то, где вы можете задать вопрос. Но реальность в том, что если вы не без понятия, вы можете прочитать числа прямо с экрана. Здесь нет никакой магии. Так что LLM видит числа так же, как вы можете видеть их на своем отчете. В основном он может отвечать только на вопросы, на которые можно легко ответить с помощью панели инструментов.
Да, если вы не очень хорошо знакомы с определением каждого числа, он может прояснить это для вас. Но у вас также может быть, и вот где Lokad это делает, подсказка, которая просто дает вам краткое описание, прикрепленное к каждой панели инструментов, для каждого числа, которое присутствует на панели инструментов. И это будет выполнять ту же самую роль, без участия ИИ.
Итак, в итоге я очень-очень скептически отношусь к этим разговорным ИИ, к этим сопилотам, потому что, по сути, они являются трюками, которые наложены на существующие системы, которые никогда не были разработаны для какой-либо системы машинного обучения, даже для классического машинного обучения, не говоря уже о LLM.
Вот почему я говорю, насколько мне известно, все наши конкуренты делают сопилотов, где, по сути, у них есть что-то вроде чат-бота, который находится поверх панелей инструментов. Но он не выполняет никакой автоматизации. Он не позволяет вам автоматизировать какие-либо ИИ-пилоты. Это, да, трюк поверх устаревшей системы.
Conor Doherty: Хорошо, спасибо. Я продолжу. Вот вопрос от Кайла. “Можете ли вы обсудить важность анализа процессов перед внедрением модели ИИ?” Я рассмотрю его в контексте цепей поставок.
Joannes Vermorel: Как удивительно, анализ процессов очень важен. Но не обязательно в тех аспектах, в которых люди думают. Реальность заключается в том, что, особенно в цепях поставок, компании имели четыре или пять десятилетий, чтобы изобрести множество выдуманных процессов. И я намеренно говорю “выдуманных”. Цепь поставок - это игра бюрократии. Она имеет бюрократическую основу. Игра в цепи поставок за последние пять десятилетий была способом организации труда, потому что нельзя иметь одного человека, который занимается всеми SKU, всеми складами, всеми местоположениями, всеми продуктами. Поэтому вам нужно разделить и победить проблему, распределяя нагрузку на десятки, возможно, сотни людей для крупных, очень крупных компаний.
Таким образом, вы оказываетесь в ситуации, когда 90% ваших процессов отражают возникающие сложности, вызванные тем, что нагрузка распределена между большим количеством людей. Таким образом, это случайные процессы, а не существенные процессы. Поэтому я бы сказал, да, вам нужно провести анализ процессов, но будьте осторожны, 90% существующих процессов не решают фундаментальную проблему, с которой сталкивается ваша цепочка поставок, а являются случайными проблемами, созданными тем, что вам нужно много людей для решения 10% проблемы, которую нужно решить.
В отраслях, таких как химическая переработка, где есть много потоков и зависимостей, все очень сложно. Например, когда у вас есть химические реакции, у вас будут побочные продукты. Так что, когда вы производите соединение, вы производите что-то еще. Это что-то еще можно продать или использовать для другого процесса. Вам нужно согласовать все это. У вас есть масса ограничений, у вас есть процессы, работающие пакетами, и процессы, работающие непрерывно. Это очень сложно.
Но реальность заключается в том, что большинство процессов, вместо того чтобы сосредоточиться на физической стороне проблемы, факте того, что, скажем, в отрасли процессов у вас есть химические реакции, у которых есть очень конкретные входы и выходы, и все это очень, очень четко определено и известно. Вместо того, чтобы сосредоточиться на базовом уровне физической реальности вашего бизнеса, анализ процессов может просто создавать процессы, которые исчезнут, когда вы настроите AI Pilot.
Интересно то, что когда вы делаете это в стиле AI Pilot, вам больше не нужен этот подход “разделяй и властвуй”. Это единый набор числовых рецептов, решающих проблему от начала до конца. Так что все эти проблемы координации, которые решались с помощью множества процессов, просто исчезают.
Мой опыт говорит о том, что 90% этих процессов просто исчезнут к моменту завершения проекта. Вот почему я говорю, что очень важно сосредоточиться на базовом физическом уровне вашей цепочки поставок, в отличие от выдуманных процессов, которые просто существуют для координации многочисленных команд. Эти вещи не будут модернизированы, они будут заменены AI Pilot.
Conor Doherty: Спасибо. И на самом деле, приведенный вами пример в этом ответе хорошо подходит. Итак, от зрителя Дурвеша, у вас есть планы по открытию исходного кода Envision для образовательных или малых бизнесов? И можно ли его программировать с правилами, чтобы это было полезно для B2B-бизнесов, таких как химическая промышленность, требующая обширного ручного ввода?
Joannes Vermorel: Да, у нас есть планы по открытию исходного кода Envision в какой-то момент. Но позвольте мне сначала объяснить, почему. В этом мире корпоративного программного обеспечения у нас есть общедоступная документация для Envision. У большинства моих коллег есть языки, специфичные для отрасли (DSL), но они не документированы публично. Dassault Systèmes приобрела другую компанию под названием Quintiq. В то время у них был DSL, который не был документирован публично. Так что, в сфере цепочки поставок есть другие компании, у которых есть DSL, и они не являются общедоступными. В Lokad мы документируем все публично, и у нас есть бесплатная песочница для Envision. У нас даже есть бесплатные мастер-классы, чтобы вы могли научиться или изучить Envision с помощью упражнений. Так что мы делаем гораздо больше.
Теперь, когда речь идет о открытии исходного кода языка, это, конечно, часть плана, но пока что слишком рано. Почему? Потому что Envision все еще находится в быстром развитии. Вы видите, одна из проблем, с которой вы сталкиваетесь при открытии исходного кода компилятора, компилятор - это программное обеспечение, которое позволяет вам компилировать ваш скрипт во что-то, что выполняется. Как только вы открываете исходный код своего компилятора, это означает, что люди будут использовать код Envision, в случае Lokad, в дикой природе. И Lokad теряет возможность автоматически обновлять эти скрипты. Реальность заключается в том, что за последнее десятилетие Lokad изменила сотни раз язык программирования Envision. Этот язык нестабилен. Если вы посмотрите на мою книгу “Количественная цепочка поставок”, которая сейчас примерно шесть лет, синтаксис Envision сильно изменился. Вы можете увидеть остаточный синтаксис, который больше не существует в Envision.
Итак, как мы справляемся с этой постоянной сменой синтаксиса? Ну, каждую неделю в Lokad у нас есть еженедельные релизы по вторникам, и то, что мы применяем, это автоматические переписывания для всех скриптов Envision, которые работают на платформах Lokad. Таким образом, одно из ключевых свойств Envision - это очень высокая аффинность к статическому анализу. Статический анализ, кстати, является разделом языкового проектирования и анализа языка. Когда я говорю о языке, я имею в виду компьютерный язык, который позволяет иметь свойства программ без их запуска. И через статический анализ мы можем буквально автоматически переписать существующий скрипт из старого синтаксиса в новый синтаксис. И мы делаем это автоматически по вторникам. И обычно, когда мы делаем обновление, у нас будет в течение нескольких дней старый и новый синтаксис, которые оба принимаются. Мы делаем автоматические переписывания, и затем, когда мы видим, что старый синтаксис больше не существует, мы с помощью флага функциональности фиксируем факт того, что существует только новый синтаксис.
В Lokad мы уже развернули более 200 таких автоматических переписываний. Обычно мы выпускаем их каждый вторник, но обычно у нас бывает около двух переписываний в месяц, и мы делаем это уже десять лет. Пока этот процесс продолжается, Lokad не может реалистично выпустить Envision в открытый доступ. Это произойдет в свое время, но я не хочу повторить огромную ошибку Python. Обновление с Python 2 на Python 3 заняло сообществу Python десять лет, и это было невероятно болезненно. Я имею в виду, компании занимались обновлениями в течение нескольких лет, это был кошмар, который длился десять лет. Так что это было действительно, действительно неправильно. Даже Microsoft с обновлением от C# и .NET Framework до .NET Core заняло половину десятилетия, и это было большой, большой головной боли. И это снова проблема того, что когда у вас есть компилятор с открытым исходным кодом, вы не контролируете код. Поэтому, если вы хотите внести изменения в язык, вам нужно сотрудничать со своим сообществом. Это делает процесс очень медленным, очень болезненным, и в конце концов вы никогда не устраните все плохие особенности вашего языка.
Если мы посмотрим на Python, то, например, введение объектно-ориентированного программирования в Python, синтаксис, ах, он громоздкий. Можно почувствовать, что Python не был разработан с учетом объектно-ориентированного программирования. Это было позднее дополнение в конце 90-х, и синтаксис довольно плохой, и теперь он будет там навсегда. И, кстати, у каждого языка есть такое. В C# есть ключевое слово volatile, которое больше не имеет никакого смысла. C++ навсегда застрял с множественным наследованием. Это была ошибка. Множественное наследование - это плохое проектирование, которое усложняет все и так далее. Единственный способ избежать таких больших ошибок, Lokad, мы сделали много больших ошибок в проектировании Envision, но мы исправляем их после одной, и мы все еще находимся в процессе, особенно когда у нас появляются новые парадигмы. Например, дифференцируемое программирование было большой новой парадигмой, и нам пришлось переосмыслить сам язык, чтобы адаптироваться к этой парадигме.
Кстати, есть такое большое предложение для Swift, предложенное Apple, чтобы сделать дифференцируемое программирование полноправным гражданином в Swift. Но это, вероятно, не произойдет в ближайшее время. Это как крупная, крупная перестройка. В настоящее время язык, который наиболее близок к тому, чтобы иметь дифференцируемое программирование как полноправного гражданина, это Julia, и даже там это много пластырей.
Conor Doherty: Спасибо еще раз. Еще три вопроса. Следующий от Виктора. Он широко касается искусственного интеллекта. Как искусственный интеллект решает случайные узкие места, учитывая, что он работает с большими наборами данных для прогнозирования вероятных сценариев или повторяющихся проблем?
Joannes Vermorel: Давайте будем ясными, когда мы говорим об искусственном интеллекте, это совокупность техник. В Lokad у нас обычно есть LLM, дифференцируемое программирование и стохастическая оптимизация. Дифференцируемое программирование используется для обучения, стохастическая оптимизация - для оптимизации при наличии ограничений в условиях неопределенности, вероятностные модели, которые обычно регрессируются с помощью дифференцируемого программирования, и LLM используется для создания универсального, устойчивого к шуму шаблонного движка.
Когда вы подходите к управлению цепочкой поставок с помощью вероятностных инструментов, большинство задач, которые подразумеваются этим вопросом, просто исчезают. Вот в чем красота вероятностного прогнозирования: эти прогнозы не более точные, они просто намного устойчивее к фоновому шуму в цепочке поставок. Когда вы сочетаете вероятностное прогнозирование со стохастической оптимизацией, вы в значительной степени устраняете необходимость в ручном вмешательстве. И когда я говорю “в значительной степени”, я имею в виду, что для большинства клиентов это полностью исключается. И теперь у нас остаются задачи, которые требуют просмотра текста и работы с ним, и это LLM. И снова, то, что я описал, это Lokad, у нас есть эти автоматизированные AI-пилоты, и если есть ручное вмешательство, то это не сводится к вводу клерикальной записи в систему, это ввод стратегической переработки числового рецепта, который обычно представляет собой глубокую модификацию самой логики для отражения пересмотренной стратегии. Это не будет, знаете ли, мелочью. Обычно это будет что-то, что является своего рода фундаментальным и изменяет саму структуру реализованной логики.
Conor Doherty: Этот вопрос от Ахсана. Не могли бы вы объяснить, как искусственный интеллект, в частности, ускоряет заказ? Сможет ли он выполнять транзакции в системе ERP на основе устных команд?
Joannes Vermorel: Устные команды - не правильный подход к этой проблеме. Если вам нужно ускорить ввод данных, то голос - это очень низкоскоростной канал. Вы печатаете быстрее, чем говорите, если только вы не очень плохо печатаете. Таким образом, вы не сможете получить такую выгоду. Если ваш интерфейс пользователя правильно разработан с использованием клавиатуры, вы будете быстрее, чем при использовании голосовых команд. Я это очень хорошо знаю, потому что 20 лет назад я работал в AT&T Labs над системами распознавания речи промышленного уровня. Было множество приложений, где это не сработало. Распознавание речи работало, но на самом деле ваши руки на клавиатуре были просто быстрее. Голос использовался только в случаях, когда руки были грязными или занятыми. В остальных случаях клавиатура работает быстрее.
Вернемся к вопросу, сначала вам нужно отфильтровать заказы. Здесь у нас есть процесс принятия решений, где вы хотите решить, какие заказы нужно ускорить. Это классический подход Lokad, это чисто квантитативный процесс принятия решений. Вам нужно решить, да или нет, требуется ли ускорение процесса для этого заказа. Мы делаем это с помощью дифференцируемого программирования, стохастической оптимизации. Именно так мы приходим к правильным решениям.
Как только у нас есть это, у нас автоматически каждый день есть решения для заказов. Речь не идет о том, чтобы кто-то давал устные указания для этого. Это будет частью набора числовых рецептов, с помощью которых мы будем вычислять оптимизированные заказы. С течением времени мы понимаем, что некоторые заказы были переоценены или недооценены, и мы будем просить отложить или ускорить соответственно. Часть LLM заключается в использовании этого квантитативного решения, где у вас есть двоичный флаг, который говорит “пожалуйста, ускорьте”, чтобы сгенерировать электронное письмо с соответствующим контекстом, отправить его поставщику с просьбой “подтвердите, что вы можете это сделать”, и затем поставщик, надеюсь, подтвердит и скажет “да”, “нет”, “может быть, я могу” или “вот что я могу предложить”.
LLM автоматизирует чат с поставщиком. Искусственный интеллект не решает вопрос об ускорении заказа. Это чисто квантитативное решение, которое должно рассматриваться с помощью квантитативных инструментов, дифференцируемого программирования, стохастической оптимизации. LLM предназначен для взаимодействия с поставщиком, который часто использует неструктурированный канал, например, электронную почту.
Если вы думаете о голосовых командах, это не сработает. Это слишком медленно. Мне довелось работать с командами, которые буквально 20 лет назад впервые представили на рынок системы голосового распознавания высокого качества. Но суть в том, что вы не будете использовать эти технологии искусственного интеллекта для этого. Голосовые команды не имеют пропускной способности, чтобы делать то, что вы хотите сделать.
Conor Doherty: Кстати, когда мы говорим о стохастической оптимизации и дифференцируемом программировании, у нас есть обширные видео-ресурсы по этим темам. Мы не раскрываем их, потому что это трехчастная серия (часть 1, часть 2 и часть 3) о дифференцируемом программировании, но мы не игнорируем их. Они были рассмотрены, и я любезно направляю зрителей, которые хотят узнать больше об этом, ознакомиться с ними и затем собрать все эти части вместе.
Последний вопрос от Исаака. Как клиент, который сейчас изучает Envision, меня интересуют его возможности интеграции, в частности с GitHub. Можете ли вы обсудить потенциал Envision для поддержки интеграции с GitHub, особенно для таких приложений, как объяснение блоков кода на естественном языке или определение изменений между версиями? Наконец, есть ли планы в ближайшем будущем представить помощника Envision?
Joannes Vermorel: Краткий ответ - да, да и да. Сроки очень различаются в зависимости от компонентов, о которых мы говорим. Что касается использования LLM для создания практически помощника, подобного GitHub copilot, но это будет Lokad copilot для кодов Envision, мы уже работаем над этим. Очень интересно то, что благодаря тому, что это DSL, где мы контролируем, у нас полный контроль над учебными материалами. Это очень круто, потому что это означает, что в день, когда нам удастся успешно запустить этот LLM в производство, когда мы изменяем синтаксис, мы повторно запускаем процесс обучения с обновленным синтаксисом, и у нас всегда будет помощник, который предоставляет вам актуальный синтаксис Envision. В отличие от GitHub copilot, который предоставляет вам синтаксис Python, синтаксис C#, синтаксис Java.
Потому что, видите ли, Java существует уже 25 лет, Python существует уже более 30 лет, C# существует уже 22 года или что-то в этом роде. Поэтому, когда вы просите компилятор GitHub написать код для вас, проблема в том, что он дает вам один вкус полу-свежести этих языков, но на самом деле не совсем свежий. И иногда вам не нужен свежий вкус, потому что ваша среда не соответствует этим самым свежим версиям, которые вы еще не поддерживаете.
Мы работаем над целым рядом супер-естественных функций, таких как комментирование моего кода, объяснение моего кода, завершение моего кода. Мы также думаем о множестве расширенных действий с кодом, которые очень специфичны для рабочих процессов, которые происходят в Lokad. Например, мы работаем над возможностью автоматизировать создание панелей управления данными о состоянии. Это очень типичная задача.
Панели управления данными о состоянии в основном являются инструментами, которые проверяют, что данные, которые мы получаем, являются правильными. И у нас есть много галочек и знаний о том, что нужно проверять, потому что проблемы, с которыми вы столкнетесь в данных ERP, всегда примерно одинаковы. Когда мы проверяем данные на правильность, поступающие из ERP, у нас, ученых по цепочке поставок, есть свои собственные методы обучения, чтобы знать, на что обращать внимание, и у нас есть свои собственные рецепты, то есть человеческие рецепты, о том, что следует реализовать, что следует проверить, и мы в значительной степени можем автоматизировать это с помощью LLM. Так что это то, над чем мы работаем в Lokad.
Мы работаем над Lokad copilot. Чтобы сделать Envision более дружелюбным с GitHub, мы уже выпустили расширение Visual Studio code с открытым исходным кодом. Вы уже можете поместить код Envision в репозиторий git. Просто создайте файл .nvn, сделайте коммит и вы готовы. Если вы хотите редактировать код с красивой подсветкой кода, вам понадобится расширение Visual Studio code. Если вы ищете расширение Visual Studio code для Envision от Lokad, есть одно, которое полностью открытое и вы получите подсветку кода.
В будущем мы планируем предоставить код Envision, который находится в учетной записи Lokad, как репозиторий git. Способ хранения кода Envision в учетной записи Lokad практически такой же, как у репозитория git. Он версионируется практически так же. Он не организован точно так же, как git, снова я не собираюсь углубляться в технические причины. Git очень агностичен к языку. Если вы работаете только с одним конкретным языком, вы можете быть умнее и делать все возможные вещи, которые невозможны в общем случае. Но главное, что код Envision полностью версионируется. Мы могли бы предоставить репозиторий git, который позволяет экспортировать весь ваш код из учетной записи Lokad в репозиторий git, а, возможно, позже - в обратном направлении, чтобы обеспечить двустороннюю синхронизацию. Git - это децентрализованная система, где каждый репозиторий git - это как целое, у вас есть полная копия, и поэтому вы можете получать изменения из удаленного репозитория, но отправлять свои изменения в удаленный репозиторий. Итак, в какой-то момент мы, вероятно, сначала представим экспорт, а затем представим повторный импорт, но это займет время. Мы еще не там. Это часть дорожной карты, но у нас пока нет временных рамок для этого.
Conor Doherty: Стоит отметить, что несколько человек в комментариях сказали, что они изучают Envision. Мы создаем серию учебных пособий, которые выполняются в сотрудничестве с Университетом Торонто и несколькими другими, которые находятся в процессе разработки. Есть бесплатные ресурсы, и мы можем предоставить ответы, если люди захотят. Для тех, кто хочет учиться, наши ученые по цепочке поставок вкладывают много усилий в эти мастер-классы. Они бесплатно доступны на нашем веб-сайте.
Joannes Vermorel: Для тех, кто не заинтересован в том, чтобы самостоятельно стать ученым по цепочке поставок, Lokad может предоставить ученого по цепочке поставок в рамках предложения AI Pilot.
Conor Doherty: Вот все вопросы, Джоаннес. Большое спасибо за ваше время и большое спасибо за просмотр. Надеюсь, это было полезно, и увидимся в следующий раз.
