HyperBrowseComp：面向 Web-Browsing Agent 的多语多模态压力测试

  • 关联论文：2610.03574
  • 作者：flyP
  • 更新：2026-10-05

一句话结论

HyperBrowseComp 是一个由人工撰写、覆盖 13 种语言、刻意"上调难度"的多模态网页浏览基准（423 题），用来检验 Browsing Agent 是否真的能跨语种、跨模态（视频、扫描件、图片、地图）地"挖掘+拼图"式检索，而不是吃老本回答。

解决的真问题

过去一年，GAIA、HLE、WebArena、Mind2Web 等基准把"会浏览网页的 Agent"这件事炒得很热。然而这些基准有个隐忧：很多题目虽然标着"需要搜索"，但 LLM 用参数知识或浅层检索就能答上来；或者题目难度集中在英文一种模态。多语种真实用户（小语种、低资源语言）几乎没被代表。

HyperBrowseComp 想直击三个痛点：

  1. 基线可解污染：现有基准里大量题目被闭卷模型撞对，掩盖了真实检索/推理能力差距。
  2. 单语单模态盲点：英文 + 纯文本题占主流，非英文、图像/视频/扫描文档/地图题几乎缺位。
  3. 难度不可审计：题目太容易 → 头部模型拉不开档次；题目太难 → 噪声高。HyperBrowseComp 用"先用无联网模型过一遍，过关的全部筛掉"的方式反保硬。

核心机制

1. 数据构造流水线（4 步）

论文没在 abstract 写完整流程，但从题目"423 题 / 13 语言 / 人工撰写 / 母语者或精通者"和"无联网模型预筛"两个关键约束反推，构造大概是：

  • 母语作者撰写：每题由该语言的母语或高水平使用者撰写，避开翻译腔与文化语境损失。
  • 答案约束：每题有"简短、可公开验证"的答案（数字、专名、年份、URL 等），避免开放式回答带来评分噪声。
  • 线索链设计：题目故意指向"偏僻证据 + 多步推理"，需要 follow 多步线索链才能收敛。
  • 预筛反污染：用一组断网模型跑一遍所有题；凡是闭卷就能答对的，统统剔除——留下的题必须真的需要外部检索才能解决。

这相当于给数据集做了一道"闭卷可解性"的防火墙，把"伪检索题"砍掉。

2. 多模态覆盖

题目的证据可能藏在视频、扫描文档、图片、表格 HTML 网页等异构来源里。这意味着 Agent 不能只靠文本检索，必须：

  • 能解析视频（抽帧、读字幕、ASR）；
  • 能读扫描件（OCR）；
  • 能看图（看图说话、识别地标、地图判读）；
  • 能整合多源信息（同名线索交叉）。

这是 GAIA 类基准较少触及的部分。

3. 评估协议：统一检索 harness + 原生搜索 + 人类校准

评估采用两个并行设置：

  • Provider-native search：模型直接调用底层厂商提供的搜索 API（如 OpenAI / Anthropic / Google 的 native tool）。
  • 共享外部检索 harness：所有模型在统一检索栈（如同一种搜索引擎 + 抓取器 + 重排器）下接受同一份"外部工具"。

两路对比的好处是能区分"模型真的更会搜"vs"模型的搜索栈更好"。再加上人类在子集上做题做基线，给出 effort/正确率的对照，避免把"答不上"直接归因为 Agent 笨——可能是题本身对人类也难。

关键实验与数据

abstract 给出的硬数字较少，可核实的有：

  • 423 题（人工撰写 + 人类二验）；
  • 13 种语言；
  • 每题答案简短可公开验证；
  • 评估覆盖若干主流模型，跑两路：provider-native search + 共享外部 retrieval harness；
  • 另在子集上做人类评估做 effort 校准。

⚠️ 论文未明确：具体模型清单、闭箱预筛用了哪几个模型、各模型在 13/语言上的具体正确率分布、人类基线准确率与耗时。这些要进工程级落地必须看正文表（abstract 没给）。

亮点与局限

亮点

  • 反闭卷防火墙：用断网模型预筛剔除"伪检索题"，比单纯堆数据量更能拉开真伪。
  • 多模态 + 异构证据：覆盖视频/扫描件/地图/图片，填补了 GAIA 类基准的盲区。
  • 统一 vs 原生双栈评估：能区分"模型能力"和"工具栈能力"，避免把搜索红利算成模型红利。
  • 13 种语言：真正做到多语，而非英文基准 + 翻译对齐。
  • 人类 effort 校准：把"难度"用人做题时间/正确率定量，避免"主观题难"。

