模块一-RAG概述
系列导航：本文是 RAG 技术教程 的第一篇。本系列基于吴恩达 RAG 课程整理，面向有基础知识的开发者。
前置知识：无，本篇是系列起点。
版权声明：本系列基于 DeepLearning.AI 课程Building and Evaluating Advanced RAG Applications（讲师 An Hassan）整理，为学习笔记性质的二次创作。原始课程版权归 DeepLearning.AI 及讲师所有。
1. RAG 入门：从"模型不知道的事"到检索增强生成
1.1 1. LLM 的知识盲区
大语言模型训练时读遍了互联网上的公开数据，但它仍然回答不了很多问题。
原因很具体：训练数据有截止日期，之后发生的事它不知道；公司内部的文档、客户手册、产品规格从未出现在训练集里；专业领域的病例、判例、行业报告也不是公开互联网能覆盖的。要求一个模型精通所有领域本身就不现实。
更麻烦的是，LLM 不会老实说"我不知道"——它会生成听起来合理但实际不正确的回答，这叫幻觉。当用户问了一个模型训练时没见过的信息，它可能编造一个看似可信的答案，而用户很难分辨真假。
解决办法不复杂：如果模型不知道，就把信息放到它的提示里。这就是 RAG 的出发点。
1.2 2. RAG 的核心思想
RAG 的全称是 Retrieval-Augmented Generation，检索增强生成。名字有点长，但做的事情很直接——在用户的问题发送给 LLM 之前，先从知识库中检索相关信息，把这些信息拼进提示中，让模型基于真实数据生成回答。
人类回答问题本来就是两步走：先收集信息，再推理回答。问"周末酒店为什么贵"靠常识就行，不需要查资料；问"温哥华这周末酒店为什么暴涨"就得搜一下，结果发现是泰勒·斯威夫特在开演唱会；问"温哥华为什么市中心酒店容量不足"可能需要查城市规划历史。问题越专业、越有时效性，就越需要检索外部信息。
RAG 就是把第一步自动化了。
工作流程用 mermaid 表示：
增强提示的构建方式很朴素，就是字符串拼接：
defrag_query(question):# 1. 检索相关文档documents=retriever.search(question)# 2. 拼接增强提示prompt=f"""请回答以下问题：{question}以下是可能有帮助的参考资料：{documents}"""# 3. LLM 基于增强提示生成回答answer=llm.generate(prompt)returnanswer没有复杂的魔法，就是把检索到的内容塞进提示里。RAG 能工作的根本原因在于 LLM 的上下文理解能力——即使信息不在训练数据中，只要在提示里提供了，模型就能理解并将其融入回答。
1.3 3. RAG 系统架构
一个 RAG 系统由三个核心组件构成：LLM、检索器、知识库。
- LLM负责理解上下文并生成回答
- 检索器负责从知识库中找到与问题最相关的文档
- 知识库存储 LLM 训练数据中没有的信息
这三者的分工很清晰：检索器从海量信息中筛选关键内容，LLM 专注于文本生成，每个组件做自己最擅长的事。检索器不需要会写文章，LLM 不需要会查资料，各司其职。
RAG 相比直接用 LLM 有四个明显优势：
| 优势 | 说明 |
|---|---|
| 访问私有信息 | 使 LLM 能获取训练数据之外的专有或最新信息 |
| 降低幻觉 | 通过提供相关事实"锚定"LLM 的回答，减少编造 |
| 便于信息更新 | 只需更新知识库，无需重新训练模型 |
| 支持来源引用 | 可在回答中包含引用，便于读者验证 |
“锚定"这个词用得挺形象——就像给 AI 一根绳子拴住，让它不要天马行空地编造，而是基于提供的事实回答。模型没有经历心理发作，它只是在生成"可能的文本”，而 RAG 确保这些"可能的文本"更接近"真实的文本"。
1.4 4. LLM 基础速览
要理解 RAG，需要对 LLM 的工作原理有基本认识。
1.4.1 词元（Token）
LLM 处理文字的最小单位是词元，不完全等于"单词"。英文中 “programmatically” 可能被拆成 “program” + “matic” + “ally” 三个词元，标点符号各自是一个词元。中文里"人工智能"可能是一个词元，也可能拆成"人工" + “智能”，不同模型的分词方式不同。大多数模型的词汇量在数万到十万个词元之间。
1.4.2 自回归生成
LLM 每次只生成一个词元。生成过程：拿到当前所有文本 → 遍历词汇表中每个词元 → 计算每个词元作为下一个出现的概率 → 从概率分布中采样一个 → 追加到文本末尾 → 重复。这意味着早期的随机选择会影响后续方向，同一提示多次运行可能产生不同结果。
1.4.3 幻觉
LLM 设计的目标是生成"可能的"文本序列，而非"真实的"文本。当模型缺乏相关信息时，它会基于训练数据中的模式生成听起来合理但实际不正确的内容。幻觉从轻微（把折扣说成 5% 实际是 10%）到严重（虚构公司从未提供的信息）不等。
| 幻觉级别 | 表现 | 示例 |
|---|---|---|
| 轻微 | 准确描述但细节错误 | 折扣 5% vs 10% |
| 中等 | 错误声称存在实际不存在的信息 | 声称某功能已上线 |
| 严重 | 完全虚构信息 | 虚构不存在的客户折扣 |
RAG 解决幻觉的原理：不是改变模型本身，而是改变模型能看到的信息。在提示中注入相关事实，让模型的回答锚定在真实数据上。
1.4.4 上下文窗口
LLM 有上下文窗口限制——一次能处理的最大词元数量。添加的检索信息会占用这个窗口，所以需要控制检索结果的数量和长度。旧模型的窗口可能只有几千词元，新模型可以处理数百万，但成本随窗口使用量线性增长。
1.5 5. 检索器的角色
检索器的工作可以用图书馆来类比：知识库是藏书，文档索引是按主题分类排列的书籍，查询处理是能理解你问题并帮你找到相关书籍的图书管理员。
检索器有三大组件：
- 文档知识库：所有可用文档的集合
- 文档索引：将文档按某种结构组织，便于快速搜索
- 查询处理：理解用户问题的含义，利用索引搜索并返回最相关的文档
返回文档数量是个需要权衡的问题。返回太多，信息会被淹没在无关内容中，提示成本增加，甚至耗尽上下文窗口；返回太少，可能遗漏重要信息。理想情况是检索器完美排序并返回恰到好处的数量，但现实中检索器有时会把相关文档排得太低，或把无关文档排得太靠前。
检索器可以用两种方式实现：向量数据库擅长"找意思相近的内容"（语义搜索），传统关系型数据库擅长"找精确匹配的内容"（关键词搜索）。实际生产中通常将两者结合使用，形成混合搜索。
1.6 6. 实际应用场景
RAG 的应用比想象中广泛：
| 场景 | 说明 |
|---|---|
| 代码生成 | 以代码库为知识库，LLM 生成符合项目风格的代码 |
| 企业客服 | 了解产品详情、库存状态、故障排除步骤 |
| 内部助手 | 回答公司政策、流程指引，引导至相关文档 |
| 医疗法律 | 高精准度要求的专业场景，涉及大量私密信息 |
| AI 搜索 | 搜索引擎的 AI 摘要本质上就是以互联网为知识库的 RAG |
| 个人助手 | 短信、邮件、日历中的个性化协助，知识库虽小但富含上下文 |
只要拥有未用于训练的额外信息，就有构建 RAG 应用的潜力。
1.7 7. RAG 的演进路径
RAG 不是一成不变的技术，经历了三个阶段：
| 阶段 | 特点 |
|---|---|
| 基础 RAG | 人工编写规则，决定文档分割、检索策略、上下文数量 |
| 高级 RAG | 更复杂的检索策略和优化技术（混合搜索、重排序） |
| Agentic RAG | 多个 LLM 各司其职，AI 代理自主决定何时检索、用什么关键词、是否需要二次检索 |
吴恩达认为 RAG 不会被淘汰——随着语言模型技术提升，语言模型将持续受益于高质量的相关数据。RAG 常成为复杂多步骤工作流中的一个组件，比如在某个企业任务的第五步或第七步发挥作用。
来源：吴恩达 RAG 课程模块一（讲1-讲8），讲师 An Hassan。
1.8 思考题
- 如果你的公司有一份 100 页的产品手册，你会如何设计 RAG 系统来回答客户关于产品功能的问题？需要考虑哪些组件？
- RAG 能完全消除 LLM 的幻觉吗？为什么？
- 除了文中列出的场景，你还能想到哪些 RAG 的应用场景？
下一篇：模块二：信息检索与搜索基础
