Rerank (переранжирование) работает на последнем участке поисковой цепочки: сначала векторный или гибридный поиск находит десятки или сотни кандидатов, затем cross-encoder попарно оценивает запрос и документ и выводит действительно полезные фрагменты наверх. Он не генерирует текст, но заметно исправляет ситуацию «ответ находится на десятом месте».

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

Примечание: Cohere, Jina, Voyage, Qwen, BGE, Weaviate, Milvus, Elasticsearch и другие названия — товарные знаки их правообладателей; статья носит технический характер. Возможности, лимиты и условия продуктов меняются; перед подключением сверяйтесь с документацией соответствующего поставщика.

1. Сначала убедитесь, что узкое место — в реранкинге

Не всякий слабый результат RAG стоит исправлять реранкингом. Обратите внимание на три сигнала: правильный фрагмент находится поиском, но часто стоит после пятого места; после гибридного поиска первые строки явно зашумлены, и совпадение ключевых слов перевешивает семантику; генеративный ответ ссылается на неверный абзац, а при ручной подстановке правильного абзаца отвечает верно.

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

2. Что представляют собой три пути

Хостинговый Rerank API: поставщик упаковывает модель и инференс в интерфейс, который обычно принимает query, documents, top_n и возвращает индексы и оценки в порядке релевантности. Плюсы — быстрое подключение, обычно хорошее многоязычное покрытие, не нужен GPU; минусы — данные покидают вашу сеть, действуют лимиты и формат поставщика, а долгосрочная стоимость растёт с объёмом вызовов.

Открытый cross-encoder: модель разворачивается на своём GPU или сервисе вывода. Частые варианты — семейство BGE reranker, Qwen3-Reranker, Jina Reranker. Плюсы — данные не выходят за периметр, возможна дообучение и фиксация версии; минусы — GPU, масштабирование, обновление моделей и поддержка фреймворка на вас. vLLM, TEI и подобные фреймворки уже предоставляют интерфейс реранкинга и сокращают объём адаптации.

Встроенный реранкинг векторной БД: некоторые векторные базы предлагают встроенную или интегрированную возможность переранжирования — например, модуль rerank в Weaviate, rerank retriever в Elasticsearch, функцию rerank в новых версиях Milvus; другие продукты только ищут, передавая реранкинг внешнему сервису. Плюсы — меньше сетевых переходов, единые границы прав и эксплуатации; минусы — выбор модели ограничен продуктом, возможностей тонкой настройки меньше.

Важно учитывать: у Rerank нет единого стандарта, совместимого с OpenAI Chat Completions. У Jina, Cohere и Voyage поля различаются — например, top_n против top_k, возврат текста документа, параметры усечения одного документа; endpoint тоже может быть /v1/rerank или /v2/rerank. При смене поставщика адаптация протокола часто занимает больше времени, чем сама модель.

3. Как сравнивать по шести измерениям

По качеству и хостинговый API, и открытая модель могут быть cross-encoder; разница скорее в обучающих данных, языковом распределении и версии. Не ограничивайтесь публичными рейтингами — оценивайте на своих бизнес-запросах и наборе кандидатов. Встроенная возможность векторной базы, если вызывает модель того же класса, обычно близка по эффекту, но настраиваемых параметров меньше.

По задержке время реранкинга примерно растёт с «числом кандидатов × длиной документа». Хостинговый API добавляет один выход в публичную сеть и подходит для небольших наборов со стабильным параллелизмом; собственное развёртывание убирает внешнюю зависимость, но добавляет очередь GPU; встроенный вариант экономит сетевой переход, но может конкурировать с поиском за те же ресурсы.

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

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

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

По эксплуатации хостинг передаёт обновление модели и масштабирование поставщику, но вы управляете ключами, лимитами и различиями поставщиков; собственное развёртывание требует дежурства на GPU и обновления драйверов и фреймворков; встроенный вариант объединяет две системы, но и домен отказа становится более концентрированным.

4. Выбор по сценарию

Сценарий Рекомендуемый путь Причина На что обратить внимание
Быстрая проверка, десятки кандидатов Хостинговый Rerank API Подключение за день, GPU не нужен Сначала подтвердите допустимость передачи данных
Преимущественно китайский, чувствительные данные Открытая модель на своём сервере Можно изолировать, выбрать сильную китайскую модель Заложить GPU и эксплуатационный персонал
Уже используется векторная БД, задача простая Встроенный реранкинг Меньше интеграции, единые права Убедитесь, что модели и параметров достаточно
Высокий параллелизм, чувствительность к задержке Своё развёртывание или встроенный вариант в том же регионе Нет выхода в публичную сеть и очереди Проведите нагрузочный тест, смотрите не только среднее
Много языков, редкие языки Хостинговый API или сильная многоязычная открытая модель Проще языковое покрытие Проверьте на наборе с редкими языками
Малый объём, нет GPU у команды Хостинговый API Ниже фиксированные затраты Настройте бюджет и оповещения о лимитах

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

5. Как оценивать качество, а не полагаться на ощущения

Подготовьте как минимум три вещи: набор реальных запросов, разметку правильного документа для каждого запроса и текущий набор кандидатов. Смотрите Recall@k, MRR или nDCG, а не только «кажется, стало релевантнее». Выгрузите одних и тех же кандидатов до и после реранкинга, выборочно проверьте первые десять вручную и запишите тип ошибки: потеря при поиске, разрыв при нарезке или смещение правильного абзаца вниз реранкером.

Код Python ниже делает одну вещь: сравнивает, попал ли правильный документ в первые k позиций до и после реранкинга. Он не зависит от поставщика; на входе два отсортированных списка индексов.

def hit_rate(cases, k):
    hits = 0
    for gold, ranked in cases:
        if gold in ranked[:k]:
            hits += 1
    return hits / len(cases)

# cases: [(индекс правильного документа, список индексов после реранкинга), ...]
before = hit_rate(baseline_cases, 5)
after = hit_rate(reranked_cases, 5)
print(f"Recall@5: {before:.3f} -> {after:.3f}")

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

6. Чек-лист миграции

При переходе от одного Rerank API к другому или с хостинга на собственное развёртывание действуйте по порядку:

  1. Зафиксируйте оценочный набор и текущую базовую линию: Recall@k, MRR, задержку p95 и стоимость вызова.
  2. Уточните endpoint, способ аутентификации и поля запроса нового решения, особенно top_n и top_k, возврат текста и параметры усечения.
  3. Согласуйте семантику оценок: нормированная релевантность от нуля до единицы или ненормированные logits, сортировка по возрастанию или убыванию; не смешивайте пороги.
  4. Проверьте лимиты на число документов, токены одного документа, размер тела и параллелизм; при превышении делите запрос на клиенте, а не ждите ошибки интерфейса.
  5. Реализуйте повторы и деградацию для тайм-аутов, 429 и 5xx; при деградации сохраняйте исходный порядок поиска, чтобы не ронять всю цепочку.
  6. Сравните старое и новое результаты на теневом трафике, наблюдайте минимум неделю, фиксируйте различия порядка и качества ответов.
  7. Включайте постепенно и задайте порог отката, например при превышении доли ошибок или p95 относительно базовой линии.
  8. Обновите мониторинг и методику счёта, убедитесь, что повторы, кэш и офлайн-оценка учтены.

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

Чем Rerank API отличается от Embedding API?

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

Открытая модель реранкинга всегда дешевле хостингового API?

Нет. При малом объёме фиксированная стоимость GPU и трудозатраты обычно выше оплаты по факту; при большом объёме, чувствительных данных или требованиях к настройке собственное развёртывание легче распределяет затраты. Учитывайте расширение на пиках.

Достаточно ли встроенного реранкинга векторной базы?

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

Как выбрать модель реранкинга для китайского языка?

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

Нужно ли перекалибровать порог оценок после смены сервиса?

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

Что дальше

Если нужно сначала просто проверить цепочку, создайте тестовый ключ в ZSQH AI Gateway, сравните качество поиска до и после реранкинга на одном наборе запросов, а затем оцените стоимость по странице тарифов. Доступность моделей и методика тарификации — по странице тарифов.

Связанные статьи: