用 RAG 撬开多模态检索：从文本问答到以图搜图与视频筛选

原创已于 2025-12-15 13:27:26 修改 · 509 阅读

18 ·

CC 4.0 BY-SA版权

文章标签：

#多模态 #RAG #以图搜图 #视频筛选 #混合检索

于 2025-12-15 13:20:53 首次发布

用 RAG 撬开多模态检索：从文本问答到以图搜图与视频筛选

如果你以为 RAG 只是“把文档切块塞进向量库，然后用大模型回答”，那你可能正陷在检索不准、回答幻觉、多模态无解的泥潭里。真正的 RAG，是一套精密的检索-生成流水线，它能处理的不止是文本，还有海量的图片与视频。

🧠 一、RAG 到底是什么？

1. 为什么 90% 的 RAG Demo 都在裸奔？

很多开发者上手 RAG（Retrieval-Augmented Generation，检索增强生成）的第一反应是：

装个 LangChain / LlamaIndex
把 PDF 切成 chunk
扔进向量库（Vector DB）
坐等大模型回答完美答案

结果往往是惨烈的：

用户问“2023年Q1营收”，模型答非所问，因为财务报表的表头和具体数值被切分到了不同片段（Chunk），导致上下文关联丢失。
用户搜索“红色长裙设计图”，系统无法召回，因为仅构建了文本索引，缺失了对图像的多模态向量化处理，导致“文搜图”功能失效。
模型生成了看似专业的结论，但无法提供具体的文档出处和页码引用（Citation），导致回答缺乏可解释性，难以验证真伪。

真正的 RAG，不是简单的工具堆砌，而是一套把「外部证据」强力注入「生成过程」的工程系统。

2. 一句话重新定义 RAG

先检索出最确凿的“证据”（Evidence），再让模型基于证据进行“回答”（Generation），并必须给出“证据出处”（Reference）。

在这个过程中：

大模型：是大脑，负责理解意图、组织语言、逻辑推理。
检索系统：是眼睛和耳朵，负责在海量数据（文档、图片、视频）中找到最新、最权威的真相。
核心目标：消灭幻觉，让每一个回答都可追溯。

3. 为什么 RAG 是大模型的必修课？

大模型再强，也有三个死穴，而 RAG 就是解药：

“由于训练截止日期…”：大模型不知道今天的新闻，但 RAG 知道。
“这是公司机密…”：大模型没看过你公司的合同、代码和产品手册，但 RAG 可以挂载私有知识库。
“我猜…”：大模型喜欢一本正经胡说八道，但 RAG 强迫它看着证据说话。

4. 视野打开：RAG 的目标不止是文本

RAG 的“R（Retrieval）”如果只局限于文本，那就太浪费了。只要能把数据编码成向量（Embedding），万物皆可 RAG：

📄 文本 RAG：FAQ、合同、代码、工单（最基础）。
🖼️ 图片 RAG：以文搜图、以图搜图（电商找同款、版权检测）。
🎥 视频 RAG：从海量监控中搜“红色车辆闯红灯”、从电影库中搜“那个爆炸的镜头”（多模态检索的深水区）。
🔊 音频 RAG：声纹识别、会议纪要关键词定位。

关键技术：CLIP（Contrastive Language-Image Pre-training）这类图文对齐模型，打破了模态的次元壁，让“文字”和“图像”能在同一个数学空间里对话。

🧩 二、RAG 的本质原理：一条精密的工业流水线

别再把 RAG 看作一个黑盒。在工程落地时，我们必须把它拆解为 离线建库（Indexing） 与 在线问答（Serving） 两条严密的生产链路。

✓ 1) 离线链路：把业务知识变成“可检索证据”

1.1 数据接入与解析（Parsing）—— 垃圾进，垃圾出

常见数据源：

文档：PDF、Word、HTML、Wiki、Markdown
结构化：MySQL/ES/数据仓库（通常要先转成“可读片段”）
多模态：图片、视频（抽帧/关键帧/镜头切分）

工程深水区：

PDF/扫描件：如果你直接提取文本，表格和段落会乱成一团。必须做版面结构还原（识别标题层级、表格、段落）。
保留引用锚点：必须记录页码、段落号、URL、文档ID。否则生成时无法告诉用户“答案在第几页”。
权限信息入元数据：部门/角色/租户ID。检索时必须带上 ACL，否则实习生也能查到 CEO 的工资条。

1.2 切分与组织（Chunking）—— 切得好，检索才准

