图片与文档 RAG

flowchart LR
  A["图片与文档 RAG"]
  A --> B["分类：检索增强 (RAG)"]
  A --> C["关键词：RAG"]
  A --> D["关键词：Multimodal"]
  A --> E["关键词：PDF"]
  A --> F["关键词：CLIP"]

前面几篇讨论的 RAG，大多默认知识以“可切分的纯文本”形式存在：一段说明、一篇文档、一条 FAQ、一页 Wiki。但真实世界里的知识很少这么整齐。

企业里的知识往往长这样：

PDF 里既有正文，也有页眉页脚、脚注、表格、图表、图片和附录
扫描件里没有原生文本，只有图像
产品手册的重要信息可能藏在参数表、尺寸图和标注图里
财报和研究报告里的关键结论往往来自图表，而不是正文段落
设计稿、流程图、截图、原型图中包含大量“看得到、但不一定能直接抽成文本”的信息

如果系统还只会做“抽文本 → 切 chunk → 向量检索”，它当然还能工作，但效果很容易在关键处打折。因为很多信息不是丢了，而是在进入 RAG 之前就已经被错误降维了。

于是，多模态 RAG 的问题就出现了：

当知识不只是文字，而是存在于版面、表格、图像、图表和扫描件里时，RAG 该如何理解和检索这些内容？

这篇要讨论的，正是这件事。

为什么纯文本 RAG 在文档场景里经常“不算错，但不够用”

先看一个典型场景：PDF。

如果你把一个复杂 PDF 直接“抽文本”，你往往会得到一种看起来像文本、实际上已经丢失大量结构的信息：

标题层级不清了
两栏排版被串成一列
表格被打平为一串字符
图注和正文的对应关系丢了
图片里的文字根本没被抽出来
坐标、页码、版面区域关系消失了

从系统角度看，它得到的是“有字的字符串”；但从读者角度看，原始文档里的很多关键语义其实来自：

这一段在不在标题下
这一行属于哪个表头
这张图对应哪个图注
某个数字是在图表里、正文里，还是脚注里
某一页是目录页、正文页、附录页还是表格页

这意味着，在文档理解里，语义往往不只是文本本身，还来自文本所在的结构和视觉上下文。

这会让纯文本 RAG 暴露出几个常见问题：

载体	真正的难点	纯文本 RAG 的典型局限
PDF	版面、层级、图表、表格混合	只抽文字会丢结构，且容易错序
扫描件	没有原生文本，需要 OCR	即便识别出文字，也常丢失版面和局部视觉信息
图片 / 截图	关键信息是视觉内容	无法按“长得像什么”或“图上有什么”来检索
表格	语义来自行列关系	打平成文本后，行列结构被破坏
图表	信息在坐标、图例、走势中	只抽图注通常不够，甚至会误解数据关系

一句话概括：

纯文本 RAG 擅长处理“写成段落的知识”，但不天然擅长处理“嵌在版面和视觉结构里的知识”。

多模态 RAG 真正扩展的，不只是输入类型，而是“可索引的知识单位”

很多介绍多模态 RAG 时，会把重点放在“图像也能检索”。这当然对，但还不够完整。

更准确的理解是：

多模态 RAG 把 RAG 的知识单元，从“纯文本片段”扩展成了“任何可被解析、表示、索引和回溯的内容块”。

这些内容块可能是：

一段正文
一个标题及其下属段落
一张表格
一张产品图
一页 PDF 页面
一段图表区域
一张扫描件中的签字区域
一组图文联合块
一个结构化表单区域

于是，系统不再只问“这段文字和 query 像不像”，还会开始问：

这张图是不是用户要找的那种图
这页是不是包含目标表格的那一页
这个表里的某一列和问题有没有关系
这段图注对应的是不是那张图
这个扫描件上的章、签名、抬头是不是具有业务含义

从这个角度看，多模态 RAG 的本质不是“让模型看图片”，而是：

让系统在检索阶段就承认：知识可能存在于文本之外。

一条更完整的 Document AI 流水线

