0: Ещё раз всем привет. Меня зовут Эдуард Зарипов. Сегодня я вам расскажу про нашу рексис платформу. Зачем мы её делаем, какие цели преследуем? Я работаю в т. Банке уже более 3 лет разрабатывал разные системы. И сегодня расскажу про рексис платформу. Сначала немножко интерактива.

1: Вопрос в зал кто из вас работает в рекомендательных системах или в смежных отраслях? Давайте похлопаем.

2: Круто, как будто персонально мне похлопали. Другой вопрос кто из вас часто, кто хлопал, взаимодействует с бэкендом, общается с ним, делает какие-то интеграции и так далее.

3: Ну, поменьше, кстати, мои мельчик не похлопали. Ну, ну, ладно, похлопали. Ну, давайте тогда начнём, потому что доклад будет как раз про это. Какой у нас план начнём мы с того, что я расскажу, где автобанке у нас вообще живут рекомендации.

4: Далее расскажу про архитектуру нашей платформы, зачем мы её строили. Далее расскажу про пример заезда на нашу платформу и в конце подведём какое-то овервью, расскажу про наши планы, поэтому давайте начнём. Стартуем мы с

5: Рекомендации в т. И хочется отметить в 1 очередь то, что у нас есть множество направлений, где мы используем рекомендательные системы, это товарные направления, супермаркеты, шоппинг, отели это контентные, это реклама, поиск и на

6: Более интересно это cjm customer journey map, когда мы пытаемся предугадать сценарий пользователя в приложении и сократить этот сценарий до наиболее оптимального уже по всем этим направлениям, рексис внедрён в том или Ином виде и мы уже.

7: Имеем какие-то зелёные аб тесты, которые приносят буквально бизнес value нашему продукту.

8: Во сработало в курсах по презентациям часто говорят, что нужно показывать картинки, поэтому я покажу тоже немного картинок у нас в приложении можно открыть, например, шоппинг и супермаркеты. Кстати, картинки у меня не этот, не показываются. Жалко. Ну ладно.

9: И тут тоже не показывается. Но считайте, что тут была гифка, которая показывала красивые анимации. Че то я забыл про это сказать. Ну ладно, о, зато тут нет анимации, это рекламные баннера, они так выглядят в приложении. У нас есть реклама, как

10: Внутренних продуктов, так и внешних, например, справа от наших рекламодателей. Слева наши внутренние продукты. Но давайте чуть чуть шагнём назад и пройдём всю хронологию рекомендательных систем в нашем банке, чтобы понять, что мы вообще делаем. Мы сейчас

11: Поминутно расскажем, кто что разрабатывал. Начнём с года 19, а именно в 19 году мы жили только исключительно на бачевым рекомендациях. Что это такое. Давайте на примере расскажу. Тогда у нас была биджи си лента в

12: Пульсе это биджис, значит бизнес генерейт контент это значит то, что все посты в нашем приложении генерировались исключительно нашими редакторами и была простая задача. Нужно рекомендовать посты, которые заинтересуют пользователя.

13: Как это выглядело? Смотрим, у нас было мобильное приложение, у нас был бэкэнд пульса, и работало это так, что у нас была какая-то рекомендательная система. Пока это сделаем каким-то абстрактным прямоугольником. Бэкэнд пульса ходил к нам.

14: Audition пользователя, а мы возвращали ему список релевантных постов. Давайте углубимся что вообще за рекомендательная система тогда была? Работала она так-то что у нас были какие-то исторические данные эти исторические данные мы и телепрое вычитывали генери

15: Посты наиболее релевантные рассчитывали, фичи делали инференс в какой-то модели и складывали результат инференса в сторедж, и важно сказать то, что в этом сторедже хранился список всех хранился.

16: Список постов, релевантных для каждого пользователя в банке. И далее мы этот сторож просто отдавали бэкенду пульса, пульс ходил в сторож сам и получал наиболее релевантные посты для пользователя. Когда мы делали такие бачевым, мы понимали их трейдов.

17: То, что построить такую систему достаточно просто потому что это быстрая и Дешёвая разработка и backend тоже достаточно простой, но есть ряд недостатков. 1 это то, что мы считаем рекомендации для всех пользователей, но далеко не все пользователи зайдут в приложении.

18: И посмотрят их. Получается, часть расчётов оказывается бесполезна, а на десятках миллионах пользователей, как в нашем случае, это уже достаточно дорогая штука. Плюс мы не адаптируемся к трендам в системе. Например, если происходит какое-то событие на бирже и выходит интересный пост про это

19: Его начинают активно лайкать. Мы это не видим и не можем рекомендовать этот пост другим пользователям, чтобы ещё сильнее разогнать Шумиху. И 3, мы не можем учитывать контекст пользователя, где он находится, сколько у него время. Например, если пользователь переехал, приехал из Москвы в Питер на день, а мы

