Поиск в глубину: какие инструменты помогают работать поиску в Uzum Market

Всем привет! 

Меня зовут Дмитрий Шипилов, с вами команда поиска Uzum Market.

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

Но хороший поиск — это не только правильное ранжирование и мощная retrieval-часть. Хороший поиск — это набор различных инструментов и компонентов, собранных в сложную систему.  Поэтому в этой статье вы узнаете о важных вещах, без которых наш поиск не может обойтись, в том числе: как мы помогли опечаточнику понимать контекст нашего маркетплейса, почему безобидные синонимы могут привести к неожиданным эффектам, в каких случаях важно сужать количество товаров и как построить устойчивую LLM-систему для оценки качества ранжирования. 

Сервис ранжирования и инфраструктура

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

Сервис принимает модели в ONNX-формате, а это значит, что при необходимости можно добавить в граф дополнительные вычисления. Фичи для ранжирования мы собираем с помощью Airflow через Spark. В Airflow реализованы другие ежедневные процессы: мониторинги для отслеживания фичей и параметров модели, ежедневная разметка выдач. Все значимые изменения мы пропускаем через А/В-тесты, в рамках теста смотрим на различные поисковые метрики (например: конверсии в корзину и заказ), а также отслеживаем глобальные метрики всего маркетплейса.

Что под капотом на самом деле 

Как видно на схеме, наш ранжирующий механизм работает далеко не в первую очередь — ваш запрос, конечно, достигнет индекса Elastic, но сначала необходимо понять, а нет ли в запросе опечатки и, если она есть, исправить её. 

С этим нам помогает отдельный сервис — «опечаточник» (aka speller). 

Учитываем контекст для качества исправлений

Почему вообще важно учитывать, есть ли в запросе опечатки? 

Представим, что к нам пришёл запрос «щина» (буквы рядом, и такую опечатку допустить очень легко), это вызовет проблемы на этапе retrieval, потому что товаров с таким названием у нас нет. Будут проблемы и на этапе ранжирования, когда мы попытаемся посчитать какие-либо признаки на основе текстовой близости. В первом случае мы ещё можем попробовать «полечить» проблему с помощью векторного поиска (сразу скажу, в наших случаях это сработало не очень), а вот второй кейс можно исправить только с помощью опечаточника. 

Если исключить (пока) экзотичные варианты, которые работают на основе нейронных сетей и LLM, то можно сказать, что большинство опечаточников работают по следующей схеме: сначала мы пытаемся понять, есть ли в конкретном слове опечатка, потом подбираем подходящих кандидатов из словаря возможных замен, ранжируем их и возвращаем самого подходящего. 

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

Мы обучали наш словарь замен на следующих данных Uzum (учитываются и русские, и узбекские языки): 

• названия всех карточек товаров

• синонимы из списка синонимов 

• название фильтров 

• названия категорий 

Вот пример сэмпла из нашего датасета для обучения:

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

Сразу можно отметить пару проблем: 

1. Описания товаров, которые пишут продавцы, не идеальные, в них могут быть опечатки, значит, словарь замен получается шумным

2. Наша система строится на исключительно текстовых фичах и не рассматривает контекст более широко и ничего не знает о внешнем контексте. В итоге копятся неочевидные кейсы. Как пример: исходное слово «стуль», исправилось на «сталь», а не «стул», ведь с точки зрения ранкера, основанного только на текстовых признаках, эти два исправления одинаковы по правильности.

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

Для сбора датасета для обучения и оценки мы взяли историю запросов в наш поиск и того, что выдавал опечаточник «без контекста». Разметили эту выборку с помощью асессоров, разбив всё на несколько классов: 

1. опечатка была, и мы её исправили правильно

2. опечатка была, и мы её пропустили

3. опечатки не было и мы правильно ничего не поменяли 

4. опечатки не было, а мы попытались что-то исправить

