【AI应用开发】 RAG篇（一）：概述与核心架构
前言
现在大模型落地业务，90% 的企业场景都会优先上 RAG（检索增强生成）。不管是知识库问答、智能客服还是私有文档助手，RAG 都是绕不开的核心方案。
本文作为系列第一篇，通俗易懂讲清：什么是 RAG、为什么必须用 RAG、完整双阶段架构流程。新手程序员看完就能搭建最简 RAG Demo。
目录
- [什么是 RAG](#什么是 RAG)
- 1.1 基础定义
- 1.2 RAG 解决大模型三大原生痛点
- [为什么要用 RAG](#为什么要用 RAG)
- 2.1 两种给大模型注入新知识的方案：微调 vs RAG
- 2.2 RAG 主流落地场景
- [RAG 的核心完整架构](#RAG 的核心完整架构)
- 3.1 阶段一：离线索引阶段（数据预处理入库）
- 3.2 阶段二：在线查询阶段（用户实时问答）
- 3.3 RAG 核心底层逻辑：Embedding 语义对齐
1. 什么是 RAG
1.1 基础定义
RAG（Retrieval-Augmented Generation，检索增强生成）
简单说：大模型回答用户问题前，先去外部私有知识库检索相关原文，再拿着检索到的真实资料生成答案，而非仅依靠模型自身训练记忆。
生活化比喻，快速理解
我们可以把整套系统拆成三个角色，很好理解：
| 角色 | 对应组件 | 职责 |
|---|---|---|
| 用户 | 提问方 | 提出业务问题的员工 / 客户 |
| 检索器（Retriever） | 资料库管理员 | 在海量文档里快速筛选相关片段 |
| LLM 大模型 | 领域专家 | 只记住训练数据的专家，需要管理员提供资料才能准确作答 |
1.2 RAG 解决大模型三大原生痛点
原生大模型存在无法规避的短板，RAG 针对性解决：
| 问题 | 具体表现 | RAG 解决方案 |
|---|---|---|
| 知识截止问题 | 模型训练数据固定，无法获取最新业务、实时资讯 | 知识库可随时新增 / 更新文档，检索实时生效 |
| 模型幻觉 | 遇到陌生知识凭空编造虚假内容，误导业务 | 生成答案强制绑定检索原文，有据可溯源，大幅降低胡说 |
| 私有领域知识缺失 | 企业内部文档、行业专业内容不在训练数据内 | 自有文档向量化入库，推理时调取内部资料 |
三个痛点的本质是同一个问题：大模型的"记忆"是训练时固化的，无法动态获取外部信息。RAG 给大模型装了一个"搜索引擎"，让它回答问题前先查资料，从根本上改变了模型的运作方式。
2. 为什么要用 RAG
2.1 两种给大模型注入新知识的方案：微调 vs RAG
想要让大模型掌握企业私有知识，行业只有两条主流路线，两者互补而非对立：
| 对比维度 | 微调（Fine-tuning） | RAG（检索增强） |
|---|---|---|
| 底层原理 | 训练更新模型权重，永久修改模型认知 | 不改动模型权重，推理阶段动态注入外部文档 |
| 知识更新成本 | 新增文档需重新训练，耗时耗算力 | 文档上传入库即可生效，实时更新 |
| 答案溯源能力 | 无法定位回答来源，难以校验真实性 | 每条回答可绑定对应原始文档段落，方便审计 |
| 硬件成本 | 需要高显存 GPU，训练成本高 | 仅推理算力，向量库开销低，中小企业友好 |
| 适用场景 | 统一输出格式、优化对话风格、统一语气 | 事实类问答、动态知识库、频繁更新文档场景 |
工程最佳实践
两者组合使用，而非二选一：
- RAG 负责提供真实业务知识，确保答案准确
- 微调 统一模型输出规范、对话风格，让回答更符合业务调性
实际落地顺序：先上 RAG 解决"能不能答对"的问题，再考虑微调优化"答得好不好看"。
2.2 RAG 主流落地场景
| 场景 | 说明 | 典型例子 |
|---|---|---|
| 企业内部知识库问答 | 员工查询制度、文档、规范 | 人事制度、产品接口文档、技术规范 |
| 行业智能客服 | 匹配产品手册、FAQ、历史工单 | 电商售后、金融咨询、运营商客服 |
| 专业辅助系统 | 法条/病例/政策检索辅助决策 | 法律法条检索、医疗病例辅助、政务政策问答 |
| 科研写作助手 | 检索论文文献辅助写作 | 撰写综述、实验报告、文献调研 |
| 个人知识库 | 本地笔记、文档私有问答 | 个人笔记检索、学习资料问答 |
这些场景的共同特点是：知识量大、更新频繁、对准确性要求高------恰好是 RAG 最擅长的领域。
3. RAG 的核心完整架构
整套 RAG 系统分为两大独立流程：
- 离线索引构建阶段：一次性或定时执行，把文档处理好存起来
- 在线查询问答阶段：用户实时请求，检索 + 生成同步完成
3.1 阶段一：离线索引阶段（数据预处理入库）
作用：把企业海量原始文档，处理成向量数据库可检索的数据。离线提前执行，不占用线上问答耗时。
流程链路
原始文档 → 文档解析 → 文本切分 (Chunking) → Embedding 向量化 → 存入向量数据库
分步拆解
① 文档解析
- 解析 PDF、Word、Markdown、HTML 等多种格式文件
- 提取纯文本内容
- 过滤水印、空白行、无效页眉页脚、乱码字符
这一层的质量直接决定后续所有的效果------垃圾进，垃圾出。建议根据实际文档格式选用专业的解析库（PyPDF2、python-docx、Unstructured 等），必要时针对企业特有格式做定制解析。
② 文本切分（Chunking）
- 将超长文档拆分为固定长度的文本块（Chunk）
- Chunk 是检索的最小单元，每个 Chunk 独立被检索和召回
- Chunk 长度直接影响召回效果------太长引入噪声，太短丢失上下文
切分策略的选择将在第三篇《文档切分与多路检索》中详细展开，包括固定长度、语义切分、递归切分等多种方案。
③ Embedding 向量化
- 使用嵌入模型，将每一段 Chunk 文本转为低维数字向量（通常 768 或 1536 维）
- 核心原理：语义相近的文本，在向量空间中距离更近
- 同一套系统必须使用同一个 Embedding 模型
python
# 概念示意（非完整代码）
chunk_text = "年假申请需要提前三个工作日提交..."
vector = embedding_model.encode(chunk_text)
# 结果: [0.023, -0.451, 0.891, ..., 0.132] ← 1536 维向量④ 向量入库
- 向量 + 对应原文 + 元数据（文档名称、页码、分类、更新时间）一并存入
- 向量数据库负责持久化存储和高效相似度检索
- 元数据留作后续过滤条件（如"只检索技术文档"）
3.2 阶段二：在线查询阶段（用户实时问答）
用户发起提问后，实时执行检索 + 生成，完整链路：
用户提问 → 查询处理 → Query向量化 → 向量库相似度检索 TopK → (Re-rank重排) → 拼接Prompt → LLM生成回答
分步讲解
① 查询处理（Query Processing）
可选但强烈推荐的优化步骤，直接决定了检索质量的上限：
- 清洗口语化问题：用户输入"那个什么，就是上次说的请假怎么搞来着？"→ 清洗为"请假申请流程"
- 多意图拆分："年假怎么申请？病假需要什么材料？" → 拆分为两个独立查询分别检索
- 同义扩展：为关键词补充同义词，提升召回覆盖面
- 指代消解：多轮对话中，"它有什么限制？" → 补全为"年假申请有什么限制？"
② Query Embedding
- 和离线阶段使用同一个嵌入模型，保证向量空间一致
- 将用户问题转为与文档 chunk 相同的向量格式
③ 向量相似度检索
- 在向量库中计算距离（余弦相似度、欧氏距离等）
- 召回相似度最高的 Top-K 个文本块
- K 值选择需要权衡：太小丢信息，太大引入噪声。典型范围 3~10
④ 【进阶优化】Re-rank 重排序
- 对粗召回的 K 个候选片段进行精细化二次打分
- 使用更强但更慢的重排序模型（如 Cohere Rerank、BGE-Reranker）
- 过滤无关内容，最终只保留最相关的 3~5 个片段送入 LLM
- 效果提升显著：相同召回基础下，重排后答案准确率可提升 10%~30%
Re-rank 是 RAG 系统从"能用"到"好用"的关键跨越，第四篇将详细展开。
⑤ Prompt 构造
将用户原始问题 + 筛选后的高质量文档片段拼接成提示词：
基于以下参考资料回答用户问题：
【参考资料 1】（来源：员工手册-第3章，第2页）
年假申请需提前三个工作日提交OA系统，经直属上级审批...
【参考资料 2】（来源：考勤制度-请假章节，第5页）
年假天数按工龄计算：1-10年5天，10-20年10天...
【用户问题】
公司年假怎么申请？我能休几天？
请基于上述资料回答，注明引用来源。如资料不足，明确说明。⑥ LLM 生成答案
- 大模型仅基于提供的检索文档作答
- 输出完整回答，附带原文引用来源
- 如果资料不足，模型应诚实说明"依据现有资料无法回答"，而非编造
3.3 RAG 核心底层逻辑：Embedding 语义对齐
整套检索能生效的根本，在于 Embedding 模型的语义编码能力：
| 情况 | 说明 | 举例 |
|---|---|---|
| 语义相近，表达不同 | 向量空间距离近，能被检索匹配 | "如何申请公司年假" 和 "年假申请流程是什么" → 向量高度相似 |
| 语义无关 | 向量距离很远，不会被误召回 | "年假申请" 和 "办公电脑维修流程" → 向量差距大，不会匹配 |
这个"语义相近 → 向量相近"的数学性质，是整个 RAG 检索能力的物理基础。Embedding 模型的质量，决定了 RAG 系统的检索天花板。
下一篇将深入拆解：向量相似度到底怎么算？有哪些高效的近似检索算法？7 款主流向量数据库怎么选？Embedding 模型怎么评估？敬请期待《Embedding 与向量数据库》。
本篇小结
| 知识点 | 一句话总结 |
|---|---|
| RAG 是什么 | 先检索外部文档，再基于文档生成答案 |
| 解决什么问题 | 知识截止、模型幻觉、私有知识缺失 |
| RAG vs 微调 | RAG 管"答得准"，微调管"答得好看"，组合使用 |
| 离线阶段 | 文档 → 切分 → 向量化 → 入库，提前执行 |
| 在线阶段 | 提问 → 向量检索 → 重排 → 拼 Prompt → LLM 回答 |
| 底层原理 | Embedding 把语义相近的文本映射到相近的向量 |
下一篇将深入 Embedding 与向量数据库，从数学原理到工程选型一次讲透。
下一篇文章 ：第二篇《Embedding 与向量数据库》 --- 深入讲解向量相似度计算、ANN 近似检索算法、主流向量库选型对比、Embedding 模型选择标准。