HyperEyes: Dual-Grained Efficiency-Aware Reinforcement Learning for Parallel Multimodal Search Agents

Paper: arXiv:2605.07177 Code: DeepExperience/HyperEyes Code reference: main @ 61548258 (2026-05-23)

1. Motivation (研究动机)

现有 Multimodal Search Agent 的核心问题不是“会不会搜索”，而是“以什么交互形态搜索”。DeepEyes-V2、MMSearch-R1、WebWatcher、VDR、REDSearch 等 agent 通常沿用 ReAct 式串行轨迹：先定位一个实体、调用一次工具、读回观察，再定位下一个实体。对多实体视觉问题或多约束检索问题来说，这会把本来互相独立的子检索拆成长链条，造成两类损失：第一，工具调用轮数随实体数增长，延迟和推理成本急剧上升；第二，越长的检索链越容易累积 distractor evidence，后续回答会被早期噪声污染。

Figure 1 解读：左侧传统 multimodal search agent 把“裁剪实体—搜索—读证据”重复执行多次；右侧 HyperEyes 把多个目标区域一次性作为 image_search 的 area 列表传入，并把多个独立文本子问题一次性作为 text_search 的 input 列表传入。图中强调的不是单纯并发工程优化，而是 action space 本身允许模型在一个 reasoning turn 中表达“多实体并行检索”。

更深层的动机是：即使模型具备并行工具调用接口，也不等于它会自动学会高效调用。只用最终 accuracy 做 RL reward 时，模型可能把并行能力退化成 brute-force over-search：一次 turn 里塞入过多检索、或在多轮里反复补查，accuracy 偶尔提升但成本不可控。因此这篇论文把 inference efficiency 提升为训练目标的一部分，要求 agent 在保持正确率的同时学习“search wider, not longer”。

该问题值得研究，是因为多模态搜索 agent 的真实应用往往面对开放世界、可验证信息和多个视觉实体：电商/旅游图片问答、体育图像统计、图像中人物/物体的外部知识检索等。若每个实体都要串行检索，延迟和工具费用会让 agent 难以实时部署；若能够在单轮完成 grounded retrieval，则可以把 grounded multimodal QA 从“深而慢的搜索链”变成“宽而短的检索批处理”。

2. Idea (核心思想)

HyperEyes 的核心 insight 是：多实体 multimodal search 的瓶颈不只在模型推理能力，而在 action space 与训练信号错配。论文把视觉 grounding 和 image retrieval 合并成一个 Unified Grounded Search (UGS) 原子动作，再用 trajectory-level 的效率 reward 和 failed-rollout token-level distillation 同时约束“少轮数、少冗余、保留正确中间步骤”。

关键创新可以概括为三点：第一，UGS 允许 image_search(image_id, area=[[...], ...]) 一次处理多个 normalized boxes，并允许 text_search(input=[...]) 一次处理多个独立 query；第二，Parallel-Amenable Data Synthesis + Progressive Rejection Sampling 先给 SFT 阶段提供短而正确的并行轨迹；第三，Dual-Grained Efficiency-Aware RL 用 TRACE 奖励压缩 tool-call cost，用 OPD 在失败轨迹上从 235B teacher 注入 token-level 修正。

与 DeepEyes-V2 的区别很具体：DeepEyes-V2 依赖 crop-then-search 的串行 pipeline，agent 需要先产出 crop，再对 crop 做 image search；HyperEyes 则把 box list 作为 image search 参数，让模型直接表达“这些区域都需要检索”。与只做 accuracy reward 的 GRPO agent 相比，HyperEyes 的 TRACE 不是奖励“多搜就可能答对”，而是根据每个样本的参考工具成本动态收紧效率边界，正确但冗余的轨迹也只能拿到较低或负向的 tool reward。

3. Method (方法)

3.1 Overall framework：UGS + 数据合成 + 双粒度 RL

Figure 2 解读：框架分两阶段。上半部分是 Parallel-Amenable Data Synthesis：先从 public benchmarks、自合成 visual multi-entity / textual multi-constraint 任务得到 271k QA pool，再用 Progressive Rejection Sampling 选出 30k 短成功轨迹做 SFT。下半部分是 Dual-Grained Efficiency-Aware RL：GRPO 采样多条 rollout，TRACE 在 trajectory level 奖励正确且低成本的轨迹，OPD 在 failed rollouts 上调用 frozen teacher 给 token-level reverse KL 信号。

