Day 15：RAG 原理与架构

学习目标

今天是 Week 3 的第一天。前两周我们学了 API 调用、Prompt 工程和结构化输出，这些能力让大模型可以按照我们的要求工作。但有一个根本性的限制始终没有解决：大模型的知识是静态的，它只知道训练数据截止日期之前的内容，对企业的私有数据一无所知。

RAG（Retrieval-Augmented Generation，检索增强生成）就是解决这个问题的核心方案。今天的目标不是写代码，而是彻底搞清楚 RAG 是什么、为什么需要它、它怎么工作、它的边界在哪里。只有把这些底层逻辑理顺了，后面六天的文档解析、切分、向量化、检索优化才有意义。

学完今天的内容，你应该能用白板给一个非技术人员讲清楚：为什么企业不能直接把文档丢给 ChatGPT，而需要一套专门的系统来做知识库问答。

核心概念

一、RAG 的定义

RAG 全称 Retrieval-Augmented Generation，中文翻译是”检索增强生成”。拆开来看：

Retrieval（检索）：根据用户的问题，从外部知识库中找到相关的文档片段
Augmented（增强）：把检索到的内容作为额外上下文，拼接到 Prompt 中
Generation（生成）：大模型基于增强后的上下文来生成回答

用一句话概括：先搜后答。不是让大模型凭记忆回答，而是先从你的文档里找到相关内容，再让模型基于这些内容来回答。

这个思路并不新鲜。你可以把它类比为开卷考试：闭卷考试靠记忆答题（普通大模型对话），开卷考试可以翻资料答题（RAG）。没有人会否认，开卷考试在回答事实性问题时准确率高得多。

RAG 最早由 Meta（当时的 Facebook AI Research）在 2020 年的一篇论文中正式提出。原始论文探讨的是将预训练的检索器与生成模型联合训练的方法。但今天工业界说的 RAG 已经泛化了，指的是一切”先检索外部知识、再让模型生成”的模式，不一定要端到端联合训练。

二、RAG 解决什么问题

要理解 RAG 的价值，先得搞清楚大模型本身有哪些缺陷：

第一，知识过时。 大模型的知识停留在训练数据的截止日期。你问它”2024 年公司最新的退货政策是什么”，它不可能知道。即便是最强的模型，也无法回答训练之后发生的事情。

第二，缺乏私有知识。 大模型是在公开数据上训练的。你企业的内部文档、产品手册、客户合同、技术规范，它一概不知。你让它回答”我们公司的差旅报销标准是什么”，它会老老实实说不知道，或者更糟——编一个看起来合理的答案。

第三，幻觉问题。 这是大模型最令人头疼的缺陷。当它不知道答案但又想给出一个回答时，它倾向于生成一段看起来非常专业、逻辑通顺、但实际上完全错误的内容。这种”一本正经地胡说八道”在医疗、法律、金融等领域是致命的。

第四，无法引用来源。 即便大模型碰巧给出了正确答案，你也无法验证这个答案的出处。在企业场景中，“答案对不对”和”答案从哪里来的”同样重要。

RAG 针对的就是这四个问题。通过检索外部知识库，它让大模型可以回答训练数据之外的问题（解决过时和私有知识问题），让回答有据可依（减少幻觉），并且可以附带引用来源（可追溯）。

但要注意：RAG 不是银弹。它减少了幻觉，但没完全消灭幻觉。如果检索到的内容本身就有问题，或者模型在生成时偏离了检索到的内容，幻觉仍然会发生。这一点后面讲局限的时候会展开。

三、RAG 的标准流程

一个典型的 RAG 系统包含两个大阶段：离线阶段（Indexing）和在线阶段（Querying）。

离线阶段——把文档准备好：

文档加载：把各种格式的文档（PDF、Word、Excel、HTML、Markdown 等）读进来
文档解析：提取文档中的文本内容，保留结构信息（标题、段落、表格）
文本清洗：去掉页眉页脚、水印、乱码、无意义的格式字符
文本切分（Chunking）：把长文档切成适当大小的片段
向量化（Embedding）：把每个文本片段转换成数值向量
存储：把向量和对应的原始文本存入向量数据库

在线阶段——回答用户问题：

用户提问：接收用户的问题
问题向量化：用同一个 Embedding 模型把问题也转换成向量
向量检索：在向量数据库中找到与问题最相似的 top-k 个文档片段
上下文拼接：把检索到的文档片段组装成 Prompt 上下文
答案生成：大模型基于上下文和问题生成回答
引用标注：标注答案引用了哪些文档的哪些片段

这个流程看起来不复杂，但每个环节都有大量细节和优化空间。接下来的六天我们会逐个深入。今天只需要在脑中建立起这个端到端的全景图。

四、RAG 与普通问答的区别

普通的大模型问答（也就是 Week 1-2 我们做的事情）和 RAG 问答有什么本质区别？

普通问答的流程： 用户提问 → Prompt 组装 → 大模型直接生成回答

RAG 问答的流程： 用户提问 → 检索相关文档 → 增强后的 Prompt → 大模型基于文档生成回答

区别就在于中间多了一个”检索”环节。这个环节引入了外部知识，让模型的回答从”凭记忆答题”变成了”参考开卷资料答题”。

从工程角度看，这个区别带来了几个重大变化：

系统复杂度增加了。 你不再只需要一个模型调用接口，而是需要文档处理管线、向量数据库、检索服务、以及把这一切串起来的编排逻辑。RAG 系统的模块数量比普通问答系统多了好几倍。

评估维度变了。 普通问答主要看生成质量（通顺、准确、格式对），RAG 还要看检索质量（找对了没有、找全了没有）。一个 RAG 系统回答不好，可能是模型的问题，也可能是检索的问题，还可能是文档处理的问题。排错链路更长了。

运维成本增加了。 文档要持续更新，向量要重新生成，数据库要维护。这不是一次性的工作，而是持续性的工程任务。

但这些代价是值得的。 在企业场景中，没有 RAG 的大模型应用几乎无法落地。企业不可能接受一个”不知道公司政策的 AI 助手”，更不可能接受一个”编造政策的 AI 助手”。

五、RAG 的优势

知识可更新。 只需要更新知识库中的文档，不需要重新训练模型。今天公司改了政策，明天更新文档，RAG 系统就能回答新政策相关的问题。这个迭代周期是以分钟和小时计的，而不是以周和月计的。

知识可溯源。 每个回答都可以标注来自哪篇文档的哪个段落。用户不信任回答时，可以直接查看原文。在合规要求严格的行业（金融、医疗、法律），这个能力几乎是强制性的。

成本可控。 相比于微调（Fine-tuning）一个模型，RAG 的成本要低得多。微调需要 GPU 资源、标注数据、模型训练和部署，每次知识更新都要重新来一轮。RAG 只需要处理文档和更新索引，这些操作的算力需求远低于模型训练。

灵活性强。 不同部门、不同客户可以有不同的知识库，互不干扰。你可以给销售团队建一个产品知识库，给客服团队建一个工单处理知识库，给法务团队建一个合同模板知识库。同一个底层系统，不同的知识源，不同的使用场景。

幻觉降低。 有了检索到的上下文作为约束，模型更倾向于基于给定内容回答，而不是自由发挥。这不是绝对保证，但统计意义上确实显著降低了幻觉率。

六、RAG 的局限

说完了优势，必须诚实面对 RAG 的局限：

检索质量决定上限。 RAG 的天板不是模型能力，而是检索质量。如果检索不到正确的文档片段，模型再强也没用。而检索质量受太多因素影响：文档切分是否合理、Embedding 模型是否够好、用户的问题表述是否清晰、数据库中是否有对应的答案。检索失败是 RAG 系统最常见的问题。

长文档的处理难题。 一篇 50 页的技术报告，切成几十个片段分别存储后，片段之间的逻辑关系被打断了。模型可能检索到了第三章的一个片段，但缺少第二章的上下文，导致理解不准确。

多跳推理困难。 有些问题的答案需要综合多个文档的信息。比如”我们公司去年在东南亚市场的退货率和利润率分别是多少”，这个问题可能需要从财务报告和区域销售报告中分别检索信息再综合。简单的 RAG 框架处理不好这类问题。

