上一篇文章里我们讨论了 RAG 如何处理 PDF、Word、Excel 和网页。一个重要结论是真实知识库不是纯文本文档解析质量会直接影响后续所有环节。但企业知识继续往前走还会遇到一个更复杂的问题知识不只是文字。很多重要信息存在于图片 截图 表格 流程图 架构图 报表截图 产品界面截图 宣传图里的说明文字如果 RAG 只能处理纯文本这些内容就会被忽略。所以这篇文章讨论一个越来越常见的话题多模态 RAG 是什么图片、截图、表格也能不能检索。为什么需要多模态 RAG纯文本 RAG 很适合处理制度 接口文档 会议纪要 技术说明 FAQ但真实业务里很多知识不是这样存在的。比如产品截图里写着按钮说明 错误截图里包含报错码 流程图里说明审批路径 报表图里展示业务趋势 架构图里显示系统依赖这些信息如果不处理用户问相关问题时系统就容易漏答。例如这个页面的按钮在哪里 这个报错截图里的错误码怎么处理 这个流程图里谁是审批人 这个图表里哪个指标异常如果只靠文本检索系统可能根本找不到答案。所以多模态 RAG 的目标就是把图片、截图、表格、图表也变成可检索知识。多模态 RAG 不只是“让模型看图”很多人会把多模态 RAG 理解成把图片直接丢给大模型看。这只解决了一部分问题。真正的多模态 RAG 通常包括两件事第一多模态内容要可检索。第二多模态内容要可引用。也就是说不只是让模型“看懂图”还要让系统能“找到图”。一个更完整的流程可以是图片 / 截图 / 图表 ↓ OCR / 图像理解 / 表格识别 ↓ 提取文本与结构 ↓ 生成多模态索引 ↓ 用户问题 ↓ 文本检索 多模态检索 ↓ Rerank ↓ 生成答案所以多模态 RAG 不是一个模型能力点而是一条工程链路。OCR 是第一步但不是全部图片和截图最基础的处理方式是 OCR。OCR 可以把图片里的文字抽出来。比如错误码、按钮标题、页面提示、截图说明、表格单元格文字但 OCR 只能解决“看见文字”的问题。它解决不了很多结构问题。比如图片里文字和区域的关系 表格的行列结构 流程图的节点关系 截图中的高亮位置所以 OCR 只能算第一层。更进一步还要做图像理解和版面理解。比如识别这是不是页面截图 识别这是不是报表 识别这是不是流程图 识别哪一块是标题 识别哪一块是表格 识别哪一块是备注对于业务截图很多时候用户问的不是整张图而是图里某个局部的信息。所以图像定位和结构识别非常重要。表格为什么适合做多模态处理表格本身既是结构化信息也是视觉信息。如果表格被截图成图片它的结构可能会丢失。这时就需要做表格识别。比如审批额度表 接口字段表 权限对照表 价格对照表 版本差异表这些表格如果只做纯 OCR可能只能拿到文字。但如果能保留表头 行名 列名 单位 合并单元格关系检索质量会好很多。对于很多企业问答表格里的答案比正文更重要。比如这个参数是否必填 这个额度对应哪个审批人 这个版本支持哪些功能表格结构保留得越好答案就越稳。流程图和架构图怎么处理流程图和架构图是多模态 RAG 的另一个重点。用户问这个流程怎么走 这个系统依赖哪些服务 这个方案里有哪些关键节点答案可能就在图里。处理这类图常见做法包括OCR 提取图中文字 图像理解识别节点和关系 把图转成文本描述 把图转成结构化关系例如一个流程图可以被转成申请人 - 主管审批 - 财务复核 - 系统归档一个架构图可以被转成前端 - 网关 - 业务服务 - 数据库这样图像就不只是图而变成了可检索的知识结构。文本检索和多模态检索要结合多模态 RAG 最稳的方式不是只做图像检索也不是只做文本检索。而是两者结合。比如用户问一个错误码 ↓ 先查文本知识库 ↓ 再查错误截图和处理截图 ↓ 合并候选 ↓ Rerank ↓ 生成答案再比如用户问某个按钮在哪 ↓ 先查页面说明文档 ↓ 再查产品截图 ↓ 再查操作指南因为很多问题既有文字依据也有视觉依据。如果只用一种模态召回会不完整。所以多模态 RAG 的核心是融合而不是替代。多模态 Embedding 的作用为了让图片和文本都能进入统一检索链路通常需要多模态 Embedding。它的目标是把不同模态映射到可比较的向量空间里。这样用户问文本系统也能检索图片。比如“这个报错截图怎么处理”系统可以召回错误码说明文档 处理步骤截图 故障案例图片多模态 Embedding 的关键价值在于文本可以找图 图可以找文本 图文混合内容可以一起检索但它也有局限。因为不同场景下图文对齐质量差别很大。所以不要幻想只靠一个向量模型就解决所有多模态问题。通常还是要结合 OCR、结构抽取和业务规则。多模态 RAG 的常见误区第一觉得“有 OCR 就够了”。OCR 只能提文字不能保证结构正确。第二把图片直接转文本后当纯文本处理。这样容易丢失位置信息和关系信息。第三忽略表格结构。表格是很多业务知识最重要的承载方式。第四不做多模态和文本的融合。只做一条通路会漏掉很多问题。第五没考虑图像质量。模糊截图、压缩图片、低分辨率图表都会影响识别效果。第六没保留原图引用。如果答案来自截图最好能回链到原图或图像片段。这样更容易解释和审计。一个可落地的多模态处理链路一个比较实用的多模态 RAG 流程可以这样设计图片 / 截图 / 图表 / 表格 ↓ 类型识别 ↓ OCR / 表格识别 / 图像理解 ↓ 结构化提取 ↓ 图文对齐 ↓ 多模态索引 ↓ 文本检索 多模态检索 ↓ Rerank ↓ Prompt 生成其中有几个重点第一先识别内容类型再决定处理策略。第二尽量保留图文关系和表格结构。第三文本和图像索引要能一起检索。第四结果要能回到原图或原表。第五图像质量差时要有兜底。多模态 RAG 适合什么场景多模态 RAG 比较适合这些场景产品操作文档 报错截图排障 业务报表分析 流程图问答 架构图说明 图文混合知识库如果你的知识主要是纯文本那么没必要过早上多模态。但如果图片和表格已经占了很大比例多模态能力就很值得做。落地建议第一不要把多模态理解成单纯“让模型看图”。第二OCR、表格识别、图像理解和多模态 Embedding 要组合使用。第三文本检索和图像检索要融合而不是二选一。第四表格、流程图、架构图是重点场景。第五尽量保留原图、原表和原文的回链关系。第六不要一开始就追求所有图都能理解先从高频场景做起。第七图像质量差时要有清晰兜底策略。总结多模态 RAG 的本质是让 RAG 不再只依赖纯文本。图片、截图、表格、流程图和架构图都可能是答案来源。如果系统只会处理文本就会丢掉大量真实知识。所以多模态 RAG 不是炫技而是在企业知识库里补齐信息类型。下一篇文章可以继续讨论 RAG 如何降低成本。因为系统上线以后成本不仅来自模型调用也来自 Embedding、检索、Rerank 和长上下文。