12家搜索API实测：任选两家命中率竟追平最优单家

构建AI智能体时，搜索API的选择往往被当作一个需要精挑细选的环节。但最近Reddit社区分享的一组基准测试数据给出了一个反直觉的结论：随机挑选两家搜索API组成 fallback（故障转移）组合，其命中率与表现最好的单一供应商几乎持平。

基准测试设置与核心数据

据Reddit用户披露，这次测试覆盖了12家搜索API供应商，使用同一组363个查询，评估指标是“已知答案是否出现在前5条结果中”。结果如下：

• 仅用1家（最优）：命中率68%
• 用2家（叠加）：命中率77%
• 用3家：命中率约80%
• 用全部12家：命中率84%

最令人意外的数字是：随机抽取两家供应商，命中率同样达到68%，与表现最佳的单家供应商持平。这意味着，在统计意义上，你精心挑选的“最优解”并没有比随便拉两家来兜底更可靠。

命中率（Hit Rate） 是信息检索领域常用的评估指标，特指在返回的结果列表中是否包含已知正确答案的比例。本文中“前5条结果”的限定对应检索系统常用的 Recall@5（前5条召回率）概念，衡量的是系统在有限展示位内找全正确答案的能力，而非排序质量（如MRR或NDCG）。这一指标对搜索增强型智能体尤为关键，因为智能体通常只将前几条结果送入后续推理，靠后的结果往往被截断丢弃。需要注意的是，Recall@5 无法反映答案在结果中的具体位置，因此命中率相同的两家供应商，在实际智能体管线中的表现仍可能因答案排序分布不同而存在差异。

为什么“有兜底”比“选对家”更重要？

从数据看，命中率从68%到77%的跃升发生在从1家增加到2家的时候，之后边际收益迅速递减——3家约80%，12家也才84%。这说明搜索API的错误模式具有一定独立性：当一家供应商没搜到，另一家很可能搜到，两者互补的概率远大于重复失败的概率。

对智能体开发者来说，这个结论的实操含义是：与其把时间花在死磕基准测试、寻找“唯一最好”的搜索API上，不如快速接入两家供应商做 fallback。触发机制可以是首轮未命中时切换，也可以按查询类型路由。

故障转移（Fallback） 在分布式系统中指主路径失败时自动切换到备用路径的容错模式。在搜索API场景中，fallback 的收益取决于多个供应商错误模式的相关性：若各供应商因索引来源、爬虫策略、排序算法不同而在不同查询上失败，则失败事件近似独立，叠加后的联合命中率接近 (1-(1-p)^n)；若它们共享上游数据源或对同类查询系统性失败，则互补性大打折扣。本文数据中从1家到2家命中率提升约9个百分点，正是低相关性错误模式的体现。实践中还需注意 fallback 会引入额外延迟与一致性开销，需在超时阈值和重试策略上做权衡。

16%的查询谁都搜不到，切换供应商无法解决

测试中还有一个关键数字：16%的查询在所有12家供应商中都没有出现答案。这部分失败与供应商选择无关，问题出在智能体本身的搜索策略或页面读取能力上。

原文作者对此的解读是，这属于“搜索方式”或“是否读取页面”层面的问题——比如查询构造不当、需要深入阅读页面正文才能提取答案，而API只返回摘要片段。换句话说，优化方向不在换供应商，而在改进智能体的检索逻辑。

两种策略：命中后切换 vs. 每次扇出

原文抛出了一个开放问题：应该采用“fallback-on-miss”（首轮失败后再切换）还是“fanning out”（每次查询同时向多家供应商发起请求）？

前者节省调用成本、延迟略高；后者响应更快但费用成倍增加。结合数据来看，由于第二家的边际贡献最大，fallback-on-miss 已经能拿到大部分收益；fanning out 更适合对延迟极度敏感、且查询成本可承受的场景。

扇出（Fan-out） 指对同一查询并行向多个后端发起请求并合并结果，与串行 fallback 相对。扇出的核心优势是延迟取决于最慢而非累加，但代价是请求量成倍增加，且需要结果融合逻辑（如按分数重排、去重）。在本文数据下，第二家供应商的边际命中贡献最大，因此串行 fallback-on-miss 能以更低成本获得大部分收益；扇出更适合对首字节延迟极度敏感、且供应商调用成本可忽略的场景。另一种折中方案是投机执行（hedged request）：首请求发出后若在设定时限内未返回，再并行发出第二请求，兼顾延迟与成本。

对智能体搜索架构的启示

这组数据挑战了“基准测试决定一切”的采购思路。对于构建搜索增强智能体的团队，更务实的做法是：先快速上线双供应商 fallback，再针对那16%的顽固失败案例做查询改写、页面级读取等深度优化。供应商选择本身，可能没有想象中那么重要。