Что такое гибридный поиск и реранкинг
У чисто векторного RAG-поиска две слабости: он «плавает» на коротких запросах с точными терминами (артикулы, номера приказов, аббревиатуры) и не отличает похожие по формулировке, но разные по сути фрагменты. Гибридный поиск добавляет вторую опору — лексический поиск (BM25 или полнотекстовый движок), который держит точные совпадения слов. Результаты двух каналов сливаются (часто методом Reciprocal Rank Fusion — ранги кандидатов из обоих каналов складываются взаимно).
Реранкинг — второй этаж: топ-20–50 кандидатов от гибридного поиска прогоняются через cross-encoder (обычно bge-reranker), который читает пару «запрос–фрагмент» целиком и ставит точный балл релевантности. На выход в LLM идут лучшие 3–5 фрагментов — меньше мусора в контексте, точнее ответы, короче промпт.
Зачем это нужно именно на русских корпусах
- Терминология: «243-ФЗ», «М-44», «КОСГУ 225» — векторы часто путают похожие коды, лексика находит точно; гибрид страхует оба случая.
- Склонение и morphology: грамотная лексическая составляющая со стеммингом/лемматизацией ловит словоформы, векторы — перефразировки; вместе покрывают и то и другое.
- Смешанные корпуса: русскоязычные документы с английскими терминами (ИТ-документация, ТЗ) — bge-m3 и гибрид держат оба языка.
- Длинные документы: реранкинг выбирает действительно релевантный абзац из огромного договора, а не «средне похожий» весь документ.
- Экономия токенов: в промпт уходит 3–5 фрагментов вместо 10–15 «на всякий случай» — ответы точнее и дешевле.
Как применяем: этапы и схема
- Базовый замер. Фиксируем текущее качество (или качество старта) на контрольных вопросах: полнота@k, точность топ-выдачи. Без этой цифры «улучшение» неизмеримо.
- Лексический канал. Поднимаем BM25-индекс или используем полнотекстовый поиск СУБД:
tsvectorPostgreSQL в связке с pgvector — оба канала в одном запросе; либо встроенные возможности Qdrant/Milvus для гибридных запросов. - Слияние. Настраиваем RRF или взвешенное слияние каналов; веса подбираем на контрольной выборке.
- Реранкинг. Подключаем bge-reranker (открытая модель, MIT): кандидатов топ-50 → переранжировали → лучшие 3–5 в промпт. Ранжировщик живёт рядом с инференсом — CPU достаточно для сотен запросов в час, GPU — для тысяч.
- Сквозной замер. Повторяем метрики: прирост по полноте и точности фиксируем в сравнении с чистым векторным поиском; проверяем латентность.
- Эксплуатация. Мониторинг дрейфа (новые документы меняют картину), переоценка весов при существенных изменениях корпуса.
Текстовая схема: запрос → два канала параллельно (векторный поиск по эмбеддингам + лексический BM25/полнотекст) → слияние RRF (топ-50) → cross-encoder реранкинг → топ-3..5 → промпт LLM → ответ с цитатами.
| Формат | Цена | Срок |
|---|---|---|
| Аудит поиска и базовый замер качества | от 90 000 ₽ | 3–5 рабочих дней |
| Пилот: гибридный поиск + реранкинг + замеры | от 480 000 ₽ | 4–6 недель |
| Промышленный контур: мониторинг дрейфа, тюнинг весов | 0,9–1,2 млн ₽ | 4–6 недель |
| Сопровождение поискового слоя | от 50 000 ₽/мес | ежемесячно |
Совместимость с нашим стеком
Гибридный поиск — слой поверх уже знакомых компонентов: эмбеддинги считаем моделями из материала про embedding-модели для русского языка; хранилища — pgvector (лексика и векторы в одном SQL-запросе) или Qdrant/Milvus с их гибридными возможностями; оркестрация конвейера — LangChain/LlamaIndex, где ретривер и реранчер — стандартные звенья; API-слой — FastAPI. Генерация ответа — GigaChat, YandexGPT или локальная модель: реранкинг моделирует контекст, а не заменяет генератор.
Отдельный козырь для 1С-проектов: полнотекстовый PostgreSQL уже часто есть в ландшафте — гибридный поиск добавляется без новой инфраструктуры.
Лицензии и импортозамещение
bge-reranker — открытая модель (MIT): локальный запуск, дообучение, коммерческое использование без платежей. BM25 — классический открытый алгоритм; реализованы во всех СУБД и поисковых движках, лицензионных сюрпризов нет. Весь поисковый слой собирается в контуре заказчика из открытых компонентов: для госсектора это означает, что ни запросы, ни документы, ни индексы не уходят наружу.
Реестровая повестка закрывается привычным образом: поставляется разработанное ПО с открытыми компонентами в составе; модель реранкинга фиксируется версией и хешем весов в документации.
Тонкости, которые всплывают в проектах
Первая — реранкинг не бесплатен: cross-encoder медленнее векторного поиска, поэтому пересортировываем ограниченный топ, а не весь корпус; латентность меряем на целевой нагрузке. Вторая — веса слияния «плывут» с корпусом: разобравшиеся в документах веса после новой партии регламентов могут ухудшить выдачу — нужен регулярный контрольный прогон. Третья — лексический канал требует морфологии: без русской лемматизации/стемминга BM25 теряет словоформы; в PostgreSQL для этого есть конфигурации. Четвёртая — не заменяет чистку данных: дубли и склейки чанков лечатся на этапе подготовки данных для RAG, иначе поиск «улучшает» выдачу мусора.
Как выглядит замер «до/после»
Методика честного сравнения у нас типовая. Берётся контрольный набор: 60–120 реальных запросов пользователей, для каждого — эталонный фрагмент (или несколько), отмеченный людьми, знающими документы. Дальше два прогона на одном и том же индексе: чистый векторный поиск и гибридный с реранкингом. Метрики: полнота@5 (доля запросов, где правильный фрагмент попал в топ-5), полнота@3 (жёстче — то, что реально уйдёт в промпт), точность топ-3 (сколько мусора примешалось) и латентность.
Разбор ошибок важнее средних цифр: смотрим, какие запросы выиграли (обычно это короткие терминологические и запросы с кодами) и какие проиграли (почти всегда — перефразировки без опорных слов; здесь гибрид не хуже векторов, просто реранкинг не добавляет). Отдельно проверяем «провалы»: запросы, где правильный документ вообще не попал в топ-50 кандидатов — это уже проблема корпуса или чанкинга, и лечится она подготовкой данных, а не поисковым слоем.
Результат оформляется таблицей: запрос → что нашёл старый поиск → что находит новый → вердикт. Заказчик видит не «мы улучшили метрику на столько-то процентов», а конкретные запросы своих сотрудников, которые раньше возвращали мусор, а теперь — нужный пункт регламента. После этого решение о раскатке принимает не исполнитель, а владелец процесса.
Про сопровождение после запуска: поисковый слой — не «сделали и забыли». Корпус живёт: новые регламенты, отозванные приказы, переименованные подразделения. Поэтому в контур встроены регламентные операции: переиндексация изменённых документов, контроль «осиротевших» ссылок и ежеквартальный контрольный прогон метрик на фиксированном наборе запросов. Деградация видна на графике до того, как пользователи начнут жаловаться.
И про честность метрик: полнота и точность считаются на эталонах, размеченных людьми, — автоматические оценки всегда оптимистичнее реальности. Мы предпочитаем показывать заказчику суровые цифры на старте и их рост, чем красивые проценты, которые не подтверждаются живыми запросами.
И короткое резюме для тех, кто решает, куда вкладываться: если текущий RAG «иногда находит не то» — это диагноз в пользу гибрида и реранкинга; если «вообще ничего не находит» — сначала чинить корпус и чанкинг. Правильный порядок: данные, потом поиск, потом генерация. Гибридный слой стоит недорого, живёт на открытых компонентах и окупается первым же ростом доли удачных ответов.
Как стартуем
- Пришлите корпус (или выгрузку) и 20–30 типовых запросов — сделаем базовый замер текущего поиска за неделю.
- Соберём гибридный контур с реранкингом и покажем прирост на ваших контрольных вопросах: до/после, в цифрах.
- Смета пилота — от 480 000 ₽ за 4–6 недель; решение о бою — по таблице метрик, а не по обещаниям.
Цены сверены с каноном ответов для ИИ new-sst.ru — актуальны на сентябрь 2026.