文档型多模态 RAG，通常不会一上来就直接把整份 PDF 丢给模型。更常见的做法，是先经过一条文档理解流水线，把原始文档拆成更适合索引和检索的中间表示。

一个典型流程可以写成：

原始文档
  → 解析（PDF / Office / Image）
  → OCR（如有扫描页）
  → 版面分析
  → 结构识别（标题 / 段落 / 表格 / 图片 / 图注）
  → 内容块生成
  → 不同模态分别表示与索引
  → 检索
  → 融合
  → LLM 生成

如果进一步拆开，常见步骤大致如下：

步骤	作用	关键问题
文档解析	提取文本、页面、图片、坐标、元数据	能不能保留页面结构，而不只是拿到裸文本
OCR	把扫描件和图片里的文字转出来	识别率、版面保真、表格与手写处理
版面分析	识别标题、段落、页眉、页脚、表格、图片区域	如何避免把“看起来像正文”的噪声也当正文
表格抽取	保留行列结构、表头和单元格关系	如何避免表格被扁平化
图像 / 图表处理	提取区域、描述、视觉表示	图和文字如何对齐，图注如何回连
切块与索引	形成适合检索的多种块	不同块类型该如何切、如何存、如何查

这里最重要的一点是：

文档型 RAG 的上游，不是简单的“读文件”，而是“重建文档结构”。

如果这个结构重建得不好，后面的 embedding、检索和生成再强，也是在失真的输入上工作。

多模态 RAG 为什么比纯文本 RAG 更像“系统工程”

纯文本 RAG 的核心难题通常集中在：

chunk 怎么切
embedding 选什么
检索和 rerank 怎么调
答案如何引用

而多模态 RAG 会把问题前移很多。它真正难的地方，往往不是“最后怎么答”，而是“最初怎么把内容表示对”。

这也是为什么多模态 RAG 更像一套系统工程，而不是单个模型能力：

第一，表示方式不再统一

文本通常都能映射成“字符串 + 元数据”。但图片、表格、图表、页面区域、扫描件签名区，未必能用同一种方式表示。

第二，检索路径会分叉

一个问题可能同时需要：

文本检索
图像检索
表格检索
页级检索
结构化查询

最终再在融合层汇合。

第三，证据回溯更复杂

纯文本 RAG 往往只需要回指 chunk。多模态 RAG 可能要回指：

第几页
哪个坐标区域
哪张图
哪张表的哪一行哪一列
OCR 结果还是原图区域

因此，多模态 RAG 真正增加的，不只是模态，而是：

更多中间表示、更多索引策略、更多路由逻辑，以及更复杂的证据组织方式。

多模态 Embedding：为什么“图也能检索”这件事成立

让图片参与 RAG，关键不是让 LLM 在生成时能看图，而是让图像在检索阶段就能被表示和比较。

这就需要多模态 embedding。

它做的事情，本质上是把不同类型的输入——例如文本和图像——映射到一个可比较的向量空间里。于是系统就可以支持：

以文搜图：用一句文字描述去找相关图片
以图搜图：用一张参考图去找相似图片
图文混搜：文本 query 命中图片，图片 query 命中文本描述

这类模型的意义，不只是“酷”，而是非常实用。因为很多业务问题本来就是视觉导向的：

找和这张产品图类似的型号
找包含某种流程图样式的文档页
找带某种柱状图的报告
找版面结构类似的表单
找含某个 logo、icon、界面布局的设计文档

如果没有多模态表示，这些问题只能退化成：

先给图片做 caption
再把 caption 当文本去检索

这种做法不是不能用，但它的上限有限。因为很多视觉差异并不容易被自然语言完整描述。

所以，多模态 embedding 的真正作用是：

让“视觉相似性”和“文本语义”第一次能在检索层相遇。

多模态模型不只是给图片做向量，还会改变“文档页”的处理方式

在一般图像检索里，图片就是图片。但文档页不是普通图片。

一页 PDF 页面里，往往同时包含：

标题层级
正文块
表格
图注
图表
公式
页码
栏布局
白边和装饰元素

如果你把它完全当普通图片处理，模型可能能看出“这是一页文档”，却未必能理解：

