Применение ИИ в e-commerce

Значит, прежде чем перейти к основной части и представиться, хочу сразу огласить правила. Правила очень простые: все вопросы, которые появляются у вас, можете писать в чате в канале. Мы будем их задавать нашему гостю, нашим гостям. Относитесь друг к другу с уважением. Вот, всё. Единственное правило.

Значит, меня зовут Лыков Александр. Я академический руководитель Школы высшей математики. Мы запускаем, у нас разные есть программы по обучению в искусственном интеллекте, есть математические программы по высшей математике, разные. И сегодня у нас в гостях, в нашем вебинаре, Артём Бочкарёв. Отвечает за ML в AliExpress, Head of Data Science, выпускник Физха, очень крутой специалист в Data Science. Он расскажет про применение искусственного интеллекта в e-commerce. Артём, пожалуйста.

Слово так. Да, всем привет. Я сейчас пошарю свою презу. Одну секунду. Так, сейчас, одну секунду, я перезайду. Мне нужно... Так, да, вот я зашёл. Извините за накладку. Видно ли мой экран сейчас?

Да, да, всё видно.

Отлично. Так, а ну, у нас правила, что потом? Да, мы задаём вопросы. Мы можем их накапливать, наверное, в чатике.

Угу, да.

Так, вот видно ли сейчас полную, полную презентацию?

Так, пропала. Вот до этого была. Сейчас пропала. Теперь на полный экран видно?

Да, да.

На полный. Всё супер, супер, супер. Так, да, давайте начинать. У меня сегодня доклад, собственно, AI моделей в задачах e-commerce. И я постараюсь рассказать про эти применения, про эту тему, преимущественно в разрезе соприкосновения с LLM, с большими языковыми моделями. Вот. И расскажу о своём опыте.

Пару слов про меня. Почему вообще я взял на себя смелость рассказывать про это? Я, какая была моя карьерная лестница? Я работал в начале карьеры в Озоне несколько лет. Я занимался Data Science прикладным в нескольких командах. Делал рекомендации, руководил командой поиска, делал A/B-тестирование, делал алгоритмы всякие для складской оптимизации для складов Озона. Вот. И добился, в общем, там достаточно нормальных результатов. Последние 4 года с небольшим я руковожу отделом ML в AliExpress. У нас есть пять команд ML-инженеров, которые занимаются разными, разными задачами, связанными с ML. Разбиты они по доменам либо по продуктам. Вот. Моя роль заключается в управлении всеми этими... вклада, которые эти проекты могут в бизнес, запуск новых каких-то инициатив и помощь в построении жизнеобеспечения критической инфраструктуры для, которая требуется, чтобы обучать модели и получать какой-то профит. Вообще, в основном скоупом, и я именно про эти модели, про эти применения буду рассказывать, потому что это то, в чём я разбираюсь. Про какие-то вещи я могу не знать, которые с этим не очень связаны. Я видел до этого много вопросов, которые были заданы при регистрации на вебинар. Вот. Я думаю, что моя преза будет точно весь спектр, потому что они были очень разнонаправленными и разносторонними. Поэтому на что-то я смогу ответить, на что-то, может быть, получится ответить в конце, в конце презентации, когда у нас будет время на вопросы.

Итак, давайте начнём. Собственно, наш, наш рассказ. Как я построю своё выступление? Сегодня я сначала расскажу про какой-то кейс применения больших языковых моделей в e-commerce, успешный, который прямо у нас стреляет и который используется в продакшене, и который мы считаем успешным с точки зрения как ML, так и бизнеса. Дальше я попробую дать представление вообще о каких-то других задачах, которые встречаются в e-commerce, может быть, моделями, которые вы будете использовать, и которые приносят. Ну и, наконец, я завершу перечислением каких-то основных направлений перспективного применения в e-commerce, как я себе это вижу, и то, что мы делаем сейчас в AliExpress, чтобы было понятно, куда, куда движется индустрия, какие вещи мы пробуем. Вот. Это не исчерпывающий список ни наших проектов, ни того, что мы делаем. Вот. Возможно, если появятся ещё вопросы, я в конце про это что-то про расскажу. Вот.

Давайте тогда дальше поговорим про успешное применение, про успешный кейс применения. Прежде чем про это вести разговор, вообще обсудить, какие важные вопросы мы должны задать, как люди, которые собираются внедрять в e-commerce, прежде чем мы начнём это делать, потому что, безусловно, LLM – это хайпово, круто и так далее. Вот. Но прежде чем начать что-то такое применять, хочется, собственно, сформулировать вообще, с чем мы имеем дело. Я сейчас побуду, приведу список вопросов, которые я считаю важным ответить для себя, прежде чем начать что-либо делать.

Во-первых, мы хотим задаться вопросом: зачем мы вообще всё это делаем? Какая у нас бизнес-бизнес-цель всего мероприятия? Я говорю это с точки зрения человека, который занимается именно практическим прикладным ML. Мы обычно стараемся не делать какой-то research прямо в стол ради research или ради движения науки вперёд. К сожалению или к счастью, вот у нас, наша деятельность напрямую завязана на какие-то метрики. Вот. Мы должны определить, что за проблема мы хотим решить, какие метрики для бизнеса являются главными в этом домене, в этой сфере, и что значит вообще успешно решить задачу. Какие метрики мы хотим подрастить? И можем ли мы эти метрики замерить? И критичный вопрос: верим ли мы сами, что той тем решениям, которое мы разрабатываем, мы эти метрики сможем пошарить? К примеру, если мы говорим про то, что мы хотим, я не знаю, сменить плашку там у какого-нибудь телефона, там поменять цвет, главный или что-то. Верим ли мы, что это вырастут там ордера или ещё что-то? Я сейчас говорю не про проект, вообще в целом, что мы на какие вопросы мы хотим здесь ответить.

Вот. Дальше, соответственно, когда мы определились с тем, зачем мы это делаем, какую проблему решаем, что у нас за метрики, нам нужно посмотреть на те данные, которые есть в нашем распоряжении, и с помощью которых мы, собственно, будем задачу решать. Помимо того, что нам нужно понять вообще структуру данных: что это, картинки, текст, какие-то табличные, это просто сырые логи, вообще не обработанные. Нам нужно понять, сколько у нас этих данных есть и насколько чистые данные, потому что от этого критическим образом зависит то, какие модели мы будем использовать, какие методы мы будем применять. Вот. Помимо того, что нам нужно разобраться с данными, не менее важно понять, будет выглядеть на продакшн столе. Мы делаем для того, чтобы они приносили бизнес итоговый результат. У нас почти всегда это какой-то продакшн-процесс, и нам нужно заранее понимать, что это за продакшн-процесс, в каком моменте он используется, когда, когда юзер там или кто-то взаимодействует с приложением, сайтом. Нужен ли нам real-time? Если не нужен, как часто нам нужно делать какие-то предикты, которые мы хотим? Если нам нужен, то насколько нам нужно уметь быстро отвечать? Какая нагрузка? Соответственно, из этого вытекает, какое железо у нас есть, какое железо нам нужно.

Вот. Теперь только ответив, мне кажется, на вот эти вот три больших блока вопросов, можно перейти к, собственно, самому интересному для инженера, для исследователя. То, какие мы модели будем здесь применять. Ответы на предыдущие блоки напрямую влияют на выбор модели. Обычно хочется всегда, когда мы работаем с реальной какой-то задачей, применить самые простые модели, потому что они дают возможность быстро итерироваться и требуют меньше всего каких-то вычислительных решений, вычислительных ресурсов, простите. Вот. Но не всегда этого достаточно. Какие, какое семейство моделей мы будем применять? Можем применять линейные, ансамблевые модели, нейронные сетки. Если мы хотим применять LLM, например, то будем ли мы поднимать свою или мы будем где-то запрашивать какой-то чужой и к ней ходить просто с данными? Это всё вопросы, на которые нам предстоит ответить.