上下文窗口的限制。 虽然现代模型的上下文窗口越来越大（从 4K 到 128K 甚至更长），但”能放进去”和”能用好”是两回事。塞入太多检索结果，模型的注意力会被稀释，回答质量反而下降。

维护成本不低。 文档需要持续更新、去重、版本管理。向量数据库需要监控和优化。Embedding 模型可能需要升级。这些都是长期的运维负担。

不适合实时数据。 RAG 的知识库是定期更新的，不是实时同步的。如果你的问题涉及到”现在”的状态（比如”这个工单当前处理到哪一步了”），RAG 不是正确的工具，你需要的是 Tool Calling 来查询实时系统。

七、企业知识库场景

RAG 最典型的落地场景就是企业知识库。具体来说，以下场景 RAG 是首选方案：

产品文档问答。 销售团队需要快速了解产品规格、定价、竞品对比。这些信息分散在数十页的产品手册中，人工翻找效率极低。RAG 可以让销售直接用自然语言提问，秒级获得答案。

内部制度查询。 大型企业有数不清的规章制度、流程规范、操作手册。新员工入职时最头疼的就是在浩如烟海的文档中找到自己需要的信息。RAG 把这些文档变成可对话的知识库，新员工可以直接问”出差到上海，住宿标准是多少”。

技术知识库。 研发团队的 API 文档、架构设计文档、故障排查手册。当工程师遇到问题时，可以在知识库中搜索类似案例和解决方案。这比在 Confluence 里一页一页翻要高效得多。

客户服务知识库。 客服团队面对客户的各种问题，需要快速找到标准答案。RAG 可以根据客户的问题描述，自动匹配最相关的知识条目，辅助客服给出准确回答。

合规与法务查询。 合规要求、法律法规解读、合同模板。法务团队可以用 RAG 快速检索相关条款，而不需要通读整个法规文件。

八、RAG 系统架构

一个完整的企业级 RAG 系统架构包含以下核心模块：

文档处理层： 负责文档的上传、解析、清洗、切分。支持多种文档格式，保留文档结构信息，输出干净的文本片段。

向量化层： 负责将文本片段转换为向量表示。选择合适的 Embedding 模型，处理批量文档的向量化任务。

存储层： 包括向量数据库（存储向量和元数据）和可能的全文索引（用于混合检索）。负责高效的向量存储和检索。

检索层： 负责接收用户查询，执行向量检索或混合检索，返回最相关的文档片段。这一层还包括查询改写、重排序等优化策略。

生成层： 负责将检索结果和用户问题组装成 Prompt，调用大模型生成回答。包括引用标注、答案格式化等后处理。

应用层： 对外的接口和服务。包括对话界面、API 接口、用户管理等。

管理层： 文档管理（上传、更新、删除）、权限控制、使用统计、系统监控。

这些模块不是孤立的，它们通过数据流和调用关系连接在一起，形成一个完整的系统。

概念关系图

下面用文字图展示 RAG 系统各组件之间的关系：

离线管线（Indexing Pipeline）
=========================================================

[原始文档]         [PDF/Word/HTML/Excel]
    |                      |
    v                      v
[文档解析器] -----> [文本内容]
    |
    v
[文本清洗] --------> [干净文本]
    |
    v
[文本切分 Chunker] -> [Chunk 1, Chunk 2, ... Chunk N]
    |
    v
[Embedding 模型] ---> [Vector 1, Vector 2, ... Vector N]
    |
    v
[向量数据库] <------+ [元数据: 来源、页码、章节]


在线管线（Query Pipeline）
=========================================================

[用户问题]
    |
    v
[问题向量化] -------> 问题向量
    |
    v
[向量检索] ---------> Top-K 相关 Chunks
    |
    v
[Prompt 组装] ------> "基于以下内容回答问题：{chunks}\n问题：{question}"
    |
    v
[LLM 生成] ---------> 回答 + 引用来源
    |
    v
[返回给用户]


