Rerank (переранжирование) — одна из самых недооценённых статей затрат в цепочке RAG. Отдельный вызов выглядит недорого, но он выполняется для каждого пользовательского вопроса, а при большом числе кандидатов счёт растёт вместе с количеством запросов и документов.
У разных поставщиков разные единицы тарификации: где-то за запрос, где-то за документ, где-то за токены. Сравнивать «сколько стоит один вызов» бессмысленно — нужно пересчитывать на свой объём запросов, набор кандидатов и длину документов. Ниже разобраны структура тарификации, выбор кандидатов, кэширование и расчёт бюджета без фиксированных цен; актуальные значения — на странице тарифов и в документации поставщика.
Примечание: Cohere, Jina, Voyage, BAAI и другие названия — товарные знаки их правообладателей; статья носит технический характер и описывает структуру тарификации. Единицы, лимиты и цены могут меняться — перед закупкой сверяйтесь с официальной страницей поставщика.
1. Что Rerank делает в цепочке
Типичный двухэтапный поиск выглядит так:
Вопрос пользователя
→ векторный/ключевой поиск: 20–200 кандидатов
→ Rerank: точная сортировка, выбор первых 5–10
→ сборка контекста и передача генеративной модели
На вход Rerank получает «запрос + набор документов-кандидатов», а на выходе отдаёт оценки релевантности и порядок, не генерируя текст. Он решает проблему «нужный фрагмент найден, но стоит десятым, и при простом усечении теряется».
Отсюда понятно место затрат: вызов на каждый поиск, иногда несколько; каждый кандидат проходит через модель. Реранкинг обычно дешевле, чем переход на более крупную генеративную модель, но не бесплатен.
2. Три распространённые модели тарификации
| Модель | Единица | От чего растёт стоимость | Типичный пример | На что смотреть в бюджете |
|---|---|---|---|---|
| За запрос | Один запрос с определённым числом документов | Число запросов; длинные документы после нарезки тоже учитываются | Cohere Rerank | Правила нарезки увеличивают число документов |
| За токены | Токены запроса и документов | Длина запроса, число кандидатов, длина документов | Voyage, Jina и др. | Токены запроса умножаются на число документов |
| За документ или вызов | Каждый документ или каждый запрос | Число документов, число запросов | Часть хостинговых сервисов | Уточните усечение и лимит на вызов |
| Собственный хостинг | Часы GPU и эксплуатация | Параллелизм, размер модели, загрузка | Открытые модели семейства BGE | Фиксированные затраты, важна утилизация |
Cohere тарифицирует по search unit; на странице цен определение звучит как «один запрос, не более 100 документов». Но длинные документы нарезаются, и фрагменты учитываются отдельно. Поэтому «100 документов» не равно «100 тарифицируемым документам»: для баз знаний с длинными текстами оценку нужно строить по числу фрагментов после нарезки.
Voyage тарифицирует по токенам по формуле: токены запроса × число документов + сумма токенов всех документов. Чем длиннее запрос и больше кандидатов, тем сильнее эффект множителя. Поле usage.total_tokens в ответе можно использовать для сверки. Интерфейс принимает до 1000 документов за вызов; слишком длинный вход по умолчанию может усекаться, правила усечения нужно уточнить заранее.
Jina также считает общее число входных токенов, включая запрос и документы; по официальному описанию неудачные запросы не тарифицируются, а при снижении баланса ниже порога доступно автоматическое пополнение. После исчерпания бесплатного лимита начинается платный режим; детали — на странице счёта.
Собственный открытый реранкер (например, семейство BGE) не имеет платы за вызов, но требует GPU, пропускной способности и эксплуатационных затрат. При стабильном и большом трафике собственный хостинг может быть управляемее; при малом или неравномерном трафике фиксированная стоимость GPU часто выше оплаты по факту.
3. Как определить набор кандидатов
Стоимость Rerank примерно растёт с числом документов-кандидатов. Переранжировать все 200 найденных документов обычно в несколько раз дороже, чем 50, и задержка тоже увеличивается.
| Число кандидатов | Относительная стоимость | Задержка | Когда подходит |
|---|---|---|---|
| 20–30 | Низкая | Низкая | Частые обращения в поддержку, чувствительные к задержке интерфейсы |
| Около 50 | Средняя | Средняя | Обычная отправная точка для универсальной базы знаний |
| 100 | Повышенная | Повышенная | Длинные документы, много шума в поиске |
| Более 200 | Высокая | Высокая | Сначала улучшите поиск, не начинайте с этого |
Начинайте примерно с 50 кандидатов, сравнивайте Recall@k и долю правильных ответов на оценочном наборе, а затем решайте, увеличивать или уменьшать число.
Распространённое заблуждение: уменьшение top_n сокращает только число возвращаемых результатов и обычно не уменьшает число тарифицируемых документов. Экономить нужно до передачи в реранкинг, а не после. Фильтрация по метаданным, приблизительное удаление дублей, порог похожести и ограничение документов по бизнес-линии работают лучше, чем усечение результата.
4. Длина документов и нарезка
У многих интерфейсов реранкинга есть лимит токенов на документ, а превышение усекается. Отрезанная часть не участвует в оценке, и можно потерять ключевой абзац — качество ухудшится.
При тарификации по токенам длинный документ дороже; при тарификации по документам длинный текст может быть разрезан на несколько платных документов. В обеих моделях стратегия нарезки влияет и на качество, и на счёт.
- Отправляйте на реранкинг только найденные фрагменты, а не документ целиком.
- Согласуйте размер фрагмента с лимитом модели, не теряя заголовок и важный контекст.
- Удаляйте дубли до индексации, чтобы похожие фрагменты не оплачивались повторно.
- Записывайте распределение токенов по фрагментам и считайте бюджет по P95, а не по среднему.
5. Как уравновесить задержку и стоимость
Rerank увеличивает задержку, и чем больше кандидатов, тем заметнее. Балансировать нужно не одним правилом, а по сценариям:
- Для частых FAQ можно пропускать реранкинг и сразу использовать кэш или ключевой поиск.
- Для чувствительных к задержке интерфейсов ограничьте число кандидатов и сначала примените фильтрацию по метаданным.
- Для офлайн-задач, где важно качество и невысок параллелизм, можно расширить набор кандидатов.
- Задайте клиентский тайм-аут и предел повторов. Повтор после тайм-аута может привести к двойной оплате одного запроса.
- Оценивайте задержку по P95, а не по среднему.
6. Кэш и дедупликация
Кэш Rerank располагается после поиска и до генерации. Ключ кэша должен включать как минимум: нормализованный запрос, идентификатор и версию документа, имя модели, top_n. Если чего-то не хватает, ошибочный результат может уйти другому арендатору.
- Частые вопросы: TTL от часа до суток.
- Быстро обновляемые документы: TTL в минутах или активная инвалидация при обновлении.
- Права доступа: в ключе обязательны арендатор и область прав, попадание между арендаторами недопустимо.
- Неудачные результаты: не кэшировать; отрицательный кэш с коротким TTL тоже требует осторожности.
- Пакетные задачи: одинаковый набор документов в течение дня можно оценивать повторно без нового вызова.
В поддержке и вопросах по внутренним регламентам доля повторных вопросов высока, и кэш часто даёт более прямой эффект, чем переход на более дешёвую модель.
7. Как оценить бюджет
Сначала переведите «стоимость одного запроса» в единицы тарификации целевого поставщика, затем умножьте на объём запросов:
Месячная стоимость ≈ дневное число запросов × 30 × единиц тарификации на запрос × цена
+ повторы и запас на пики
При тарификации по токенам:
Токенов на запрос = токены запроса × число кандидатов + сумма токенов всех кандидатов
Воспроизводимые шаги оценки:
- Возьмите из журналов среднесуточное и пиковое число запросов.
- Выберите 100–200 реальных запросов, посчитайте P50 и P95 для числа кандидатов и токенов документов.
- Переведите каждый запрос в единицы тарификации поставщика.
- Умножьте на дневной объём и 30 дней, добавьте 10–30 % на повторы, рост и пики.
- Умножьте на актуальную цену со страницы тарифов, а не на старый скриншот.
- После запуска сверяйте раз в неделю и корректируйте оценку по фактическим счетам.
# Оценка при тарификации по токенам: цену подставьте со страницы /pricing
QUERY_TOKENS = 60 # медиана по выборке
DOCS_PER_QUERY = 50
AVG_DOC_TOKENS = 180
UNIT_PRICE_PER_MILLION = 0.0 # заглушка, замените фактической ценой
def cost_per_query(q_tokens, n_docs, doc_tokens, price):
total_tokens = q_tokens * n_docs + n_docs * doc_tokens
return total_tokens / 1_000_000 * price
per_query = cost_per_query(
QUERY_TOKENS, DOCS_PER_QUERY, AVG_DOC_TOKENS, UNIT_PRICE_PER_MILLION
)
print(f"Один запрос примерно {per_query:.6f}")
print(f"10 000 запросов в день примерно {per_query * 10_000:.2f}")
Цены, бесплатные лимиты и ступенчатые скидки могут меняться. Цену в скрипте следует читать с текущей страницы тарифов, а не жёстко прописывать в репозитории.
8. Сверка счёта и оповещения
- Разделяйте счёт по ключам, проектам и бизнес-линиям, не смешивайте все вызовы в одном ключе.
- Отдельно записывайте число запросов, кандидатов, токенов, модель и задержку.
- Разделяйте затраты на Embedding, Rerank и генерацию, иначе непонятно, что оптимизировать.
- Следите за повторами, пустыми запросами, повторными отправками с фронтенда и фоновой переиндексацией — это типичные источники пиков.
- Настройте дневной бюджет и оповещение о низком балансе с уведомлением ответственного.
Поля расхода в ответе поставщика можно использовать для сверки; точные имена полей и методику смотрите в документации.
Частые вопросы
Rerank выгоднее, чем более крупная генеративная модель?
В большинстве случаев да. Реранкинг обрабатывает несколько десятков кандидатов, затраты контролируемы, и он напрямую исправляет ситуацию «правильный фрагмент стоит ниже». Но если поиск вообще не нашёл нужный фрагмент, реранкинг не спасёт — сначала исправляйте поиск.
Уменьшение top_n экономит деньги?
Обычно нет. Тарификация считается по переданным кандидатам или токенам, а top_n влияет только на число результатов, возвращаемых генеративной модели. Экономить нужно до реранкинга: сокращать кандидатов, удалять дубли и фильтровать.
Чем больше кандидатов, тем лучше качество?
Не обязательно. Чем больше кандидатов, тем больше шума, выше задержка и стоимость. Сравните Recall@k и долю правильных ответов на оценочном наборе, найдите точку насыщения; частая отправная точка — около 50 документов.
Нужно ли нарезать длинные документы заранее?
Да. Большинство интерфейсов усекают по лимиту токенов, и лишняя часть не участвует в оценке; сервисы с тарификацией по документам могут делить длинный текст на несколько платных документов. При нарезке сохраняйте заголовки и контекст, чтобы не разорвать ответ.
Собственный Rerank всегда дешевле?
Нет. Собственный хостинг убирает плату за вызов, но добавляет GPU, развёртывание, масштабирование и эксплуатацию. При стабильном трафике и высокой загрузке он управляемее; при малом или неравномерном трафике и отсутствии эксплуатационной команды API с оплатой по факту проще.
Что дальше
Сначала соберите статистику по реальным запросам — число кандидатов и длину документов. Затем на ZSQH AI Gateway с небольшим бюджетом прогоните цепочку «поиск — реранкинг — генерация» и сравните качество, задержку и стоимость с реранкингом и без него. Доступность моделей и цены — на странице тарифов.
Связанные статьи:
