OpenRouter 推出实时网页搜索基准测试：如何为智能体选择引擎、深度与模型

对于大多数 LLM 请求来说，网络搜索已是必备手段，用以突破知识截止日期的限制。各家实验室和搜索提供商正在快速演进，让搜索更有效、更高效，这也让我们所有人都面临一系列棘手抉择：是采用某些实验室内置的原生搜索，还是接入 Exa、Parallel 或 Perplexity 这样的第三方引擎？一次搜索够不够，如果不够，我该让智能体持续搜索多久？更多的搜索轮次是否值得它们所换来的质量提升？

我们构建了实时排行榜，帮助你用数据决定最佳的搜索配置。查看数据请见我们全新的 Benchmarks 页面。

我们对所有组合进行基准测试，以找出各自的优势与劣势

在设置一次搜索请求时，你有四个决策：

• 模型。它负责写出提交给搜索引擎的确切查询，并处理返回的结果。
• 引擎。你可以选择某个特定的引擎，也可以依赖某些实验室提供的捆绑引擎。在 OpenRouter 上，我们提供 Exa、Parallel 和 Perplexity，以及来自 OpenAI、Anthropic 和 Google 等实验室的原生引擎。
• 搜索方式。你既可以在调用模型之前先执行搜索，并把结果作为上下文传入，也可以为模型配备一个网络搜索工具，由它自行决定何时调用。
• 搜索预算。如果你选择搜索工具方式，你还可以给模型设定一个允许执行多少次搜索的预算。这使模型能够在对结果不满意时调整查询，或进行后续搜索。我们的运行使用 1、5 或 25 轮。

为了全面了解网络搜索性能，我们定期在多个模型、引擎和搜索配置上运行四项基准测试：

• BrowseComp：需要真实浏览的困难事实查找
• DeepSearchQA：多跳研究问题
• WideSearch：广泛的“填满整张表格”式收集
• HLE：带搜索的专家考试题

每个页面都按质量、性价比和速度对配置进行排名，因此你可以根据对自身工作负载最重要的因素做出决策。排行榜是实时的，因此随着新的运行结果落地以及新模型和引擎的加入，数字会不断变化。今天的领先者未必是明天的领先者。本文不会花太多时间讨论今天的领先者，因为我们预计这会随时间而变化。相反，让我们看看数据告诉了我们什么，以便为你的工作负载做出决策。

搜索预算比其他任何因素都更重要

将引擎预算从一轮开始提升，对质量的改善超过你能做的任何其他单项改动。为说明这一点，以下是我们在 Perplexity 上以三种不同预算对 BrowseComp 的初始运行结果：

这一规律在我们测量的所有提供商中都成立：

这些运行仅覆盖 BrowseComp，使用服务器工具，每次搜索返回十条结果，不进行页面抓取或代码执行，且每种配置取最近一次符合条件的运行。

增加搜索深度是我们发现的提升质量最便宜的方式。从 1 轮增加到 25 轮，得分大约翻倍，而每个问题的成本仅增加 2.5-7 倍。

你可能会认为这普遍会拖慢响应时间，但事实并非总是如此。例如，Luna 在 1 轮时每个问题耗时 140 秒，在 25 轮时为 111 秒。在我们同时以 1 轮和 5 轮运行的 35 种配置中，超过三分之一在轮数更少时反而更慢。这些全都是 OpenAI 的模型。这些模型通过额外的推理来应对受限的搜索预算。

另一方面，在较简单的任务上，搜索深度可能反而对成本不利。例如，在 HLE 上，搭配 Perplexity 的 GPT-5.6 Sol 在 1 轮和 25 轮之间得分相近，成本却是三倍。如果你的搜索往往比较简单，那么限制预算可能仍然值得。

你最坏情况的成本由失败率决定

扩大预算带来不利影响的另一种情况，是模型未能找到答案时。我们发现，模型会耗尽预算去尝试寻找答案，尽管它们最终仍会失败。

我们记录到的最深尝试是在一个 WideSearch 表格上进行了 81 次搜索，但最终仍被判定为错误。如果你的工作负载失败率很高，那么降低搜索深度很可能是降低成本的一条高效路径。