RAG 系统架构全貌
=========================================================

  +------------------+     +------------------+
  |   文档管理后台    |     |    用户界面       |
  |  (上传/更新/删除) |     |  (对话/API)      |
  +--------+---------+     +--------+---------+
           |                        |
           v                        v
  +------------------+     +------------------+
  |  文档处理服务     |     |    检索服务       |
  |  解析/清洗/切分   |     |  向量检索/混合    |
  +--------+---------+     +--------+---------+
           |                        |
           v                        v
  +------------------+     +------------------+
  |  Embedding 服务   |     |    生成服务       |
  |  文本转向量       |     |  Prompt/LLM/引用  |
  +--------+---------+     +--------+---------+
           |                        |
           v                        v
  +------------------+     +------------------+
  |   向量数据库      |     |    LLM API       |
  |  存储/索引/检索   |     |  模型调用         |
  +------------------+     +------------------+

实战分析

今天的实战任务不涉及代码，而是用纸笔或绘图工具完成几个设计练习。这些练习的目的是让你在动手写代码之前，先从全局视角理解 RAG 系统的完整面貌。

任务一：画 RAG 系统架构图

这是今天最重要的任务。不要用现成的模板，自己从零画。

画的时候注意几个要点：

分层画。 最上面是用户触达层（前端界面、API），中间是业务逻辑层（检索服务、生成服务、文档处理服务），最下面是数据层（向量数据库、文档存储、模型 API）。每一层之间用箭头标注数据流向。

标注数据格式。 每个模块之间的数据传递，标注清楚是什么格式。比如文档处理服务输出给 Embedding 服务的是”文本片段列表”，Embedding 服务输出给向量数据库的是”向量 + 元数据”。

区分离线和在线。 用不同颜色或不同区域标明哪些是离线操作（文档入库），哪些是在线操作（用户问答）。这两条管线的运行频率、性能要求、错误处理策略完全不同。

任务二：拆解 RAG 全流程

选一个具体的场景，比如”员工查询差旅报销标准”，然后用一问一答的方式走通整个 RAG 流程。

考虑这些问题：

用户的问题是什么？“上海出差的住宿标准是多少？”

这个问题会被怎么向量化？Embedding 模型会把这段文字转成一个高维向量。

向量数据库里会匹配到什么？应该匹配到公司差旅政策文档中关于上海住宿标准的那一段。

匹配到的内容会怎么拼接到 Prompt 中？作为上下文放在问题的前面。

模型会怎么回答？基于检索到的内容，给出具体数字，并标注来源。

这个走读的过程看似简单，但它帮助你理解每个环节的输入和输出，以及每个环节可能出问题的地方。

任务三：设计企业知识库 MVP

MVP 是 Minimum Viable Product，最小可行产品。不要一上来就想做全功能的企业知识库，先确定最小的功能集。

一个企业知识库 MVP 需要什么？

必须有的功能：

文档上传（先支持 PDF 和 Markdown 就够了）
自动解析和索引
自然语言问答
显示答案的来源（引用哪个文档的哪一段）

可以没有的功能（后续迭代）：

多用户和权限管理
文档版本管理
检索效果评估面板
对话历史记录
多语言支持

技术选型（先做决策，后面几天再验证）：

Embedding 模型：选一个中文效果好的开源模型或 API
向量数据库：选一个上手简单的（先用 Chroma 或 FAISS，后面再换生产级的）
大模型：用你已经熟悉的模型 API
后端框架：继续用 FastAPI

任务四：选择测试文档

好的测试文档是 RAG 开发的基础。选文档的时候遵循以下原则：

格式多样性。 至少包含 PDF 和 Markdown 两种格式。如果有 Word 文档更好。这样可以验证文档解析的鲁棒性。

内容多样性。 不要全是同一类型的文档。一篇技术手册、一份制度文件、一个产品介绍、一份 FAQ、一份案例分析。不同类型的文档对切分策略的要求不同。

长度多样性。 有几页的短文档，也有几十页的长文档。长文档能更好地暴露切分和检索的问题。

内容有明确答案。 选择的文档中应该有一些事实性的、可以明确回答的问题。比如”退款处理的 SLA 是多少小时”这种有确定答案的问题，便于评估 RAG 系统的准确性。

当日产物说明

今天需要产出的三个文档：

