相同准确率，不同证据：搜索API作为工具型代理的决策表面

# 同等准确率，不同证据：作为工具使用型Agent决策面的搜索API

来源：https://arxiv.org/html/2607.10198

###### 摘要

搜索API是许多Agent的基础检索层，也往往是它们使用最频繁的工具。传统搜索API提供URL、标题和摘要，用于预览网站内容。由于完整页面检索需消耗大量token，Agent检索架构越来越多地采用渐进式披露：Agent先看到摘要，再决定是否获取完整页面。在此类系统中，搜索API的性能通常主要通过答案准确率来评估。我们认为，商业搜索API更应被理解为**决策面**：即排序后的摘要、URL和元数据，它们决定了Agent是立即回答、再次搜索，还是花费token打开页面。我们用一个固定的GPT-5.4 Agent、两个工具（`search_web`和`fetch_page`）以及来自SealQA-Hard的100个问题来验证这一观点，唯一变化的是搜索提供商（Brave、Tavily、Firecrawl）。一个Kimi-K2.6预言机对Agent可见的每个内容元素（URL、标题、摘要以及在获取时的页面内容）进行标注，生成了6,869个有效的按URL评估结果。我们使用一个经过审计的**正确答案**标签`semantic_match`，该标签保留精确匹配，同时接受无害的格式和命名变体。在此度量标准下，各提供商表现接近（25、25、26 / 100），但它们的证据经济性差异显著：Brave提供富含黄金答案的摘要，Tavily将黄金支撑型URL集中在排名第一的位置，而Firecrawl在此固定Agent策略下与更广泛的探索相关联。我们还引入了表面矛盾与黄金URL比率，该比率从0.92到2.59不等。因此，提供商的选择不仅是召回决策，更是检索预算和策略决策。

## 1 引言

早期搜索增强型Agent通常主要依赖搜索API提供商提供的提取页面数据。随着复杂用例的发展，Agent领域已转向渐进式披露：模型接收排名靠前的nn个URL、标题、摘要以及新鲜度等关键元数据，然后决定是否获取完整页面。在这一新格局中，工程实践常将搜索API提供商视为可替换组件。如果两个API返回了看似合理的靠前kk个URL，并产生相似的答案准确率，则Agent管道的其余部分通常被认为不受影响。

本文认为，关键对象是**预获取表面**。在页面打开之前，Agent看到的不是搜索索引或语料库，而是依赖搜索API结果。该表面是Agent决策的证据状态，决定其是直接回答、再次搜索还是花费获取token。我们将商业搜索API称为工具使用型语言Agent的**决策面**。对于基于事实的语言模型系统而言，检索API是事实接口的一部分。它决定了生成前暴露了哪些证据、哪些矛盾进入上下文、以及在产生答案前花费了多少检索预算。因此，决策面评估不仅衡量检索质量，还衡量生成基于事实的答案时的忠实性和效率条件。

这种区分之所以重要，是因为最终正确性可能趋同，而内部流程却可能不同。某个提供商可能暴露出足够的摘要证据供立即回答；另一个提供商可能将相关URL放在排名第一的位置，使得顶级结果获取策略有效；第三个提供商可能暴露稀疏的摘要，并在相同策略下与更广泛的探索相关联。这些模式在成本、延迟、污染和失败模式方面可能产生相似的总体准确率。

在受控协议下，我们固定了回答模型、提示词、工具、最大迭代次数、评判器和页面获取后端。唯一的实验条件是商业搜索API：Brave、Tavily或Firecrawl。然后，我们评判Agent可见的每个URL级别证据项，将预获取摘要支持与仅在页面获取后发现的支持区分开来。按URL的预言机使我们不仅能够询问最终答案是否正确，还能询问在决策面有哪些证据和操作可用。我们不将提供商身份视为排行榜变量；我们使用Brave、Tavily和Firecrawl作为不同预获取证据表面的生产示例，表明相同的答案准确率可能隐藏不同的事实依据、矛盾和检索预算机制。