20: Все ещё рекомендуем ему, например, отели московские. Ну, наверное, это что-то не то, но мы с этим жили и жили нормально до года 25, потому что в 25 году у нас запустилось ряд интересных направлений. Запустилась юджиси лента в пульсе юзер генерейтед.

21: Content, когда уже сами пользователи начали писать посты, запустили супермаркеты, шоппинг, отели и рекламная платформа. И тут уже на самом деле даже не стоял вопрос, переходить ли в онлайн, потому что все эти направления критично зависят от онлайн.

22: Рекомендаций это стандарт индустрии уже использовать онлайн рейки в таких системах. Почему простой пример. Допустим, у нас онлайн магазин. Мы строим такую же бачеву систему, как на прошлых слайдах. В начале дня мы пересчитали, рекомендации сохранили, хранили

23: Наш пользователь встал в 8 утра, молодец, открыл приложение и увидел рекомендацию телефона и он счастливый, купил телефон в 8 утра и ушёл на работу. Приходит с работы. Он в 15:00, тоже счастливый человек.

24: И все ещё видит рекомендации телефона, когда заходит в приложение. Ну, наверное, он его не купит 2 раз, и у него будет вопрос, а зачем ему 2 телефон? И мы, наверное, тоже на него не ответим. Вот. И только в конце дня мы узнаем, что он купил телефон при пересчёте, и что-нибудь порекомендуем к телефону.

25: Но мы уже потеряем момент, когда пользователь мог что-то купить к телефону в 15:00. Ну и вот, значит, нам нужны онлайн рекомендации, онлайн система. Что это такое?

26: Выглядит оно примерно так. У нас есть такая же такой же фронтент наш, наше мобильное приложение есть продуктовый бэкэнд, и у нас появляется бэкэнд рекомендаций, что делает backend рекомендаций бэкэнд, рекомендаций, ходит в сторедж кандидатов в сторедж фичей.

27: Собирает их и идёт в инференс, в реальном времени, получает какой-то скор, стороч кандидатов и фичей, заполняется либо на исторических данных, либо на стриме событий. И за счёт этого наша система уже умеет учитывать контекст пользователя, потому что мы можем реагировать на стриме.

28: В реальном времени можем собирать исторические данные и, в общем, крутить как хотим, но тут тоже есть. Но такие системы сложны в разработке, ну, сложнее, чем бачевым. Что на батчевых мы могли говорить

29: Что это занимает? Недели разработки, а на онлайн рекомендациях уже это месяцы. Почему? Потому что теперь нам нужно согласовывать контракты с бэкендом. Нам нужно продумывать хранилища данных для фичей. Для кандидатов. Нужно выдерживать необходимые рпс. Латенси нужно поддерживать аб тест.

30: Короче, много всего ещё настраивать наблюдаемость всего этого, чтобы это работало и не падало. Также и трудозатратна доставка новых новых нового функционала. Почему? Потому что нам опять же нужно идти в backend, обновлять бэкэнд, если мы хотим добавить новые фичи, добавить новый вид.

31: Кандидаты генерации или, например, построить новый пайплайн все это достаточно трудно, но мы это понимали и с полной уверенностью пошли в это и начали разрабатывать системы для онлайн рекомендаций.

32: И что мы заметили? Например, мы строили системы одновременно для пульса и для шоппинга. И что мы видим? Так выглядит пайплайн для этих систем? Ну, упрощённый. Давайте по каждому пункту пройдёмся, например, начнём с кандидата генерации, что для пульса какая может

33: Простая эвристика. Выбрать топ 100 популярных постов для шоппинга. Например, выбрать топ 100 популярных товаров. Видимо, какие-то сходства. Отлично. Получение фичей. Какие фичи могут быть для пульса. Например, количество просмотров постов от 1 автора. А для

34: Шопинга. Количество покупок 1 товара для инференса вообще в целом примерно одинаковое. Это нужно упорядочить фичи и отправить их в модель. И постпроцессинг тоже какой-то бизнес процесс, который может быть очень схож между собой и разрабатывая такие системы.

35: Параллельно и независимо можно выделить 3 недостатка. 1 это то, что, во первых, у нас высокий тайм ту маркет, потому что у нас нет предсказуемости в разработке. Каждая команда разрабатывает по своему, у каждой команды свои стандарты и непонятно, сколько будет занимать сама разработка. Далее

36: Мы постоянно повторяем решение, потому что, например, команда пульса реализует свою кандидата, генерацию, потом шопингу нужна своя кандидато, генерация, и каждый делает своё. Это не круто. И важный пункт. Ещё то, что у нас замедляется развитие самого Эмеля, потому что

37: Ml. Инженерам приходится думать теперь о том, как их решение будет эксплуатироваться в рантайме, что отнимает их время на разработку новых идей, которые могли бы улучшить наше приложение. Поэтому, понимая все эти проблемы.

