00:00:00 Введение в интервью
00:01:00 Путь Рината в Lokad и проблемы цепочки поставок
00:03:59 Эволюция Lokad и инсайты симуляций
00:07:07 Сложности симуляций и решения на основе агентов
00:09:15 Введение LLM и оптимизация симуляций
00:11:18 Влияние ChatGPT и категории моделей
00:14:14 LLM как когнитивный инструмент в предприятиях
00:17:10 Улучшение взаимодействия с клиентами и листингов благодаря LLM
00:20:30 Ограниченная роль LLM в расчётах цепочки поставок
00:23:07 Повышение коммуникации в цепочках поставок с помощью LLM
00:27:49 Роль ChatGPT в аналитике данных и инсайтах
00:32:39 Работа с текстом и проблемы количественных данных LLM
00:38:37 Уточнение корпоративного поиска и заключительные мысли по ИИ
Резюме
В недавнем диалоге Conor Doherty из Lokad беседовал с Joannes Vermorel и Ринатом Абдуллиным о влиянии генеративного ИИ на цепочки поставок. Vermorel, генеральный директор Lokad, и Абдуллин, технический консультант, обсудили эволюцию от прогнозирования временных рядов до использования больших языковых моделей (LLM) таких как ChatGPT. Они исследовали потенциал LLM для автоматизации задач, повышения продуктивности и помощи в анализе данных без уничтожения рабочих мест. Хотя Vermorel оставался осторожен в отношении LLM в планировании, оба признали их полезность в составлении решений. Интервью подчеркнуло преобразующую роль ИИ в управлении цепочками поставок и важность интеграции LLM со специализированными инструментами.
Расширенное резюме
В недавнем интервью Conor Doherty, руководитель отдела коммуникаций Lokad, принял участие в содержательной беседе с Joannes Vermorel, генеральным директором и основателем Lokad, и Ринатом Абдуллиным, техническим консультантом Trustbit и бывшим техническим директором Lokad. Беседа была посвящена стремительно развивающейся области генеративного ИИ и его влиянию на управление цепочками поставок.
Ринат Абдуллин, вспоминая своё время в Lokad, рассказал о ранних трудностях, с которыми столкнулась компания, особенно в согласовании технологий с потребностями клиентов и в обеспечении понятности и надёжности сложных данных цепочки поставок. Joannes Vermorel подтвердил, что истоки Lokad связаны с прогнозированием временных рядов, ключевым элементом оптимизации цепочки поставок.
По мере развития диалога Абдуллин подробно рассказал об эволюции технологий Lokad, подчёркивая напряжённость между объяснимостью и производительностью моделей машинного обучения. Он поделился опытом использования симуляций для упрощения сложных систем, что проложило путь к более оптимизированным вычислительным методам.
Затем разговор перешёл к большим языковым моделям (LLM), при этом Vermorel отметил их недавний всплеск популярности. Абдуллин поделился своими первыми впечатлениями о языковых моделях и их превращении в удобные инструменты, такие как ChatGPT. Он подчеркнул преобразующий потенциал LLM, сравнив их с личным отделом ассистентов, способных выполнять разнообразные задачи – от составления документов до автоматизации поиска информации в крупных силосах.
Абдуллин развеял опасения, что LLM заменят рабочие места, утверждая, что они повышают эффективность сотрудников, а не заменяют их. Он привёл примеры, когда производительность возрастала в 10–100 раз. Также он отметил, что, хотя цепочки поставок медленно внедряют LLM, маркетинговые отделы быстро начали использовать их для улучшения взаимодействия с клиентами и сокращения затрат.
Joannes Vermorel подробно рассказал о потенциале LLM в автоматизации открытых коммуникаций с партнёрами по цепочке поставок, экономии времени на рутинной переписке и возможности сосредоточиться на более сложных задачах. Он отметил их лингвистическую утончённость в подборе тона общения – задача, требующая значительных временных затрат для людей.
Абдуллин выделил продвинутые возможности ChatGPT в аналитике данных, позволяющие руководителям принимать обоснованные решения без навыков программирования. Однако Joannes Vermorel сохранил скептицизм по отношению к генеративному ИИ в планировании цепочек поставок, подчёркивая, что LLM больше подходят для создания одноразовых анализов и отчётов.
Ринат Абдуллин предположил, что LLM можно использовать совместно со специализированными инструментами для достижения лучших результатов, особенно на пересечении числовых, текстовых и кодовых данных. Joannes Vermorel согласился, пояснив, что LLM лучше подходят для составления программ для решения задач, а не для их непосредственного решения.
В заключение Ринат Абдуллин призвал компании принять LLM, поскольку они могут привнести значительную пользу при использовании вместе со специализированными инструментами. Conor Doherty завершил интервью, поблагодарив Joannes и Рината за их вклад в динамичное развитие генеративного ИИ и его роль в будущем управления цепочками поставок.
Полная стенограмма
Conor Doherty: Добро пожаловать на Lokad TV. Прогресс, достигнутый в области генеративного ИИ за последние 12 месяцев, является выдающимся достижением технологического развития. LLM, или большие языковые модели, за менее чем год вышли из нишевого применения в массовое использование. Сегодня, чтобы объяснить значение этого явления, особенно в контексте цепочки поставок, у нас с нами первый технический директор Lokad, Ринат Абдуллин. Ринат, добро пожаловать в Lokad.
Rinat Abdullin: Для меня большая честь и удовольствие вернуться. Я был в Lokad, когда всё только начиналось в маленькой комнате, кажется, в университете. Из всех компаний, с которыми я работал, включая семь стартапов, Lokad была самой сложной и в то же время приносящей удовлетворение.
Conor Doherty: Тебе не нужно напрямую говорить о Joannes, но когда ты упоминаешь, что это было самое сложное место, что именно делало Lokad таким вызовом? И какова была сложность будущих проектов?
Rinat Abdullin: Мы тогда были стартапом, и это было интересное сочетание попыток найти соответствие между технологиями и тем, что требовал и действительно нуждался клиент. Баланс этого треугольника всегда был проблематичным, поскольку технологии тогда находились на заре. Мы были одними из первых крупных клиентов Azure, только начинали создавать распределённую библиотеку для обработки огромного количества временных рядов от клиентов. Поддержки не было – всё приходилось строить с нуля, и этот путь занял много лет. Затем мы приступили к созданию кастомного DSL для расширения возможностей экспертов в Lokad, и этот процесс до сих пор продолжается. Это – одна сторона треугольника. Другая заключалась в том, что клиенты требовали более точных цифр; они хотели, чтобы их бизнес работал предсказуемо без замороженных средств на складе. В то же время они требовали понятности этих цифр, ведь если предоставить клиенту данные, полученные из волшебного чёрного ящика, руководители могут сказать: “Да, это работает”, а специалисты по цепочке поставок на местных складах ответят: “Я не понимаю эти цифры. Я не доверяю формулам, и моё чутьё, основанное на 10–20-летнем опыте, подсказывает, что они не сработают, поэтому я их проигнорирую.” И, очевидно, уволить всех невозможно. Баланс этих трёх аспектов всегда представлял сложность как для Lokad, так и для всех клиентов, с которыми я работал с тех пор.
Joannes Vermorel: Слушая Рината, я помню, что мы раньше работали с временными рядами, так ли это?
Rinat Abdullin: Да, Lokad была буквально основана как сервис прогнозирования временных рядов, так что я многое знаю о них, даже если спустя годы мы отошли от этого направления. Мы работали с временными рядами, и это была базовая строительная единица. Напряжённость, о которой говорил Ринат, относительно объяснимости, также была решена, но только спустя более чем десятилетие после основания Lokad. Нам пришлось внедрить дифференцируемое программирование, чтобы, наконец, появились модели, основанные на машинном обучении, но остававшиеся объяснимыми. Это произошло довольно поздно. В течение многих лет у нас был выбор между примитивными моделями, которые были «белым ящиком», но не очень хорошими, и моделями машинного обучения, которые, хотя и были лучше, представляли собой чёрные ящики, создавая массу эксплуатационных проблем. Иногда они по всем параметрам проблемы вовсе не превосходили предыдущие. Это была огромная борьба, и путь Lokad представлял собой почти десятилетнюю серию непрерывных восхождений. Ринат провёл первые полдесятилетия этих испытаний, а затем другие люди продолжили борьбу по остальным направлениям. Это была очень длинная череда масштабных проблем, решать которые требовалось неустанно.
Conor Doherty: Спасибо, Ринат. Обращаясь к тебе, когда мы пытаемся объяснить, чем занимается Lokad, мы делаем это через серию очень длинных статей, лекций и обсуждений, подобных этому. Но когда речь заходит о том, как сделать машинное обучение прозрачным в таком контексте, как ты к этому подходишь?
Rinat Abdullin: Один из подходов, который сработал довольно успешно, когда я помогал организовывать хакатон для международной логистической компании, заключался в использовании симуляций. Когда речь идёт о международной логистике, задействовано огромное число переменных. Груз должен транспортироваться между несколькими локациями с использованием различных видов транспорта. Существуют транспортные компании и другие фирмы, конкурирующие на открытом рынке за доставку груза из точки A в точку B. Затем есть реальные маршруты доставки – дороги, железнодорожные сети, возможно, доставка последней мили. Когда грузовики перевозя груз между этими точками, случаются задержки, пробки, и груз может прибыть на склад вне рабочего времени или разгрузочная зона может быть переполнена.
Мы хотели смоделировать всю эту сложность так, чтобы она была понятна студентам или новым сотрудникам компании. То, что мы сделали, было довольно радикально – почти как когда древние учёные пытались вычислить число пи посредством подбрасывания монеты в симуляции. Мы создали виртуальную карту Европы с главными дорогами, где каждая дорога имела свою длину, время шло, грузовики курсировали туда-обратно, а транспортные компании могли самостоятельно решать, какой груз забрать и успеют ли его доставить вовремя. Это стало отправной точкой для участников хакатона, поскольку они могли запрограммировать агентов, которые принимали решения вроде: “Я – водитель грузовика A, и я собираюсь перевезти этот груз из точки A в точку B.” Но была одна особенность: как и в реальном мире, когда грузовик перевозит груз из одной точки в другую, это требует затрат. Чтобы заработать деньги, нужно платить налоги, стоимость топлива, а также обеспечивать отдых водителя.
Поскольку это симуляция, сложные формулы не требуются – вы просто имитируете реальность. Вы запускаете процесс, как пакетный скрипт для NPC или как последовательность игровых событий, и при этом можете использовать множество понятных правил, записанных на бумаге. Этот виртуальный мир был настолько прозрачен для людей, что мы создали два уровня сложности. На первом уровне компании просто водили грузовики, стремясь заработать больше всего денег. На втором уровне цены на газ слегка выросли, компаниям пришлось компенсировать выбросы CO2, а водители начинали уставать. Если водитель управлял грузовиком более 12–14 часов, вероятность аварии возрастала. При аварии водитель отправлялся на отдых, и автомобиль, по сути, простаивал, теряя время. Мы создали эту среду, участники могли программировать своих агентов, а при запуске дискретного событийного моделирования в ускоренном режиме месяцы виртуального времени проходили за считанные секунды реального.
Мы смогли быстро запустить множество симуляций и сказать: “Команды, решения, которые принимали ваши агенты в этом виртуальном мире, дали распределение срока поставки, распределение цен, маржи и число аварий, произошедших с вашими агентами.” По сути, это тот подход, который я обычно использую для объяснения сложной среды. Сначала начинается симуляция, потому что это похоже на игру, правила легко объяснить, без необходимости в дифференциальном программировании. Но когда вы запускаете симуляцию, это по сути анализ Монте-Карло, прослеживающий зависимости в сложных системах. Это означает, что в некоторых случаях на выходе вы не наблюдаете простого распределения, а из-за взаимного влияния элементов системы возникают интерференционные картины. Это выглядит как чёрный ящик, но люди могут понять и изменить правила игры, и, например, если компания наконец поймёт, как работает эта среда, и ей понравятся цифры, полученные медленным путём из-за длительности симуляции, то существует способ оптимизировать вычисления, заявив: “Хорошо, это те цифры, которые мы получаем из симуляции, давайте перейдём к дифференциальному программированию с вероятностями, чтобы получить те же результаты, но быстрее.” Это просто оптимизация производительности. Именно так я обычно к этому подхожу.
Joannes Vermorel: Что очень интересно, за последний год появилась новая категория инструментов — LLM, и это действительно любопытно, потому что это буквально целый класс технологий, которые существуют уже около полудацени, но раньше они были весьма нишевыми, и только эксперты могли действительно оценить их потенциал, поскольку тогда всё сводилось к потенциалу. Может быть, Ринат, как ты видишь, что изменится после внедрения этой категории инструментов LLM? Как ты их сравниваешь? Раньше у нас было несколько классов инструментов для машинного обучения для компаний, таких как классификация, регрессия, методы Монте-Карло. Это были классы инструментов, которые можно было комбинировать, а теперь у нас появился еще один класс совершенно других инструментов — LLM. Возможно, для аудитории, которая знакома с LLM только через ChatGPT, как ты воспринимаешь это в контексте enterprise software, корпоративных процессов? Каково твое общее видение?
Rinat: Я работаю с языковыми моделями с 2015 года, до появления чат-ботов, которые сделали их популярными. Вы правы, они были действительно нишевыми. Их применяли в переводчиках, системах распознавания речи и в моделях, которые исправляют орфографические ошибки или помогают находить текст в огромных корпусах. Когда через ChatGPT они стали известны, их популярность взлетела. Одной из причин этого стало то, что их обучали быть полезными и послушными людям.
Именно поэтому они порой бывают такими раздражающими: когда вы хотите получить результат от модели, а она начинает извиняться, постоянно говоря «Извините», это может сводить с ума. По моему мнению, я делю модели на две крупные категории. Одна категория моделей в основном работает с числами, то есть речь идет о регрессиях, методах Монте-Карло, нейронных сетях. Другая категория — это большие языковые модели, которые, да, работают с числами, но на поверхности имеют дело с текстом, с большим неструктурированным текстом, и именно оттуда исходит их основная полезность.
Эти модели позволяют подключать машину или систему автоматизации непосредственно к взаимодействию с человеком. Например, при использовании регрессий или временных рядов модель нужно интегрировать где-то посредине цифровых бизнес-процессов. С одной стороны находится база данных, в центре — механизм прогнозирования, а с другой — возможно, база данных или CRM или ERP. В лучшем случае вы получаете отчет, но это всё еще цифры. С LLM вы внедряете модель непосредственно в сам бизнес-процесс, в саму цепочку взаимодействия людей.
В применении LLM в корпоративной сфере, что я видел, они в основном используются в том, что называют цифровизацией бизнеса. Это помогает компаниям автоматизировать рабочие процессы, связанные с поиском текста в огромном массиве данных. Например, у компании много информации, у неё есть базы знаний, но эти базы по сути являются изолированными. Это могут быть RFC, анкеты или Википедия, которую никто на самом деле не обновляет, и сотрудникам приходится выполнять задачи, которые нередко требуют поиска информации в труднодоступных местах. Это требует времени, усилий и, особенно, умственных ресурсов.
То, что могут делать LLM, — это выполнять предварительную работу. Они могут составлять черновики статей, проводить исследования по внутренним данным компании, говоря: «Хорошо, вы составляете ответ для предприятия, так что, основываясь на ваших рабочих процессах и закодированных запросах, вот мой черновой вариант». Для каждого пункта из этого контрольного списка они могут показать источник информации. Таким образом, человеку больше не нужно заниматься рутинной работой, и он может перейти к более интеллектуально сложной задаче — проверке, правильно ли сработала модель. Это позволяет существенно повысить эффективность компании. Conor: Если можно продолжить эту мысль, ведь контекст обсуждения — генеративный ИИ, LLM в контексте цепочек поставок. Из того, что ты сказал, Ринат, складывается впечатление, что LLM в целом будут способствовать повышению производительности. Но видишь ли ты какие-то конкретные случаи применения в цепочке поставок, или это просто, как ты сказал, «У меня есть команда полиглотов, мне нужно перевести это RFP на 10 языков»? Rinat: По моему опыту, цепочки поставок немного медленнее внедряют LLM в суть процесса. LLM скорее начинают проникать с внешней стороны. Обычно первыми внедряют их маркетинговые отделы. Когда компания, например, взаимодействует с пользователями, грань между компанией и клиентами — вот где я видел наибольшее применение. Например, существуют маркетплейсы, которые продают товары своим клиентам и хотят сделать это взаимодействие более приятным, а возможно, снизить затраты на само общение с клиентами. Уже сегодня вполне реально создать системы, которые автоматически проходят по каталогам товаров один за другим, неутомимо, круглосуточно, и обнаруживают: «Хорошо, это продукт, но он был внесён поставщиком цепочки поставок с ошибкой». Почему? Потому что я прошерстил интернет, нашёл технические характеристики этого продукта, которые совпадают, нашёл также PDF-описание от производителя, и, по моему мнению, примерно половина интернета указывает правильное значение, а у вас — нет. Это и есть ссылки. Пожалуйста, примите решение, стоит ли автоматически исправлять это. «О, дорогой менеджер, я заметил, что вы исправили описание продукта, это свойство товара. Хотите, чтобы я сгенерировал новое описание, включающее обновлённое число, не только само число, но и текст?». И вдобавок, я создал три варианта описания продукта, чтобы вы могли выбрать то, что имеет наибольший смысл. Я также подготовил текст для SEO-маркетинга, обновил ключевые слова в вашей системе публикаций, а также составил объявления для Twitter и LinkedIn. Ещё один канал взаимодействия между клиентами и розничными продавцами, интегрированными в цепочку поставок, — это листинг товаров на маркетплейсах. Представьте, что вы поставщик, с которым приходится работать многим маркетплейсам, а ваш каталог состоит из 10 000 позиций с небольшими вариациями, например, автомобильных или авиационных запчастей. Вы хотите автоматизировать этот процесс, особенно если ваш собственный инвентарь быстро меняется. Это вполне реально, и я уже видел, как это реализовано. Например, вы получаете несколько изображений продукта, особенно если это товары с повторным использованием, как в моде, и это работает отлично. Вы пропускаете их через систему распознавания изображений, которая работает лучше всего, когда обучена на моде и стилях. Вы получаете тексты, описания, выделяете нужные блоки, автоматически изменяете размеры изображений, и на их основе создаёте описание для пользователей. А затем наступает одна из самых интересных частей. Вы также создаете скрытое описание, дополненное LLM, которое используется для семантического поиска. Что это означает? Когда клиент модной платформы пытается найти какой-либо предмет одежды, он не всегда будет искать, например, «рубашку в стиле бохо с драконами, размер M и стоимостью менее $10». Он может искать: «Эй, я иду сегодня на вечеринку, и там будут мои друзья, что надеть, чтобы мои шорты смотрелись гармонично?» Если у вас есть описания продуктов и семантические пояснения, извлеченные LLM, и вы ищете их, но не полный текст, потому что мало кто знает, как именно пишется «бохо», а используете поиск на основе эмбеддингов, который по сути является векторным поиском — поиском по смыслу текста, а не по точным словам, — тогда вы получаете результаты, которые на первый взгляд выглядят волшебно, поскольку модель как будто начинает предлагать то, что вы имели в виду, а не то, что буквально сказали. Conor: Спасибо, Ринат. Йоаннес, что скажешь? Когда я наблюдаю за цепочками поставок, складывается впечатление, что они работают примерно пополам. Половина сотрудников взаимодействует с таблицами, а другая половина занимается рутинными коммуникациями с партнерами, поставщиками, клиентами и т.д. Таблицы — это действительно автоматизация решения вопроса о количестве, и этим занимается Lokad уже десятилетие. Вторая часть в основном не была автоматизирована, потому что до появления LLM не существовало реальной технологии, способной решить эту задачу. Joannes: То есть, когда дело касается коммуникаций, если налажен очень строгий рабочий процесс, можно автоматизировать, например, через EDI для передачи заказа. Есть некий мост, который передает заказ, и затем возникает задача, не связанная с текстом. Но это не совсем то, что имеют в виду, когда говорят, что люди тратят половину своего времени на работу с таблицами, а вторую половину — на управление партнерами, клиентами, перевозчиками, поставщиками. Скорее, это больше похоже на: «Не могли бы вы ускорить выполнение этого заказа, и если да, то по какой цене?» Это более расплывчато и открыто. Приходится рассматривать такой пограничный случай и писать по нему письмо, чтобы уточнить, что именно подразумевается, что поставлено на карту, и это занимает полчаса. Затем повторяете с другой ситуацией, другим вопросом, и пишете еще одно письмо. В итоге, в отделе закупок каждый за восьмичасовой рабочий день тратит четыре часа на работу с таблицами и четыре часа на написание 20 писем 20 партнерам. Здесь я вижу огромный потенциал для улучшения. Lokad уже буквально автоматизирует первую часть, но с LLM существует огромный потенциал для частичной, но не полной, автоматизации второй части. По сути, позволяя людям получать поддержку в автоматическом составлении коммуникаций, которые будут адресованы вашим партнерам. LLM используются для создания достаточно контекстуализированной версии постановки проблемы и того, чего мы ожидаем от партнера. Если постановка задачи имеет четкие рамки, то можно применять EDI; это просто становится частью полностью механизированного рабочего процесса. Но я говорю о том, что выходит за эти рамки, например, когда вы заказали 1 000 единиц, а получили 1 050. Вы не откажетесь от заказа из-за того, что доставили на 50 больше. Вам нравится этот поставщик, поэтому вы примете и утвердите заказ, получите его и заплатите за 1 050 единиц вместо 1 000. Но вы хотите вежливо сообщить поставщику, что предпочли бы, чтобы они придерживались первоначального соглашения, согласно которому должно отгружаться 1 000 единиц, а не 1 050. Здесь присутствует некоторая тонкость: вы не хотите нарушать рабочий процесс; это почти правильно, но всё же хотите дать понять, что постоянная поставка на 5% больше — недопустима, чтобы поставщик не мог начислить вам немного больше. Именно в этом LLM действительно преуспевают — в такого рода мягкой коммуникации, когда нужно донести сообщение. Понадобилось бы много времени, чтобы подобрать формулировку так, чтобы она не была слишком агрессивной, но чтобы партнер понял, что вы настоятельно требуете строгого соблюдения первоначально согласованного количества. Это тот случай, когда кто-то может мучиться над письмом целый час, а современные LLM справляются с этим буквально за секунды. Они не обладают сверхинтеллектом в том смысле, чтобы видеть общую картину или направление, но если нужно просто изменить тон текста — сделать его немного более агрессивным, мягким или поддерживающим — они блестяще справляются с этой задачей. Может, вам потребуется 20 минут, чтобы проработать полстраницы, а LLM сделает это буквально за секунды. Именно в таких моментах можно достичь огромного прироста производительности в делах, где люди буквально тратят часы. Если рассмотреть масштабнее, представьте компанию, в которой ежедневно происходит тысячи подобных коммуникаций по пограничным случаям. Это новая возможность, которую предоставляют LLM. Для владельцев бизнеса, для заинтересованных сторон, которым нужно увидеть общую картину, требуется значительные усилия, но теперь у нас есть LLM, которые прекрасно справляются с анализом огромного объема неструктурированных текстов и выявлением закономерностей. Представьте, что LLM может просмотреть сотни отчетов или писем или переписок о том, чтобы не отправлять лишние 5%, и к концу дня предоставить краткое резюме руководству, говоря: «Эй, кажется, мы наблюдаем повторяющуюся тенденцию: все больше поставщиков за последнюю неделю пытаются отправить нам больше запасов». Как вам известно, ChatGPT обладает удивительной функцией, называемой продвинутой аналитикой данных, и это буквально как наличие отдела аналитиков данных под вашим контролем. Они не являются экспертами в области цепочек поставок, поэтому для этого вам всё равно понадобится Lokad, но вы можете задавать им простые вопросы типа: «Вот мой файл базы данных, вот мой Excel-файл, проведите анализ и найдите тренды». Это удивительная возможность, которая доступна в основном онлайн. Вы не можете запустить это локально или через API, но ChatGPT предложит теории, напишет код, выполнит его, возможно столкнется с ошибками, исправит их, выведет результаты и даже создаст для вас диаграмму. Весь процесс — от того момента, когда вы отправляете Excel-таблицу и вопрос, до получения красивой диаграммы — полностью автоматизирован. Он самокорректирующийся, самовосстанавливающийся, и вы получаете отличные результаты. Это дает руководителям возможность самостоятельно анализировать данные, даже если они хранятся в сложных системах, визуализировать их без необходимости знать Python, JavaScript, C или SQL. Я думаю, это действительно даёт людям силы, открывает новые бизнес-возможности и создаёт дополнительную бизнес-ценность.
Conor: Примерно шесть месяцев назад мы обсуждали генеративный ИИ и его роль в цепочке поставок, и в целом были несколько скептичны. Когда вы слушаете, что рассказано о достижениях всего за последние шесть месяцев, сохраняется ли у вас прежняя точка зрения или она стала несколько мягче?
Joannes: Моя позиция остаётся глубоко скептической в отношении некоторых аспектов. Мой скептицизм по сути возник как реакция на большинство конкурентов Lokad, которые заявляют: «Мы просто применим ChatGPT непосредственно к терабайтам транзакционных данных, и он сработает». Моё мнение таково: нет, я так не думаю. Я всё ещё весьма скептически настроен, ведь всё не так просто. Если вы утверждаете, что можно просто вывести пару таблиц со схемами или позволить инструменту автоматически исследовать схему базы данных для расчёта одноразовых показателей, например, среднего размера корзины, то это совершенно иное предложение. Раньше это должно было проходить через команду бизнес-аналитики. Я говорю о базовых вещах, таких как средний размер корзины, как долго в среднем мы удерживаем клиентов, сколько единиц продано в Германии — очень простые вопросы. В крупных компаниях обычно работает десятки человек в подразделениях BI, которые весь день составляют одноразовые отчёты. Для подобных задач я считаю, что LLM действительно может помочь, но это никак не то, что предлагают наши конкуренты. Они говорят: «У вас есть эти модели, вы даёте им вашу терабайтную базу данных, предоставляете доступ к Twitter и Instagram, и у вас всё — планирование, решения, полностью автоматизировано». Я говорю: нет, даже близко. Мы живём в мире фантазий.
Rinat: Относительно вашего ответа на этот вызов, у меня есть две мысли. Во-первых, о процессе использования LLM для обработки огромного количества данных: я работаю с различными LLM уже довольно давно. Один из первых вопросов, который обычно задают клиенты, — можно ли запустить что-то вроде ChatGPT локально на их площадке. Чтобы ответить на этот вопрос, необходимо провести тестирование LLM в разных конфигурациях и выяснить затраты. LLM довольно дороги. Прогон одного мегабайта текста через модель для предсказания может стоить пару евро, в зависимости от модели. Если вы хотите запускать его локально на лучших доступных моделях, это может обойтись в 10 или, может быть, 20 евро.
И вот что делает GPT-3.5; это очень дешёво. Но суть в том, что пропустить через LLM терабайты или петабайты данных даже невозможно. Во-вторых, LLM ужасно справляются с числами. Если кого-то попросить LLM выполнить математические вычисления или перечислить простые числа, это будет неправильным использованием. LLM — это языковые модели; у них огромная база знаний и они очень интеллектуальны, хотя и имеют ограничения. Вы не просите LLM решить математическую задачу напрямую; вместо этого вы просите его сформулировать задачу, а затем вычисления передаются специализированному ядру Python или чему-то подобному, что справится с этим намного лучше, чем трата ресурсов на LLM.
Самое интересное происходит на стыке различных областей. Например, с одной стороны у нас огромная числовая область, с другой — текст или мягкие, расплывчатые крайние случаи, а третьей — код. Код — это не числа, не текст, он структурирован и в то же время проверяем, и LLM чрезвычайно хорошо справляются с ним. Это создаёт новые возможности, которые могут быть применимы в цепочке поставок, расширяя применение таких решений, как Lokad, ещё дальше.
Например, один из случаев, когда я использовал LLM для анализа огромного количества текста, выходящего за рамки его возможностей, заключается в том, что я формулирую задачу для LLM. Например, поиск текста в сотнях гигабайт годовых отчётов по всему миру или помощь в решении числовой задачи без проведения фактических вычислений. Вы разрабатываете теорию подхода, потому что вы умны, знаете предысторию, и это те управляемые параметры, которые я вам задаю.
Когда речь заходит о поиске по огромной базе данных, я прошу LLM в определённом синтаксисе сгенерировать embedding запросы, над которыми я буду работать, составить список стоп-слов или белый список ключевых слов, которые усиливают поиск. Затем другая система, предназначенная для обработки в масштабах, берёт этот правильно сформулированный запрос от LLM и выполняет его. Вот где проявляется лучшая часть, ведь LLM способны уточнять поисковые запросы.
Вы возвращаетесь к LLM и говорите: «Вот моя исходная проблема, вот что вы о ней подумали, вот запрос, который вы составили, и вот бесполезный результат, который он вернул. Пожалуйста, скорректируйте и адаптируйте.» Поскольку работа с LLM практически бесплатна, вы итеративно повторяете процесс, может быть, около десяти раз, применяя метод цепочки мыслей или дерево мыслей с хорошими и плохими решениями, и затем результат улучшается. То же самое применяется и к числовым областям. Например, менеджеры по снабжению хотят придумать способ, как лучше сбалансировать запасы. Теоретически они могут сказать: «Вот небольшая симуляция моего окружения, которой, возможно, достаточно, и вот как вы можете её настроить. А теперь, пожалуйста, проведите нечеткое решение ограничений и попробуйте предложить идеи, которые помогут мне лучше сбалансировать запасы.»
Это возможность, которая открывается, когда вы начинаете объединять несколько областей: числовую, код и текст, и используете лучшие инструменты, доступные для каждой из них вместе.
Conor: Спасибо, Ринат. Джоаннес, что вы об этом думаете?
Joannes: Чтобы прояснить для аудитории, интересная особенность в том, что для множества задач подход с использованием LLM заключается в том, чтобы сказать: «Пожалуйста, составьте программу, которая решит задачу». Вы не скажете: «Я хочу, чтобы вы решили задачу». Вы скажете: «Составьте программу, а затем я изучу её». Существуют и другие приёмы, например, предоставление LLM компилятора для проверки, компилируется ли программа, или инструмента, который позволяет запустить программу немного, чтобы убедиться, что результат имеет смысл.
Дело не в том, чтобы LLM решал проблему напрямую; всё происходит опосредованно. LLM генерирует программу, затем используется что-то другое, что всё ещё является текстовым выводом, потому что если использовать компилятор, он попытается скомпилировать программу. Если это не удаётся, он выдаёт сообщение об ошибке. LLM обожают обрабатывать сообщения об ошибках и исправлять связанные проблемы. Мы полностью находимся в текстовой сфере.
Для цепочки поставок большинство ситуаций будет опосредовано. Мы хотим, чтобы LLM составил программу, которая решит поставленную задачу. Например, в исходной задаче по определению оборота в Бельгии за прошлый год для клиентов с объёмом свыше 1 миллиона евро LLM не возьмёт данные из базы данных для расчёта. Он составит SQL-запрос, который будет выполнен самой базой данных. Опять же, опосредованное решение.
Что это означает для корпоративного программного обеспечения? Есть ли у вас, в рамках вашей корпоративной среды, платформы, которые поддерживают выполнение цепочки поставок, хотя бы на уровне принятия решений, с возможностями программирования? LLM не возьмёт необработанные транзакционные данные для получения результата; он берёт формулировку задачи, создаёт программу, и эта программа очень универсальна. Но затем что-то в вашей среде должно выполнить эту программу. Какую среду программирования вы можете предоставить для LLM?
Большинство классического корпоративного ПО не предоставляет никакой среды. У них есть лишь база данных с языком, который вы можете использовать, но единственный способ взаимодействовать, скажем, с крупной ERP-системой, которая должна позволить оптимизировать запасы, — это ручная настройка минимальных и максимальных уровней запасов или параметров резервного запаса для каждого продукта. LLM может подсказать рецепт, который необходимо применять, но если вы хотите его реализовать, придётся настраивать ERP вручную. Если ERP предоставляет API, он может составить программу, позволяющую сделать это в масштабах через API, но это всё равно очень громоздко по сравнению с нативным программируемым решением. Всё будет опосредовано через фреймворк.
Это требует серьёзных изменений и внедрения программируемости решения как объекта первого класса. Без стеснения скажу, что у Lokad есть программируемая платформа. Мы не делали этого специально для LLM; это скорее была удача, но мы сделали это 10 лет назад, чтобы программистский подход стал ядром платформы и объектом первого класса. Это была удача, а не провидческое предвидение того, что произойдёт через десятилетие с LLM.
Conor: Спасибо, Джоаннес. Я помню о времени всех, поэтому, как принято, Ринат, передаю слово вам для заключительного слова. Есть ли что-то, что вы хотели бы сказать всем, кто смотрит?
Rinat: В прошлом были несколько пузырей, таких как дотком-пузырь и финансовый пузырь. LLM и ИИ тоже могут оказаться пузырём, а могут и не оказаться. Даже моя мама знает о ChatGPT и как им пользоваться, что интересно. Я призываю всех не бояться наших машинных властителей, ведь Скайнет не заработает так легко. Будучи человеком, который пытается стабилизировать эти системы в производстве, я знаю, что это требует огромных усилий и не всегда работает надёжно. Так что, во-первых, не бойтесь LLM, а во-вторых, просто принимайте их. LLM в сочетании с людьми и бизнесом могут создавать куда большую ценность, особенно в связке со специализированными инструментами, такими как прогнозирование от Lokad, которые отлично интегрируются в окружение.
Conor: Спасибо, Ринат. Джоаннес, большое спасибо за ваше время. Ринат, огромное спасибо, что снова присоединились к нам. И спасибо всем за просмотр. До встречи в следующий раз.
