RAG检索增强生成实战

本文来源于数据从业者全栈知识库，更多体系化内容请访问知识库。

核心理念

RAG就像给AI配了一个”开卷考试”的机会——不用死记硬背所有知识，遇到问题时可以翻书找答案，然后用自己的话组织回答。

为什么需要RAG？

大语言模型 很强大，但有三个致命问题：

问题	表现	场景举例
知识过时	训练数据有截止日期	”2025年GDP增速是多少？“——答不了
幻觉问题	一本正经地编造事实	”公司差旅报销流程是什么？“——乱答
私有知识缺失	不知道企业内部信息	”我们产品A的技术参数？“——不知道

RAG的价值

RAG = 让AI在回答前先”查资料”，基于真实文档回答，大幅减少幻觉，还能回答私有知识问题。

---

一、RAG是什么？

1.1 一句话定义

RAG（Retrieval-Augmented Generation）= 检索 + 生成

先从知识库中检索相关文档，再让大模型基于检索结果生成回答。

1.2 工作流程

graph LR
    A[用户提问] --> B[问题向量化]
    B --> C[向量检索]
    C --> D[获取相关文档]
    D --> E[构造Prompt]
    E --> F[大模型生成]
    F --> G[返回答案]

    subgraph "知识库"
        H[文档切片]
        I[向量化存储]
        H --> I
        I --> C
    end

生活化比喻：图书馆管理员

想象你问图书馆管理员一个问题：

1. 理解问题：管理员听懂你要找什么
2. 检索资料：去书架上找相关的书籍（检索）
3. 阅读整理：快速翻阅，找到关键段落
4. 组织回答：用自己的话给你解答（生成）

RAG就是这个”图书馆管理员”的AI版本。

1.3 与传统方法的对比

方法	原理	优点	缺点
纯大模型	全凭记忆回答	使用简单	幻觉、过时、无私有知识
传统搜索	关键词匹配	结果准确	只返回文档，不能直接回答
模型微调	在私有数据上训练	知识内化	成本高、更新慢
RAG	检索+生成	实时、准确、低成本	依赖检索质量

---

二、RAG的核心组件

2.1 整体架构

graph TB
    subgraph "离线阶段：知识库构建"
        A[原始文档] --> B[文档解析]
        B --> C[文本切片]
        C --> D[向量化]
        D --> E[向量数据库]
    end

    subgraph "在线阶段：问答服务"
        F[用户问题] --> G[问题向量化]
        G --> H[相似度检索]
        E --> H
        H --> I[重排序]
        I --> J[Prompt构造]
        J --> K[大模型生成]
        K --> L[答案输出]
    end

2.2 核心组件详解

组件一：文档解析

把各种格式的文档转成纯文本。

文档类型	处理难度	注意事项
纯文本/Markdown	低	直接处理
PDF	中-高	扫描件需OCR，表格难提取
Word/PPT	中	注意格式丢失
网页	中	清理HTML标签、广告
数据库	中	转换为自然语言描述

组件二：文本切片（Chunking）

为什么要切片？

大模型的上下文窗口有限（如8K、32K tokens），不能把整本书都塞进去。需要切成小块，只检索最相关的部分。

常用切片策略：

策略	说明	适用场景
固定长度	每500字切一块	通用场景，实现简单
按段落	以段落为单位	文章类内容
按语义	根据话题变化切分	对话、复杂文档
递归切分	先大块，再逐级细分	层次结构明显的文档
滑动窗口	切片之间有重叠	避免关键信息被切断

切片的黄金法则

• 太大：检索不精准，上下文浪费
• 太小：信息不完整，上下文碎片化
• 推荐：300-800字/块，保持语义完整

组件三：向量化（Embedding）

把文本转换成向量（一串数字），让计算机能计算”语义相似度”。

详见 → 向量数据库与语义搜索

向量的魔力

传统关键词搜索：

• 搜”如何退款” → 只能找到包含”退款”的文档

向量语义搜索：

• 搜”如何退款” → 能找到”申请退货流程”、“订单取消步骤”等语义相关的文档

常用Embedding模型：

模型	来源	特点
text-embedding-3	OpenAI	效果好，需付费API
BGE系列	智源	中文效果优秀，开源
M3E	Moka	中文优化，开源
Cohere	Cohere	多语言支持好

组件四：向量数据库

存储向量并提供高效检索。

数据库	特点	适用场景
Milvus	分布式、高性能、开源	大规模企业应用
Pinecone	云托管、易用	快速原型、中小规模
Chroma	轻量、易集成	开发测试、小项目
Weaviate	支持混合搜索	需要关键词+语义结合
Faiss	Facebook出品、纯库	嵌入现有系统

组件五：检索与重排序

graph LR
    A[用户问题] --> B[初步检索<br/>Top 50]
    B --> C[重排序模型<br/>精排]
    C --> D[最终结果<br/>Top 5]

为什么需要重排序？

• 向量检索是”粗筛”，追求召回率
• 重排序是”精筛”，提高相关性
• 两阶段可以在效率和准确性间取得平衡

---

三、RAG的核心挑战

3.1 检索质量问题

检索是RAG的命门

如果检索不到正确的文档，再强的大模型也答不对。

常见检索问题：

问题	表现	解决方案
语义鸿沟	问题和文档表述不同	查询扩展、多路召回
信息分散	答案散落在多个文档	多跳检索、知识图谱
噪声干扰	检索到不相关内容	重排序、相关性过滤
切片不当	关键信息被切断	优化切片策略

3.2 上下文窗口限制

问题：检索到太多相关文档，但上下文放不下

解决策略：

策略	说明
精选Top-K	只取最相关的3-5个切片
摘要压缩	先对检索结果做摘要
分层检索	先文档级，再段落级
使用长上下文模型	如Kimi、Claude 200K

3.3 答案质量问题

问题	原因	解决方案
答非所问	Prompt设计问题	优化Prompt模板
信息遗漏	检索不全	多路召回、查询扩展
自相矛盾	检索到冲突信息	添加来源标注、冲突检测
过度依赖检索	该用常识时也在检索	混合策略

---

四、RAG最佳实践

4.1 文档预处理最佳实践

数据质量决定RAG上限

预处理清单：

• 去除无关内容（页眉页脚、广告、导航）
• 统一格式（标点、空格、换行）
• 保留结构信息（标题、层级）
• 提取元数据（作者、日期、来源）
• 处理特殊内容（表格→文字描述、图片→OCR/描述）

4.2 切片策略最佳实践

graph TD
    A[选择切片策略] --> B{文档类型}
    B -->|技术文档| C[按章节切分<br/>保留层级关系]
    B -->|对话记录| D[按对话轮次<br/>保持完整性]
    B -->|新闻文章| E[按段落切分<br/>首段单独处理]
    B -->|FAQ| F[问答对为单位<br/>不切分]
    B -->|长文档| G[递归切分<br/>父子关联]

4.3 检索优化最佳实践

多路召回策略：

召回方式	原理	擅长场景
向量召回	语义相似	”怎么退货”找到”退款流程”
关键词召回	精确匹配	专有名词、编号
知识图谱召回	关系推理	实体关联查询

推荐组合

混合检索 = 向量召回 + BM25关键词召回 + 重排序

这是2025年企业RAG的主流方案，兼顾语义理解和精确匹配。

4.4 Prompt设计最佳实践

详见 → Prompt Engineering

RAG专用Prompt模板要点：

要素	说明	示例
角色设定	定义AI身份	”你是XX公司的智能客服助手”
任务说明	明确回答方式	”基于以下文档内容回答用户问题”
文档引用	插入检索结果	”{context}“
兜底策略	无答案时怎么办	”如果文档中没有相关信息，请说明”
来源标注	要求引用出处	”请在回答后标注信息来源”

---

五、RAG的进阶技术

5.1 查询改写与扩展

用户的问题往往不够”好”

通过改写优化检索效果

常用技术：

技术	说明	示例
HyDE	先让LLM生成假设答案，用答案去检索	问：“GDP是什么”→生成：“GDP是国内生产总值…”→用这段话检索
查询扩展	生成多个相关查询	”退款流程”→“退货流程”、“取消订单”、“申请退款”
子问题分解	复杂问题拆成简单问题	”对比A和B的优缺点”→“A的优点”+“A的缺点”+“B的优点”+…

5.2 多跳推理

当答案需要整合多个文档的信息时：

graph TD
    A[用户问题：张三的上司是哪个部门的？] --> B[第一跳检索]
    B --> C[找到：张三的上司是李四]
    C --> D[第二跳检索]
    D --> E[找到：李四属于销售部]
    E --> F[综合回答：张三的上司在销售部]

5.3 RAG + 知识图谱

graph LR
    A[用户问题] --> B[实体识别]
    B --> C[知识图谱查询]
    C --> D[获取关联实体]
    D --> E[向量检索扩展]
    E --> F[生成答案]

什么时候需要知识图谱？

• 需要多实体关系推理
• 有明确的实体和关系结构
• 需要精确的事实性问答

