Embedding API 怎么测才有意义：召回率、延迟、成本和租户隔离一起看

Embedding API 看起来比聊天模型简单：输入文本，返回向量。但向量质量会直接影响搜索、推荐和知识库回答，真正的差异往往要经过检索链路才能看出来。只比较维度和价格，很容易选到“单价便宜、业务召回差”的方案。

先建立带难例的检索集

测试集至少包括同义表达、错别字、缩写、跨语言、长文档、数字和权限标签。每个查询需要有人工确认的相关文档，才能计算 Recall@K、MRR 或 nDCG。不要只用随机切分的训练文档，因为那会掩盖真正的难例。还要专门放入“看起来相似但权限不同”的样本。

质量之外的四项指标

第一是批量吞吐。生产系统经常需要离线切片和重建索引，单条延迟并不能代表批处理效率。第二是尾延迟，P95 和 P99 直接影响在线问答。第三是成本，包括输入字符、token、批处理折扣和重复重建的费用。第四是版本稳定性，模型升级后向量空间可能变化，旧索引是否需要重建必须提前验证。

多语言系统还要比较不同语言之间的相似度是否可用；中文、英文、代码和混合文本不要用同一条结论。对于长文档，要测试切片长度、重叠窗口和标题保留对召回的影响，而不是把问题归咎于模型。

把租户边界放入测试

向量检索最大的安全问题之一不是“搜不到”，而是搜到了不该看到的内容。每条向量都应带租户、项目、来源和权限元数据，检索过滤必须在向量库或网关的受控层执行。测试集需要包含同文档不同租户副本，确认相似度排序不会绕过过滤条件。

统一 API 入口可以让不同 Embedding 供应商共享鉴权、配额和账单。通过 top-api.cc 做对照时，建议固定文本清洗、切片和批量大小，只替换 embedding 模型，否则测到的是整个数据处理流程的差异。

推荐的评测表

• Recall@5、Recall@10 和 MRR；
• 中文、英文、代码和混合文本分组结果；
• 单条与批量的 P50、P95、P99 延迟；
• 每百万字符或 token 的实际成本；
• 模型升级后旧索引的兼容性；
• 过滤条件下的跨租户误召回率。

最终选择不一定是分数最高的模型。一个质量略低但延迟稳定、价格可预测、版本策略透明的 API，可能更适合生产；一个离线检索很强却无法稳定批处理和隔离租户的服务，则需要谨慎使用。

参考资料：各供应商 Embedding API 文档、向量检索基准的 Recall/MRR 定义，以及 OpenTelemetry 对生成式 AI 调用指标的讨论。价格和模型版本应在发布前重新确认。

如果需要把多个 embedding 上游放入相同的鉴权和成本框架，可用 top-api.cc 做一层实验性统一入口，再把最终结果回写到自己的检索评测平台。