В целом это похоже на классическую confusion matrix с ее True Positive/False Positive/etc-ячейками. Понятно, что мы хотим лучше исправлять кейсы из класса 1 и 3, и желательно, чтобы кейсы из класса 4 переходили в класс 3. 

Имея размеченные примеры из разных классов, мы сгенерировали выборку для обучения: достали различные варианты исправлений для наших размеченных ключевых слов и отметили «правильные» варианты из разметки. 

Как и в feature engineering, для любой ML-модели здесь можно придумать много признаков, в том числе и оконных, например, чтобы отслеживать какие-то быстрые тренды, которые недавно появились на рынке (помните бум на лабуб? Вот). 

Мы добавили несколько дополнительных фичей для самого запроса: как часто запрос вводили за последние дни, сколько было событий покупки, сколько добавлений в корзину, какая конверсия по запросу. Важный момент — текстовые признаки тоже надо взять, иначе модель будет пытаться исправить фразу на конверсионную, но далёкую (по расстоянию Левенштейна) от той, что вводит пользователь. Это видно, если взглянуть на топ итоговых фичей нашей модели (по shap values): 

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

В течение эксперимента целевая метрика конверсии в заказ прокрасилась достаточно уверенно (+1% роста), и мы раскатили ранжирование в опечаточнике на всех пользователей. 

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

Подсказки 

Итак, с опечатками разобрались, однако у нас есть ещё один инструмент, который может помочь и пользователю, и поиску: это подсказки. 

Есть несколько видов подсказок, которые мы комбинируем: 

• Товарные подсказки: пользователь нажимает на поле ввода запроса, мы показываем набор товаров. 

• Категорийные подсказки: по тому, что вводит пользователь, мы пытаемся найти подходящую категорию и показать ему её

• Текстовые подсказки: можем показывать различные варианты ключевого слова, которые изменяются в зависимости от введенного в поисковую строку префикса. Про эволюцию этого варианта расскажем далее 

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

Первую итерацию системы подсказок мы реализовали с помощью индексов подсказок внутри Elastic. У нас есть отдельный индекс на каждый из возможных вариантов подсказок — товарный, категорийный, текстовый. 

Текстовый корпус мы глобально обновляем каждый месяц, для этого собираем популярные названия товаров за месяц (на основе статистики продаж) и популярные запросы. 

После этого проводим их обработку: 

• убираем опечатки; 

• фильтруем стоп-слова и нецензурную лексику;

• выполняем стандартные преобразование по типу lowercase, фильтруем дубликаты;

• ограничиваем длинные фразы до 5 токенов.

Получившийся текстовый корпус, мы заливаем в Elastic, который поддерживает autocomplete из коробки. Для каждого из вариантов у нас есть статистика по количеству продаж и количеству запросов за последний 30 дней (её мы обновляем ежедневно). Ранжирование итоговых вариантов ведется как раз на основе этих двух фичей: число покупок после запроса за 30 дней, запросы с 0 покупок имеют меньший вес. 

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

Мы оставили общие признаки с предыдущей итерации и добавили еще несколько: конверсия по запросу в добавление корзину и заказ за разные окна во времени, средняя цена товара в топ-10 по запросу. 

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

Из занятного — в персонализации важно смотреть на интерпретируемость признаков, которая позволяет проверить, насколько вообще задуманная фича отражает «смысл» того, что мы в нее закладывали. 

Ниже вы видите график зависимости скора модели от того, насколько запрос «мужской» (доля покупателей мужского пола среди всех для запроса), и, что логично, если пользователь — мужчина, этот скор растёт, а если женщина — падает. 

На офлайне мы увидели прирост NDCG@40 по покупкам по сравнению с предыдущим подходом.

А вот на онлайне помимо классической метрики конверсии в заказ мы замеряли usage наших подсказок: насколько чаще клиенты стали пользоваться подсказками и взаимодействовать с ними. Прирост по конверсии был, скорее, в серой зоне, а вот метрики вовлечения в использования подсказок — зелёными. 

