多模态内容在 RAG 中应该如何处理？

传统 RAG 处理的大多数内容都是文本：

Word / PDF / Markdown
↓
解析文本
↓
Chunk
↓
Embedding
↓
Vector DB
↓
LLM

但真实企业知识库往往不仅有文字，还有：

PDF
图片
扫描件
表格
流程图
架构图
PPT
图表

这时候就会遇到一个问题：

这些非纯文本内容，怎么放进 RAG？

一、最简单的方法：Apache Tika

我自己常用的一种方式，就是先使用：

Apache Tika

把各种文件统一解析成文本。

例如：

PDF
Word
PPT
Excel
HTML
↓
Apache Tika
↓
Text + Metadata
↓
Chunk
↓
Embedding

它最大的优点是：

简单、统一、工程成本低。

比如一个 PDF：

产品名称：XXX

产品支持 14 天退款。

经过 Tika 后直接提取成文本，就可以按照普通 RAG 流程处理。

对于：

普通 PDF
Word
网页
PPT 中的文字

这种方案通常已经够用了。

二、Tika 的问题是什么？

Tika 更擅长：

提取文本和 Metadata。

但是它并不真正“理解图片”。

例如 PDF 中有一张架构图：

User
 ↓
Gateway
 ↓
Service
 ↓
Database

如果这些关系主要存在于图片里面，Tika 很可能只能得到：

Architecture Diagram

甚至什么都提取不到。

于是：

原文信息很完整
↓
转成纯文本
↓
视觉信息丢失
↓
RAG 无法检索

所以严格来说：

Tika 解决的是“文档解析”，并没有完全解决“多模态理解”。

三、扫描 PDF：使用 OCR

如果 PDF 本质上是一张张扫描图片，就需要 OCR。

流程：

扫描 PDF
↓
OCR
↓
文字
↓
Chunk
↓
Embedding

OCR 比较适合：

扫描合同
发票
书籍
纸质文档
截图

例如图片上写着：

合同有效期：2026 年 1 月 1 日

OCR 把它转换成：

合同有效期：2026 年 1 月 1 日

然后就可以进入普通 RAG。

所以可以简单理解：

Tika
→ 提取已有文本

OCR
→ 从图片中识别文字

四、复杂 PDF：使用 Layout Parser

企业 PDF 往往不是简单的一段文字。

可能是：

标题

左栏文字        右栏图片

表格

页脚

如果直接提取文本，很容易变成：

顺序混乱
表格错位
标题和正文分离

这时候可以使用：

Layout-aware Document Parsing

也就是先识别文档结构：

标题
正文
表格
图片
页眉
页脚

然后分别处理。

最终可能得到：

Document
│
├── Title
├── Paragraph
├── Table
├── Image
└── Caption

相比直接：

PDF → 纯文本

这种方式能保留更多文档结构信息。

五、图片怎么办？让视觉模型生成描述

如果知识库中存在：

产品图片
流程图
架构图
截图
设备照片

一种非常实用的方法是：

使用视觉模型，把图片转换成文字描述。

例如图片是一张系统架构图。

视觉模型生成：

该架构图描述了一个微服务系统。

用户请求首先进入 API Gateway，
然后由 Gateway 转发给 Order Service，
Order Service 最终访问 MySQL 数据库。

然后：

Image
↓
Vision Model
↓
Image Description
↓
Embedding
↓
Vector DB

用户以后问：

请求是怎么进入 Order Service 的？

RAG 就有可能通过这段图片描述把架构图检索出来。

这种方式可以理解成：

把视觉信息翻译成文本，再进入传统 RAG。

六、更进一步：直接做图片 Embedding

还有一种真正的多模态方案：

不一定把图片全部转换成文字，而是直接：

Image
↓
Multimodal Embedding
↓
Vector

文本也是：

Text
↓
Multimodal Embedding
↓
Vector

这样用户输入：

查找系统架构图

可以直接匹配：

图片

而不只是匹配图片对应的文字描述。

最终：

Query
↓
Multimodal Retriever
↓
Text + Image
↓
Multimodal LLM
↓
Answer

这才更接近真正意义上的：

Multimodal RAG。

七、表格最好单独处理

表格也是 RAG 中非常容易出问题的一种内容。

例如：

产品	价格	退款期限
A	100	7 天
B	200	14 天

如果直接转换成：

A 100 7
B 200 14

模型可能很难理解其中的对应关系。

所以最好尽量保留结构：

产品 A
价格：100
退款期限：7 天

产品 B
价格：200
退款期限：14 天

或者直接保存：

Markdown Table
JSON
Structured Data

例如：

{
  "product": "B",
  "price": 200,
  "refund_days": 14
}

对于表格来说：

结构完整性往往比纯文本提取更重要。

八、实际项目里比较推荐“双路处理”

一个比较实用的 Multimodal RAG 架构是：

                Document
                   ↓
        ┌──────────┴──────────┐
        ↓                     ↓
     Text Parser          Image Parser
        ↓                     ↓
Tika / OCR / Layout       Vision Model
        ↓                     ↓
      Text             Image Description
        └──────────┬──────────┘
                   ↓
               Embedding
                   ↓
               Vector DB

也就是说：

文本内容：

Tika / OCR
↓
Text Embedding

图片内容：

Vision Model
↓
Description
↓
Embedding

两部分最后统一进入知识库。

这是目前工程上非常容易落地的一种方案。

九、更完整的方案：多路索引

如果系统要求更高，还可以建立：

Text Index
+
Image Index
+
Table Index

查询时：

User Query
   ↓
──────────────
↓      ↓      ↓
Text  Image  Table
Search Search Search
↓      ↓      ↓
──────────────
       ↓
    Reranker
       ↓
Text + Image + Table
       ↓
Multimodal LLM

这样就不会强行把所有信息都转换成一种格式。

十、实际项目怎么选？

如果知识库主要是：

Word
普通 PDF
网页
PPT 文字

那么：

Tika
+
普通文本 RAG

通常就够用了。

如果存在大量：

扫描 PDF

加入：

OCR

如果存在大量：

复杂 PDF
表格

加入：

Layout Parser
+
Table Parser

如果存在大量：

架构图
流程图
截图
产品图片

最好加入：

Vision Model
+
Image Description

如果视觉信息本身非常重要，则进一步使用：

Multimodal Embedding
+
Multimodal LLM

总结

多模态 RAG 的核心其实不是：

“把所有文件都转成文本。”

而是：

尽可能保留原始信息的语义。

最简单的方案：

Tika
↓
Text
↓
RAG

进一步可以升级成：

Tika
+
OCR
+
Layout Parser
+
Table Parser
+
Vision Model

再复杂一些，就是：

Text Embedding
+
Image Embedding
+
Multimodal Retriever
+
Multimodal LLM

可以简单记住：

普通文字
→ Tika

扫描内容
→ OCR

复杂版式
→ Layout Parsing

表格
→ Structured Parsing

图片 / 图表
→ Vision Model

真正多模态
→ Multimodal Embedding + Multimodal LLM

所以，Tika 是一个很好的起点，但如果知识库里真正重要的信息存在于图片、表格和图表里，仅仅使用 Tika 就不够了。

Multimodal RAG 真正要解决的问题是：

不管知识存在于文字、图片还是表格中，都能够被正确解析、检索，并最终交给模型理解。