RAG多模态数据处理

多模态 RAG 可以理解为：

不只处理文本，还能处理 图片、PDF、表格、音频、视频 等多种数据，然后通过检索增强，让大模型基于这些资料回答问题。

传统 RAG 主要是：

文档文本 → 切分 → 向量化 → 检索 → 大模型回答

多模态 RAG 是：

文本 / 图片 / 表格 / 音频 / 视频 / PDF
        ↓
多模态解析
        ↓
文本化 + 向量化 + 结构化
        ↓
多路检索
        ↓
结果融合
        ↓
大模型生成答案

---

一、整体处理流程

1. 数据接入

多模态 RAG 首先要接入不同类型的数据。

常见数据包括：

类型	示例
文本	Word、Markdown、网页、合同、制度文档
PDF	扫描 PDF、电子 PDF、论文、报告
图片	截图、票据、商品图、架构图
表格	Excel、CSV、数据库表
音频	会议录音、客服录音
视频	培训视频、监控视频、课程视频

---

二、多模态数据解析

不同数据不能直接丢进向量库，需要先解析。

1. 文本数据处理

文本数据最简单。

流程：

文档读取
 ↓
清洗文本
 ↓
按段落 / 标题 / token 切分
 ↓
生成 Embedding
 ↓
存入向量库

比如：

公司报销制度.docx

处理后可能变成：

{
  "content": "员工出差住宿标准为每天不超过 500 元。",
  "metadata": {
    "fileName": "公司报销制度.docx",
    "page": 3,
    "section": "出差报销"
  }
}

---

2. PDF 数据处理

PDF 比普通文本复杂，因为 PDF 可能包含：

• 正文文本
• 图片
• 表格
• 扫描件
• 页眉页脚
• 多栏排版

处理方式通常是：

PDF
 ↓
判断是电子 PDF 还是扫描 PDF
 ↓
提取文本 / OCR 识别
 ↓
识别表格 / 图片
 ↓
按页码、标题、段落切分
 ↓
生成向量
 ↓
存储

PDF 处理重点

内容	处理方式
普通文字	PDF Parser 提取
扫描图片	OCR 识别
表格	表格识别，转 Markdown / JSON
图片	图片描述生成 Caption
页码	存入 metadata

例如 PDF 里有一张架构图，可以先让视觉模型生成描述：

该图片展示了一个 RAG 系统架构，包括数据接入、向量化、向量库、检索器、重排序和大模型生成模块。

然后把这段描述也存入向量库。

---

3. 图片数据处理

图片不能直接像文本一样切分，所以一般有两种处理方式。

方式一：图片转文字

使用 OCR 或视觉模型把图片内容转成文本。

图片
 ↓
OCR / 视觉模型识别
 ↓
图片描述 Caption
 ↓
文本向量化
 ↓
存入向量库

例如发票图片：

{
  "content": "这是一张增值税发票，金额为 1280 元，购买方为某某公司。",
  "metadata": {
    "type": "image",
    "fileName": "invoice.png"
  }
}

方式二：图片直接向量化

使用多模态向量模型，例如 CLIP 类模型，把图片直接转成图片向量。

图片
 ↓
Image Embedding
 ↓
存入向量库

查询时，如果用户问：

找一下包含系统架构图的图片

系统可以通过图片向量进行相似度检索。

---

4. 表格数据处理

表格数据不能简单当普通文本处理，否则容易丢失结构。

例如 Excel：

日期	商品	销售额
2026-05-01	手机	30000
2026-05-02	电脑	50000

处理方式可以是：

方式一：转 Markdown

| 日期 | 商品 | 销售额 |
|---|---|---|
| 2026-05-01 | 手机 | 30000 |
| 2026-05-02 | 电脑 | 50000 |

方式二：转 JSON

[  {    "日期": "2026-05-01",    "商品": "手机",    "销售额": 30000  },  {    "日期": "2026-05-02",    "商品": "电脑",    "销售额": 50000  }]

方式三：入库查询

如果是业务表，比如订单、支付、退款数据，最好进入数据库或 ClickHouse。

Excel / MySQL / CSV
 ↓
结构化入库
 ↓
SQL 查询
 ↓
查询结果交给大模型总结

这种场景不一定适合完全靠向量库。

---

5. 音频数据处理

音频一般要先转文字。

音频文件
 ↓
ASR 语音识别
 ↓
生成文字稿
 ↓
按时间片段切分
 ↓
向量化
 ↓
存入向量库

例如客服录音：

{
  "content": "客户表示订单已经付款，但系统显示未支付。",
  "metadata": {
    "audioFile": "customer-call.mp3",
    "startTime": "00:01:25",
    "endTime": "00:01:42"
  }
}

这样用户问：

哪个客户反馈过付款后订单状态异常？

系统可以检索到对应音频片段。

---

6. 视频数据处理

视频最复杂，因为视频包含：

• 画面
• 字幕
• 语音
• 关键帧
• 时间轴

处理流程通常是：

视频
 ↓
抽取音频
 ↓
ASR 语音转文字
 ↓
抽取关键帧
 ↓
图片理解 / OCR
 ↓
按时间段切分
 ↓
文本向量 + 图片向量
 ↓
存入向量库

例如培训视频：

{
  "content": "讲师正在介绍 RAG 的检索增强生成流程。",
  "metadata": {
    "videoFile": "rag-training.mp4",
    "startTime": "00:08:10",
    "endTime": "00:09:30",
    "frame": "frame_0810.jpg"
  }
}

---

三、多模态 RAG 的核心架构

可以理解为下面这个流程：

用户问题
  ↓
问题理解
  ↓
判断查询类型
  ↓
文本检索 / 图片检索 / 表格查询 / 音频检索 / 视频检索
  ↓
多路召回结果
  ↓
