RAG 只做文本已经不够了：多模态问答的工程化落地指南

引言：为什么下一代 RAG 一定是多模态

在过去一年，RAG 已经从“新概念”变成了企业级大模型落地的标配架构。
但你如果真正观察企业内部的数据形态，会发现一个现实问题：

真正有价值的信息，从来不只是文本。

在真实业务中，知识往往存在于：

• 产品说明书中的结构化表格
• 设备巡检报告中的图片、截图
• 财报、合同里的扫描件
• BI 系统导出的图表

如果你的 RAG 系统只能“读文字”，那它在很多关键场景下，天生就是信息不完整的。

多模态大模型的出现，让“看懂图片”“理解表格”成为可能；
但 RAG + 多模态 并不是把图片直接丢给模型这么简单。

这篇文章将围绕一个核心问题展开：

如何构建一个真正可用的多模态 RAG 系统，而不是一个 Demo？

技术原理：多模态 RAG 到底“难”在哪里？

先明确：多模态 RAG ≠ 多模态模型 + 向量库

很多人的第一反应是：

“我已经有能看图的模型了，直接把图片扔进去不就行了吗？”

这在对话演示中成立，但在企业级问答系统中几乎行不通。

原因在于：
RAG 的核心不是“模型能不能看”，而是 “系统能不能找”。

多模态 RAG 的三层结构

从工程角度看，一个多模态 RAG 至少包含三层能力：

• 模态解析层：把图片、表格、PDF 转成可理解的中间表示
• 检索层：让不同模态的信息“可被召回”
• 生成层：让模型基于多模态证据进行受控回答

其中，检索层是难度陡增的地方。

不同模态，语义空间并不天然一致

一个非常容易被忽略的事实是：

• 文本 embedding
• 图片 embedding
• 表格 embedding

并不天然处在同一个语义空间中。

如果你直接把三种向量丢进同一个向量库，很可能出现：

• 文本问题检索不到图片证据
• 图片相关问题被文本 chunk 覆盖
• 表格信息召回严重失真

因此，多模态 RAG 的第一原则是：

先统一“语义对齐策略”，再谈检索。

实践步骤：一套可落地的多模态 RAG 工程方案

下面进入实战部分，我将按真实工程顺序展开。

第一步：多模态数据预处理（90% 的问题在这里）

图片：不是“存图”，而是“理解图”

在 RAG 场景中，图片有三类常见来源：

• 扫描件（合同、报告）
• 截图（系统界面、报表）
• 原生图片（设备、现场照片）

建议处理流程：

• OCR 提取可见文字
• 图像 Caption（整体语义描述）
• 关键区域标注（表格、图表、关键数值）

最终目标不是“还原图片”，而是生成 可检索的语义文本。

表格：千万别当成“长文本”

表格是多模态 RAG 中最容易踩坑的对象。

错误做法：

• 把表格 flatten 成一大段文本

正确思路是：

• 保留行列结构
• 提取表头语义
• 构建“字段级”描述

示例（简化）：

表名：2023 年销售数据  

字段：月份、产品、销售额、同比增长  

2023年3月，产品A，销售额1200万，同比增长15%

第二步：多模态 embedding 的设计策略

三种常见方案对比

• 方案一：多模态统一 embedding
  • 优点：结构简单
  • 缺点：语义对齐难，效果不稳定
• 方案二：分模态 embedding + 融合
  • 图片、文本、表格各自 embedding
  • 查询时做加权融合
• 方案三：文本主导，模态转文本
  • 图片 / 表格先转“结构化文本”
  • 统一走文本 embedding

在企业场景中，方案三是成功率最高的。

原因很现实：

你不是在做多模态研究，而是在做可控问答系统。

embedding 模型的现实选择

实践经验：

• embedding 的“稳定性” > “极限效果”
• 中等维度（768）更易调优
• 行业数据适配非常重要

如果你需要对 embedding 或多模态编码器做领域适配，LLaMA-Factory Online可以作为一个低门槛选择，
避免从零搭训练管线。

第三步：检索层设计——多模态 RAG 的核心

检索一定是“多路并行”的

一个成熟的多模态 RAG 检索层，通常包括：

• 文本向量召回
• 图片语义文本召回
• 表格字段级召回
• 关键词 / 规则兜底

查询流程示意：

用户问题

  ↓

查询改写（是否涉及图片 / 数值 / 表格）

  ↓

多路召回

  ↓

结果合并 + 去重

  ↓

Rerank

Rerank 在多模态场景中更重要

多模态 RAG 中，召回噪声远高于纯文本。

建议：

• Top 50～100 召回
• 统一 rerank 到 Top 5～8
• rerank 输入包含：
  • 原问题
  • 候选内容
  • 模态标签

第四步：生成阶段——让模型“看证据，而不是乱猜”

多模态 RAG 的生成阶段，最容易出现“模型自由发挥”。

工程上必须做三件事：

• 明确证据来源（文本 / 图片 / 表格）
• 严格限定回答范围
• 支持引用回溯

示例 Prompt 思路：

你将基于以下资料回答问题：

资料可能来自文本、表格描述或图片解析结果。

请仅使用资料中的信息回答。

效果评估：多模态 RAG 怎么评？

不能只看“答得像不像人”

建议至少评估四个维度：

• 多模态召回覆盖率
• 关键信息准确率（数值 / 图表结论）
• 错误拒答率
• 延迟与稳定性

一个实用的评估技巧

把问题按类型拆分评估：

• 纯文本问题
• 依赖图片的问题
• 依赖表格计算的问题

你会非常直观地看到系统短板。

总结与未来展望：多模态 RAG 会走向哪里？

当你真正落地多模态 RAG，会发现一个事实：

多模态的价值，不在“炫技”，而在补全信息维度。

未来 1～2 年，多模态 RAG 很可能出现以下趋势：

• 图片 / 表格优先结构化，再进入检索
• 多模态 Agent 参与复杂分析
• RAG 与微调、工具调用深度融合

如果你正在构建多模态 RAG 系统，强烈建议：

• 不要一开始就追求“端到端多模态”
• 先把工程可控性做到位
• 把数据处理与模型能力解耦

如果你愿意，下一篇我可以继续深入：
《多模态 RAG + Agent：复杂任务如何一步步拆解执行？》