38: После 25 года мы пошли в платформу, что для нас платформа. Давайте поговорим о ценностях наших платформы. Мы как платформа хотим в себе аккумулировать наиболее удачные технические решения. Для нас идеальный вариант, когда эмэль инженер,

39: Не думает о том, как его, какое какая-то идея будет решена, реализована, эксплуатироваться. Он думает только о том, а сработает ли его идея. И мы, как платформа, хотим давать возможность внедрять эти эмэль технологии с минимальными усилиями. Поэтому

40: Чтобы понять, как мы её делали, давайте перейдём к архитектуре платформы, как она выглядит. Выглядит она примерно так, чтобы в ней получше разобраться. Давайте начнём с нашего ядра. Это фреймворк для пайплайнов.

41: Мы назвали его маэстро с отсылкой к великим. И, во первых, давайте ответим на вопрос, а почему вообще фреймворк в реисе обычно рассказывают то, что есть там 4 вида архитектур, это пайплайн сэнтен моделью, когда

42: Модель сама знает про кандидатов. Это одноуровневый пайплайн, когда кандидаты приходят снаружи. Это двухуровневый пайплайн, когда мы делаем кандидата генерацию на своей стороне и трехуровневый, когда к предыдущему добавляем какой-то бизнесовый постпроцессинг или препроцессинг. Как решить?

43: Эту задачу. То есть какая задача то стоит? Задача стоит такая, чтобы можно было строить все эти архитектуры универсально для всех доменов. То есть можно было переиспользовать какое-то 1 решение и какие были варианты. Было 3 варианта. 1 вариант это делать кодген. Что это значит? Это значит

44: То, что мы пишем какой-то конфиг к нам или нам приносят какой-то конфиг и по конфигу мы генерируем весь пайплайн, который работает, запускается в проде. И вообще с ним все хорошо. Плюс в том-то, что у нас минимальная разработка бэкенда минус в том, что, ну это достаточно сложно сделать.

45: И мы теряем немного гибкости в этом, потому что это все-таки конфиг. И, ну, короче, теряем гибкости. 2 вариант это сделать универсальный пайплайн это 2 крайность, когда мы хотим сделать 1, 1 сервис на все

46: Плюс в том-то, что мы быстро будем запускать новые решения. А минус в том-то, что у нас вообще пропадает гибкость. Если нам нужны какие-то домено специфичные этапы или пайплайны, мы начинаем костылять. Ну и 3 вариант это фреймворк. Что для нас фреймворк

47: Фреймворк это инструмент, который говорит, как строить пайплайны и предоставляет все готовые кубики, из которых можно построить этот пайплайн. И чтобы получше понять, это есть такая картинка, то, что как фреймворк наш маэстро,

48: Предоставляет ряд готовых этапов. И, уже используя эти этапы, мы можем взять и построить этот готовый pipeline из Кубиков супер. Также фреймворк даёт из коробки наблюдаемость для

49: Каждого этапа даёт динамическую конфигурацию, каждый для каждого из этапов. И в итоге получается так-то, что вся система у нас управляется динамически через конфигурацию. То есть мы можем добавлять новый вид фичей, можем добавлять новые кандидата. Генерацию, можем добавлять новый инференс, запускать

50: Тесты, не меняя систему, а меняя только динамические конфиги. Ну и из коробки, получаем наблюдаемость удобную. То, что можно искать боттлнек в каком-либо из этапов в пайплайне, возвращаясь к архитектуре, чтобы реализовать каждый из этапов, нам нужны

51: Какие-то компоненты и снизу видны компоненты. Собственно давайте начнём для с кандидата генерации мы поддерживаем несколько видов кандидата генерации из коробки. 1 вид это самая простая Батчева или триггерная, когда кандидаты считаются

52: Заранее, как я уже говорил, для пульса, например, это топ 100 популярных товаров мы берём, считаем их на исторических данных и складываем в наше хранилище 2 вариант это онлайн кандидаты, генерация, когда мы считаем их уже в real time через векторный поиск.

53: И, например, можем обновлять эти векторы тоже в real time на топике событий, что по поводу компонента работы с фичами с фичами у нас также есть 2 варианта 1 достаточно простой это Кивель, хранилище фичей, мы для этого используем наше внутреннее решение в банке это

54: Который позволяет хранить фичи в ci велью. И 2 вариант это профиль. Про профиль мы поговорим чуть чуть попозже, подробней, но сейчас достаточно знать, что это наше платформенное решение для хранения фичей целиком в 1 блоге.

55: Для инференса, для инференса тут все просто для внешнего, для внешнего инференса мы используем нашу сервинг платформу, которая из коробки предоставляет тритон, а для внутреннего инференса предоставляем наш on annix или локальный катбуст или лайт гбм.

56: Идея в том, что для систем, которые очень зависимы от латенси, например, реклама, которой латтенси меньше 100 миллисекунд, мы можем использовать локальный инференс, который будет существенно ускорять нашу систему.