直觉上，SFT 负责把模型从普通 MLLM 拉到“能按 schema 并行调用工具”的 cold-start 区域；TRACE 负责把“能调用”进一步变成“愿意少调用、并且不在单轮塞满无用检索”；OPD 负责避免 sparse reward 把失败轨迹中正确的 reasoning / tool-call token 一起惩罚掉。这三个模块分别处理可行性、效率边界、credit assignment，少一个都会暴露不同 failure mode：无 SFT 时 schema 和并行行为不稳定；无 TRACE 时 tool calls 膨胀；无 OPD 时 30B student 很难从失败轨迹中恢复局部正确步骤。

3.2 Formulation and Unified Grounded Search

HyperEyes 沿用 ReAct 轨迹形式。给定 query $q$ ，轨迹写作： $τ = (q, (r_{0}, a_{0}, o_{0}), (r_{1}, a_{1}, o_{1}), \dots, (r_{T}, a_{T}, o_{T}), y),$ 其中第 $t$ 轮的 context 为 $h_{t} = (q, (r_{0}, a_{0}, o_{0}), \dots, (r_{t - 1}, a_{t - 1}, o_{t - 1}))$ ，policy $π_{θ}$ 生成 reasoning trace $r_{t}$ 、选择 tool call $a_{t} \sim π_{θ} (\cdot ∣ h_{t}, r_{t})$ ，再从 retrieval environment 得到 observation $o_{t}$ 。

UGS 的 tool schema 来自论文 prompt 和 released code：image_search 支持整图检索，也支持 area 参数一次传入多个 normalized boxes；text_search 支持把多个 query 放入 input list。released code 中 env_agent.py 的 parallel_image_search_observation() 和 parallel_text_search_observation() 都用 asyncio.gather 并发发起请求；image_search 分支会先用 crop_area_from_image() 依据 $[x_{1}, y_{1}, x_{2}, y_{2}]$ 裁剪多个区域，再把成功裁剪得到的 img_i 列表并行送入 reverse image search。这样，一个 model turn 可以产生多个 retrieval observation，而不是每个实体消耗一个 turn。

Figure 6 解读：这个 appendix case study 对比 serial DeepEyes-V2 与 HyperEyes。DeepEyes-V2 逐个处理人物，多个中间 observation 会把噪声持续带入下一轮；HyperEyes 在一个 image_search 中提交多个区域，并在后续统一综合证据。该图解释了为什么“并行”不仅减少 latency，也减少链式检索带来的 distractor accumulation。

def unified_grounded_search_step(model_output, image_registry, text_search, image_search):
    action = parse_xml_json_tool_call(model_output)  # <reason>, <tool_call>, <answer>
    if action.answer is not None:
        return {"done": True, "answer": action.answer}
 
    if action.name == "image_search":
        image_id = action.arguments.get("image_id", "img_0")
        areas = action.arguments.get("area")
        if areas:
            crops = []
            for box in areas:
                crop = crop_area_from_image(image_registry[image_id], box)  # normalized bbox
                if crop is not None:
                    crops.append(crop)
            observations = await asyncio.gather(*[image_search(crop) for crop in crops])
        else:
            observations = await asyncio.gather(image_search(image_registry[image_id]))
        return {"done": False, "observation": merge_observations(observations)}
 
    if action.name == "text_search":
        queries = action.arguments.get("input", [])
        if isinstance(queries, str):
            queries = [q.strip() for q in queries.split("|") if q.strip()]
        observations = await asyncio.gather(*[text_search(q) for q in queries])
        return {"done": False, "observation": merge_observations(observations)}

3.3 Parallel-Amenable Data Synthesis and SFT trajectory curation

训练数据由三类来源组成。Public benchmarks 提供 LiveVQA 100k、REDSearch 10k、InfoSeek 41k、iNaturalist 75k、Google-Landmark 12k、DeepDive 3k；自建数据包括 5k internal human annotations、20k Visual Multi-Entity、5k Textual Multi-Constraint。经过 tool-necessity filtering 后，总池为 271k genuinely tool-dependent QA pairs，其中 30k 用于 SFT，约 6k / 9k 用于 30B / 235B RL。