局限

  • 规模 423 题不大：相比 GAIA/HLE 的千题级别，统计显著性会偏弱；分层（13 语言）后每语言均值 ~32 题。
  • 语言分布未公开：abstract 没披露 13 种语言是哪些（看作者名单含 KZ、TH、VI、UZ、FA 等推测包含中亚/东南亚多语种，但仍需正文确认）。
  • 题目可被逆向工程：刻意难 + 公开可验证的答案，长期被刷榜后会泄露；需要定期迭代题目集。
  • 检索栈公平性难保证：所谓"共享外部检索 harness"具体配置（搜索引擎、抓取频率、超时）在 abstract 未明确，不同团队的复现可能不一致。
  • 评估成本高：13 语言 × 多模态 × 双路评估 × 人类基线，单轮评估预算不低。

⚠️ 诚实标注：论文未在 abstract 给出 GitHub / 数据集 / 模型卡的具体链接，需查正文/项目主页；评分细节、人类对照基线具体数字同样未在 abstract 披露。

对工程落地的启发

  1. 做自建基准必加"闭卷预筛"：拿一组无联网的模型过一遍，把"不搜也能答"的题砍掉——这条原则比堆数据量更能拉开真伪。
  2. 多模态 Agent 评测必须跨模态取证（视频/扫描/地图）：纯文本检索评测已经过拟合到"长上下文召回"上了。
  3. 多语种优先：低资源语言用户的真实痛点经常被英文基准掩盖；做产品级 Agent 必须用小语种题集验真。
  4. 统一栈 + 原生栈双路评估：上线自家 Agent 时，至少跑两套评估，避免"换了搜索 SDK 分数暴涨"但其实模型没变强这种错觉。
  5. 人类 effort 作难度锚：把人类做题耗时纳入题库难度标签，比单看模型准确率更稳。

与同方向工作的关系

  • GAIA：经典多步真实浏览基准，但英文主导 + 文本为主；HyperBrowseComp 是其多模态 + 多语强化版。
  • HLE（Humanity's Last Exam）：极难基准，但更偏 Q&A 而非 browsing 任务。
  • Mind2Web / WebArena：Web 任务操作型基准（点按钮、填表单），与 HyperBrowseComp 的"信息检索+多步推理"定位互补。
  • BrowseComp（OpenAI 2025）：纯英文信息检索基准，HyperBrowseComp 可看作其多语多模态延伸。
  • xBench / Seal-Tools：中文/双语 Agent 工具评测，HyperBrowseComp 在"多模态跨语种检索"上覆盖更全。

定位上，HyperBrowseComp 不抢"通用 Agent SOTA 评测"位，而是专攻"真实开放网络 + 多语种 + 异构证据"这块细分。

适合谁读

  • Agent / LLM 推理架构工程师：评估自家 browsing agent 在多语种 + 多模态下的真实差距。
  • 多语种产品团队：做面向小语种用户的搜索/助手时，需要这种难度天花板更高的基准。
  • 基准设计者 / 数据集作者：反闭卷防火墙、多模态证据构造、母语撰写流程可借鉴。
  • AI 安全 / 评估研究人员：把"题难度"用人类 effort 定锚的方法值得借鉴到所有开放域评测。
  • 不推荐：只想快速跑个 SOTA 数字、纯文本 QA 工程师；这个基准会让你的工具栈护城河满分。

不确定处（重要）

  • ⚠️ 具体模型清单与得分：abstract 未给出每个模型在 13/语言 × 双路的具体正确率。
  • ⚠️ 人类基线数字与平均耗时：abstract 仅说"conduct human evaluation"，未给具体百分比。
  • ⚠️ 闭卷预筛用了哪几个模型：abstract 仅说"models without internet access"，具体组合未公开。
  • ⚠️ GitHub / 数据集是否公开：abstract 未提公开仓库或下载链接，需查正文/项目主页。
  • ⚠️ 13 种语言列表：从作者名单推测含 KZ、TH、VI、UZ、FA、RU、EN、ID 等，但完整 13 种名单以正文为准。

边界：本解读仅基于 arxiv abstract + paper card + 作者名单推断；数字若与正文不一致，以正文为准。

工程落地与核查（Jay）