57: Так, опять овервью архитектуры мы рассмотрели с вами фреймворк, рассмотрели компоненту для генерации кандидатов, компоненту для работы с вичами. Давайте уже попробуем заехать на нашу платформу, чтобы получше понять, о чем мы вообще делаем.

58: Для примера возьмём товарную ленту в шоппинге. Наша задача показать ленту товаров, наиболее релевантных для пользователя. Когда он открывает шоппинг. Я вам гарантирую, что тут была анимация, которая показывала эту ленту, но считай,

59: Что она есть, как это выглядит? Начнём с верхнего уровня интеграции. У нас есть мобильное приложение, мобильное приложение ходит в backend шопинга бэкэнд шоппинга, входит в backend рекомендации по id пользователя, получает список id товаров и тут возникает

60: Вопрос, кто будет делать этот правый кубик, есть 3 варианта 1 вариант это будет делать эмэль инженер, плюс в том, что вся ответственность, вся ответственность за энту энн фичу будет у 1 человека, а минус в том, что вся ответственность будет на anna and у 1 человека.

61: Потому что это будет потребует каких-то компетенций в бэкенде и самое главное, отнимет время у мельчика на backend задачи. И 2 вариант это будет делать человек из платформы. Плюс в том, что это сделается достаточно быстро, потому что человек из платформы имеет достаточно

62: Экспертизу в этом минус в том, что таких разработчиков немного и скоро это станет ботлнеком при большом количестве доменов. Ну и 3 вариант это из домена, из продуктовой команды придёт разработчик и на нашей платформе построит нужный ему рексис.

63: Плюс в том, что это даст максимальный контроль продукту минус в том, что опять же не всегда есть ресурс на это мы как платформа вообще поддерживаем и то, и то, и то. Нам в целом не так важно, кто это будет делать. Но давайте для примера возьмём, что это будет делать инженер из платформы, чтобы

64: Лучше понять, что нужно, чтобы заехать на платформу давайте разобьём этот, эту задачу на этапы будет 4 этапа, и чтобы лучше понять, что платформа забирает на себя, я вот такую табличку построил, которая будет показывать, что, что, от кого tre.

65: 1 этапом это будет выбрать эмэль систем дизайн. Возвращаясь к той картинке, там с 4 видами архитектур для шопинга. Давайте скажем, что наш эмэль инженер, выбирает трехуровневую архитектуру с постпроцессингом. Он там долго думал, выбирал и

66: Выбрал вот это вот и на самом деле, чтобы выбрать вот это, ему не нужен был бэкэнд, потому что как платформа, мы предоставляем все нужные нфт. Мы знаем, сколько будет работать та или иная кандидата генерация. Мы знаем, сколько фичей мы сможем переварить и знаем сколько

67: Не знаю, будет работать тот постпроцессинг или иной, и поэтому эль, инженеру просто нужно из этих Кубиков примерно представить, что ему нужно. И поэтому это достаточно удобно. Далее мы, нам нужно собрать какие-то нефункциональные требования по нашей системе. А как мы вообще хотим, чтоб

68: Наша система работала. 1. Нам нужно сходить к продуктовой команде и узнать какую нагрузку мы хотим какую нагрузку они хотят на нас давать, сколько рпс и сколько они ожидают от нас в латенси. И 2, нам нужно сходить к ameli, получить этот эмэль ситим дизайн, узнать какие будут кандидаты.

69: Узнать, какие будут фичи и получаем такой список. Там у нас где-то 6 пунктов получилось нормально, да, вот. И для этого мы говорим то, что это будет делать backend инженер как человек, который обладает наибольшей экспертизой в этом и на самом деле это не так.

70: Такое долгое занятие, но требует, да, как я уже сказал, экспертизы, так давайте приступим уже к реализации. Мы выбрали наш эмэль систем дизайн. Мы поняли наше нфт, давайте реализовывать этап за этапом. 1 этап это кандидаты генерации, нам нужно было

71: Выбрать, что это за кандидаты генерация. Тут давайте ещё раз вспомним, что мы можем делать бочеву кандидата, генерацию, когда мы считаем кандидатов заранее и складываем в какое-то хранилище. У нас это канген стор, это обёртка вокруг кассандры, это может быть триггерная кандидат генера.

72: Когда мы также считаем кандидатов заранее, но можем реагировать на какие-то крутые события. Например, пользователь купил телефон, вспоминаем, да, и по этому событию мы можем пересчитать ему кандидатов заранее в моменте или

73: Например, онлайн координата генерации для шоппинга. Это могут быть айтуй рекомендации или использовать, например, наш персеус, про который сегодня был доклад.

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

75: Это по сути, набор кандидатов, сформированный по какому-то принципу. Это может быть коллаборативная коллекция, это может быть соцдемовской или, например, по персеус также и что нам нужно пролить эти коллекции и в конфиге для получения канди.

