目录一、面试最后一问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.typedecision, edge.semanticflow_condition第四层 检索与推理适配目标让大模型能够“读图”图序列化把图转换成文本描述例如‘从节点A用户上传经箭头流向节点B系统校验。若校验通过经箭头到达节点D存入数据库’子图检索根据用户问题中的实体如‘驳回’检索图中包含该实体的子图路径推理给定两个节点提取所有可达路径按节点顺序生成文本输出供大模型回答的结构化上下文这套架构的核心在于第二层和第三层。大部分团队止步于第一层面试时只能说出OCR多模态模型却讲不清“连线怎么匹配节点”“菱形和矩形怎么区分”。而这正是百度这类公司考察的深度。四、典型案例 / 对比Naive RAG vs Layout-aware vs Graph-based RAG为了让你直观感受差异我拿一张典型的业务流程图书籍借阅系统来测三种方案。图内容节点A“读者申请”-节点B“查询馆藏”。节点B分两支有库存-节点C“生成借阅记录”-节点D“出库”无库存-节点E“加入预约队列”。问题“如果库存不足后续流程是什么”方案一Naive RAGOCR全文检索OCR抽出的文字集合{读者申请查询馆藏有库存生成借阅记录出库无库存加入预约队列}。检索“库存不足”匹配到“无库存”和“加入预约队列”。大模型看到一堆文字猜答案是“加入预约队列”。但是它对“后续流程”中的流转顺序没有感知可能漏掉“无库存”这个判断节点本身。对了但脆弱。方案二Layout-aware RAGOCR空间位置简单逻辑额外利用了文字块的坐标。例如“无库存”位于节点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系统拿到一张包含循环回退箭头的流程图时能正确回答“什么条件下会回到前一步”吗如果不能你今天就可以从一张简单的流程图开始动手改造了。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。