产物一：《RAG 系统架构图》

这是一个技术架构图，不是流程图。架构图强调的是系统的模块组成和数据流，而不是某个具体操作步骤。

质量标准：

至少包含六个核心模块：文档处理、Embedding、向量存储、检索服务、生成服务、应用接口
标注模块之间的数据流向和数据格式
区分离线管线和在线管线
标注关键技术选型（具体用哪个模型、哪个数据库可以后面再定，但要标注”这里需要选型”）
图例清晰，别人看图能理解整个系统

怎么组织： 可以用一张大图展示全貌，也可以拆成几张小图分别展示离线管线、在线管线、系统部署架构。关键是不要画成流程图，要画成架构图。

产物二：《企业知识库 MVP 设计》

这是一份简短的设计文档，描述你要做的最小可行产品。

应该包含：

产品定位（给谁用的、解决什么问题）
核心功能清单（必须有的功能列表）
非功能清单（明确不做的事情）
技术选型初步方案
数据流设计（文档从上传到可检索的过程）
用户使用流程（从提问到获得答案的过程）

质量标准： 另一个人看了这份文档，能理解你要做一个什么东西、大致怎么做。不需要面面俱到，但方向和边界要清楚。

产物三：《RAG 流程说明》

这是一份流程走读文档，用一个具体例子说明 RAG 系统如何工作。

应该包含：

一个具体的用户问题和对应的文档内容
逐步描述从问题到答案的完整过程
每一步的输入和输出
标注可能出问题的环节

质量标准： 非技术人员看了能理解 RAG 的工作原理。这就是检验标准。

常见误区与避坑

误区一：RAG 就是把文档丢给 AI

这是最常见的误解。很多人以为 RAG 就是把文档上传到某个平台，然后就能对文档进行问答了。实际上，从文档到可检索的知识库中间有大量工作要做：文档解析要处理各种格式，文本清洗要去掉无用的格式字符，切分要考虑语义完整性，向量化要选择合适的模型和维度。任何一个环节做不好，最终的问答效果都会大打折扣。

就好比做饭，你不能把一整条鱼直接扔进锅里就说”我在做红烧鱼”。你得杀鱼、去鳞、去内脏、切花刀、腌入味，每一步都有讲究。RAG 也是一样，文档处理不是一步到位的，而是一套完整的管线。

误区二：RAG 能完全消除幻觉

RAG 能降低幻觉，但不能消除幻觉。模型可能基于检索到的内容”过度推理”，得出原文并未明确表达的结论。也可能在检索不到相关内容时，忽略检索结果而自己编造答案。

正确的理解是：RAG 把幻觉率从”经常发生”降低到”偶尔发生”。要进一步降低幻觉率，还需要结合其他技术，比如 Grounding（让模型严格基于检索内容回答）、Citation（强制标注来源）、Self-Check（让模型自检回答是否与检索内容一致）。

误区三：Embedding 模型越贵越好

Embedding 模型的选择要看具体场景。贵的模型在通用语义理解上确实更强，但在特定领域（比如半导体、法律、医疗），一个在该领域微调过的小模型可能比通用的大模型效果更好。

选择 Embedding 模型的关键是看两点：在你的数据集上的检索效果（召回率和准确率），以及推理延迟和成本。不要盲目追求参数量最大、价格最高的模型。

误区四：向量检索是唯一的检索方式

纯向量检索（语义检索）在很多场景下效果不错，但它有自己的弱点。比如精确匹配专有名词、产品型号、人名等，向量检索不如关键词检索准确。

实际工程中，更常见的做法是混合检索（Hybrid Search）：同时做向量检索和关键词检索，然后把两路结果合并排序。这在后面的 Day 20 会详细讲到。

误区五：RAG 能解决所有知识问题

RAG 解决的是”从静态文档中检索信息”的问题。它不能解决以下场景：

实时数据查询（需要 Tool Calling 接数据库）
复杂数据分析（需要 Agent 编排多个工具）
创意生成（不需要外部知识，模型本身的能力就够了）
长链推理（需要多步推理，单次检索不够）

RAG 是工具箱里的一个重要工具，但不是唯一工具。

延伸思考

