Reranking (переранжирование)

Переранжирование (reranking) — это второй этап поиска, который не ищет новые документы, а пересортировывает уже найденные по смысловой релевантности к запросу. В RAG и поисковых системах его обычно ставят после первого отбора кандидатов: сначала быстрый поиск возвращает набор документов или чанков, затем reranker поднимает наверх наиболее уместные.

Английский термин: reranking. В документации также встречается форма rerank. По состоянию на 2026-08-18 официальные страницы Cohere, Azure AI Search и Pinecone описывают его именно как second-stage или семантическое переупорядочивание кандидатов, а не как отдельный полнотекстовый поиск по всему индексу.

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

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

Поэтому переранжирование нужно там, где «примерно подходящие» результаты уже есть, но их порядок ещё можно заметно улучшить.

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

Классическая идея стала стандартом после работы Passage Re-ranking with BERT (2019): модель оценивает не документ сам по себе, а пару «запрос + passage». Позднее исследование про BERT в ранжировании отдельно подтвердило, что это именно interaction-based ranking model: качество строится на совместном рассмотрении запроса и кандидата.

Запрос пользователя
  ↓
Первичный поиск / retrieval в индексе
  ↓
N кандидатов (документы, passage, чанки)
  ↓
Reranker оценивает пары:
(query + candidate_1), (query + candidate_2), ...
  ↓
Оценки релевантности
  ↓
Новый порядок результатов
  ↓
Top-k для выдачи или для RAG

1. Первый этап быстро находит кандидатов. Это может быть обычный поиск, гибридный поиск или retrieval в пайплайне RAG.
2. Второй этап получает запрос и каждый кандидат как отдельную пару и вычисляет, насколько кандидат отвечает именно на этот запрос.
3. Сортировка строится заново уже по смысловой релевантности, а не только по сигналам первого поиска.
4. Дальше верхние результаты уходят либо в интерфейс поиска, либо в контекст для генерации ответа.

У разных сервисов этот этап устроен по-разному в деталях, но принцип одинаков. Например, Azure AI Search semantic ranker переранжирует только уже имеющиеся top 50 результатов и добавляет поле @search.rerankerScore по шкале от 4.0 до 0.0. В Pinecone прямо отмечено, что rerankers медленнее retrieval, поэтому рекомендуется двухэтапный процесс. В Cohere публичный API вызывается через POST /v2/rerank.

Для длинных документов важно помнить о лимитах. У Cohere v4.0 контекстное окно rerank-моделей — 32,768 токенов; длинные документы автоматически режутся на части, а сервис вернёт ошибку, если число документов, умноженное на максимальное число чанков на документ, превышает 10,000. Это делает качество лучше на длинном тексте, но одновременно влияет на лимиты и биллинг.

Где применяется

• RAG для базы знаний. Сначала вы находите набор кандидатных фрагментов, затем reranker выбирает те, которые действительно стоит отправить в промпт модели. Это особенно полезно, когда retrieval приносит много «почти подходящих» чанков.
• Корпоративный и сайт-поиск. В Azure semantic ranker используется поверх уже найденных результатов поиска и может возвращать не только @search.rerankerScore, но и extractive captions или answers.
• Мультиязычный поиск. Cohere rerank-v4.0-pro и rerank-v4.0-fast, а также Pinecone bge-reranker-v2-m3 заявлены как multilingual, поэтому их используют там, где запросы и документы не ограничены одним языком.
• Полуструктурированные записи. Cohere v4.0 поддерживает semi-structured JSON data, так что можно переранжировать не только чистые абзацы текста, но и записи с полями вроде названия, описания и метаданных.

Практический пример

Ниже — минимальный сценарий по официальному quickstart Cohere: вы устанавливаете SDK, создаёте ClientV2, передаёте список документов и запрос в co.rerank(...), а затем проверяете порядок через results.results.

pip install cohere

import cohere

co = cohere.ClientV2()

documents = [
    "Сброс пароля в корпоративном портале",
    "Настройка SSO для сотрудников",
    "Политика возврата и обмена"
]

results = co.rerank(
    model="rerank-v4.0-pro",
    query="как настроить SSO",
    documents=documents,
)

print(results.results)

1. Соберите кандидатов на первом этапе поиска.
2. Передайте только этот набор в reranker, а не весь индекс.
3. Проверьте новый порядок результатов в results.results.
4. Если документы длинные, заранее учитывайте влияние chunking на лимиты и на стоимость.

Практический нюанс: у Cohere один Rerank search unit — это один запрос с количеством до 100 документов, но длинные документы режутся на части, и каждый chunk учитывается в общем document count для биллинга. Для trial-ключей Cohere публикует лимит 10 requests per minute, для production-ключей — 1,000 requests per minute.