Вот. Это такой слайд, вводный, который просто подчёркивает какую-то вот парадигму, как мне видятся основные, основные вопросы, на которые нужно ответить при построении ML-решения. Дальше мы будем какие-то конкретные кейсы смотреть в разрезе ответов на эти вопросы.

Вот. Давайте перейдём теперь к конкретике. Извините от теоретической части. Проектом, который у нас взлетел с LLM, про которые я здесь хочу рассказать, это генерация товарных тайтлов. Что это за задача такая? Тут вот на слайде вы видите, слева есть то, как выглядит обычный товар с AliExpress. Вот. В нём есть тайтл. Тайтл у нас сверху написан над вот этой звёздочкой с числом отзывов. И тут, как вы видите, не знаю, 20 слов, они все немножечко про одно и то же. Но сходу, вот когда видишь этот тайтл, особенно без картинки, где-то в поиске, может быть, вообще не очень понятно, про что идёт речь. Вот. И это очевидная проблема. То есть на первый вопрос: можем ответить, зачем мы это делаем? Мы хотим починить вот эту ситуацию для пользователя, когда у нас нечитаемые тайтлы и непонятно, что за товар имеется в виду. Про какой товар идёт речь? Мы хотим таким образом поднять метрики довольства пользователей, чтобы им новые тайтлы нравились больше, и в идеале мы хотим поднять какие-то конверсионные метрики, чтобы увидеть результат в А/Б-тесте.

Вообще, пару слов скажу, почему так получается, почему на AliExpress такие тайтлы. Дело в том, что львиная доля товаров у нас это заведённые из Китая китайскими продавцами. Китайские продавцы обычно знают только китайский, и у них немного другие, другие цели, другое представление того, как должен выглядеть тайтл у товара. Поэтому, чтобы получить такой тайтл, обычно какой-то китайский продавец вводит свой тайтл на китайском, потом AliExpress-переводчик переводит это на английский, а дальше мы получаем перевод из английского в русский, и выходит вот такой вот короткая, непроницаемая парка, пальто из натурального кроличьего меха, натуральный лисий енот. Вот. Ничего не понятно, хотя в принципе понятно, что речь идёт о какой-то куртке, которая, в общем-то, ну, не супер сложный товар. Вот. Это, соответственно, вопрос: зачем мы это делаем?

Дальше, какие, какие данные у нас есть, чтобы эту проблему исправить? Мы хотим использовать, соответственно, все данные о товарах, которые это может быть, описание, атрибуты, категория его. У нас товаров очень много. Сейчас у нас порядка 200 с чем-то миллионов SKU. 200 с лишним SKU – это... ой, айтемов. Айтем – это, собственно, товар. У товара может быть несколько SKU. SKU – это вариация товара, которая может отличаться цветом, размером, чем-то ещё. Из каких-то данных очень много. Вот. И все эти данные, они на самом деле грязные в плане тайтлов, потому что мы гарантированно не знаем товаров, на которых написан хороший тайтл, какие-то товары, на которых вот такой тайтл. То есть мы ничего сдуть сказать не можем про тайтлы, и у нас нету какой-то другого способа получить хорошие тайтлы. Мы для этого используем нашу внутреннюю краудсорсинговую платформу для разметки. Вот. Соответственно, мы можем эти данные собрать, попросить людей, чтобы они вот такие вот товары написали какой-то понятный и человекочитаемый тайтл.

Посмотрим, есть ли у этой задачи какие-то ограничения по продакшну? Нам не нужен здесь никакой real-time. Нам не нужен, потому что в принципе, как бы, товар завели, он лежит, с ним больше ничего не происходит. Периодически его продавец может может изменять. То есть нам нужно один раз, по сути, запретить на все товары какие-то новые тайтлы, и дальше просто обновлять наш дит, если появится новый товар или если у старого что-то поменяется. И у нас есть большой датасет, под большие данные у нас есть много GPU, собственно, ресурсы. У нас есть задача не супер сложная в плане, в плане какого-то хайпа. Поэтому вот первая, первая идея была, что действительно здесь нам LLM смогут чем-то помочь, и будет, будет сделано эффективно и хорошо этот проект. Вот.

Ну и, собственно, забегая вперёд, я сказал про LLM, что мы можем сказать про эту задачу с точки зрения моделей? Я не знаю какой-то простой модели, которая может вот из такого тайтла выбрать, э-э, выбрать и сгенерировать какой-то короткий, человекочитаемый типа: "зимняя куртка для женщин там с капюшоном". Вот. Это довольно сложная ML-задача на самом деле. Если так подумать, эта задача вообще может быть сформулирована быть как задача машинного перевода. Она очень близка к ней, когда нам нужно из вот такого вот AliExpress-ного русского перевести в нормальный, человекочитаемый русский язык. При этом, человекочитаемый русский язык – критерий, что такой человекочитаемый русский язык, он тоже...

[музыка]

...довольно, довольно неоднозначен. И мы не всегда точно можем там одному человеку кажется, что это назвать зимней курткой, другому там кажется, что это пальто. То есть, в целом, тут даже тоже могут быть какие-то противоречия, которыми нам надо уметь работать. Ну и более того, здесь нам в итоге нужно сгенерировать текст, потому что просто выкинуть и зачеркнуть какие-то слова и получить результат здесь не получится. А поэтому это как раз идеальный кейс того, где нам может помочь LLM, и здесь справляется хорошо.

Действительно, опишу общий подход, как мы эту задачу решаем и что у нас получилось. Мы сначала собрали достаточно много чистых данных, попросив людей, показываем им разные товары, попросив их написать тайтл для этих товаров, как вот им кажется правильным и хорошим. Понятно, что мы там потратили какое-то время, чтобы э-э составить, сформулировать там для нас самих, что мы считаем хороший, правильный тайтл. И дальше мы пробуем собрать какое-то количество там тысяч, десятков тысяч примеров, когда люди пишут хорошие тайтлы. После этого, что мы можем сделать как инженер, работающий с LLM? Мы можем, соответственно, написать, попробовать начать писать промпт для этой... просто использовать промпт. Можно её тюнить на той разметке, которую мы до этого собрали. В промпте можно указывать какие-то неочевидные вещи, типа добавлять блок-лист слов, которые мы точно не хотим видеть, либо наоборот, просить модель сохранить бренд, например, для товара, потому что в каких-то категориях это очень важно. Вот. После того, как мы провели такую итерацию, нашли какую-то версию LLM, мы берём выборку товаров, которых она до этого не видела, просим её сгенерить тайтлы на эти товары, и после этого мы всё это, этот результат отдаём на ручную разметку.

Вот. Соответственно, зачем нам снова отдавать на ручную разметку? Потому что мы, задача генерации текста, она не просто там задача классификации. Мы не можем заранее собрать какой-то валидацию работы. Нам нужно обязательно после того, как мы что-то сгенерили, проходить вот этот вот луп, отдавать людям наши предикты на посмотреть и оценить. И дальше мы снова переходим к предыдущей итерации. Вот так вот итерируясь, пока нам не, не покажется, что модель достаточно хороша для нашей задачи.

Кратко скажу, какие у нас результаты получились. У нас есть два типа оценивания результатов: офлайн, как обычно, и A/B-тест. В офлайне мы мерили две метрики. Это... это когда модель придумала какой-то... мы работаем с каким-нибудь телефоном, и модель сказала, что это не смартфон, а кнопочный телефон, тайтл такой назвала. Это очевидная ошибка, как бы, мы такое не любим. У нас получилась модель имеет меньше 5% таких ошибок. А вторая, финальная метрика, которую мы замеряли, это сравнение side-by-side, когда мы показываем человеку, соответственно, два товара, и он просим... вернее, не два товара, сорри, а один товар с двумя разными тайтлами. Один тайтл – оригинальный, второй тайтл – это тот, который мы, собственно, с помощью сгенерировали. Какой тайтл с его точки зрения лучше, более подходящий, более красивый? Что у нас получилось? В 87% случаев почти наша модель выигрывает, то есть генерирует лучше тайтлы, чем исходные. 25% – ничья, и там в 6% мы проигрываем. Понятно, что никакая модель не может работать идеально. После выкатки в A/B-тест мы получили рост ордеров, конверсии в ордер примерно на 1%. Скажем так, вот. И по дополнительным продуктовым прокси-метрикам мы видим, что юзерам стало проще находить товары, проще понимать из поисковых, из рекомендаций, что это за товар, ориентируясь на короткий тайтл и переходя на него, нежели это было с оригинальными тайтлами. Вот. Ну и в итоге получается, что мы вот такими вот менными тайтлами, красивыми, покрыли 70% товаров, которые у нас в принципе когда-либо показывались на платформе. Вот. Это мощный, хороший результат, и здесь уже можно поставить себе галочку, сказать, что мы молодцы. LLM нам... живой кейс, когда мы просто применили LLM и получили влияние на ML-компанию, которое можно замерить в тесте. Это, собственно, идеальный сценарий, то, к чему мы стремимся и для чего мы работаем. Вот. Это, собственно, пример кейса.

Давайте я ещё расскажу немножко про другие задачи и посмотрим, какие... секунду.

Артём, а можно вопрос сразу в топку? А вы вот эту задачу решили на какой-то внешней или вы какую-то свою там развернули?

У меня отключились наушники. Сейчас я слышу. А, да, про LLM. Здесь мы использовали Open Source LLM. Мы не делали, не тренировали с нуля какую-то foundational модель. Мы брали Open Source разные, разные модели, там Gemma, не знаю, Llama, разные китайские вот эти вот все истории, и мы просто смотрели, что лучше работает.

Угу.

Вот. И поднимали это у себя.

Так.

Всё, вернулись мои наушники. Извините.

Дальше, что я под этим имею в виду? Давайте посмотрим ещё на парочку проектов, которыми мы в e-commerce встречаемся и работаем. Первый проект – это проект модерации. Также я структурированно попробую про него рассказать. Зачем мы решаем задачу модерации? Компания миллион товаров, и среди этих товаров много бывает нелегального, чего-то запрещённого, что нельзя просто по закону продавать. И если какие-то контролирующие органы найдут это у нас на сайте и придут, а такие кейсы, как бы, периодически всплывают, то это грозит юридическими разбирательствами, судами, штрафами, вот это вот всё. Ну, мы хотим соблюдать законодательство и убирать такие вещи с нашей платформы. Также мы не хотим показывать какой-то вызывающий контент, где будут, не знаю, грибок, грибок ног какой-нибудь увеличенный, или там 18+ товары, которые будут всплывать у подростков на главном экране. То есть мы вот это вот тоже хотим с этим справиться.

Модераторы по таким признакам. Как можно решать эту задачу? Почему вообще ML? Потому что с таким количеством товаров, как на AliExpress, невозможно посадить людей и заставить их разметить 200, 200 млн товаров на соответствие каким-то там правилам. Это просто в принципе невозможно. Тут никак не обойтись без ML, если мы такую, такую задачу хотим решать. Что у нас есть для этого решения? В принципе, тоже самое, что у нас было в предыдущем примере, в предыдущем проекте. У нас есть вся информация по товарам, которые, которую мы можем только себе вообразить: картинка, тайтл, описание, атрибуты. Опять, всё вот это вот. И мы имеем доступ к надёжной, хорошей, любимой получать какую-то разметку: соответствует товар правилам или не соответствует.

Какие у нас ограничения на продакшн? Нам здесь не нужен тоже, в принципе, как и в тайтлах, потому что никто не будет стоять там и за 3 секунды ловить товар, пока его не забанили. В принципе, время есть, чтобы забанить товар. Но тут надо понимать другое ограничение: мы хотим при введении каких-то новых правил, юридических или новых законов, мы хотим уметь достаточно быстро обновлять скоры, пересчитывать, пересчитывать всё, все наши правила, и новые правила, которые мы добавляем, в том числе по всем товарам. Что это означает на практике? Это означает, что когда вводится новое правило, это может вводиться там, не знаю, раз в неделю, несколько раз в неделю что-то происходит. Нам нельзя с этим долго, долго возиться. Мы должны достаточно быстро всё это разруливать. Работать только с помощью ML решать эту задачу. У нас продакшн забит всеми вычислительными мощностями. Это, очевидно, очень большая задача.

Что дальше? Какая у нас здесь задача? У нас здесь задача классификации. Нам не надо ничего генерировать, нам нужно просто определить, удовлетворяет товар каким-то нашим правилам или не удовлетворяет. Какие мы можем здесь выбирать модели? На самом деле, здесь мы можем использовать очень простые модели. Например, чуть ли не какие-нибудь регулярки. Мы даже используем, на самом деле, регулярки в продакшене на этой задаче тоже, чтобы находить какие-то, ну, запрещённые слова. То есть никто не хочет видеть там свастику, какой-нибудь нацизм, ещё что-нибудь в этом духе в товарах или в отзывах. И мы такое можем без помощи всяких LLM и больших языковых моделей поймать. Помимо этого, здесь в этой задаче критически важно то, что мы будем использовать и смотреть ещё и на картинку, а не только на текст, потому что зачастую запрещённый контент он может быть и в тексте, может быть и в картинке. Вот. Но картинка – это достаточно большая доля из всего того, что мы баним, поэтому здесь обойтись просто одним текстом не получится.

Вот. Когда вопросы ответили, можно какое-то общее решение набросать. Давайте я в паре слов, в паре слов расскажу, что у нас получается. Наш общий подход здесь такой: мы берём какое-то новое правило, которое к нам поступает от юристов или от каких-то контролирующих органов. Вот. Правила – это, знаешь, обычно означает следующее: вот такой товар или вот такую группу товаров их надо забанить. Окей. Что мы с этим делаем? Мы считаем фичи по тексту, картинке, по каким-то другим полям, которые есть у нас в товаре, и пытаемся найти похожие на них, потому что очевидно, что если юристы там принесли нам один какой-то товар, наверняка они все не искали, и в принципе, невозможно им вручную всё, всё такое найти. Поэтому нам надо сделать эту работу. Мы ищем похожие товары и просим наш метчиков разметить их и сказать, нарушают ли вот эти товары все сформулированное правила или не нарушают. После того, как мы такую разметку получили, мы можем фичи, которые мы на предыдущем шаге создали, и другие какие-то фичи: цену, категорию, атрибуты, что угодно, что мы придумаем, использовать в качестве входов, с помощью этой модели посчитать вероятности для всех товаров вообще AliExpress, насколько они удовлетворяют или не удовлетворяют этому правилу. Вот. После того, как у нас такая модель есть, которая оценивает вероятности, мы можем выставить пороги, опять же, исходя из какой-то ручной разметки, и запустить эту модель в продакшн. Всё. Таким образом, мы переходим к модели, которая может нам сделать достаточно быстро предикты по всем товарам и сказать, какие из них надо забанить, а какие товары – окей. Собственно, это у нас сейчас работает в продакшене. У этой штуки очень высокая точность, при этом зависит от типа этого правила, которое мы... Вот. Там есть разные, как бы, цифры, но в целом нас точность устраивает. Более того, главным образом нас устраивает, что сейчас у AliExpress нету каких-то, тьфу-тьфу-тьфу, проблем с законом в плане нелегального контента или как чего-то запрещённого. Мы, в принципе, можем, если такие проблемы будут всплывать, мы можем их быстро, оперативно решать, не доводя дело до штрафов и до судов. Вот. Это один из таких примеров. Смотрите, задачи, которая не использует себе LLM, вот, но при этом она, можно сказать, критически важна, важна для решения для бизнеса. И я бы сказал, что в случае AliExpress это такая уникальная на российском рынке технология, потому что я не особо слышал, чтобы там кто-то ещё вот настолько тщательно и выверенно своего контента. Но нам это просто необходимо, потому что у нас дикое количество китайских товаров, где может быть вообще всё, что угодно. И без вот этого нашего счёта мы не сможем, мы не сможем просто на российском рынке нормально работать и оперировать. Вот. Это ещё одна задача, которая является важной для бизнеса.

Давайте представлю ещё один, ещё один пример задачи, которая решается нами, и которую мы считаем очень важной. Это задача поиска рекомендаций. Какая у нас здесь цель? Мы вот слева нарисован скриншот выдачи наша по запросу "беспроводные наушники". Мы хотим по любому такому запросу, либо в рекомендательной ленте, если мы говорим про неё, показывать самые релевантные товары для пользователя. С одной стороны, при этом мы хотим, чтобы пользователь не только их там смотрел, кликал, но ещё их покупал. То есть росло наше количество продаж, росли наши деньги, revenue и так далее. Вот. То есть здесь для вот этого вот проблемы, как нам, какие товары показать наиболее релевантные, наиболее подходящие для пользователя, мы на самом деле оптимизируем вообще, в принципе, главные метрики компании – это GMV, revenue, и сколько у нас людей покупает. Вот. В случае поиска мы также можем как метрику использовать релевантность поиска. Релевантность – это оценка, насколько вот заданный товар релевантен, не релевантен, может быть, запросу, по которому мы его ищем. Ну вот здесь хорошая, хороший кейс, видно, что это, в принципе, всё беспроводные наушники, они все релевантны. И дальше уже идёт вопрос, насколько действительно там вероятно, что человек купит их или не купит. Так, с точки зрения релевантности, здесь всё.

Какие здесь данные для этой задачи? Вообще, если мы хотим что-то, что-то такое решать, у нас, помимо тех данных, с которыми я уж два раза упоминал, весь контент всех товаров, у нас есть все логи пользовательских сессий, многие из которых закончились как-то позитивно для нас и для пользователя. Что значит позитивно? Пользователь кликнул, что-то, может быть, что-то заказал, добавил в корзину. То есть произошло качественное взаимодействие между пользователем и тем, что мы ему предложили. Вот. А какие у нас здесь ограничения на продакшн? Э-э, так как мы ожидаем всё-таки мгновенной работы поиска и интересных, разнообразных...

рекомендаций, которые обновляются не раз в день. Нам здесь нужен real-time. А помимо этого, кроме того, что нам здесь нужен real-time, сервисы, которые вот эти вот штуки делают, они могут находиться под достаточно большой нагрузкой, особенно во время распродаж. Во время там нашей главной распродажи 11.11 у нас многократно повышается трафик, люди все заходят, пытаются купить, покупают, и нам всё равно, несмотря на то, что на платформу заходят миллионы пользователей одновременно, нужно, нужно, чтобы эти ML-модели работали как часы и отдавали какие-то предикты. При этом нужно, да, чтобы это было быстро, меньше одной секунды в идеале, намного быстрее, потому что помимо того, что когда вы вводите запрос в поисковую строку, должна отработать ML-модель, там ещё есть много всякой подкапотной кэндо-ской машинерии, вида там достать нужную цену, достать нужный тайтл, подгрузить картинку. То есть всё это не происходит мгновенно и по волшебству, поэтому тут для ML вообще очень-очень большие, большие ограничения по времени, насколько быстро мы должны отвечать. Вот, ну и собственно, дальше, когда у нас есть ответ на вопрос, почему данные и какие у нас ограничения на на прок, мы можем подумать о моделях. Очевидно, что задача вообще, ну, понять, релевантен товар или не релевантен, затек какие-то модели, мэтчинг-модели, рела и модели ранжирования. Вот для таких вещей обычно подходят либо какие-то ансамблевые методы над деревьями, какие-то модели бустинга типа CatBoost, XGBoost, LightGBM и так далее. И могут э э также хорошо себя показывать языковые модели типа BERT ээ в качестве именно модели для ранжирования. Но здесь опять же нужно говорить про то, что inference должен быть очень быстрый, то есть Преди мы здесь не можем ковыряться и долго что-то генерить. Вот.

Давайте теперь я коротко расскажу, как мы эту задачу решаем. Мы пытаемся всегда собрать как можно больше данных, насколько это возможно, насколько пролезает в на в нашу GPU-машину и кластер. Модели поиска рекомендаций мы обычно решаем двух стадийность. Перера мы их уже на основании каких-то наших целей и ранжирования. Вот что, что за модели для мэтчинга мы здесь можем использовать? Либо какие-то нейронные сетки, искать ближайших через векторный поиск, это в поиске. Либо мы можем использовать обратный индекс обычный, как в любых поисковых движках, как так работает, это тоже в поиске. Либо если мы говорим про рекомендации, мы тоже можем использовать либо нейронки, либо какие-то алгоритмы матричной факторизации, чтобы искать ближайшие товары, самые подходящие для пользователей или под товар, если мы говорим про ам ам рекомендации. Дальше нам нужно сгенерировать фичи из сырых сессий. Что значит фичи? Это значит, мы можем посчитать какие-нибудь статистики, аля, как часто по этому запросу покупают этот товар, или в принципе, насколько этот товар часто часто покупают, насколько у него высокая, то есть вот такие вот штуки мы можем посчитать. Таких статистик много, много, много разных, обычно это несколько сотен фичей. Вот. И дальше мы обучаем модель ранжирования, которую мы пытаемся натренировать на тот таргет, который мы хотим оптимизировать. Это тоже на самом деле бизнес, бизнес решение. То есть мы хотим от нашего поиска, можем теть, можем хотеть какую-то комбинацию между этими двумя метриками. При этом ещё есть какие-то рекламные товары, которые для которых важнее клики, а не продажи, потому что нам платят за клики и так далее. Вот. То есть здесь мы тоже имеем достаточно, достаточно большую почву для эс.

[музыка]

