企业文档中的信息并不只存在于文字里：产品手册中的结构示意图、操作指南中的界面截图、汇报材料中的数据图表、维修手册中的零件照片。传统 RAG 在解析文档时往往直接丢弃这些图片，导致相关问题无法回答。多模态 RAG 的目标，是让知识库也能“看见”并检索这些视觉信息。

为什么文本 RAG 不够用

  • 用户问“设置页面里的导出按钮在哪”，答案在一张截图里；
  • 用户问“去年第三季度哪个区域增长最快”，答案在一张柱状图里；
  • 用户上传一张故障设备的照片，问“这是什么问题”；
  • 流程图中的审批节点和分支条件，文字说明里并没有完整描述。

这些情况在企业场景中非常普遍。

三种主流实现方式

方式一：图像转文字描述

在入库阶段，用视觉语言模型为每张图片生成详细的文字描述，例如图表的标题、坐标轴、主要数据和结论，截图中的界面元素和文字，然后把描述作为普通文本进行切分和向量化。

  • 优点：可以复用现有的文本 RAG 架构，改动最小；检索和生成环节都是文本，成本可控。
  • 缺点：描述的质量决定上限，生成描述时遗漏的细节在检索时无法找回；入库时需要为每张图调用视觉模型，有一定成本。

视觉模型的能力边界见视觉语言模型能看懂什么。

方式二：多模态向量检索

使用能把图像和文字映射到同一向量空间的多模态 Embedding 模型。图片直接编码为向量，用户的文字问题也编码为向量，在同一空间中检索。用户还可以用图片搜图片。

  • 优点：不依赖文字描述，保留了图像本身的信息；支持以图搜图。
  • 缺点：多模态向量对复杂图表、密集文字的细节表达有限；检索到图片后，仍需要视觉模型来理解和回答。

方式三：把文档页面当作图片

不再解析 PDF 的文字和版面，而是把每一页渲染成图片，用专门的视觉检索模型直接对页面图片建立索引。检索到相关页面后，把页面图片交给视觉语言模型阅读并回答问题。

  • 优点：完全绕开了复杂的 PDF 解析问题，表格、图表、排版信息都能保留，参见 PDF 与表格解析的坑；
  • 缺点：存储和检索成本较高；生成阶段需要把图片发给视觉模型，单次调用成本和延迟高于纯文本。

如何选择

  • 图片数量不多、以说明性截图为主：方式一最简单实用；
  • 需要以图搜图，比如商品图片、零件照片：方式二是必要的；
  • 文档排版复杂、图表密集，如研究报告、财务材料：方式三效果往往最好；
  • 组合使用：文本部分走常规 RAG，图片部分同时保存描述和向量，在检索阶段融合结果。

实践要点

保留图文关联

图片的上下文很重要。入库时记录图片所在的章节、前后段落和图注，检索到图片时一并提供给模型。

回答时展示原图

用户看到原始图片比看到文字描述更容易核实答案。在回答界面中展示引用的图片或页面截图，并标注来源。

控制成本

入库阶段的视觉模型调用是一次性成本，查询阶段的视觉模型调用是持续成本。高频查询的场景要特别评估查询时的成本，可参考大模型 API 成本优化。

专门评测

为图表、截图、照片类问题单独建立测试集，因为文本问题上的良好表现并不能代表视觉问题的效果。

小结

多模态 RAG 让知识库能够利用图片、图表和截图中的信息，补上了企业知识检索的一块重要短板。从图像转文本描述起步，根据需要引入多模态向量或页面级视觉检索，并做好图文关联、原图展示和专项评测，是比较稳妥的推进路径。文本 RAG 的基础知识可参考 RAG 文档切分策略。