Содержание
  1. Карта выбора под ограничения приложения
  2. Ручной эталон и фактический выход модели
  3. Проверка положительного и отрицательного случаев
  4. Продуктовый путь, API и условия доступа
  5. Границы применимости и критерии приёмки
  6. Частые вопросы
Подборки и сравнения

Реранкеры для поиска: как выбрать модель

7 ноября 2026 · 9 минут чтения

Реранкеры для поиска: как выбрать модель — значит сопоставить тип входа, язык корпуса, способ запуска и входной лимит с условиями приложения, а затем проверить выбор на учебном наборе пар запрос-документ с ручным эталоном. Универсального победителя здесь нет: локальный cross-encoder, облачный rerank API и listwise-модель решают разные задачи.

Карта выбора под ограничения приложения

Начните с четырёх вопросов о приложении. Первый: где живут пары «запрос — документ» — на вашем железе или у внешнего провайдера. Второй: на каком языке корпус и запросы. Третий: какой тип входа — текст, изображения, таблицы, код. Четвёртый: какой входной лимит выдерживает ваш конвейер.

Документация Sentence Transformers описывает cross-encoder как модель, которая считает оценку сходства для пар входов и обычно даёт более высокое качество, чем bi-encoder, ценой скорости: вычисление идёт для каждой пары. По этой причине cross-encoder применяют для переранжирования top-k результатов, уже полученных от более быстрой модели. Библиотека Sentence Transformers позволяет загружать разные модели.

Документация Cohere описывает Rerank как вторую ступень: первый этап — лексический или семантический поиск, второй — эндпоинт переранжирования. В примере Cohere вызов co.rerank() принимает query, documents, top_n и model; в документации указана модель rerank-v5.0-pro. Модели rerank поддерживают 100+ языков, а также полуструктурированные данные — письма, счета, JSON, код и таблицы; поля учитываются в порядке их появления в YAML-строке.

Страница Jina Reranker описывает трёхшаговую схему: первичный поиск по эмбеддингам или BM25, затем переранжирование с анализом взаимодействия запроса и документа, затем выдача переупорядоченных результатов. Там же приведено сравнение reranker, векторного поиска и BM25 по критериям: лучший сценарий, гранулярность, сложность во время запроса, сложность индексации, сложность обучения и качество поиска.

Соберите эти сведения в карту выбора. Она заполняется под ограничения вашего проекта.

Ограничение приложения Подходящий маршрут Что проверить до запуска
Пары «запрос — документ» обрабатываются локально CrossEncoder из Sentence Transformers model card выбранной модели, поддержка языка, входной лимит
Нужен облачный rerank API Cohere Rerank или Jina Reranker язык, идентификатор модели, точный входной лимит
Кандидаты — изображения или визуально насыщенные документы Мультимодальный реранкер поддержка модальностей через model.modalities и model.supports()
Полуструктурированные данные: письма, JSON, таблицы Реранкер с поддержкой таких данных порядок полей в сериализации
Нужен listwise-подход Listwise-модель входной контекст на запрос и все документы

Проверьте входной лимит по документации конкретного владельца. У Jina в разделе вопросов указаны разные контексты: у jina-reranker-v3.5 — 131 072 токена на запрос и все документы вместе с автоусечением, у jina-reranker-v2-base-multilingual — 1 024 токена с автоматическим разбиением длинных документов, у jina-colbert-v2 — 8 192 токена. Там же сказано, что hosted API может применять другой контекст, чем поддерживает архитектура модели.

Ручной эталон и фактический выход модели

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

Учебный вход для этой статьи выглядит так. Полный запрос: «Какой лимит заявок проекта?». Документ D1: «Лимит проекта — 12 заявок в день». Документ D2: «Лимит скорости в городе — 30 км/ч». Документ D3: «Проект завершён в прошлом квартале». Ручная градация: D1 = 2 как прямой ответ, D2 = 0, D3 = 0. Эталон фиксирует D1 выше D2 и D3. Взаимный порядок D2 и D3 не фиксируется, поскольку оба не отвечают на вопрос.