76: Кандидатов, написать этот список коллекций и написать максимальное количество кандидатов. Отлично.

77: Мы реализовали кандидата генерацию выглядит примерно так, что мы написали конфиг и реализовали проливку в канген стор по поводу получения фичей тут давайте немножко углубимся какие вообще бывают фичи? У нас их может быть 3 вида.

78: Для рексис это могут быть юзерские фичи, это могут быть айтемы фичи, и это может быть кросс фичи взаимодействия пользователя с айтемом. И тут я покажу ценность платформы в том-то, что давайте представим, что мы какой-то кастомный бэкэнд, который разрабатывает такую систему и что мы

79: 1, попробуем сделать, это положить все фичи в Кивель. Хранилище супер. Мы кладём и получаем такую, такую, такой статус. То, что юзерские айтемы фичи хранятся нормально. Мы можем их хорошо кэшировать. Это работает быстро. А вот cross фичи с ними

80: Уже проблема, потому что если их становится много, у нас получается комбинаторный взрыв ключей, потому что, во первых, у нас высокая разреженность, из за которой множество запросов в базу оказываются бесполезными, и наша база просто перегружается. Поэтому тут

81: Как платформа, мы сразу говорим, что мы храним кросс фичи в профиле, а другие фичи можем хранить как в профиле, так и сверали. Это уже зависит от домена и от количества этих фичей. И давайте уже поговорим, че такое профиль вообще.

82: Профиль это единый набор фичей в прото формате тут простой пример вот у нас есть user profile это прото структура у нас есть user profile у него есть поле total, прочёсе это общее количество покупок и

83: 2 поле уже поинтереснее. Почему-то у меня оно 2 1, но не важно. Следующее поле интереснее, потому что оно как раз-таки символизирует кросс фичи. Мы просто храним мапу, где мапим айдишник товара на профиль товара и уже в профиле товара храним, какие, какие нам нужны.

84: Кроос свечи. В нашем случае это количество покупок за последние 30 дней и количество кликов за последние 7 дней. И таким образом, взаимодействие выглядит так, что нам из нашего пайплайна нужно получить этот профиль целиком и использовать его уже в памяти. Это работает очень быстро и не

85: И занимает очень и не требует большого количества походов в нашу базу.

86: Тут возникает другой вопрос. Вот у нас есть профиль, мы считаем этот профиль, как-то его проливаем, а как мы его проливаем? Насколько часто мы нужно проливать этот профиль? И тут есть 2 полярности. То, что может быть оффлайн профиль, когда мы считаем его бачево обычно раз в день и

87: Онлайн профиль, когда мы считаем его на клик стриме в оффлайне. Проблема какая-то, что у нас точнее сначала плюс плюс в том-то, что у нас низкая ошибка, потому что мы считаем это на исторических данных. И если что-то упало, мы можем просто перезапустить жабу.

88: Минус в том-то, что у нас нет актуальности, то, что данные доезжают до исторических событий. В нашем случае за 8 плюс часов онлайн профиль. У него все наоборот. Мы получаем актуальные данные, но у нас могут быть какие-то непредсказуемые ситуации с ошибками, с

89: И так далее. Что мы говорим, как платформа, мы говорим, что, а давайте мы не будем выбирать, а будем объединять и то, и то решение мы будем хранить и офлайн, и онлайн профиль, чтобы лучше понять, как это работает. Возьмём пример, количество просмотров това,

90: Просто счётчик как работает. Представим, что оффлайн профиль мы считаем итиэль джаббой раз в 2 дня. И вот за 23 число мы посчитали его за на все исторические данные. И у нас получилось значение 4. Что происходит дальше. Дальше мы

91: Считаем онлайн профиль за последние n дней с гранулярностью в день, то есть за 24 число, мы посчитаем онлайн профиль и сохраним единичку за 25. Будем считать его с нуля и посчитаем 2. И что нам нужно сделать в real time нам ну вот для

92: Математичности. Покажу как это выглядит. По простому, что у нас за 23 4 события. Тут 1, тут 2. И чтобы посчитать текущую фичу, нам нужно просто сложить это и вот в реальном времени. И выглядит это так. То, что на этапе получения фичей из маэстро

93: Мы идём в 2 кассандры, получаем эти фичи, склеиваем их, а собственно фичи туда попадают через исторические данные или через топик событий.

94: Возвращаясь к нашей задаче с шоппингом что мы делаем, мы используем и то и то мы храним в сфераи атомные фичи, а в профиле храним юзерские и кросс фичи, и на самом деле тут для нас как для реализации этого пайплайна.

95: Огромный плюс в том, что мы вообще не думаем о том, как эти фичи будем хранить, потому что за нас это уже решено. И это работа будет работать шикарно. Чтобы настроить этот конфиг. Тут нам нужно, ой, чтобы настроить этот этап, нужно написать конфиг, как выглядит конфиг.

