DeepSearchQA

查找一条事实与查找 每一条 事实是不同的搜索问题。一次幸运的查询就能找到 BrowseComp 的答案；而 DeepSearchQA 的答案必须通过多次搜索汇总而成，智能体需要跟踪已找到的内容和尚缺的内容。这种覆盖范围的压力考验了搜索技术栈的另一个方面：结果的广度和去重与排序同样重要。

我们在固定模型的情况下运行测试，因为这样可以单独考察 OpenRouter 用户实际能够控制的变量。这些变量包括由哪个引擎处理搜索、搜索以服务器工具还是插件的形式运行，以及智能体循环允许执行多少轮。这些参数正是您如今可以在请求中设置的内容。

这些分数比较的是搜索配置，而非智能体产品。模型仅读取搜索结果摘要，不抓取完整页面，也不使用代码工具，因此绝对分数低于已发布的智能体排行榜，后者允许这两种操作。请比较配置，而非原始分数水平。

全对才得分的评分方式使这套测试十分严格：遗漏一个列表成员与遗漏全部成员的得分相同，因此分数偏低，搜索引擎间的小幅差距也容易受噪声影响。此处将置信区间重叠视为尚无定论，而非相等的证据。配置的成本与其分数同样实在，因此请结合质量和效率进行解读。

这些问题是公开的，这意味着记忆效应可能会随着时间推移抬高绝对分数；搜索配置之间的差异仍有意义，因为每种配置都使用相同的模型。

每项任务都是一个问题，并附有预期答案要点的参考列表。评判模型会逐一核对回答是否涵盖每个预期要点，同时标记多余答案，即回答中断言但参考列表中未包含的内容。只有当评判模型找到所有预期要点且未发现任何多余答案时，任务才算正确。评分采用二元制，不给部分分数，失败或被拒绝的任务得分为零。

reward = all_expected_parts_found ∧ no_excessive_answers   // ∈ {0, 1}
judge  = gemini-2.5-flash, strict json_schema completeness verdict
empty or refused answers skip the judge and score 0

搜索配置包含一个模型、搜索引擎、请求格式和最大搜索预算。分数按每次已验证运行中的问题数量加权；小规模冒烟测试不计入。

运行任务在 OpenRouter 的基准测试框架 Kepler 上执行，面向生产端点。服务器工具配置为以下工具设置请求级别的工具调用预算： 网页搜索服务器工具。插件配置会在推理前使用以下插件对问题进行一次搜索： 网页搜索插件。各引擎使用与处理生产流量相同的默认配置。

每次运行都会持久保存其确切的模型、引擎、请求格式、搜索预算、成本以及可用的计时遥测数据。缺失的配置在比较表中仍保持缺失，并且 absent or zero telemetry is not treated as free or instantaneous performance.