Добавьте контрольный нерелевантный документ D4: В настольной игре лимит — 12 карт у игрока. Ручная оценка D4 = 0: это другая сфера, несмотря на совпадение числа 12. Такой контроль ловит модель, которая цепляется за числовое совпадение.

Отдельно разберите документ «Лимит проекта отменён». Он может быть очень релевантен вопросу. Реранкер оценивает релевантность, а истинность, дату и приоритет источников проверяют отдельно. Утверждение об отмене лимита, которое прямо отвечает на вопрос, нельзя объявлять нерелевантным только за противоречие другому источнику.

Ручные оценки нужно отличать от непроведённого прогона. Пока вы не запустили модель на этих парах, у вас есть эталон и нет фактического выхода. Оценки моделей не придумывают: их получают прогоном на вашем наборе.

Проверка положительного и отрицательного случаев

Соберите набор из четырёх документов выше и прогоните его через выбранный маршрут. Ниже — учебный скрипт для локального cross-encoder. Он читает идентификатор модели из переменной окружения, чтобы не хранить его в коде, и печатает пары с оценками.

PYTHON19 строк
import os
from sentence_transformers import CrossEncoder

MODEL_ID = os.environ["RERANK_MODEL_ID"]

query = "Какой лимит заявок проекта?"
documents = [
    "Лимит проекта — 12 заявок в день",
    "Лимит скорости в городе — 30 км/ч",
    "Проект завершён в прошлом квартале",
    "В настольной игре лимит — 12 карт у игрока",
]

model = CrossEncoder(MODEL_ID)
pairs = [[query, doc] for doc in documents]
scores = model.predict(pairs)

for doc, score in sorted(zip(documents, scores), key=lambda x: x[1], reverse=True):
    print(f"{score:.4f}\t{doc}")

Ожидаемый результат по ручному эталону: D1 стоит выше D2, D3 и D4. Порядок D2, D3 и D4 между собой не фиксирован. Если D4 обошёл D1, модель не прошла этот контроль релевантности. Причину ошибки проверяют отдельно по входам, настройкам и результату модели.

Документация Sentence Transformers предупреждает: модели MS Marco возвращают логиты. Для оценок в диапазоне от 0 до 1 модель загружают с activation_fn=torch.nn.Sigmoid(). На ранжирование это не влияет. В примере документации запрос «How many people live in Berlin?» получает по паре с абзацем о населении Берлина оценку 8.61, а по паре с фразой о музеях — минус 4.32. Отрицательные значения здесь нормальны.

Документация BAAI для bge-reranker-v2-m3 описывает тот же принцип: реранкер принимает вопрос и документ и сразу выдаёт сходство вместо эмбеддинга, а оценку можно привести к значению от 0 до 1 сигмоидой.

Проверьте оба случая: положительный D1 и отрицательный D4. Зафиксируйте, какой документ оказался первым, и сравните с эталоном. Так вы получаете проверяемое утверждение о своём наборе.

Продуктовый путь, API и условия доступа

Облачный маршрут начинается с ключа. Документация Cohere показывает создание клиента cohere.ClientV2 с ключом API. Страница Jina описывает единый ключ для всех своих API: Reader, Embeddings, Reranker, Classifier и Segmenter, с общим балансом токенов. Там же указано, что ключи не имеют срока истечения, а скомпрометированный ключ отзывают в панели управления.

Лимиты запросов у Jina зависят от типа ключа: бесплатный — 100 запросов в минуту и 100 000 токенов в минуту, платный — 500 и 2 000 000, премиальный — 5 000 и 50 000 000. Действует и ограничение по IP: 10 000 запросов за 60 секунд. Те же лимиты применяются к Embeddings и Reranker. Батч-лимита на число документов в запросе нет: API группирует входы внутри по количеству токенов.

