Реранкинг (reranking)

Реранкинг — это второй этап поиска, на котором система берет уже найденные кандидаты и пересортировывает их более точной, но более дорогой моделью. Его используют там, где важны верхние позиции: в поиске по документам, каталогах товаров, рекомендациях и RAG. Метод не решает проблемы плохого первичного поиска, плохо подходит при очень жестком бюджете по задержке, при крошечном наборе кандидатов и в сценариях, где результат почти полностью определяется фильтрами или нужна простая, полностью объяснимая формула сортировки.

Простыми словами

Если упростить, реранкинг — это перепроверка результатов. Сначала быстрый поиск находит, например, 50 или 100 кандидатов. Потом вторая модель смотрит на них внимательнее и решает, какие из них действительно лучше отвечают на запрос. После этого порядок меняется: слабые совпадения опускаются ниже, а более релевантные поднимаются вверх.

Важно не путать реранкинг с самим поиском. Поиск отвечает на вопрос что вообще стоит показать, а реранкинг — в каком порядке это показать. На практике это почти всегда двухэтапная схема: сначала нужен широкий охват кандидатов, потом — точная пересортировка верхней части списка.

Как это работает

В типичной системе реранкинг ставят после первичного поиска. Первый этап должен быть быстрым и давать хороший recall, то есть не пропускать потенциально нужные документы. Второй этап может быть медленнее, потому что работает уже не со всем индексом, а только с небольшим списком кандидатов.

Этап	Задача	Типичные методы	Ключевое требование
Первичный поиск	Найти набор кандидатов	BM25, векторный поиск, гибридный поиск, фильтры	Скорость и широкий охват
Реранкинг	Пересортировать кандидатов	Learning to Rank, семантический ранкер, cross-encoder	Точность верхних позиций

1. Система получает запрос. На этом шаге обычно применяются фильтры, нормализация текста, языковые настройки и бизнес-ограничения.
2. Первичный поиск отбирает кандидатов. Например, гибридный поиск возвращает 50 документов, которые хотя бы потенциально подходят.
3. Реранкер оценивает пары запрос–документ. В отличие от простого поиска, здесь модель может смотреть на запрос и текст документа совместно, а не по отдельности.
4. Документы получают новые оценки. Эти оценки могут учитывать не только текстовую близость, но и структуру документа, свежесть, тип контента, поведенческие сигналы или признаки домена.
5. Список пересортировывается. Из него выбирают верхние k результатов для интерфейса, API-ответа или контекста RAG.

Реранкинг можно строить по-разному. Самый простой вариант — ручные правила. Более зрелый вариант — Learning to Rank, где модель учится на кликах, конверсиях или оценках асессоров. В современных поисковых системах часто используют семантические реранкеры или cross-encoder-модели: они точнее понимают соответствие между формулировкой запроса и конкретным фрагментом документа, но стоят дороже по времени и вычислениям. Поэтому реранжировать весь индекс обычно невыгодно: смысл метода именно в том, чтобы применять дорогую проверку только к небольшому набору кандидатов.

Зачем нужно

• Поднять качество верхних результатов. Для большинства интерфейсов критичны первые позиции, а не весь список.
• Совместить разные сигналы релевантности. Быстрый поиск хорошо находит кандидатов, а реранкер лучше различает нюансы смысла.
• Улучшить RAG. Чем точнее верхние документы, тем меньше шанс, что генеративная модель получит шумный или почти релевантный контекст.
• Снизить влияние ложных совпадений. Это особенно заметно в длинных документах, каталогах с похожими названиями и внутренних базах знаний.
• Точнее обрабатывать сложные запросы. Например, когда важны отрицания, условия, сравнения, роли пользователей или редкие комбинации терминов.

Реранкинг особенно полезен там, где первичный поиск должен быть быстрым и дешевым, но пользователь ожидает качественные первые ответы. Если же документов мало, запросы простые, а релевантность почти целиком задается фильтрами, дополнительный этап может не окупиться.

Пример

Практический сценарий: корпоративный поиск по базе знаний для техподдержки. Пользователь вводит запрос «как настроить SSO для партнерского портала». В индексе есть статьи по разным продуктам, версиям и ролям доступа, а формулировки в документах не всегда совпадают с языком пользователя.