Visual Multi-Entity synthesis 从 CUB-200-2011、Oxford Flowers-102、Stanford Cars、FGVC-Aircraft、Oxford-IIIT Pets 等 fine-grained classification datasets 出发，先用 Gemini-3.0-Flash web search / page crawling 构建 per-class knowledge base，再把不同类的图像 mosaic 成多实体 scene，并生成必须整合所有实体知识才能回答的 QA。Textual Multi-Constraint synthesis 则从 Wikidata multi-hop random walk 得到候选实体，采样 $m \geq 2$ 个 predicate，使 predicate intersection 定义唯一答案。

SFT 轨迹通过 Progressive Rejection Sampling (PRS) 获得。PRS 的关键不是“采更多轨迹”，而是从最小 turn budget 开始寻找成功轨迹；一旦某个 budget 下存在成功 trajectory，就返回其中 tool turns 最少的一条，从而天然偏向 one-shot parallel dispatch。

def progressive_rejection_sampling(q, answer, policy, budgets, num_rollouts, judge):
    for budget in sorted(budgets):
        rollouts = [policy.rollout(q, max_turns=budget) for _ in range(num_rollouts)]
        successful = [tau for tau in rollouts if judge(tau, answer) == 1]
        if successful:
            return min(successful, key=lambda tau: tau.num_tool_turns)
    return None  # REJECT

最终 SFT 用 next-token prediction 训练 base MLLM，让模型先学会 <reason>/<tool_call>/<answer> schema、并行 area list、并行 input list，以及“证据足够后停止调用工具”。论文 appendix 给出的 SFT 配置是 LoRA：rank $r = 8$ 、 $α = 32$ 、target modules 为 all-linear，1 epoch，global batch size 64，max sequence length 32k，每图最多 1,200 visual tokens，训练在 8 nodes × 8 NVIDIA H20 141GB GPUs 上进行。released repo 当前包含 SFT/ms-swift-hypereyes/ fork，但我没有找到 paper-specific SFT launch config；因此上述 SFT 数字按论文 Appendix E 记录，而 RL 数字按 released HyperEyes_RL.sh 交叉验证。

3.4 TRACE：trajectory-level efficiency reward

TRACE 的目标是给每个样本维护一个“合理工具成本”参考，而不是设置全局固定阈值。总 reward 为： $R = R_{acc} + R_{fmt} + R_{tool},$ 其中 $R_{acc} \in {0, 1}$ 是 correctness judge， $R_{fmt} \in {0, - λ_{fmt}}$ 惩罚 schema parse failure， $R_{tool}$ 是效率项。论文用两个成本维度描述轨迹：tool-call rounds $t_{c}$ 与所有 rounds 内总 tool invocations $t_{s}$ 。每个 medium-difficulty RL sample 初始用 SFT 成功轨迹的 $t_{c}, t_{s}$ 作为 $\hat{t}_{c}^{(0)}, \hat{t}_{s}^{(0)}$ ；之后每个 epoch 用成功 rollout 中最小 $t_{c}$ 单调收紧： $\hat{t}_{c}^{(e + 1)} = min (\hat{t}_{c}^{(e)}, t_{c}^{(e + 1)}), e = 0, 1, \dots, n - 1.$ TRACE 的 tool reward 为： $R_{tool} = ⎩ ⎨ ⎧ - λ_{red}, 0, R^{+} \in [r_{m i n}^{+}, r_{m a x}^{+}], R^{-} \in [r_{m i n}^{-}, r_{m a x}^{-}], R_{acc} = 0 and (t_{c} < \hat{t}_{c} or t_{c} > γ \hat{t}_{c}) R_{acc} = 0 and t_{c} \in [\hat{t}_{c}, γ \hat{t}_{c}] R_{acc} = 1, t_{c} > 0, t_{c} \leq \hat{t}_{c} and t_{s} \leq \hat{t}_{s} R_{acc} = 1, t_{c} > 0, otherwise .$ 对于 group size $G$ 内的 rank $ρ$ ，论文再用线性插值给连续信号： $R^{*} = r_{m i n}^{*} + \frac{G - ρ}{G - 1} (r_{m a x}^{*} - r_{m i n}^{*}), * \in {+, -} .$ 代码实现中，HyperEyes_reward_V1_2_w_dynamic_w_OPD_v0.py 会解析 completion，统计 tool_count、search_count、max_parallel 和 per_turn，再用 group bonus 给正确且更省工具的 rollout 更高分。HyperEyes_RL.sh 里实际 RL 配置包括 --advantage-estimator grpo、--eps-clip 0.2、--eps-clip-high 0.28、--eps-clip-c 3、--use-tis、--kl-loss-coef 0.00、--entropy-coef 0.00。

