Artificial Analysis Search Index:Search API 基准测试方法论
概述
Search API Bench 在智能体检索范式下评估各类搜索服务商。
该基准测试采用替换服务商的对比方式。每个样本都使用相同的候选回答模型和基准测试任务,只改变搜索服务商。
我们用同一个回答模型来评估结果,以此衡量各家 Search API 服务商带来的提升。
在本页中,一条结果指的是与固定候选回答模型搭配的一家 Search API 服务商。我们称之为服务商结果。
核心指标
Artificial Analysis Search Index
公开排行榜以单一的综合得分 Artificial Analysis Search Index 作为主要指标。它是各项基准测试主要质量指标的等权平均值:
关于计算方式的说明:
- AA-Omniscience 贡献的是准确率,而非其 Omniscience Index 或幻觉率。在搜索服务商与候选模型这一范式下,准确率是最能直接比较的信号。
- 所有输入都使用相同的常量(见下文),因此该指数能够单独反映搜索服务商的差异。
指数构成
| 评测 | 领域 | 任务数 | 回答类型 | 评分方式 |
|---|---|---|---|---|
| DeepSearchQA | 深度研究型问答(单一答案与集合答案) | 900‡ | 开放式回答 / 答案集合 | 由大模型对回答条目评分得到的 F1,pass@1 |
| AA-Omniscience | 事实型问答(正确性 + 校准度) | 600† | 开放式回答(允许弃答) | 由大模型评分的准确率,pass@1 |
| BrowseComp | 高难度网页检索问答 | 200^ | 简短的精确答案 | 由大模型评分的精确答案准确率,pass@1 |
三项基准测试均使用 GPT-5.6 Luna(medium)进行评分,并各自采用相应的评分标准。
‡ DeepSearchQA:完整的 900 行公开评测集。
† AA-Omniscience:600 个非公开留出样本,覆盖 6 个领域,每个领域 100 个,分布均衡。
^ BrowseComp:从 1,266 个样本的评测池中抽取的 200 个高难度样本子集。
常量
下列每个取值在所有服务商结果中都保持固定,因此对比中唯一的变量就是搜索服务商。
- 候选回答模型:GPT-5.6 Luna(medium)
- 推理强度:Medium
- 温度:0.6
- 最大输出 token 数:127,999 token
- 评分模型:GPT-5.6 Luna(medium),三项基准测试共用
- 轮次预算:25 个智能体轮次(t25)
- 每个样本的工具调用次数:在轮次预算内不限次数
- 展示的搜索结果:每次搜索最多 10 条
- 搜索工具:
web_search与web_fetchweb_search— 将候选模型的查询发送至目标 Search API 服务商,并返回其原生响应内容。web_fetch— 抓取搜索结果中的某个 URL 并返回页面内容(仅文本)。
- 提取层:纯文本提取器,每个页面超时时间为 15 秒
- 搜索返回内容格式:服务商原生格式;模型看到的是服务商的原始响应体
- 污染过滤:已启用,详见下文
- 智能体工作流:二者之一:
- 不使用搜索的
model_only基线,或 - Stirrup 搜索智能体循环
- 不使用搜索的
工作流
仅模型基线
model_only 样本不使用任何搜索工具,直接以基准测试提示词一次性调用候选模型。它用于估计候选模型仅凭内部知识或推理能够解决多少问题。
model_only 得分较高,说明该基准测试样本无需最新的搜索信息即可作答;而 model_only 得分较低时,搜索带来的提升会更容易观察到。
搜索智能体循环
使用搜索的样本运行在固定的智能体循环中,由 Artificial Analysis 的 Stirrup 框架统一编排。
该框架提供两个工具:web_search 与 web_fetch。
对应的搜索服务商 API 驱动 web_search 工具,候选模型总共可使用 25 个轮次、不限次数的工具调用来完成给定任务。
当模型认为已收集到足够信息时,会调用 finish 工具提交最终答案。如果模型用完全部 25 个轮次仍未调用 finish,则视为未提交答案,该任务计零分。
由针对该基准测试的评分器,对照隐藏的参考数据为答案评分。
错误处理
可恢复错误会作为一次失败的工具调用返回给模型,并保留在公开结果中。可恢复错误包括:
- 抓取网页时的超时或 HTTP 错误
- 模型抓取了
web_search并未返回的 URL
致命错误会一直重试直至成功,含致命错误的结果不会发布。致命错误包括:
- Search API 服务商侧的错误(如 429、5xx 和超时)
成本
成本以实验总成本报告,并拆分为:
- 候选回答模型成本,包含全部输入、缓存、推理和输出 token。
- Search API 服务商成本。
- 注意:
model_only基线不产生 Search API 服务商成本。
- 注意:
延迟
延迟以多种方式报告:
- 每任务模型耗时。每个任务中候选模型输入、思考、输出 token 的平均推算端到端耗时。
- 每任务搜索耗时。每个任务中在
web_search上花费的平均实测时间。 - 每任务耗时。每任务模型耗时与每任务搜索耗时之和。
- 每次搜索查询耗时。整个基准测试中,单次
web_search请求的平均延迟。
如果模型对某家服务商发起的搜索更频繁,即使其单次调用很快,累计耗时仍可能更高。
污染过滤
污染过滤会移除潜在和已知的基准测试泄漏内容及其来源。
过滤在两个搜索工具内部完成,早于候选模型看到任何输出:web_search 的结果按 URL、标题和摘要进行筛查,web_fetch 的页面文本则在提取后筛查。被标记的条目会从服务商的结果列表中剔除,而不改变响应的结构。
例如:
- 已知来源位置。基准测试原始托管的 URL 和数据集。
- 数据集文本伴随信号。源材料中已知的金丝雀字符串。
搜索服务商 API 设置
每家服务商均固定使用 max_results=10(或该服务商的等效设置)。除下列项目外,其余设置一律保持服务商默认值。
| 服务商结果 | 文档 | 基准测试请求设置 |
|---|---|---|
| Brave | Brave Web Search API | q=agent query, result_filter=web |
| Tavily basic | Tavily Search API | search_depth=basic |
| You.com | You.com Search API | safesearch=moderate |
| Firecrawl | Firecrawl Search API | scrape_format=none |
| Exa fast | Exa Search API | type=fast, contents={"highlights": True} |
| Exa auto | Exa Search API | type=auto, contents={"highlights": True} |
| Parallel turbo | Parallel Search API | mode=turbo |
| Parallel basic | Parallel Search API | mode=basic |
| Parallel advanced | Parallel Search API | mode=advanced |
| Keenable pro | Keenable Search API | mode=pro |
| Keenable realtime | Keenable Search API | mode=realtime |
基准测试范围
DeepSearchQA
一项深度研究风格的问答基准测试,包含单一答案与集合答案两类数据行。
- 来源:Google DeepSearchQA。Hugging Face。论文。
- 样本范围:完整的 900 行公开
eval评测集。 - 主要指标:F1。
BrowseComp
一项高难度的网页检索问答基准测试。
- 来源:OpenAI BrowseComp,随 Simple Evals 一同发布。论文。
- 样本范围:200 个样本的
n200判定集,筛选方式见“指数构成”。 - 主要指标:准确率。
AA-Omniscience
一项非公开、留出的事实型问答基准测试,重点考察正确性与校准度。
- 来源:AA-Omniscience。公开参考数据集:AA-Omniscience-Public。论文。
- 样本范围:600 个非公开样本,覆盖 6 个领域,每个领域 100 行,分布均衡。
- 主要指标:准确率。
我们采用准确率,而非 Omniscience Index 或幻觉率。AA-Omniscience 的设计目的是考察参数化知识,以及在上下文不足时选择弃答的能力。
当有搜索工具提供上下文时,模型往往会始终作答,因此准确率有助于回答这样一个问题:在服务商提供搜索上下文的情况下,模型作答的准确程度如何?
结果解读
Search API Bench 是一项多目标对比:
- 相比
model_only,搜索是否改善了回答? - 哪家服务商对质量的提升最大?
- 这一提升的代价是多少?
- 它增加了多少延迟?
- 这些提升在各项基准测试中是否稳健,还是只适用于某一类任务?
对某项任务而言,最合适的服务商未必是得分最高的那家。针对具体使用场景挑选搜索服务商时,应从以下几方面评估:
- 相对基线的质量提升。
- 相对基线的成本增加。
- 相对基线的延迟增加。