Rerank API не участвует в генерации, но напрямую определяет, правильные ли результаты окажутся в первых строках поиска. Он отправляет «запрос + набор документов-кандидатов» в модель переранжирования и возвращает порядок по релевантности. Поскольку вызов происходит, пока пользователь ждёт ответа, командам в Китае нужно решать не только задачу «можно ли вообще вызвать», но и вопросы стабильности сети, оплаты и счетов, управляемой задержки и деградации при сбое.
Ниже сравнение трёх путей — прямого подключения, релея и единого шлюза — и чек-лист проверки перед запуском. Конкретные модели, пути интерфейсов и цены смотрите в документации поставщиков и на странице тарифов.
Примечание: Cohere, Jina AI и другие названия — товарные знаки их правообладателей; статья не связана с этими компаниями. Фиксированные цены не приводятся; перед закупкой ориентируйтесь на текущее предложение поставщика и договор.
1. Почему Rerank API — отдельная задача подключения
У Rerank три отличия от чат-API. Во-первых, это синхронный короткий запрос: вызов может занимать от десятков до сотен миллисекунд, но пользователь ждёт именно этот результат. Во-вторых, он не входит в стандарт OpenAI Chat Completions: поля и пути определяет каждый поставщик, например Cohere использует /v2/rerank, Jina — /v1/rerank, и при миграции недостаточно заменить Base URL. В-третьих, единицей тарификации может быть запрос, документ, токен или search unit, и структура счёта сложнее, чем «входные/выходные токены».
Поэтому схема доступа из Китая должна одновременно удовлетворять четырём требованиям: сеть стабильно доступна в долгую перспективу, оплата и счета проходят корпоративные процедуры, задержка укладывается в бюджет поиска, а на случай лимитов и сбоев есть план. Проверки «возвращает ли ответ» недостаточно.
2. Прямое подключение, релей и единый шлюз
Распространённые пути делятся на четыре класса. Прямое подключение к зарубежному поставщику подходит командам с международной сетью и возможностью оплаты в валюте; прямое подключение к локальному поставщику проще по сети и счетам, но требует адаптации моделей и протокола; коммерческий релей объединяет сеть и оплату; единый шлюз делает акцент на консолидации поставщиков, управлении ключами и едином счёте.
| Путь | Сеть | Оплата и счёт | Управляемость задержки | Лимиты и переключение при сбое | Кому подходит |
|---|---|---|---|---|---|
| Прямое подключение к зарубежному поставщику | Зависит от международного канала, нестабильна в пики | Обычно нужна иностранная карта, счёт оформляется дольше | Регион можно выбрать, но трансграничный RTT высокий | 429 и повторы берёте на себя | Есть зарубежная структура и эксплуатационная команда |
| Прямое подключение к локальному поставщику | Внутри Китая обычно стабильно | Расчёты в юанях, счёт удобнее | Регион выбирается, канал короткий | Ограничено квотой поставщика | Основные пользователи в Китае |
| Коммерческий релей | Поставщик оптимизирует маршрут | Пополнение в юанях, уточните счёт | Зависит от маршрутизации релея | Поставщик страхует, но границы уточняйте | Небольшие команды, которым нужен быстрый запуск |
| Единый шлюз | Несколько маршрутов на стороне шлюза | Единый счёт, удобно для закупки | Зависит от региона развёртывания | Можно настроить несколько upstream и деградацию | Несколько моделей и проектов параллельно |
При выборе не сравнивайте только цену. Внесите в таблицу оценки «кто диагностирует сбой», «какая сторона выставляет счёт» и «можно ли получить длительность и детализацию оплаты по каждому вызову» — это часто важнее сэкономленных процентов. Если планируете тестировать единое подключение, сначала через страницу регистрации посмотрите доступные интерфейсы и список моделей, затем решайте, выводить ли сервис в продакшен.
3. Сеть и задержка: сначала бюджет поиска
Реранкинг обычно находится между поиском кандидатов и генерацией. Рабочий бюджет выглядит примерно так: поиск 20–80 мс, P95 реранкинга в пределах 300 мс, генерация 1–3 секунды. Для поиска с выводом по мере ввода реранкинг, возможно, придётся сделать асинхронным или применять только ко второй странице результатов.
На задержку влияют три переменные: число документов-кандидатов, длина одного документа и общее число токенов запроса и документов. Документация Jina приводит ориентир: 100 документов примерно по 256 токенов и запрос на 64 токена занимают около 150 мс, но документ на 4096 токенов увеличивает время до нескольких секунд. Cohere рекомендует не превышать 1000 документов за запрос и по умолчанию усекает документ до 4096 токенов. Эти числа зависят от модели и нагрузки, но закономерность одна: сначала сокращайте кандидатов, затем усекайте, и только потом думайте о более быстрой модели.
На инженерном уровне приоритетны четыре действия: задать небольшой top_n, возвращая только нужное число записей; нарезать или усекать длинные документы; вызывать сервис в регионе, близком к бизнесу; переиспользовать соединения, чтобы не выполнять рукопожатие на каждом запросе. При измерении смотрите P95 и P99, а не только среднее.
4. Оплата, счета и договор
У прямого зарубежного подключения типичные проблемы — способ оплаты и порядок отчётности. Иностранная карта, курс, счёт от зарубежной структуры и правила возврата предоплаченного баланса влияют на финансовые процедуры. Локальные поставщики и большинство шлюзов работают в юанях, но всё равно нужно уточнить тип счёта, момент выставления, можно ли выставить счёт на пополнение и возвращаются ли средства тем же путём.
До подписания договора или заказа письменно подтвердите пять пунктов: что является единицей тарификации, тарифицируются ли неудачные запросы, есть ли минимальный платёж, как уведомляют об изменении цен, какова политика хранения данных и журналов. Для реранкинга запрос содержит фрагменты бизнес-документов, включая сведения о клиентах или внутренние материалы, поэтому условия обработки данных нельзя по умолчанию считать «такими же, как у чат-интерфейса».
5. Лимиты, тайм-ауты и переключение при сбое
Ограничения Rerank обычно учитывают и RPM, и TPM. Поскольку стоимость растёт как «число документов × длина», один пакетный реранкинг легко упирается в квоту в пик. Клиенту нужен явный тайм-аут, например от 800 мс до 1,5 секунды; после ошибки — не более одного повтора со случайным разбросом, чтобы избежать шторма.
Важнее путь деградации. При сбое реранкинга система должна вернуться к исходному порядку поиска или переключиться на другого поставщика, а не ронять весь поиск. Ниже пример вызова с тайм-аутом; имена полей уточняйте по документации поставщика:
curl -sS --max-time 1.5 https://<your-endpoint>/v1/rerank \
-H "Authorization: Bearer $RERANK_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "<по документации поставщика>",
"query": "какие документы нужны для регистрации компании в России",
"documents": ["фрагмент один", "фрагмент два", "фрагмент три"],
"top_n": 5,
"return_documents": false
}'
Учтите: пути и поля у поставщиков не унифицированы, return_documents, диапазон оценок и поддержку структурированных документов нужно проверять отдельно. Не предполагайте, что достаточно заменить Base URL чат-интерфейса, чтобы вызвать реранкинг.
6. Чек-лист проверки перед запуском
- Сверьте протокол: путь запроса, обязательные поля, диапазон оценок и максимальное число документов.
- Проведите офлайн-сравнение на реальных запросах и 50–100 кандидатах, зафиксируйте изменение качества сортировки.
- Проведите нагрузочный тест в целевом регионе, запишите P50, P95, P99 и долю ошибок.
- Намеренно вызовите 429 и проверьте, срабатывает ли стратегия backoff.
- Смоделируйте тайм-аут и 5xx, убедитесь в возврате к исходному порядку или резервному поставщику.
- Сверьте фиксированную нагрузку: сравните журналы вызовов и фактический счёт.
- Подтвердите сторону договора, тип счёта, правила возврата и условия данных.
- Запустите малую долю трафика и одновременно наблюдайте за кликабельностью поиска и задержкой интерфейса.
Смысл чек-листа не в разовой проверке, а в воспроизводимых записях. Качество и задержка реранкинга сильно зависят от бизнес-корпуса, поэтому чужие benchmark могут служить только ориентиром.
7. Частые вопросы
Чем Rerank API отличается от Embedding API?
Embedding превращает текст в вектор и используется для первичного поиска кандидатов; Rerank напрямую оценивает пару «запрос—документ» и применяется для точной сортировки. Обычно они работают последовательно и не заменяют друг друга.
Можно ли локальной моделью Rerank напрямую заменить зарубежную?
Интерфейсы и распределения оценок могут различаться. После замены нужно заново калибровать пороги и сравнивать порядок на одном наборе запросов, а не только проверять, что интерфейс вернул 200.
Обязательно ли выделять линию для прямого доступа к зарубежному API?
Не обязательно. Сначала измерьте потери пакетов, P95 и долю тайм-аутов в целевые часы. Если бизнес чувствителен к задержке, тогда оценивайте выделенный канал, региональный шлюз или релей — не начинайте с самой тяжёлой схемы.
Насколько реранкинг замедляет поиск?
Зависит от числа кандидатов и длины документов. Если держать кандидатов в пределах нескольких десятков и усекать документы, прирост обычно укладывается в несколько сотен миллисекунд; длинные документы и большие пакеты замедляют заметно сильнее.
Любой единый шлюз поддерживает Rerank?
Нет. Rerank не входит в стандарт чат-интерфейса OpenAI, поэтому поддержку нужно проверять по списку интерфейсов шлюза. При выборе сначала подтвердите совместимость протокола, затем обсуждайте цену и квоты; текущие возможности можно проверить после входа через страницу регистрации.