Говоря, можно сказать, что ну вот на моей какой-то, по моему опыту, на моей памяти, если суммарно взять выкладки, релизы, всё такое, порчу и по рекам, это будет ну больше, чем в 10 раз, наверное, и больше импакта на бизнес по сравнению с первым проектом, который я показывал. Про я хочу сказать, в данный, в данный момент времени, конкретно вот на ком бизнесе, как я себе его вижу и как он работает в AliExpress, вот решение вот этой задачи, оно с точки зрения денег и удержания пользователей и числа заказов на платформе, оно намного, намного более эффективно, чем решение какой-то другой задачи, потому что ну вот это вот именно то, что человек видит, с чем он взаимодействует. Плюсы ещё простых моделей заключаются в том, что мы можем делать очень быстрые итерации. У нас обычно за квартал проводится там, я не знаю, в районе десятка могут проводиться а тестов разных, именно что моделей, какие модели мы померили. То есть об тестов понятно меньше десяти, но именно проверок каких-то, какую модель, какую модель мы выкатываем и что за модель мы там тестируем, больше десяти моделей точно каждый квартал, а то и там 20, условно. Вот. И вот эти задачи поиска рекомендаций на самом деле, они, они имеют огромное количество нюансов под собой и много очень всяких методов и подходов, которые мы ещё не пробовали. И чем больше ты начинаешь вот с этим вот работать, тем больше понимаешь, что это ну такой бесконечный research, где можно много чего пробовать и по-прежнему это будет давать какой-то буст дальше и дальше на твои метрики. То есть тут я не вижу вообще какого-то конца сейчас в экспериментах и в том, что ещё можно сделать. В принципе, если у нас были бы ресурсы, мы могли бы там, не знаю, на 2-3 года вперёд расписать задачи и просто сидеть только эти задачи и делать, если бы к нам ещё не прилетали бы какие-то дополнительные задачи сбоку, сбоку откуда-то. Вот. Собственно, это вот третий кейс про который я сегодня рассказал, сеч рекомендации.

Давайте теперь попробуем как-то вынести какой-то урок из этого, подвести какие-то промежуточные выводы. А что, что мне кажется, когда имеет смысл использовать LLM, когда не имеет смысла использовать LLM. Объективно LLM лучше всего справляется и это лучшая модель, когда речь идёт про генерацию текста, когда мы хотим убрать полностью какой-то ручной труд или сделать его более эффективным. То есть, как в задачах с переписывания тайтлов, в принципе, могли бы посадить трёх человек, дать им задачу переписывать тайтлы, но они бы это делали там несколько тысяч лет, и понятно, это не очень эффективно. С этим справляется намного быстрее. Также хороша, когда у нас неструктурированный вход и выход у модели, и в целом как бы задача менее строго сформулирована, чем скажем, какая-то задача просто классика. Осторожностью и не использовать это, когда речь идёт про какие-то сервисы с высокой нагрузкой, когда нужно прям держать высокий RPS с маленьким latency. Здесь LLM пока что не не на том уровне находится развитие в плане компактности моделей и железа под эти модели. То есть мы не можем быстро обрабатывать огромный поток информации через latency. Также, ну, как я сказал, не стоит, наверное, сразу использовать там, где у нас понятный очень вход и выход, структурированный, то есть какие-нибудь табличные данные. И прежде чем слепо начать применять LLM, стоит провести какой-то research. Есть ли какие-то лучше, более простые модели в домене, с которым вы работаете, не LLM, потому что часто такие модели, вот на задачах e-commerce, я знаю, что наверно в большинстве задач такие модели есть, они более простые, они легче, и просто такие пайплайны легче поддерживать, чем делать какую-то LLM-историю. Вот. Итого, промежуточный вывод с моей точки зрения - это полезные очень лови, но во многих задачах это не первостепенное, не самое эффективное решение, и нужно быть особенно бдительными и внимательными сейчас при выборе модели, не поддаваться какой-то вот LLM, LLM хайпу. Давайте всё делать через LLM, нет, это не то, не тот путь, который облегчит вам жизнь. Больше всего мне кажется, что ну наш опыт в e-commerce, по крайней мере, это показывают. Вот. Ну и переходя к третьему, заключительному отрезку презентации, мы же тут всё-таки не какие-то это самое, диты. М, на мой взгляд, это очень крутая и многообещающая тема, и я хочу рассказать про несколько ещё проектов, которые находятся в разной степени разработки в AliExpress, которыми мы сейчас пытаемся работать и жить, и где нам кажется, может быть перспективной, и где вот именно другие модели не подходят и не смогут справиться с задачей также эффективно. Первое, самое очевидное, на самом деле, все сейчас везде повсюду и у всех. Мы тоже хотим сделать своего чатбота. Цель основная - это увеличить скорость и эффективность кастомер саппорта. Речь не идёт о том, чтобы убрать человека полностью из всего этого пайплайна. Действительно, какое-то экспертное понимание, умение разобраться, ответить на вопрос, большую часть вопросов, аля, где мой заказ? Так, у меня тут что-то сломалось. Ну ладно, большую часть каких-то вопросов, чтобы решал бот. Вот здесь подходит, потому что это, потому что нам нужен читаемый, человек читаемый аутпут. У нас нагрузка на нашу модель не очень большая, всё-таки не заходит по несколько миллионов человек, они пишут в службу поддержки AliExpress, если у нас, не знаю, не лёг сайт и всё нормально. Вот. И вообще, что мы, как мы дальше хотим это развивать? Мы хотели бы здесь использовать RAG-подход, то есть уметь генерировать какие-то ответы, от ответы для пользователей от чатбота, используя данные, которые чатбот будет знать из наших баз данных про историю пользователя, про то, какие он товары покупал. То есть мы хотим, чтобы можно было пользователю написать: "Где мои кроссовки?" И ой, пользователю боту написать, и бот поймёт, что вот твои кроссовки, ты заказывал кроссовки только там в позапрошлом заказе, значит, это речь идёт именно про этот заказ. Нормально, там 185, пойти выяснить по нашим данным, по нашим базам, по ручкам, спросить, где этот заказ, что с ним, и сгенерировать какой-то человек читаемый ответ. Так как такая архитектура, она подразумевает хождение и обработку зачастую наших данных конфиденциальных достаточно, то есть история заказов пользователей, что там человек лайкает, кликает, мы хотели бы это поднимать себя внутри, в третьи руки, чтобы не делиться вот такими вот данными.

Вот следующая задача, которая кажется важной и прикольной, интересной, это улучшение контента. Основная здесь основная здесь мысль в том, что помимо тайтлов, например, которые мы уже успешно умеем генерировать с помощью, например, другие какие-то атрибуты из сырого, из сырого контента, мы бы хотели уметь извлекать там размер оперативной памяти для телефонов, там диагональ экрана, является ли, не знаю, что угодно, короче. Является ли это пальто водонепроницаемым или не является? Зачем нам это нужно? Это нужно для того, чтобы эти данные потом класть в поисковые фильтры, использовать рекомендательные фичи. Также вот здесь вот тоже можно сказать, что это обогащение контента. Слева нарисована картинка того, как мы сейчас себе видим теги. Это фича, у нас в тестировании находится. Что это значит? Это значит, что мы анализируем все отзывы на товар и пытаемся в этих отзывах найти какие-то общие темы, про что пишут пользователи. Как, например, вот здесь в примере, пользователи там могут жаловаться или наоборот хвалить время автом ра. Мы таким образом можем человеку просто сделать какое-то саммари из всех отзывов и сократить место, которое занимает сама страница отзывов до минимума, чтобы человек видел саммари, он мог, если ему интересно, пройти и поискать вот те характеристики, которые его наиболее интересуют. При этом, так как у нас отзывы будут занимать мало места, натт больше места, которые, которые в общем-то и приносят львиную долю нам продаж и конверсий. Вот. Это штука, которая у нас сейчас находится в тестировании. В принципе, такой аналог какой-то есть в Яндекс Маркете из русских маркетплейсов. Я других аналогов в России не знаю. У Amazon это фича развитая. Если вы зайдёте, вы можете тоже много такого там увидеть. Вот. Мы это тоже сейчас делаем.