结果重排序
  ↓
上下文组装
  ↓
大模型生成答案

---

四、关键模块说明

1. 数据解析层

负责把各种原始文件处理成可检索的数据。

PDF Parser
OCR
ASR
Image Caption
Table Parser
Video Frame Extractor

---

2. 向量化层

不同模态可以使用不同 Embedding 模型。

数据类型	向量化方式
文本	Text Embedding
图片	Image Embedding
图文	Multimodal Embedding
音频转文字	Text Embedding
视频字幕	Text Embedding
视频关键帧	Image Embedding

---

3. 存储层

多模态 RAG 通常不是只用一个向量库，而是组合存储。

存储类型	存什么
对象存储	原始 PDF、图片、音频、视频
MySQL/PostgreSQL	文件元数据、任务状态、权限
向量库	文本向量、图片向量
Elasticsearch	关键词检索
ClickHouse	大规模结构化分析
Redis	缓存、任务状态、分布式锁

---

4. 检索层

多模态 RAG 常用 混合检索。

关键词检索 BM25
+
向量检索 Embedding Search
+
结构化查询 SQL
+
图片相似度检索

例如用户问：

帮我找一下包含支付流程图的文档

系统可能同时做：

1. 文本检索：“支付流程图”
2. 图片 OCR 检索：“支付、订单、回调、退款”
3. 图片向量检索：查找类似流程图的图片
4. PDF 元数据检索：查找相关文件

---

5. 结果融合层

不同模态检索出来的结果需要合并。

例如：

文本段落 3 条
图片描述 2 条
表格数据 1 条
视频片段 1 条

系统需要根据相关性排序，组成最终上下文：

【文档片段】
...

【图片内容】
...

【表格数据】
...

【视频片段】
...

然后交给大模型回答。

---

五、一个完整示例

用户问：

这个 PDF 里 RAG 架构图表达了什么？

系统处理过程：

1. 读取 PDF
2. 提取 PDF 文本
3. 识别 PDF 中的图片
4. 对图片做 OCR
5. 对图片生成描述
6. 将文本、图片描述、页码一起存入向量库
7. 用户提问时检索相关内容
8. 找到对应页的架构图描述
9. 大模型根据检索结果总结

最终回答可能是：

这张图表达的是一个典型 RAG 流程：先进行文档加载，然后进行文本切分和向量化，接着存入向量数据库。用户提问后，系统先检索相关知识片段，再将问题和片段一起交给大模型生成答案。

---

六、多模态 RAG 和普通 RAG 的区别

对比项	普通 RAG	多模态 RAG
数据类型	主要是文本	文本、图片、表格、音频、视频
解析难度	较低	较高
检索方式	文本向量检索	文本检索 + 图片检索 + SQL + OCR
存储方式	向量库为主	向量库 + 对象存储 + 数据库
应用场景	文档问答	图文问答、视频问答、票据识别、会议分析
工程复杂度	中等	较高

---

七、实际落地架构建议

企业级多模态 RAG 可以这样设计：

前端上传
  ↓
文件服务
  ↓
任务队列 RabbitMQ
  ↓
多模态解析服务
  ├── 文本解析
  ├── PDF 解析
  ├── OCR 识别
  ├── 表格解析
  ├── 音频 ASR
  └── 视频抽帧
  ↓
Embedding 服务
  ↓
向量库
  ↓
检索服务
  ↓
重排序服务
  ↓
大模型问答服务

---

八、Java 后端落地可以这样分层

controller
 ├── FileUploadController
 ├── ChatController

service
 ├── DocumentParseService
 ├── OcrService
 ├── AsrService
 ├── EmbeddingService
 ├── VectorStoreService
 ├── RetrievalService
 ├── RerankService
 ├── RagChatService

domain
 ├── KnowledgeFile
 ├── KnowledgeChunk
 ├── VectorRecord
 ├── ParseTask

infrastructure
 ├── MySQL
 ├── Redis
 ├── RabbitMQ
 ├── MinIO
 ├── Milvus / Elasticsearch / pgvector

---

九、核心难点

1. 图片和表格不能粗暴转文本

图片、表格都有结构信息。
如果直接转成普通文本，容易丢失语义。

例如表格：

张三 100 李四 200

这种文本没有字段含义。

更好的方式是：

{
  "姓名": "张三",
  "金额": 100
}

---

2. PDF 版式容易乱

PDF 可能有多栏、页眉、页脚、图片、脚注。

所以需要：

去页眉页脚
保留标题层级
保留页码
保留表格结构
保留图片位置

---

3. 检索结果需要重排序

多模态数据召回后，结果可能很多，需要 rerank。

初步召回 50 条
 ↓
重排序
 ↓
保留最相关 5 条

否则上下文太多，大模型回答会混乱。

---

4. 权限控制很重要

企业知识库必须控制权限。

例如：

用户 A 只能查财务制度
用户 B 可以查合同和订单数据
用户 C 不能查人事薪资文件

所以每个 chunk 都应该带 metadata：

{
  "fileId": "xxx",
  "tenantId": "1001",
  "userId": "u001",
  "departmentId": "finance",
  "permission": "private"
}

检索时必须加权限过滤。

---

十、简单总结 🎯

多模态 RAG 的本质是：

把文本、图片、表格、音频、视频等不同类型数据，先解析成可理解、可检索、可追溯的知识片段，然后通过向量检索、关键词检索、结构化查询等方式找到相关内容，最后让大模型基于这些内容生成答案。

最核心的处理链路是：

多模态数据
 → 解析
 → 文本化 / 结构化 / 向量化
 → 存储
 → 检索
 → 重排序
 → 上下文拼接
 → 大模型回答

一句话说：

普通 RAG 主要解决“文档问答”，多模态 RAG 解决的是“所有资料都能问”。