5.4 自适应RAG

根据问题类型动态决定是否检索：

问题类型	是否需要RAG	理由
”1+1等于几”	否	常识问题，LLM直接答
”公司年假政策”	是	私有知识，必须检索
”写一首诗”	否	创意任务，不需检索
”解释区块链”	可选	通用知识，检索可增强

---

六、RAG应用场景

6.1 企业知识库问答

graph LR
    A[员工提问] --> B[RAG系统]
    B --> C[内部文档库]
    C --> D[返回答案+来源]

    subgraph "文档来源"
        E[规章制度]
        F[产品手册]
        G[FAQ文档]
        H[历史工单]
    end

典型场景：

• HR政策咨询：“年假怎么算？”
• IT支持：“VPN连不上怎么办？”
• 销售支持：“产品A和B的区别？“

6.2 智能客服

传统客服	RAG客服
关键词匹配FAQ	理解用户意图，语义匹配
答案生硬固定	自然语言组织回答
处理不了复杂问题	多轮对话，追问澄清
更新维护成本高	文档更新即生效

6.3 专业领域助手

领域	知识库内容	应用价值
法律	法规、判例、合同模板	法规查询、合同审核
医疗	指南、病例、药品说明	辅助诊断、用药参考
金融	研报、财报、监管文件	投研分析、合规检查
教育	教材、习题、知识点	智能答疑、个性化辅导

6.4 代码助手

graph LR
    A[开发者提问] --> B[RAG系统]
    B --> C[代码库]
    B --> D[技术文档]
    B --> E[内部Wiki]
    C --> F[返回相关代码示例+解释]

---

七、RAG评估指标

7.1 检索评估

指标	含义	计算方式
召回率	相关文档被检索到的比例	检索到的相关文档 / 全部相关文档
准确率	检索结果中相关文档的比例	相关文档 / 检索到的文档
MRR	第一个正确结果的排名	1 / 正确结果的排名
NDCG	考虑排名的综合指标	考虑相关性和位置

7.2 生成评估

指标	含义	评估方法
准确性	答案是否正确	人工评估/事实核查
相关性	是否回答了问题	人工评估/LLM评估
完整性	是否覆盖关键信息	对照标准答案
流畅性	语言是否通顺	自动指标+人工
忠实度	是否基于检索内容	检查是否有编造

7.3 端到端评估

graph TD
    A[RAG系统评估] --> B[自动评估]
    A --> C[人工评估]
    A --> D[在线评估]

    B --> B1[Rouge/BLEU等指标]
    B --> B2[LLM-as-Judge]

    C --> C1[标注团队评分]
    C --> C2[用户满意度调研]

    D --> D1[点击率]
    D --> D2[采纳率]
    D --> D3[追问率]

---

八、RAG vs 微调：如何选择？

维度	RAG	微调
知识更新	实时（更新文档即可）	需要重新训练
成本	低（只需向量化）	高（GPU训练）
可解释性	高（可追溯来源）	低（黑盒）
幻觉控制	好（基于真实文档）	一般
专业术语	一般	好（学习领域表达）
推理速度	稍慢（需检索）	快

选择建议

优先RAG：

• 知识经常更新
• 需要追溯信息来源
• 预算有限
• 快速上线需求

考虑微调：

• 需要特定领域的表达风格
• 固定的专业术语
• 对响应速度要求极高

最佳实践：RAG + 轻量微调结合

---

九、本章小结

核心要点回顾

1. RAG本质：检索 + 生成，让AI”开卷考试”
2. 核心组件：文档解析、切片、向量化、检索、生成
3. 关键挑战：检索质量、上下文限制、答案质量
4. 最佳实践：混合检索、查询改写、Prompt优化
5. 应用场景：知识库问答、智能客服、专业助手

金句

“RAG不是让AI更聪明，而是让AI更诚实——基于事实回答，而不是凭空编造。“

---

学习路径

graph LR
    A[本文：RAG概述] --> B[向量数据库]
    B --> C[实际项目实践]
    C --> D[Agent整合]

推荐下一步：

• 向量数据库 - RAG的核心基础设施
• AI Agent - 更复杂的AI应用架构
• Prompt工程 - 优化RAG的生成质量

---

延伸阅读

• 大语言模型 - 理解RAG中的生成部分
• 深度学习基础 - 理解Embedding原理
• MLOps - RAG系统的工程化部署

---

本文节选自数据从业者全栈知识库。知识库包含 2300+ 篇体系化技术文档，覆盖数据分析、数据工程、数据治理、AI 等全栈领域。了解更多 →