Rerank API 不在生成链路上，却直接决定搜索结果的前几条是否正确。它把“查询 + 一批候选文档”送进重排序模型，返回按相关性排好的顺序。因为调用发生在用户等待期间，国内团队真正要解决的不是“能不能调通”，而是网络是否稳定、账单能否报销、延迟是否可控、出故障时能否降级。
本文对比直连、中转和统一网关三种路径，并给出上线前的验真清单。具体模型、接口路径和价格以各服务商文档及站内模型价格为准。
说明：Cohere、Jina AI 等名称是其权利人的商标，本文与相关厂商无隶属关系。文中不写死单价，采购前请以服务商当期报价和合同为准。
一、Rerank API 为什么是独立的接入问题
Rerank 与聊天 API 有三点不同。第一，它是同步短请求：一次调用可能只有几十到几百毫秒，但用户就在等这个结果。第二，它不是 OpenAI Chat Completions 标准的一部分，字段和路径由各家定义，例如 Cohere 使用 /v2/rerank，Jina 使用 /v1/rerank，迁移时不能只换 Base URL。第三，计费单位可能是请求数、文档数、Token 或 search unit，账单结构比“输入/输出 Token”复杂。
因此，国内访问方案要同时满足四件事：网络可长期连通、支付和发票可走企业流程、延迟在搜索预算内、限流和故障有预案。只看“能不能返回结果”远远不够。
二、直连、中转与统一网关怎么选
常见路径可以归为四类。海外厂商直连适合有国际网络和外汇支付能力的团队；国内厂商直连网络和发票更省事，但模型与协议要重新适配；商业中转把网络和支付打包；统一网关则强调多厂商收口、Key 管理和统一账单。
| 路径 | 网络 | 支付与发票 | 延迟可控性 | 限流与故障切换 | 适合谁 |
|---|---|---|---|---|---|
| 海外厂商直连 | 依赖国际链路，高峰期波动 | 通常需外币卡，发票流程较长 | 可自选区域，但跨境 RTT 高 | 自己处理 429 与重试 | 有海外主体和运维能力 |
| 国内厂商直连 | 国内访问通常较稳 | 人民币结算，发票方便 | 区域可选，链路短 | 受厂商配额约束 | 主要服务国内用户 |
| 商业中转 | 由服务商优化线路 | 人民币充值，需确认发票 | 取决于中转路由 | 服务商兜底，但边界要问清 | 想快速上线的小团队 |
| 统一网关 | 网关侧做多线路 | 统一账单，便于采购 | 取决于网关部署区域 | 可配置多上游与降级 | 多模型、多项目并行 |
选型时不要只比较单价。把“故障时谁来定位”“发票由哪个主体开”“能否提供每次调用的耗时和计费明细”写进评估表，往往比省下的点数更重要。如果准备测试统一接入，可先通过注册入口查看当前支持的接口与模型清单，再决定是否纳入生产。
三、网络与延迟：先算搜索预算
重排序通常位于“召回之后、生成之前”。一条可用的预算大致是：召回 20–80 毫秒，重排 P95 控制在 300 毫秒以内，生成 1–3 秒。对于搜索即输即显的场景，重排可能要改成异步或只对第二页结果使用。
延迟主要受三个变量影响：候选文档数量、单篇文档长度、查询与文档的总 Token。Jina 的文档给出的参考是，100 篇约 256 Token 的文档、64 Token 查询，耗时约 150 毫秒；但单篇 4096 Token 的文档会上升到数秒。Cohere 的文档则建议单次请求不要超过 1000 篇文档，并默认按 4096 Token 截断单篇。这些数字会随模型和负载变化，但规律一致：先减候选，再截断，最后才考虑换更快的模型。
工程上优先做四件事：把 top_n 设小，只返回真正要用的条数；对长文档先切块或截断；在业务所在区域就近调用；用连接复用避免每次请求重新握手。测量时看 P95 和 P99，不要只看平均值。
四、支付、发票与合同
海外直连常见的问题是支付方式与报销口径。外币卡、汇率、境外主体发票、预充值余额的退款规则，都会影响财务流程。国内厂商和多数网关可以用人民币结算，但也要确认发票类型、开票时点、充值是否可开票、退款是否原路退回。
建议在合同或订单前书面确认五件事：计费单位是什么、失败请求是否计费、是否有最低消费、价格调整如何通知、数据保留与日志策略。对重排序来说，请求里会带业务文档片段，可能包含客户信息或内部资料，数据处理条款不能默认“和聊天接口一样”。
五、限流、超时与故障切换
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 换掉就能调用重排序。
六、上线前的验真清单
- 核对协议：确认请求路径、必填字段、分数范围和最大文档数。
- 用真实查询和 50–100 条候选做离线对比，记录排序质量变化。
- 在目标区域压测，记录 P50、P95、P99 和错误率。
- 主动触发 429，验证退避策略是否生效。
- 模拟超时与 5xx，确认能退回原始排序或备用服务商。
- 用固定 workload 对账，比较调用日志与实际账单。
- 确认合同主体、发票类型、退款规则和数据条款。
- 小流量灰度上线，同时观察搜索点击率和接口延迟。
这份清单的重点不是“测一次”，而是留下可复现的记录。重排序的效果和延迟都与业务语料强相关，别人的 benchmark 只能作参考。
七、常见问题
Rerank API 和 Embedding API 有什么区别？
Embedding 把文本变成向量，用于粗召回；Rerank 直接对“查询—文档”配对打分，用于精排。两者通常串联使用，不能互相替代。
国内厂商的 Rerank 能直接替换海外模型吗？
接口和分数分布都可能不同。替换后要重新校准阈值，并用同一批查询对比排序结果，不能只看接口是否返回 200。
直连海外 API 一定要专线吗？
不一定。可以先测目标时段的丢包、P95 和超时率。若业务对延迟敏感，再评估专线、区域网关或中转，不必一开始就上最重的方案。
重排序会让搜索慢多少？
取决于候选数量和文档长度。按上文方法把候选控制在几十条、单篇做截断，通常能把增量压在数百毫秒内；长文档和大批量会明显更慢。
统一网关一定支持 Rerank 吗？
不一定。Rerank 不属于 OpenAI 聊天接口标准，是否支持要看网关的接口清单。选型时先确认协议兼容性，再谈价格和额度；可从注册入口进入后核对当前能力。
