第 24 课：记忆与 RAG 工程化｜第一性原理大模型课程

第 24 课：记忆与 RAG 工程化

上一课我们把"工具"这条通道打通了——模型能通过 MCP 去调用外部世界。但工具解决的是"能做什么"，没解决"知道什么"：模型的知识停在训练截止日，你的私域文档它从没见过。这一课从一个反问开始：上下文窗口都到百万 token 了，塞进上下文就等于用得上吗？我们从检索链路（切分 / 嵌入 / 重排）、中间遗忘、记忆分层、写权重 vs 放检索，一路算到"怎么评估一条 RAG（先去资料库检索出相关片段，再把这些片段塞进上下文让模型照着回答）链路"。

🎯 学完这 6 步你将能够：

① 说清"窗口大 ≠ 该全塞"的成本与效果账，并算出全量塞入与按需检索的 token 差
② 讲清 RAG 检索链路的每一环，用 recall / precision 量化召回质量，并解释"中间遗忘"为什么让塞进去的内容用不上
③ 用 CoALA 的四层记忆组织 Agent 状态，在"写进权重 vs 放检索"之间做取舍，并用 RAGAS 分层评估定位"是检索坏还是生成坏"

🗺 本节推理链（6 步逻辑递进：从"为什么要检索"到"怎么证明它有用"）

1要让模型回答它训练里没见过、而且会变的事实，这就要求先做一个选择：把知识塞进权重（贵、慢、会遗忘）还是放进 context（便宜、可更新）。既然知识会变、又要能溯源，于是选"运行时取"。知识要运行时取。

↓

2既然「知识要运行时取」，所以得先把文档变成一个能被检索的结构——这就要求解析、切分、embedding 成向量、建索引；链路里任何一环坏，最终答案都会坏。检索质量由链路最弱环决定。

↓

3既然「检索质量由链路最弱环决定」，那么把对的材料取回来只是第一步——这就要求接着解决「取回来怎么摆」：材料进 context 后是线性铺开的，而模型对中段利用最差（Lost in the Middle），否则检索得再准，收益也会被位置吃掉。取回来还要放对位置。

↓

4既然「取回来还要放对位置」，所以要先看清一件事：上下文里的"位置"是稀缺资源——这就要求决定"什么值得占用它"：把记忆按用途分层（工作 / 情节 / 语义 / 程序），只有工作记忆常驻 context，其余外置、用时再取，不同层配不同的 cache。记忆要分层。

↓

5既然「记忆要分层」，于是最上层的决策就浮出来了：这份知识该放哪一层——这就要求在"写进权重"与"放 context 里的检索"之间，按更新频率、规模、是否要溯源来取舍。放权重还是放检索要按场景定。

↓

6既然「放权重还是放检索要按场景定」，所以最后还得能证明这个选择真的对——这就要求一套分层评估：把检索指标与生成指标分开测，否则"检索涨了、答案没涨"会被漏掉。衡量这一切的输入与输出都是 tokens。评估要分层。

RAG切分与嵌入重排Lost in the Middle记忆分层RAGAS

上下文窗口都到百万 token 了，为什么还要 RAG？

提示：先算两笔账——把整个知识库都塞进去，一次请求要多少 token、多少成本？再想"装得下"和"用得上"是不是同一件事。

▾

知识背景

RAG（Retrieval-Augmented Generation，检索增强生成）由 Lewis 等人于 2020 年提出（arXiv:2005.11401，NeurIPS 2020）：把参数化记忆（模型权重里的事实）与非参数化记忆（一个可检索的维基百科向量索引）结合，先检索、再生成。它要解决的正是语言模型的三处结构性缺陷——知识无法方便地扩充或修订、无法给出出处、容易编造（幻觉）。注意：RAG 早于"百万 token 窗口"，但窗口变大并没有取消它的理由。

上一课我们把"工具"这条通道打通了：模型能通过 MCP 去调用外部世界。但工具解决的是"能做什么"，没解决"知道什么"——模型的内部知识停在训练截止日，你的私域文档它从没见过。这一张先回答一个最容易被忽略的反问：窗口都这么大（标称百万 token），为什么还要费劲检索？

因为"装得下"和"用得上"是两回事。装得下是显存/工程问题（窗口够大即可），用得上是能力问题（模型在训练时见过多少长依赖）。就像开卷考试：你不会把整间图书馆搬进考场，而是按题目去书架上取那几页——取哪几页、取多少页，才是真正决定成绩的一步。所以下面用两笔账，把"全塞"与"检索"的差距算出来。

更自然的做法是「窗口既然到了百万 token，那就把知识库整个塞进去」。但输入 token 是线性计费的：100 万 token 的知识库每次请求都送，10,000 次/天就是 1×10¹⁰ token、约 $1,500/天；按需检索 top-5 只要约 $3.84/天，相差约 391 倍。「装得下」也不等于「用得上」——这由第 3 张卡片来算。

🧮 第一笔账：全量塞入 vs 按需检索

Step 1：一次请求的 token 差多少

方案	每次输入 token	说明
全量塞入	1,000,000	把 100 万 token 的知识库整个放进 context
检索 top-5	2,560	5 块 × 512 token
比值	1,000,000 ÷ 2,560 ≈ 391 倍

算术：知识库 100 万 token、检索每次只取 top-5（每块约 512 token）时，一次请求的输入从 1,000,000 降到 2,560，相差约 391 倍。窗口再大，也不该把无关的 99.74% 也一起付钱。

Step 2：这个差距换算成钱是多少

口径	每天 10,000 次请求的累计输入	按 $0.15/百万 token 计
全量塞入	10,000 × 1,000,000 = 1×10¹⁰ token	≈ $1,500 / 天
检索 top-5	10,000 × 2,560 = 2.56×10⁷ token	≈ $3.84 / 天

算术：按输入 $0.15/百万 token（示意价）计，每天 10,000 次请求：全量约 $1,500/天、检索约 $3.84/天，同样相差约 391 倍。输入 token 是线性计费的，"省掉的 99.74%"会直接变成账单。

Step 3：标称窗口 ≠ 有效窗口

项	数值
标称窗口（百万级窗口的一个示例取值）	500,000 token
假设的实测有效区间（举例，非某模型实测）	约 125,000 token
有效利用率（示意）	125,000 ÷ 500,000 = 25%

先说可核验的结论：标称窗口 ≠ 有效窗口——Lost in the Middle（Liu 等，arXiv:2307.03172）证明即便显式支持长上下文的模型，对中段信息的利用也会下降，所以"能装下"不等于"能用好"。但具体阈值没有统一答案：不同模型、不同任务差异很大，没有可照搬的统一数字。这里把 125K / 500K 只当示意，工程上必须按你自己场景的实测有效范围设计。

🎯 关键认知

RAG 的第一个理由不是"窗口不够大"，而是成本与效果都不支持全塞：输入 token 线性计费，而模型对超长上下文的利用在远低于标称上限时就已退化。RAG 把"把整个库读一遍"换成"只读相关的那几页"——这是在成本与效果上同时更优的选择。

AI 助教

👋 对"窗口够大为什么还要 RAG"有疑问？比如「窗口够大是不是就不用检索了」「成本到底差多少」？

说一下你的知识库规模与日请求量，我帮你估算全塞与检索的成本差。

检索链路这么长，怎么保证拿回来的就是对的？

提示：把链路拆成"入库"和"查询"两条路——文档进库前要先被切、被编码；查询时先粗排、再精排。想想哪一步做错，后面怎么补救都白搭。

▾

知识背景

