Ранжирование перевернуло поиск в базе из 35 000 страниц: как Reranker спас нейропоиск в Рунити
В компании Рунити масштабирование корпоративного RAG-ассистента до 35 000 страниц столкнулось с типичной проблемой больших баз знаний: документы находились, но были скрыты в десятках почти релевантных вариантов. Инженеры выяснили, что рост числа кандидатов не решает проблему качества, если не применять к ним перекрестный классификатор (cross-encoder reranker). Именно этот слой, а не смена векторной модели или усложнение индексации, обеспечил резкий прирост точности выдачи ответов.
# Когда плотный поиск перестал справляться с масштабом
Масштабирование корпоративного RAG (Retrieval-Augmented Generation) часто становится неожиданным вызовом. Если на малом наборе данных достаточно найти документ, похожий по смыслу, то при работе с тысячами страниц картина меняется. В центре гибридного интеллекта Рунити столкнулись с ситуацией, когда поиск среди почти 35 тысяч страниц и 80 тысяч чанков (фрагментов текста) начал давать сбой. На поверхность выдачи все чаще выплывали материалы, по теме похожие, но не содержащие прямого ответа на вопрос пользователя.
Команда ML-инженеров проверила стандартные пути оптимизации: изменили метод выгрузки из Confluence, усложнили чанкирование, вынесли код в отдельные векторные представления и даже попробовали более мощную модель для генерации эмбеддингов. Ни одна из этих мер не привела к значимому улучшению. Ключевой инсайт пришел из анализа метрик: нужные документы фактически уже находились в сотне кандидатов, но система не могла их выделить.
*«Главная подсказка пришла из метрик: нужный материал в большинстве случаев уже находился, но стоял слишком низко»*, — отмечает Александр Михеев, ML-инженер Рунити.
Это открытие сместило фокус разработки с расширения поиска на улучшение порядка выдачи.
Гибридный подход: объединение смыслов и ключевых слов
Исходная система использовала классический плотный поиск (dense retrieval) на основе модели BGE-M3. На небольшом корпусе таких моделей достаточно хорошо справляться с семантическим пониманием запроса. Однако на большом корпусе вокруг каждого запроса появлялось множество «почти правильных» документов.
Для решения этой проблемы инженеры внедрили гибридный подход. Они добавили разреженное представление (sparse representation), которое оперирует статистической встречаемостью токенов, а не только смысловой близостью. Это позволяет системе лучше реагировать на точные технические термины, имена параметров API и специфические идентификаторы, которые часто теряются в семантических моделях.
Реализация включала:
* Dense-вектор: Смысловое представление текста. * Sparse-вектор: Вектор, где вес слова определяется его уникальностью и частотой встречаемости, а не контекстом. * RRF (Reciprocal Rank Fusion): Метод объединения результатов двух поисков. В результате поиска выдавались кандидаты от обоих каналов, а затем они объединялись с весами, установленными после подбора (grid search). Оптимальным оказался вес плотного канала в 4 раза больше, чем разреженного.
Результат этого перехода был заметен: показатель Page@1 (доля запросов, где нужный документ оказался на первом месте) вырос сразу на 12,1 процентного пункта. Тем не менее, команда не остановилась на достигнутом.
Перекрестный классификатор: финальный штрих к точности
Анализ метрик показал критическую деталь. Показатель Evidence@20 (доля запросов, где нужный фрагмент документа находился в первой двадцатке результатов) достигал 94,1%. Это означало, что катастрофической нехватки данных (recall problem) не существовало. Проблема была в порядковом ранжировании (ordering problem).
Для решения этой задачи применялся cross-encoder reranker. В отличие от обычных поисковых моделей, которые кодируют запрос и документ отдельно, перекрестный классификатор принимает пару «запрос-кандидат» целиком. Он «читает» их вместе и выдает более точную оценку релевантности. Это значительно дороже в вычислительном плане, поэтому его применяют только к топ-100 кандидатов, отобранным на предварительном этапе.
Команда выбрала модель BAAI/bge-reranker-v2-m3 — мультиязычный классификатор на 568 миллионов параметров, оптимизированный для русского и английского языков.
Применение reranker принесло следующие результаты:
* MRR@10 (Mean Reciprocal Rank): Улучшился с 0,597 до 0,769. * Top-1/Top-5: Резко выросли, что критически важно для ограниченного контекстного окна локальных LLM.
Как отмечают авторы, reranker не столько нашел новые документы, сколько поднял уже найденные правильные кандидаты в список лидеров.
Главные выводы для построения корпоративных систем
Кейс Рунити иллюстрирует несколько важных принципов построения сложных систем поиска:
1. Понимание ограничений данных. Трикратный рост количества чанков не всегда улучшает качество, если они конкурируют друг с другом и размывают сигнал поиска. Иногда простое удаление лишнего шума (например, старых версий инструкций) эффективнее, чем усложнение структуры данных. 2. Роль бенчмарков. Автоматизированное тестирование на больших выборках запросов (в данном случае 5 000 сгенерированных LLM) показало реальную картину работы системы, которую невозможно обнаружить при ручной проверке десятка примеров. 3. Правильный инструмент для задачи. Попытка заменить векторную модель (embedding) на более крупную могла бы быть затратной и не гарантировать результата. В данном случае приоритет был отдан алгоритму ранжирования, что дало более быстрый и измеримый эффект. 4. Этапность внедрения. Архитектура системы должна включать ACL-фильтры (доступ) на уровне metadata уже при ретриеве, чтобы ограниченные пользователи не видели лишних данных, которые затем пришлось бы отфильтровать на этапе ранжирования.
Таким образом, «оживление» нейропоиска в Рунити произошло не за счет увеличения мощности моделей, а за счет корректного конвейера обработки данных: качественная подготовка корпуса, гибридная выборка кандидатов и точное перекрестное ранжирование.
*Вторую часть серии статей о гибридном интеллекте в Рунити посвящено работе с агентами и безопасности в развертываемых системах.*