Практический вердикт: переранжирование имеет смысл тогда, когда у вас уже есть разумный первый этап поиска и нужно улучшить порядок кандидатов перед выдачей или генерацией ответа. Использовать его как замену retrieval по всему корпусу по этим источникам не предполагается.

Чем отличается от…

Ограничения и заблуждения

• Заблуждение: «reranking сам ищет документы». Нет. Если нужного документа нет среди кандидатов первого этапа, reranker не сможет поднять его наверх.
• Заблуждение: «оценки score универсальны». Нет. В Azure semantic ranker шкала @search.rerankerScore идёт от 4.0 до 0.0, а у Pinecone pinecone-rerank-v0 score для пары query-document лежит в диапазоне от 0 до 1. Жёсткие пороги нужно перепроверять при смене модели или сервиса.
• Ограничение: задержка. Pinecone прямо рекомендует двухэтапный retrieval flow, потому что rerankers медленнее простого отбора кандидатов.
• Ограничение: лимиты на длину и объём. У Cohere v4.0 контекстное окно 32,768 токенов, но длинные документы режутся автоматически; у bge-reranker-v2-m3 в Pinecone — до 1024 токенов на пару query-document и максимум 100 документов; у pinecone-rerank-v0 — максимум 512 токенов контекста и тоже до 100 документов.
• Ограничение: доступность и цены зависят от сервиса. Azure semantic ranker доступен только в отдельных регионах. Для Pinecone в захваченном source pack не было полной универсальной матрицы регионов и не был виден живой долларовый прайс для всех reranker-моделей, поэтому бюджет лучше считать только по актуальной официальной странице.

Редакционное ограничение: этот материал не даёт единой мировой таблицы цен и региональной доступности. В самом source pack отмечено, что для Cohere, Azure и Pinecone эти параметры нужно перепроверять в официальных страницах сервиса и консоли на момент внедрения.

Связанные термины и материалы

• RAG (Retrieval-Augmented Generation) — основной сценарий, где reranking помогает выбрать лучший контекст для ответа.
• Chunking (разбивка текста) — влияет на то, какие куски документа вообще попадут в reranker.
• Fine-tuning (дообучение) — отдельная тема: меняет модель, а не порядок уже найденных кандидатов на этапе запроса.
• Reasoning model (модель рассуждений) — полезно отличать от reranker: рассуждающая модель отвечает, а reranker помогает выбрать, что ей показать.

Источники

• Release Notes | Cohere
• Pricing | Secure and Scalable Enterprise AI | Cohere
• Different Types of API Keys and Rate Limits | Cohere
• Pricing | Pinecone
• GitHub – cohere-ai/cohere-python: Python Library for Accessing the Cohere API
• Releases · pinecone-io/python-sdk · GitHub

• Rerank API (v2) | Cohere
• Cohere’s Rerank Model (Details and Application)
• Best Practices for using Rerank | Cohere
• Reranking – quickstart | Cohere
• Semantic Ranking Overview – Azure AI Search | Microsoft Learn
• Add Semantic Ranking – Azure AI Search | Microsoft Learn
• Rerank results – Pinecone Docs
• bge-reranker-v2-m3 – Pinecone Docs
• pinecone-rerank-v0 – Pinecone Docs
• Passage Re-ranking with BERT
• Understanding the Behaviors of BERT in Ranking

Вопросы и ответы

Reranking — это поиск по всему индексу?

Нет. По этим источникам reranking — это второй этап: он пересортировывает уже найденных кандидатов. Azure semantic ranker, например, работает только с текущими top 50 результатами.

Сколько документов можно отдать на переранжирование?

Лимит зависит от сервиса. Azure reranks top 50. У Pinecone для моделей bge-reranker-v2-m3 и pinecone-rerank-v0 заявлен максимум 100 документов. У Cohere биллинг определяет один search unit как один запрос до 100 документов, но при длинных документах учитываются и автоматически созданные chunks.

Что делать с длинными документами?

Их нужно учитывать отдельно. В Cohere длинные документы chunked automatically, а число чанков влияет и на лимиты, и на billing. На практике это связывает reranking с качеством предварительного chunking.

Можно ли сравнивать score разных reranker-моделей напрямую?

Не стоит. Даже в официальных документах шкалы различаются: Azure использует 4.0–0.0, а pinecone-rerank-v0 — 0–1. Порог, который работает в одном сервисе, не следует переносить в другой без повторной проверки.

Нужен ли reranking в каждом RAG-пайплайне?

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