RAG 教程里的示例文档都是干净的 Markdown 段落；真实企业文档是另一回事：财报的核心数字在合并表格里，研报的结论在图表曲线上，合同的关键条款藏在跨页版式里。把这些 PDF 喂给「OCR → 切块 → 向量化」的标准管线（切块与混合检索见站内《RAG 切块策略实战》《混合检索与重排序》），结果常常是检索召回了一堆乱码表格、生成模型对着破碎文本编答案。多模态 RAG 就是为了补上这块短板。
文本管线为什么在真实文档上翻车
OCR 管线的失效是结构性的，三个层面：
- 表格与多栏版式：OCR 按阅读顺序线性输出，多栏文档的左右栏被串成一句话，表格被压扁成逗号分隔的乱码——语义在解析这一步就没了；
- 图表信息直接丢失：柱状图里的趋势、流程图里的箭头关系，OCR 天生「看不见」——图变成一个占位符，图里的数据蒸发；
- 空间关系消失：「见上表」「如下图所示」这类指代依赖版式，拍平成文本后指代悬空。
两条补齐路线
路线 A：解析增强——把解析做对
思路是保留文本 RAG 的骨架，把最脆弱的解析环节升级：用版式感知的文档解析（表格结构还原、阅读顺序重建、图表转数据/转描述），把文档转成「带结构的富文本」再走老管线。优点是检索基础设施完全复用（向量库、混合检索、rerank 全部照旧），生成的引用粒度也细；缺点是解析管线本身复杂且按文档类型调参，长尾版式永远有翻车率。适合文档量大、类型集中的场景（如财务、法律文档库先专门调表格与多栏）。
路线 B：视觉检索——ColPali 的「页即图」
2024 年 7 月的 ColPali 论文（Faysse et al.）提出了更激进的思路：别解析了，把 PDF 每页渲染成图片，直接用视觉语言模型检索页面。机制两步：
- 索引：用 VLM（PaliGemma 系）对页面图像编码——不是压成一个向量，而是每个页面产出一组 patch 级多向量；
- 检索：查询文本编码后，用 ColBERT 式的 **late interaction（MaxSim）**打分——查询的每个 token 找页面里最匹配的 patch，取最大相似度求和。它保留了「查询词 vs 页面局部区域」的细粒度对齐，能命中表格某个单元格、图表某个标签这类局部语义。
这条「OCR-free」路线的价值：表格、图表、版式、页眉页脚全部保留在像素里，没有解析损耗；VLM 看页面就像人看页面。生态跟进很快——微软开源了基于它的多模态 RAG 参考实现，Weaviate 等向量库加了多向量支持，检索质量有专门的 ViDoRe 基准追踪。代价也明确：索引存储暴涨（每页几十到上百个向量 vs 文本切块的一两个）、需要多向量检索引擎、页面图像还要占生成端的上下文。
生成端：图文交织进上下文
无论检索层走哪条路线，最后都要把「检索到的东西」交给生成模型。多模态 RAG 的编排选项：
- 文本直通：路线 A 解析出的结构化文本直接进 prompt，最省上下文；
- 页面图像直通：把命中的页面截图直接贴给多模态 LLM（GPT-4o/Qwen-VL 类），让模型「亲眼」读表格——这是 ColPali 路线的标配，也是对生成端模态能力的要求；
- 混合编排：图表给图像、正文给文本、元数据（页码/章节）做引用锚点——工程上最稳的组合。
选型权衡：一张决策表
| 维度 | 解析增强（A） | 视觉检索（B） |
|---|---|---|
| 表格/图表召回 | 依赖解析质量，长尾有漏 | 像素级保留，召回好 |
| 检索基础设施 | 现有向量库直接复用 | 需多向量能力，存储数倍增 |
| 生成端要求 | 纯文本模型即可 | 需多模态 LLM |
| 工程复杂度 | 集中在解析管线调优 | 集中在索引与编排 |
| 引用粒度 | 段落/表格级，精细 | 页面级，较粗 |
务实的混合打法也常见：ColPali 做召回（页面级），命中页再做轻量解析拿到精确段落做引用——用 B 的召回质量 + A 的引用粒度。
结语
多模态 RAG 的出现，本质是承认了一件事：文档的真实形态是版式，不是文本流。解析增强路线尊重「检索要文本」的传统，把功夫花在把版式转译成文本；视觉检索路线则让检索器直接长上眼睛。2026 年的落地共识大致是：表格图表占比高的文档库（财报、研报、图纸）优先试视觉检索，纯文本文档留在成熟管线——先看你的文档里，信息到底藏在什么形态里。
读者留言
COMMENTS 暂无还没有留言，来说第一句？