Чем гибридный поиск в YDB отличается от обычного поиска по смыслу?

Суть отличия

Обычный векторный поиск оценивает только семантическое сходство: запрос и документы превращаются в эмбеддинги, и сортировка идёт по косинусной близости (или L2/inner product). Он хорошо понимает «ноутбук для учёбы подешевле», но плохо работает с точными идентификаторами: артикул «AB-12345-X» может разложиться на бессмысленный вектор, близкий к массе других мусорных строк, и нужный товар не попадёт в топ.

Гибридный поиск в YDB (по аналогии с гибридным поиском в других векторных СУБД) объединяет лексический (полнотекстовый/точное совпадение) и векторный каналы: кандидаты отбираются и ранжируются сразу по двум сигналам, и результат — это слитая выдача, где и «AB-12345-X» встаёт на первое место, и «ноутбук для учёбы» тоже находится.

Как комбинируются результаты

Типичная схема, которую используют YDB и аналогичные системы, — это RRF (Reciprocal Rank Fusion) или взвешенная сумма нормализованных скоров:

• RRF: для каждого документа считается $s = \sum_i \dfrac{w_i}{k + r_i}$, где $r_i$ — позиция в выдаче канала $i$, $k$ — константа (обычно 60), $w_i$ — вес канала. Позиционная формула не требует нормализации скоров между каналами, поэтому косинус и BM25 можно смешивать напрямую.
• Взвешенная сумма: каждый канал нормализуется (min-max или ранг), затем $s = \alpha \cdot s_{\text{lex}} + (1-\alpha) \cdot s_{\text{vec}}$.

В обоих случаях сначала из каждого канала берётся топ-N кандидатов (например, по 100), потом они объединяются и переупорядочиваются.

Веса и настройка

• По умолчанию — не нужно. YDB поднимает гибридный поиск «из коробки» с разумными значениями ($\alpha \approx 0.5$, $k = 60$), и для смешанного каталога это обычно работает лучше, чем чисто векторный.
• Ручная настройка имеет смысл, если:
  • выдача критична к точным артикулам/кодам → поднимаете вес лексического канала;
  • запросы в основном естественноязыковые → поднимаете вес векторного;
  • есть типовые запросы, на которых нужно бенчмаркить → перебираете $\alpha$ (или $k$) по NDCG/MRR на размеченной выборке.

Практический смысл для каталога

Запрос	Чисто векторный	Гибрид
AB-12345-X	часто мимо, артикул «размазан» в векторе	точное попадание из лексического канала
«ноутбук для учёбы подешевле»	хорошо	хорошо (векторный канал)
«ноутбук AB-12345-X»	среднее	оба канала дают попадание, RRF поднимает нужный товар в топ

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

Главное отличие

Обычный векторный поиск сравнивает эмбеддинги запроса и документов. Он находит товары, близкие по смыслу: запрос «тёплая куртка для зимних прогулок» подтянет «утепленный пуховик». Но он плохо работает с точными строками: артикулы, модели, коды, редкие названия. Эмбеддинг артикула «AX-7731B» почти не отличается от эмбеддинга «AX-7731C», и модель может вернуть похожие, но не нужные товары.

Гибридный поиск объединяет два механизма:

• Лексический (полнотекстовый, BM25-подобный) находит точные совпадения токенов, в том числе артикулов.
• Векторный (семантический) находит документы по смыслу.

Для каталога это даёт следующее. Запрос «AX-7731B» попадёт в точное совпадение по лексике, даже если векторная модель его не распознала. Запрос «кроссовки для бега по асфальту, без шипов» найдёт товары по смыслу, даже если в описании нет ни одного совпадающего слова. Запрос вроде «Nike Pegasus 40 лёгкие» получит оба типа совпадений.

Как комбинируются результаты

Обычно используют один из двух подходов:

1. RRF (Reciprocal Rank Fusion). Берутся ранги из каждого списка, итоговый балл считается как сумма 1/(k + rank) по спискам, обычно k ≈ 60. Метод не зависит от масштаба оценок, поэтому его часто выбирают по умолчанию.
2. Взвешенная сумма нормализованных оценок. BM25 и косинусное сходство приводятся к одному диапазону (например, min-max), затем складываются с весами α и (1 − α). Здесь веса действительно нужны.

Точный механизм в YDB (какой метод слияния и какие параметры доступны в SQL/API) я не могу подтвердить по анонсу, поэтому сверьтесь с документацией.

Нужно ли настраивать веса вручную

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

• Для запросов с артикулами лексическая часть должна весить больше.
• Для описательных запросов («что подарить маме») больше должна весить семантика.

Практичный подход: собрать 100–200 реальных запросов с отмеченными релевантными товарами, прогнать поиск с разными весами (например, 0.3, 0.5, 0.7) и выбрать вариант с лучшими метриками (nDCG@10 или Recall@10). Часто помогает и разделение запросов по типу: если запрос похож на артикул (regex по формату кода), можно увеличивать вес лексики.

Рекомендация для вашего кейса

1. Индексируйте артикул и название отдельно от описания, с меньшим весом у описания для лексики.
2. Стартуйте с RRF или весов около 0.5.
3. Добавьте правило: если запрос совпадает с форматом артикула, лексика получает приоритет.
4. Измеряйте качество на собственной выборке, а не полагайтесь на общие примеры.

Гибридный поиск объединяет лексический поиск по словам и векторный поиск по смыслу.

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

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