Appearance
🐣 小a的考试困境
小a答历史题老翻车——它"记得"的事有一半是编的。老z说:"你这是在闭卷考试。想答准?试试开卷——先查资料再答。"
小a:"开卷?可我没资料可查啊。"
老z:"给你装个检索器,你就有资料可查了。这叫 RAG。"
13.1 闭卷考试困境:幻觉的根源
回忆第 1 章的幻觉——模型会自信地编造不存在的事实。为什么?
🧙 因为模型在"闭卷考试"。
答案全靠训练时记进脑子的东西,记错或没学过就瞎编。这和"开卷考试"的区别:
- 闭卷(裸模型):凭脑子里的记忆答题 → 记错就完蛋
- 开卷(RAG):先翻笔记本找相关页 → 把那页摊开在桌上 → 看着笔记答题 → 准确多了
13.2 RAG 是什么
🧙 **RAG(Retrieval-Augmented Generation,检索增强生成)**让模型从"闭卷考试"变成"开卷考试"——答题前先去查资料,把查到的相关内容塞进 prompt,再让模型基于这些资料回答。
本质:RAG = 搜索 + 生成。 先搜出相关资料,再让模型基于资料生成答案。
13.3 RAG 的三步流程
用户问:"公司的报销流程是什么?"
↓
① 切块(chunk):把公司的规章制度文档,切成一小段一小段
↓
② 向量化(embedding):把每段文字转成一串数字(向量),代表它的"语义"
↓
③ 检索(retrieval):把用户的问题也转向量,找出最相关的几段
↓
把找到的相关段落 + 用户问题,一起喂给模型
↓
模型基于"看到的真实资料"回答(不再瞎编)🧙 三个关键词:
- 切块:文档太长塞不进窗口,得切碎
- 向量化:用 embedding 模型把文字变成"语义坐标",相似的内容坐标相近
- 检索:找坐标最接近用户问题的那几段
13.4 深入理解三个环节
切块:怎么切
🧙 切块(chunking)的讲究:
- 块太小(几十字)→ 语义不完整,检索不准
- 块太大(几千字)→ 塞不进窗口,且包含太多无关内容
- 常见做法:按段落/按语义切,块大小 200-1000 token
切块的好坏,直接影响检索质量。 这是 RAG 工程里最容易被低估的一环。
向量化:怎么变成坐标
🧙 向量化(embedding)用专门的 embedding 模型,把文字变成一串数字(向量)。
关键特性:语义相近的文字,向量坐标也相近。
- "公司报销流程"和"报销需要什么材料" → 向量很近
- "公司报销流程"和"如何做红烧肉" → 向量很远
这样就能用"距离"判断"哪段文档和问题最相关"。
检索:怎么找
🧙 检索 = 把问题转向量,找出坐标最近的几段文档。
常用"余弦相似度"衡量距离,取 Top-K(如最相关的 3-5 段)喂给模型。
13.5 RAG 适合什么?不适合什么?
🐣 小a问:"那写代码也该用 RAG 吗?把整个代码库向量化,让模型查?"
🧙 "不该——这正是 pi 不用 RAG 的原因。"
场景 该用 RAG 吗 为什么 知识库问答("公司报销流程") ✅ 该用 答案在海量文档里,要检索 长文档问答("这份合同说了啥") ✅ 该用 文档太长,要找相关段 客服 bot("我的订单到哪了") ✅ 该用 要查数据库/文档 写代码(改 bug、加功能) ❌ 不该用 代码要精确操作(read/edit),不是"语义近似"
🧙 为什么写代码不用 RAG?
向量检索是"模糊匹配"——找"意思相近"的内容。但写代码要的是"精确到行"——
read一个文件,拿到的是确切内容;RAG 给的是"可能相关的一段",反而可能误导。工具精确读文件(read/grep) vs RAG 语义检索:前者确定,后者概率。 写代码要确定,所以用工具不用 RAG。
13.6 RAG 的常见坑
🧙 RAG 不是银弹,常见坑:
- 检索不准:切块不好/embedding 模型弱 → 搜不到相关段落 → 模型还是瞎编
- 上下文污染:检索结果里混入无关内容 → 模型被带偏
- 数据过时:文档库没更新 → 答的是旧信息
- 成本:embedding + 存储 + 检索,都有基础设施成本
RAG 的核心是"检索质量"。 检索不好,RAG 就是"开卷考试但翻不到正确答案"。
13.7 RAG 的进阶:混合检索与 GraphRAG
"基础 RAG 讲完了。"老z说,"但两个进阶变体,你早晚会碰到。"
变体一:混合检索(向量 + 关键词)
🧙 纯向量检索有个盲区:专有名词、代码标识符、人名,向量常常检索不准。
比如问"
fetch函数返回Promise吗",向量化的"语义"可能搜不到含fetch的文档;但关键词检索(传统 BM25 算法)能精确命中"fetch"。混合检索(hybrid) = 向量检索 + 关键词检索 一起上,结果合并:
- 向量 → 抓"语义相近"(换说法、同义词)
- 关键词 → 抓"字面命中"(专有名词、代码、编号)
- 合并 → 比单一方式更全、更准
变体二:GraphRAG(检索知识图谱)
🧙 基础 RAG 按"段落相似度"找资料,答不好"跨多段、关系型"的问题。
比如问"我们公司的报销,一共涉及哪些部门、要经过几道审批?"——答案散在多份文档的多段里,向量检索只能零散捞到片段。
GraphRAG 的思路:先建知识图谱(把文档里的实体——部门、流程、角色——和它们的关系抽出来,连成一张网),再在图结构上检索:
- 问"报销涉及哪些部门" → 在图上沿着"报销 → 涉及 → 财务部/行政部"的关系走一遍 → 给出结构化的全局答案
一句话:基础 RAG 按"相似段落"检索,GraphRAG 按"关系网络"检索。 后者适合"多跳、关系型、全局型"的问题,但建图成本更高。
RAG 的定位:它只是"喂资料"的一种方式
🐣 小a:"那 RAG 和工具查询、还有第 8 章的记忆加载,是什么关系?"
🧙 "它们是兄弟,不是替代。 给模型『喂资料』有三条路:"
方式 机制 适合 RAG 语义检索(向量) 资料多、问题开放("报销流程是什么") 工具查询 确定性读取(read/grep/API) 要精确答案(文件内容、数据库记录) 记忆加载 直接取出长期记忆(第 8 章) 用户偏好、项目背景等稳定事实 选哪条,看你要"精确"还是"相关"、资料是"稳定"还是"海量"。 成熟的 Agent 往往是三者并用:RAG 查知识库、工具查精确数据、记忆带上下文。
本章小结
🐣 小a的开卷课
┌──────── RAG ────────┐ │ │ │ • 幻觉 = 闭卷考试 │ │ RAG = 开卷考试 │ │ │ │ • 三步:切块→向量化│ │ →检索→喂给模型 │ │ │ │ • 本质:搜索+生成 │ │ │ │ • 适合:知识库问答 │ │ 不适合:写代码 │ │ (精确 vs 模糊) │ │ │ │ • 坑:检索不准/污染/ │ │ 过时/成本 │ │ │ │ • 进阶:混合检索 │ │ (向量+关键词) │ │ GraphRAG(关系网) │ │ │ │ • 定位:RAG/工具/ │ │ 记忆 = 三条喂料路 │ └──────────────────────┘
关键认知:RAG 让模型"开卷考试"——先检索相关资料再作答,缓解幻觉。它适合知识库问答,不适合写代码(要精确不要模糊)。检索质量决定 RAG 成败;进阶玩法是混合检索与 GraphRAG,而 RAG 只是"喂资料"三兄弟之一(另两个是工具查询、记忆加载)。
课后实验
- 感受幻觉 vs RAG:问模型一个编造的 API,再给它一段真实文档,对比准确率。
- 设计切块:拿一篇长文档,想想怎么切块检索效果最好(块多大?按什么切?)。
- 判断场景:三个场景(技术问答/代码修改/客服)哪些该用 RAG,为什么?
- 体会混合检索:用一个支持混合检索的 RAG 工具,分别用"纯向量"和"向量+关键词"搜同一个含代码标识符的问题,对比结果差异。
- 想 GraphRAG 场景:想一个"跨多段文档、关系型"的问题(如"认证流程涉及哪些服务"),判断基础 RAG 能不能答好,GraphRAG 的优势在哪。
下一章:除了让模型自由发挥(Loop),还有两种"按路线图干活"的范式——Workflow 和 Graph。 → 第 14 章 · Workflow vs Graph