96: На выход с этого этапа нам нужно получить уже список готовых фичей, которые полетят в inference. Для этого, собственно, нужно написать такой же список в конфиге, как выглядит он. У нас есть 3 поля. Это название фичи, это тип фичи и экспор экспор.

97: Это наш дсль, который описывает то, откуда фичу взять, как её положить и как её преобразовать. Например, есть фича каррент. Аур. Это Коли сколько времени сейчас, который час. И чтобы посчитать его, мы его нигде не храним. Мы считаем его.

98: В реальном времени просто через функцию now. Отлично. Мы реализовали получение фичей. У нас есть конфиг, у нас есть профиль и Фрадин. Давайте перейдём к инференс. Тут долго не будем останавливаться. Все очень просто. Мы

99: Диплом, модель в нашу платформу серии, платформу и в конфиге просто указываем путь до сервинг платформы и путь, и название модели, и собственно, все для постпроцессинга. Нам нужно нужен какой-то кастомный этап тут на самом деле

100: Есть множество вариантов, у нас уже был готовый этап, поэтому мы просто его настраиваем. Можно реализовать как конкретно свой, потому что архитектура это легко позволяет сделать за счёт фреймворка. Так?

101: Так, получаем такую штуку что нам нужно сделать дальше нам нужно обсудить собственно что нужно чтобы реализовать такой пайплайн опять же нам здесь не нужен backend. Почему? Потому что вся реализация заключается в написании конфигов эмэль инженеру нужно просто прийти в platform.

102: Форму написать конфиги для всех этапов и все. А платформа предоставит контракты для этих конфигов, предоставит то, как лучше их сделать и написать, и пролить. Отлично. Так выглядит итоговый пайплайн. То, что мы собрали все этапы вместе мы

103: Завернули это в какой-то айпиай и отдали нашему бэкенду шоппинга. И, резюмируя всю табличку. Тут появился 4 пункт со сбором пайплайна. Можно сказать то, что теперь эмэль инженер, может самостоятельно, без помощи

104: Бэкенда, выбирать эмэль систем дизайна онлайн рекомендаций и можно самостоятельно реализовывать весь этот пайплайн и после выкатки в prod может менять состояние этого пайплайна как он хочет, он может добавлять новые фичи, он может добавлять новые кандидаты, генерацию, может делать аб тесты на разные модели и все это.

105: Предоставляет наша платформа ещё 1 овервью платформы и чтобы так запомнилось и давайте уже сделаем обзор. Обзор какой. Тут просто расскажу, какие тут были приняты решения важные. У нас 1 решение.

106: То, что мы реализуем под каждый домен свой пайплайн, мы не делаем универсальное 1 что-то, и это позволяет нам разделять ресурсы, потому что на самом деле пайплайны могут быть разные. Домены могут быть разные. Например, для рекламы нам нужно очень низкая латте.

107: А для шоппинга у нас, например, очень много кандидатов и за счёт такого решения очень просто разделять ресурсы и накидывать там, где они нужны. Также мы пошли в лоукод. То, что за счёт фреймворка нам теперь не нужно писать бэкенды с нуля. Нам нужно просто указывать конфиги.

108: Если что-то нужно расширять, это также у нас. Предоставляем решение с профилем пользователя, который позволяет удобно и быстро хранить кросс фичи и онланиз ровать их. И также, как платформа, мы знаем все нфт это тоже очень важный пункт, потому что теперь эмэль инженеру не

109: Нужно закладывать время в квартале на перфтесты, закладывать на то, а получится ли это сделать, потому что все теперь это упаковано и все это хранится в нашей платформе. И по поводу наших планов. В 1 очередь мы целимся в то,

110: Что мы хотим платформизма ь наше R&D направление с нейросетевым ранжированием, с применением классических трансформеров для векторизации и генеративной модели также мы хотим платформизма ь работу с данными, мы хотим унифицировать работу с проливкой фичей, с обучением модели.

111: И мы хотим пойти в полный ноукод, мы хотим попробовать сделать какой-то интерфейс, который позволит создавать энэн пайплайны вообще без бэкенда. Вот это примерно такой, такой план. Вот. А на этом, я думаю, я буду заканчивать. Спасибо вам за внимание и давай

112: Поотвечаем на ваши вопросы.

113: Спасибо большое, Эдуард, за доклад, сейчас появился QR-код, вы все знаете что делать можете потом в отзыве на конференцию написать, что душный ведущий заставлял вас оставлять отзывы я вообще не обижусь, но давайте пожалуйста.

114: Как-то поощрим спикера, оставим ему обратную связь. А пока вы оставляете обратную связь. На самом деле человек с микрофоном уже наблюдает за вашими руками и тихонечко подходит к вам. Спасибо большое. Всем привет. В общем, мой

