Rerank — второй этап ранжирования в цепочке поиска: сначала векторный или ключевой поиск кандидатов, затем модель переранжирования оценивает каждый документ и оставляет самые релевантные для контекста большой модели. Он решает проблему «кандидатов много, а в начале не то», но не проблему «ничего не найдено».

Ниже — конечная точка и аутентификация, запрос и ответ, top_n и размер кандидатского набора, интеграция с векторным поиском, задержка и деградация, типовые ошибки и метрики оценки. Модели и цены — на странице тарифов.

Примечание: Cohere, Jina AI, BAAI, Alibaba Cloud и другие названия принадлежат их правообладателям и приведены для технического пояснения. ZSQH AI Gateway не связан с этими компаниями отношениями подчинения; интерфейс, модели и биллинг — по информации на сайте.

1. Место переранжирования в цепочке поиска

Типичный RAG-поиск состоит из трёх этапов: отбор кандидатов, переранжирование, генерация. Отбор стремится к скорости и полноте, переранжирование — точность, генерация использует только отфильтрованный контекст.

Этап Типичный метод Вход Выход Основная метрика
Отбор Векторный поиск, BM25, гибридный поиск Запрос пользователя 30–100 кандидатов Recall@k
Переранжирование Модель Rerank Запрос + кандидаты 5–10 документов nDCG@10
Генерация Большая языковая модель Переранжированный контекст Ответ Точность, верность источнику

Модель переранжирования обычно является кросс-энкодером: читает запрос вместе с каждым документом и выдаёт оценку релевантности. Это точнее векторного сходства, но медленнее. Её место — после отбора, а не вместо него.

2. Интерфейс, аутентификация и параметры запроса

Конечная точка переранжирования ZSQH AI Gateway:

POST https://ai.zhongshangqihang.com/v1/rerank

Аутентификация — Authorization: Bearer <key>, тело запроса — JSON. Шлюз также совместим с путём /rerank. Создание ключа и настройки безопасности описаны в отдельном руководстве.

Параметр Обязателен Описание
model Да Имя модели переранжирования — по списку моделей на сайте
query Да Запрос пользователя, не может быть пустым
documents Да Массив документов-кандидатов, обычно строки; структура объектов зависит от вышестоящего сервиса
top_n Нет Число возвращаемых документов; задавайте явно, не полагайтесь на значение по умолчанию
return_documents Нет Возвращать ли содержимое документов в результате
max_chunk_per_doc Нет Предел фрагментов длинного документа; поддержка зависит от вышестоящего сервиса
overlap_tokens Нет Перекрытие токенов при разбиении; уточняйте в документации

Большинство реализаций принимают массив строк; часть платформ — объекты с полем text. Перед миграцией проверьте формат минимальным запросом, не переносите пакет вслепую.

3. Запрос и ответ: Python и curl

Пример на Python: сначала отбор, затем переранжирование:

import os
import requests

api_key = os.environ["RERANK_API_KEY"]
base_url = "https://ai.zhongshangqihang.com/v1"

documents = [
    "Пробный период составляет 14 дней; до окончания можно запросить продление.",
    "Поддерживается безналичный перевод и оплата через гаранта платформы.",
    "Счёт выставляется в течение 3 рабочих дней после оплаты.",
]

resp = requests.post(
    f"{base_url}/rerank",
    headers={"Authorization": f"Bearer {api_key}"},
    json={
        "model": "имя-вашей-модели-rerank",
        "query": "Сколько длится пробный период?",
        "documents": documents,
        "top_n": 2,
        "return_documents": False,
    },
    timeout=20,
)
resp.raise_for_status()

for item in resp.json()["results"]:
    print(item["index"], item["relevance_score"], documents[item["index"]])

Тот же запрос через curl:

curl "https://ai.zhongshangqihang.com/v1/rerank" \
  -H "Authorization: Bearer $RERANK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "имя-вашей-модели-rerank",
    "query": "Сколько длится пробный период?",
    "documents": ["Пробный период 14 дней.", "Поддерживается безналичный перевод."],
    "top_n": 2
  }'

В ответе results уже отсортирован по убыванию релевантности, каждый элемент содержит:

  • index: индекс документа в исходном массиве documents, а не место в рейтинге. По нему нужно возвращаться к исходному тексту.
  • relevance_score: оценка релевантности, обычно нормализована в диапазон 0–1, но это не вероятность и не линейная разница.
  • document: может возвращаться только при return_documents: true; структура зависит от вышестоящего сервиса.
  • usage: расход токенов для сверки счёта и анализа стоимости.

Не используйте relevance_score как готовый порог. При смене модели, языка или типа документов распределение оценок меняется, порог нужно калибровать заново.

4. top_n и размер кандидатского набора

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

Размер кандидатов Сценарий Относительная задержка Замечания
20–30 Небольшая база знаний, низкая задержка Низкая Низкий потолок отбора, легко пропустить ответ
50 Типовая отправная точка для RAG Средняя Сначала оценка, затем изменение
100 Много документов, разнообразные запросы Повышенная Следите за длиной документа и обрезкой
200+ Ценные запросы, офлайн-оценка Высокая Стоимость и задержку оценивайте отдельно

Практика: начинайте с 30–50 кандидатов, top_n — 5–10. Слишком маленький набор ограничивает потолок, слишком большой повышает задержку и расход и может принести шум в контекст. У вышестоящего сервиса могут быть лимиты на число документов и длину одного документа; слишком длинный документ обрежется, и место обрезки может прийтись на ключевое предложение.