论文公式与 released code 实现差异：论文描述 TRACE reference 会跨 epoch 单调更新；当前 main@61548258 的 reward file 虽然保留了 BaselineCache 类和“单调递减、逐步收紧参考标准”的注释，但 reward_func 路径中出现 # skip cache update，实际使用 sft_tc = orig_sft_tc、sft_total = orig_sft_total、eff_parallel = orig_parallel，没有调用 cache update。也就是说，当前开源版本更像“基于 SFT reference 的 group efficiency bonus + OPD branch 标注”，与论文中的动态 TRACE cache 存在实现差距。

def trace_reward_for_group(stats, sft_ref):
    bonuses = []
    for stat in stats:
        acc = stat.acc_reward
        tc = stat.tool.count
        total_search = stat.tool.total
        if acc <= -0.5:
            bonuses.append(0.0)        # parse / format failure
        elif acc <= 0:
            too_short = tc < sft_ref.tool_call
            too_long = tc > int(1.5 * sft_ref.tool_call)
            bonuses.append(-0.1 if too_short or too_long else 0.0)
        else:
            bonuses.append(None)       # correct trajectories ranked below
 
    ranked = [i for i, b in enumerate(bonuses) if b is None]
    ranked.sort(key=lambda i: (stats[i].tool.count, stats[i].tool.total))
    for rank, i in enumerate(ranked):
        hi, lo = (0.20, 0.05) if is_strictly_efficient(stats[i], sft_ref) else (-0.02, -0.10)
        bonuses[i] = hi if len(ranked) == 1 else hi - (hi - lo) * rank / (len(ranked) - 1)
    return [stat.acc_reward + bonus for stat, bonus in zip(stats, bonuses)]

3.5 OPD：failed-rollout token-level correction

TRACE 是 trajectory-level reward，因此失败 rollout 上所有 token 都会共享负 advantage；这会错误惩罚失败轨迹中已经正确的局部 reasoning 或 tool call。OPD 的做法是在 $R_{acc} (τ) = 0$ 的 rollout 上，用 frozen teacher $π_{teacher}$ 给 completion tokens 做 reverse KL： $ \mathcal{L}(\theta) = \mathcal{L}_{\text{GRPO}}(\theta)

\lambda_{\text{kd}},\mathbb{E}{\tau\sim\pi{\theta}^{\text{old}}}!\left[ \mathbf{1}[R_{\text{acc}}(\tau)=0]\cdot \frac{1}{|\mathcal{A}\tau|}!\sum{t\in\mathcal{A}\tau}! \mathrm{KL}!\bigl(\pi\theta(\cdot\mid s_t),|,\pi_{\text{teacher}}(\cdot\mid s_t)\bigr)\right]. $ 论文强调 reverse KL 的 mode-seeking 性质：student 会靠近 teacher 高概率的推理模式，而不是平均多个可能模式；并且 KL 只作用在失败 rollout，避免覆盖 TRACE 已经发现的成功并行策略。released code 中 reward_func 对 acc <= 0 的样本返回 opd_branch="reverse_kl"，对成功样本返回 opd_branch="skip"；训练脚本开启 --use-opd、--opd-type sglang、--opd-kl-coef 0.05、teacher timeout 500s、connector limit 32。论文的 teacher 是已经 RL 收敛的 HyperEyes-235B (RL)，对 30B student 提供 token-level guidance。

def assign_opd_branch_and_loss(rollout, acc_reward, student_logits, teacher_logits):
    if acc_reward > 0:
        return {"opd_branch": "skip", "opd_loss": 0.0}
 
    student_log_probs = torch.log_softmax(student_logits, dim=-1)
    teacher_probs = torch.softmax(teacher_logits.detach(), dim=-1)
    reverse_kl = F.kl_div(student_log_probs, teacher_probs, reduction="batchmean")
    return {"opd_branch": "reverse_kl", "opd_loss": 0.05 * reverse_kl}

3.6 IMEB benchmark and Cost-Aware Score

Figure 3 解读：IMEB 包含 300 个人工审核的 multi-entity visual instances，平均每张图 4.6 个实体，覆盖多种 domain。图中右侧示例展示了典型问题结构：答案不能只靠图像像素得出，需要先识别多个实体，再检索外部信息并综合比较。IMEB 的价值在于它把“多实体并行搜索是否高效”显式纳入 benchmark，而不是只看最终 answer correctness。

IMEB 的 cost-aware score 定义为： $CAS = \frac{Acc ^{2} \times 100}{N _{tok} + 2 N _{tool} + 1} .$ 其中 $N_{tok}$ 以千 token 计， $N_{tool}$ 是 sequential tool-call rounds。平方 accuracy 保证正确性仍是主目标；分母则惩罚 generation cost 和 tool execution cost，近似把二者都视为约一秒 latency overhead。

Figure 4 解读：appendix 对比三种 search paradigm：HyperEyes UGS、LLM-Crop、Code-Crop。在 30B 和 235B backbone 上，UGS 同时改善 accuracy 与 average tool-call turns；这说明收益不是只来自更强 backbone，而是来自 action schema 对多区域 grounded retrieval 的表达能力。

Code reference: main @ 61548258 (2026-05-23) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
UGS action schema / prompt	`prompts/hypereys_system_prompt.tex`, `prompts/system_prompt_for_trajectory_construction.tex`	`image_search` with `area`, `text_search` with `input` list
Parallel image/text search environment	`RL/relax-hypereyes/examples/HyperEyes/env_agent.py`	`crop_area_from_image`, `parallel_image_search_observation`, `parallel_text_search_observation`, `HyperEyesEnv.step`
TRACE-style reward statistics and group bonus	`RL/relax-hypereyes/examples/HyperEyes/HyperEyes_reward_V1_2_w_dynamic_w_OPD_v0.py`	`extract_completion`, `compute_single_stats_async`, `compute_group_bonus`, `reward_func`
Dynamic reference cache skeleton	`RL/relax-hypereyes/examples/HyperEyes/HyperEyes_reward_V1_2_w_dynamic_w_OPD_v0.py`	`BaselineCache`, `_best_rollout_baseline` (present but not active on the current reward path)
RL launch config	`RL/relax-hypereyes/examples/HyperEyes/HyperEyes_RL.sh`	GRPO / rollout / SGLang / Megatron / OPD arguments
Agent runtime config	`RL/relax-hypereyes/examples/HyperEyes/agent_config.yaml`	`max_turns: 9`, `rollout_interaction_env_path`
SFT stack	`SFT/ms-swift-hypereyes/`	ms-swift fork; paper-specific SFT launch config not found in current release
Public assets / benchmark preview	`figures/`, `IEMB/IMEB_demo.parquet`	paper figures and IMEB demo parquet; full IMEB benchmark and model weights are marked “will be released soon” in README

4. Experimental Setup (实验设置)

Datasets and scale

训练数据总表：LiveVQA 100k QA pairs（13.5k SFT / 3k 30B RL / 5k 235B RL）、REDSearch 10k（2k / 0.5k / 0.5k）、InfoSeek 41k（3k / — / —）、iNaturalist 75k（2.5k / 2k / 3k）、Google-Landmark 12k（1k / — / —）、DeepDive 3k（1.5k / — / —）、Internal Human Annotations 5k（0.5k / — / —）、Visual Multi-Entity 20k（5k / 0.5k / 0.5k）、Textual Multi-Constraint 5k（1k / — / —）。总计 271k QA pairs、30k SFT trajectories、约 6k 30B RL samples、约 9k 235B RL samples。IMEB benchmark 另含 300 个人工验证 multi-entity visual instances，平均每图 4.6 个实体。

Baselines

论文比较三组 baseline：原生 backbone Qwen3-VL-30B-A3B-Instruct、Qwen3-VL-235B-A22B-Instruct；开源 multimodal search agents DeepEyes-V2、MMSearch-R1、WebWatcher、VDR、REDSearch；闭源/商业模型 Kimi-K2.5、Claude-Opus-4.6、Gemini-3.1-Pro。结果表区分 Direct Answer 与 Agentic Workflow，因为 direct answer 测的是 parametric knowledge，agentic workflow 才暴露工具调用效率。

Metrics

Accuracy (Acc)：由 LLM-as-a-judge 对预测答案与 ground truth 进行判定。
Average Tool-Call Turns (Turns)：产生 tool-call block 的 decoder forward passes 数量，反映 serial interaction depth。
CAS： $Acc^{2} \times 100/ (N_{tok} + 2 N_{tool} + 1)$ ，用于把 accuracy、token cost、tool-call rounds 放到一个 cost-aware 轴上。

Training config

论文实现基于两个 backbone：Qwen3-VL-30B-A3B-Instruct 与 Qwen3-VL-235B-A22B-Instruct。所有训练运行在 8 nodes × 8 NVIDIA H20 141GB GPUs；SFT 使用 ms-swift LoRA fine-tuning，RL 使用 Relax + Megatron-LM + SGLang。RL released script RL/relax-hypereyes/examples/HyperEyes/HyperEyes_RL.sh 的关键配置为：literal flags --lr 1e-6、--rollout-batch-size 32、--n-samples-per-prompt 8，并通过环境变量 MAX_TOOL_CALLS_NUM=8、MAX_ITERATIONS=9 控制工具调用预算；优化器为 Adam $β_{1} = 0.9, β_{2} = 0.98$ 、weight decay 0.1、constant LR schedule、rollout batch size 32、group size $N = 8$ 、global batch size 256、rollout temperature/top- $p = 0.8/0.95$ 、eval top- $p = 0.7$ 、max prompt length 15,000、max response length 1,524、每图最多 1,200 visual tokens、每 rollout 最多 50 images、max tool calls / max turns = 8 / 9、retrieval concurrency 64。Megatron 参数包括 tensor model parallel size 4、pipeline model parallel size TOTAL_GPUS/8、expert model parallel size 8、context parallel size 1；SGLang 每 engine 4 GPUs、max running requests 64。OPD 只用于 30B RL，teacher 为 HyperEyes-235B (RL)，KL coef 0.05，teacher connector limit 32，timeout 500s。

5. Experimental Results (实验结果)

Main benchmark results

Model	MMSearch	FVQA	LiveVQA	BCVL	MMSearch+	IMEB	Avg.
DeepEyes-V2	63.7 / 2.1	60.6 / 2.8	58.0 / 3.7	24.8 / 4.3	9.5 / 3.9	18.0 / 4.7	39.1 / 3.6
MMSearch-R1	53.8 / 1.4	58.4 / 1.3	48.4 / 1.4	19.1 / 1.7	10.1 / 1.8	3.3 / 1.9	32.2 / 1.6
WebWatcher	55.3 / 4.8	64.3 / 4.0	58.7 / 4.1	27.0 / 4.9	11.5 / 5.7	15.3 / 7.8	38.7 / 5.2
VDR	69.6 / 11.1	74.2 / 12.7	77.6 / 10.2	53.7 / 11.7	28.5 / 11.4	21.2 / 12.3	54.1 / 11.6
REDSearch	72.9 / —	— / —	79.3 / —	57.2 / —	26.6 / —	— / —	— / —
HE-30B (SFT)	82.0 / 1.8	76.1 / 2.0	80.3 / 1.9	47.6 / 3.9	25.0 / 3.7	42.0 / 3.8	58.8 / 2.9
HE-30B (RL)	86.9 / 1.6	79.3 / 1.7	81.6 / 1.7	57.9 / 2.6	31.5 / 2.3	46.7 / 3.1	64.0 / 2.2
HE-235B (SFT)	84.4 / 1.7	80.3 / 1.9	83.7 / 2.1	54.4 / 3.7	31.8 / 3.9	50.0 / 3.3	64.1 / 2.8
HE-235B (RL)	88.5 / 1.4	81.4 / 1.5	84.1 / 1.5	60.0 / 2.2	32.6 / 2.2	52.7 / 3.0	66.6 / 2.0

表中每个 cell 是 Accuracy % / Avg. Tool-Call Turns。HE-30B (RL) 相对 comparable open-source agent 的平均提升为 +9.9 accuracy points，同时 average turns 减少 9.4；HE-235B (RL) 平均 accuracy 达 66.6，接近 Gemini-3.1-Pro 的 67.7，但 average turns 只有 2.0，而 Gemini-3.1-Pro agentic workflow 为 1.8。闭源 Kimi-K2.5 在 IMEB accuracy 上最高（55.3），但 turns 为 8.8，说明高 accuracy 可能来自高交互成本。

Cost-aware results

Method	BCVL Tok(k)	BCVL Tool	BCVL Acc	BCVL CAS	IMEB Tok(k)	IMEB Tool	IMEB Acc	IMEB CAS
MMSearch-R1	2.6	1.71	19.1	0.520	3.4	1.90	3.3	0.013
DeepEyes-V2	24.2	4.30	24.8	0.182	16.7	4.71	18.0	0.119
WebWatcher	27.4	4.87	27.0	0.191	22.8	7.82	15.3	0.059
VDR	200.8	11.72	53.7	0.128	303.4	12.34	21.2	0.014
HyperEyes-30B	8.8	2.61	57.9	2.232	16.7	3.13	46.7	0.910