1. Первичный гибридный поиск с фильтрами по продуктовой линии и языку возвращает 40 кандидатов.
2. Реранкер получает пары из запроса и текста каждой статьи или отдельного фрагмента статьи.
3. Он пересчитывает оценки так, чтобы выше оказались материалы именно про партнерский портал, а не любые статьи, где просто встречается SSO.
4. В интерфейс выводят верхние 5 результатов, а в RAG-пайплайн передают только верхние 3 фрагмента.

Что это дает на практике: статья «Настройка SSO для внутреннего портала сотрудников» может быть найдена на первом этапе из-за совпадения терминов, но при реранкинге опустится ниже. А статья «Подключение федерации входа для партнеров» может подняться выше, даже если ее формулировка не повторяет запрос дословно. Но есть важный предел: если нужная статья не попала в топ-40 на первом этапе, реранкинг ее уже не спасет. Поэтому сначала надо проверить качество кандидатов, а потом улучшать их порядок.

Заблуждения и ограничения

• «Реранкинг всегда улучшает поиск». Нет. Если первичный поиск не находит нужные документы, пересортировывать нечего. Сначала нужен достаточный recall.
• «Это замена BM25 или векторному поиску». Нет. Обычно это дополнение ко второму этапу, а не альтернатива первичному извлечению.
• «Можно просто увеличить число кандидатов и качество вырастет». Не обязательно. Большой список повышает задержку и может добавить шум. Подбирать размер набора кандидатов нужно по задаче и бюджету по латентности.
• «Нейросетевой реранкер всегда лучше». Не всегда. В задачах с жесткими бизнес-правилами, сильными структурными признаками и требованиями к объяснимости модель Learning to Rank или даже прозрачная формула могут быть практичнее.
• «Реранкинг подходит для любого ответа». Нет. Если итог определяется почти полностью фильтрами, сортировкой по цене, наличию или SLA, семантическая пересортировка может только мешать.
• «Проблема только в качестве». На практике есть и инфраструктурные ограничения: стоимость вычислений, лимиты на длину текста, приватность данных, требования к локальному размещению модели и поддержка нескольких языков.

Еще одно ограничение — объяснимость. Чем сложнее реранкер, тем труднее объяснить пользователю или внутреннему заказчику, почему один документ оказался выше другого. В regulated-средах это может быть критично. Поэтому для production-систем полезно заранее решить, какие сигналы допустимы, где нужны логи причин ранжирования и можно ли использовать внешние API для текста документов.

Частые вопросы

Чем реранкинг отличается от первичного поиска?

Первичный поиск быстро находит кандидатов во всем индексе. Реранкинг работает только по этому ограниченному списку и точнее определяет порядок результатов. Первый этап оптимизируют под охват и скорость, второй — под качество верхних позиций.

Нужен ли реранкинг в RAG?

Часто да, если в базе много близких по смыслу документов и ошибки в верхних фрагментах портят ответ модели. Но при маленьком корпусе, строгих фильтрах или очень коротких фактах дополнительный этап может быть избыточным.

Сколько кандидатов отправлять на реранкинг?

Универсального числа нет. Обычно выбирают столько, сколько позволяет задержка и насколько хорошо первичный поиск покрывает релевантные документы. Практический подход — начать с ограниченного диапазона, например десятков кандидатов, и проверить, не теряется ли нужный документ до реранкинга.

Можно ли обойтись без нейросети?

Да. Реранкинг можно делать правилами, формулами или моделью Learning to Rank на инженерных признаках. Это особенно разумно, когда важны предсказуемость, объяснимость и низкая стоимость вычислений.

Связанные понятия

• Ретривер. Компонент, который находит кандидатов для последующей обработки.
• Гибридный поиск. Комбинация лексического и векторного поиска для лучшего охвата кандидатов.
• Learning to Rank. Класс моделей, которые учатся ранжировать документы по признакам и историческим данным.
• Cross-encoder. Модель, оценивающая запрос и документ совместно; часто применяется именно как реранкер.
• Recall и precision. Метрики охвата и точности. Ретривер обычно борется за recall, а реранкер — за качество верхних результатов.
• RAG. Подход, в котором генеративная модель отвечает на основе найденных документов; качество реранкинга напрямую влияет на полезность контекста.