企业采购 Rerank API，最容易犯的错是只比“每次调用多少钱”。重排会接触查询和文档原文，调用量随候选数量放大，效果又必须用自有数据验证。只盯单价，常在额度、合规或验收阶段返工。

本文给一份可直接拿去开会的清单，从调用量、额度、发票到隐私、评测、降级和验收逐项展开。文中不写死单价和配额，以站内模型价格与合同为准。

说明：Cohere、Jina、BAAI、BGE、OpenAI 等名称归各自权利人所有，本文与上述机构无隶属或代理关系。本文仅作采购讨论，不构成法律意见；额度、价格与数据处理条款以签署合同和官方页面为准。

一、采购清单总表

先把采购项汇总成表，后面逐项展开：

采购项 要确认的问题 验收材料
用量与额度 月额度、QPS、单请求候选数、超限行为 配额说明、压测记录
计费与发票 计费单位、结算周期、开票主体、发票类型 报价单、合同、发票样例
数据与隐私 留存、训练、存储位置、删除、子处理方 数据处理协议、安全说明
效果 评测集、基线、指标、验收阈值 评测报告、回归记录
权限与审计 子账号、密钥轮换、调用日志 权限矩阵、日志样例
降级与 SLA 故障通知、备用通道、版本变更 SLA 条款、演练记录
成本监控 用量看板、预算告警、项目分摊 看板截图、告警配置

二、先算调用量，再谈单价

重排调用量不是“用户提问数”，而是查询数乘以每次候选文档数，再乘重试系数：

日调用量 ≈ 日查询数 × 每次候选数 × (1 + 重试率)

每天一万次查询、每次 30 条候选，就是三十万次文档打分；按搜索单元或 token 计费时，文档长度还会放大账单。采购前准备日常均值、活动峰值和十二个月增长预期，用演示流量估算通常会低估。

计费颗粒度也要确认：按查询次数、文档条数、token，还是按“每次搜索”打包。不同口径不能直接比价，要换算到同一业务量。

三、额度、限流与峰值行为

额度条款要落到书面，重点问清楚：

  • 月度和年度额度，试用与生产额度是否分开。
  • 速率限制按 QPS、每分钟请求还是并发计算。
  • 单次候选数和单条文档最大长度。
  • 超限后是报错、自动转按量计费还是停止服务。
  • 多项目能否共享额度，能否为单个密钥设上限。

“超限行为”最容易被忽略：有的直接报错，有的自动转后付费，账单可能在未审批时上涨。应要求预算告警和硬性上限。

四、计费、合同与发票

网页价格只是参考，最终要拿到正式报价单和合同。确认：

  • 计费单位、阶梯价格、最低消费或承诺用量。
  • 预付费或后付费，结算周期与账期。
  • 合同主体、开票主体、发票类型与税率。
  • 是否支持增值税专用发票，内容是否与服务一致。
  • 调价提前通知期，已购额度是否受影响。
  • 退款、未用额度处理，终止后的数据导出。

走 API 网关时，要分清付款给谁、发票由谁开、故障责任由谁承担。跨境服务还涉及币种、汇兑和税务，财务应提前介入。

五、数据隐私与处理边界

重排请求同时包含查询和候选文档，信息密度可能高于普通对话。合同和制度文档里常有客户名称、价格、个人信息，一旦出境或长期留存，风险会传导到业务侧。

采购时逐项确认：

  • 请求内容是否留存，留多久，做什么用。
  • 是否用于训练或服务改进，能否书面关闭。
  • 存储与备份地点、跨境传输路径。
  • 删除机制：能否按租户批量删除，多久生效。
  • 子处理方名单及变更通知。
  • 加密、访问控制、事件通知和数据处理协议。

数据特别敏感的团队可评估开源自部署：权重在自己的 VPC 内运行，数据不出内网，代价是 GPU、运维和升级成本。托管服务则要把“不留存、不训练、可删除”写进合同。

六、效果评估：评测集与 NDCG

评测集从真实日志抽 100–300 条查询，覆盖常见问法、错别字、多语言、长文档和“资料里没有答案”的情况。每条配一组生产召回的前 20–50 条候选，按 0（无关）、1（相关）、2（直接回答）分级标注。

