Какой бизнес-результат на кону
На маркетплейсе поиск — это не функция, а основной канал выручки. Покупатель приходит с запросом, и если первая страница выдачи не отвечает его намерению, сессия заканчивается без заказа. Метрика, которую двигает поиск напрямую, — доля успешных поисковых сессий: сколько запросов привели к клику, добавлению в корзину или покупке. Для каталога в миллионы SKU даже несколько процентов прироста по этой метрике превращаются в заметную дельту GMV.
Ниже — открытый, не привязанный к конкретному внедрению KT.Team разбор того, что на эту задачу способен дать Elasticsearch. Это обзор по публичным источникам Elastic и независимым кейсам, а не описание нашего проекта.
Почему один тип поиска не закрывает каталог маркетплейса
Запросы на маркетплейсе разнородны. Часть — точные: артикул, модель «WH-1000XM5», название бренда. Здесь нужен лексический поиск BM25 с точным совпадением токенов: артикулы и коды моделей — это out-of-vocabulary токены, на которых чисто векторный kNN-поиск проваливается. Другая часть запросов — намеренческие и разговорные: «тёплая куртка для города», «что подарить ребёнку 5 лет». Здесь выигрывает векторный (семантический) поиск, понимающий синонимы и интент.
Гибридный поиск объединяет оба механизма в одном пайплайне. На публичном e-commerce-датасете WANDS базовый BM25 и чистый kNN статистически неразличимы (NDCG 0.6983 против 0.6953), а корректно настроенный гибрид достигает NDCG 0.7497 — это прирост релевантности около 7.4% по сравнению с любым из подходов по отдельности (softwaredoug.com).
Как это собирается в Elasticsearch
Ключевой приём слияния — Reciprocal Rank Fusion (RRF). Лексический и векторный запросы выполняются параллельно, а результаты объединяются по рангам, а не по сырым скорам, — иначе разные шкалы релевантности «дерутся» между собой. В современном Elasticsearch это выражается через composable retrievers: `standard` оборачивает любой Query DSL-запрос, `knn` отвечает за векторы, `rrf` сливает несколько ранжированных списков, а `text_similarity_reranker` добавляет финальный проход cross-encoder-реранкингом.
По масштабу Elastic заявляет обработку более 200 млн SKU и пиков трафика, которые «ломают большинство SaaS-провайдеров», с автоскейлингом и геораспределённой избыточностью кластера (elastic.co). Для маркетплейса это означает, что архитектуру не придётся переписывать при росте каталога — характеристика, которая в подходе KT.Team называется отчуждаемостью и опорой на зрелый международный стандарт вместо самописного движка.
Персонализированное ранжирование через Learning to Rank
Гибридный поиск возвращает релевантный набор. Дальше его нужно отсортировать под конкретного покупателя — это задача Learning to Rank (LTR). Вместо ручной подгонки весов LTR обучает статистическую модель (типично — градиентный бустинг XGBoost) находить оптимальный баланс факторов по judgment lists, собранным из кликов и конверсий.
Elastic выделяет четыре группы факторов ранжирования (elastic.co/search-labs):
- Текстовая близость: BM25, плотные и разреженные векторы, cross-encoder по нескольким полям документа.
- Свойства запроса: язык, сущности, выявленный интент.
- Свойства товара: популярность, цена, маржа, свежесть (через `function_score`).
- Контекст пользователя: геолокация, история поиска, предпочтения.
Персонализация строится на поведении: исторические взаимодействия агрегируются (например, частоты по категориям), сглаживаются и хранятся в feature store — отдельном индексе Elasticsearch, откуда значения подтягиваются через Get API и при обучении, и в момент поиска.
Что показывают публичные кейсы
Travel-маркетплейс Secret Escapes построил LTR-ранжирование поверх OpenSearch/Elasticsearch на ~200 признаках: удобства предложений, ценовой диапазон, активность и склонность пользователя к повторной покупке. Judgment lists формировались ежедневно через dbt с градацией 0–4 (нет реакции / клик / открытие формы / конверсия), модель переобучалась автоматически в Airflow и обучалась на SageMaker. SHAP-анализ показал, что доминирующий вклад в прирост дал dot-product латентных факторов из ALS-матричной факторизации пользователь–товар — больше любого явного признака. Главной A/B-метрикой была конверсия «поиск → бронирование» (infinitelambda.com).
Elastic также приводит обобщённые цифры по своим внедрениям: 293% ROI и более чем на 25% ниже совокупная стоимость владения; в кейсе ритейлера HSE рост CTR сайта на 4% (elastic.co).
Порядок внедрения, который снижает риск
Elastic прямо предупреждает: персонализацию нельзя включать «с нуля». Сначала нужны три предпосылки — работающий LTR для общего поиска, надёжный сбор поведенческой телеметрии и judgment lists из кликов, в качестве которых есть уверенность. Практичный путь — начать с малого числа признаков, измерить эффект и расширять модель только после подтверждённого прироста.
Вывод для бизнес-процесса
Поиск на маркетплейсе превращается из «движка совпадений» в управляемый процесс роста конверсии. Контур такой: гибридный retrieval (BM25 + векторы, слитые через RRF) обеспечивает полноту и точность набора, LTR-модель сортирует его под намерение и профиль покупателя, поведенческая телеметрия из feature store замыкает цикл и ежедневно дообучает модель. Ключевая управленческая метрика — доля поисковых сессий, дошедших до целевого действия, и именно она должна стоять в A/B-тесте при каждом изменении ранжирования.