В итоге персонализированный ранкинг подсказок мы раскатили на всех зарегистрированных пользователей. 

Расширяем retrieval: синонимы 

Главный итог работы предыдущих инструментов — это запрос, который отправится в Elastic, чтобы подобрать подходящие товары-кандидаты. И здесь у нас работает механизм, который позволяет расширять этот запрос за счёт синонимов. К примеру, мы можем находить кроссовки по различным запросам, скажем: спортивная обувь, обувь для бега, etc. В большинстве случаев это действительно помогает сделать выдачу более разнообразной, однако может приводить и к неприятный кейсам: 

Произошло это из-за синонима «гарнитура» к запросу «наушники», в результате в выдачу попали все товары, которые этот синоним содержат. Всё из-за того, что в нашей базе стало слишком много синонимов — десятки тысяч. При этом добавлялись они без особого контроля, в режиме ad-hoc и никак не отслеживались. В итоге получилась ситуация, когда запрос содержит только два токена, а после применения синонимов разрастается до 25-30 токенов. 

Для понимания — «база синонимов» для Elastic это txt-файл, где каждая строка соответствует какому-то кейсу.  Выглядит это так: 

“aйфон”  => iphone 

Первый путь попадания синонимов в эту базу — это наш стандартный процесс, через PR в репозиторий git со словарём, каждый новый синоним проводится через review от нашей команды модераторов. Второй путь — это различные артефакты от наших попыток массово собирать подходящие фразы, например, переформулировки в рамках одной сессии. 

Стоит отметить, что мы ещё продолжаем работать над подходом по работе с синонимами, однако уже реализовали несколько вещей для наведения порядка. 

Мы выбрали два вектора для приложения усилий: 

1. Удаление неиспользуемых синонимов, которые просто занимают место в словаре, а фактически никак не используются 

2. Поиск синонимов-«вредителей», которые делают нашу выдачу хуже 

Для поиска вредителей работал следующий алгоритм:

• Мы выбрали 10 000 самых популярных запросов

• Для каждого из запросов собрали две версии выдачи: версия, где у запроса не было синонимов, и версия с полным набором синонимов 

• Для каждой из версии выборок были подсчитаны offline-метрики с помощью LLM: ndcg@10, precision@10; если версия с синонимами показывала себя значимо хуже, для запроса удалялось всё множество синонимов

• Отдельно мы удаляли синонимы, которые за последний год ни разу не использовались — то есть ни разу не вводилась поисковая фраза, для которой этот синоним бы отрабатывал

• В итоге был сформирован отдельный файл-словарь для А/В-теста 

Мы запустили тест и почти сразу увидели просадку в основных поисковых метриках. При анализе получилось увидеть следующее: удаляя всё множество синонимов по алгоритму, мы выкидывали в том числе и полезные, те, что делали выдачу реально

лучше. Чаще всего наши синонимы выглядели так, как на скрине ниже для слова sumka. Получается, что у нас множество всевозможных фраз, и нельзя просто удалить их все. 

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

1. беспроводные наушники => гарнитура

2. беспроводные  => хендсфри

3. наушники  => затычки 

Если у нас есть первая строчка, то для целого запроса мы однозначно сопоставляем синоним, на отдельные слова у нас ничего не срабатывает. Однако если эту строчку удалить, то синонимы начнут работать для каждого токена отдельно, и для запроса «беспроводные наушники» появится новый синоним «хендсфри затычки».

Качество синонимов, которые появились после удаления старых, мы отдельно не проверяли, а они могли быть хуже, чем старые. 

В итоге мы решили провести два разных эксперимента: 

1. Отдельно удалить неиспользуемые синонимы, чтобы со словарем было в целом удобно работать, 

2. Отдельно придумать новый алгоритм для синонимов-«вредителей», который будет учитывать все особенности Elastic. 