哪一块是表格
哪一块是图表
标题和正文的层级关系
两栏文本是不是应该分别阅读
这一页最值得索引的区域在哪里

这也是为什么一些文档专用视觉模型会比通用图文模型更适合文档场景。它们不是单纯做“图片理解”，而是在做“带版面感知的文档理解”。

对文档 RAG 来说，这很重要。因为系统最终不是要回答“这张图好不好看”，而是要回答：

哪一页包含我要的表格
哪个区域是关键证据
这个问题应该匹配整页、局部块，还是图文联合区域

这意味着，文档视觉模型的真正价值，是让“页面”成为一种可检索单位，而不只是 OCR 的附属品。

PDF RAG：最常见，也最容易被低估的多模态场景

很多团队做多模态 RAG，真正第一个遇到的不是图片搜索，而是 PDF。

因为现实世界里，大量企业知识根本就是 PDF：

合同
手册
财报
研报
制度文档
招投标材料
产品说明书
论文和专利

PDF 最大的问题是：它既像文本容器，又不像真正的结构化文本。你能从里面提字，但“字被怎么摆放”常常同样重要。

因此，PDF RAG 常见会有三类路径。

路径	做法	优点	局限
纯文本路径	提取文字后走传统 RAG	简单、便宜、实现成熟	丢版面、丢表格、丢图表语义
视觉路径	把页面或区域作为视觉对象处理	能保留版面、图表和图像信息	成本高，索引与检索更复杂
混合路径	文本为主，视觉作补充	效果与成本更平衡	系统设计更复杂

真正实用的做法，通常不是三选一，而是根据 PDF 类型决定主路径。

文字为主的 PDF

例如普通说明文档、政策文件、技术白皮书。这类文档可以以文本抽取为主，只在保留标题层级、页码和块坐标上多下功夫。

表格密集型 PDF

例如财报、参数手册、报价单。这类文档如果只抽文本，往往会直接损坏语义。必须至少把关键表格单独识别、结构化或做表格级索引。

图表密集型 PDF

例如研究报告、商业分析报告、监控报表。这类内容里，核心结论可能来自图表而不是正文。如果系统完全看不到图，回答往往只会停留在图注附近，无法真正理解趋势和对比。

所以，PDF RAG 里一个很重要的原则是：

不要把“能抽出字”误认为“已经理解了文档”。

表格 RAG：为什么表格不能被当成“长得奇怪的文本”

表格是文档 RAG 里最容易被错误处理的一类内容。

原因很简单：表格的语义不是线性的，而是二维的。

一个单元格的意义通常依赖于：

它所在的行
它所在的列
对应的表头
是否是合并单元格
所属的小节或表名
单位和注释

如果把它简单打平成一串文本，例如：

产品A 10 20 30 产品B 15 25 35 …

这当然还能“看出一些数字”，但很多关键关系已经没了。系统会很难可靠回答：

某型号的尺寸是多少
某季度毛利率在哪一列
某一行是否满足某个条件
对比的是哪两个维度
单位是万元、百分比还是毫米

因此，Table RAG 的重点不是“能把表读出来”，而是：

如何在索引阶段保住表的行列结构。

常见做法大致有三类。

1. 结构化存储

把表转成 JSON、CSV 或数据库表形式，保留：

表名
表头层级
行列索引
单元格内容
单位
页码和来源

这种方式最工程化，也最适合做精确定位和后续结构化查询。

2. 生成自然语言描述

例如把表转成类似：

“该表展示了各型号的尺寸、重量和功率参数”
“X 型号在尺寸列中的值为 ……”

这种方式更适合用文本检索做粗召回，但不适合替代原始表结构。因为一旦只保留描述，细粒度查询能力会下降。

3. 混合：结构 + 描述

实践里更常见的是保留两份表示：

一份是可计算、可定位的结构化表
一份是便于语义召回的自然语言摘要

这样可以兼顾召回与精读。

所以，对表格 RAG 来说，最重要的不是“表怎么转文字”，而是：

表格作为一种独立知识形态，应该有自己的索引策略。