一条 RAG 链路由入库路径（解析 → 切分 chunking → 嵌入 embedding 成向量 → 建索引）与查询路径（问题编码 → 相似度检索 → 重排 re-ranking → 生成）组成。重排用更强的交叉编码器对粗排结果重新打分——检索质量有提升，但要权衡延迟代价（见 Step 3）。常见失败模式有三类：切分把语义切断、嵌入模型在入库端与查询端不一致、检索分数未校准。

上一张卡片说明知识要运行时取，而不是全塞。这一张盯住"取"这条链路：它这么长，怎么保证拿回来的是对的？

因为入库与查询是两条独立的路，任何一环出错都会沿着链路传到最终答案——切分把一句话劈成两半、嵌入模型两端用得不一样、粗排召回了却没排进前面，都会让生成拿到错的材料。就像一条水管：只要有一个接口漏水，末端就出不了水；你没法在末端"补回来"。所以下面先用一笔账看切分，再用两个指标量化召回质量。

更笨的做法是「让粗排的结果直接进生成」。但粗排靠向量相似度打分，只判「语义像不像」，分不清「字面很像、其实在讲别的」；重排用更强的交叉编码器把候选重新打分，实测能把 Context Precision 从 0.80 抬到 0.85、Context Recall 从 0.78 抬到 0.86——代价是运行时间约上升至原来的 5 倍。

🧮 第二笔账：切分、召回、重排各值多少

Step 1：切分与重叠决定块数

项	数值
文档长度	10,000 token
块大小 chunk	512 token
重叠 overlap	50 token
步长	512 − 50 = 462
块数	⌈(10,000 − 512) ÷ 462⌉ + 1 = 21 + 1 = 22 块

算术：块数 ≈ (文档长度 − 块大小) ÷ (块大小 − 重叠) + 1 = (10,000 − 512) ÷ 462 + 1 ≈ 22。块太小会丢上下文、块太大又塞进无关内容——那 50 token 的重叠，就是为了防止关键句正好横跨两块边界被劈开。

Step 2：召回率怎么算

项	数值
文档里真正相关的片段	3 个
检索 top-5 命中的相关片段	2 个
召回率 recall	2 ÷ 3 ≈ 0.667

算术：召回率 = 相关片段中被召回的比例 = 2 ÷ 3 ≈ 0.667。它衡量"该拿的拿到没有"——漏掉的那个片段，生成阶段再怎么努力也变不出来（这正是"垃圾进、垃圾出"）。

Step 3：重排能带来多少提升

指标	重排前	重排后	变化
Context Precision（相关块是否排在前面）	0.80	0.85	+0.05
Context Recall（相关块是否被召回）	0.78	0.86	+0.08

据一项 RAG 优化研究（arXiv:2505.08445），加入重排后 Context Precision 从 0.80 升到 0.85、Context Recall 从 0.78 升到 0.86（绝对提升 0.05 / 0.08），属"小幅提升"。代价是延迟：该研究报告运行时间约上升至原来的 5 倍（单一研究、单配置，示意），因此是否上重排取决于你的延迟约束。它对应的朴素做法是：先粗排取 top-50，再用交叉编码器精排取 top-5——用更多候选换更准的顺序。

🎯 关键认知

检索链路的产出上限由最弱的一环决定：切分错了，后面的重排与生成都在错的材料上工作，修生成模型救不回来。所以调优顺序应该是——先把切分与嵌入对齐，再上混合检索与重排，而不是一上来就换更大的生成模型。

AI 助教

👋 对检索链路有疑问？比如「chunk 该切多大」「重排到底值不值」？

说一下你的文档类型与查询方式，我帮你判断瓶颈最可能在切分、嵌入还是重排。

内容都塞进上下文了，为什么模型还是答不到点上？

提示：材料没问题、也确实放进去了。那换个角度想——同一份材料，模型读它的「顺序」会不会有影响？

▾

知识背景

Lost in the Middle（Liu 等，arXiv:2307.03172，TACL 2024）用"多文档问答"实验发现：当相关信息在上下文（context）里的位置改变时，模型性能显著变化——放在开头或结尾时最高（primacy bias / recency bias，即首因 / 近因偏好：更依赖开头与结尾的信息），放在中间时显著下降，整体呈 U 形曲线；即便换成显式支持长上下文的模型，这个现象依然存在。

