0: Да, всем привет. Меня зовут Лёша. Я расскажу про поиск и про то, как можно его быстро или не очень быстро сделать. Давайте сначала небольшое отступление. Че мы вообще делаем? Кто? Кто мы вообще такие? Мы
1: В общем, занимаемся эмэлем в разделе в так называемых нефинансовых сервисах, то банка, то есть в разделе город, и там есть конкретно наш внутренний маркетплейс это shopping, и вот речь сейчас прежде всего пойдёт про поиск.
2: Именно внутри шоппинга, то есть про поиск по товарам. Короче, поиск, задача, которую решали достаточно давно и которую уже много людей, в принципе знают, как решать. Я думаю, что если у любого эмэль специалиста
3: Спросить примерно как строить поиск типа эмэль систем дизайн вопрос, то будет придумано что-то примерно вот такое, типа есть какая-то товарная база там с фидами, которые нам откуда-то приходят. Есть хранилка, это все как-то попадает.
4: Индексируется в оффлайне. Дальше есть некоторый ретривал как 1 этап поиска. Обычно там плюс минус, все подходы делятся на фуллтекст, фулл, текстовые либо векторные. Дальше, собственно, есть какая-то моделька финального ранжирования всего, что поднялось с ретривала. Ну и собственн.
5: Выдача. И на самом деле такой пайплайн в современных реалиях можно собрать, ну, наверное, недели за 2 вопрос, наверное, как, как это будет работать, насколько, какую нагрузку это будет выдерживать. Но сейчас там с агентами для кода это уже вообще
6: Не сложно первичное требование к поиску, которое, ну вот когда только начинаешь строить поиск, первичное требование это просто релевантность. То есть, чтобы, пожалуйста, выдавалось вот именно то, что пользователи ищут, какие сразу сходу именно в пайплайне екома возникают проблемы.
7: Такого подхода, наверное, самая 1 проблема, с которой сталкивается любой такой начинающий Строитель еком поиска. Это проблема смартфонов и Чехлов, Чехлов. Ну, например, айфонов. Всего там несколько сотен.
8: С учётом предложений от разных партнёров, это какие-то примерно такие порядки Чехлов, при этом просто дофига. И при этом чехлы, если мы смотрим на вот часть с ретривал, то есть на вот эту 2 синий квадрат,
9: Чехлы гораздо более часто сео оптимизированы, чем айфоны, потому что партнёры, которые продают айфоны, они, ну, как бы, это обычно достаточно крупные партнёры, либо селлеры, которые понимают, че они продают. Чехлов дох.
10: И они просто очень по разному написаны и часто лучше себя оптимизированы, чем айфоны. Поэтому 1 проблема, что ретривал ограничен каким-то размером. В итоге он нагребает, работает
11: Достаточно тупо часто в итоге он нагребает все, где написано айфон, и из за того, что Чехлов очень много, реальные айфоны туда могут не попасть, сделать ретривал глубоким, очевидно нельзя, потому что это уже влияет на latency и в принципе на скорость обработки что же?
12: Делать. На самом деле, самое простое решение, которое опять же, можно сделать там стройку, это mvp поиск, это элэл эмки. Ну, во первых, нам нужно эмэль ую модель сделать ранжирующей на релевантность. И это, собственно, и будет разметка, потому что с помощью эл эмок можн,
13: Генерить огромные датасеты, на самом деле с довольно хорошей точностью относительно Асессоров. Вот, и также для топ запросов можно добавить так называемые предрасчитанные выдачи. Это типа супер быстрое решение. Че это такое по сути, так как мы не можем ходить в ретривал
14: В онлайне с большой глубиной. Ну давайте тоже самое просто делать в оффлайне это как будто достаточно простое решение. И дальше мы просто фильтруем все, что он нашёл с помощью лэнки. И в оффлайне можно ходить в ретривал с какой угодно глубиной, то есть в
15: Каком-то вырожденном случае можно вообще доставать сразу всю базу, если она небольшая и просто под запрос скорить все, Эллэй зависит от доступного компьютера. Окей, это нам даёт примерно там 10% конверсии в покупку на
16: По сравнению с самым самой самой 1 версией поиска какая проблема вылезает следующая? Давайте поиграем в такую игру. Можно просто выкрикивать. Типа, как вы думаете, че не так с этими выдачами? Вот с левой и с правой картинкой? Какие
17: Основные проблемы здесь че, дубли, наверное, да, но на достаточно узком запросе типа iphone 17 про Макс показывать 1 товар тоже не очень, поэтому, наверное, слева.
18: Дубли это действительно проблема справа скорее нормально. Тут скорее нету дублей. Какие ещё?
19: Вот, да, это на самом деле следующая, основная проблема, которая вообще, типа, есть, на, с которой сталкивается человек, который делает поиск на маркетплейсе цена, потому что вообще то вот, вот эти товары стоят.
20: Вот эта электрическая мельница стоит 24000, это со скидкой, а без скидки она стоит 60. Я знаю не так много людей, которые готовы купить электрическую мельницу за 60 000 ₽ с айфонами примерно та же са.
21: С айфонами более интересная фигня, тут даже нарисованы стрелочки как подсказка по сути, тут самая основная проблема, что большинство людей, которые ищут айфон 17 про Макс, хотят именно версию на 256 гигабайт, потому что pro max круто, но большая.
22: Память, как правило, не нужна. Ну, настолько большая, мы показываем так как наш поиск настроен на релевантность, мы показываем, ну, типа, просто айфон. Вот просто потому что вот он так попал лучше, потому что эмэль так выучил. И в итоге мы показываем сначала айфон за 2
23: Терабайта его никто не покупает, и, как правило, пользователи, привыкшие к другим маркетплейсам, думают, что это означает, что у нас айфонов на 256 и нет. Соответственно, проблема, что теперь выдача в целом релевантная, но не конверсионная вообще.
24: И у нас появляется новое требование к поиску. Это конверсионность, собственно, то есть релевантность и конверсионность. На самом деле, то, что в поисковых приложениях это не то чтобы сонаправленные вообще метрики, они часто ортогональные, потому что релевантность это про то,
25: То, что показывать товары, которые просто соответствуют запросу. Ну и тут вроде это требование выполняется, да, то есть мельница, мельница, айфон, айфон, а конверсионность это про то, что мы хотим показать товары, которые с большей вероятностью купят по этому запросу.
26: То есть мы хотим ещё смотреть там на цену, на персонализацию и на, в общем, подобные вещи. Ну, решение очень простое. Давайте обучим модель на, на, сделаем, типа эмэль, ранжирование на конверсионность какой-то профит мы здесь получили, тут важно
27: Подчеркнуть, что мы на самом деле пробовали по разному вот эту часть схемки перерисовывать и по разному это решать, потому что, ну мы пробовали это засунуть в 1 модель, как-то блендить таргеты, скорить товары там одновременно и на релевантности.
28: Конверсионность, обучаться и на пользовательский сигнал, и на асессорские разметку лучше всего. Ну, по нашему, по крайней мере, опыту мы поняли, что это решается, когда мы решаем вообще 2 отдельных задачи, и это работает примерно так, что в начале есть фильтрующая модель на релевантность, потом
29: Она, собственно, отфильтровывает то, что ретривал поднял нерелевантного и оставляет типа только релевантное условно. И дальше скор вот этой модели идёт как фича в модель, которая уже занимается ранжированием чисто на конверсию. И вот именно такая связка по на
30: По крайней мере, экспериментом работает. Лучше всего с таргетом. То есть сначала фильтруем на релевантность, потом сортируем на конверсионность. Окей?
31: Че произошло дальше? В принципе, стало лучше, но проблема с конверсионность полностью не ушла на самом деле, потому что мы какой-то сигнал конверсионности прокинули только вот сюда. То есть только во
32: Пайплайна. Все, что происходит до этого, вообще ничего про конверсионность не знает и отсюда возникает, ну типа довольно понятная проблема, что ретривал нагребает что-то дальше, это что-то ранжируется.
33: Уже моделями, которые там знают про релевантность, конверсионность и так далее. И типа эмэль работает, но по факту происходит так, что на каких-то Широких и не очень популярных запросах, например, турка. Турок у нас очень много, но
34: При этом их не то чтобы очень часто ищут, это не попадает, например, в предрасчитанные. И, ну, где там много релевантного ассортимента, выдача забита, во первых, либо однотипными товарами, либо просто, типа не очень конверсионными.
35: Товарами, потому что вот здесь, например, одинаковые турки, нету Турок от каких-то топовых производителей. Это все супер какой-то кустарная история. Поэтому лучше это диверсифицировать, потому что разным пользователям нужно разное решение на самом
36: Деле 2 2 вещи. Это эмэль модель на ретривал и диверсификация. Нам нужно научиться прокидывать сигнал конверсионности товара хотя бы в каком-то виде на ретривал. И на самом деле, если использовать довольно лёгкие фичи, то
37: Это можно делать на ретривал, потому что у товара есть какие-то типа абсолютные метрики, там, ситиары, сиары в покупку и так далее. И диверсификация. Диверсификация тоже супер. Важно для того, чтобы предлагать пользователю как бы разный ассортимент и смотреть, че ему
38: Понравится, потому что товаров достаточно много, запросов достаточно много. Диверсификацию, ну, облегчённую эмэль модель на конверсионность мы сделали прямо на этапе ретривела, благо большинство, наверное, современных, по крайней мере, полнотекстовых ретривал, в позволяют это делать.
39: Типа опен серч, ластик и все вот это вот дальше мы сделали 2 диверсификации на уровне ретривала. Мы сделали мэмар диверсификацию достаточно классическую на уровне дальше на самом деле эмар диверсификация
40: Уровне ретривела, работает норм, но это иногда не даёт диверсификации уже вот здесь на выдаче и поэтому её нужно делать как бы в 2 местах. Причём опять же экспериментами мы поняли, что перед самой уже выдачей
41: Лучше всего работает диверсификация по тупым правилам без всяких умных алгоритмов, типа не более икс товаров подряд. И это типа норм. Вот. И здесь мы тоже получили какой-то положительный зелёный прокрас на б. То есть в принципе вроде как делаем что-то
42: Достаточно, достаточно. Правильно, достаточно хорошо. Окей. Че дальше? Дальше мы начали сталкиваться с проблемами, которые нас привели на самом деле к тому, что у поиска есть ещё 1 стадия, то есть есть ретри.
43: Есть, собственно, все, что происходит после ретривела, там с эмэль модельками и так далее. Но вот, вот, вот ту, ту часть мы пока что не трогали вообще, и это начало стрелять.
44: Во первых, есть запросы с нетривиальным описанием. Например, смартфон, камерафон. Скажут, что да, ну, можно сказать, что типа, есть векторный поиск, и он должен, по идее, такие кейсы решать, но по нашему опыту, эмбеде, кото
45: Который обучается на все-таки на более простых примерах. Чаще он по умолчанию скорее не понимает, что смартфон, камерафон это на самом деле какие-то характеристики из атрибутов смартфона, а смартфон, камерафон в тайтле пишут единиц.
46: Наверное, типа мерчантов, особенно если мы возьмём какие-то большие крупные якомы. Вот. И 2 проблема, тоже связанная. Вот Ровно с этим же мы просто эти проблемы, они на самом деле отдельные, но решаются 1 и тем же.
47: Это то, что в топ выдачи начинают попадать партнёры не с хорошими товарами по сути, а скорее с хорошо заполненными и сео оптимизированными фидами. То есть следующая проблема, с которой мы столкнулись, это по сут.
48: Отсутствие каких-то ключевиков и проблема с её оптимизацией глобально то, что в топ выдачи попадают партнёры, опять же из за ретривала попадают партнёры, не которые хорошие по сути, а у которых просто крутые фиды, а крутые фиды сделать проще.
49: Чем, ну, как бы хороший товар. Вот, поэтому следующее. И вот это уже решалось чуть менее тривиально. На самом деле, следующее, че мы сделали? Мы, ну, нашей задачей было уравнять фиды, чтобы
50: Партнёр с хорошей сео оптимизацией, но не конверсионными товарами не получал преимущества. Есть наша задача показать пользователю самое как бы лучшее, что у нас есть, что он с наибольшей вероятностью купит. Поэтому мы, ну, это было как бы задач.
51: Работы именно с фидами. То есть задача, которая по хорошему должна решаться на этапе индексации. Следовательно, тут есть 2 решения, которые на самом деле, они примерно про 1 и тоже, но мы их делали параллельно и все-таки воспринимаем как 2, 2 отдельных, 1.
52: Это то, что мы вообще выбросили партнёрский фит, в итоге и сделали так, что моделька на него даже практически не смотрит и вместо этого мы полностью его перегенерирует по нашей модельке и одинаковым правилам с помощью lm, то есть мы все разнообразные данные от партнёров.
53: Но на самом деле, это был отдельный большой проект, который занял, ну, наверное, примерно месяцев 6, 9. Вот, потому что данные очень разные, естественно, лмки галлюцинируют. Тут приходилось также привлекать людей Асессоров, поэтому
54: Ну, собственно, такая история, и да, и отдельными процесс процессами мы там выделяем категорию, заполняем те атрибуты по нашей инфомоделирования ны. И это тоже влияет на поиск. И 2, что мы сделали, это сдела
55: Так называемые лэм квери. Это когда мы делаем отдельное поле, которое генерируется, по сути, таким образом, то, что мы просто показываем лмке все, что мы знаем про товар и говорим, как ты думаешь, по
56: Каким запросом было бы логично искать этот товар, по каким запросам этот товар должен вообще находиться. На самом деле это работает чуть чуть сложнее. У нас примерно вот такой вот пайплайн, где лмка по очереди смотрит на все поля и пытается
57: Из каждого поля выделить какую-то сущность и смачить, возможно на какие-то запросы. Вот тут наверное супер глубоко не буду рассказывать, но если кратко, то этот пайплайн как бы достаточно мно
58: Много компьютер сжирает и много вызовов лмки стоит. Но хорошо, что это делается только 1 раз на этапе собственно, индексации товара. Вот, и мы, соответственно, свои предрассчитанный выдачи с с лэмками, которые были сделаны нами на
59: Шаги 1 мы заменили как раз вот на этот пайплайн, где мы, по сути, просто перерабатываем контент, который идёт к нам на вход и делаем его унифицированным. Вот, и это дало на самом деле довольно большой прокрас, практически 8% конве.
60: Покупку на аб. То есть это зарешало какой-то очень тяжёлый хвост кейсов, где поиск работал плохо, либо показывал не конверсионные товары из за вот этой проблемы с партнёрскими фидами.
61: Изначальный. Что дальше? Давайте снова поиграем в эту игру. Как вы думаете, че не так с этими выдачами? Вопрос? Ну типа, на самом деле ответ уже сильно менее тривиальный. Может быть у кого-то есть
62: Какие-то предположения, если че, я не надеюсь, что вы угадаете.
63: Нет, ну ладно, окей. На самом деле есть 2 проблемы, которые уже вообще не видны по выдаче, и они не видны пользователю, они видны на самом деле только, только уже нам. Во первых, это то, что в топе появляются това.
64: Товары с плохой для нас экономикой, но это и невозможно было угадать. Ну то есть это низкий тейк, рейт, нет рекламного продвижения и какие-то товары, которые в целом мы, ну, товары, например, там не фокусных партнёров, где-то, и ещё 1 очень
65: Большая проблема это то, что некоторые партнёры, в частности, новые вообще не попадают в выдачу. И в итоге это приводит к тому, что мы просто не развиваемся как маркетплейс, потому что мы даём мало трафика новым партнёрам. Это прям очень большая проблема, и это при
66: Вводит нас к собственно, ещё какому-то ряду требований к поиску. То есть если до этого у нас была просто релевантность, то есть тупо показывать то, что пользователь попросил. Потом у нас добавилась конверсионность. Это требование показывать товары, которые с большей вероятностью ку
67: И дальше у нас появляется ещё 2 важных истории 1 это экономика, то есть при прочих равных мы хотим показывать товары с хорошей для нас комиссией и explore explore.
68: Это, по сути, требование к поиску, что новые партнёры должны достаточно быстро набирать статистику и gmv, иначе они просто, ну так как у нас площадка, которая мы сейчас много активно подключаем партнёров.
69: Это прям большой блокер развития в целом площадки, потому что если они не получают быстрый какой-то эффект, они, как правило, просто уходят, либо начинают несерьёзно относиться. Вот решение. 1 решение, которое мы сделали, это busta, по сути.
70: Мы просто сделали взвешенную сумму некоторых факторов, где мы к базовому эмэль скору конверсионной модельки прибавляем какие-то, в общем, добавки, которые зависят от рекламного продвижения, от собственно тейк рейта и от эксплора.
71: Это, по идее, должно как раз решить 3 проблемы. Это, собственно, проблема того, что не работает рекламное продвижение. Проблема того, что товары, которые мы продаём в топе, экономически невыгодны, либо, типа, не настолько выгодны как-то, что otherwise, мы могли бы показать.
72: И, собственно, эксплор это то, что новые партнёры не получают трафика, либо получают мало трафика. Но это довольно известная проблема в целом. Вот, и, собственно,
73: Эти. Вся логика бустинга встроена после собственно, эмэль ранжирования. Когда мы получили уже товары, мы каким-то образом там портим выдачу бустингом для того, чтобы больше зарабатывать, и для того, чтобы новые партнёры в нас
74: Не разочаровывались.
75: Но аботе серый, это не то чтобы решило проблему, то есть мы, казалось бы, вот там все, все это сделали и в итоге это, ну, практически, в общем то, ничего и не дало. Почему так?
76: На самом деле проблема, ну, это типичная проблема в поиске, что что-то делается на финальном этапе, но мы забываем про вот эти все этапы, которые идут до, опять же, ретривал ничего не знает ни про экономику, ни про рекламу и поднимает просто какие-то товары, которые
77: Вот, ну, захотел поднять по соображениям конверсионности, релевантности. Соответственно, нужно опять эту проблему фиксить на этапе чуть чуть раньше. И в итоге мы сделали вот такую штуку.
78: Что, что, что это такое? Мы просто разделили ретривы и, по сути, сделали для каждого, для каждой категории товаров, которые мы хотели бы видеть в топе выдачи, мы сделали отдельный ретривал. Если мы хотим партнёров с высо.
79: Take рейтом мы делаем, мы определяем, что такое партнёр с высоким тейк рейтом, но это довольно просто. И, собственно, делаем, делаем отдельный движок, который работает только на них.
80: Тоже самое для рекламных партнёров. Тоже самое для новых партнёров. В общем, ну и сохраняется какой-то общий ретривал, который типа для всех остальных, которые не попали в другие группы. Вот эта штука единственное, что она нам даёт, как бы my
81: Минус по конверсии, но зато она нам даёт огромный буст выручки, поиска, ну и минус по конверсии, учитывая все предыдущие положительные абки, в принципе, уже не настолько существенный. Вот, соответственно, и дальше важно, что вот на
82: Вот этом этапе после ретривала, но до фильтрующей мы балансируем в зависимости от того, че мы сейчас хотим от поиска. В данный момент мы балансируем как бы то, из чего у нас наполняется выдача. То есть мы можем у каждого ретривала есть максимум, сколько он может товаров нагрести.
83: И вот этими максимумами мы по сути, контролируем, типа, че мы вообще сейчас хотим больший фокус на партнёров с высоким тейк рейтом, на каких-нибудь, на какую-то отдельную группу партнёров больше фокус на рекламу либо больше фокус просто на базовое качество.
84: Ну и дальше у нас возникла новая проблема, которая уже с нами, скорее всего, будет всегда. Это просто проблема управления трафиком, казалось бы, куртка. Ну, ну, куртка вроде все нормально, но возника
85: Опять много вопросов почему в категории там x так мало партнёра игрек партнёр стал неприоритетным, нужно его убрать, но так, чтобы если этот ассортимент есть только у него, он все равно искался, но по запросам, где ассортимент есть не только у этого партнёра.
86: Чтобы его не показывать. Есть, допустим, какой-то партнёр с супер крутым товаром. По мнению просто там категорийного менеджера, который, как правило, совпадает с реальностью, и он просто не попадает в топ выдачи. Почему пофиксите опять
87: Ничего не ищется. Ну, тоже самое, например, вот с сезонными товарами. То есть проблема вот этого запроса конкретно в том, что этот запрос был сделан недавно. Ну, то есть летом, и мы показываем тут, как бы, ну, не совсем летнюю куртку, что
88: На самом деле, наверное, как-то плохо влияет на конверсию. Скорее всего. Вот. Ну и, собственно, дальше эту проблему уже решать. Наверное, тут нет каких-то супер простых решений, потому что это не 1 проблема, это скорее некоторый
89: Набор в целом проблем и инструментов управления. И на самом деле тут в качестве такого это даже не то чтобы решения, это скорее прокси к решению мы вводим просто более сложную оффлайн метрику.
90: В чем суть офлайн позволяет даже не только в поиске тут скорее в принципе в любом подобном мельном проекте офлайн позволяет быстро находить точки роста раньше наша оффлайн метрика выглядела как просто ndc джи, ну там.
91: Релевантные энди сиджи кликовые ndc джи скорее всего, если вы будете проходить эмэль систем дизайн по поиску, это и будут примерно первые метрики, которые вы предложите типа оффлайн метрика поиска ну ndc джи либо какая-то другая метрика ранжирования, но смысл в том.
92: То, что её можно считать 2 способами по релевантности и по кликам, по пользовательскому сигналу.
93: По факту мы поняли, что от нас требуется гораздо больше и гораздо более, что наша оффлайн метрика должна быть гораздо более сложной, потому что помимо просто релевантности и просто конверсии, теперь есть ещё куча условий, которые, которым мы должны соответ
94: Как поиск для того, чтобы не расстраивать партнёрами партнёров, быть экономически выгодными, экономически положительными и, собственно в целом, в общем, соблюдать какие-то критерии.
95: Довольно сложные, которые иногда ещё и меняются. И сейчас наша оффлайн метрика это по сути, вот такой вот набор графиков различных, на которые мы смотрим, которые ещё можно смотреть в разных срезах. Ну и для того, чтобы все-таки ориентироваться на 1 цифру, чтобы не потеряться в этом многообразии гра.
96: Мы ввели какую-то примерно формулу, которая нам позволяет понимать вообще, насколько хорошо работает наш поиск и прикол в том, что релевантность занимает только 40%. И это типа нормально коррелирует с результа.
97: А вот все остальное, это доля просто каких-то вещей, которых от нас хочет бизнес и которые реально положительно влияют именно на бизнес, на экономику и на впечатления пользователя. Вот. Ну и в общем,
98: По итогам всех вот этих манипуляций, по итогам всех этих действий мы ввели такую штуку, как меморандум. Поиск. На самом деле это относится, скорее всего, не только к поиску к любому в целом, Такому статистическому мельному проекту, самое
99: Статистическая фича должна быть подкреплена, а он работает супер. Вот. То есть любая наша фича должна быть подкреплена офлайн и онлайн метриками, которые мониторят
100: Что вот именно эта фича работает хорошо, и договорённость с заказчиком должна звучать не в формате, что, ну, мы сделаем вот круто, что вы хотели, а в формате то, что вот мы построили такую метрику сейчас она вот столько должна стать, вот столько и
101: Тогда это работает, потому что иначе возникает куча проблем и разрыва ожиданий. Дальше мы даём заказчикам инструменты управления трафиком и но при этом сохраняем контроль над выдачей. Ну то есть банально
102: Правило доверяй, но проверяй, если партнёр что-то хочет поменять в выдаче. Окей, мы меняем. Но при этом, если мы видим по опять же офлайн и онлайн метрикам, что это что-то сильно просаживает, то мы, собственно, имеем возможность это выключить.
103: И дальше 3 и 4 правило. На самом деле, примерно про 1 и то g4, скорее про то, что нужно регулярно смотреть вообще глазами и быть пользователями своего продукта. Без этого очень сложно находить точки роста в ml ом продукте. То есть когд.
104: Наш продукт для нас это просто набор там цифр и метрик. Очень часто происходит такое, что в этих цифрах и метриках мы теряемся и мы не понимаем, че вообще надо пользователю в итоге, что чувствует пользователь. Поэтому важно, ну, как бы регулярно смотреть и пользоваться как
105: Кажется, мысль достаточно очевидна, но многие на самом деле команды её пропускают. И 3 правило это такое контр, контр правило к 4, что при этом максимум 20% бэклога должны быть заполнены эдхок решениями. Все остальное это какие-то системны.
106: Фиксы, потому что если пользоваться своим продуктом очень быстро, можно скатиться в то, что мы фиксим какие-то несуществующие проблемы, которые работают там на 0 0 точка 1 проценте трафика. И, ну мы
107: Просто начинаем улучшать воздух и поэтому нам нужно искать именно системные проблемы, оценивать их масштаб и на какую-то вот такую отхок штуку типа давайте полечим конкретно этот запрос мы стараемся выделять не больше 20% бэклога ну и
108: 5 это типа иметь это скорее такое уже более политическая история иметь стабильный канал поддержки и дежурных, которые могут ответить на вопрос, почему выдача именно такая, так как поиск это основной канал распределения трафика распределения gmv всегда.
109: Есть люди, которые не очень то и довольны и считают, что трафик или gmv было распределено как-то неоптимально или не так, как им хотелось бы, или не так, как нужно, поэтому важно иметь просто стабильный канал поддержки для того, чтобы очень быстро.
110: Такие вопросы обрабатывать, отвечать на них и оттуда также генерить. В общем, проблемы, которые можно дальше решить, улучшив поиск. Вот на этом у меня все. Всем большое спасибо и жду ваших вопросов.
111: Тогда, Лёша, спасибо большое за доклад. Так мы сразу начнём с вопросов.
112: Здравствуйте. Так работает. Раз, раз, да, да, меня Алексей зовут, Алексей Печёнкин. Слушайте, ну, 2 55. Вот, конечно, очень хочется посмотреть на цифры, которые абсолютные маунт.
113: Потому что, ну 2% gmv в поисковой выдачи 55% выручки это ну могут быть совершенно разные вещи рекламная выручка, например, заландо это 2% от gm. Ви, ну то есть типа это окей.
114: Вот у меня вопрос такой вот вы покрасили выдачу брендовых запросов, кстати как вы это сделали рекламой, вот потому что бренд adidas и бренд найк после этого к вам придёт с вилами и скажет почему вы на моём
115: Брендовом запросе поставили рекламу другого бренда. Это интересный вопрос. Вот. A2, вот Селлер, после того, как вы сделаете вот такое перераспределение, абсолютно точно напишет вам, что вы покрасили его органику в рекла.
116: Anna деньги и я хочу чтоб вы мне это как-то объяснили или вернули и ладно, черт с ним, что он вам это напишет, он напишет об этом форуме в каждом теллеграм, посте и так далее и тому подобное. Вот интересно как вы собираетесь с этим работать?
117: Ща, то есть ещё раз вопрос в том, что мы сильно прокрасили как бы выручку поиска на самом деле не только не только и не столько за счёт рекламы тут важно это подчеркнуть, потому что это скорее просто за то, что мы
118: Показываем при прочих равных. То есть очень важно, что вот на вот этом слайде была история про экономику, именно про то, что мы должны при прочих равных показывать товары с хорошей для нас комиссией или
119: Платным продвижением. То есть условно, если отвечать на 1 часть вопроса про бренды, то такого скорее, наверное, не должно происходить, что по запросу night у нас показывается адидас, мы тогда нарушаем буквально 2/1 правила, вот, и
120: Ну даже если, допустим, по какой-то причине адидас нам продавать сильно выгоднее, то экономика это как бы уже правило 3 приоритета, потому что тут на самом деле это все отсортировано достаточно-таки в порядке приоритета. Вот. Ну и 2, что
121: С партнёрами. Ну, на самом деле, вот, вот эта проблема, которую я говорю дальше, вот то, то, что 2 часть вопроса про партнёров, это в некотором смысле как раз следствие вот такого мува, потому что, ну, ну, да.
122: Естественно, мы как бы улучшили свою выручку, покрасили свою выручку таким тестом, естественно, появились и партнёры, и там k аккаунт менеджеры этих партнёров, которые супер недовольны что теперь, после такого?
123: У нас там этого партнёра стало меньше или больше, по сути, системно сейчас, по крайней мере. Ну то есть это какая-то проблема на самом деле, и в поиске, и в рекомендациях, которая в целом всегда существует, то, что как-то мы не так что-то распределили. Вот по сути, мы хотим систе.
124: Это решать как раз-таки вот этой историей с ретривала и как бы с разными ретривала и и нагребания, и разных товаров. Возможно в итоге это сведётся вообще к тому, что у нас под каждого партнёра будет отдельный ретривал. Возможно вопрос просто, ну, скорее, хватит ли компьютер
125: На такую штуку. Вот. Ну, собственно, да, и поэтому, то есть ответ такой, что базово мы это решаем инструментами управления трафиком, а инструментов управления трафиком, трафиком. У нас, по сути, 2 это логика, собственно,
126: Бустинга и подкидывания, и разные ретривала и нагребание из них. Вот собственно, как-то так.
127: Спасибо за интересный доклад. Вопрос не мельный от имельщик. Все замечательно вот в этой схеме, но здесь нет. И вы в своём докладе все время говорили о 2 интересах, об интересах партнёра.
128: И об интересах вашего маркетплейса хотел бы задать, а пользователей. Вот я как раз про пользователя, собственно говоря, если пользователь, где в этой схеме жёсткие ограничения, которые задаёт пользователь, например, если я выставляю жёсткую сортировку по цене минимальной
129: Цена. И здесь не показано, каким образом будет выгребаться. Собственно говоря, минимальная штука или жёсткое ограничение по провайдеру, ну, по поставщику. Угу. Спасибо. Да, да, да. Ну, жёсткое ограничение по поставщику решается на самом деле достаточно
130: Просто на уровне просто ретривала, ну то есть
131: Да, да, почему? Да, то есть вы же сталкиваетесь, ну, по совершенно простым вещам, вы там всегда, вы будете выбирать, хоть вы здесь десятки распараллельте, допустим, первые топ 5, и туда не попадёт самый дешёвый товар, например. А я хочу там самую дешёвую кофе.
132: Вари, вы здесь попадаете либо на большой компьютер и для того, чтобы сохранить мои интересы как пользователя, либо вы тогда пренебрегаете моими интересами и вообще показываете мне где-нибудь медианную или среднюю цену. Ну, потому что да, там, собственно,
133: Вы пожалели компьютер? Да, да, да. Вот. На самом деле вопрос очень хороший. По партнёрам, по партне. Я почему специально сначала отвечаю про партнёров, а потом про цену, потому что с ценой это, ну, короче, пришлось много экспериментировать, скажем это так, чтобы получит
134: Получилось как-то нормально отсортировать и выдать запрос типа пользовательский типа дай мне самую дешёвую цену на релевантный товар.
135: Да, да, да. Вот. Ну, вообще фильтры там партнёрские, либо атрибутные фильтры, они, как правило, нормально работают на уровне просто ретривала и все текущие движки ретривала, типа опен серч и ластик, они позволяют достаточно без проблем это фильтровать.
136: Единственная проблема это когда фильтр, допустим, это когда мультифильтр, там приходится делать множественный индекс, но в целом как бы на какие-то частотные, на самом деле пользователей, которые прям супер активно пользуются фильтрами и выстраивают какие-то большие большие цепочки запросов с кучей фильтров. Их не так много.
137: Поэтому это проблема, как бы, с которой, ну то есть имеется ввиду пользователи, которые одновременно тыкают типа 10 фильтров. Вот такого скорее не происходит. Это происходит там в каких-то Десятых долях процента случаев. Вот, а то, что касается цены на
138: Извините, я дополню, я как, может быть, в качестве добавки сейчас самый популярный запрос в алисе. Найди мне самое дешёвое с жёлтеньким пластиком, типа того, где человек как раз вот выстраивает вот этот мультифильтр, да, а так как у яндекса, вы знаете, есть
139: Специальный сервис, который грабит все ценки, цены, да, то там они как-то решают этот вопрос. И вот, вот мой вопрос из, да, конкурентной среды. Вот, вот теперь, если говорить про цену, цена, да, вот фильтром именно по цене, но это не фильтр, точнее
140: А сортировка по цене вот этим пользуются довольно часто. И тут возникает действительно 2 проблемы. 1 это типа как нагрести правильно. И 2, это как показать релевантный товар с самой низкой ценой.
141: Потому что если просто всю выдачу отсортировать, там будет внизу что-то нерелевантное, опять же, всплыет проблема там айфонов и Чехлов, да, и в результате, что мы сделали, во первых, как мы решаем проблему на ретривал, у нас
142: Есть буквально матчинг, который позволяет товары с, ну, короче, склеивать товары и на моменте ретривала у нас все склеенные на этот товар товары, возможно, у которых ниже более низкая цена, просто к нему подклеивают.
143: Вот, и это нам позволяет поднимать как бы не 1 товар, а сразу всю группу товаров, при этом компьюта там ну меньше вот. Ну то есть это влияет на compute на следующих стадиях, но не на этапе ретривала, а то, что касается цены дальше у нас на самом
144: Есть фильтрующая на релевантность эмэль модель, и у неё есть 2 порога. 1 порог это порог попадания в целом в выдачу, порог по релевантности, a2 порог это как раз порог попадания в выдачу с сортировкой по цене, потому что в топе, ну, вся выдача.
145: Это у нас там, например, я не знаю, 1000 товаров, естественно, если там человек ищет самый дешёвый айфон, ну, во первых, он у нас по умолчанию должен быть на 1 позиции, потому что, как бы они отличаются во многом часто только ценой, потому что все знают, че такое, ну, там, ценой и характеристиками, да, вот.
146: Но если, допустим, человек ищет самый дешёвый смартфон в целом, то наша задача отрезать все смартфоны от Чехлов и, собственно, потом их отсортировать. Поэтому фильтру мы просто ставим более, если пользователь нажимает на сортировку по цене.
147: Мы ставим, во первых, у нас, ну, срабатывает вот эта логика на ретривал, а потом мы ставим более жёсткий порог, фильтрующий, потому что, по сути, когда человек фильтрует, по точнее, сортирует по цене, вот эту всю часть можно закрыть. То есть, работает только вот, вот, вот до этого момента, вот.
148: Соответственно, мы просто делаем очень жёсткий порог на фильтрующее. Вот это все убираем и просто сортируем по цене. Как-то так.
149: Ну да, в зависимости от фильтров он ветвится. Ну, потому что странно, когда пользователь попросил сделать дешевле, ну, типа, отсортировать по цене, странно не сортировать по цене строго. Вот.
150: Спасибо большое за доклад. Было очень интересно. Вот у меня 2 вопроса. 1 зелёненький квадратик. Вот вы говорите, что релевантность это очень просто, но на самом деле, вот как вы бизнесово определяете, что такое релевантность и что она подходит бизнесу.
151: Я, наверное, в своём докладе говорю про релевантность как про какое-то абсолютное понятие, которое может быть не скоррелировано вообще никак с бизнесом. То есть релевантность это скорее интерес как раз-таки пользователя, ну то есть
152: Что вот что этот товар подходит под запрос, на самом деле, на именно на екомных запросах это делается в целом не так сложно. То есть есть не короче, мы это решаем за счёт того, то, что мы периодически проводим разметки категорийными
153: Командами, то есть просим буквально людей, которые отвечают за какой-то конкретный бизнес и очень хорошо разбираются в какой-то конкретной категории товаров, разметить на релевантность. Дальше смотрим, насколько это коррелировано с людьми. Типа следующий этап это асессоры и уже следующий
154: Этап это лмка. Ну, понятно, что 1 совсем не масштабируемо, 2 ограниченно масштабируемое ллма сейчас, ну, сильно масштабируема. Вот. И таким образом, мы, собственно, пытаемся прорастить сигнал от бизнес заказчиков через Асессоров в лмку мне просто кажется, вот
155: Куртки летние, допустим, можно через релевантность решить. Типа, летом рел плюсы это летние куртки, там тема реел, это какие-то зимние куртки. Ну, кстати, спасибо за идею, наверное, наверное. Да. И 2, вот вы говорите, что накрути.
156: Большую какую-то оффлайн метрику, но типичный мельчик, он как делает, я накрутил оффлайн метрику. Давайте за неё под неё обучимся и пайплайн оптимизируем. Ну короче, типа, может быть не только на релевантность надо обучаться, а там сесть с продуктовыми аналитиками, подумать во
157: Про какую-то сложную метрику и её оптимизировать, чем вот кучу вот накручивать каких-то бизнес. Логик имеется ввиду засунуть, короче, нашу новую оффлайн метрику прям в target модели может быть не
158: Её полностью может не все решиться, но какую-то часть, типа не только релевантность, а как-то усложнить, да, вот, вот это мы, короче это буквально наш следующий эксперимент, который мы хотим сделать. Вот. И, ну вот это кстати, очень ну в общем, я
159: К этому отношусь, типа, что 60 на 40 где-то получится, если честно, потому что
160: Там, там очень много правил, да, они не все могут быть в итоге, ну, если мы прям в лос это засунем, там не все может быть дифференцируемо, нормально. Ну, типа, ну, может быть, как to gain. Ну, короче, можно, наверное, в Гейн это как-то засунуть. В общем, там надо просто подумать, как эт.
161: Это правильно сделать. И, наверное, ну тогда мы повысим зависимость модели от оффлайн метрики. Мы буквально будем обучаться под оффлайн метрику. И это может разорвать цикл, что как бы оффлайн метрика, она все-таки больше
162: Создано для поиска проблем, а тут мы пытаемся как бы решить проблему инструментом для поиска проблемы. Вот непонятно, короче, не будет ли там каких-то прикольных фидбэк Лупов, когда мы сделаем вакуумную метрику, которая плохо будет в итоге.
163: С пользователем обучимся под неё и получим ещё хуже результат.