如何评估用于AI的网页搜索

作者：@everythingmeta，Parallel 公司 MTS

请阅读本文，或将其交给您的智能代理，以帮助您有效评估网络搜索 API。

如果您正在使用 Parallel，并希望今天就能充分利用我们的 Search API，请阅读我们的 最佳实践。

搜索已成为智能体系统中不可或缺的一部分。无论您是在构建编程智能体、个人助理、知识应用，还是其他完全不同的东西——AI 加上搜索会更好！

但一旦开始，您很快就会发现：选择太多了！提供商、模型、不同的评估技术。如何决定？应该使用现成的评估工具吗？还是快速编写一个？或是找一位被遗忘在角落里的领域专家来生成数据，并让他们标注一份黄金数据集？

答案是……看情况！（抱歉。）

本指南的目标是解释为什么搜索评估比看起来更复杂——但绝非不可能——并为您提供一份运行评估的清单，让您和您的子智能体对您在这一领域的深厚专业知识印象深刻。

准备好了吗？让我们开始吧。

搜索、提取，还是任务？

对普通人来说，“搜索”就是在Google里输入关键词或短语。但对于使用搜索的智能体而言，世界要丰富得多，也奇特得多。

人们通常称之为“搜索”的，其实有三种相关任务。它们恰好与我们的产品对应得很好：

搜索和提取几乎总是配合使用。LLM经过专门训练，期望能深入页面内容。像Parallel这样的智能体搜索，专门设计为返回密集的片段——与查询相关的页面摘要——从而尽量减少对提取的依赖。因此，将搜索和提取结合使用总是一个好主意，因为模型可以自行决定是否需要深入探索。

尽管大多数开发者首先会想到使用搜索API，但值得确认的是，你的用例是否更适合研究（任务）API。如果任务是“接受这个目标和输出模式，进行搜索和阅读，并返回有来源、结构化的答案”——比如丰富公司列表、生成带引用的研究报告——任务API只需一个便捷的端点即可完成全部工作。

在配置任何内容之前，先确定你要衡量什么

如果你在评估搜索功能，很可能有一个待解决的问题。也许你正在丰富客户列表、为智能体添加搜索能力，或翻阅旧财报。无论你做什么，你关注的公式大概是：

智能体框架 + 大语言模型 + 搜索 + 提取 = 答案

最重要的是确保你有一套可信的黄金标准标签，并端到端评估整个“框架 + 模型 + 搜索”堆栈。避免只看输出（如特定搜索响应）或仅关注搜索成本。不要直接将查询传给搜索 API——你无法预知智能体会如何格式化查询或目标，而且你可能会惊讶地发现，智能体在提示方面比人类更擅长。始终评估最终答案。

构建黄金数据集

最好的数据是你已有的数据。也许你曾费心手工收集过往数据。如果这些数据与你预期使用搜索 API 的数据类型匹配，它们将构成一个极佳的评估集。

如果必须生成合成数据（唉），先手工编写几个问题，再让智能体生成更多。生成后，确保这些数据在尽可能多的维度上与你预期的生产数据匹配：措辞、领域、答案类型和时效性。

务必审查由大语言模型生成的黄金标签。你在获得结果时会重复这一过程，但最好在花费搜索和推理的令牌与金钱之前现在就做。

以下是一些可以混入的常见类型，只要它们与你的实际工作负载相似即可：

避免过度依赖公开基准测试。尽管它们在业界很流行，但它们反映的是特定领域的问题，很可能与你的实际情况不符。此外，一些答案早已在网上公开，并已被纳入LLM和搜索引擎索引的数据集中。如果你使用公开基准测试，如BrowseComp、SealQA等，务必理解每项测试衡量的是什么，以及它是否适合你的场景。

搭建测试框架

现在你已准备好运行第一次评估，而且还没到午饭时间。首先，保持除搜索工具外的一切不变：相同的模型、相同的提示词、相同的预算、相同的评判标准。将每个提供商作为唯一可用的搜索工具，让代理进行多轮交互——代理经过训练，会搜索、缩小范围、再搜索。不要通过限制轮数来扼杀它们的能力。相反，考虑限制它们的总搜索预算，以反映你的实际成本考量。

然后，按照各提供商的文档建议进行配置。不同提供商有不同的方式让搜索发挥最佳效果。

对于Parallel，我们常向客户推荐一些通用做法（更多详情见我们的最佳实践）：

将搜索模式与搜索模型相匹配

除了查询本身，搜索模式是你在使用Parallel的搜索API时最重要的控制手段之一。思考模式的一种方式是看它们搜索的广度和深度。fast模式非常适合大多数需要接近前沿质量且成本较低的代理型用例（成本更低 => 更多搜索！），而advanced模式则最大化质量。

哪个更好？坏消息又来了：这要看情况！

有时答案很明确，比如你有一个特定的产品限制需要解决：也许你的延迟要求迫使你使用turbo，或者你的预算要求你使用fast。但在大多数情况下，你应该评估多种模式，并找到最便宜、最快且能达到满意结果的模式。

当然，名称可能具有误导性，所以要看实际结果。

模型也很重要。将经济实惠的LLM与昂贵的搜索配对，或反之，通常是不合理的。所以不要只问：“哪个搜索提供商最好？”而要问：

哪种模型×搜索配置，在我们能承受的成本和延迟下，最适合这个任务？

为模型评分

在真正执行评估之前，您应考虑如何为答案评分。大多数人会采用某种“以LLM为裁判”的方法，利用高端模型将已验证的基准答案与结果进行对比。以下是一些常见的衡量技巧：

请记住，召回率指的是“我们找到了正确列表中的多少内容？”；精确率则指“我们返回的结果中有多少是正确的？”

信任但验证

使用LLM评判器时，切勿盲目信任其结论。确保评判器在返回结果的同时附带其推理依据。务必人工抽查至少10%的运行——包括失败与成功案例。此时你很可能会有有趣的发现，并希望将其纳入下一轮评判中。请确保你的代理跟踪已收集的答案，这样你就不必从头重新生成答案，只需执行评判步骤即可。

这并不引人注目，但你的代理可能失败的一些原因将是……基本的基础设施问题。以下是我们曾见过的一些情况：

只有检索未命中和提供商错误是搜索API的直接失败。由于评估通常在高负载下运行，许多失败可能反映的是账户限制而非实际能力。

做生意的成本

请记住，归根结底，重要的是完成任务的端到端成本：搜索开销加上智能体在推理搜索结果时消耗的LLM令牌费用。一个单次调用更便宜但返回结果嘈杂、密度低的API，总体成本可能更高——更多的调用、更多的跳转、每次调用中更多的上下文令牌。

因此，要以智能体的实际体验来衡量成本：

每个已解决任务的成本 =（搜索 + 提取 + 模型令牌费用）/ 已解决任务数

结果长度和跳转次数作为效率代理指标很诱人，但单独使用并不可靠：冗长的结果可能帮助智能体提前退出，过度压缩的结果可能迫使额外跳转，而并行工具调用会让跳转次数低估实际工作量。追踪每次运行的总体工具调用次数、端到端延迟和端到端成本——绝不要用替代指标。

解读结果

很少存在单一的“最佳”搜索工具；它们分布在权衡曲面上，即帕累托前沿。将结果绘制在XY图上——准确度对成本，以及准确度对延迟。你通常是在寻找一个在你最关心的象限中“位于前沿”的提供商。

有几个做法能将一个人们信任的基准与一个会被忽视或争论的基准区分开来：

检查清单

这就是评估代理搜索的方式。现在，你可以将领域专家从被遗忘的隔间中释放出来了。