Chunk 不是越小越好，也不是越大越好。工程上常用三层策略：

结构切分：按标题/小节/列表/表格分块（优先，保留语义完整性）。
滑窗切分：比如 300–800 tokens，overlap 10%–20%（兜底策略，防止切断句子）。
语义切分：按句向量相似度/主题边界切段（效果最稳但计算成本高）。

高阶技巧：建议同时存两份内容：

chunk_text：原始切片，用于检索与拼 prompt。
chunk_summary：切片摘要，用于“长文压缩检索”（做多级检索/分层索引）。

1.3 表示学习（Embedding）—— 万物皆向量

Embedding 的作用是：把“查询”和“证据”投射到同一个数学空间，让语义相似的东西靠得更近。

文本：BGE/GTE/E5 等（中文场景务必优先看 C-MTEB 榜单）。
图片：CLIP/ViT 系列（图文同空间）。
视频：抽帧后用图像 Embedding；或用 VideoMAE 等专用模型生成片段向量（成本更高）。

1.4 检索索引（Index）—— 向量库只是配角

这里才轮到“向量库/向量索引”登场，但请把它看成 RAG 的一个零件，而不是全部。

向量检索常用 ANN（近似最近邻）索引；例如 HNSW 通过分层小世界图提升高维近邻搜索效率。

工程铁律：永远不要只用向量检索。通常是两路索引并存：

稀疏/关键词检索：BM25（适合专有名词、产品型号、错误代码）。
稠密/向量检索：Embedding + ANN（适合语义改写、同义表达、跨语言）。

再通过混合检索（Hybrid Search）把两路结果融合。Elastic 的实践中常见融合策略包括加权融合与 RRF（Reciprocal Rank Fusion）。

✓ 2) 在线链路：从“问一句”到“带证据的回答”

2.1 Query 预处理（决定你检索到什么）

永远不要直接把用户的原始问题扔给检索器。

常见增强手段：

Query 改写：把口语问题“它为什么报错”改成检索友好表达“App启动时出现 Error 500 的原因”（补全实体、消歧义）。
意图识别：是查制度？查订单？查图片相似？查视频片段？
结构化过滤生成：从问题里抽取时间、产品线、地区、角色 → 转化为 metadata filter。

经验：过滤条件越明确，检索范围越小，噪声越少；噪声越少，模型越不容易“胡说”。

2.2 一阶段召回：混合检索（Sparse + Dense）

你会经常遇到这样的“互补现象”：

“A-10023 订单为什么被风控拦截？” → BM25 完胜（精准匹配编号）。
“这个用户像不像之前那批羊毛党？” → 向量完胜（匹配语义模式）。

BEIR 基准测试的结论之一是：BM25 依然是强健的 baseline，跨域零样本时往往很能打；而更复杂的模型（重排/late-interaction）常能带来更高效果但计算更贵。

2.3 二阶段精排：Rerank（把“相关”变成“真的很相关”）

这是提升 RAG 效果性价比最高的手段。

常见做法：

Cross-Encoder 重排序：把 (Query, Passage) 拼一起交给模型打分，相关性极准，但速度慢。
规则重排：加入新鲜度、权威度、点击率、业务优先级加权。
去重与多样性：避免 topK 都来自同一页同一段，保证信息丰富度。

Elastic 的检索体系也明确把“先召回候选，再进入更昂贵的重排序”作为典型流水线思路。

2.4 生成（Generation）：把证据组织成“可验证输出”

生成阶段的关键不在“写得文采飞扬”，而在“写得严谨可控”：

上下文拼接策略：按 Rerank 分数拼、按文档分组拼、按时间衰减拼。
引用输出格式：例如 [doc_id#chunk_id] 或 (链接/页码)。
拒答与澄清：证据不足时，优先追问或拒答（防止幻觉）。

✓ 3) 一张图看全流程（文本 + 多模态统一视角）

🔧 三、RAG 与传统搜索/传统问答的区别（不只是“多了个向量库”）

1) 对比一：传统关键词搜索 vs RAG（搜索→阅读→总结自动化）

维度	传统搜索（Search）	RAG（Search + Generate）
目标	找到相关文档	直接产出可用答案（并给证据）
交互	用户自己阅读、拼结论	系统自动综合多段证据生成
召回优势	专名词、编号、短语匹配强	语义泛化强（同义、改写、多语言）
风险	信息过载、读错、漏读	检索错→生成错（需要评估/防护）
评估	nDCG/Recall 等检索指标	检索指标 + 事实一致性/引用命中率