上一张卡片把检索质量量化成了 recall 与 precision。但还有半步没走完：就算检索到的片段是对的，把它们一股脑塞进上下文，模型就一定会用吗？

因为这不是"有没有材料"的问题，而是"材料放在哪"的注意力问题——同一段正确材料，放在上下文开头/结尾和放在中间，模型的利用率差别很大。就像念一长串名单：开头和结尾的名字记得最清楚，中间那一大段常被一带而过。所以下面看这个"中间遗忘"有多大，以及怎么把材料放对位置。

🧮 第三笔账：位置决定利用率

Step 1：位置改变，准确率跟着变（示意）

相关信息位置	相对准确率（示意）	说明
第 1 位（最前）	100%（基准）	primacy bias
第 10 位（中间）	≈ 70% 基准	明显下降
第 20 位（最后）	≈ 95% 基准	recency bias，回升

示意：把"信息在开头时的准确率"设为 100% 基准，位置移到中段会掉到约 70%，回到末尾又接近开头（约 95%）——形状是先降后升的 U 形。具体幅度随模型与任务而异（此处为读图近似，仅示形状），可核验的是方向：中间最差（Liu 等，arXiv:2307.03172）。

Step 2：减少塞入的片段数就能缓解

方案	塞入片段数	注意力竞争面
粗排放进全部候选	20 块	20 个片段竞争
精排后只放 top-5	5 块	5 个片段竞争

算术：从 20 块降到 5 块，竞争注意力的片段数 20 ÷ 5 = 4，缩小到原来的 1/4。无关块挤占的是注意力预算，不是 token 预算——取太多会稀释真正相关的信号。

Step 3：把材料放对位置的三条做法

做法	具体操作
最相关的放首尾	重排后把 top-1 放开头、top-2 放结尾
减少总片段数	精排取 top-5，而不是 top-20
结构化标注	给每块加来源标题，帮模型定位

算术无关的一条总纲：既然"中间最难用"，那就把最关键的材料放在两端、并砍掉总量。这也是重排（把最相关的排到最前）与少取几块两个动作能同时提升答案质量的原因。

🎯 关键认知

RAG 的失效常被误判成"没检索到"，其实更常见的是"检索到了但没用上"。对策有三：把最相关的放首尾、减少塞入的片段数、给材料加来源标记。记住这条顺序：先保证取到（recall），再保证用好（位置）。

AI 助教

👋 对"中间遗忘"有疑问？比如「为什么不把最相关的直接放最前就好了」「多放几块是不是更保险」？

说一下你一次塞几块、按什么顺序排，我帮你调排布。

工作记忆、情节记忆、语义记忆、程序记忆——Agent 的记忆为什么要分这么多层？

提示：想想你自己的信息是怎么分开放的——正在处理的事、上周发生的事、一般性知识、做事的步骤，是不是放在不同的"地方"、用不同的方式取？

▾

知识背景

Agent 记忆的分层来自 CoALA（Cognitive Architectures for Language Agents，Sumers 等，arXiv:2309.02427，2023）：一个工作记忆（working memory，即当前 context 窗口内正在推理的状态）+ 三类长期记忆——情节记忆（episodic：过去的事件与经历）、语义记忆（semantic：事实与知识）、程序记忆（procedural：做事的步骤与技能）。它借鉴认知科学，把"短期/长期"这种模糊二分，换成按信息类型区分的更细分类——分层也决定了哪一层可以放进高速 cache、哪一层必须走外部检索。

上一张卡片说明取回来还要放对位置。可"放"在哪里、放多久，本身就需要一个结构——这一张问：Agent 的记忆为什么要分这么多层？

