00:00:00 Введение в интервью
00:01:01 Влияние ИИ на традиционные рабочие места
00:04:36 Автоматизация с помощью ИИ в цепях поставок
00:09:08 Необходимость единой системы в 2012 году
00:10:30 Внедрение решений обратно в системы
00:13:08 Избегание проблемы галлюцинаций в ИИ
00:16:11 Влияние и задержки из-за отставания в ИТ
00:20:04 Сравнение подходов Lokad и других поставщиков
00:23:06 Обсуждение галлюцинаций и выдумок LLM
00:30:38 Подчеркивание прогресса важнее совершенства в ИИ
00:33:00 Получение недостающей информации и сроков доставки заказа
00:36:17 Количественные задачи и LLM в цепях поставок
00:38:28 Будущее AI-пилотов в цепях поставок
00:41:18 Ценность диалогов и автоматизация задач низкой ценности
00:44:57 Использование AI-пилотов для сокращения отставания
00:49:00 AI-пилот против копилота и сценарий локдауна
00:53:36 Скептицизм в отношении разговорного ИИ и анализ процессов
00:57:18 Понимание бизнес-реальности и замена процессов ИИ
01:00:12 Проблемы открытого исходного кода Envision
01:06:21 Подход ИИ к узким местам и цепям поставок
01:09:17 Неэффективность устных команд и автоматизация заказов
01:14:12 Учёный по цепям поставок как копилот для AI-пилота
01:17:32 Проверка правильности данных и автоматизация проверок с помощью LLM
01:20:15 Приведение Envision в соответствие с Git
01:21:14 Бесплатные ресурсы для изучения Envision
Резюме
В диалоге между генеральным директором Lokad, Жоанном Верморелем, и главой коммуникаций Конором Дохерти обсуждается влияние ИИ на управление цепями поставок. Верморель подчёркивает достижения в области ИИ и больших языковых моделей, которые революционизировали автоматизацию задач. Он представляет AI-пилоты, предложение Lokad, которое автоматизирует принятие решений и выполнение канцелярских задач, благодаря использованию фирменного языка программирования Lokad, Envision. Верморель также обсуждает потенциал ИИ для автоматизации задач, связанных с мастер-данными, и сравнивает подход Lokad с конкурентами. Он предсказывает, что AI-пилоты станут нормой в управлении цепями поставок, что приведёт к значительному повышению производительности. Разговор завершается сессией вопросов и ответов.
Расширенное резюме
В недавнем разговоре между Конором Дохерти, главой коммуникаций в Lokad, и Жоанном Верморелем, генеральным директором и основателем Lokad, дуэт углубился в преобразующую роль искусственного интеллекта (ИИ) в управлении цепями поставок. Обсуждение, являющееся продолжением предыдущего разговора о влиянии ИИ на занятость, было сосредоточено на потенциале ИИ в качестве автономного пилота для принятия решений в цепях поставок.
Верморель начал с того, что выделил знаковое достижение генеративного ИИ и больших языковых моделей (LLM) в 2023 году. Эти достижения, как он объяснил, революционизировали автоматизацию задач, связанных с текстом, таких как чтение электронных писем или категоризация жалоб. 2023 год был особенно значим, так как в нём произошло значительное снижение операционных затрат на методы обработки естественного языка для компаний. Верморель предсказал, что это приведёт к автоматизации многих внутренних функций поддержки, при этом управление цепями поставок окажется на переднем плане.
Затем Верморель представил AI-пилоты, предложение Lokad, которое автоматизирует процесс принятия решений и выполняет рутинные канцелярские задачи. Он подчеркнул уникальный подход Lokad, при котором один специалист по цепям поставок может полностью взять на себя инициативу. Это становится возможным благодаря фирменному языку программирования Lokad, Envision, предназначенному для предиктивной оптимизации цепей поставок. Однако Верморель признался, что ранее Lokad сталкивался с трудностями в поиске данных и работе с различными диалектами SQL.
Введение GPT-4, как объяснил Верморель, стало переломным моментом для Lokad, позволив автоматизировать составление SQL-запросов. Эти запросы затем могут быть проверены специалистом по цепям поставок и протестированы для обеспечения точности. Это развитие, в сочетании с безопасным облачным соединением, позволяет команде специалистов по цепям поставок Lokad самостоятельно искать данные клиентов, тем самым сокращая задержки.
Верморель также отметил потенциал LLM для автоматизации множества задач, связанных с мастер-данными, включая их анализ, мониторинг и улучшение. Он сопоставил подход Lokad с подходами конкурентов, указав, что Lokad, как правило, привлекает к инициативе меньше людей, при этом каждый сотрудник обладает компетенциями на всех этапах процесса. По его словам, это резко контрастирует с конкурентами, которые часто вовлекают в инициативу гораздо больше людей, включая менеджеров проектов, консультантов, UX-дизайнеров, администраторов баз данных, сетевых специалистов и программистов.
Затем разговор перешёл к роли специалистов по цепям поставок в проверке или мониторинге скриптов, сгенерированных LLM. Верморель признал, что LLM иногда могут выдавать неточные или «галлюцинированные» результаты, но они, как правило, верны в общем направлении и могут быть исправлены несколькими итерациями через систему обратной связи. Он предположил, что, хотя LLM могут совершать ошибки, они всё равно могут приносить большую пользу, а их уровень ложных срабатываний и пропусков можно измерить.
Верморель также пояснил повседневную координацию между специалистом по цепям поставок, AI-пилотом и клиентом. AI-пилот, составляемый специалистом по цепям поставок, управляет ежедневными операциями в цепях поставок, контролируя мелочи, связанные с подготовкой данных и принятием решений по заказам. Клиента в этой схеме можно сравнить с капитаном, дающим общие стратегические указания.
Что касается основных выводов для специалистов по цепям поставок и управленческих команд, Верморель предсказал, что в течение десятилетия AI-пилоты станут нормой в управлении цепями поставок (SCM). Он считает, что это приведёт к огромному повышению производительности, с потенциальным сокращением штата до 90% для ранее выполнявшихся функций. Он призвал специалистов по цепям поставок уделять больше времени стратегическому мышлению и глубоким обсуждениям с поставщиками и клиентами.
Разговор завершился сессией вопросов и ответов, в ходе которой Верморель ответил на вопросы по ряду тем, включая роль AI-пилотов в сокращении отставания в ИТ, разницу между AI-пилотом и копилотом, важность анализа процессов перед внедрением модели ИИ, планы Lokad по открытию исходного кода Envision и способы, с помощью которых ИИ справляется с случайными узкими местами. Он также подтвердил, что Lokad работает над копилотом Lokad и планирует сделать Envision более удобным для GitHub.
Полная транскрипция
Конор Дохерти: Добро пожаловать на прямой эфир Lokad. Меня зовут Конор. Я глава коммуникаций здесь, в Lokad. Со мной в студии находится основатель Lokad, Жоанн Верморель.
Сегодняшняя тема — как ИИ может выступать в роли автономного пилота для принятия решений в цепях поставок. Не стесняйтесь задавать вопросы в чате YouTube в любое время, и мы ответим на них примерно через 30–35 минут.
Итак, Жоанн, AI-пилоты в цепях поставок — мне кажется, что этот разговор является продолжением того, который у нас был, я думаю, около четырёх недель назад, когда мы говорили о влиянии ИИ на занятость и будущем традиционных рабочих мест по сравнению с ИИ в цепях поставок.
Прежде чем перейти к подробностям AI-пилотов, не могли бы вы для тех, кто не видел предыдущего видео, дать краткое резюме, каково наше видение традиционных рабочих мест по сравнению с ИИ в цепях поставок?
Жоанн Верморель: Резюме таково: в 2023 году было достигнуто знаковое событие — генеративный ИИ и, более конкретно, большие языковые модели (LLM). С точки зрения чистых исследований, это всего лишь продолжение почти четырёх-пяти десятилетий непрерывного совершенствования машинного обучения. Если рассматривать это с исследовательской точки зрения, 2023 год — как и другие, в длинной цепочке прогресса, а прогресс за последние два десятилетия был довольно быстрым.
Теперь в 2023 году на рынок вышел готовый пакет генеративного ИИ как для изображений, так и, что важнее, для текста. И существует один продукт, который сделал это популярным — ChatGPT от OpenAI. Что это означает? Это означает, что, в частности, благодаря этим большим языковым моделям, у вас есть универсальная машина для шаблонов, устойчивая к шуму.
Это означает, что все этапы для корпоративного программного обеспечения — говорю о работниках, как о белых воротничках в корпоративной среде, — те этапы, которые ранее не могли быть автоматизированы, поскольку приходилось работать с текстом в любой форме, то есть чтение электронного письма, извлечение ссылки или цены из письма, определение количества или категоризация типа жалобы или запроса от партнёра или поставщика клиента, определение, является ли маркировка продукта бессмысленной (например, если маркировка продукта буквально означает, что описание отсутствует — ну, у нас проблема). Все эти процессы в прошлом не могли быть легко автоматизированы. Их можно было выполнить и другими способами, но автоматизировать их было трудно.
Если вернуться, скажем, на пять лет назад, то добыча текстов уже существовала. Уже было возможно использовать классификаторы текста и применять всевозможные методы обработки естественного языка, но это стоило дорого. 2023 год стал знаковым, потому что благодаря уровню упаковки, достигнутому с помощью, по сути, GPT-4 через API, операционные затраты на все эти методы NLP для компаний были снижены в 100, если не в 1000 раз. Это означает, что сокращаются не только затраты, но и время, необходимое для настройки системы.
Таким образом, основная мысль, и это мое предсказание, заключается в том, что многие вспомогательные функции в компаниях, являющиеся внутренними процессами, которые принимают данные и предоставляют результаты для других подразделений, будут автоматизированы. Цепи поставок находятся на переднем плане, поскольку это не функция, ориентированная на клиента. Это в значительной степени внутренняя функция, важная, но внутренняя. И вот здесь большие языковые модели стали недостающим звеном для автоматизации на всех этапах подавляющего большинства рутинных операций в цепях поставок.
Lokad автоматизирует количественный анализ и процесс принятия количественных решений уже десятилетие, но существует множество рутинных операций, которые предшествуют и следуют за этим процессом, и именно их можно автоматизировать благодаря большим языковым моделям быстро и недорого.
Конор Дохерти: Ну, спасибо. И у нас уже есть видео, где мы говорили, думаю, около полутора часов на эту тему, так что я не буду уделять этому сегодня дополнительное время, но это задаёт тон всему дальнейшему разговору. Я приглашаю всех, кто хочет узнать больше, посмотреть предыдущее видео. А теперь, что касается AI-пилотов, как они вписываются во всё, что вы только что сказали? Что они из себя представляют? Что они реально делают?
Жоанн Верморель: Говоря об ИИ в общем, в течение последних двух десятилетий поставщики постоянно используют этот термин как модное словечко и обобщающий термин, чтобы обозначить всё, что у них есть. Поэтому, когда я говорю об AI-пилотах, это, безусловно, предложение от Lokad. Это эволюция предложения, пожалуй, самое значительное за последние годы. И в чем же разница? Разница в том, что AI-пилот — это нечто, это программное обеспечение, то, что мы называем серией числовых рецептов, которые не только выполняют процесс принятия решений — то есть чисто количественную сторону цепи поставок, когда буквально определяется, сколько заказать, куда распределить запасы, нужно ли повышать или понижать цены, как точно планировать производство со всеми этапами и т.д.
То, что мы уже делали, плюс всё, что происходит до и после, в виде рутинных канцелярских задач, в основном связанных с управлением мастер-данными перед анализом данных, а затем исполнением решения, которое может включать неструктурированные каналы, такие как электронная почта, например, когда вы хотите отправить письмо поставщику с просьбой ускорить выполнение заказа или, наоборот, отложить его.
Суть этого предложения заключается, очевидно, в использовании больших языковых моделей, которые Lokad не изобретал, но которые мы активно используем уже 14 месяцев, даже немного больше. И ключевое понимание в работе Lokad заключается в том, что один специалист по цепям поставок должен иметь возможность полностью контролировать инициативу.
В очень крупных компаниях у нас может быть несколько человек, работающих над этим, но в отличие от большинства наших конкурентов, они обычно не являются узкоспециализированными. То есть мы не формируем команду из трёх человек: Мистера Базы Данных, Мистера Алгоритмов и Мистера UI/UX. Совершенно не так работает Lokad. Специалист по цепям поставок способен выполнить всё от начала до конца.
И это одна из причин, почему Lokad спроектировал свою технологию именно таким образом, и у нас есть собственный язык программирования, доменно-специфичный язык под названием Envision, предназначенный для предиктивной оптимизации цепей поставок. Это может показаться странным — создавать специализированный язык программирования, но суть в том, что нам действительно было нужно что-то единое, чтобы один человек мог выполнить всю работу от начала до конца. Это решение я принял ещё в 2012 году.
Не так давно всё заключалось в том, чтобы получить сырые данные транзакций из ERP-систем, CRM, EDI и всех этих транзакционных систем, дополнить их набором таблиц для всей структурированной информации, которая, к сожалению, является частью теневого IT, а не обычного IT, а затем создать числовые алгоритмы для принятия решений. И это была ответственность специалиста по управлению цепочками поставок — выполнить всё это, а затем разработать все инструменты, включая панели управления и отчёты, чтобы убедиться, что цифры верны, а также успокоить наших клиентов относительно достоверности того, что мы делаем, плюс все инструменты для контроля качества принимаемых решений с течением времени, плюс система для извлечения данных из систем и последующего ввода решений обратно в системы.
Таким образом, вот каким был масштаб задач для Lokad, и было две вещи, которые мы действительно не могли сделать. Во-первых, мы должны были быть получателями данных, мы не могли сами их добывать. И когда я говорю «добывать», имеется в виду, что специалист по управлению цепочками поставок мог запросить данные — мы не просили IT-отделы наших клиентов выполнять какие-то изощрённые преобразования, это было просто выгрузкой таблиц, знаете, типа select star from table, бац — вы делаете это один раз в день, и всё готово. Так что это были максимально простые извлечения, но всё же, их в основном выполнял IT-отдел наших клиентов.
От специалистов по управлению цепочками поставок не ожидалось, что они будут добывать данные в приложенческой среде наших клиентов, необходимые для инициативы. Причина очень проста: существует около 20 различных диалектов SQL, таких как Oracle SQL, диалект T-SQL для Microsoft SQL Server, 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 сможет выделить нужное время.
Второй приоритет — улучшение основных данных (Master Data Improvement). И снова, в прошлом, когда перед вами стоял каталог с, скажем, 100 000 описаний продуктов, среди которых некоторые были мусором (примерно 1%), приходилось тратить огромное количество усилий на просмотр этих 100 000 записей, выявление неверных описаний или обозначений продуктов, или даже ситуацию, когда цена была совершенно несоответствующей описанию. Если указывается, что это винт, а цена — 20 000 долларов, то, вероятно, это не просто винт, а что-то другое и т.д. Существовало множество простых проверок на здравый смысл, которые кажутся очевидными и простыми, но их было очень сложно автоматизировать, и часто не оставалось иного выбора, кроме как поручить человеку проверку записей для выявления действительно плохих данных.
С использованием LLM, а возможно, даже LLM, способного анализировать изображения, можно сделать многое в области оценки, мониторинга и улучшения всего, что связано с основными данными. В конкретном случае Lokad речь идёт об основных данных, необходимых для управления цепочками поставок.
Conor Doherty: Ну, там многое, спасибо. У меня куча вопросов, на которые я хочу получить ответы. Я немного отступлю назад, потому что, если суммировать всё, что вы описываете, и поправьте меня, если я ошибаюсь, один специалист по цепочкам поставок с доступом к хорошему LLM может выполнить огромное количество работы. Работа, которая до этого момента занимала бы много времени и требовала участия множества людей. А теперь, в условиях, не похожих на Lokad, сколько бы людей было вовлечено? Сколько «рук в деле» было бы задействовано? И потом можно говорить об эффективности, но если говорить только о численности, в чем разница между специалистами по цепочкам поставок с LLM и, скажем, S&OP?
Joannes Vermorel: Наши клиенты обычно в недоумении от того, что даже крупная инициатива состоит из двух-трёх человек — и это всегда одни и те же. У нас есть Lokad, и я очень горжусь тем, что Lokad, как работодатель, умеет удерживать сотрудников в течение довольно долгого времени. Таким образом, в итоговом расчёте, Lokad обычно работает с числом, соответствующим 1% от начала до конца. Если у нас несколько человек, то это делается для обеспечения резервирования: один день вы сосредотачиваетесь на этой части процесса, я — на другой, а на следующий день мы меняемся. Это не значит, что люди не специализируются — каждый обладает компетенциями по всему процессу. Конечно, есть различия и у некоторых людей есть своя особая специализация, но в целом, люди могут действительно заменить друг друга.
Наши конкуренты действуют совершенно иначе. Даже небольшая инициатива включает буквально полдюжины человек. У вас будет проектный менеджер, который просто координирует остальных, затем консультант, UX-дизайнер, специалист по конфигурациям, администратор базы данных, сетевой специалист и, возможно, программист, инженер-программист для нестандартных доработок. Ещё раз: Lokad — это программируемая платформа, а у большинства наших конкурентов платформы не являются программируемыми. Поэтому, если вам нужно нечто, имеющее программируемое поведение, вам понадобится полноценный программист, который буквально реализует недостающие части с помощью общего языка программирования, такого как Java или Python. Таким образом, Lokad действительно не такой. Я бы сказал, что у наших конкурентов, по сути, задействовано около десятка человек. Инициативы S&OP могут включать несколько десятков человек, но это не обязательно требует столь разнообразных навыков — в основном это просто разные люди из разных отделов, и зачастую это не так сильно связано с IT.
Таким образом, когда я говорю, что у Lokad работает один человек против десятка у конкурентов, я сравниваю нас с теми, кто продаёт APS, системы продвинутого планирования или системы оптимизации запасов — то есть с таким видом корпоративного программного обеспечения.
Conor Doherty: Спасибо. И возвращаясь к ещё одному пункту, который вы упомянули в начале, когда говорили о специалистах по цепочкам поставок, вы привели пример различных диалектов SQL, а затем упомянули специалиста, который, возможно, не владеет конкретным диалектом клиента, и который проверяет или контролирует автоматически сгенерированные скрипты, поскольку LLM иногда начинает фантазировать.
Что ж, в этом отношении LLM действительно часто фантазируют. Хотя ситуация улучшается, вы можете попросить LLM, используя какой-либо текст, «Найди это скрытое слово, видишь его?», — и он ответит: «Да», хотя на самом деле его там нет. Я знаю, что его там нет, вы знаете, что его там нет. Как в масштабах можно обеспечить безопасность и контроль качества, когда речь идёт об автоматизированном использовании LLM?
Joannes Vermorel: Фантазии, или, как я предпочитаю называть, конфабуляции, действительно случаются, когда вы используете 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: Спасибо. И я хочу отметить, что у нас действительно есть вопросы от аудитории, которые затрагивают те моменты, которые я собирался обсудить, так что я пропущу некоторые темы, но они будут рассмотрены в вопросах от зрителей. Но последний вопрос: когда вы говорите о специалистов по цепочке поставок, AI Pilot, и мы вернёмся к этому позднее в вопросах, как именно эта координация работает на ежедневной основе между специалистом по цепочке поставок, AI Pilot и клиентом? Имеет ли клиент доступ? Взаимодействует ли он с LLM?
Joannes Vermorel: Обычно мы считаем, что все числовые рецепты, составленные специалистами по цепочке поставок, являются AI Pilot. Это то, что ежедневно управляет цепочкой поставок. Он работает без присмотра и генерирует решения. Теперь, с помощью LLM, он также обрабатывает мелочи, связанные с подготовкой данных и принятием решений по заказам на закупку. Например, предварительный этап может заключаться в запросе к поставщикам об их MQS. Вам нужно получить эту информацию; если её нет или она не обновлена, её надо исправить. LLM могут помочь в этом. После принятия решения отправляется электронное письмо с запросом ETA — ориентировочного времени прибытия, если у вас нет настроенной EDI или моста, или запрос на ускорение или отсрочку заказа. Это те мелочи, которые следуют за основным решением, когда Lokad может сформировать решение о запросе на ускорение заказа, но не заниматься мелкими деталями вроде составления и отправки письма.
Все это, по сути, AI Pilot, и это большой числовой рецепт, который реализует процесс от начала до конца. Всё это реализуется специалистом по цепочке поставок. Таким образом, для Lokad это расширение объёма работ. Специалист по цепочке поставок на самом деле является вторым пилотом. И действительно, когда я говорю “пилот”, я имею в виду автоматизированного пилота в самолёте. Кстати, в современных самолётах самые сложные манёвры выполняются на автопилоте. Если у вас есть действительно страшные аэропорты, как старый аэропорт Гонконга, а новые гораздо проще, но один из них расположен буквально посреди высоток, автопилот для таких манёвров обязателен. Так что всё это делается автоматически, а люди лишь наблюдают.
Таким образом, здесь специалист по цепочке поставок разрабатывает числовые рецепты и выступает в роли второго пилота. Он принимает решения, проводит навигацию для направления процессов, а затем разрабатывает план и маршрут для пилота. Но в основном специалист по цепочке поставок исполняет роль второго пилота, определяя направления, предвидя и обеспечивая максимально плавное управление пилотом. При этом все частые коррективы выполняет именно пилот, а не второй пилот. А клиент играет роль капитана.
Знаете, как в старом телесериале «Звёздный путь», где капитан сидит в кресле и даёт общие указания экипажу. Таким образом, в этой схеме клиент задаёт стратегию и общие направления, затем специалист по цепочке поставок реализует их, а роль пилота заключается в выполнении всех необходимых микро-корректив или ежедневных решений для цепочки поставок, а затем в непосредственном управлении процессом.
Conor Doherty: И это тоже, чтобы было понятно, так как мы об этом не говорили, — это дополнение к уже выполненным автоматизированным количественным задачам, которые делаются уже много лет. Так что, если кто-то слушает и думает: “О, это же только качественные задачи”, — мы говорим о процессе от начала до конца. Да, количественные задачи, такие как учёт экономических драйверов, формирование распределения, закупки, ценообразование — всё это уже управляется ИИ и автоматизировано.
Таким образом, специалист по цепочке поставок контролирует обе эти области — количественную и качественную.
Joannes Vermorel: Именно. И причина, по которой Lokad наконец принял термин «ИИ» — обобщающий термин — заключается в том, что теперь мы добавляем к нашей работе LLM. У нас уже было машинное обучение с дифференцируемым программированием и стохастическая оптимизация, но теперь мы добавляем LLM. Итак, это буквально очень полный набор инструментов.
Эффект от этого заключается в том, что цепочки поставок наших клиентов могут работать без присмотра в течение недель. Людей удивляет, как долго, благодаря этим экономическим драйверам, можно функционировать полностью автономно. Прелесть в том, что не требуется выполнять какие-либо микро-коррективы. Например, корректировки прогноза для большинства наших клиентов практически отсутствуют. И большинство других корректировок также происходит автоматически, например, введение новых продуктов, вывод из ассортимента старых товаров, привлечение новых поставщиков и отказ от неэффективных.
Таким образом, всё это является обычным ходом дел, и когда рецепты выполняются правильно, в прошлом требовалось гораздо меньше вмешательств. Но с этим AI Pilot, который включает LLM, добавление нового поставщика и подобные задачи могут требовать ещё меньшего ручного вмешательства, чем раньше.
Conor Doherty: Хорошо, Жуаннес, спасибо. Мы идём уже около 40 минут. Вопросы ждут, так что я переведу нас к ним. Но прежде чем мы продолжим, в качестве краткого итога или завершающей мысли, в контексте гораздо более широкой беседы, которую мы вели месяц назад и ведём сегодня, в чём основной вывод как для специалистов по цепочке поставок, так и для управленческих команд, курирующих обычного специалиста по цепочке поставок? Какой призыв к действию или основное сообщение для них?
Joannes Vermorel: Я считаю, что через десятилетие видение AI Pilot, возможно под другим названием, станет нормой. Возможно, люди просто станут говорить “цепочка поставок” вместо “AI Pilot для цепочки поставок”. И станет само собой разумеющимся, что в цепочке поставок присутствуют AI Pilot, как когда вы говорите о компьютере: вы не упоминаете наличие процессора или памяти, ведь наличие процессора — само собой разумеющееся.
На мой взгляд, примерно через десятилетие эти функции будут широко автоматизированы, и Lokad, с помощью этих AI Pilot, предложит пакетное решение вместе со специалистом по цепочке поставок. Для наших клиентов это означает, что практика управления цепочкой поставок по своей сути меняется. Это означает, что у них будут AI Pilot, способные освободить массу ресурсов. Мы уже освобождали ресурсы для процессов принятия решений и сложных вычислений. Но теперь мы также освобождаем время, которое раньше тратилось на мониторинг списка SKU, списка поставщиков, списка клиентов, просто для того, чтобы поддерживать мастер-данные в корректном, чистом и упорядоченном виде. Всё это постепенно исчезает, и необходимость в ручном вмешательстве, которое зачастую даже не является количественным, отпадает. Раньше вам приходилось исправлять ярлыки, записи, устранять дубликаты и тому подобное. Всё это, опять же, будет обеспечено Lokad.
Итак, вывод таков: это огромное повышение производительности. Думаю, что с некоторыми клиентами нам буквально удаётся сократить численность сотрудников, занимающихся рутинными задачами, на 90%. Реальность такова, что теперь у вас больше времени, и вы можете заниматься тем, что гораздо труднее автоматизировать, а это, по моему мнению, приносит большую ценность. Это означает, что нужно вдумчиво разрабатывать стратегию, тратить гораздо больше времени на обдумывание вариантов, что исследовать, вместо того чтобы снова тратить время на работу с таблицами.
Так что посвящайте много времени глубокому размышлению о сложных проблемах, затем общайтесь с поставщиками и клиентами, ведите по-настоящему содержательные беседы, чтобы вы могли организовать свою цепочку поставок так, чтобы удовлетворить поставщика, и тогда он будет готов дать вам лучшие цены, вы получите лучшее качество, большую надёжность и т.д. Если вы организуете свою работу с учётом потребностей поставщиков, это может показаться немного противоположным подходом, как будто вы говорите: “Я клиент, и поставщики должны подстраиваться под меня”. Но если вы сможете лучше учитывать интересы ваших поставщиков, это командная работа, и вы получите большую надёжность и лучшие цены.
И тот же подход можно применить и к работе с клиентом, ведь должна быть установлена такая же форма сотрудничества. И опять же, для этого требуется множество интеллектуальных обсуждений, и это те задачи, которые сегодня выходят за рамки возможностей LLM. Поэтому я считаю, что Lokad может автоматизировать задачи, которые нам нравятся — рутинные, не приносящие высокой ценности мелкие детали и обыденные офисные задачи, — и позволить людям заниматься высокоуровневой, полу-стратегической работой. Говорю “полу-стратегической”, потому что вы будете общаться с клиентом по одному, а затем разрабатывать стратегию, которая заключается в обобщении всей информации, создании видения и поддержке руководства цепочкой поставок, чтобы у них была чёткая и обоснованная стратегия для их компании.
Conor Doherty: Итак, чтобы привести два примера для лучшего понимания: низкоуровневые решения, когда вы просматриваете Excel-таблицу и говорите: “О, здесь написано ‘block in colors’ — должно быть черное”, то есть вы это автокорректируете — это тривиально, обыденно и не стоит вашего времени. “Должен ли я открыть склад в Гамбурге?” — стратегический вопрос.
Joannes Vermorel: Да, это стратегический вопрос. Плюс проблема в том, что вариантов так много. Можно спросить: для склада — покупать его или брать в аренду, какие заключать контракты, какой уровень автоматизации необходим, нужен ли договор на оборудование, чтобы потом его вернуть, стоит ли арендовать оборудование или нет. То есть, существует сотни вопросов, и очень часто, когда людям приходится тратить 99% своей умственной энергии на канцелярские задачи, у них не остается времени на решение этих крупных вопросов.
Понимаете, если применить закон Паркинсона, то можно заметить, что я видел много компаний, где, если подсчитать общее количество минут, затраченных на что-то вроде ABC-анализ классов, ежегодно тратятся целые человеко-годы на проведение ABC-анализа. А когда дело доходит до принятия решения об открытии нового склада, речь идёт о неделях времени. Видно явное несоответствие: люди в совокупности тратят буквально годы рабочего времени на нечто абсолютно бессмысленное, вроде ABC-анализа, а на инвестицию в 50 миллионов евро для открытия склада уходит буквально несколько недель, и затем, бац, принимается решение. Всё должно быть наоборот.
Conor Doherty: Хорошо, спасибо за это. На этом я переключаюсь к вопросам аудитории. Большое спасибо. Задавайте вопросы до тех пор, пока я, по сути, не закончу. Итак, Жуаннес, вопрос от Массимо: не могли бы вы подробнее рассказать, как IT может использовать AI Pilot для сокращения отставания и почему, по вашему мнению, этот подход следует предлагать?
Joannes Vermorel: AI Pilot не предназначен для сокращения IT-отставания. Речь идёт о том, чтобы справляться с тем фактом, что у IT накоплены годы отставания. Таким образом, наш план в Lokad не заключается в уменьшении IT-задолженности. Это требует переосмысления IT так, как это сделал Amazon. Это уже отдельная тема. Я бы сказал: обратите внимание на меморандум Джеффа Безоса 2002 года, касающийся API в Amazon. Суть в том, что все отделы современной компании нуждаются в огромном количестве программного обеспечения. Каждое подразделение — маркетинг, финансы, бухгалтерия, цепочка поставок, продажи — требуют множества программных инструментов, и всё это ложится на плечи IT. IT буквально разрушается под этим бременем.
Таким образом, моя мысль такова: в Lokad мы являемся специалистами по цепочке поставок. Мы не будем решать задачи для маркетинга, продаж, бухгалтерии и всего прочего. Мы утверждаем, что с помощью LLM мы можем освободить IT от забот о Lokad. Суть в том, что вместо того, чтобы требовать, скажем, 10–20 дней работы IT для запуска инициативы по количественной аналитике цепочки поставок и построения инфраструктуры, теперь требуется всего несколько часов. Таким образом, мы не решаем проблему отставания. IT занимается тем, чем занимается. Они также могут получить выгоду от LLM, но в их случае задачи гораздо разнообразнее и сложнее.
Итак, мое предложение не в том, что большие языковые модели (LLM) действительно могут помочь IT сократить их отставание. Это просто способ для Lokad, в данном конкретном случае, сказать: “Ну, вместо того чтобы прибавлять к отставанию ещё 20 дней, мы просто прибавляем что-то вроде четырех часов, и всё готово.” Вот как мы справляемся с отставанием. А в более общем смысле, решение этих лет задержек в работе заключается в том, что каждое подразделение должно освоить большую часть программных вещей внутри себя. Видите ли, за эти годы компании в целом требуют от IT слишком многого. В каждом отделе должны присутствовать цифровые практики — маркетинг, продажи, бухгалтерия и тому подобное. Вы не должны просить IT решать все эти проблемы за вас. Необходимо, чтобы в каждой области были свои цифровые эксперты. И именно в этом состоит суть меморандума 2002 года, если я не путаюсь, от Джеффа Безоса для его команды. Это очень известный меморандум. Можно ввести в поисковике “известный меморандум Безоса”, ведь он в сущности говорил: “У вас две недели, чтобы разработать план, позволяющий каждому подразделению обнародовать все ваши данные, чтобы у нас не было такого сайлообразования и игр власти в компании, в Amazon.”
И безос заключал: “Каждый менеджер, у которого через две недели на моём столе не окажется плана, — уволен или что-то в этом роде.”
Conor Doherty: Хорошо, большое спасибо. Следующий комментарий — это вопрос, который я не задал, потому что увидел, что его упомянули в комментариях, так что он оформлен как комментарий, но воспринимайте его как вопрос. Это от Джесси. “Один ученый по цепочке поставок плюс одна LLM всё равно звучит как сопилот. Так что, ещё раз, объясните разницу между AI Pilot и сопилотом.”
Joannes Vermorel: Причина, по которой мы говорим, что это пилот, заключается в том, что у некоторых клиентов в течение нескольких недель все решения генерируются и затем выполняются без вмешательства. И когда я говорю “без вмешательства”, я действительно это имею в виду. Во время локдаунов 2020 года у нас даже была компания, где в течение 14 месяцев все офисные сотрудники буквально оставались дома, не работали и получали оплату от государства, поскольку государство предоставляло субсидии в Европе. Несколько стран предоставляли субсидии, чтобы, по сути, оставаться дома и не работать. Вот такая была ситуация. Когда у вас есть цепочка поставок, которая функционирует практически без вмешательства в течение 14 месяцев, я называю это пилотом, а не сопилотом. Если некому контролировать числа, сгенерированные системой, я действительно считаю, что это пилот.
Но тогда мы не использовали LLM. Ситуация была такова, что данные были чистыми и не было острой нужды совершенствовать управление основными данными. Это был клиент с очень высоким уровнем зрелости в плане интеграции EDI и тому подобного. То, что требовалось до и после, было крайне ограниченным.
В любом случае, возвращаясь к вопросу о сопилоте. Большинство конкурентов Lokad утверждают, что они создают сопилота. И действительно, то, как они это делают, — совершенно иное дело. Lokad, ученый по цепочке поставок, использует язык программирования. Поэтому, когда мы применяем LLM, он нужен для генерации, для помощи в создании фрагментов программы. Вот для чего мы его используем.
Таким образом, LLM используется для генерации, по сути, фрагментов программ, которые могут представлять собой SQL-диалекты или иные элементы. А затем мы разрабатываем пилот, и пилот работает без вмешательства.
Наши конкуренты, особенно те, кто заявляет, что собираются выводить на рынок разговорный ИИ, разговорный UI, пользовательский интерфейс, делают нечто совершенно иное. Обычно они используют подход, называемый retrieval augmented generation (RAG). То, что они делают, — они составляют запрос. Буквально, все наши конкуренты, которые сейчас говорят, что применяют ИИ с помощью LLM в области цепочек поставок, составляют, скажем, дюжину запросов, подходящих под различные сценарии. Затем, после запроса, они вставляют данные, извлечённые из базы данных, например, базовую описательную статистику. Они добавляют пару десятков чисел — средние продажи за прошлую неделю, прошлый месяц, прошлый год или что-то ещё, базовую статистику, соответствующую сценарию. И затем они дополняют дополнительный запрос от пользователя, после чего LLM завершает ответ.
Видите, LLM по сути занимается дополнением текста. Вы составляете текст, и он его дополняет. А в retrieval augmented generation часть, связанная с извлечением, заключается всего лишь в получении некоторых чисел из базы данных, а затем в компоновке. Но суть такова: теперь у вас есть нечто, куда можно задать вопрос. Однако реальность такова, что если вы хоть немного разбираетесь, вы можете сами прочитать числа с экрана. Нет никакой магии. LLM просто видит числа так же, как и вы их видите в отчёте. В основе своей он может отвечать только на те вопросы, на которые уже можно ответить с помощью панели управления.
Так что, да, если вы не совсем знакомы с определением каждого числа, он может разъяснить это для вас. Но вы также можете иметь, как делает Lokad, что-то вроде шпаргалки, которая даёт краткое описание, прикреплённое к каждой панели, для каждого числа, присутствующего на ней. И это будет выполнять ту же самую роль — без ИИ.
В итоге, я чрезвычайно скептически отношусь к этим разговорным ИИ, этим сопилотам, потому что по сути они являются уловками, наложенными поверх существующих систем, которые никогда не были спроектированы для работы с каким-либо видом систем машинного обучения, даже классического, не говоря уже о LLM.
Вот почему, насколько мне известно, все наши конкуренты используют сопилотов, где по сути у них есть что-то вроде чат-бота, работающего поверх панелей управления. Но он не обеспечивает никакой автоматизации. Он не позволяет автоматизировать никакие AI Pilot. Это, да, просто уловка поверх устаревшей системы.
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 — его высокая склонность к статическому анализу. А статический анализ, кстати, — это раздел дизайна и анализа языков. Когда я говорю “язык”, я имею в виду компьютерный язык, который позволяет получать свойства программ без их запуска. С помощью статического анализа мы можем буквально автоматически переписывать существующий скрипт со старого синтаксиса на новый. И мы делаем это автоматически по вторникам. Обычно, когда мы проводим обновление, в течение нескольких дней принимаются как старый, так и новый синтаксис. Мы выполняем автоматизированные переписывания, а затем, когда видим, что старый синтаксис больше не используется, посредством feature flag фиксируем то, что существует только новый синтаксис.
И в Lokad мы уже внедрили свыше 200 таких автоматизированных переписываний. Обычно мы выпускаем обновления каждую неделю по вторникам, но в среднем у нас выходит около двух переписываний в месяц, и мы занимаемся этим уже десятилетие. Пока этот процесс продолжается, мы не можем реалистично выпустить Envision с открытым исходным кодом. Это произойдет со временем, но я не хочу повторять колоссальную ошибку Python. Обновление с Python 2 до Python 3 заняло у сообщества целое десятилетие и было невероятно болезненно. Компании затрачивали годы на обновления — это было настоящим кошмаром, продолжающимся десятилетие. Это было действительно, действительно неправильно. Даже Microsoft при переходе от C# и .NET Framework к .NET Core потратила полдесятилетия, и это было огромной болью. Вот в чем, опять же, дело: как только у вас есть компилятор с открытым исходным кодом, вы теряете контроль над кодом. Если вы хотите внести изменения в язык, вам нужно сотрудничать с сообществом. Это делает процесс супер медленным, невероятно болезненным, и в итоге вы никогда не устраните все недостатки вашего языка.
Если мы посмотрим на 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 на переднем крае систем промышленного уровня распознавания речи. Было множество приложений, где это не срабатывало. Распознавание голоса работало, но правда в том, что руки на клавиатуре просто быстрее. Ситуации, в которых голос используется, — когда руки грязные или заняты. В остальных случаях клавиатура незаменима.
Возвращаясь к вопросу, сначала нужно отфильтровать заказы. Здесь мы имеем процесс принятия решений, в котором определяется, какие заказы требуют ускорения. Это классический подход Lokad — чистый количественный процесс принятия решений. Нужно решить, да или нет: заслуживает ли текущий заказ запроса на ускорение процесса. Мы делаем это с помощью дифференцируемого программирования и стохастической оптимизации. Именно так мы приходим к правильным решениям.
Как только это сделано, ежедневно автоматически принимаются решения по заказам. Речь не идёт о том, чтобы кто-то отдавал устные команды для этого. Это станет частью набора числовых рецептов, с помощью которых мы вычисляем оптимизированные заказы. Со временем мы понимаем, что некоторые заказы превышают или не достигают поставленных целей, и мы будем запрашивать отсрочку или ускорение соответственно. Роль LLM здесь заключается в использовании этого количественного решения — например, бинарного флага с надписью «пожалуйста, ускорьте» — для генерации письма с надлежащим контекстом, отправки его поставщику с просьбой, что-то вроде «подтвердите, что сможете выполнить», а затем поставщик, надеюсь, ответит: «да», «нет», «может, смогу» или «это то, что я могу предложить».
LLM автоматизирует общение с поставщиком. ИИ не предназначен для принятия решения об ускорении заказа. Это чисто количественное решение, которое необходимо принимать с помощью количественных инструментов — дифференцируемого программирования и стохастической оптимизации. LLM же используется для взаимодействия с поставщиком, который часто применяет неструктурированные каналы, такие как email.
Если вы думаете о голосовых командах, это не сработает. Они слишком медленные. Мне посчастливилось работать с командами, которые буквально выпустили на рынок первые промышленные системы распознавания речи 20 лет назад. Но суть в том, что вы не будете использовать эти технологии ИИ для подобных задач. Голосовые команды не обладают достаточной пропускной способностью для выполнения требуемых действий.
Conor Doherty: В продолжение темы, когда мы говорим о стохастической оптимизации и дифференцируемом программировании, у нас имеется обширный видеоматериал по этим темам. Мы не углубляемся в детали, поскольку это трёхсерийный цикл (часть 1, часть 2 и часть 3) по дифференцируемому программированию, но мы не игнорируем эти материалы. Они уже рассмотрены, и я рекомендую зрителям, желающим узнать больше, ознакомиться с ними и объединить полученные знания.
Последний вопрос, и он от Айзека. Будучи клиентом, который в настоящее время изучает Envision, меня интересуют возможности его интеграции, в частности с GitHub. Не могли бы вы рассказать о потенциале Envision для поддержки интеграции с GitHub, особенно для таких задач, как объяснение блоков кода на естественном языке или идентификация изменений между версиями? И, наконец, существует ли план по внедрению Envision copilot в ближайшем будущем?
Joannes Vermorel: Краткий ответ — да, да и да. Сроки зависят от конкретных компонентов. Что касается использования LLM для реализации функционала copilot, подобного GitHub Copilot, но для кода Envision — мы уже над этим работаем. Очень интересно то, что, благодаря тому, что это специализированный язык (DSL), над которым мы имеем полный контроль, мы полностью контролируем обучающие материалы. Это здорово, потому что означает, что в тот день, когда мы успешно переведём этот LLM в продакшн, при каждом изменении синтаксиса мы будем повторно запускать процесс обучения с обновлённым синтаксисом, и у вас всегда будет copilot, предоставляющий актуальный синтаксис 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. Если вы поищете расширение Lokad для Visual Studio Code для Envision, то найдёте его — оно полностью открытое и обеспечивает подсветку кода.
В будущем мы планируем предоставить код Envision, который хранится в аккаунте Lokad, в виде git-репозитория. То, как код Envision хранится в аккаунте Lokad, практически соответствует способу хранения в git-репозитории. Он версионируется примерно так же. Организация отличается от git, но я не буду вдаваться в технические подробности. Git очень нейтрален в отношении языка программирования. Если вы работаете с одним конкретным языком, можно действовать умнее и реализовывать вещи, недоступные в общем случае. Но суть в том, что код Envision полностью версионируется. Мы могли бы предоставить git-репозиторий, который позволит экспортировать весь ваш код из аккаунта Lokad в git-репозиторий, а возможно, и обеспечить двунаправленную синхронизацию. Git — это децентрализованная система, где каждый репозиторий содержит полную копию, что позволяет получать изменения из удалённого репозитория, а также отправлять туда свои изменения. Так что, возможно, сначала мы реализуем экспорт, а затем импорт, но это займёт время. Мы ещё не на этом этапе. Это часть дорожной карты, но конкретных сроков пока нет.
Conor Doherty: Стоит отметить, что некоторые люди в комментариях говорили, что они изучают Envision. Мы выпускаем серию учебных материалов, созданных в сотрудничестве с Университетом Торонто и несколькими другими, которые находятся в разработке. Существуют бесплатные ресурсы, и мы можем ответить на вопросы, если кто-то захочет. Для всех, кто хочет учиться, наши специалисты по цепочкам поставок вкладывают много усилий в эти семинары. Они доступны бесплатно на нашем сайте.
Joannes Vermorel: Для тех, кто не заинтересован в том, чтобы стать специалистом по цепочкам поставок самостоятельно, Lokad может предоставить специалиста по цепочкам поставок в рамках предложения AI Pilot.
Conor Doherty: Это все вопросы, Joannes. Большое спасибо за ваше время и спасибо за просмотр. Надеюсь, это было полезно, и до встречи в следующий раз.