Что дальше? Дальше немного более такие внутренние истории, которые ээ не просто так показать наружу, и пользователь увидит: "О, у нас теги появились". Воду. Первая штука - это автоматизация разметки. Мы можем на самом деле использовать LLMки для того, чтобы увеличивать ээ на порядок обучающие данные для других наших ML-задач, для других наших ML-моделей. К примеру, здесь нарисована пара: вот чехол и запрос какой чехол для для iPhone. Мы просим обычно наших разметчиков любимых поставить метки на такие пары: является ли это релевантно, слабо релевантно или нерелевантно. Вот в этом примере, например, скорее всего, правильно поставить метку, потому что это какой-то чехол, тот, который нас интересует, не тот, который пользователь. Зачем нам нужна такая разметка? Мы этой разметкой на самом деле очень активно пользуемся, когда обучаем модели поиска. Поиску важно знать про релевантность товаров, и мы нигде по сути напрямую, кроме как из такой разметки, такую инфу достать не можем. Вот. Потому что покупки - это не про то, что товар релевантен. Может, человек просто увидел, не знаю, телефон за 100 руб., он не мог его не купить по какому-то просто рандомному запросу. Вот. И да, значит, таким образом мы можем с помощью каким-то образом дособрать, увеличить наш датасет для другой задачи. Общий па предполагается здесь таким, что мы формулируем задачу разметки, получая небольшой какой-то сэмпл от людей, там порядка 1000 пар или каких-то других сущностей, что нам надо разметить. В LLM, LLM из этого учится и учится, по сути, работать как человеческий разметчик. У неё будет безусловно качество ниже, но в каких-то задачах нам сильно не хватает данных, разметка дорогая, и учить людей тоже это не быстро. Поэтому, если мы можем заливать просто с чуть меньшим качеством от одного, с тысяча от 1000 примеров обучающей выборки до там 100.000 примеров обучающей выборки, это было бы нам просто идеально. И дальше мы можем на этих данных уже обучить какую-то более легковесную модель, какую-нибудь другую языковую модель типа BERT или что-то что-то попроще, может быть, вообще бустинг какой-то, который будет эту задачу решать для нас в real-time. Вот. То есть это такая как бы универсальный способ, как можно поска ваши обучающие данные с помощью LLM, потеряв немного в качестве, но значительно, значительно расти в объём. Мы с этим сейчас тоже играемся и думаем, что там есть какой-то профит для нас для наших моделей. Вот. Ну и напоследок хочется рассказать про историю с оптимизацией, с облегчением вообще работы наших дорогих разработчиков. То есть нас слева приведена картинка, как вы можете там использовать какое-нибудь Copilot для того, чтобы кодить. Наверняка многие про это слышали про эту технологию, но насколько мне известно, сейчас она не супер там, по крайней мере, если смотреть на наш, на наш AliExpress, не то, чтобы каждый второй человек, каждый второй разработчик этим пользуется. И хочется это немножко скалировать. Написать код, помимо просто задачи того, что давайте посадим какого-нибудь ассистента, который будет помогать разработчику. Здесь также с помощью LLM в эту же тему может быть организация какой-то RAG-системы по кодовой базе, по документации. Это тоже очень важно, чтобы человек мог находить среди десятков тысяч там документов и сотен тысяч строчек кода то, что ему нужно, какие-то намеки их куда-то себе выдергивать или находить правильную информацию. Вот. Что я тут хочу два момента каких отметить, которые мне кажется важными. Во-первых, вот эта тула, она наиболее полезна будет именно для сеньоров, потому что модель всё равно ошибается, и слепо верить ей как бы нельзя. Поэтому если единственное, что будет, то, что будет модель ему выдавать, это, конечно, будет фиаско, потому что рано или поздно будут допущены ошибки, и человек уже не разберётся, не поймёт, откуда это у него и как так получилось. Поэтому здесь именно имеется в виду, что такой тулой наиболее эффективно могут пользоваться более, более опытные разработчики. Вот. Ну и исходя из того, что я сказал, в принципе, очевидно, что такие инструменты, они не могут, ну, в данной там ближайшей перспективе заменить точно никаких разработчиков, аналитиков и ML-инженеров, потому что технология она не идеальная, она не будет идеальная, скорее всего, ещё долгое очень время, и чтобы ей, ну, извлекать плоды из неё и эффективно пользоваться, нужны знания, нужно понимание высокоуровневое, что происходит, и низкоуровневое понимание деталей вашего кода. Поэтому я бы здесь не пугался и не ждал, что Колот завтра уволит всех разработчиков и будет там ChatGPT всё за вас. Нет, мне кажется, это малореалистичный сценарий на самом деле. У меня презентация подошла к концу. Я хочу поблагодарить всех за внимание, и я готов поотрывать.

Отличный рассказ, очень любопытно послушать было. Да, очень много прислали вопросов. Перед тем, как люди записывались на вебинар, в общем-то, можно их разбить на три категории: это вопросы, связанные с применением инструментов искусственного интеллекта, там, эффективный инструмент, интересные кейсы, новые модели, подходы. Часть на этих вопросов ты ответил. Я сейчас, может, какие-то ещё парочку задам вот из того списка, что нам ребята прислали. Много вопросов было, много штук. Да, давай, прежде чем к этим сложным вопросам переходить, чуть-чуть паузу возьмём, я лёгкие вопросы позадаю, а потом вернёмся к применению. Давай, давай, давай. Вот чуть-чуть просто по сторонние темы поговорим, а потом вернёмся к [музыка] сложному. Вообще, выучил искусственный интеллект вообще? Ну, где так получается? В принципе, да. Я учился на физтехе с первого курса, учился. У меня кафедра была интеллектуальный анализ данных, факультет М, это совместно с Яндексом они делают. Нет, это было не совместно с Яндексом, это вот кафедра, кафедра Воронцова, Стрижова. Вот, вот, вот эти ребята, если кто-то знает. Угу. Вот. Дальше я с пятого курса начал учиться параллельно ещё в Сколтехе по про программе двойных дипломов. Вот. Соответственно, в Сколтехе тоже мне достаточно много я знаний приобрёл, получил. И параллельно с работой в учёбой в Сколтехе, на втором курсе уже, я как раз вот вышел на работу в Ozon. И, собственно, ну, всю свою трудовую деятельность я занимался тем, что применял ML. Поэтому это долго уже, короче, в этом варюсь. М. Понятно. А в Сколтехе ты в какой группе был? Там Бурнаев, Оселедец, какие-то? Ну, в Сколтехе там у нас было, когда я учился, я не знаю точно, как сейчас, потому что раньше была вот группа, поток, направление анализа данных, направление материалов, энергии, вот какие-то такие потоки. Ягу был в потоке анализа данных, и у нас там были да, лекции Бурнаева, лекции Оселедец, в общем, все вот эти вот знаменитые классические лекции я слушал. Было очень полезно, интересно. Ну и Ozon, конечно, Ozon там сильнейшая команда была по Data Science, ну и сейчас, наверное, там сильная довольно, конечно, не как в AliExpress. Ozon все подрассосались, насколько я понял, там в разные стороны прошли. Вот. Ну, ну, кто-то много ещё народу работает там, вообще сильно, сильно выросло. В плане, мне кажется, что ну в Ozon, если просто по людям посмотреть, то DS отдел, люди, которые занимаются ML, сильно больше, чем в Ali. При этом, как бы, задачи мы решаем очень похожие. Не может вызвать у меня некоторое гордости, что мы закрываем такие важные бизнес-задачи относительно небольшим числом людей. Как думаешь, никогда не считал, сколько нужно моделей знать, моделей, алгоритмов, чтобы вот прям комфортно себя чувствовать, любые решать задачи? Ну, ээ, должна быть база какая-то, то есть фундаментальная. Мне кажется, человек, если не знает классический ML, то ему будет в любом случае сложно. Даже если ты там знаешь очень хорошо нейронки или знаешь очень хорошо LLM ээ, и или то, иногда всё-таки ну нужна какая-то база, типа, чтобы увидеть более простые, более эффективные, качественные решения. То есть я не могу здесь число, число моделей точно назвать. Вот. Ну, на мой взгляд, в современном ML, да, никуда. Тебе повезло, ты умный, попал на физтех. Вот. А если человек не попал на физтех, например, учился на скромно на мехмате, или ещё где-то, я шучу. Ну, если в общем, вот человек решил сейчас пойти в мир ML из какой-то смежной области, какие бы ты дал рекомендации по изучению? С чего бы следовало бы начать? Как, или если он уже в нём есть, но хочет в нём дальше развиться? Что есть, какие мысли по этому? Ну, мне кажется, всегда есть вариант пойти в какую-то школу, ашама и такого рода. То есть это точно даёт какой-то базы, которой не хватает, возможно, если ты не учился изначально в институте или что-то обучение. Вот. Это точно даёт базу, точно хорошо. Ну, если не хватает времени, силы, вот этого всего, конечно, можно подучить какие-то онлайн-курсы, посмотреть, поделать педпроекты. Вот. Но мне кажется, самый такой надёжный способ, хоть он и требует большого количества сил и усилия - это пойти в какое-то такое серьёзное, плюс-минус место и подучить, получить хорошие изначальные знания от каких-то людей, которые являются прямо реально экспертами в ML, и потом уже от этой базы развиваться в том направлении, в котором интересно. То есть можно поднимать там System Design, читать какие-нибудь блоги компаний, как они вот свои решения, смотреть какие-нибудь конференции, посещать, делать проекты. То есть дальше, не знаю, вариант спектр, возможно, о широк. Хорошо. Слушай, давай тогда вернёмся уже конкретно к вопросам. Вот смотри, там был вопрос. Ты много раз упоминал про RAG, и человек спрашивает, задаёт конкретный вопрос: как подход RAG может улучшить качество рекомендации, поиск, обработку запросов на платформах? Какие задачи, где он ещё остаётся экспериментальным? Какие наиболее странные ошибки в применении искусственного интеллекта в электронной коммерции наблюдали? Какие уроки извлекли из неудачных кейсов? Даже вдогонку, как интегрировать решения в legacy-системы без остановки бизнеса? Вау, нужна вторая лекция. Я не знаю, много вопросов. Как я говорил, мне видится LLM одним из важных применений, которые может быть, это генерация каких-то обучающих данных для других, для других алгоритмов. И не только RAG, в целом LLM. Здесь вполне может играть решающую роль. К примеру, я вот когда готовился к му, во в М, я часто натыкаюсь на какие-то статьи, где люди там говорят типа: "Давайте применим для ранжирования". Окей, давайте применим. Пишут статью, значит, берём какой-нибудь датасет, начинаем ранжировать с помощью LLM, получаем какие-то там сверхвысокие метрики, всё у нас классно, обогнали все, про никуда не идёт. То есть вот такую вот историю вполне можно было бы использовать для того, чтобы дообучить и подтянуть те модели, которые как бы не справляются так же хорошо, как LLM, с ну, вот ручной какой-то историей типа "переставь товарки", но они очень хорошо скалируются, и их можно было бы таким образом использовать и жить для улучшения моделей основными для задачи. Так, а что ещё там было? Ну, про ошибки. Ты уже сказал. Какие уроки извлекли из неудачных? Да, я могу сказать, что на самом деле неудачные проекты бывают чаще всего, по моему опыту, неудачный проект, когда ладно, нередко в 50% случаев неудачный проект получается, когда технология ещё не там. Technology. То есть, условно, у нас периодически большой периодичностью всплывает проект, когда я работал в Ozon, и когда я сейчас работаю в AliExpress, это проект какого-то улучшения картинок товаров. Да, когда приходит, приходит заказчик и говорит: "Вот у нас есть ээ 100 млн картинок товаров, видите, тут всякие налепленные стикеры, там, какие-нибудь текст по диагонали, ээ, всё это ещё может быть на каком-то непонятном фоне, размыто. Сделайте из этого типа красивую картинку, подложите красивый фон, аккуратный, вырежьте товар, уберите все надписи". То есть, звучит это задача как такая достаточно, наверное, если бы мы так могли сделать, было бы хорошо, и мы, может, как в тайтлах показали бы какой-то профит. Но просто при том, что у нас вот есть такие задачи, как сейчас я говорил про поиск, рекомендации, там, модерации, те же самые тайтлы, мы потратим просто колоссальное время и скорее всего ни к чему не придём. Вот с такой вот задачей большого research с картинками. Вот. Неудачные проекты, а могут неудачные, когда, например, что-то делаем, но потом выясняется, что по какой-то причине продукт там бизнесу не нужен, или он может быть не настолько актуален, или он может быть не может пошану так сильно бизнес-метрики, как мы бы того хотели. И ну, такой проект тоже можно сказать, неудачный. Ну, в моём плане, то есть, если мы решили хорошо задачу, но мы можем с этого, то для нас это не является успехом. Слушай, ещё такой вопрос. Мне много кто его задавал в списке, вскользь я тоже его задавал, может, чуть-чуть ещё раз поговорим. Спрашивают, как безопасно с конфиденциальной точки зрения внедрить LLM в контур компании? Да, да, я готов ответить на этот вопрос. Да, скажи, пожалуйста, если можно, сколько для этого мощностей нужно? Там, условно, 10.000 видеокарт? Ну, это хорошо, там, вот. Но какие ещё есть? Да, да. Ну, смотри, у нас как сейчас, как сейчас у нас строится работа с LLM. Во-первых, мы не отправляем никакие конфиденциальные данные в третьи руки. То есть, если нам нужно какие-то конфиденциальные данные прогнать через LLM, мы просто поднимаем LLM у себя и прогоняем её у себя. Что значит поднимаем? Это не обязательно нужно, чтобы это была какая-то история в виде там машины сервисом, которая в real-time там, вот ты закидываешь в неё запрос, она там думает, и через 2 секунды отвечает. Это может быть просто обычный какой-то data pipeline, который работает там через Airflow, раз в день он там поднимает эту модель, может быть, какую-нибудь дистиллированную, на нескольких пушках прогоняю через неё все данные и получается результат. И промт мы тоже можем там заранее какое-то сгенерить. То есть здесь вообще никакого риска. Погоди, несколько подо, несколько пушек? А сколько? Несколько? 2-3, 5? Ну, это зависит от модели, от того, сколько есть. То есть мы используем иногда там, условно, по 10 каких-нибудь пушек на, чтобы поднять модель. Вот. Но там, это речь не идёт про сотни тысяч. Особенно сейчас, с учётом вот быстрых, быстрых прорывов, которые там вот китайцы с Deepcom показывают и так далее. То есть в целом, какую-то дистиллированную модель можно поднять. Я не скажу, что на домашнем компьютере вы прямо поднимете, и всё будет работать идеально, чики-пуки, но на тех каких-то прок-машинах, которые есть в больших компаниях, пу, там, где есть, не знаю, десяток GPU современных, более-менее, это вполне поднимается и работает. Ясно. Я тогда пользуюсь. Вот. Либо да, да, я хотел ещё добавить, что у нас в целом мы используем и разные модели, которые поднимаются в облаке, где-то ещё кем-то, потому что, ну, иногда просто не хочется вот эти вот наши драгоценные ресурсы занимать вот какими-то моделями, которые будут ждать latency отклика от пользователя и ничего не делать, кроме этого. Поэтому мы мы подняли у себя там в своём мессенджере корпоративном ботика, которому можно там как-то пописать и пообщаться с анкой, но понятно, что там есть дисклеймер, что мы туда никакой корпоратив или лично информацию не засовываем, не отправляем. Все эти запросы у нас гиру, можем легко там присесть какие-то не очень, не очень корректные истории использования. И для вот таких вот эхо вещей мы вполне готовы и ходим в какие-нибудь третье, третье LLMки, не стесняемся. Наш, что как это можно увидеть вживую? У нас закончился курс по обучению LLM, первая итерация, там сильно команда проводила обучение, и там через неделю будут ребята защищать проектные работы. Одна проектная работа - это что-то вот надо с LLMкой сделать, развернуть, что-то там тюнить, что-то настроить, с оптимизировать, какие-то задачи конкретно решить. Вот. И в общем-то, мы думаем защиту проектов сделать открытой. Так, то есть есть желающие, следите за анонсами, приходите, может, увидите вживую, как это может в таких пет-проектах работать. Это, конечно, не продакшн, но вот т проект, такое начало может быть таким началом знакомства. Следите за анонсами. Слушай, ещё спрашивают много вопросов по по, ну, собственно, по LLM. Вот один из них мне очень понравился, такой насущный. А что важнее? Навык программирования и знания тонкости и подходов, или же навык пользования и настройки LLM-моделей и решений с пониманием программирования? Что важно уметь настраивать? Я бы сказал, программирование. Программирование важно, потому что в любом случае будущее - это не не в том, что ты будешь совсем на укот что-то делать. Ну, то есть, да, будущее, наверное, там через какое-то время люди, даже которые хорошо будут уметь программировать, будут программировать меньше. Но для того, чтобы все эти пайплайны завести, недостаточно. Ну, если говорить именно про не про research, вот есть в больших компаниях позиции там, App Sci, там, research, что-нибудь типа того. То есть это люди, которые не катят там в про, они именно обучают модели, читают научные, думают, там и так далее. Вот. Это для таких людей, может быть, иногда даже кодинг не так важен, важно и математическая составляющая. Но это, мне кажется, единицы. Основная наша, основные наши коллеги - это инженеры, которые занимаются не только LLM, начиная от сбора данных, переходя к обучению, там, метрики и выкатывания в продакшн. И здесь я бы сказал, что просто понимание типа: "А вот где там LLM можно применить?" - это, конечно, полезный навык, но далеко не достаточный. Их, ну, надо ещё уметь, собственно, кодить и какую-то практическую, вот практические навыки получить. Угу. Осталось совсем чуть-чуть времени. Ээ, ещё парочку вопросов задам тебе про перспективы, про будущее. Люди спрашивают, интересуются. Ээ, вообще, какие перспективы для применения искусственного интеллекта ээ в области e-commerce в ближайшие 5 лет? Какие ты видишь перспективы? Что там будет? Агенты какие-то? А что там? Да, я понял. Я слышал какие-то версии, что у людей будут персональные агенты, которые будут за них совершать покупки, и в общем-то, вы будете уже настраивать свои системы. Я так понимаю, если в ээ теория, не для людей, а для агентов. Слушай, это возможно. То есть 5 лет назад тоже вряд ли кто-то мог предположить, что у нас сейчас прямо LLMки начнут всё всех вся рвать на задачах, на которых они сейчас хорошо работают. Вот. Но мне кажется, именно что с точки зрения e-commerce, наверное, ну, в каком-то плане, конечно, люди откажутся от там бытовых каких-то, не знаю, бытового взаимодействия там с сайтами, с приложениями. Это может быть. Но я не думаю, что это произойдёт там на 100%, и мы просто будем делать продукт для машин, которые затем будут какой-то тее предлагать пользователю. О, будет сам как-то выбирать. В случае, люди, которые занимаются e-commerce, они, ну, у них есть, есть экспертиза, есть понимание, в каком виде людям удобнее показывать ассортимент, как, как человеку там читаемое, нечитаемое, как он может выбирать между товарами. И мне кажется, что ну от этого это будет сложно так сходу переплюнуть. Поэтому я не очень верю, что через 5 лет будут полностью какие-то автономные штуки, типа: "Нам не нужен поиск на Ali, потому что туда ходят какие-то боты, LLM сами всё ищут за людей, и им пофигу, что наш поиск работает не очень чётко, они и так всё найдут". Может быть, но я в эту в эту картину не очень верю. Я скорее верю в то, что с помощью LLM, как раз мы сможем намного быстрее итерироваться и двигаться в плане разработки вот. И все качество тех продуктов, с которыми человек взаимодействует, оно будет намного выше благодаря тому, что эффективность разработчиков будет больше, и они будут лучше продукты выпускать, и с которыми людям будет приятнее взаимодействовать, нежели что всё взаимодействие с внешним миром у человека будет через просто один чатбот. Угу. Посмотрим. Не знаю. Слушай, ну последний вопрос. Спрашивают, какие, я немножко перефразируя, какие стартапы вообще могут стрельнуть в e-commerce? Что-то вот такое, что-то вот, чтобы такое сделать, что, например, Ali будет интересно, он скажет: "Давайте куплю". Что вот самому его тяжело сделать? Ну, вот мне кажется, что задача с контентом очень сложная, и нету хорошего решения прямо какого-то. Это не решённая задача. То есть каждый её решает в виде в силу своих каких-то возможностей и способностей. Вот. Но мне кажется, что от контента товаров и того, что выставляется на маркетплейсе, очень сильно всё зависит. И тут, конечно, сами маркетплейсы пытаются как-то оптимизировать. То есть мы со своей стороны улучшаем контент, мы там пытаемся продавцам предоставлять какой-то функционал, чтобы они лучше заводили карточки товаров. Но я здесь не вижу какой-то прямо, что-то невозможное. Что появится какой-нибудь стартап, куда ты загружаешь в сыром виде всё описание, он тебе выплёвывает там в нужном виде для разных маркетплейсов, как бы, что нужно загрузить, чтобы тебя был идеальный контент. Это вот одна из таких, которые, может быть, могли бы иметь ценность. Непонятно, как это прямо монетизировать. В смысле, понятно, но не очень ясно, насколько здесь много денег можно заработать. Но это проблема, которая пока не решена. Ну, я надеюсь, что кто-то из слушателей, если реализует эту идею, то поделится процентом с тобой за идею. Да, да, надеюсь, надеюсь так. Что ж, ждём. Хорошо. Я предлагаю завершать. Артём, спасибо тебе большое за прекрасный рассказ, прекрасный вебинар. Было супер интересно. Я надеюсь, также нашим слушателям за кадром тоже осталась Ксения Бокша, это коллега Артёма, тоже из AliExpress. Вот, она как я понимаю, вместе с Артёмом они работали над презентацией. Вот. И на вебинаре. Спасибо вам большое. Получилось. Спасибо, спасибо за внимание. Было интересно рассказывать и поотрывать.