因为不同的信息有完全不同的生命周期与取用方式：当前这一步的推理必须常驻 context（快、但贵、会话结束就没），而"三天前用户说过什么"要能跨会话留存、"公司报销规则"要能长期复用、"先校验再下单"这类步骤要能指导行为。就像办公桌、日记本、百科全书、操作手册——信息不同，放的抽屉和取的方式也不同，全堆桌面上很快就乱。所以下面看四层各存什么，再算一笔上下文预算。

更省事的做法是「所有信息都放进同一段上下文，谁需要谁自己看」。但上下文的位置是稀缺资源：单次会话约 5,000 token 的轨迹，30 次会话就是 150,000 token，是 8,000 预算的 18.75 倍——不分层、不外置，历史很快就把窗口占满。

🧮 第四笔账：四层记忆与一份上下文预算

Step 1：四层记忆各存什么

层	存什么	典型载体	存取方式
工作记忆 working	当前任务的状态与中间结果	context 窗口	直接读写
情节记忆 episodic	过去的事件、会话记录、工具调用轨迹	日志	向量检索
语义记忆 semantic	事实、偏好、领域知识	知识库	向量 + 图检索
程序记忆 procedural	做事的步骤、技能、决策规则	prompt 规则或代码	直接注入

算术无关的一条结构说明：四层的区别不是"存多久"，而是"存什么"——工作记忆按窗口存、情节按时间存、语义按事实存、程序按步骤存。一个 Agent 通常同时用其中 2~3 层（经验说法，示意）。

Step 2：一份 8,000 token 的预算怎么分

用途	预算	占比
system prompt	500 token	6.25%
工作记忆（本轮历史 + 中间结果）	3,000 token	37.5%
检索片段	4,000 token	50%
输出预留	500 token	6.25%
合计	500 + 3,000 + 4,000 + 500 = 8,000	100%

算术：工作记忆 + 检索片段 + system + 输出 = 8,000 token，其中检索片段占 50%。这也是"记忆分层"的落地方式——每一层都要在 context 里分到一块预算，而不是谁先来谁占满。

Step 3：情节记忆为什么必须外置

项	数值
每次会话产生的轨迹	5,000 token
30 次会话累计	30 × 5,000 = 150,000 token
相对 8,000 预算	150,000 ÷ 8,000 = 18.75 倍

算术：单次会话 5,000 token，30 次就是 150,000 token，是 8,000 预算的 18.75 倍——装不下。所以情节记忆必须外置到检索里，用时按需取回少数几条，而不是无脑累积进 context。

🎯 关键认知

记忆分层回答的问题是"什么该常驻、什么该外置"：工作记忆常驻 context（快但贵、易失），情节/语义/程序记忆外置到存储（便宜、可持久、需检索）。把这条想清楚，RAG 就不只是"文档问答"，而是 Agent 记忆体系里的语义记忆层。

AI 助教

👋 对记忆分层有疑问？比如「我的场景该用哪几层」「情节记忆怎么存才不爆」？

说一下你的 Agent 要记什么、记多久，我帮你分到合适的层。

新知识该写进权重还是放进检索？为什么不能全用微调？

提示：比较两条路的成本——"改权重"要做什么、多久一次能承受？"放检索"又便宜在哪？再想：哪些知识根本不该动权重。

▾

知识背景

把新知识装进模型有两条路：改权重（持续预训练 / 微调 / 模型编辑——ROME、MEMIT 属后者，把事实当键值对、直接改写模型局部权重）与放检索（RAG）。一项综述（Wang 等，arXiv:2502.12598，Bring Your Own Knowledge: A Survey of Methods for LLM Knowledge Expansion）给出取舍：模型编辑适合精确、定向的少量事实更正；检索适合动态、频繁变化的事实，无需改参数、天然可溯源；持续学习适合大规模知识增量。要注意编辑的代价：一篇编辑方法综述与基准（Yao 等，arXiv:2305.13172）指出，现有编辑方法在可移植性、局部性上仍有局限；一项规模化研究（Gupta 等，arXiv:2401.07453）进一步发现，对 ROME/MEMIT 做持续顺序编辑时，模型会先"渐进遗忘"、随后进入"灾难性遗忘"——即少量、定向的编辑尚可，编辑量一上去就明显退化。