RAG 与 Week 1-2 的衔接

Week 1 我们学了 AI 应用开发的九大模块，其中”知识层”就是 RAG 所在的位置。Week 2 我们学了 API 调用和结构化输出，这些能力在 RAG 系统中同样关键：调用 Embedding API 做向量化，调用 LLM API 做答案生成，用结构化输出来格式化检索结果和答案。

RAG 不是独立于前面所学内容的新东西，而是在已有能力基础上的架构升级。你已经会调用 API 了，RAG 只是让你在调用生成 API 之前，先调用检索 API 获取上下文。

RAG 与微调的关系

经常有人问：RAG 和微调（Fine-tuning）该选哪个？答案是：它们不冲突，解决的问题不同。

微调改变的是模型本身的行为和能力。如果你想让模型学会某种输出格式、某种语气、某种推理方式，用微调。

RAG 增加的是模型可以参考的外部知识。如果你想让模型回答它训练数据中没有的信息，用 RAG。

在大多数企业场景中，RAG 是首选方案，因为它的迭代速度快、成本低、效果直观。微调作为补充手段，在 RAG 解决不了的时候再考虑。

RAG 的未来方向

当前 RAG 领域有几个值得关注的方向：

Graph RAG。 把知识组织成图谱结构，而不是扁平的文本片段。这样可以更好地处理实体关系和多层推理。微软已经开源了 GraphRAG 项目，值得关注。

Agentic RAG。 把 RAG 和 Agent 结合起来。Agent 可以自主决定是否需要检索、检索什么、检索结果够不够、需要不需要再检索一次。这比固定的”检索一次就生成”更灵活。

Multi-modal RAG。 不只是文本，还包括图片、表格、图表的检索。企业文档中大量信息是以视觉形式存在的，纯文本 RAG 会丢失这些信息。

这些方向在 Week 4（Agent）和后续学习中会有更多涉及。

自测问题

用自己的话解释 RAG 是什么，以及它和普通大模型问答的核心区别在哪里。
列举大模型的三个核心缺陷，并说明 RAG 如何分别应对这些缺陷。
画出 RAG 的离线管线和在线管线，标注每个步骤的输入和输出。
为什么说”检索质量决定了 RAG 系统的上限”？举一个具体的例子说明检索失败会导致什么问题。
企业知识库场景中，RAG 适合解决哪些问题？不适合解决哪些问题？各举两个例子。
RAG 的五个核心优势是什么？分别对应解决了什么痛点？
RAG 的维护工作包括哪些？为什么说这不是一次性的工程任务？
解释 RAG 系统架构中”文档处理层”和”检索层”的职责，以及它们之间的数据流。
如果你给一家企业设计知识库 MVP，你会优先支持哪些文档格式？为什么？
RAG 和微调分别解决什么问题？为什么在企业场景中 RAG 通常是首选？

关键词

RAG（Retrieval-Augmented Generation）：检索增强生成，先从知识库检索相关内容，再让大模型基于检索内容生成回答的架构模式
Indexing：索引阶段，离线将文档处理成可检索的向量形式并存储的过程
Querying：查询阶段，在线接收用户问题、检索相关内容、生成回答的过程
Chunk：文本片段，长文档被切分成的小段文本，是 RAG 系统处理和检索的基本单位
Embedding：向量嵌入，将文本转换为数值向量的过程，使文本可以被计算相似度
Vector Database：向量数据库，专门存储和检索向量的数据库系统
Top-k：检索结果数量，返回与查询最相似的前 k 个文档片段
Hallucination：幻觉，大模型生成看似合理但实际错误的内容的现象
Hybrid Search：混合检索，同时进行向量检索和关键词检索，合并两路结果
Grounding：答案落地，让模型的回答严格基于检索到的内容，减少自由发挥
MVP（Minimum Viable Product）：最小可行产品，功能最精简但可以验证核心价值的产品版本
离线管线（Offline Pipeline）：文档上传、解析、切分、向量化、入库的批处理流程
在线管线（Online Pipeline）：用户提问、检索、生成回答的实时交互流程

MindCarver Blog

MindCarver

探索

Day15-RAG原理与架构