115: Вопрос про перспективы использования фундаментальных и вообще перспективы появления фундаментальных моделей в домене рексис. Что я имею ввиду, если мы рассмотрим задачу энэлпи, вспомним, что до появле

116: Там чата gpt, в принципе, ллм, ну, приходилось постоянно под конкретную задачу, под конкретный датасет, обучать свою эмэль модель. Сейчас, что мы видим, это то, что не

117: Нужно спрос на обучение моделей, он упал, потому что фундаментальные собственно модели умеют решать 99% задач в нлпи, и кажется, что в рексис такая история, она очень маловероятна.

118: В силу того, что каждая рекомендация, она очень персонализирована для пользователя, ну, именно по отношению к конкретному пользователю, и, следовательно, появление таких фундаментальных моделей кажется невозможным.

119: Вот, собственно, повторю свой вопрос. Какие перспективы ты видишь? Развития фундаментальных моделей в домене рексис, потому что вот на последнем слайде ты как раз упомянул, что у вас там идёт работа в этом направлении. Спасибо.

120: На самом деле, я хотел сказать там-то, что мы, как платформа хотим попробовать перенести наше решение с фундаментальными моделями. На самом деле про фундаментальные модели, я думаю, лучше расскажут мои другие коллеги, которые занимаются конкретно развитием этого, но, возможно, в чем-то вы правы, а в чем-то

121: Нет, но я скажу так, то, что как платформа, мы хотим просто перенести наши решения, которые используются в банке на нашу платформу. Вот, а по поводу использования, ну, мы пробуем пока, наверное, я не могу говорить про результат.

122: От этого спасибо.

123: Спасибо большое, Эдуард. Было очень интересно. На самом деле, вот архитектура вот этой платформы, она была очень интересной. Вот. Единственное, у меня вопрос такой. Там было видно, что, откуда, как данные подтягиваются. Вот мне интересно насчёт вот холодного старта, когда

124: У тебя условно нету данных по юзеру или по продукту, как в таком случае? Ну, как бы, платформа работает, и, может быть, вы там условно какие-нибудь мета фичи используете или?

125: Или ща, ну или что, что вообще, или может какие-то эмбендинги из смежных областей условно, вот как вообще вот решается проблема холодного старта, да, это хороший вопрос про холодный старт. На самом деле, мы не часто

126: Решали такую задачу, потому что мы заходили в продукты, которые уже имеют какие-то данные, но с холодным стартом можно сказать, что да, во первых, можем использовать кросс фичи, как я уже говорил, тот же персеус фреймворк, который позволяет использовать фичи из разных доменов и вообще

127: Можно просто немного подождать и собрать данные, чтобы построить более удачную рекомендательную систему.

128: Да, привет. Спасибо за доклад. Было очень интересно послушать. Вот касался ты как раз cross фичей и говорил о способе. Как вы избежали вот этого комбинаторного взрыва, когда у вас там для 1 пользователя нужно хранить фичи, там по всем айтемам как-то очень быстро.

129: Можешь, пожалуйста, чуть подробнее раскрыть все-таки, как это реализовано вот именно работа с кросс фичами я попробую ответить как-то быстро, но у нас ещё потом k будет stand, я могу там подробнее рассказать вообще ещё раз. Мы храним кросс фичи в профиле, профиль это единый.

130: Лоб, который хранится в каком-то там Кивель хранилище, и мы по 1 айдишнику пользователя сразу получаем блоб целиком. В этом лобе хранятся информация о том, как пользователь взаимодействовал со всеми товарами просто в 1 мапе. И получается мы Перека.

131: Этот профиль в память и просто в этой мапе ходим и получаем по нужному товару нужные фичи. Ну то есть речь про оптимизированное доставание этих фичей, а не про эффективное хранение, потому что вы все ещё храните как бы, ну нет, нет, нет. Важно сказать то, что мы

132: Храним по 1 айдишнику пользователя сразу целиком блок его общения со всеми айтемами. Ну да, да, но весь этот блок хранится как бы целиком. То есть мы не распыляемся на все взаимодействия со всеми товарами. То есть ключ все равно user id остаётся, да.

133: А, да, это понятно. Окей, спасибо. Здравствуйте. Фомичев, Никита, газпромбанк. Очень большое спасибо за демонстрацию. Вот всего пути развития системы. И понятно, что такую систему был

134: Было построить довольно сложно и дорого. Вот считали ли вы окупаемость вот этой платформы и окупилась ли она уже

135: Я скажу так, что мы движемся к тому, чтобы она окупилась.

136: Спасибо большое за доклад. У меня, наверное, 2 вопроса. 1 вопрос. Какое количество Айтимов может ваша платформа хранить внутри десятки миллионов? Сотни миллионов, миллиарды на примере шопинга, там десятки миллионов товаров, а теоретически

137: Масштабироваться там до миллиардов сможет. Ну, если нужно, понятно, теоретически, возможно все. Но мы об этом не думали, пока не было такой потребности, но, я думаю, на сотни миллионов точно можно. Угу. И 2 вопрос, наверное.

