SearchEyes 深度解读

1. 问题与动机

SearchEyes 解决的是多模态 Deep Search/Agentic Search 训练中的结构性断裂：训练数据、搜索环境、奖励信号通常分别构造。已有方法会用图结构生成多跳问题，但生成完 QA 后丢弃中间路径、实体 ID、关系类型等元数据；训练环境又常依赖外部搜索 API，带来不可复现、非确定性和高成本；到 RL 阶段，奖励往往只看最终答案是否正确，长链条一旦任一 hop 出错，整条轨迹都变成失败，credit assignment 极其稀疏。论文把这个问题定义为多模态搜索智能体训练的核心瓶颈，而不是单纯的模型能力不足。

这个动机成立的背景是，Search-R1、ASearcher、REDSearcher 等文本搜索智能体已经证明 RL 能提升长程检索推理；Vision-DeepResearch、OpenSearch-VL、MMSearch-R1、VSearcher 也开始让 MLLM 调用视觉和文本搜索工具。但这些系统依然缺少一个同时服务于数据合成、环境交互和训练奖励的共享结构。SearchEyes 的关键假设是：如果用类型化知识图谱作为统一骨架，就能把多跳问题、可复现环境和 step-level reward anchor 串起来，让搜索智能体学到真实的“逐跳找证据”能力，而不是只学会表面 tool-call 模板。

2. 方法详解

SearchEyes 的整体框架由三部分组成：Perception-Knowledge Chain（PKC）合成、自包含搜索世界、Hop-Anchored Policy Optimization（HaPO）。输入是图像和自然语言问题，智能体以 ReAct 形式循环产生 thought 和 action；动作可以是结构化工具调用，也可以是最终答案。状态是截至当前 turn 的完整交互历史，reward 初始仍是最终答案是否正确，但训练时会借助 PKC 保留下来的金实体序列，把最终奖励拆到中间检索 hop 上。

知识图谱来自 Wikidata5M、Wiki6M/OVEN 和 Wikipedia images 的交集。Wikidata5M 提供 4.6M 实体、822 种关系和 20.6M triples；Wiki6M/OVEN 提供 6.06M 实体描述和 2.03M canonical images。经过交集、hub exclusion 和 predicate blacklist 过滤后，最终图包含 1.2M 实体，其中 340K 是通过质量过滤的 visual entities，边为 5.8M relation triples。每个保留实体同时有结构关系、文本描述和视觉表示，这让同一个图可以承担训练数据源和检索环境。

搜索环境是确定性的。每个实体对应 Wiki6M 摘要和文档，文本检索由 dense retrieval 与 BM25 sparse retrieval 组成，再用 Reciprocal Rank Fusion 融合；视觉检索通过指定图像区域裁剪，计算 image embedding 后从预计算视觉实体 embedding 中取相似项。Agent 暴露五个工具：text_search、visual_search、lookup、summarize 和 python_interpreter。核心点是，每个 document 都和 Wikidata QID 一一对应，环境能记录每次工具调用到底访问了哪个实体，这正好可以和 PKC 的 gold entity sequence 对齐。

PKC 合成先从图上做 constrained random walk。约束包括：第一，P-K alternation，路径必须在视觉感知 hop 和知识检索 hop 之间交替，且至少包含两个 P-hop；第二，treewidth2 disambiguating constraint，至少一个关系要有多个 sibling target，并附加约束边，迫使模型不能只沿主链走；第三，semantic domain diversity，避免单一领域链条；第四，anti-shortcut filtering，排除高 hub、元谓词、重复 anchor-answer 等简单路径。随后用 LLM 生成自然语言问题，但隐藏实体名、别名、完整谓词序列和约束实体精确名称，防止模型靠字符串匹配跳过推理。

SFT 轨迹合成时，作者使用三个 privileged mechanisms 提高专家轨迹成功率：retrieval boost 抬高 gold entity 的检索分数；observation denoising 用 GPT-4o-mini 从冗长检索结果中抽取 query 相关事实；rejection sampling 只接受最终答案匹配 gold answer 的轨迹。导出给学生模型时，会把 denoised observation 换回原始 observation，使学生在真实噪声环境中学习。最终 SFT 数据为 30K expert trajectories，大约每个问题三条；SFT 基于 Qwen3.5-9B 全参数训练 3 epoch，观测 token 只作为上下文，不计入 loss。

HaPO 在 GRPO 上改造。标准 GRPO 把同一个 trajectory-level advantage 分配给整条轨迹的所有 token，无法区分哪个 hop 贡献了成功。HaPO 的做法是：如果某条轨迹在某一步检索到了 gold entity，就认为它到达了一个语义锚点；所有首次检索到同一 gold entity 的 trajectory-step pair 组成 hop anchor group，在这个 group 内根据最终 outcome 计算 group-relative advantage，并把该 advantage 分配给该 anchor step 及之后 token。多个 anchor 重叠时用最近的 anchor，因为它的归因更精确。最终 per-token advantage 是 hop-anchored signal 和 trajectory-level signal 的插值。除此之外，HaPO 还加入 fatal-aware masking：连续工具错误产生的 degenerate suffix 不参与训练，valid prefix 做 one-sided clamping，只保留正向信号，避免外部工具故障污染前面正确决策。

