OpenRouter 上线实时网页搜索基准榜单，为智能体选引擎、深度与模型提供实测数据

对于大多数 LLM 请求来说，网络搜索是克服知识截止日期限制的标配。各实验室和搜索提供商正在快速演进，让搜索更有效、更高效，这给我们所有人留下了一连串棘手的决策：是采用某些实验室内置的原生搜索，还是接入第三方引擎，如 Exa、Parallel 或 Perplexity？一次搜索就够了吗？如果不够，我要让智能体继续搜索多久？更多的搜索轮次换来的质量提升是否值得？

我们构建了实时排行榜，帮助你用数据来决定最佳的搜索配置。请在我们全新的基准测试页面上查看数据。

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

在设置搜索请求时，你需要做四个决策：

• 模型。撰写提交给搜索引擎的确切查询，并处理搜索结果。
• 引擎。你可以选择特定的引擎，或依赖某些实验室提供的捆绑引擎。在 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中告诉我们接下来应该对哪些引擎或模型进行基准测试。