图像 RAG：不是 OCR 的补充，而是另一条检索路径

很多人一提图片检索，第一反应还是“先 OCR”。但 OCR 只能解决图片里的文字问题，解决不了真正的视觉内容问题。

例如下面这些请求，OCR 都不够：

找和这张商品图外观相似的产品
找包含某类界面布局的设计稿
找有某种图标、配色或结构的页面
找带某类流程图的方案文档
找某种故障截图或报错界面

这些问题的核心不是文字，而是“看起来像什么”。这时，图像 RAG 的真正作用就体现出来了。

它通常有几种典型形式：

场景	核心方法
以图搜图	图像 embedding → 相似向量检索
以文搜图	文本和图像映射到同一空间 → 图像检索
图文联合检索	图、caption、周边文本共同索引
页面区域检索	不是整页搜，而是搜图中某个区域或对象

这里最值得强调的一点是：

图像 RAG 不是“把图片也塞给模型看看”，而是“让图片在检索阶段就获得和文本同等级的可检索地位”。

只有这样，系统才能真正支持多路召回，而不是把图像永远当作生成阶段的补充材料。

Caption 有用，但不能替代视觉表示

一个很常见的工程折中，是给图片生成 caption，然后把 caption 当文本去检索。

这在很多场景里确实有价值，因为它：

便于落入现有文本 RAG 体系
成本低于全量视觉模型
对“图片里大概是什么”类问题足够好用
更容易和现有文本索引统一

但它也有明显边界：

caption 会丢细节
caption 往往偏概括，不保局部
视觉相似不一定能被自然语言充分描述
图表、UI、结构化图像的关键差异，caption 不一定能说清

因此，更成熟的设计通常不是“caption 或视觉 embedding 二选一”，而是：

caption 用来补文本召回，视觉表示用来保留图像自身的信息密度。

这在产品图、界面图、图表页、设计稿、表单页等场景里尤其重要。

多模态 Chunking：块不再只是“几百个 token”

在纯文本 RAG 里，chunk 常常意味着一段字符范围。但在多模态文档里，“块”变成了一个更广义的概念。

它可能是：

块类型	更合适的处理方式
文本块	常规 chunking，保留标题、页码、坐标
表格块	作为整表或子表保留结构化表示
图片块	独立存储视觉表示，可附 caption
图文联合块	图片 + 图注 + 周边正文一起建索引
页面块	一整页作为视觉或文档级单位处理
区域块	页面中的某个框、图表、签名区域、注释区

这意味着 chunking 不再只是“按 token 长度切”，而是要问：

这个内容的自然语义边界是什么
它更像文本、表格、图像，还是图文复合体
哪种粒度最利于召回
哪种粒度最利于后续答案合成
哪种粒度最利于证据回溯

在文档型多模态 RAG 里，切块策略往往比文本 RAG 更重要。因为切错了，不只是少了上下文，而是直接破坏了模态内部的结构关系。

一个更真实的多模态 RAG 系统架构

如果把多模态 RAG 放进一个系统图里，它通常更像“多路检索 + 融合”，而不是单通道流程。

                    ┌─────────────────┐
                    │   用户 Query     │
                    └────────┬────────┘
                             │
                 ┌───────────┼───────────┐
                 ▼           ▼           ▼
           ┌──────────┐ ┌──────────┐ ┌──────────┐
           │ 文本检索  │ │ 图像检索  │ │ 表格检索  │
           │ Text Emb │ │ Multi Emb│ │ Structured│
           └────┬─────┘ └────┬─────┘ └────┬─────┘
                │            │            │
                └────────────┼────────────┘
                             ▼
                     ┌──────────────┐
                     │ 融合 / Rerank │
                     └──────┬───────┘
                            ▼
                     ┌──────────────┐
                     │  LLM 生成答案 │
                     └──────────────┘

这个架构里真正关键的，不只是“多模态”三个字，而是三件事：

1. 不同模态允许走不同检索逻辑

文本不一定要和表格走同一条检索路线。图片也不一定非要和文本共用同一种 embedding。

2. 最终要有统一的融合层

