面向图像与表格的 RAG

真实文档并不是文本。财报主体就是表格。技术文档里全是架构图。幻灯片演示稿是配了说明的图片。

从这些里面抽文本，你会把真正要紧的内容丢掉。一套跑在季度报告上的分块流水线，抓住的是叙述，扔掉的是数字。

三种策略，而它们的区别主要在于代价落在哪一环。

1 · 在索引时生成描述

让视觉模型跑过每一张图片、表格或图表，生成一段文字描述。把描述建索引。照常检索。

[图 3：2024–2026 年各季度营收对比柱状图。
营收稳步上升，2025 年 Q3 出现一次明显跃升。
2026 年 Q4 达到最高值。]

好处。 全程都是标准文本检索——不用新基础设施，混合检索原样可用。描述是可审查的，你能看到它到底抓到了什么。

局限。 描述有损，而且是永久的。它漏掉的东西，就永远检索不到了。一段提到了 Q3 的跃升、却没提具体数值的描述，回答不了关于具体数值的问题。

补救办法：既存描述，也存一个指向原图的引用，然后在生成时把图片本身发给模型。用文本检索，用原图作答——和检索小块、发送大块是同一个原则。

对大多数系统来说，这是最实用的选项。

2 · 多模态 embedding

把图像和文本编码进同一个共享向量空间，然后用一次查询在两者之上检索。

好处。 没有那一步有损的描述。文本查询可以直接检索到图片。

局限。 这类空间是粗粒度的。比起具体数值，它们更擅长捕捉「这是一张关于营收的柱状图」，而且在图像里渲染的文字上很弱——往往靠有没有像文字的像素来匹配，而不是真去读它。在网络图注数据稀少的专门领域，表现同样会下降。

最好和策略 1 结合起来用，而不是单用。

3 · 为表格做结构抽取

表格值得单独对待，因为它是最常见的情况，也是被文本抽取破坏得最厉害的一种。

表格是一个被压扁成一维流的二维结构，而这个压扁过程毁掉了让它可读的对齐关系。合并单元格、多行表头、无边框表格，全都能让朴素抽取失败。

管用的做法是：抽成一个真正的结构化格式——JSON、CSV 或 markdown——保住那个网格。然后索引两样东西：一份说明表格内容是什么的自然语言摘要，用于检索；以及结构化数据本身，用于生成。

面对数值型问题，最强的选项是完全跳过「先检索再阅读」：把表格加载进数据库，给模型一个 SQL 工具。聚合和过滤本来就是数据库该干的事，而让语言模型去求一列之和，就是让它做算术——它做得很差。

抽取质量排在最前面

无论你选哪种策略，文档抽取都在它们全部的上游，而且失败源于这里的比例比人们预想的高。

一张被搅乱的表格会产生噪声，流经之后的每一个环节。双栏 PDF 被横着读穿两栏，产出的文本局部流畅、整体错乱。这两种情况，下游都救不回来。

在调检索之前，先直接检查抽取输出。这个先后顺序能省下大量白费的功夫。

实操要点

保留对原件的引用。 每个派生出来的文本块旁边，都存上页码、边界框和源图片的路径。引用要用它，生成时发原图要用它，排查问题也要用它。

能可视引用就可视引用。 做文档问答时，把某个说法出自的页面区域直接展示给用户，比文本引用可信得多。

按问题类型分流。 数值型问题走 SQL，概念型问题走文本检索，视觉型问题走图像检索。一条流水线包打三种，比三条分流路径都差。

盯住成本。 图像会吃掉大量上下文——一页高分辨率页面可能超过好几页文本。每次查询都发五张页面图，很快就贵起来了。

按模态分别度量。 对文本、表格、图像三类问题分别追踪检索命中率。聚合数字会掩盖掉到底哪个模态在拖后腿。

要点回顾

• 文本抽取会丢掉那些常常装着答案的表格、图表和示意图
• 索引时生成描述，同时保留原件——用生成的文本做检索，生成时再把真正的图片发过去
• 多模态 embedding 免去了有损的描述，但粒度粗、对图中文字弱；应当结合使用，而不是替代
• 表格需要结构抽取；数值型问题就加载进数据库，把 SQL 交给模型
• 先修好文档抽取——它在一切的上游，而且失败起来悄无声息

下一篇： 评测 RAG