BrowseComp

BrowseComp 问题通过多层间接线索锁定一个可验证的唯一答案，例如通过职业生涯片段描述的人物，或通过交叉约束定位的事件。一次搜索很少能找到答案；智能体必须提出假设、搜索、排除假设并调整方向。这使其成为我们衡量搜索 配置 所带来贡献的最有力工具：同一模型在完整的智能体预算下，得分比仅进行一次推理前搜索高出数倍。

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

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

此处将置信区间重叠视为尚无定论，而非相等的证明。当某个配置的效果略好但价格高出很多时，应结合质量来考量成本。

该数据集以加密形式提供，并附带金丝雀字符串以防其进入训练语料库，但问题是公开的；评分依赖实时多步骤搜索，难以通过记忆走捷径。

每项任务都是一道附有简短参考答案的问题。模型以固定格式（解释、确切答案、声明的置信度）作答，评判模型则判断提取的答案是否与参考答案在语义上等价。“1988 to 1996”与“1988-96”匹配；不同的实体则判为不通过。评分为二元制，不给部分分数，失败或被拒绝的任务得零分。

reward = judge(extracted_answer ≡ reference_answer)   // ∈ {0, 1}
judge  = gpt-4.1 at temperature 0, strict json_schema 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.