3. 核心技术贡献

第一，SearchEyes 把知识图谱从“问题生成材料”升级为统一的 search world simulation。已有多跳 QA 合成通常只留下 question-answer pair，导致训练时不知道每一步应该到达哪个中间实体。SearchEyes 保留 QID、关系类型、P/K hop 类型和约束边，使数据、环境和奖励都共享同一结构。这解释了为什么它能做 step-level credit assignment，而不需要另外训练 process reward model。

第二，PKC 的约束设计直接针对多模态搜索的失败模式。P-K alternation 迫使模型在视觉识别和文本检索之间切换；treewidth2 constraint 制造需要独立验证的歧义；information concealment 防止实体名泄漏；anti-shortcut filtering 避免单跳或高频实体捷径。消融显示，完整 PKC 在四项基准平均 61.8；去掉 anti-shortcut filtering 降到 54.1，去掉 P-K alternation 降到 57.6，GPT-4o free-form synthesis 只有 49.2。这说明结构化数据质量比单纯让强模型自由生成问题更关键。

第三，HaPO 把长程搜索中的 sparse outcome reward 变成 hop-aware credit。它没有要求人工标注每一步好坏，而是重用 PKC gold entity anchors：只要轨迹先检索到某个中间实体，就能在该 anchor group 内比较后续动作。消融中，Full HaPO 平均 61.8，比 Standard GRPO 的 57.8 高 4.0；去掉 hop-anchored advantage 后只剩 59.1，是最大单项退化。这说明多跳搜索训练的核心瓶颈确实在逐步归因，而不是泛泛替换 RL 算法。

第四，论文给出可复现的多模态搜索评估闭环。它不仅在六个公开 benchmark 上测试，还构造 VisSearch Bench：1000 个问题、935 个 Wikipedia entity images、最少 4 hop、至少 2 个 perception hop，并保留推理链和约束实体。这个 benchmark 能检查模型是否真正学会 P-K 交替，而不是靠单轮常识或参数知识答题。

4. 实验结果分析

主实验覆盖 SimpleVQA、VDR、MMSearch、LiveVQA、BrowseComp-VL 和 FVQA。SearchEyes-27B 在六项平均 68.1，比最强开源 OpenSearch-VL-32B 的 61.9 高 6.2 分；SearchEyes-9B 平均 59.3，接近或超过许多 30B 级开源搜索模型。直接推理模式表现明显不足：GPT-5 平均 42.3，Gemini-2.5-Pro 平均 45.8；Qwen3.5-9B 只加普通 agentic workflow 为 44.7，而 SearchEyes-9B 到 59.3，说明工具访问本身不能替代专门的搜索训练。

结果里最值得注意的是 MMSearch 和 VDR。MMSearch 上 SearchEyes-27B 得 82.4，接近 Gemini-3.1-Pro 的 86.1，并明显高于 OpenSearch-VL-32B 的 72.3；VDR 上 39.4 也高于 OpenSearch-VL-32B 的 33.8。它说明 SearchEyes 的收益集中在需要多跳信息搜集和视觉-文本切换的任务，而不是普通视觉问答。

PKC 消融表明，数据结构约束贡献很大。Full PKC 平均 61.8；无 P-K alternation 为 57.6，说明如果问题退化成单模态链，模型学不到多模态切换。无 anti-shortcut filtering 只有 54.1，是最大下降之一，尤其 VDR 从 28.3 降到 20.8，说明捷径样本会严重伤害多跳推理。无 retrieval boost 为 57.1，表明 SFT 阶段需要适当提升 gold evidence 可见性，否则专家轨迹太难采样或样本被简单 case 主导。与 GPT-4o free-form synthesis 的 49.2、Wikipedia path sampling 的 53.5 相比，图约束合成明显更强。

HaPO 消融也很清楚。Full HaPO 平均 61.8；Standard GRPO 57.8，GiGPO 58.5，DAPO 58.1，说明通用 RL 改进不够解决多跳搜索归因。去掉 hop-anchored advantage 后为 59.1，下降 2.7；使用 hop-only 固定信号为 61.1，优于 ep-only 的 59.0，但仍低于插值版本，说明最终答案级奖励仍有补充价值。fatal-aware masking、one-sided clamping、smooth asymmetric gating 分别贡献 1.9、1.1、1.3 左右的平均点，主要是在长轨迹工具错误场景中降低噪声。