Пути размещения у Jina описаны отдельно. Хостируемый API работает по подписке с оплатой за токены. Модели доступны на маркетплейсах AWS, Azure и GCP для развёртывания в вашем облачном аккаунте. Для самостоятельно управляемой инфраструктуры, включая изолированную, Elastic продаёт коммерческую лицензию Jina On-Prem с моделями в виде офлайн-контейнеров.

Лицензии различаются по моделям. У jina-reranker-v3.5, jina-reranker-v3, jina-reranker-m0, jina-reranker-v2-base-multilingual и jina-colbert-v2 указана CC-BY-NC 4.0: некоммерческое использование, распространение и адаптация разрешены, коммерческое применение требует лицензии. Устаревшие модели jina-reranker-v1-* остаются под Apache-2.0. У BAAI/bge-reranker-v2-m3 в карточке модели указана лицензия apache-2.0.

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

Границы применимости и критерии приёмки

Качество, скорость, приватность и юридическая достаточность зависят от вашего корпуса, железа и договора. Обещать их заранее нельзя.

По скорости ориентируйтесь на опубликованные данные владельца. Страница Jina приводит таблицу времени для одного запроса и 100 документов: при документе в 256 токенов и запросе в 64 токена — около 156 миллисекунд, при документе в 4096 токенов и запросе в 512 токенов — около 7068 миллисекунд. Это опубликованные значения провайдера.

По качеству опирайтесь на собственный прогон. Владельцы публикуют свои метрики: в релизной заметке Jina для jina-reranker-v3.5 указано 63.20 nDCG@10 на BEIR, а для jina-reranker-v3 — 61.94 nDCG@10. Эти числа относятся к их условиям оценки.

Сформулируйте критерии приёмки до прогона. Рабочий набор критериев:

Критерий Как проверяется Что фиксируется
Прямой ответ выше нерелевантных D1 стоит выше D2, D3, D4 позиция D1
Отрицательный контроль не проходит D4 не первый позиция D4
Язык корпуса поддержан прогон на реальных запросах доля корректных пар
Входной лимит выдержан длина запроса и документов усечение или разбиение
Лицензия подходит под использование карточка модели тип лицензии
Условия доступа соблюдены тип ключа и лимиты запас по RPM и TPM

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

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

Как выбрать между локальным cross-encoder и облачным rerank API?

Локальный маршрут подходит, когда пары «запрос — документ» обрабатываются на вашем железе и вы готовы платить временем за вычисление по каждой паре. Облачный маршрут подходит, когда нужен управляемый сервис с ключом и лимитами. Документация Sentence Transformers описывает cross-encoder как модель для переранжирования top-k. Документация Cohere описывает Rerank как вторую ступень после первичного поиска.

Что такое listwise-реранкинг?

В listwise-архитектуре запрос и все кандидаты попадают в одно контекстное окно и оцениваются за один прямой проход, поэтому модель сравнивает документы между собой. Точечные реранкеры оценивают каждую пару «запрос — документ» независимо от остальных документов. В разделе вопросов Jina сказано, что listwise-оценка точнее, поскольку релевантность часто относительна к составу набора кандидатов.

Как проверить реранкер на своём наборе?

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

Почему оценки модели бывают отрицательными?

Модели MS Marco возвращают логиты. Документация Sentence Transformers предлагает загружать такую модель с activation_fn=torch.nn.Sigmoid(), чтобы получить оценки в диапазоне от 0 до 1. На порядок документов это не влияет. В примере документации пары получают значения 8.61 и минус 4.32.

Можно ли запустить реранкер на своём сервере?

Да. Страница Jina указывает развёртывание на AWS, Azure и GCP в вашем облачном аккаунте, а для самостоятельно управляемой и изолированной инфраструктуры — коммерческую лицензию Jina On-Prem с офлайн-контейнерами. Лицензия CC-BY-NC 4.0 требует коммерческого соглашения для продуктового использования. Модель BAAI/bge-reranker-v2-m3 распространяется под apache-2.0.

Читайте также

3 материала