引擎固然重要，但模型更重要

一旦预算确定，下一个最重要的问题就是使用哪个模型。

上表展示了在 25 轮对话时的 BrowseComp 结果，对比了前沿模型与低成本模型在不同搜索引擎上的表现。

在模型保持不变的情况下更换搜索引擎，得分平均变化 10 分，而前沿模型与高性价比模型之间的平均差距更大，为 15 分。在各搜索引擎之间，前沿模型的成本差异最大，最贵的引擎成本是最便宜引擎的 2.5 倍，而高性价比模型则为 1.5 倍。

之所以能够进行这样的对比，是因为该服务器工具位于提供商之上。在请求中更换模型，搜索行为保持一致，包括那些其提供商自身并未提供搜索功能的模型。

当然，基准测试只是对可能性能的参考。它们告诉你哪些配置值得尝试，以及大致需要多少成本。这些选择在你自己的真实任务中的成本和质量会有所不同，因此你能用这些页面做的最有价值的事情，就是把它们当作一份候选清单，然后用你自己的问题在排名靠前的几个配置上跑一遍。

在你自己的工作负载上试一试

以上所有内容都是你今天就可以在 OpenRouter 上设置的请求参数。

• Web 插件。web 插件会在模型开始写作之前执行一次搜索，对于只需要最新事实的问题来说，这是快速、低成本的选择。
• 服务器工具。 服务器工具把搜索工具交给模型，让它自行决定接下来要查什么，当答案需要经过好几步才能找到时，这正是你想要的方式。
• 引擎。 在 OpenRouter 上，你可以把 engine 设为 exa、parallel、perplexity 或 native；auto 会先尝试原生方式，再回退到第三方。
• 搜索预算。 顶层的 max_tool_calls 请求字段限制了智能体可进行的轮数，也就是在必须给出答案之前最多可以搜索多少轮，而 max_results 则设定每次返回多少条结果。

一个合理的起点是：选择最贴近你任务的评测套件，在最高分几个百分点之内挑选最便宜的配置，然后针对它上面的两到三行重新运行你自己的评测集，看看多花的钱是否体现在你的结果中。

基准测试方法

每次运行都通过公开的 OpenRouter API 针对生产端点进行，使用我们的开源基准测试框架。

• 隔离到搜索性能。 为确保我们只比较搜索配置，我们统一设定为每次搜索十条结果、不抓取页面、不执行代码。推理按模型固定，如表中所反映。
• 评分标准很严格。每个被评估的答案都会对照官方答案标准判定为正确或错误，在需要语义比较时使用 LLM 作为评判者。WideSearch 还会单独报告答案项的准确率。
• 成本和速度均按每个问题计算。成本是总支出（包括评分）除以被评估的问题数。速度是每个被评估问题的候选生成时间。
• 每个页面都会显示每种配置的最新合格运行结果。一次运行在完成最低数量的问题后即视为合格，新的运行会取代旧的运行。

常见问题

这些分数与厂商公布的智能体排行榜相比如何？

它们不能直接比较。这些基准的大多数已公布表格衡量的是结合了搜索、完整页面抓取和代码工具的完整智能体产品。而这些排行榜隔离的是搜索配置：模型只读取搜索结果摘要，页面抓取和代码工具均关闭。这样可以实现配置之间的直接比较，但不会最大化基准分数。

我应该选择哪个搜索引擎？

这取决于具体的模型和任务，这正是这些页面存在的意义。不同引擎之间的差距在某些模型上很大，在另一些模型上则微乎其微，而且提供商自家的原生搜索并不自动就是其最佳选择。请查看与你工作负载最接近的那套测试的实时排行榜，在阅读分数的同时一并关注成本和延迟，并随时间反复核查，因为随着新的运行结果不断加入，排名会发生变化。

这些数字的时效性如何？

排行榜始终显示每种配置最新的合格运行结果，这些结果是在 OpenRouter 的基准测试框架上针对生产端点执行的。新运行结果会在页面上取代旧结果。

请在 Discord 的 #feedback 中告诉我们接下来应该对哪些引擎或模型进行基准测试。