0: Всем привет.
1: Сегодня мы подготовили для вас доклад про то, как мы делаем фоундейшн модель в Сбере. Пару слов о том, кто мы. Меня зовут Зорин Константин. Я занимаюсь непосредственно разработкой фоундейшн модели.
2: И мой коллега Андрей занимается внедрением её во всякие рексис процессы. Введём немного в контекст нашей задачи. Наверное, все знают про Сбер, что это крупнейший в России банк у нас более 100.
3: 20000000 клиентов. Из этого следует, что у нас огромные объёмы данных, огромные объёмы разных источников это транзакции, это кликстрим, это разные коммуникации и экосистемы и так далее.
4: Все это ведёт к тому, что нам очень важно получать даже маленькие клементы в улучшении качества, так как это имеет огромный бизнес эффект. То есть это все вот эти доли процентов рокауков, так называемых конвертируются в 1000000
5: В миллиарды, соответственно, в чем наша задача? Мы хотим все эти огромные объёмы данных разных данных уместить в 1 модель и получить наиболее качественный, наиболее информативный эмбеддинг.
6: Пользователя, который мы используем для решения любых банковских задач. Соответственно, какие проблемы наша модель вообще решает, с какими проблемами мы сталкиваемся. Вот. 1, это, конечно же, у нас гетерогенные данные. Вот здесь
7: В табличке видно, что у нас очень разные длины последовательностей. Разный род источников. То есть, например, в клик стриме у нас 270, средняя длина в транзакциях 700 за год. Вот.
8: А также мы хотим решить проблему того, что нам нужен фичер инжиниринг. Зачастую, то есть мвп там в большинстве продуктов это какой-то бустинг на табличных фичах, которые человек подготовил. Конечно, здесь есть проблема
9: Что нужен человек, нужен человек, который будет готовить фичи. У него фантазия ограничена, и мы хотим от этого уходить, переходить в нейросетевую область. И, соответственно, также у нас не хочется делать по 1 модели на каждую задачу. Они не
10: Не переиспользуемые, они не берут сигнал из других задач. Вот и все это мы хотим решить. Соответственно, здесь вы можете увидеть архитектуру нашей модели базово. Она выглядит так. У нас есть секвен модул.
11: Это который мы замораживаем. Далее подробно расскажу, как он устроен. Вот это основная часть, в которой мы все последовательные данные загоняем. Но также у нас в проде очень много табличных фичей в бизнесе, они
12: Разрабатываются уже годами, они очень информативны для задач, поэтому полностью мы уйти от них не можем. Поэтому вот они стороной с помощью табличного трансформера отдельно прикладываются к нашей основной модели. Соответственно, потом
13: Выходы соединяются и уже это учится с помощью какой-то лёгкой даунстрим головы, которая уже используется там под разные задачи. Соответственно. Далее я расскажу, как подробно у нас работает наша последовательная модель, соответственно,
14: У нас мультимодальность, у нас много, много разных источников, как я говорил, там пример, это транзакции кликстрим, соответственно, как же мы, как же устроена у нас мультимодальность? Во первых, скажу, что
15: Нужно мы хотим предобучить модель. Соответственно, как её предобучить? Берём идею из лмок, учимся предсказывать следующий токен токен. В нашем случае это событие. Вот. И как же устроена мультимодальность. Во первых, нам нужно привести
16: Все к 1 словарю понятно. То есть у нас есть сквозная токенизация, у нас категориальные фичи обрабатываются с помощью обычного эмбеддинг слоя, а числовые через линейный слой вот после этого
17: Нам нужно как-то подружить их между собой, эти модальности. Соответственно, что мы делаем? У нас есть так называемый ивент инкодер. Мы берём и падём до максимального количества фичей в каждой модальности. Что это значит? Например, у нас
18: У транзакции фичи это сумма, категория покупки, у клик стрима это место клика и так далее. Вот. Соответственно, мы, у нас есть фичи, которые общие на разные модальности. Есть фичи, которые 1, которые разные. Вот
19: И, например, у нас есть транзакции внутренние, есть транзакции, которые приходят с эквайрингов, то есть с других банков. И, соответственно, конечно же, у них есть общие фичи, мы их хотим между собой тоже совмещать. Соответственно, мы падём до макси.
20: Максимальной размерности атрибутов. Далее считаем аттеншен внутри размерности атрибутов. После этого их пуллим между собой. И таким образом мы получаем эмбединг для каждого события. А так как мы получили эмбединг для каждого события здесь уже аналогично.
21: Тому, как делают влэках, можно считать обучать обычный декодер на предсказание следующего, следующего события.
22: Чуть чуть также расскажу про наш табличный трансформер, раз уж его упомянул это обычный трансформер из статьи фт трансформер с небольшими модификациями в виде свеклушка вместо активаций.
23: Соответственно, здесь мы точно также категориальные фичи процессим через эмбеддинг числовые, через линейный слой. После этого конкатенируем, добавляем туда шум, тоже проверяли, что это улучшает стабильность работы модели и, соответственно, уже обу,
24: Обучаем на на наш таргет. Соответственно, здесь мы ничего не претрени, это используется только для даунстримов и это используется потому что у нас мы не можем пока отказаться от всех табличных фичей.
25: Ещё 1 интересная идея, которая у нас используется, звучит так у нас в банке зачастую важно получать не эмбеддинг события, а достаточно получать эмбеддинг дня.
26: Для человека. Почему? Потому что мы обычно предсказываем, что там произойдёт в следующий день, через месяц и так далее. Это большинство банковских задач. Соответственно, хотим сократить сложность вычислений в обучении. Что мы делаем? Мы создаём патч.
27: Дня инициализируем его днём, года, днём недели и с помощью кросс аттеншен связываем его с событиями дня, как я рассказывал ранее. Вот, соответственно, мы таким образом получаем какой-то патч дня и уже
28: Вот эти патчи дня подаём в большой трансформер декодер и учим также предсказывать следующее событие. Только событие. У нас уже здесь день получается. Таким образом, у нас матрица аттеншена сильно уменьшаются. Вот так как
29: Ограничены днями и, соответственно, у нас вычислительное сильное ускорение порядка 40%. Ну, понятно, зависит там от обучающей выборки. Вот, но при этом в качестве не проигрываем.
30: Далее хочу рассказать про то, какие вообще эксперименты мы делаем, в какую сторону мы движемся. 1, конечно же, это скеллинг. Сейчас, я думаю, в рекомендательных системах, также в лмках, это везде на слуху просто увеличи.
31: Модель. Надеемся, что она запомнит больше информации. У нас это работает на слайде как пример. Переход от 13000000 к 100000000 параметров 100000000. Это сейчас самая большая у нас используемая конфигурация, но
32: Кажется, что это не предел в 1 табличке можно увидеть приросты, если не использовать табличные фичи, видно, что приросты довольно значимые. Напомню, что в банковской, в банковских задачах там доли.
33: И проценты это очень значимые приросты. Вот. И, а снизу можно увидеть совместно с табличными фичами. Интересно, что табличные фичи иногда перекрывают вообще приросты от развития самой модели. Конечно, от этого тоже
34: Хочет уйти. Но вот интересно, до какого момента в скиллинги можно доходить. Далее упомянул, что мы используем обычный декодер. Какой вопрос? Честно кажется, что это не супер.
35: Мы долгое время использовали gpt 2, просто как легко интерпретируемую и модифицируемую архитектуру вот попробовали ламу.
36: С интуицией того, что там более современная активация и так далее. То есть там на самом деле особо прогресс далеко не ушёл. Вот, но за счёт всяких оптимизационных приколов
37: Которые ведут к лучшей сходимости модели. Все-таки улучшения есть. Поэтому используем ламу. Также, если там отводить в сторону лемок сразу на ум приходит. Моё пробовали моё
38: Обычный, то есть вот как например gps сходу он не работает как получилось завести у нас гипотеза такая, что модальности очень разнородные и хочется прямо в трансформере, в процессе.
39: Независимо друг от друга. Соответственно, что мы сделали прямо в трансформере. Например, там в gpt разделили эффи под каждую модальность отдельно. В таком, в такой постановке уже заработало, заработало, видно, что на
40: 1 из 3 задач, кажется, не идеальный результат, но как минимум положительный сигнал здесь есть. Кажется, он хороший, и в эту сторону тоже стоит идти. Долго говорю про то, как можно предобучить модель, вопрос.
41: Нужно ли это вообще ответ нужен. Нужно. У нас есть стабильный прирост абсолютно на всех задачах от предобучением. Поэтому мы считаем, что этот этап важен. Также он позволяет
42: Переиспользовать. Далее модель. Что тоже важно, ещё 1 проблема, которая возникает. Когда мы переобучаем модель, мы добавляем источник. Источник может быть полезен для каких-то задач.
43: Действительно, но на каких-то он может качество ухудшать. Вот вопрос, как с этим бороться?
44: Самое тривиальное, что происходит, приходит на ум, это просто отключать на инференсе этот источник, и это работает. Вот в табличке. Можно это увидеть, как эту табличку читать. У нас есть 2 таски. Вот первые 3 строчки, это 1 таска, соответственно.
45: 1 строчка, это у нас источник добавлен во 2 мы удалили до обучения, в 3 до инференса. Видно, что при удалении источника до обучения примерно эквивалентно тому, чтобы убрать его перед инференсом. Соответственно, мы можем
46: Бесконечно добавлять источники в нашу модель. И уже на этапе инференса мы можем корректировать качество, то есть делать так, чтобы источники были всегда безопасны при добавлении.
47: Ещё 1 вопрос, почему мы обучаем в постановке некст её предикшн, как бы это понятно в лмках, в предсказании там следующей транзакции уже не супер, очевидно, вот здесь на самом деле
48: Нет, пул, тасок, который, возможно, на претрени, он очень большой. То есть мы там пробовали базовые млм контрастивно на больших данных это все работает хуже, чем к предикшен, но кажется, что все равно ещё есть Куч.
49: Задач, которые мы хотим исследовать. Вот, например, на слайде можно увидеть 1 из задач, которую мы добавляем в притрен. Это мы из каких-то модальностей, например, из клик стрима, транзакций, предсказ
50: Там отклик человека на коммуникацию. Вот, то есть мы из одних модальностей предсказываем другую. Таким образом мы, можно сказать, аргументируем нашу модель, и это добавляет по качеству довольно стабильно.
51: Хочется и дальше идти в эти претрейн таски, следующая при таска, которая вытекает из того, что табличные фичи все ещё важны. Мы не можем от них отказаться. Хочется добавить их прямо в претрейн здесь.
52: Результаты не прям однозначные. Что мы делаем? Мы добавляем в центр цепочки в центр месяца, ставим цлс токен из цлс токена, предсказываем агрегаты на конец месяца. Агрегаты составляют наибольшую там часть.
53: Табличных фичей. Вот мы предсказали. Таким образом, мы в претрейн добавляем табличную часть на некоторых задачах это сильно помогает, на некоторых наоборот ухудшает. Кажется, что положительный сигнал здесь тоже
54: Хороший и он есть. Поэтому эту часть точно нужно развивать и потенциально. Если доба научиться добавлять все табличные фичи в претрейн, это сильно упростит жизнь. Теперь чуть чуть расска.
55: Расскажу вообще о том, чем, зачем мы здесь собрались. Все-таки бизнес эффекты. Мы встроили головы ффм для 6 ключевых продуктов в пуш коммуникациях, в банке по сравнению с бустингами. Это дало плюс
56: 1% к финансовым метрикам, что очень значимо на таких масштабах, а также раскатили в прод нашу модель как дефолтную модель склонности, но
57: На этом задача рекомендаций не заканчивается. Мы научились получать хороший эмбеддинг пользователя. Он довольно, он довольно короче, он подходит для всех задач, но при этом рекомендательная система
58: Штука сложная. Хочется подавать информацию ещё и о продуктах, ограничениях, оо каналах. О всем этом расскажет мой коллега Андрей, передаю слово. Да, кость. Спасибо. Действительно.
59: Получение хорошего эмбеддинга клиента это очень важная часть. И действительно, это всего лишь часть того, что необходимо для того, чтобы хорошо решать задачу рекомендаций. И в целом для решения этих задач мы разработали отдельные башни над фмом.
60: Который мы назвали омниканальная модель рекомендаций. Но прежде чем я перейду к тому, чтобы описать, как именно мы решили эту задачу, позвольте я немножко погружу в контекст. Чем же рекомендации банковских продуктов отличаются от других рекомендаций в других доменах? 1
61: У нас очень маленькая полка на 1 клиента. В 1 момент времени доступно одновременно примерно 70 75 продуктов. И эти продукты очень сильно отличаются друг от друга, от кредиток до промокодов в сервисе доставки. 2, мы работаем на
62: Максимизацию прибыли клиента, то есть наше ранжирование максимизирует мат ожидания прибыли. Мы ищем баланс между релевантностью для клиента и заработком для банка. При этом из за того, что наши продукты очень отличаются друг от друга, их финансовые метрики тоже очень
63: Сильно отличаются, что привносит свои коррективы. 3 окно атрибуции у нас занимает от 1 дня до 2 месяцев. И из за этих 2 месяцев нам очень сложно быстро подстраивать модели под последние события клиента. Четвер
64: Релевантность в нашей задаче гораздо сложнее, чем в классическом рексис любой банковский продукт подходит под конкретную жизненную ситуацию клиента, которая происходит гораздо Реже, чем желание послушать какой-то трек, посмотреть какой-то фильм или заказать любимой шоколадку из доставки.
65: И следующее. До какого-то момента основными моделями в наших рекомендациях были бустинги, причём 1 выход бустинга отвечал за 1 конкретный продукт. У этого решения есть свои плюсы, но есть свои минусы. Например, в бустингах мы не можем полностью утилизи.
66: Эмбеддинг фма да, бустинг может выучить какие-то полезные сигналы из координат эмбеддинга, которые fm может нам сгенерировать да, в кабусе он может использовать этот эмбединг для того, чтобы находить похожих клиентов между собой, но это все ещё недостаточно. Бустинг не может выловить всю семантику.
67: Которая находится в эмбединге. Также хочется немножко поговорить о тех каналах, в которых мы коммуницируем. Мы делим их на 2 типа. 1 это пуш каналы, такие как емейл СМС и уведомления. Здесь инициируем контакт с клиентом. Мы сами
68: И таргетируем определённую аудиторию, которой наш продукт может быть интересен.
69: 2 группа это paul каналы, такие как приложение, отделение или звонок в колл центр. Здесь контакт инициирует сам клиент. И у нас есть, условно говоря, прослойка между банком и клиентом в виде клиентского менеджера, за счёт которого мы можем сильнее воздействовать.
70: На клиента. И дальше я буду рассказывать именно про наше решение в пул, в пул каналах, в пул коммуникациях. Также ещё очень важный момент. У нас поведение продуктов в каналах отличаются. Например, если взять один и тот же продукт, то его конвер
71: В 3 разных каналах будет отличаться от 3% до 54. И это очень большой разброс. Более того, если посмотреть на среднюю конверсию в каналах, то она тоже очень сильно отличается. Давайте перейдём к этому в целом. Если говорить про
72: То, что у нас поступало в модель, это там 4 основных канала коммуникации, в которых мы можем либо показать баннер, либо презентовать что-то на планшете, либо презентовать что-то в звонке и как можно увидеть количество коммуникаций в 1 канале, очень сильно доминирует над остальными 90.
73: 3% всех наблюдений у нас попадают в 1 канал. При этом, если взять конверсию как некую базу, вот конверсию 1 канала, как некую базу, то она в 10 раз меньше, чем конверсия в других каналах. То есть поведение продуктов в разных каналах в целом. Плюс минус отлича.
74: Ну, в общем, средняя конверсия каналов также отличается как поведение продуктов в этих каналах. И если бы мы начали обучение в таком формате, то моделька бы выучила чаще, скорее всего, только паттерны из 1 канала и плохо понимала бы остальные. Поэтому мы сделали
75: Семплинг 1 канала уменьшили количество коммуникаций в 10 раз увеличили конверсию, наоборот, в 10 раз сделали датасет более менее гомогенным, чтобы модель плюс минус одинаково с погрешностью могла понимать паттерны поведения в разных каналах.
76: И теперь, собственно, про саму архитектуру модели по факту ещё раз это башни над фмом, и в это классическая тут Ауэр архитектура с башнями клиента и с башнями продукта в башню клиента у нас поступает собственно эмбеддинг фма табличные агрегаты.
77: Которые все ещё несут полезный сигнал для нас и эмбеддинг коммуникаций. Обо всем этом мы поговорим чуть позже. В башне продукта у нас идут эмбеддинги описания продукта и иерархии продукта.
78: Ядром нашей модели является дип кросс нетворк 2 версии от гугла в парадигме лоурен, чтобы мы не разращивания, условно говоря, параметры нашей модели и при этом могли хорошо находить взаимодействие между отдельными фичами для решения конкретной задачи. Более
79: Того мы решили сравнить, а если взять дисинки и взять бустинг, подать в него плюс минус одинаковые данные, получим ли мы какой-то прирост только от смены архитектуры, от смены модели и результаты следующие, если мы подаём и в бустинг, и в dsm информацию?
80: Там табличные данные и иерархию, но в виде категориальных фичей, то метрики одинаковые, однако если мы формируем иерархию как именно эмбеддинг, который чуть лучше описывает конкретный продукт, то dc начинает выигрывать бустинг.
81: В наших экспериментах мы увидели в среднем разницу на 4 процентных пункта порока. У это очень хорошая разница для нас. И более того, за счёт того, что мы используем нейро ранкер, мы можем максимально утилизировать ффм по нашим аблей, если, условно говоря, отка
82: От фма и решать задачу на остальных данных мы все ещё можем решать эту задачу, но опять же на 5 процентных пунктов рокаук, наше качество уменьшится для нас это катастрофически.
83: Давайте теперь поговорим про собственно конкретные элементы в разных башнях. Поговорим, начнём с табличных данных. Собственно, мы их делим на 2 категории. Непрерывные и категориальные. Непрерывные обрабатываем через пле, которые здесь уже описывали категориальные, через таблицу эмбеддингов. Причём
84: Категориальные. Делим на 2 категории, низко координальные, такие как пол и высококоординированный. Даём каждой из этих групп свой свою размерность, что логично, чтобы не делать. Не получилась ситуация, когда ебени наоборот, либо сильно сжат, либо сильно разрежен. После-ка,
85: Каждый эмбеддинг мы пропускаем через слой дроп аут, но отключаем не отдельные нейроны, а весь эмбеддинг фичи и финально конкатенируем все признаки в 1 большой эмбед, так как размерность эмбеддингов разная суммирование нам недоступно, но конкатинация тоже отлично работает.
86: Теперь проговорим немножко про энкодер коммуникаций. С его помощью мы кодируем историю и успешность предыдущих коммуникаций на вход. Мы подаём канал коммуникации продукт разницу между последней и текущей коммуникацией, тип канала и этап воронки, до которого мы дошли в этой коммуникаци.
87: Затем это все прогоняем через инкодер, дообучаем файнтюне его с остальными элементами и, собственно, уже прогнозируем там cr CTR и прочие таргеты. При этом может возникнуть вопрос но вы вроде говорите, что коммуникации в fm подаются, зачем их здесь дублироват?
88: Ответ простой в fm коммуникации это, условно говоря, свойства клиента здесь же мы хотим с помощью коммуникаций уловить как раз-таки ту самую специфику продуктов и каналов, которая фму пока что недоступна, и, более того, с помощью отдельного инкодера мы хотим перейти к тому.
89: Что мы называем секту аплифт, то есть имея какую-то базовую историю коммуникаций, мы и получив какой-то базовый сиар, да, по, не знаю, кредитке или вкладу, мы хотим добавлять какие-то фиктивные коммуникации, которые мы могли бы провести и посмотреть, насколько изменится
90: Итоговая конверсия клиента вот этой коммуникации. Таким образом, выбирая наиболее оптимальную. Теперь давайте поговорим про башню продукта, про иерархию. Иерархия у нас состоит из 3 уровней. Это макро класс, класс и группа продуктов. Примеры
91: Можете увидеть на слайде каждый уровень текст каждого уровня, название каждого уровня мы пропускаем через текстовый инкодер Фрида и получаем текстовый эмбеддинг каждого уровня. Затем мы каждый этот эмбеддинг умножаем на его соответствующий вес и итоговый эмбед это
92: Взвешенная сумма эмбеддингов каждого уровня веса нам нужны для того, чтобы улучшить разделяемую способность кластеров, чтобы модель понимала, чем кредитная карта отличается от дебетовой. И в целом, так как иерархия есть у каждого продукта, в который, по которым мы коммуницируем, мы можем, да,
93: Наши прогнозы, в том числе для Холодных продуктов, которых раньше модель не видела. Например, там в 24 году появился новый банковский продукт. Программа долгосрочного сбережения. Раньше о ней никто не знал, но опять же, она относится к какому-то макроклассов классу за счёт того, что мы не знаем.
94: Группу, но знаем другие уровни. Мы можем дать хороший сиар, прогнозный сиар. 2 часть это описание продукта. С его помощью мы хотим лучше учитывать отличительные свойства, которые могут заинтересовать клиента по конкретному продукту. Примеры также можете увидеть на слайде в качестве
95: Эмбеде мы используем эмбеде на базе гига чата, и у кого-то обязательно возникнет вопрос а почему GigaChat, почему не queen 3 и так далее? Ответ максимально простой и связан с инфраструктурой эмбеде на базе гиги нам доступен с 1 дня и у нас заложен банально бюджет.
96: На то, чтобы его использовать. То есть это самый простой доступный эмбеде для нас в проме. Поэтому мы начали с него. Тем не менее, у нас запланированы эксперименты для того, чтобы проверить, насколько обработка описаний с помощью других эмбедерам растит или там не растит нашу модель.
97: Наши метрики и по нашим экспериментам мы видим, что добавление описания растит сиар по страховым продуктам и по пакетам услуг. И более того, мы видим рост практически по всем группам продуктов в премиальных сегментах. Мы связываем это с тем, что премиальным сегментом как раз
98: Таки очень важно какие-то отличительные особенности продукта, которые могут их заинтересовать. Поговорим, наконец, о применении. Как мы уже говорили, у нас 120000000 активных клиентов на каждого примерно 75 продуктов, и мы получаем 9 миллиардов Скоров, которые мы на ежедневной
99: Подготавливаем и складываем в real time сторедж для того, чтобы применять дальше по процессу и типа применения у нас 2 1 это апстрим, когда скором не подаётся в канальный специфичный бустинг, который уже участвует непосредственно в ранжировании, может возникнуть вопрос.
100: А зачем апстрим? Вы же вроде говорите, что бустинги победили с помощью нейронок, а тут опять бустинги. Что происходит? Все очень просто. Часть информации приходит нам в запросе онлайн, и передача скара как фичи, а не напрямую на применение позволяет нам как раз-таки.
101: Очень дёшево утилизировать эти рил тайм признаки. Ну, например, клиент пришёл в конкретное отделение банка за конкретным там решением своей проблемы и попал к конкретному менеджеру. Эту всю информацию мы можем получить только в момент, когда он пришёл, мы не можем предсказать её с хорошим качеством, тем не
102: Менее сравнивая, проведя б тест, сравнивая 2 одинаковых бустинга в 1, мы подаём омни, в другой. Нет, мы видим, что мы наращиваем сиар на 0 78% и фимерии на 0 43%. Для нас это очень большой рост.
103: 2 тип применения, собственно, это даунстрим, применение, оно сейчас применяется в оффлайн сценариях. Рекомендации это где, собственно, скором не передаётся как итоговый скор для формулы ранжирования. Сейчас оно чаще применяется для новых каналов коммуникаций, где раньше не было.
104: Никаких вообще предложений, никакой статистики. Мы можем ничего построить. И также, проведя тест, мы видим, что мы с помощью orm не наращиваем все метрики на 4% относительно бейзлайна, который применяется. И, более того, мы очень сильно сокращаем время за
105: Рекомендаций. Если раньше по новым компаниям продаж, по новым продуктам мы ждали по 3 месяца для того, чтобы запуститься на рандоме, собрать какую-то статистику для бизнес правил, затем обучить какие-то бустинги. Сейчас мы можем запуститься сразу, тоже самое с новыми каналами, если опять же для
106: Того, что раньше нужно было ждать около квартала для того, чтобы запустить эмэль рекомендации в новых каналах. Сейчас мы можем это сделать примерно за 3 дня и в заключении в части омни немножко поговорим о тех вызовах, которые мы перед собой видим. Во первых, мы хотим лучше понимать,
107: Большую детализацию продукта мы хотим научиться отличать, когда клиенту стоит предложить СберПрайм для того, чтобы решить его вопросы. А когда достаточно более простого СберПрайм лайт. 2 проблема. 2 вызов. Это типичная история для любых мультидомен.
108: Моделек, а именно сисо эффект. Мы себя ощущаем как вот этот прекрасный мужчина на картинке, что улучшая качество 1 канала, например, отделений, мы хуже понимаем клиента в канале приложения. У нас есть уже идея, как это исправить. Собственно, планируем эксперимент
109: В ближайшее время и 3 это хотим реализовать сдвиг вклада, вклада табличных признаков сейчас, как я уже говорил, табличные признаки все ещё несут много полезного сигнала для нашей задачи, и хочется перенести этот сигнал в fm, чтобы fm стало единым.
110: Источником клиентской информации для нас. Ну, о дальнейших планах и прочих оо заключении по fm я передаю слово обратно Косте спасибо, чуть чуть расскажу вообще.
111: Какие планы сейчас перед foundation модул 1, это конечно же скеллинг хайпует. Дальше там нолики к параметрам приписываем. Вот соответственно интересно вообще, как скеллинг лос с lm переносится.
112: Наш транзакционный домен. Работают ли они вообще, сколько мы можем скелиться. Вот. Далее мы, конечно же, хотим добавлять текстовую модальность. У нас очень много текстовых данных, это обращения, звонки и так далее. Вот.
113: Сейчас они не используются. Хочется использовать. Вот хочется расширять пул претрейн задач. Как я говорил, этот пул, он не ограничен, и хочется найти какие-то наиболее подходящие для нас наиболее универсальные, которые реально будут прибавлять
114: Качество на разных дом стримах и в целом делать модель более богатой с точки зрения знаний. Ну и конечно же, хотим продолжить менять бустинги в проме, хотим перекатываться полностью на
115: Нейро ранжирование, чем мы сейчас активно и занимаемся. Также хочется подсветить, что у нас по нашей фондейшн модели прошла статья на кдд в августе, поэтому если кому-то там что-то непонятно или хочется больше изучить, можно будет посмо.
116: Смотреть, почитать. Ну и конечно же, там сейчас мне задать вопрос, в том числе в заключении хочется сказать, что фоундейшн модул реально хайп не только на словах это работает, работает хорошо приносит там бизнес эффекты растит.
117: Метрики. Вот. Соответственно, мы таким образом научились, продолжаем учиться делать хорошее представление, векторное пользователя. Это нам даёт возможность сделать какую-то универсальную модель, чтобы ре,
118: Все задачи 1 моделью. И также это позволяет нам выстраивать единую эмэль платформу для персонализации клиента, в том числе, учитывая омни, встраивая туда информацию о каналах, о продуктах.
119: И так далее. Спасибо за внимание. Будем рады услышать ваши вопросы.
120: Так, Андрей, Костя, спасибо да, за доклад, перед тем как я предложу вам задать вопросы, попрошу оценить ваш доклад тоже по QR-коду. Так будет ли у нас QR-код?
121: Да, в общем QR-код появился, пожалуйста, оцените доклад, вот все читаем, очень важно, давайте перейдём к вопросам.
122: Привет. Привет. Спасибо за доклад. Хотел спросить про патч дня. Не понял немножко вот этот момент, что все действия агрегируются в день, а мы на следующий день предсказываем 1 действие. Нет, мы предсказываем также эмбеддинг следующего события. Ну, у нас просто события перетекает в ден.
123: То есть мы предсказываем следующий день. Таким образом, мы учимся агрегировать всю информацию о пользователе, которая произошла за день. Вот. Соответственно, у нас там матричка аттеншен, она не из не из количества событий состоит, а из количества дней, что типа гораздо, гораздо
124: Меньше. Вот. И, соответственно, это сокращает вычислительные сложности. Я просто не понял, что у нас, у нас же может быть несколько действий в день, да, совершенно разных, да, мы, мы сначала делаем кросс аттеншн между днём недели и днём года на собы.
125: Дне. Вот мы сделали кросс теншн, потом как-то это запулили, вот и уже, и уже получили эмбеддинг дня. И по этому дню обучаем декодер. Круто. Спасибо.
126: Да, спасибо большое за доклад. У меня вопрос, наверное, тоже про лос и не до конца понял. То есть, смотрите, ну, в nlp у нас есть там дискретные токены, и мы просто предсказываем следующий токен. А вот тут у нас есть и категории транзакций, и там
127: Объём транзакции. То есть у нас есть, во первых, гетрогар, ые, фичи, во вторых, вы ещё это как-то агрегируете, поэтому можете ещё раз уточнить, как вот вы и категориальные, и непрерывные переменные. Какой лосс, да, хороший вопрос. Соответственно, у нас ллосы отдельные, вот.
128: То есть, у нас для категориальных это, ну, стандартная кроссэнтропия для числовых, это там моё, или mse, в целом, неважно. Вот. И, соответственно, их нужно как-то взвешивать. Вот взвешиваем мы, ну, так как они у нас там примерно в 1, в 1
129: Диапазоне мы просто их между собой складываем, но в целом можно и взвешивать. Вот. То есть здесь какого-то универсального ответа нет. Tam используем какую-то, какие-то веса, которые в нашей конфигурации работают лучше всего. Вот, то есть вы непрерывные признаки как-то нормируете, да, чтобы они в 1 масштабе
130: А потом просто суммируете кроссэнтропию с mc ёшкой или ну грубо говоря да а, спасибо большое и 2 вопрос. Другая модель, которую использует Сбер для эмбедингов это вот колёс, да, контрастивная, которая отделяет разных пользователей, как соотносится?
131: Метрики просто вроде бы не было, сравнения с ней, да, сравнения в презентации не было. Мы сравнивали у себя. То есть там не могу сказать, что что-то однозначно хуже, что-то однозначно лучше вот на нашем объёме данных. То есть колесон все-таки проверял
132: На каких-то открытых датасетах, вот на на наших датасетах, то есть у нас они сильно больше, там в десятки 1000 раз. Вот на наших данных next the prediction работает лучше, чем млм работает лучше, чем
133: Иные методы, в том числе колёс. Ну, у нас так получилось. Спасибо.
134: Большое спасибо за доклад. Следующий вопрос про моё модель. Если я правильно понимаю, во первых, устроен сам, само событие, как там условные даты, стоимость покупки, направление и так далее, и тому подобное. Вы в случае того, когда заводили моё, сделали примерно то, что у ва
135: Эксперты стали детерминированные. Да, вопрос, куда делся роутер и зачем, в принципе, такая конфигурация? Роутер испарился. То есть мы роутим, роутим руками вот по модальностям, соответственно, с роутером тоже пробовали с роутером.
136: Просто работает лучше, ой, хуже, хуже. Угу. Вот. Поэтому его убрали в целом, ну, как бы, валидное замечание, да, интуитивно роутер должен работать. Ну, на самом деле, у вас буквально, если я правильно понимаю, терминированная должна детерминированный роутинг. И вопрос, как тогда Балан,
137: Этот самый роутер, в принципе, если он работал хуже, хотя он должен, по идее, просто направлять. Всегда известно, куда вы должны направлять следующее событие. Если, ну, если я правильно понимаю то, что каждое событие, оно должно быть заранее утверждено, 1 и та же схема сейчас, ну, ты говоришь про то, что
138: У нас получается, если роутер работает идеально, то он работает не хуже, чем мы. Я не понимаю, во первых, че было с роутером. Просто мне интересно, что было там условно с метриками баланса роутера.
139: Тогда поясни, что такое метрики баланса роутера.
140: Условно, в идеальном аешке есть какой-то баланс, что мы не направляем в отдельных экспертов, в отдельных экспертов слишком много токенов, потому что они вырождаются. Одни не учатся, другие учатся, если я правильно понимаю, что в схеме до того, как стали эксперты детерминированными
141: Учили то, что у вас просто есть какой-то общий пул экспертов, и роутер по ним раскидывает. Ну не совсем так. То есть у нас вот получается, в трансформерных слоях у нас есть типа thank, которая работает
142: На всю последовательность мы её сплитим по модальностям. То есть у нас по 1 не на каждую модальность. Соответственно, если модальности нет, ну она не работает. Вот.
143: Окей, ладно, хорошо. Если можно, сразу 2 вопрос. Говорили то, что есть до 700, по моему, событий для 1 пользователя это достаточно большой контекст, особенно для маленькой модели. Ну, 700 это за год. И, ну, конечно, их там можно найти y 1000.
144: Ну вот это среднее хорошо. А как такой, в принципе, немаленький контекст держит маленькая моделька? Вот вы демонстрировали до скейл, до 100000000 параметров, но были модельки и меньше что-нибудь делали специально для того, чтобы моделька контекст держала?
145: Или просто из коробки так его заводили и все работает. Не нужны никакие дополнительные методы. Что, например, чтоб контекст держала. Почему она не должна держать, не очень понимаю. Ну, обычно, если у вас там условно,
146: Там 8, 16, 32000 контекстов вы подаёте без, ну, условно говоря, чтобы моделька не выкидывала всю информацию из середины, какой-нибудь фильм применяют, но в обычных текстовых модельках. Ну, то, что ты, ты имеешь ввиду, что активный контекст, он не очень эффективный. Получается, что длинный, да, но не с точки зрени,
147: Не вычисления, а с точки зрения его применения, да, в эту сторону думали вот как раз в эксперименте там с патчами дня. Вот если если брать по дням, то кажется, что вот этот вот контекст, он типа, как-то борется вот с этой разреженностью.
148: Ну че то, че то специального в эту сферу, в эту сторону не делали. Спасибо.
149: Ребята, большое спасибо за доклад. Было очень интересно. Подскажите, я, конечно, понимаю, что это маловероятно, но как вы решаете проблему холодного старта, когда к вам приходит новый пользователь, например, как
150: Как-то как то точечно мы её, наверное не решаем. У нас очень много данных в банке. Вот. То есть у нас не только транзакции, у нас есть куча всего ещё, наверное, там не рискну сказать все, что у нас есть. Вот, но
151: Скорее, я думаю, я такие задачи не решаю. Вот я думаю, что в задачах холодного старта просто берётся какая-то статистика, там даётся что-то наиболее популярное, как рекомендация. Вот, но
152: Ну, наверное, не отвечу точно, просто потому что я этим не занимаюсь. Хорошо, тогда ещё 1 вопрос. Насколько долго у вас отвечает модель? Вот когда человек пришёл, например, в отделение Сбербанка, как быстро модель ему предсказания выдаёт?
153: Точнее, не ему, а, ну вот как раз, как я говорил в онлайн сценариях, у нас бустинги работают, они отвечают, там, если я не ошибаюсь, сл, у нас 200 миллисекунд 150 миллисекунд. То есть там в целом, из за того, что менеджер все равно как-то взаимодействует с клиентом, у нас там, по моему,
154: Весь ответ есть в районе секунды, то есть у нас не прям там хайлоу, но в целом где-то за 100 миллисекунд мы отвечаем, ну то есть, получается, фичи все предрассчитанному. Да, да, да. То есть у нас в рилтайме ретайм сторедже лежат все фичи, мы их подтянули в момент запроса.
155: Отдали в бустинг, получили скор, отдали обратно бизнесу. Он уже там как-то его применил. Угу. Хорошо, спасибо большое. Так, давайте, наверное, короткий вопрос. Ещё какой-нибудь. Успеем. Последний.
156: Вот скажите, у вас на 1 из слайде, там архитектура, где была показана, был указано дэнс? Нет, вот хотелось бы узнать, я вот недавно читал про использование
157: Нет, для обработки рентгенов в медицине. Ну и там, собственно, говорилось, что за 17 год сейчас уже и она, и тяжёлая, и не самая, ну, на тот момент так, передовая, но сейчас уже не самая, как бы, сказать так.
158: Продвинутая архитектура и так далее. Вот хотелось бы узнать, у вас как, то есть вы более такие современные или анализировали, или почему выбрали денет, если брать исходное
159: Dippin кросс нетворк. Саму статью от гугла там у них, я вот сейчас пытаюсь вспомнить, там-то ли реснет, то ii обычный просто mlp слой. При этом мы у себя увидели, что если просто mlp поменять опять же либо на реснет, либо денет, то модель чуть стабильнее сходится.
160: Чуть лучше метрики и просто история с денснетов более большую стабильность и более лучшие метрики пока что нам этого достаточно, там вопрос скорее, что если смотреть про что-то современное, у нас идеи скорее попробовать вместо dc.
161: Там что-нибудь, например, отметы типа вуконга какого-нибудь, который тоже решает задачу поиска информации между разными фичами. Вот если говорить про денснетов, то просто он решает задачу. Вот про оливки градиенты так же как нет, идея в целом тоже
162: Там такая же, только просто вместо резиду коннекта у нас расширение каждый раз какое-то увеличение эмбеддинга на выходе просто попробовали какую-то базу, она дала результат и вот que используем. Так ещё можно вопрос вот тоже там
163: Улучшение метрик 8/1000 стоит это 0 8%. Да, это и дальше где-то есть 1%. А вот вы сказали, что даёт это финансовый эффект достаточно большой. А можно как-нибудь, хотя бы
164: Порядок приблизительно вот 1% это в финансовом выражении. Ну хотя бы порядок, хотя бы порядок. Просто чтобы понимать, что да, там 8/1000 не зря старались. Это стоит этих денег.
165: Их там и так далее ну про деньги точно не могу сказать, вот могу сказать, что там на слайде было написано, что дисперсия че то типа 1 2 десятые процента, вот я бы расценил это просто как 4 sigma.
166: И кажется, что это стазначимость, и эти улучшения друг на друга наслаиваются, и в любом случае, там они ведут к каким-то значимым улучшениям, нет, а в финансовом выражении меня просто интересует, там на уровне 1000000, миллиард, там рублей. Ну, это, к сожалению, мы вам сказать не можем, потому что в какой-то момен,
167: Мы просто перестанем работать в Сбере, если мы это скажем. Но порядок цифр условно не миллионы, десятки миллионов. Дальше как бы, да, а в смысле больше, больше.
168: А дальше уже думает, кто как хочет.