Кроме того, часть вышестоящих сервисов при отсутствии top_n возвращает только один результат. В production всегда передавайте top_n явно и не полагайтесь на поведение по умолчанию.

5. Интеграция с векторным поиском

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

  1. При необходимости перепишите запрос, восстановив местоимения и пропуски.
  2. Преобразуйте запрос в вектор моделью Embedding.
  3. Векторный поиск отбирает первые 30–50 документов; параллельно можно запустить ключевой поиск или BM25.
  4. Объедините два списка и удалите дубликаты по ID документа.
  5. До переранжирования отфильтруйте по правам и метаданным, чтобы не отправлять модели недоступные документы.
  6. Вызовите Rerank API с top_n 5–10.
  7. Задайте порог оценки или предельное число документов, соберите контекст и передайте генеративной модели.

Несколько легко упускаемых моментов:

  • Сначала фильтрация, потом переранжирование: права, арендатор, язык и версия должны фильтроваться на этапе отбора или до переранжирования, а не удаляться после генерации.
  • Стабильные ID: переранжирование возвращает индексы, а бизнес-слой должен сопоставлять их с ID документа, заголовком и URL.
  • Переранжирование фрагментов: в RAG обычно переранжируются чанки, а не целые документы. Слишком длинный чанк размывает релевантность, слишком короткий теряет контекст.
  • Гибридный отбор: имена, артикулы и номера надёжнее искать ключевыми словами, семантику — векторами; объединение двух потоков перед переранжированием обычно лучше одного.

6. Задержка, тайм-ауты и деградация

Задержка переранжирования примерно растёт как «число документов × длина документа». Сто коротких документов обычно обрабатываются быстро, несколько сотен длинных заметно замедляют ответ. До запуска измерьте минимум три точки: P50 и P95 при 30, 50 и 100 кандидатах.

Инженерные рекомендации:

  • Задайте отдельный тайм-аут для Rerank, типичная отправная точка — 10–30 секунд, затем уточните по факту.
  • Делайте ограниченные повторы с задержкой только для 429 и 5xx; 401, 403 и 422 не повторяйте.
  • При тайм-ауте или сбое переранжирования деградируйте до порядка векторного отбора, не роняйте весь процесс ответа на вопросы.
  • Кэшируйте результаты для частых и медленно меняющихся запросов; ключ кэша должен включать запрос, ID документов и имя модели.
  • Векторный и ключевой отбор выполняйте параллельно, объединяйте и затем переранжируйте — меньше последовательного ожидания.
  • Интерфейс переранжирования возвращает полный результат сразу и не поддерживает потоковую передачу; не проектируйте фронтенд под streaming.

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

7. Типовые ошибки и диагностика

Код или симптом Частая причина Действие
400 / 422 Пустой query, пустой documents, ошибка структуры JSON Проверьте обязательные поля и тип массива
401 Ключ недействителен, истёк или отсутствует заголовок Сверьте Authorization и статус ключа
403 У ключа нет прав на модель или аккаунт ограничен Проверьте охват модели и статус аккаунта
404 Неверное имя модели или путь Сверьте /v1/rerank и список моделей
429 Лимит параллелизма или квоты Повторите с задержкой, проверьте квоту и лимит частоты
500 / 502 / 504 Сбой или тайм-аут вышестоящего сервиса Ограниченные повторы, затем деградация

Шлюз проверяет query и documents и при пустом значении сразу возвращает ошибку параметров. При диагностике сначала смотрите message в теле ответа, затем журнал запросов; не повторяйте 400 как сетевую ошибку.

8. Оценка: не полагайтесь на «кажется, стало точнее»

До запуска переранжирования подготовьте небольшой размеченный набор: 100–300 реальных запросов, к каждому 1–3 релевантных документа. Если разметки нет, проверьте вручную хотя бы 50 запросов и зафиксируйте два порядка.

Метрика Что показывает Как использовать
Recall@50 Есть ли правильный ответ среди кандидатов Потолок отбора; если низкий — сначала улучшайте отбор
nDCG@10 Качество порядка в первой десятке Сравнение с переранжированием и без
MRR Позиция первого релевантного результата Подходит для вопросно-ответных запросов
Точность ответа Правильность итоговой генерации Сквозная проверка
P95 задержки Насколько медленны редкие запросы Определяет размер кандидатов и тайм-аут
Стоимость запроса Расход на поиск в каждом запросе Оценка по странице тарифов

При оценке держите переменные фиксированными: те же запросы, тот же результат отбора, тот же top_n; меняйте только наличие переранжирования или модель. Затем запустите малый A/B в production и смотрите точность, долю ответов без ответа и задержку. Если после переранжирования стало хуже, проверьте, не потерял ли отбор правильный документ, не обрезан ли документ, подходит ли модель для русского языка и не скопирован ли порог из другого сценария.

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

Может ли Rerank заменить векторный поиск?

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

Каким должен быть top_n?

Для контекста большой модели типичная отправная точка — 5–10 документов; если дальше есть бизнес-фильтрация, можно 20–50. Окончательно — по оценке.

Чем больше кандидатов, тем лучше?

Нет. Больший набор повышает потолок отбора, но одновременно растут задержка, стоимость и шум. Начните с 30–50 и решайте о расширении по Recall@50 и nDCG@10.

Почему с переранжированием стало хуже?

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

Поддерживает ли Rerank потоковый ответ?

Нет. Для полного порядка нужно прочитать весь набор кандидатов, поэтому результат обычно возвращается сразу. Фронтенд должен работать с обычным JSON-запросом и разумным тайм-аутом.

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