В релизе 26.3 СУБД YDB, которую развивает команда Яндекса, появились полнотекстовый поиск с ранжированием и гибридный поиск. Об этом рассказал разработчик Александр Зевайкин: год назад в YDB был запущен векторный поиск, а весной 2025-го он уже применялся в сервисе «Нейроюрист» для поиска по миллионам юридических документов. Теперь к нему добавились лексический поиск и механизм объединения двух выдач в рамках одного SQL-запроса. Релиз также включает доработку фильтруемого векторного индекса. По словам автора, основная цель — дать бизнесу единый инструмент, который одинаково хорошо находит и точные строки, и близкие по смыслу фрагменты.

На примере страхового юриста, который ищет «выплаты по полису 7702-345678 при переносе рейса», видно, почему одного типа поиска недостаточно. Номер полиса требует посимвольного совпадения, а описание случая — семантической близости. Векторный поиск, работающий с эмбеддингами, находит документы, где мысль выражена другими словами, например «соглашение о найме коммерческой недвижимости» и «договор аренды нежилого помещения» оказываются рядом в векторном пространстве. Однако он не гарантирует точного попадания редкой фамилии или уникального номера в топ-50, а близкие числовые обозначения вроде «152-ФЗ» и «153-ФЗ» могут стоять почти неразличимо. Полнотекстовый поиск, напротив, приводит словоформы к основе с помощью стемминга, поэтому «суд», «суда» и «судом» считаются одним словом, но синонимы для него остаются разными. Зато фамилию, город, код ошибки, артикул или номер полиса он находит точно. В техподдержке и интернет-магазине запросы часто сочетают оба типа: инженер ищет «сервис отвечает с задержкой, повторные запросы создают дубликаты», где имя сервиса и код ошибки нужно найти точно, а симптом — по смыслу; покупатель пишет «что-нибудь тёплое на осень в офис» вместе с артикулом.

Технически оба индекса в YDB реализованы как распределённые таблицы, что позволяет хранить их внутри самой СУБД и не выносить поиск во внешние системы. Инвертированный индекс с ранжированием по BM25 учитывает частоту термина в документе и обратную частоту в коллекции, а векторный индекс хранит эмбеддинги для семантического сравнения. При записи данных оба индекса обновляются согласованно, а фильтрация может применяться непосредственно к результатам поиска, не требуя повторной реализации в слое приложения. Гибридный поиск объединяет две выдачи внутри одного плана запроса: СУБД сама решает, как скомбинировать лексическую и векторную составляющие, чтобы вернуть единый ранжированный список. Это устраняет необходимость писать код слияния на стороне клиента и снижает задержки за счёт отсутствия промежуточных пересылок между системами.

До сих пор типичная архитектура поиска предполагала наличие реляционной СУБД, отдельной поисковой системы и иногда векторного хранилища. Данные переносились через ETL-конвейеры, хранились в двух или трёх экземплярах, а между ними всегда существовало окно рассинхронизации. Строка, записанная секунду назад, могла быть ещё не видна в поисковом индексе, поэтому оператор поддержки не находил только что созданный тикет. Права доступа приходилось копировать в индекс или проверять после поиска, что приводило либо к показу документа из чужого проекта, либо к пустой выдаче после фильтрации. Каталог интернет-магазина меняется каждую минуту, а рекомендации строились по вчерашней копии и предлагали отсутствующий товар. В YDB оба индекса стали таблицами, что снимает这些问题 согласованности, дублирования и масштабирования. Для российского рынка это означает возможность строить RAG-системы и рекомендательные сервисы на отечественной СУБД без привлечения зарубежных поисковых движков, что важно в условиях импортозамещения и ограничений на использование внешних облаков.

Гибридный поиск особенно полезен для рекомендательных систем, где нужно учитывать и точные атрибуты товара, и смысловые предпочтения пользователя. Качество таких систем измеряют метриками ранжирования, например precision@k, recall@k или NDCG, и гибридный подход позволяет улучшить их за счёт объединения сигналов. По сравнению с альтернативами — отдельными поисковыми системами вроде Elasticsearch и векторными базами типа Milvus или Qdrant — YDB предлагает единое решение, где поиск не оторван от транзакционных данных. Это снижает операционные расходы и упрощает поддержку, хотя и требует доверия к экосистеме YDB. Конкуренты на российском рынке, включая решения на базе PostgreSQL с расширениями, пока не могут похвастаться нативной гибридной выдачей в одном запросе, что даёт YDB определённое преимущество.

В дальнейшем команда YDB, вероятно, продолжит развивать гибридный поиск, добавляя новые виды ранжирования и улучшая интеграцию с ИИ-ассистентами. Открытым остаётся вопрос, насколько хорошо решение масштабируется под экстремальными нагрузками и как оно поведёт себя в сценариях с жёсткими требованиями к задержкам. Также пока неясно, появятся ли аналогичные возможности в других российских СУБД и как на это отреагирует рынок. Автор анонсировал вебинар 15 октября, где покажет, как за час собрать поисковое приложение и подключить его к ИИ-ассистенту через RAG. Всё, что будет продемонстрировано, доступно на бесплатном тарифе, что позволит разработчикам самостоятельно оценить нововведения. Если гибридный поиск оправдает ожидания, он может стать стандартом для корпоративных поисковых систем и ускорить внедрение RAG в российских компаниях.