上一张卡片把记忆分了层，其中"语义记忆"这一层既可以写进权重、也可以放进 context 里的检索。这一张问最上层的决策：新知识到底该放哪？为什么不能全用微调？

因为两条路的成本结构完全不同：改权重要跑训练/编辑，慢、贵且会遗忘旧知识；放检索只需更新索引，快、可回滚、可溯源。就像改一个人的习惯要重新训练很久，而给他贴一张"今天改走这条路"的便签当场就生效——短期、易变的信息用便签，长期、稳定的能力才值得改习惯。所以下面用一笔账把两条路的成本摆出来。

更自然的做法是「有新知识就微调一遍模型」。但改权重的边际成本高、还会遗忘旧知识：按每月 100 条更新算，一年要微调 12 次，每次都是数 GPU·小时级的训练；同样的知识放进索引只要写 1,200 次、每次秒级。模型编辑只在很小的编辑量下还可用——一旦持续顺序编辑，ROME/MEMIT 就会先"渐进遗忘"、后"灾难性遗忘"（Gupta 等，arXiv:2401.07453）。

🧮 第五笔账：写权重 vs 放检索

Step 1：两条路的性质对比

维度	写进权重	放进检索
更新成本	高（训练/编辑一轮）	低（更新索引）
更新速度	小时 ~ 天	秒级
可溯源	难	易（可给出处）
适合规模	少量、定向	大量、频繁

算术无关的一条结构对比：这两条路不是"谁更好"，而是"谁更合适"——权重适合稳定、通用的能力；检索适合易变、需溯源的事实。

Step 2：一年更新成本算例

项	写进权重（月度微调）	放进检索（实时索引）
更新频率	100 条/月 → 12 次/年	1,200 条/年
单次代价	一次微调（数 GPU·小时）	一次索引写（毫秒 ~ 秒）

算术：100 条/月意味着一年 12 次微调（每次都要重新训练），或 1,200 次索引写入（每次秒级）。更新越频繁，检索的相对成本越低——这就是为什么"会变的事实"默认走检索。

Step 3：编辑规模的代价

编辑规模	ROME / MEMIT 的表现	来源
少量、定向的更正	尚可	Yao 等，arXiv:2305.13172
持续顺序编辑（规模增大）	先"渐进遗忘"、后"灾难性遗忘"	Gupta 等，arXiv:2401.07453

定性结论：模型编辑适合"少量、定向"的更正；一旦持续顺序编辑，ROME/MEMIT 会先渐进遗忘、后灾难性遗忘（Gupta 等，arXiv:2401.07453）——所以"用编辑代替 RAG"只在极小规模下成立。

🎯 关键认知

选路看四个问题：① 更新多频繁 ② 要溯源吗 ③ 规模多大 ④ 要保旧知识吗。频繁 / 要溯源 / 规模大 → 放检索；稳定 / 通用 / 少量更正 → 可考虑写权重；两者都要 → 检索为主、对稳定的部分做微调补齐。判据一句话：先问"把正确资料给它，它就能答对吗"——能就是检索问题，不能才动权重。

AI 助教

👋 对"写权重还是放检索"有疑问？比如「什么时候必须微调」「模型编辑能撑多大」？

说清你的知识更新频率与规模，我帮你判断该走哪条路。

一条 RAG 链路，怎么保证出了问题能定位到是检索坏了还是生成坏了？

提示：答案错了，可能错在"没找到材料"，也可能错在"材料在手却写错"。要分开定位，就得有能分别度量这两段的东西。

▾

知识背景