事实核查

  1. ⚠️ 423 题：需 PDF 确认具体数字，abstract 未给；解读引用该数字但需正文核实。
  2. ⚠️ 13 种语言完整名单：作者名单含 KZ（哈萨克语？）、TH（泰语）、VI（越南语）、UZ（乌兹别克语）、FA（波斯语）等，但完整 13 种以正文为准——解读中"中亚/东南亚多语种"为高置信度推断，非确认事实。
  3. ⚠️ 闭卷预筛模型组合：abstract 未给出具体用了哪些模型（GPT-4o / Claude / Gemini?），无法评估预筛严格程度。
  4. ⚠️ GitHub / 数据集链接：abstract 完全未提；解读在"工程落地启发"中建议"自建基准加闭卷预筛"，但原始基准本身 GitHub 链接未在 abstract 给出——工程团队应先确认数据集是否真的可获取，否则无法直接复现。
  5. ⚠️ 双路检索 harness 具体配置：abstract 未披露搜索引擎型号、抓取频率限制、超时配置等，"共享外部检索 harness"的公平性无法独立验证。
  6. ⚠️ 人类基线 effort 数字：abstract 仅说"conduct human evaluation"但无具体耗时或准确率，无法与模型结果做有据对比。

实际系统怎么用

坑 1：反闭卷预筛的计算成本——"听起来简单，做起来贵" 用一组闭网模型（GPT-4o / Claude / Gemini 等）跑 423 题的闭卷推理： - 若用 API：约 423 × 3 models × 单价 ≈ $15~50 每次全量预筛（具体视模型定价）； - 若需多语言模型：部分小语种（哈萨克语、乌兹别克语）主流模型能力弱，预筛效果打折； - 维护成本：每 3~6 个月需重新跑预筛防止题库泄露，持续成本不容忽视。

坑 2：多模态证据获取的系统依赖——每种模态都是独立工程坑 - 视频：需视频下载 + 抽帧 + ASR/字幕提取链路；非英语视频（如泰语/越南语）ASR 质量差异显著； - 扫描件：需 OCR，扫描质量差（如手机拍摄、倾斜角度）的图片 OCR 错误率高，会导致证据无法被正确提取； - 地图：涉及地理信息 API / 瓦片图抓取，涉及隐私合规与 rate limit； - 表格 HTML：解析逻辑需适配各国网站结构，CSS/JS 渲染差异大。

⚠️ 建议先确认自家 Agent 的多模态链路覆盖度，再决定是否在这套基准上做评测。

坑 3：多语言评测的信度——小语种人类基线极难建立 - 找 13 种语言各自的"母语者且有 AI/LLM 背景"做人类对照，招募成本极高； - 若用非母语者做人类基线，测量误差可能超过模型间差距，导致"人类 effort 校准"形同虚设； - 实际建议：若无法建立可靠人类基线，可以降低对 effort 校准维度的依赖，改为与"题目在单一语言子集上的 top-1 模型"做横向对比。

坑 4：题目逆向工程与数据泄露风险 - 423 题 + 公开可验证答案 → 若有刷题社区（如 ShareGPT / AgentOps）收录，模型可直接背答案； - 防御措施：每次评估前随机抽取 N% 题目换题，或在答案上加轻微扰动（如日期 + 随机偏移）验证是否真的推理； - 建议工程团队：不要把 HyperBrowseComp 作为唯一评测基准，应与线上流量 A/B 测试结合使用。

坑 5：双路评估的"工具栈 vs 模型"归因陷阱 - provider-native search 分数高 ≠ 模型强，可能是厂商搜索 API 本身更好； - 共享 external harness 分数高 ≠ 工具栈好，可能是模型本身推理能力强； - 正确的解读方式：用 (provider-native - external) 的差值来归因——差值为正说明模型适配了该厂商工具链；差值为负说明模型在通用工具链上更稳定。

工程落地优先级建议

优先级 动作 说明
P0 确认数据集是否真的公开可获取 若 GitHub/数据集链接不存在，基准无法直接使用
P0 确认闭卷预筛用了哪些模型 直接决定预筛严格程度，影响题目质量判断
P1 评估自家 Agent 多模态链路覆盖度 若缺视频/OCR/地图能力，评测结果反映的是工具缺位而非模型弱
P1 建立小语种人类基线（或放弃 effort 校准维度） 招募成本高，可考虑用"模型盲答正确率"替代
P2 防范题目泄露：定期换题 + 答案扰动验证 维持基准信度
P2 双路归因分析框架落地 区分工具栈效应和模型能力效应