Гибридный поиск полезен, когда одни посетители вводят точный артикул, а другие описывают задачу своими словами. Он объединяет поиск по словам и по смыслу. Проверять его стоит на запросах, с которыми нынешняя система справляется плохо: находит похожую деталь вместо нужной, теряет инструкцию из-за другой формулировки или показывает устаревший документ.
В YDB 26.3 такой подход получил встроенную поддержку. Но решение о внедрении лучше принимать после небольшого испытания: сравнить выдачу, скорость, обновление данных и стоимость. Ниже — пример проверочных запросов и критерии, по которым можно принять или отклонить пилот.
Как соединяются слова и смысл
Представьте каталог креплений. Запрос «AB-204» требует найти конкретную позицию. Запрос «крепление для полки, чтобы не было видно уголков» требует понять назначение товара, даже если в карточке написано «скрытый полкодержатель».
- Полнотекстовый поиск сопоставляет слова и другие элементы текста запроса с содержимым карточек или документов.
- Векторный поиск ищет близость по смыслу. Для этого отдельная модель превращает текст в набор чисел — вектор, или эмбеддинг.
- Гибридный поиск получает кандидатов обоими способами и объединяет их в упорядоченный список.
В YDB для этого используются два индекса одной таблицы: полнотекстовый и векторный. Индекс — вспомогательная структура, позволяющая быстрее найти нужные записи. Объединением результатов управляет функция HybridRank; вклад двух способов поиска можно настраивать.
Однако похожесть по смыслу не подтверждает совместимость детали. Если покупателю нужен артикул AB-204 или длина строго 300 мм, эти условия надо проверять отдельно. Для артикула полезно хранить отдельное нормализованное поле и задать приоритет точного совпадения. Размеры, наличие и права доступа должны быть обязательными правилами системы, а не пожеланиями к порядку результатов.
Что проверить в версии и развёртывании YDB
В анонсе Яндекса от 2 октября 2026 года гибридный поиск указан как доступный в enterprise-редакции YDB 26.3 для установки в собственном контуре и в Managed Service for YDB. При этом в списке изменений YDB Server сборка 26.3.1.16 от 18 сентября обозначена релиз-кандидатом, а гибридный поиск отнесён к возможностям, отключённым по умолчанию.
Анонс корпоративной редакции и статус конкретной серверной сборки — разные сведения. Перед оценкой сроков попросите администратора или поставщика подтвердить редакцию, номер сборки, доступность функции в выбранном сервисе и способ её включения. Наличие числа «26.3» само по себе этого не подтверждает.
В техническое задание на испытание стоит включить ещё три проверки:
- Индексы готовы. Гибридному запросу нужны полнотекстовый индекс fulltext_relevance и векторный vector_kmeans_tree по соответствующим колонкам. По документации YDB 26.3, префиксные векторные индексы для такого запроса не поддерживаются. Это важно, если проект уже использует такую схему.
- Векторы кто-то вычисляет. YDB не создаёт эмбеддинги самостоятельно. Приложению нужна модель, которая обрабатывает документы и пользовательские запросы; для неё учитывают время, стоимость и допустимость передачи данных.
- Обновляется весь путь данных. Разработчик заявляет обновление индексов вместе с данными в одной транзакции. Но новое описание сначала должно попасть в базу вместе с актуальным вектором. Задержку выгрузки из каталога или пересчёта векторов это свойство не устраняет.
Шесть запросов, на которых видно качество поиска
Ниже учебный набор, который можно заменить собственными товарами и инструкциями. Он не описывает ассортимент «Олимпа» или результат выполненного внедрения.
В условном каталоге есть скрытые стальные полкодержатели AB-204 длиной 200 мм и AB-205 длиной 300 мм; титановых креплений нет. В базе знаний есть действующая инструкция KB-17 о пустых этикетках принтера L200 и закрытый документ KB-44 об условиях поставщика. Тест выполняется под учётной записью обычного сотрудника, которому KB-44 недоступен.
| Запрос | Что должно получиться | Что считать ошибкой |
|---|---|---|
| AB-204 | Карточка AB-204 на первом месте. | Первым показан похожий AB-205. |
| Крепление для полки без видимых уголков | Хотя бы один из скрытых полкодержателей AB-204 или AB-205 в первых трёх результатах. | Нужные товары не найдены из-за слова «полкодержатель» в карточке. |
| AB-204 длиной 300 мм | Сообщение о несовпадении параметров или уточнение: AB-204 имеет длину 200 мм. AB-205 можно предложить только как явно обозначенную альтернативу. | AB-205 выдан как точное соответствие всему запросу. |
| L200 пропускает этикетки и печатает через одну | Действующая инструкция KB-17 в первых трёх результатах. | Наверху инструкция к другой модели или отменённая версия. |
| Титановое крепление для полки | Понятное сообщение, что подходящего товара нет; сталь не выдаётся за титан. | Близкая по назначению стальная деталь показана как подходящая. |
| Условия скидок поставщика | KB-44 не раскрывается этому сотруднику: ни текстом, ни фрагментом, ни ответом помощника. | Закрытый документ попал в выдачу или использован при составлении ответа. |
Такой набор проверяет всю поисковую функцию приложения. Сам HybridRank ранжирует найденные записи: он не определяет за бизнес, что считать допустимой заменой, и не обещает автоматически распознать отсутствие ответа. Эти правила, обработку противоречий и контроль доступа нужно спроектировать и испытать отдельно.
Как провести пилот без перестройки всего сайта
- Выберите один участок. Например, одну товарную категорию или базу инструкций поддержки. Зафиксируйте проблему: покупатели не находят скрытые крепления; сотрудники повторно спрашивают о решении уже описанной ошибки.
- Соберите реальные запросы. Возьмите формулировки из внутреннего поиска, обращений и наблюдений за работой сотрудников. Удалите ненужные персональные сведения. Для каждого запроса эксперт отмечает допустимые документы, обязательные параметры и случаи, когда ответа нет.
- Отделите настройку от приёмки. На одной подборке разработчик настраивает систему. Другую, например 100 запросов, сохраняют для итоговой проверки. В ней можно выделить 30 точных, 30 разговорных, 20 смешанных, 10 без подходящего ответа и 10 на разграничение доступа. Это пример состава, а не универсальная пропорция.
- Сравните варианты на одном снимке данных. Проверьте текущий поиск, улучшенный поиск по словам и гибридный вариант. Всем дайте одинаковые карточки, ограничения доступа и набор запросов. Иначе исправление описаний легко принять за заслугу нового алгоритма.
- Проверьте обновление и отказ. Измените описание, снимите товар с продажи, отзовите доступ к документу. Измерьте, когда изменения появились в выдаче. Отключите сервис вычисления векторов и проверьте безопасное поведение: возврат к разрешённому поиску по словам или понятное сообщение об ошибке.
Если пилот затрагивает CMS, товарную выгрузку и интерфейс каталога, эти связи нужно описать в требованиях к разработке сайта. Заранее определите, где хранится исходная карточка, кто отвечает за её обновление и как вернуть прежний поиск.
Как измерить результат и принять решение
Критерии согласуют до настройки. Ниже пример условий приёмки для описанного набора из 100 запросов. Это предлагаемые цели пилота, а не заявленные характеристики YDB и не полученные нами результаты.
- Точные запросы: нужная запись на первом месте во всех 30 проверках. Если прежний поиск находил артикул, а новый перестал, общее улучшение не скрывает эту ошибку.
- Разговорные и смешанные запросы: допустимый результат входит в первые три хотя бы в 45 из 50 случаев, с соблюдением всех обязательных параметров. Например, переход с 35 до 45 успешных запросов означает рост с 70% до 90%, или на 20 процентных пунктов.
- Отсутствие ответа и доступ: ни одного ложного «точного совпадения» в 10 проверках отсутствующих товаров и ни одного раскрытия закрытых данных в 10 проверках доступа. Такие проверки продолжают и после пилота: десять примеров не доказывают безопасность всей системы.
- Скорость: например, не менее 95% всех запросов за 15 минут обрабатываются не дольше 800 мс при нагрузке 20 запросов в секунду. Замеряют полный ответ поискового API, включая вычисление вектора запроса. Нагрузку и допустимую задержку выбирают под свой проект.
- Свежесть и затраты: все контрольные изменения доходят до выдачи в согласованный срок, а месячные расходы укладываются в бюджет. В расчёт включают базу, индексы, вычисление векторов, обновление данных и сопровождение.
Сохраните по каждому запросу первые результаты, время ответа и причину ошибки. Итог пилота должен позволять сказать: «улучшились такие-то запросы, точные совпадения сохранены, ограничения соблюдены, эксплуатация стоит столько-то». Одной красивой демонстрации для этого мало.
После технической приёмки проверьте поведение посетителей: стали ли они реже повторять поиск, чаще открывать подходящую карточку и доходить до полезного действия. Если цель — обращения, проверьте и следующий участок: как заявка с сайта попадает в CRM и доходит до менеджера. Рост числа найденных карточек сам по себе ещё не означает рост продаж.
Когда достаточно более простого решения
Для небольшого каталога, где ищут преимущественно по артикулам, сначала стоит проверить точное совпадение, опечатки, синонимы, понятные названия и фильтры. Если они решают проблему, усложнять систему незачем.
Пилот стоит отложить, если в карточках нет размеров и материалов, инструкции противоречат друг другу или некому подтвердить правильную выдачу. Семантическая близость не восстановит отсутствующий факт. Если поиск уже хорошо работает на другом движке, сравните стоимость его улучшения с переносом данных и сопровождением YDB.
Для ИИ-помощника гибридный поиск может подбирать документы, на основе которых тот составляет ответ. Это называют RAG. Качество подбора и качество ответа проверяют отдельно: найденная инструкция не гарантирует, что помощник правильно её перескажет, покажет действующую версию и не добавит выдуманных сведений.
Начать можно с десяти проблемных запросов. Рядом с каждым запишите, какой товар или документ должен находиться, что показывается сейчас и чем ошибка мешает работе. Такой список даст больше для оценки проекта, чем общее пожелание «сделать умный поиск».
Автор: Милюков Михаил Андреевич.
