✨导读：多页文档问答最怕两件事：图表、标题、正文被切成孤立 chunk，检索又在长上下文里反复跑偏。上海交通大学等提出 G²-Reader，把文档先构造成可演化的 Content Graph，再用 Planning Graph 维护子问题和证据缺口。在 VisDoMBench 五类多模态文档 QA 上，G²-Reader 搭配开源 Qwen3-VL-32B-Instruct 达到 66.21% 平均准确率，超过单独 GPT-5 的 53.08%。

• 作者： Yaxin Du, Junru Song, Yifan Zhou, Cheng Wang, Jiahao Gu, Zimeng Chen, Menglan Chen, Wen Yao, Yang Yang, Ying Wen, Siheng Chen

• 单位： Shanghai Jiao Tong University；Intelligent Game and Decision Laboratory

• 论文标题： G²-Reader: Dual Evolving Graphs for Multimodal Document QA

• 论文链接： https://arxiv.org/pdf/2601.22055v1

• 发表信息： ICML 2026

• 项目链接： https://icml.cc/virtual/2026/poster/66682

• 代码链接： https://github.com/DorothyDUUU/G2_Reader

为什么普通 RAG 读不好多模态长文档

这篇论文抓住了多模态文档 QA 里两个非常实际的痛点：证据被切碎，检索会跑偏。 标准 RAG 通常把 PDF、网页、论文或幻灯片切成独立文本块，再做向量检索。这个做法在纯文本里已经会丢失上下文，放到多模态文档里更严重：表格可能和 caption 分离，图可能和引用它的正文分离，跨页证据也很容易被切散。

第二个问题来自长上下文检索本身。即使使用迭代检索，系统也可能围着局部证据打转，或者随着噪声累积漂移到无关章节。原因在于很多方法只看当前 snippet，没有一个持久的全局搜索状态来记录“已经找到了什么，还缺什么”。

G²-Reader 的思路是把 RAG 拆成两个图：一个图管文档证据如何表示，另一个图管问题如何一步步被拆解和验证。

图注：原文 Figure 1 展示 G²-Reader 的整体框架。左侧是 offline document indexing 与 online inference 的连接，中间 Planning Graph 负责拆解和更新子问题，右侧 Content Graph 把文本、表格、图片等文档元素组织成结构化证据空间。

Content Graph：先把文档变成可检索的结构

Content Graph 解决的是“证据表示”问题。 G²-Reader 不把文档简单切成扁平 chunk，而是把每个原子信息单元变成节点：可以是段落，也可以是带 caption 的表格、图片、图表等多模态元素。节点保留原始内容，并由 VLM 生成摘要和关键词，再用摘要与关键词形成统一嵌入。

边的初始化也很朴素：先按阅读顺序连接滑动窗口邻居，保证局部连贯性。随后进入图演化阶段。对每个节点，系统会同时看语义相近节点和当前邻居，用 VLM 更新节点摘要、关键词和语义连接，补上隐式引用、解释、比较、因果、图文 grounding 等关系。

这样做的价值在于，检索时拿到的不再是孤立文本片段，而是带邻域的结构化证据子图。论文里 structured subgraph readout 会根据 query 排序节点，并把选中节点及其邻居一起取出，直到达到统一的节点预算 k=5。

图注：原文 Figure 3 可视化了一个 SciGraphQA 样例的 Content Graph。不同颜色表示紧密连接的节点群，文本描述、数学公式和图示被组织在同一个语义邻域里，说明图结构能把跨模态证据重新聚拢起来。

Planning Graph：让检索过程有记忆、有检查、有返工

Planning Graph 解决的是“推理控制”问题。 对输入问题 Q，G²-Reader 先用 decomposer 生成一个有向无环图 DAG，每个节点是一个原子子问题，边表示子问题之间的依赖顺序。

执行时，系统按拓扑序处理子问题。worker 会为每个子问题从 Content Graph 中取出局部证据子图，并生成中间答案；如果子节点已经得到结论，父节点可以把这些中间结论作为额外上下文。随后 evidence checker 判断当前证据是否足够回答原问题。

如果证据不足，decomposer 会基于缺口重新规划：增加新子问题、修改依赖关系，或者删除冗余节点。论文默认最多 refinement tau_max = 3 轮。最后 reasoner 用原始问题和所有经过验证的结构化证据生成答案。

图注：原文 Figure 4 展示 Planning Graph 更新案例。系统先尝试判断 Psalm 151 和 Tobit 的共同点，evidence checker 发现表格里缺少 Psalm 151 的直接证据，于是触发 replanning，新增节点去其他上下文验证其 deuterocanonical status。

VisDoMBench 实测：开源模型加结构，超过单独 GPT-5

实验使用 VisDoMBench，一个多文档、多模态 QA benchmark，共 2,271 个样本，覆盖五个子集：FetaTab、PaperTab、SPIQA、SciGraphQA 和 SlideVQA。每个问题配 5 篇文档，其中包含相关证据和干扰文档。所有检索式方法统一使用 k=5 的节点预算，结果报告三次运行均值。