因为用户的问题经常是跨模态的。例如：

“这张图对应的产品规格表里，最大尺寸是多少？”
“这页图表表达的趋势，在正文里是怎么解释的？”
“这个扫描件里的签名是否出现在另一份文档中？”

这些问题都需要多模态结果在生成前被重新组织。

3. 融合不只是拼接，而是重新排序和去重

多路召回后，系统还要处理：

哪条证据更权威
同一页是否被文本和视觉路径重复命中
表格块和正文块是否其实说的是同一件事
图像命中结果是否需要补图注或周边文本

所以，多模态 RAG 的核心并不是“有多条路”，而是：

多条路最后如何汇成一组足够干净、足够相关、足够可解释的证据。

一个典型例子：产品手册 PDF + 产品图片

这个例子很适合说明多模态 RAG 为什么不是“把所有内容都 OCR 一遍”那么简单。

假设你有一套产品知识，里面包括：

产品手册 PDF
参数表
产品实拍图
尺寸示意图
安装步骤图
常见故障截图

用户可能会问：

“某型号的尺寸是多少？”
“有没有和这张图外观类似的产品？”
“图里的安装方向对应哪一页说明？”
“这个故障截图对应什么问题？”

如果系统只做文本 RAG：

第一个问题也许还能靠正文和表格文字回答
第二个问题几乎无能为力
第三个问题会丢失图和页的对齐关系
第四个问题则很难从截图本身检索

而一个更合理的多模态 pipeline 可能是：

解析 PDF，提取标题、正文、页码、表格、图像区域
文本块按段落和标题切分，走文本 embedding
表格独立转结构化表示，并生成轻量摘要用于召回
产品图、尺寸图、故障图单独存储，走多模态 embedding
图像与图注、页码、产品型号做关联
查询时根据问题类型决定主要走哪条路
多路结果进入融合层，再送给 LLM 组织答案

这个例子里最关键的不是模型名，而是：

每种知识载体都有适合自己的表示和索引方式。

多模态 RAG 里的几个关键权衡

和前几篇一样，多模态 RAG 真正难的部分也不在“概念上会不会”，而在工程取舍。

1. 解析质量 vs 成本

更复杂的文档解析和版面分析通常能带来更好结构，但成本更高、速度更慢、依赖更多工具链。不是所有文档都值得走最重的解析路径。

2. 页级索引 vs 块级索引

页级索引简单，适合先粗召回。块级索引更细，但构建复杂度和索引数量都会上升。很多系统最终会做成两级：先页级召回，再页内定位。

3. Caption 路径 vs 原生视觉路径

caption 更便宜，更易融入文本 RAG。原生视觉表示保真度更高，但成本和维护复杂度更高。这通常不是替代关系，而是分层关系。

4. 统一 embedding vs 分模态 embedding

理论上统一空间更优雅，但现实里不同模态的最佳表示未必一致。很多系统会在融合层统一，而不是在底层强行统一。

5. 全文视觉理解 vs 检索后视觉补充

直接对整份文档做视觉理解很强，但贵。先文本或结构召回，再对关键页做视觉补充，通常更实用。

一句话概括：

多模态 RAG 很少有“最先进的单一路线”，更常见的是按文档类型和问题类型分层设计。

常见失败模式

多模态 RAG 很容易看起来“功能很多”，但真正上线时，经常会在一些基础问题上失效。

1. 过度依赖 OCR

OCR 很重要，但它只解决“图里有字”的问题，不解决“图到底表达什么”的问题。把 OCR 当作多模态的全部，通常会让系统在图表、UI、布局、形状、对齐关系上失明。

2. 把 PDF 当作普通长文本

如果复杂 PDF 只做裸文本抽取，后续回答可能看起来流畅，但关键表格、图注、页级关系已经丢了。

3. 表格被打平后再做普通 chunk

这类问题最隐蔽。系统似乎“抽到了数字”，但回答一旦涉及行列对应、单位或比较关系，就容易出错。

4. 图片只做 caption，不保留原图索引

这样虽然短期简单，但很多视觉近似检索和图形结构检索会直接失去能力。

