多模态RAG把检索变成图搜索 多跳推理稳了

多模态检索增强生成有个老问题：单跳问题（"这张图里有什么"）检索一次就够了，一旦问题需要多跳推理（"这张图对应的论文里，作者还引用了哪些相关工作的方法"），每一步都做独立检索，噪声会逐跳累积。传统方案把一堆文档切片直接喂给生成模型，让它自己在碎片里找关系，效果通常不太稳定。

做过多模态问答的人对这种情况应该不陌生：问题本身跨了图和文本两种模态，图片里是一个实验结果，对应的论文正文里有实验设置，相关工作部分又有方法对比。模型需要把三段信息串起来才能回答，而每一段检索都可能带回不相关的素材。检索阶段多带一点噪声，生成阶段就多一分跑偏的可能。

DualG-MRAG 的应对方式是把检索从"实例匹配"改成"图上推理"。

两张图各管一段

论文构造了两张图：宏观图负责全局拓扑路由，决定证据的整体走向；微观图负责局部证据验证，确认每个细节是否站得住。检索过程变成 GNN 上的查询驱动消息传递，证据相关性在文本、图片这些异构模态之间动态传播。

这个设计的意图很清楚：宏观推理和微观匹配的职责不同，混在一起容易互相干扰——全局路由的错误会带偏局部验证，局部噪声又会污染全局判断。分开之后，各自只处理自己擅长的那一段。

变化最大的是解码端

对检索系统工程师来说，这篇文章里最有意思的变化在解码端。论文提出动态规划解码机制，直接从 GNN 的前向传播中提取显式推理路径，替代了传统"孤立文档切片"作为生成模型的输入。

也就是说，喂给生成模型的不再是一堆碎片，而是一条带结构的推理路径。模型不需要自己在片段之间搭桥，路径是现成的。如果这个机制成立，检索管线从"向量相似度 Top-K"变成"构图 + 图上传播 + 路径提取"，是一次不小的架构变化。

落地前需要验证的事

代价也是公开的。图结构会随证据数量膨胀，GNN 上的消息传递和动态规划解码都可能引入额外延迟。论文没有给出这两项的开销数据，资源受限环境下的表现也是空白。多模态场景里跨模态边的构建成本，同样没有展开。

对想评估这套方案的团队，有两个点值得先验证。一个是图的构建和更新：证据库是动态的，新文档进来要重新构图，还是增量挂边，这直接决定运维复杂度和存储成本。另一个是路径提取的可解释性：动态规划解码给出的推理路径，能不能被审查、被追溯，多模态场景下路径节点跨了图和文本，出问题时定位成本有多高。这两点论文都没说。

从方向上看，检索结果从"一组相关文档"变成"一条推理路径"，可能是 RAG 从"查资料"走向"做推理"的一个中间形态，这个变化值得关注。但工程上能不能落地，取决于图规模上去之后，消息传递和解码的延迟能不能扛住线上查询。在论文补齐这些数据之前，把它接入生产检索系统需要谨慎——尤其是多跳问答这类对延迟敏感的场景，路径提取省下的拼接功夫，可能被图计算的成本吃掉。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。

官网：framewiki.com

Gitee：gitee.com/wiki-framework

GitHub：github.com/wiki-framework

示例项目：gitee.com/cdkjframework/framewiki-example

📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）