CAS 表显示 HyperEyes-30B 在 BCVL 上以 2.232 CAS 超过第二名 MMSearch-R1 的 0.520，约 4.3×；在 IMEB 上以 0.910 超过第二名 DeepEyes-V2 的 0.119，约 7.6×。这说明 HyperEyes 的优势不是简单“搜索更多得到更高 accuracy”，而是每单位 token/tool 成本的信息密度更高。

Ablation findings

数据过滤 ablation： $D_{Base}$ 使用 121k trajectories，平均 51.6 / 2.2；严格 trajectory-level filtering 后只保留 30k，平均反而提升到 58.8 / 2.9，提升 +7.2 accuracy points。说明 PRS + quality filtering 比 raw trajectory volume 更关键。

Dual-Grained RL ablation（Avg. Accuracy / Turns）：Qwen3-VL-30B agentic baseline 为 36.4 / 2.7；直接在 vanilla 30B 上加 TRACE+OPD 只有 44.7 / 2.2，说明无 SFT cold-start 会限制 RL；Qwen3-VL-30B+SFT 为 58.8 / 2.9；只加 outcome reward 得 58.3 / 6.9，准确率未升且工具调用膨胀；TRACE without dynamic update 为 61.1 / 2.5；TRACE 为 62.7 / 2.2；TRACE+OPD with off-the-shelf Qwen3-VL-235B teacher 掉到 46.3 / 2.8；TRACE+OPD with RL-aligned HyperEyes-235B teacher 达 64.0 / 2.2。这里最重要的结论是：OPD 不是“任意大 teacher 都有效”，teacher 必须 efficiency-aligned，否则会把 student 拉回非并行/低效推理模式。

Robustness and further analysis

Appendix 的 seed robustness 对 HE-30B (RL) 做 $N = 3$ independent RL runs（seeds 42、1234、2026）：平均 accuracy 为 $63.9 \pm 0.19$ ，average turns 为 $2.18 \pm 0.02$ ；单 benchmark accuracy std 最大为 MMSearch 的 1.22。Tool-call budget 分析显示，盲目增加工具调用不总是提高 accuracy：在 235B 上，FVQA 从 1 call 的 75.9/1.00 到 4 calls 的 76.5/2.89，再到 6 calls 的 74.9/3.40；BCVL 从 31.3/1.24 到 36.1/2.29/2.83 后也不再稳定提升。这个结果支持 TRACE 的设计：效率 reward 不是为了省成本而牺牲 accuracy，而是为了避免过检索造成证据噪声。

Limitations

作者明确列出三点限制：第一，OPD 需要更强且同 family 的 teacher，student 能力上限受 teacher 约束，frontier scale 上不一定直接适用；第二，当前框架只覆盖静态 image/text 环境，不包含 video/audio 这类需要 spatio-temporal grounding 的动态模态；第三，与 Gemini-3.1-Pro 等 closed-source frontier model 仍有残余 performance gap。released repo 的 README 还显示 full IMEB benchmark、Parallel-Amenable Data Synthesis pipeline、HyperEyes-30B/235B model weights、inference/demo scripts 仍在 roadmap 中，因此当前可复现实验主要集中在已发布的 SFT/RL code path 与 paper figures/IMEB demo。

Paper Notes

探索

HyperEyes: Dual-Grained Efficiency-Aware Reinforcement Learning for Parallel Multimodal Search Agents

HyperEyes: Dual-Grained Efficiency-Aware Reinforcement Learning for Parallel Multimodal Search Agents

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 Overall framework：UGS + 数据合成 + 双粒度 RL

3.2 Formulation and Unified Grounded Search

3.3 Parallel-Amenable Data Synthesis and SFT trajectory curation

3.4 TRACE：trajectory-level efficiency reward

3.5 OPD：failed-rollout token-level correction

3.6 IMEB benchmark and Cost-Aware Score

4. Experimental Setup (实验设置)

Datasets and scale

Baselines

Metrics

Training config

5. Experimental Results (实验结果)

Main benchmark results

Cost-aware results

Ablation findings

Robustness and further analysis

Limitations

目录