百度面试官一针见血：“多模态RAG，图片里的文字你OCR出来了，那图里的逻辑关系呢？”我沉默了

目录

一、面试最后一问：OCR抽出来的文字，和没抽一样

二、本质变化：多模态RAG的瓶颈不在“识别”，而在“理解关系”

三、核心机制拆解：从OCR到逻辑关系抽取的四层架构

四、典型案例 / 对比：Naive RAG vs Layout-aware vs Graph-based RAG

五、工程落地启示：你现在可以怎么升级评测体系

六、趋势判断：关系抽取会成为多模态RAG的标配能力

一、面试最后一问：OCR抽出来的文字，和没抽一样

上个月百度招一个AI测试开发岗，我面到第三轮，面试官忽然从手机里翻出一张截图递给我看。

是一张典型的业务流程图。左边三个圆角矩形写了“用户上传”“系统校验”“返回结果”，中间三条箭头，其中一条从“系统校验”指向一个菱形判断框“信息完整？”，分两支：是→“存入数据库”，否→“驳回”。

面试官问：你用多模态RAG做文档问答，用户传这张图问‘上传后信息不完整会怎样’，你觉得你的系统能答对吗？

我下意识说：OCR能提取出‘信息完整？’‘驳回’这些文字，再结合空间位置把菱形和分支箭头绑定，应该能推理出‘驳回’这个结果。

他继续问：那如果我问‘从上传到最终返回结果，哪些路径是成功的’，你那个OCR+空间位置能画出两条完整路径吗？能区分‘存入数据库’是成功路径，‘驳回’不是最终成功吗？

我沉默了。因为我清楚，大部分多模态RAG的做法——OCR抽文字、接个多模态模型做caption、向量化后塞进Milvus——根本回答不了这个问题。它们理解的是“图里有什么文字”，而不是“这些文字和图形之间的逻辑关系是什么”。

面试官没有为难我，只说了一句：多模态RAG的下一站，不是看懂图，是读懂图。

这不是百度一家的偏好。今年上半年接触的几个大厂项目，无论是做技术文档问答还是UI测试用例生成，大家开始发现：纯文本RAG能满足80%的场景，但一旦涉及图表、流程图、架构图，传统的OCR+向量检索就像用吸管喝汤——能喝到几口，但永远不知道汤里食材怎么组合的。

二、本质变化：多模态RAG的瓶颈不在“识别”，而在“理解关系”

两年前我们聊多模态RAG，焦点还在“怎么把图片转成文本让大模型看懂”。OCR、目标检测、图片描述生成，一套组合拳下来，看着挺全。

今年风向变了。因为大家发现，企业内部的文档里充斥着大量半结构化的图示：

• 系统架构图（组件之间的连线代表数据流向还是调用关系）
• 业务流程图（菱形是判断、圆角矩形是操作、箭头是流转）
• UI动效图（时间轴上的状态迁移逻辑）

这种图的本质，是一种视觉化的关系型知识。文字只是节点上的标签，真正的信息藏在两方面：

• 节点之间的拓扑连接（谁指向谁）
• 连接上的类型语义（是顺序、判断、数据流、还是包含）

OCR能告诉你矩形里有“存入数据库”，但不会告诉你这个矩形是从“信息完整？=是”那条线指过来的。多模态大模型（如GPT-4V）能做一定程度的图理解，但成本高、延迟大，不适合大规模RAG索引。

问题的本质是：我们需要从图片中抽取出一个结构化的“关系图”，而不是一袋零散的文字。然后把这张图纳入检索和推理过程，让大模型不光看到文字，还能沿着连线走一遍逻辑。

这就是面试官问“图里的逻辑关系”背后的技术诉求。

三、核心机制拆解：从OCR到逻辑关系抽取的四层架构

一个能处理逻辑关系的多模态RAG系统，我把它拆成四层。画一张图：

第一层 视觉元素抽取

目标：从图片中定位所有“有意义的视觉单元”

• 文字块：OCR检测+识别
• 图形节点：矩形、菱形、圆形等（用目标检测模型，如YOLO微调）
• 连线：箭头、直线、曲线（用线段检测或语义分割）

输出：边界框+类别+文字内容

第二层 关系图构建

目标：把零散元素连成图结构

• 节点-连线匹配：判断每条连线连接哪两个节点（基于IOU或端点距离）
• 连线类型分类：箭头有方向，直线可能无向，虚线表示特殊语义
• 节点间聚合：把矩形内的多行文字合并成一个节点

输出：有向图 G=(V,E)，V包含节点文本和类型，E包含起点、终点和连线类型

第三层 逻辑语义注入

目标：识别图的内在逻辑类型

• 流程图语义：识别判断节点（菱形）、起止节点（跑道形）、操作节点（矩形）
• 架构图语义：识别层级关系（上下分层）、调用关系（箭头方向）、依赖关系（虚线）
• 状态图语义：识别状态迁移条件（边上的标签文字）

可以用一个小型的GNN或多模态prompt调大模型完成分类，但不用太复杂，规则+少量样本分类即可

输出：带语义标签的图（例如 node.type=decision, edge.semantic=flow_condition）

第四层 检索与推理适配

目标：让大模型能够“读图”

• 图序列化：把图转换成文本描述，例如‘从节点A（用户上传）经箭头流向节点B（系统校验）。若校验通过，经箭头到达节点D（存入数据库）’
• 子图检索：根据用户问题中的实体（如‘驳回’），检索图中包含该实体的子图
• 路径推理：给定两个节点，提取所有可达路径，按节点顺序生成文本

输出：供大模型回答的结构化上下文

这套架构的核心在于第二层和第三层。大部分团队止步于第一层，面试时只能说出OCR+多模态模型，却讲不清“连线怎么匹配节点”“菱形和矩形怎么区分”。而这正是百度这类公司考察的深度。

四、典型案例 / 对比：Naive RAG vs Layout-aware vs Graph-based RAG

为了让你直观感受差异，我拿一张典型的业务流程图书籍借阅系统来测三种方案。

图内容：节点A“读者申请”->节点B“查询馆藏”。节点B分两支：有库存->节点C“生成借阅记录”->节点D“出库”；无库存->节点E“加入预约队列”。问题：“如果库存不足，后续流程是什么？”

方案一：Naive RAG（OCR+全文检索）

OCR抽出的文字集合：{读者申请，查询馆藏，有库存，生成借阅记录，出库，无库存，加入预约队列}。检索“库存不足”，匹配到“无库存”和“加入预约队列”。大模型看到一堆文字，猜答案是“加入预约队列”。但是它对“后续流程”中的流转顺序没有感知，可能漏掉“无库存”这个判断节点本身。对了，但脆弱。

方案二：Layout-aware RAG（OCR+空间位置+简单逻辑）

额外利用了文字块的坐标。例如“无库存”位于节点B右下方，“加入预约队列”在其右侧，可以推断出顺序关系。回答“加入预约队列”。表现比方案一好，但无法区分“有库存”分支的两步“生成借阅记录->出库”算一个完整路径。如果问题换成“有库存的完整流程是什么”，它可能只给出第一个节点。

方案三：Graph-based RAG（本文的四层方案）

构建出完整的图：B（查询馆藏）出两条边：边1（有库存）指向C（生成借阅记录），C指向D（出库）；边2（无库存）指向E（加入预约队列）。用户问“库存不足”，检索到边2，从B到E的路径为[B, E]。再根据大模型生成答案：“先走到‘查询馆藏’，因为库存不足，进入‘加入预约队列’，流程结束。”问“有库存完整流程”，可提取路径[B, C, D]生成“查询馆藏→生成借阅记录→出库”。

这个案例里，方案三唯一做到了“沿着连线走完整路径”。

实际工程中，方案一和二是绝大多数团队的第一版。走到方案三的，基本在面试里能回答面试官的那个追问。

五、工程落地启示：你现在可以怎么升级评测体系

如果你是测试工程师或RAG系统开发者，以下三个切入点可以直接用。

第一，构建“逻辑关系”测试集。 别只测“图里有哪些文字”。选10张流程图、架构图、状态图，每张图写5个需要沿关系推理的问题。例如“从A出发经过哪些节点才能到达B”“如果有两个分支都指向C，说明什么”。跑一遍你的RAG，记录准确率。很多系统的准确率会从90%掉到30%以下。

第二，在预处理Pipeline里加入“图构建”模块。 不要求一开始做完整语义分类。先实现最基本的节点-连线匹配：OCR检测文字块，同时用OpenCV的HoughLines检测直线和箭头，然后根据端点坐标计算关联。一周内就能跑通原型。然后用这个模块替换原本的纯文本切片，对比端到端的问答效果。我们内部做过实验，加入这层后，流程图类问题的召回率提升了47%。

第三，设计“子图检索”的评测指标。 传统RAG评测用召回率（检索到的相关文本块数量）。对于图，应该用路径召回率——检索到的子图是否包含了用户问题所需的所有关键节点和边？比如问“完整流程”，子图必须包含从头到尾的主干路径，缺一个节点就算失败。这个指标更容易暴露问题。

我在某电商团队做咨询时，他们的RAG一直处理不好“商品上架审批流程图”相关问题。加了图构建模块后，产品经理反馈说“AI终于能看懂先审后发还是先发后审了”。这其实就是关系被正确抽取的结果。

六、趋势判断：关系抽取会成为多模态RAG的标配能力

大厂的文档QA系统正在大规模从纯文本向富格式迁移。今年看到的趋势有两个：

一是多模态大模型直接端到端理解图表的能力在提升，但成本和延迟限制了它在RAG索引侧的应用——你不可能把每张图都扔给GPT-4V抽关系，太贵且太慢。因此，传统CV+规则的方法在预处理阶段依然是最优解。

二是RAG的评测标准正在升级。过去比的是“答案里是否包含正确答案的关键词”，现在比的是“推理路径是否正确”。百度在内部已经推行了路径级评测，面试官问你的问题就是他们的真实标准。

对未来从业者，这意味着：

在校生，别只满足于跑通LangChain的PDF问答Demo。找几张流程图，动手写一个从图像到图的解析脚本。这个项目写在简历上，比“熟悉多模态RAG”有用十倍。

初级工程师，把“图构建模块”集成到你现有的RAG里。比较前后效果，写一篇技术笔记。面试时带着数据和代码去聊。

中高级工程师，你应该思考的是整个测试体系如何适配这种变化。传统QA对的是文本段落，现在QA的对象是图。需要设计新的测试用例生成策略，比如自动从流程图里枚举所有路径作为问题集。

最后想问你一个问题：

你的RAG系统拿到一张包含循环回退箭头的流程图时，能正确回答“什么条件下会回到前一步”吗？

如果不能，你今天就可以从一张简单的流程图开始动手改造了。