主指标用 NDCG@10，辅以 MRR、Top-3 命中率、P95 延迟和每次查询成本。候选集的 Recall@k 也要记录，它是重排效果的天花板。

import math

def dcg(rels, k):
    return sum((2 ** r - 1) / math.log2(i + 2) for i, r in enumerate(rels[:k]))

def ndcg_at_k(ranked_rels, k=10):
    ideal = sorted(ranked_rels, reverse=True)
    idcg = dcg(ideal, k)
    return dcg(ranked_rels, k) / idcg if idcg else 0.0

# 按重排后的顺序填写相关性等级：2=直接回答，1=相关，0=无关
ranked = [2, 0, 1, 0, 0, 1, 0, 0, 0, 0]
print(round(ndcg_at_k(ranked), 4))

验收阈值不要照搬公开榜单，也不要接受“效果很好”的口头描述。业务方和供应商应在试点前书面约定：相对基线的 NDCG@10 提升、最低绝对值、P95 延迟上限和错误率上限，并保证可复现、可回归。

七、权限、审计与密钥管理

  • 按环境和项目分配独立密钥，禁止共用。
  • 密钥最小权限，支持轮换和吊销，禁止写进前端或公开仓库。
  • 如支持，配置 IP 白名单和单密钥速率上限，防止一个项目耗尽全局额度。
  • 调用日志保留时间、模型版本、耗时、状态码和用量，内容字段按合规要求脱敏。
  • 控制台支持成员角色和操作审计，离职人员及时回收权限。

用统一网关还要确认其日志策略和子账号能力：多一层中转就多一个数据处理方，合同和评审都要覆盖。

八、降级与容灾

重排是增强步骤，不应成为单点故障。采购方案要说明：

  • 服务不可用时的错误码和通知机制。
  • 是否有多区域或多供应商的备用通道。
  • 超时预算，以及超时后回退到向量相似度或关键词排序的逻辑。
  • 限流时的排队、重试和熔断策略，避免重试风暴放大故障。
  • 模型下线或版本变更的迁移窗口。

工程上把重排封装成独立接口，保留“关闭重排”的开关，并定期演练。出事时能一键回退，比任何承诺都实用。

九、试点验收与成本监控

建议按顺序推进，避免一上来就签长期大单：

  1. 明确试点范围：业务线、查询类型、日调用量上限和成功标准。
  2. 准备评测集与基线：不做重排、现有方案、候选方案使用同一批候选。
  3. 小流量接入，双跑对比，记录质量、延迟、错误率和实际用量。
  4. 组织人工复核，抽查排序前后的差异，确认指标提升不是标注偏差。
  5. 通过验收后再签正式合同或扩容，同时配置预算告警和月度复盘。

上线后监控四个数：日调用量、平均候选数、缓存命中率、每业务线成本。优化手段包括减少无效候选、对低价值查询关闭重排、缓存高频结果、按项目设预算。候选从 50 条降到 20 条，账单和延迟都会下降，效果要用评测集确认。

常见问题

Rerank API 一般按什么计费？

常见口径有调用次数、搜索单元、文档条数和 token。不同厂商定义不同，要换算到同一业务量再比价，并以合同和站内模型价格为准。

试用额度能用于正式上线吗？

多数试用额度只面向评估，可能限制商用，也没有生产级 SLA。正式业务应使用付费额度或私有化部署，并确认发票、数据处理协议和故障责任。

NDCG 多少算合格？

没有通用数字，取决于候选质量、标注标准和业务容忍度。更合理的做法是设定相对基线的提升目标，再用人工复核确认绝对质量。

数据敏感，只能私有化部署吗？

不一定。可评估支持不留存、不训练、可删除并签数据协议的托管服务；仍不满足合规要求时再选开源自部署。两条路都要算总成本。

供应商升级模型会影响效果吗？

可能。排序行为、分数尺度和延迟都可能变化。采购时应要求版本变更提前通知，尽量固定版本，并保留回归评测集，升级前后各跑一遍。

下一步

接入现有 RAG 链路，可先用小额预算注册中商起航 AI 网关，统一管理密钥、额度和用量日志，再按清单做试点验收。模型与价格以模型价格为准，采购条款以合同和官方文档为准。

相关阅读：