主结果最醒目的地方是：结构化系统可以补足单模型长文档能力的短板。 单独 GPT-5 平均准确率为 53.08%，Qwen3-VL-32B 直接零样本读多文档只有 29.90%；G²-Reader 使用开源 Qwen3-VL-32B-Instruct 后达到 66.21%，比 GPT-5 高 13.13 个百分点，相比裸 Qwen3-VL-32B 是 121% 相对提升。

对比其他 RAG，G²-Reader 也拿到最高平均分：Deepseek-OCR + RAG 为 62.62%，GraphRAG 为 50.86%，LightRAG 为 63.74%，MMGraphRAG 为 63.40%，VisDoMRAG 为 65.01%，而 G²-Reader 为 66.21%。分项上，G²-Reader 在 SlideVQA 上达到 72.31%，在 FetaTab 上达到 66.89%，在 PaperTab 上达到 57.10%。

表注：原文 Table 1 是全文主结果表。它同时比较 Single-VLM、简单 RAG、文本图 RAG 和多模态 RAG。G²-Reader 的平均准确率最高，但表中也能看到它在 SPIQA 和 SciGraphQA 上仍会落后某些专门系统，说明极细粒度图表问题仍受初始图节点分辨率影响。

消融：双图必须一起用，过度返工反而变差

论文对组件做了拆解。没有多模态、没有 Content Graph、没有 Planning Graph 的基础配置平均只有 54.8%；加入多模态证据后升到 63.2%。在多模态基础上，只加 Planning Graph 到 64.4%，只加 Content Graph 到 63.6%，两者一起达到 68.0%。

这说明两个图不是简单叠加。Content Graph 让证据本身更完整，Planning Graph 让系统知道要找什么、缺什么、何时返工；单独使用其中一个都会受限。

表注：原文 Table 2 展示组件消融。多模态证据带来 +8.4 个百分点，是最大基础增益；Content Graph 和 Planning Graph 单独都有帮助，但组合后达到 68.0%，超过各自孤立收益之和，体现了证据结构和推理结构的互补。

Planning Graph 的 refinement 也不是越多越好。tau_max = 0 时平均 64.8%，增加到 3 轮达到 68.0%；继续到 4 轮反而降到 64.4%。论文认为，过度重规划可能引入冗余或弱 grounding 的子问题，在固定预算下污染证据聚合。

表注：原文 Table 3 比较不同 Planning Graph refinement 轮数。三轮是最佳点，SlideVQA 从 66.0 提升到 74.0，PaperTab 从 52.0 提升到 64.0；但更多轮数会带来噪声。

Content Graph 侧也有类似规律。图演化从 T=0 到 T=3 平均提升 +6.2；关闭 structured subgraph readout 会让平均从 68.0% 降到 66.0%，其中 SlideVQA 从 74.0% 掉到 62.0%，说明邻域证据在跨页幻灯片场景尤其重要。

成本与部署：Lite 版本牺牲 1 分，省下大半开销

G²-Reader 的 VLM 图演化有成本，因此论文专门给了 Lite 版本。 Lite 用规则式更新替代 VLM-based evolution，不再重新生成摘要、关键词和语义关系，只在 embedding 空间中更新邻接关系。

效率表显示，原始 VLM-based Content Graph 构建每文档平均使用 2,174,531 tokens，估算成本 1.22 美元，耗时 233.6 秒；Lite 降到 471,118 tokens、0.32 美元、130.4 秒，分别节省 78.3%、73.7% 和 44.2%。性能上，Lite 在 T=3 时平均 67.0%，只比完整版本 68.0% 低 1.0 个百分点。

表注：原文 Table 5 给出 Content Graph 构建效率对比。这个表很适合说明 G²-Reader 的工程弹性：如果场景对成本或延迟敏感，可以使用 Lite 版本换取接近主模型的准确率。

图注：原文 Figure 2 分析检索预算和模型规模。G²-Reader 在 k=5 时召回率 86.3%，已经超过 Vanilla RAG 在 k=20 时的 86.2%，说明结构化图能用更少检索内容捕获更完整证据。

这篇工作的价值与边界

G²-Reader 的价值在于把“多模态长文档问答”从单纯扩上下文窗口，转向显式知识结构和显式推理状态。对真实业务文档、科研论文、网页、幻灯片和表格密集报告来说，很多答案不是某个 chunk 里的一句话，而是多处证据的组合。双图结构正好对应这个需求。

边界也很清楚。第一，Content Graph 的质量依赖前端多模态解析和节点粒度，复杂图表里的细节问题仍可能受限。第二，完整 VLM-based evolution 成本不低，虽然 Lite 能缓解，但会牺牲部分语义抽象能力。第三，评测使用 LLM-based evaluator，需要在高风险场景中结合人工或规则校验。

总体来看，G²-Reader 给 RAG 提供了一个很实用的方向：别只问“检索哪个 chunk”，还要问“文档证据如何成图，推理过程如何成图”。当这两个图一起演化，开源 VLM 也能在多模态长文档 QA 上追上甚至超过更强的单体模型。