138: Вот коллеги из Китая кань шоу, там другие в позапрошлом году написали, или в прошлом статью про one req, генеративные рекомендации, которые позволяют как раз не, ну как бы.

139: Не хранить кандидата генераторов, а на ходу генерировать айдишники. Вот с этим экспериментируйте ещё раз сгенерировать, что, ну, айдишники, то есть напрямую запихиваем в лмку. Угу. Вход и айдишники генерируются, потом просто достаются. Да, да, да, я понял. Но это как раз так.

140: 1, 1 из видов архитектур, который я говорил про enter модель. Угу. Да, мы с этим работаем, но не так много. Сейчас мы в основном фокусируемся на двухуровневых пайплайнах. Угу. Для канизат генерации в отдельном шаге. Понял? Спасибо.

141: Здравствуйте. Спасибо большое за доклад. Идея. Классная реализация. Тоже у меня вопрос. Как вы валидируете вот эти конфиги, которые генерирует эмэль инженер?

142: Это хороший вопрос, и мы над этим тоже много думали пока. Так что для критичных сервисов мы ревьювим их сами. То есть как платформа. То есть к нам эмэль инженер, меняет конфиг, приносит нам на ревью. Мы

143: Смотрим, что все окей, но в будущем планируется так. И даже на самом деле сейчас это уже есть то, что прежде чем выкатить конфиг, он сначала выкатывается на коа стенд проверяется, что там все работается, проверяется какие-то интеграционные тесты, и только после этого все выкатывается в прод, если там что-то уже

144: Ломается, то идёт какой-то разбор. Ну то есть получается сейчас вы бутылочное горлышко, ну в некоторых сервисах, да, критичных. Но, как я уже сказал, мы движемся к тому, чтобы это автоматизировать и сделать пайплайн с выкаткой на кией и

145: Тестированием там. Хорошо. Спасибо. Спасибо. Здравствуйте. Спасибо за доклад. У меня вопрос про инференс. Вот. То есть, когда разработчик приходит и пытается написать свой пайплайн на этапе инференса,

146: Когда он че то прописывает в конфиге, кто решает сколько видеокарт, например выделить под пайплайн конкретного разработчика. Это как-то на этапе вашей платформы решается или это разработчик конфиг как-то указывает это решается на

147: Уровня сервинг платформы это наша платформа внутренняя в банке, которая как раз-таки позволяет следить за ресурсами инференса. Вот мы как потребители платформы, лишь выкатываем нашу модель туда и пользуемся ей через api. Понял? А вот если, например,

148: Разработчик приходит и говорит то, что там для моего пайплайна нужно там развернуть много моделей, то есть какая-то требовательная вещь. То есть это как-то через вашу команду взаимодействие происходит или, или как это вообще у вас устроено? Ну, устроено так, что

149: Если мы выходим за рамки с платформы, которая предоставляет нам, то мы просто идём и договариваемся о том, что вот нам нужны, нужно больше ресурсов. Ну, то есть это идёт через общение. Понял? Нам выделяют эти ресурсы. Понял? Круто. Спасибо большое. Спасибо. Спасибо. Боль.

150: За доклад очень интересный у меня следующий вопрос. Вот вы говорили, что вы хотите платформизма ь, в общем, работу аранди команд, чтобы они тоже пользовались платформой и так далее. Вот часто у аранди команд бывает такое, что они готовят данные, как

151: То по своему, кто там через эскьюэль, кто ещё через какие-то методы. И таким образом часто не сходятся фичи в оффлайне при обучении модели и в онлайне. Вот вопрос как раз про это, как вы боретесь с этим и планируете ли вы это включать как-то в платформу, да?

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

153: А сейчас в процессе, поэтому я особо про это не говорил, но это будет какой-то единый движок для расчёта фичей. Угу. Окей. Спасибо. Привет. Спасибо за доклад. А подскажи, пожалуйста, вы сейчас поддерживаете как-то квотирование ресурсов или какое-то возможно?

154: Разделение ресурсов, потому что там вдруг вам придёт несколько разных сервисов. 1 скажет, что хочет 100 петабайт Логов, и вы складываетесь

155: Ну, как я уже сказал, сейчас ещё раз вопрос про то, что как вы поддерживаете квотирование ресурсов на какой-либо сервис, который к вам пришёл. Ну вот за счёт того, что мы разделяем пайплайны между разными доменами, по сути, отдельный пайплайн, это отдельный сервис у которо

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

157: Ушками. Че так же? Ну, вообще, да, но опять же, с инференсом, со всем это все через серлинг платформу работает. Мы как бы с этим не взаимодействуем плотно. Значит, как бы в этом и фишка платформы, собственно, серлинг платформы, что мы об этом много не думаем, но

158: Да, это все идёт через них. Спасибо.