Первый эксперимент мы уже провели: мы ожидали, что сможем существенно сократить размер словаря, при этом не повлияв на наши поисковые метрики отрицательно. У нас это получилось: размер словаря снизился с 1 млн строк почти в 10 раз, а поисковые метрики остались серыми.  

Сужаем retrieval: катпреды 

Катпред — это инструмент, который позволяет сопоставить ключевому слову определенную категорию и дальше использовать её для ограничения retrieval. Логичный вопрос: если с помощью синонимов мы его расширяли, для чего же теперь его сужать? 

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

Мы можем постараться решить эту проблему с помощью фичей по разрезу «запрос–документ», но это не всегда технически возможно реализовать. Кроме того, для накопления статистики для фичей нужно время, а сами фичи частично могут быть шумными: пользователи могут покупать по запросу и нерелевантные товары. 

Поэтому иногда проще поставить ограничение в виде определенной категории, тот самый катпред. 

Катпред можно реализовать несколькими способами:

• Просто добавить фичу категории в ранжирующем алгоритме, никакой дополнительной фильтрации не применяем

• Как поисковое ранжирование, когда мы полноценно ходит в retrieval, достаём релевантные товары, но потом проходим фильтром по категории. Этот способ мы называем «неполный катпред», и он хорошо подходит для выдач по запросам с конкретной моделью телефона

• Если запрос синонимичен категории, то тут можно включить «полный катпред», который по сути является редиректом в категорию, где работает отдельная модель для каталога. Это хорошо работает для общих запросов

У нас внедрены два последних способа: в специальной табличке мы храним ключевые слова, id категории и тип правила (полный/неполный). Мы активно ведём работу по отказу от неё и переходу на ML-катпред с онлайн-инференсом, но это не мешает параллельно проводить офлайн-эксперименты. 

А сделать можно следующее: поработать над полнотой охвата, по сути сгенерировать новые правила, либо улучшить точность, проверить, насколько хорошо работают текущие правила.

Тесты легко проводить, достаточно сгенерировать новую таблицу с правилами.  

Сначала мы провели одновременно дерзкий и простой тест, где было три группы: 

1. Контроль, где всё работает по-старому

2. Группа, где мы отключили вообще все правила катпреда в надежде на то, что поисковое ранжирование уже и так хорошо работает 

3. Группа, где мы добавили правила на основе списка всех актуальных смартфонов — если определяли модель, то делали неполный катпред в мобильные телефоны с фильтром по модели. Это должно было помочь с ситуациями, в которых аксессуары забивают весь топ при поиске конкретного телефона

Первая группа не прожила в тесте даже до конца дня: выдача по некоторым высокочастотным ключевым словам значительно деградировала, например, по запросу «одежда» в топ-40 попали только чулочно-носочные изделия, и это, конечно, не та одежда, на которую мы рассчитывали. Пришлось срочно отключать группу и убирать из теста. 

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

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

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

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

1. Базовая стратегия, основанная на преобладании конкретной категории в выдаче по ключевому слову 

2. Предиктивная стратегия, когда мы пытаемся предсказать категорию 

3. Стратегия поиска предков: берем кандидатов из двух предыдущих стратегий и идём вверх по дереву категорий на K шагов 

4. Стратегия «случайного блуждания», аналогична предыдущей, но мы идём не строго вверх по дереву, а заглядываем ещё и в соседние возможные ветки 

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

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

Далее все предсказанные rank для каждой категории с помощью softmax транслировались от 0 до 1, и выбирался один, с самым высоким скором. Порог, выше которого правило добавлялось в эксперимент, мы подбирали, ориентируясь на кривую точности–покрытия, которая выглядит вот так: 

По оси Y здесь precision@1: насколько хорошо мы предсказываем правила, ориентируясь на точность первой предсказанной категории, а по Х —  какой процент ключевых фраз мы покрываем. 