5. 多路召回后没有统一融合逻辑

文本、图像、表格都各自召回到了结果，但最后只是简单拼起来。这会导致：

重复证据过多
关键证据排序不合理
图和文错配
相关但不权威的信息压过权威来源

6. 忽视证据回溯

多模态系统如果不能清楚指出：

来自哪一页
哪张图
哪个表
哪个区域

那它在高可信场景里会很难落地。

实践建议：先把“文档理解”做好，再谈“多模态问答很智能”

多模态 RAG 很容易被包装成“模型现在可以读图读表读 PDF 了”，但真正决定效果上限的，通常不是最后生成那一步，而是上游有没有把文档结构正确地保留下来。

一个更稳妥的落地顺序通常是：

先明确文档类型文字为主、表格为主、图表为主、扫描件为主，处理方式不同
再确定关键知识单元对你的业务最重要的是段落、表格、页面、图像，还是图文联合区域
然后为不同单元建立合适的索引不要试图用一种 chunk 规则解决所有模态
最后再考虑多路融合与生成生成阶段只是吃证据，不负责补救上游表示错误

换句话说：

多模态 RAG 的成败，常常在检索前就已经决定了。

技术选型上的一个务实原则

如果把这篇压成一个最实用的选型建议，那会是：

文档类型	更务实的方案
纯文本文档	传统 RAG 足够
文字为主的 PDF	文本提取 + 标题层级 + 页码 / 坐标保留
表格密集文档	表格单独结构化，不要只做纯文本抽取
图表密集文档	文本检索 + 关键页 / 图表的视觉补充
产品图库 / 设计稿 / 截图库	多模态 embedding 为主，caption 为辅
扫描件 / 票据 / 表单	OCR + 版面分析 + 区域级索引

这张表想表达的不是“哪个工具最好”，而是一个更基础的判断：

不要先问“我该用哪个模型”，而要先问“我的知识主要以什么形态存在”。

小结

多模态 RAG 的真正意义，不是给 RAG 多加几个输入类型，而是把“知识”的定义从纯文本扩展到更真实的文档世界。

在现实系统里，知识往往不只写在段落里，也写在：

表格的行列关系里
图表的走势和图例里
PDF 的版面层级里
扫描件的页面区域里
图片的视觉特征里
图与图注、图与正文的对应关系里

这意味着，RAG 不再只是“切文字、搜文字、拼文字”，而是要学会：

重建文档结构
为不同模态选择不同表示
走多路检索
在融合层重新组织证据
最终把跨模态证据交给模型回答

更克制地说：

多模态 RAG 不是让 RAG 变得更花哨，而是让它终于更接近现实世界里知识真正存在的样子。

如果前几篇更多是在讨论文本知识如何被检索，这一篇补上的，是另一个关键视角：

当知识开始存在于页面、表格、图像和布局中时，RAG 的问题不再只是“检索什么文本”，而是“如何让不同模态都成为可被检索、可被回溯的证据”。

这也正好引向下一篇：当系统越来越复杂，只会“能答”已经不够了。我们还需要回答另一个问题——RAG 到底做得好不好，该怎么系统评测？

核心概念速查

概念	一句话
Document AI	对 PDF、图片、扫描件等做解析、OCR、版面分析、表格抽取的上游理解流水线
Multimodal RAG	让文本、表格、图像、页面等不同内容形态都能进入检索与增强流程
Multimodal Embedding	将文本与图像等映射到可比较的向量空间，支持以文搜图、以图搜图
Table RAG	把表格当作独立知识单元处理，保留行列结构而不是简单打平为文本
PDF RAG	不只抽文字，还要尽量保留页面结构、表格、图表和页级位置信息
图像 RAG	让图片在检索阶段就具备可索引地位，而不只是生成阶段的附加输入
Caption	对图像的文本描述，适合做轻量召回，但不能完全替代视觉表示
多模态 Chunking	块不再只是文本片段，也可以是表格、图片、页面或图文联合区域
实践原则	先把文档结构和知识单元表示对，再谈多模态检索与问答效果