#### 贡献
1. 我们将商业搜索API形式化为工具使用型Agent的**决策面**，而非静态排序列表检索器。
2. 我们引入了一个按URL的预言机协议，对Agent看到的每个API结果元素（包括获取的页面）进行标注。
3. 我们区分了预获取表面支持与后获取发现支持，并使用前者定义了一个四路决策分区（SMART、MISSED、BLIND、NO-OP）。
4. 我们表明，在固定Agent下，相似的正确性隐藏了不同提供商相关的检索机制：预获取支持、排名集中度、盲目探索、污染和互补性。

## 2 相关工作

#### 检索增强生成与开放域问答
检索增强生成将参数化模型与非参数化证据相结合（Lewis et al., 2020；Guu et al., 2020）。DPR、FiD和Atlas等开放域问答系统主要评估检索器是否向阅读器或生成器提供包含答案的段落（Karpukhin et al., 2020；Izacard and Grave, 2021；Izacard et al., 2023）。我们的设置有两个不同之处：检索由生产级网络搜索API执行，且阅读器是一个可以选择是否获取页面的Agent。

#### 信息检索评估
经典的IR指标，包括精确率/召回率以及NDCG等排序感知指标，评估静态排序（Järvelin and Kekäläinen, 2002；Manning et al., 2008）。BEIR将零样本检索器评估扩展到跨任务和领域（Thakur et al., 2021）。这些指标对Agent来说是必要但不充分的，因为它们不询问预获取表面是否充分、具有误导性或具有行为指导性。

#### 工具使用与浏览型Agent
WebGPT、Self-Ask、ReAct、IRCoT、Toolformer和Self-RAG研究了能够搜索、浏览或决定何时调用工具的语言模型（Nakano et al., 2021；Press et al., 2022；Yao et al., 2023；Trivedi et al., 2022；Schick et al., 2023；Asai et al., 2024）。FreshLLMs表明搜索增强有助于获取最新事实知识，并且证据顺序很重要（Vu et al., 2023）。过度搜索的研究主张对搜索增强型模型进行成本敏感型评估（Xie et al., 2026）。我们隔离了一个互补变量：呈现给同一个Agent的提供商表面。

#### 硬搜索基准与证据评估
GAIA、WebArena、BrowseComp和SealQA评估Agent或系统在需要搜索、浏览或硬事实推理的任务上的表现（Mialon et al., 2024；Zhou et al., 2024；Wei et al., 2025；Pham et al., 2025）。RAG评估框架如RAGAS和ARES评估答案质量、忠实性、上下文相关性或生成的声明（Es et al., 2024；Saad-Falcon et al., 2024）。我们使用一个硬问答基准作为受控探针，在固定Agent下研究提供商相关的证据状态。

#### 归因、可验证性与LLM评判器
生成式搜索系统可能产生流畅但引用支持不完整的答案（Liu et al., 2023a；Yue et al., 2023）；长上下文研究表明，更多文本并不能保证稳健的证据使用（Liu et al., 2024）。LLM作为评判器的方法可扩展评估，但需要约束的评分规则和谨慎的解释（Zheng et al., 2023；Liu et al., 2023b）。我们的评判器使用固定JSON模式对每个检索到的文档进行标注，且我们的答案正确性标签作为`semantic_match`被单独审计。

#### 商业搜索API
Brave、Tavily、Firecrawl和Jina Reader公开了不同的产品表面（Brave Software, 2026；Tavily, 2026；Firecrawl, 2026；Jina AI, 2026）。我们在主要条件下禁用了提供商端的页面内容，并使用共享的`fetch_page`后端，因此提供商差异可归因于排序后的URL、摘要和元数据，而非不同的提取管道。

图1：执行与评判管道。Agent、提示词、工具和获取后端固定；仅搜索提供商变化，然后Kimi预言机重放每个可见的URL。

## 3 实验协议

图1总结了实验。冻结的Agent在每个条件下使用相同的提示词、工具和获取后端，仅`search_web`提供商变化；然后预言机以答案模型看到的相同表示重放每个可见的URL。

#### 数据集
我们使用确定性的比例分层抽样，从254行的SealQA-Hard子集中抽取100个问题。分层维度为`freshness` × `search_results` × `topic`。我们选择SealQA-Hard是因为它提供了具有挑战性的问题，通常需要模型进行探索，且不能仅通过简单的摘要型搜索API响应完全解决。附录B给出了完整的抽样总结。