不要轻视 BM25；工程上更常见的解是 Hybrid + Rerank，而不是“只做向量检索”。

2) 对比二：传统知识库问答（FAQ/规则） vs RAG（覆盖长尾与多文档综合）

FAQ/规则引擎：对高频标准问题很好，但对长尾、组合问题、跨文档推理吃力
RAG：擅长“从多个来源抽证据→整合解释”，尤其是：
- 新制度刚更新、FAQ 还没维护
- 用户描述很口语、关键词不明显
- 需要“给原因 + 给步骤 + 给引用”

3) 对比三：只做“向量库语义检索” vs 真正的 RAG

只做向量检索通常只解决“找得到”，但不保证“答得对”。真正的 RAG 还需要：

Query 改写 / 过滤
混合召回
重排序
引用与拒答策略
端到端评估与监控

向量库重要，但它只是检索层的一种实现，不等价于 RAG。

🚀 四、端到端业务案例：从文本到多模态

🎯 1) 企业知识助手（客服/制度/研发支持）

场景痛点

内部文档多、版本多、更新快
新人上手慢、问答重复
合规要求：回答必须可追溯（引用到制度条款）

方案架构（文本 RAG）

数据源：制度/产品手册/FAQ/工单
检索：Hybrid（BM25 + 向量）+ Rerank
生成：强制引用 + 不足则追问/拒答
权限：检索前过滤（tenant/role/department）

关键实现细节

Chunk 绑定“制度条款号/页码”，引用输出直接落到条款
增量更新：只重建变更文档的索引（避免全量重算）
答案结构化：结论/依据/操作步骤/例外情况/引用

评估指标（建议落地就做）

检索：Recall@K、nDCG@K、Coverage（命中正确文档比例）
生成：引用命中率（答案中每条结论是否能在证据中找到）、拒答正确率
业务：一次解决率、平均处理时长、转人工率

🎯 2) 客服自动化（RAG + 工单系统 + 质检闭环）

场景痛点

客服问题高度依赖内部知识与历史工单
纯生成容易“看起来很像，但不一定对”
需要可控的降本增效，而不是“盲目用 AI”

方案设计（端到端）

检索：从知识库 + 历史工单召回候选（按产品线/地区/版本过滤）
生成：输出“建议答复 + 操作步骤 + 引用”
工具调用（可选）：查询订单状态、退款规则、物流节点
质检与学习：把转人工、差评、二次咨询作为 hard negative 回流重排模型/检索策略

🎯 3) 电商「以图搜图 + 商品问答」：多模态 RAG

目标

用户拍一张图：

先找相似商品（检索）
再回答“这是什么、适合谁、替代款、差异点”（生成）

多模态检索关键：CLIP 向量空间

CLIP 通过大规模图文对训练，把图片与文本投到同一语义空间，使“图片→文本/文本→图片”的相似度检索成为可能。

解决方案架构

图片 → Image Embedding → TopK 相似商品
同时对 Query 文本做 Embedding（如果用户还补充描述）
Hybrid 融合：图向量召回 + 文本 BM25（商品标题/品牌/型号）
Rerank：加入“价格区间/类目/库存/地区”等业务规则
生成：让模型基于商品结构化信息（参数、材质、尺码、评价摘要）输出对比与推荐理由，并引用商品页/参数表

典型输出模板

相似Top3：相似点/不同点/适用人群/注意事项
替代方案：更便宜/更耐用/更轻薄
引用：商品ID/参数字段/评价摘要来源

🎯 4) 视频长尾样本筛选：从“检索片段”到“生成报告”

场景

自动驾驶/安防/质检常见需求：

从海量视频中找“某类稀有事件/特定物体/特定动作”
找到后还要：生成可读报告（时间点、片段摘要、证据截图/帧号）

方案设计

视频预处理：镜头切分/抽关键帧/按时间窗生成片段
Embedding：
- 图像路线：关键帧 → CLIP Embedding（成本可控）
检索：
- 文本 Query（“夜间施工锥桶+紧急变道”）→ Text Embedding → 找相似片段
- 过滤：天气/路段/车型/摄像头位
生成：
- 把 TopN 片段的元数据 + 帧描述（可选先 caption）喂给模型
- 输出：事件摘要、发生时刻、相似案例、建议标注标签
- 引用：视频ID/时间戳/帧号