14. RAG 中如何处理表格、图片等非纯文本内容的检索?

整理 RAG 中如何处理表格、图片等非纯文本内容的检索? 的核心概念、工程要点与面试回答。

简单回答

非纯文本内容的处理是 RAG 工程化的常见难题。表格通常需要转换成文本描述或结构化格式(Markdown/HTML),图片需要通过多模态模型(VLM)提取描述或 OCR 提取文字,然后再做 Embedding 和索引。另一种思路是直接用多模态 Embedding 模型(如 CLIP 系列)对图片和文本做联合编码。核心挑战在于信息损失——非文本内容转成文本后经常丢失关键信息。

详细解释

为什么这是一个问题

标准 RAG 流程的 Embedding 模型是纯文本模型——它只能对文本做编码。但真实的企业知识库里充满了非文本内容:表格(财务报表、产品参数表、价格表)、图片(架构图、流程图、截图)、图表(柱状图、折线图)、公式等。如果忽略这些内容,检索的覆盖率会大打折扣。

表格的处理

表格是最常见的非文本内容,处理方案相对成熟。

最直接的方式是把表格转成文本。一种是转成自然语言描述——比如一个 3 行 4 列的产品参数表,转成"产品 A 的重量为 1.5kg,尺寸为 30×20×15cm,价格为 299 元"这样的文本。好处是 Embedding 模型能理解,坏处是对于大表格,文本会非常冗长,而且行列关系的表达不直观。

另一种是转成 Markdown 或 HTML 表格格式保留结构。这对现代 LLM 来说通常是可以理解的(LLM 在预训练时见过大量 Markdown 和 HTML),而且保留了结构信息。这是目前实践中更推荐的方式。

对于非常大的表格,或者需要精确数值查询的场景("Q3 北京区域的销售额是多少"),更好的方式是把表格数据灌入结构化数据库(如 SQLite、PostgreSQL),检索时让 Agent 生成 SQL 查询,直接在数据库中精确查找,而不是靠向量检索的模糊匹配。

图片的处理

图片处理的难度比表格大,因为信息形态差异更大。

OCR + 文本处理是针对"图片中有文字"的场景。比如截图、扫描件、拍照文档,用 OCR 提取文字后就可以当作普通文本处理。工具包括 Tesseract、PaddleOCR、以及各云平台的 OCR API。OCR 的识别准确率在清晰文档上很高,但手写字、模糊图像、复杂排版上还是会出错。

多模态模型描述是针对"图片本身传达信息"的场景。比如架构图、流程图、数据可视化图表。用 VLM(如 GPT-4o、Qwen-VL)对图片做描述,生成一段文字解释图片内容,然后对这段文字做 Embedding 和索引。比如一张网络架构图可能被描述为"该系统采用三层架构,前端通过 Nginx 负载均衡连接到三个 API 服务节点,API 服务节点通过 Redis 缓存访问 PostgreSQL 数据库"。

这种方式的效果高度依赖 VLM 的描述质量。对于简单的图片描述效果还行,但对于信息密度高的技术架构图、复杂流程图,VLM 经常会遗漏关键细节或描述不准确。

多模态 Embedding是另一种思路,用能同时处理图片和文本的 Embedding 模型(基于 CLIP、SigLIP 等)直接对图片编码成向量,和文本向量存在同一个向量空间中。检索时用文本 query 也能匹配到相关图片。这种方式避免了图片到文本的信息损失,但多模态 Embedding 模型在检索精度上通常不如专门的文本 Embedding 模型。

综合处理策略

实际项目中通常是多种方式结合。对于 PDF 文档中的表格,用专门的表格提取工具(如 camelot、tabula、Marker)提取后转 Markdown。对于 PDF 中的图片,先判断类型——如果是截图/扫描文字就 OCR,如果是图表就用 VLM 描述。所有提取出的文本和描述都一起做 Embedding 存入向量库。

一个重要的工程细节是保留元数据。每个 Chunk 的元数据中应该记录它的来源类型(文本/表格/图片)、在原文档中的位置、以及原始的非文本内容引用(比如图片的 URL 或存储路径)。这样在最终生成回答时,可以把原始图片或表格作为附件展示给用户,而不只是给文字描述。

ColPali 等新方向

ColPali 是近年一个值得关注的方向——它直接对文档页面的截图做 Embedding(基于 PaliGemma),跳过了文档解析、OCR、Chunk 切分这些步骤。每一页文档就是一个"图片",用多模态模型直接编码。这种方式大幅简化了处理流程,但目前在精度上和传统文本 RAG 相比还有差距,更适合做粗检索(找到相关页面),然后再在页面内做精细处理。

面试时可以这样答

非文本内容的处理是 RAG 工程化的常见痛点。表格通常转成 Markdown 格式保留结构,让 LLM 能理解行列关系。如果需要精确数值查询,更好的方式是把表格灌入结构化数据库用 SQL 查。

图片分两种情况。如果图里有文字(截图、扫描件),用 OCR 提取文字后当文本处理。如果图片本身传达信息(架构图、流程图),用多模态模型生成描述,再对描述做 Embedding。也可以用多模态 Embedding 直接对图片编码,但精度通常不如纯文本方案。

实际中是多种方式结合。关键是保留元数据——记录每个 Chunk 的来源类型和原始内容引用,方便最终回答时展示原始图表。另外 ColPali 这类直接对文档页面截图做 Embedding 的方案也值得关注,能跳过复杂的解析流程,虽然精度还有差距但在某些场景下很实用。

常见追问

  1. 你实际项目中怎么处理 PDF 中的表格和图片?
  2. 多模态 Embedding 的检索精度和纯文本 Embedding 差多少?
  3. 如果知识库中一半以上是图片和表格,RAG 架构该怎么调整?