VisSearch Bench 是对 compositional search 的更尖锐验证。SearchEyes-27B 得 24.3，SearchEyes-9B 得 18.6；OpenSearch-VL-32B 只有 9.4，GPT-5 5.4，Kimi-K2.5 7.2。绝对分数不高，说明这个 benchmark 难度很大，但相对差距说明 P-K 交替和 hop anchor 训练确实迁移到了 held-out 多跳视觉搜索。论文的 case study 也展示了 4-hop 轨迹：先用 visual_search 识别 Guggenheim Museum Bilbao，再 lookup architect，接着用背景视觉检索确认 Bilbao，最后 text_search 查 Frank Gehry 的 Pritzker Architecture Prize。这个例子中第二个 P-hop 是为排除 New York 分馆这个 distractor，不是形式化的工具调用。

5. 局限与未来方向

论文没有单独的 limitations section，但从方法和实验可以读出几个作者实际上承认的边界。第一，训练环境依赖 Wikidata5M、Wiki6M/OVEN 和 Wikipedia images 的交集，最终虽然有 1.2M 实体和 340K visual entities，但覆盖域仍偏百科式实体；对电商、社区帖子、短视频、实时新闻这样的开放 UGC 内容，需要重新构造实体图、视觉锚点和关系类型。第二，外部 benchmark 评估仍使用 Serper web search API 和 image-based web search service，虽然训练世界是确定性的，但真实评估并非完全可复现。

第三，成本不低。SFT 用 8 张 H20 全参数训练 3 epoch，RL 用 64 张 H20 训练 200 steps；轨迹合成还依赖 GPT-4o 和 GPT-4o-mini 做问题生成、denoising 和 rejection sampling。对中小团队来说，这更像是后训练 recipe 和数据构造方案，而不是可以当天上线的轻量方法。第四，评估使用 GPT-4o judge 判断答案正确性，对复杂多模态问答可能带入 judge bias；VisSearch Bench 用 EM 能补充这一点，但公开 benchmark 的整体准确率仍部分依赖 LLM judge。

未来方向可以沿三条线推进：一是把 PKC 从百科图扩展到业务知识图，例如商品、帖子、用户、地点、话题和行为事件；二是降低合成和 RL 成本，例如用较小 generator、离线 verifier 或真实日志失败轨迹替代部分 GPT-4o 合成；三是把 step-level anchors 从 gold entity 扩展到更一般的 evidence unit，例如文档块、商品属性、query rewrite、用户画像字段，让文本搜索和推荐 Agent 也能使用类似 HaPO 的逐步归因。

6. 工业实践意义

对搜索/推荐团队，SearchEyes 最重要的实践启示是：Agentic Search 的训练环境必须可控、可复现、可归因。很多线上 Deep Search 原型直接调用搜索引擎，把最终答案作为奖励，这会导致训练成本高、失败难复盘、模型难以知道哪一步检索错了。SearchEyes 的做法是先构建一个可模拟的搜索世界，让每次检索都能落到可验证实体或证据节点；这对 UGC 搜索可以变成“帖子/用户/话题/事件图 + BM25/向量混合检索 + 点击/收藏/评论证据锚点”。

在短文本社区搜索中，PKC 的 P-K 交替可以改写为“query intent hop - content evidence hop - user/context hop - constraint verification hop”。例如用户搜“上周那个吐槽某品牌售后的帖子后续”，系统需要先识别时间和品牌，再找原帖，再验证后续评论或作者更新。传统 dense retrieval 可能一次召回相似帖子，但很难保证多跳链完整；如果训练数据保留每个中间证据节点，就可以像 HaPO 一样奖励模型先找到原帖、再找到后续、最后给出答案。

HaPO 对线上优化也有启发。现在很多搜推系统只看最终点击、停留或人工标注答案是否正确，导致多步 agent 的中间 query rewrite、检索、过滤、阅读都共享一个粗粒度 reward。可以借鉴 hop anchor group：把成功 session 中的关键证据文档、query rewrite、用户画像字段或商品属性作为 anchor；对到达同一 anchor 的不同轨迹比较最终 outcome，从而学习哪些后续动作更有效。这样比简单把整条轨迹打正负标签更稳定，也更便于定位失败。

部署上需要谨慎。SearchEyes-27B 需要多工具、多 turn、最多 50 turn 的 ReAct loop，不适合直接放在低延迟主搜索链路；更适合用于高价值复杂查询、Deep Search 产品、离线标注/质检、搜索结果页的“深入研究”入口。主链路可以先吸收它的数据思想：构建可复现的任务模拟器和带 anchor 的训练集；在线只部署轻量策略，比如对少数复杂 query 触发 agentic retrieval，对普通 query 继续使用多阶段召回排序。

需要避免的做法是只给现有大模型加 search tool 就上线。论文中 Qwen3.5-9B Agentic 平均 44.7，而 SearchEyes-9B 59.3；Qwen3-VL-30B agent prompting 在 MMSearch 只有 44.2，远低于专门训练后的 SearchEyes-27B 82.4。工具可用性不是能力本身，真正的增益来自结构化任务、可复现环境、逐步奖励和针对失败模式的数据构造。