#### Agent与工具
答案模型为GPT-5.4，最大迭代次数为10次。它有两个工具。`search_web`接受查询并返回最多十个排序结果，每个结果包含文档标识符、排名、标题、URL、域名、摘要表面和提供商元数据。`fetch_page`接受先前搜索结果中的文档标识符，并返回提取的markdown及获取元数据。工具接口允许Agent在单轮中发出*多个*`search_web`调用或*多个*`fetch_page`调用；跟踪记录单独记录每个调用。最终答案必须使用确切前缀`FINAL ANSWER:`，并基于检索到的证据。附录D给出了固定的提示词合约和跟踪模式。

#### 提供商与摘要归一化
我们比较Brave、Tavily和Firecrawl搜索。每个适配器将提供商输出归一化为相同的结果模式。Brave公开了额外的提供商原生摘要块。我们将这些块聚合到通用的**摘要表面**中，而不是将其视为独立的证据通道；Agent看到的是摘要，评判器看到的是相同的文本。我们仍然将此不对称性视为一个局限性，因为它改变了Brave返回的预获取文本量。Tavily运行时禁用了原始内容，Firecrawl运行时禁用了提供商端的markdown抓取。因此，Agent可见的页面文本仅来自共享的Jina Reader后端。

#### 运行与可重复性控制
主要提供商跟踪记录于UTC时间2026-05-17 06:49–09:02跨三个提供商收集。所有提供商在附录C的固定配置下被要求返回最多10个网络结果：Brave使用美国/英语环境，安全搜索设置为中等；Tavily使用基础/通用搜索，禁用原始内容；Firecrawl使用网络搜索，禁用提供商端markdown抓取。所有完整页面文本均来自共享的Jina Reader `fetch_page`后端，超时时间为15秒，读取限制为2MB，并发数为4，并使用以归一化URL为键的gzip缓存。由于商业搜索输出具有时间敏感性，且原始API结果不属于我们可重新分发的内容，因此发布的可重现性包包含代码、配置、抽样逻辑、跟踪模式、评估脚本和聚合派生输出；报告的数字来自私有运行工件。

#### 跟踪记录
实验产生300个提供商-查询轨迹。一个跟踪记录包含每次搜索调用、每个返回的URL、每次获取决策、获取状态、token使用量、延迟、最终答案和黄金答案。提供商比较脚本从这些跟踪记录中确定性派生token、URL命中数和每个查询的支持字段。答案正确性来自单独的语义审计TSV。

## 4 按URL的预言机与指标

#### 评判器输入
对于Agent看到的每个URL，我们使用Kimi-K2.6作为评判器。评判器接收问题、黄金答案、模型最终答案以及一个检索到的文档，格式与答案模型看到的类似XML格式相同。对于未获取的URL，评判器看到标题、URL、域名、摘要表面和元数据。对于已获取的URL，同一记录还包括提取的markdown；摘要特定字段仍保持单独标注。

#### 评判器输出
评判器仅返回JSON，并被告知不得使用外部知识。所需模式如下所示。跨提供商，6,909个评判行中有6,869个有效；40个无效行被排除。有效行分为6,519个仅摘要行和350个页面可见行。我们在问题条件化的意义上使用“黄金支持”：证据必须使给定问题的黄金答案可回答，而不仅仅是提及答案字符串。

#### 预言机验证
为了评估单评判器预言机作为审计工具的可用性，我们手动验证了URL标签评判的平衡180个案例样本。样本覆盖了提供商×表面×标签×Kimi值的每个叶子切片，每个叶子切片有5个案例。表1显示总体上与清晰的人类判断具有高度一致性（164/174, 94%）。该验证是作为单标注者对Kimi标签的手动审计进行的，而非标注者间一致性研究。被人类审计员标记为不清晰的案例仅从一致性分母中排除，而非从抽样池中排除。剩余的争议涉及推理可回答性、矛盾的直接性、以及是否应将稀疏且信息量低的结果视为不可用。

表1：Kimi按URL预言机标签的人工验证。

#### 答案指标
标题级别的`Correct`指标是来自单独语义审计TSV的`semantic_match`。该表还报告了传统的token F1：我们将最终答案和黄金答案进行小写化、去除冠词和标点符号、将简单的数字词映射为数字，然后计算每个查询的token重叠F1，并宏平均100个查询。

#### 支持划分