2 июня 2026 года InfoQ опубликовал разбор о том, почему гибридный поиск RAG в продакшене часто полезнее, чем ставка только на векторный поиск. Для команд, которые уже прикрутили LLM к внутренним базам знаний, runbook’ам и тикетам, новость неприятно практичная: семантика у эмбеддингов хороша ровно до того момента, пока дежурный инженер не спрашивает про конкретный feature flag, версию релиза или код ошибки.
Как пишет InfoQ, автор статьи Аадитья Чаухан разбирает типичный сбой внутреннего omni-search на базе RAG: сотрудник поддержки вводит запрос вроде “runbook to enable the payment_v2_enforce feature flag in production”, а чат-интерфейс уверенно советует сделать обратное, то есть выключить флаг. Причина не в том, что модель “глупая”, а в устройстве самого retrieval-слоя. Для embedding-модели два runbook’а, где различается одно слово, почти близнецы: одинаковый сервис, одинаковый флаг, похожий словарь, почти идентичный контекст. В результате неправильный документ может оказаться выше правильного в top-K, а LLM уже добросовестно перескажет не тот контекст. Для RAG это особенно неприятно: наличие верного документа в выборке не спасает, если первым пришёл неверный.
Дальше Чаухан довольно безжалостно напоминает базовую вещь, которую многие команды предпочитают забыть после первого демо: эмбеддинги ищут похожее, а не точное. Это отлично работает для смысловых запросов вроде “что у нас делать при падении региона”, где документы могут не совпадать с формулировкой, но отвечать по существу. Но там, где важен точный идентификатор, векторный поиск начинает вредить. В статье приведён характерный пример с кодом ошибки ERR_PAYMENT_GATEWAY_TIMEOUT: рядом в embedding-space легко всплывают ERR_PAYMENT_GATEWAY_REJECTED и ERR_PAYMENT_GATEWAY_UNAUTHORIZED, потому что у них общий префикс и похожие troubleshooting-документы. Человек искал один конкретный код, а система приносит “что-то из того же семейства”. На презентации это выглядит почти умно. На инциденте, мягко говоря, не очень.
Выход автор видит не в замене эмбеддингов, а в парной работе с BM25, классической функцией ранжирования, которая до сих пор живее многих модных стеков. В статье напомнили три её сильные стороны: IDF усиливает редкие и отличающие токены вроде версии v3.2 или имени feature flag; term frequency saturation не даёт документам выигрывать просто за счёт повторения слов; нормализация по длине не позволяет длинным кускам текста неизбежно доминировать над короткими. Иными словами, BM25 хорошо ловит то, что для эмбеддингов выглядит как шумная мелочь, хотя именно эта “мелочь” часто и есть смысл запроса.
Ключевой инженерный приём в материале — не ручное смешивание score, а Reciprocal Rank Fusion, или RRF. Логика проста: BM25 и vector search работают параллельно, каждый строит свой ranking, а RRF склеивает результаты не по сырым score, а по позиции документа в выдаче. Это избавляет от вечной боли с нормализацией: cosine similarity живёт в одном диапазоне, BM25 — в другом, универсальный коэффициент “смешивания” всё равно упирается в тип запроса. В статье приводится стандартный rank constant 60: документ на первом месте даёт вклад 1/61, на десятом — 1/70, а отсутствующий в top-K не даёт ничего. Выигрывают те документы, с которыми независимо согласились оба retriever’а. Не магия, просто аккуратная математика без лишнего hero engineering.
Самый полезный кусок статьи — три сценария, на которых видно, где именно работает гибридный поиск RAG. Для чисто семантического запроса про expired tokens в auth-системе первым оказывается vector search, а RRF лишь закрепляет правильный документ наверху. Для чистого exact-match по коду ошибки BM25 и так побеждает, а гибридная схема сохраняет верный top-1, но делает соседние результаты чуть шумнее. Зато на гибридном запросе вроде “Rollback Runbook for v3.2 Deployment” и проявляется главный смысл конструкции: BM25 удерживает точные токены rollback и v3.2, а эмбеддинги добавляют смысловую близость. В статье приводится почти комичный разрыв: vector search может поставить выше rollout, а не rollback, причём разница в cosine similarity там порядка 0,01-0,02. То есть для модели это почти статистический шорох, а для продакшена — две очень разные кнопки.
Отдельно Чаухан показывает, что такая архитектура уже выглядит как норма, а не как экзотика для энтузиастов. В качестве примеров он приводит Perplexity, где лексическое и embedding-ранжирование сочетаются в многоступенчатой схеме поверх Vespa, и Glean с его enterprise-поиском. Для тех, кто живёт в экосистеме Elastic, статья ещё и прикладная: нативная поддержка hybrid retrieval есть в Elasticsearch 8.13+, OpenSearch движется в ту же сторону. Базовая схема у автора предсказуемая: текстовое поле под BM25, dense_vector на 768 измерений под семантику, запрос с RRF, затем при желании reranking через cross-encoder. В качестве стартовой точки он даёт k=50 и num_candidates=100 для kNN, а для финальной переоценки — 20-50 кандидатов через cross-encoder вроде ms-marco-MiniLM-L-6-v2. На GPU, по его оценке, reranking 50 кандидатов обычно укладывается меньше чем в 100 мс.
Для русскоязычных разработчиков, продактов и CTO смысл здесь довольно прямой. Если ваш внутренний поиск на базе LLM уже отвечает на вопросы по runbook’ам, RFC, postmortem и релизным документам, то quality retrieval становится не “тонкой настройкой”, а частью надёжности. Особенно там, где запросы смешанные: немного смысла, немного точных сущностей, немного человеческой надежды, что чат не перепутает enable с disable. И именно такие запросы, по наблюдению автора, в продакшене встречаются чаще всего. Следующий логичный вопрос для команд уже не в том, нужен ли гибридный поиск RAG, а где проходит граница, после которой без второго этапа reranking и явных evals по retrieval-качеству систему вообще опасно показывать дежурным инженерам. Исходный материал с примерами и упоминанием GitHub-демо — в .