Метрики на офлайне нас полностью устроили: мы увидели прирост по ndcg@40 по заказам и по большей части запросов уменьшали объём выдач. Но вот на онлайне тест был негативно-серым. Пост-анализ показал, что модель имела тенденцию навешивать катпреды на общие запросы, в которых интент пользователя был непонятен: «мужчин», «лета», «вида», «полоски». Как показывает наш опыт, на таких запросах лучше отдавать максимально возможный retrieval. 

Golden Dataset и разметка: LLM на страже релевантности поиска

Для замера качества нашего ранжирования можно использовать различные сигналы от пользователей: конверсии по различным срезам, клики. Но эти данные слишком шумные. К примеру пользователь ввел запрос «темные очки rayban», не увидел никаких очков этого бренда, но все таки решил что-то купить, и для нас это будет позитивный сигнал, хотя в действительности поиск отработал плохо. Появляется необходимость в метрике именно о качестве текстового ранжирования, о том насколько, хорошо подобрали ответы для конкретного запроса. 

Поэтому мы решили начать измерять новую метрику, которую назвали ideal precision. Эту метрику мы считаем с помощью LLM на заранее фиксированном наборе запросов, который называется Golden Dataset. 

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

• Убираем стоп-слова, запросы-артикулы, слова-исключения 

• Сортируем запросы по частотности и разделяем их на несколько групп: высокочастотные (первые 1 000 запросов), среднечастотные (9 000 запросов после высокочастотных) 

• Далее из оставшихся запросов мы собираем 20 000 в низкочастотную группу: половина из них выбирается также по частотности, вторая половина — случайно, но мы ограничиваем частотность определенным порогом, то есть в датасет не могут попасть запросы, которые совсем редко вводятся. 

Теперь перейдём к метрике. Наверное, у вас возник вопрос — почему же она называется ideal? 

Давайте посмотрим, как мы её получаем: для конкретного запроса получаем топ товаров и получаем от LLM оценку — насколько каждый товар из топа соответствует запросу. Оценка ставится по 4-балльной шкале, где 0 — это полное несоответствие, а 3 — соответствует идеально. 

Например, если у нас запрос «джинсы Levis», то джинсы этого бренда получат 3, джинсы других брендов — 2, какие-нибудь прочие джинсовые вещи — 1, а что-то совсем нерелевантное — 0. 

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

В итоге для получения финальной ежедневной оценки мы проходим по каждому из запросов в Golden Dataset, считаем для него ideal precision, а потом находим среднее по всем полученным значениям. При это часть размеченных запросов мы регулярно отправляем на дополнительную разметку нашими асессорами, для того чтобы проверить качество разметки и посмотреть на кейсы где оценки LLM и людей начали расходиться. 

За этой метрикой мы следим ежедневно на специальном дашборде, плюс отдельно считаем её для каждой экспериментальной модели, и, если видим неожиданное падение — то это повод не катить тест, а разобраться с тем, что пошло не так. 

Но c ideal precision оказалось не всё так просто: при полностью аналогичном промпте по одному и тому же товару LLM могла с некоторой степенью вероятности поменять свою оценку на менее уверенную. Из-за этого подсчёт ideal precision был шумным, и с учётом таргетов на рост этой метрики — это было неприятно. Фактически мы могли просто перезапустить разметку и достичь целевого результата, а на следующий день перезапуск, наоборот, сильно недотянуть. 

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

• repeat-level interval — показывает, как меняется итоговая метрика между повторными запусками модели на одном и том же семпле

• query-bootstrap interval — показывает неопределённость оценки среднего значения метрики из-за конечного числа запросов в семпле.

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

Вместо заключения 

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

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

Выражаю благодарность всем, кто работал и работает над ML в команде поиска Uzum Market и помогал в подготовке статьи: Дарье Запекиной, Ирине Коневской, Сергею Широкову, Андрею Кулагину, Вере Смирновой, Аркадию Полухину и Григорию Овчинникову.