评估 RAG 要把检索与生成分开测。常用指标来自 RAGAS（一个开源的 RAG 评估框架）：Context Precision（相关片段是否被排到前面，对排名敏感的 average precision@k）、Context Recall（相关片段被召回的比例）测检索；Faithfulness（答案有多少条被上下文支持）、Answer Relevancy（答案是否切题）、Answer Correctness（与标准答案的一致度）测生成。这一整条链的输入与输出最终都是 tokens，成本与延迟也都按它计。

前面五张卡片解决了"为什么要检索、怎么取、怎么放、放哪层、放权重还是放检索"。最后一张要解决一个工程问题：怎么证明这条链路真的对，且出问题能定位？

因为"答案错了"是一个笼统的现象，可能错在检索（没找到材料），也可能错在生成（材料在手却写歪）；不把两段分开测，就会一直修错地方。就像体检要分科室：肝指标高不能说明心脏没问题，必须分开看才能定位。所以下面先给五个指标各测什么，再用算例把"分段定位"跑一遍。

🧮 第六笔账：分层评估与定位

Step 1：五个指标各测哪一段

指标	测哪段	一句话定义
Context Precision	检索	相关片段是否被排到前面（average precision@k，排名敏感）
Context Recall	检索	相关片段被召回的比例
Faithfulness	生成	答案被上下文支持的程度
Answer Relevancy	生成	答案是否切题
Answer Correctness	生成	与标准答案的一致度

算术无关的一条分类：前两个属于检索段，后三个属于生成段。分开测的意义是——检索分低就去修切分/嵌入/重排，生成分低才去改 prompt 或换模型。

Step 2：三个指标怎么算

指标	算例	结果
Context Precision	取回 5 条、相关 3 条（在第 1、3、4 位）	(1.000 + 0.667 + 0.750) ÷ 3 ≈ 0.806
Context Recall	相关 3 条，召回 2 条	2 ÷ 3 ≈ 0.667
Faithfulness	答案 10 条断言，8 条有上下文支持	8 ÷ 10 = 0.80

算术：Recall 与 Faithfulness 是"命中 ÷ 总数"（2÷3≈0.667、8÷10=0.80）；Precision 是排名敏感的——相关块排在第 1、3、4 位时 P@1=1/1=1.000、P@3=2/3≈0.667、P@4=3/4=0.750，取平均得 (1.000+0.667+0.750)÷3≈0.806。三者都落在 0~1，便于跨版本对比。

Step 3：检索涨了，生成不一定涨

指标	优化前	优化后	变化
Context Precision	0.80	0.85	+0.05
Context Recall	0.78	0.86	+0.08
生成侧（Faithfulness / Correctness）	——	+0.6% / +4%（相对提升）	仅小幅提升（原文自述「muted downstream response」）

据同一项研究（arXiv:2505.08445），检索侧指标有提升（+0.05 / +0.08 绝对，该文自述为"小幅"），而生成侧只有小幅提升——Faithfulness 约 +0.6%、Answer Correctness 约 +4%，原文自述为"下游反应平淡（muted downstream response）"。这正说明必须分层测：否则"检索变好了"会被误当成"系统变好了"，而真正的瓶颈（生成）被掩盖。

🎯 关键认知

本课收口：RAG 是把"知道什么"从权重里拆出来、放进可检索的外部记忆。它的工程要点是一条链：为什么要检索（成本 + 有效窗口）→ 检索质量（切分 / 嵌入 / 重排 + recall / precision）→ 用得上的关键（位置）→ 记忆分层（工作 / 情节 / 语义 / 程序）→ 放权重还是放检索（按场景）→ 分层评估（检索段 vs 生成段）。下一课我们把这条链继续往前推：当任务长到一步做不完，Agent 怎么规划、怎么和别的 Agent 协作。

AI 助教

👋 对 RAG 评估有疑问？比如「怎么判断该修检索还是修生成」「要不要上 LLM 当裁判」？

说一下你现在的错误案例，我帮你归到检索段还是生成段。