HLE

在搜索需求谱系中，HLE 与 BrowseComp 分处两端。它的题目由领域专家编写，表述明确无歧义但难度极高，因此模型的基准得分主要取决于其已有知识。加入网页搜索后，问题就变成了另一个：搜索配置能按需检索到多少专家级知识？

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

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

由于 HLE 更侧重专业知识而非浏览深度，因此搜索配置之间的差异比在 BrowseComp 上更小：许多问题在各个预算水平下都会以相同方式得到解答（或未能解答）。对于置信区间重叠的引擎差距，此处视为尚无定论，而非相等的证据。配置的成本与其分数同样真实，因此请结合质量和效率一起评估。

我们使用公开数据集的纯文本子集（不包含多模态问题），因此分数无法与完整 HLE 排行榜直接比较。题目是公开的，这意味着随着时间推移，记忆效应可能抬高绝对分数；搜索配置之间的差异仍有意义，因为所有配置使用的都是同一个模型。

每项任务都是一道附有简短参考答案的问题。模型按固定格式作答（解释、确切答案、所声明的置信度），裁判模型则评判提取出的答案是否与参考答案在语义上等价——这与 BrowseComp 使用的答案等价性评分方式相同。评分采用二元制，不给部分分数，失败或拒绝回答的任务得零分。

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.