阶段 3 讲义 — 检索链路与上下文工程四动作
阶段 3 讲义 — 检索链路与上下文工程四动作
本阶段的核心命题 把正确的信息放进上下文，比把提示词写得更漂亮更重要。 阶段 2 解决"怎么说"，阶段 3 解决"给它看什么"。
分工提醒：本阶段只管单次请求内的上下文供给（检索 → 组装 → 压缩）；跨会话的连续性是 阶段 8 的题目。两者是同一个问题的两半，学的时候注意衔接。
一、RAG 不是一个功能，是一条有八个失败点的链路
产品经理最需要知道的是：用户抱怨"AI 答错了"时，错可能在这八个环节的任何一个，而它们的修法完全不同。
| 环节 | 典型失败 | 表现 | 修法 |
|---|---|---|---|
| ① 采集 | 源根本没进来 | 一问就说不知道 | 补数据源 |
| ② 清洗 | 页眉页脚、导航噪声混入 | 答案里混进无关内容 | 正文提取 |
| ③ 切分 | 一条规则被切成两半 | 答案只有一半 | 按语义/结构切，加重叠 |
| ④ 向量化 | 模型不擅长该领域词汇 | 专有名词检索不到 | 换 embedding、加关键词通道 |
| ⑤ 索引 | 过滤条件缺失 | 检索到过期/他人文档 | 元数据过滤 |
| ⑥ 召回 | 相似但不相关 | 自信地答错 | 混合检索 |
| ⑦ 重排 | 最相关的没排到前面 | 答案对但不完整 | 交叉编码重排 |
| ⑧ 组装 | 关键内容被埋在中间 | 明明检索到了却没用 | 位置策略、精简 |
一条判别口诀 "检索命中"不等于"事实正确"。 检索的评价指标（召回率、MRR、nDCG）和回答的评价指标（正确率、引用准确率）必须分开测。只测端到端正确率，永远不知道该修哪一段。
二、检索的三种通道与 2026 年的默认组合
| 通道 | 擅长 | 不擅长 |
|---|---|---|
| 向量（稠密）检索 | 同义改写、意图相近 | 专有名词、编号、否定与方向 |
| 关键词（稀疏，BM25）检索 | 精确匹配、罕见词、编号 | 同义表达 |
| 混合检索 + 融合 | 两者互补 | 需要调参与更多算力 |
业界在 2026 年的默认做法已经收敛为：
- 并行跑稠密与稀疏两路
- 用 RRF（倒数排名融合） 合并结果（常用参数 k ≈ 60）
- 对融合后的 Top-20 做交叉编码器重排
- 只把重排后的 Top-5～10 送进模型
为什么"只送 5～10 条" 这不是省钱，是防错。阶段 1 实验 2 已经亲眼看到：候选越多，中间位置越多，被忽略和被干扰的概率越大。上下文是有限且会衰减的资源，这是 Anthropic 在 Effective context engineering for AI agents 里反复强调的立论基础。
还有两个常被跳过、但性价比极高的环节
- Query Rewrite（查询改写）：用户的原话往往不是好的检索词。把"上次那个东京的规则"改写成"东京航线 退改签 手续费 规则"，召回质量提升通常大于换 embedding 模型。
- 元数据过滤前置：先按业务维度（航线、时间、文档类型、有效期）过滤，再做语义检索。这一步能挡掉"检索到已作废文档"这类最难被发现的错误。
三、上下文工程的四类动作
这是本阶段的核心框架。任何上下文相关的设计，都可以归到这四个动作之一：
| 动作 | 做什么 | 在 Agent 里的形态 |
|---|---|---|
| Write（写出去） | 把信息写到上下文之外，需要时再取 | 便签文件、任务状态、中间产物落盘 |
| Select（选进来） | 只把当下需要的选进窗口 | 检索、工具按需加载、Skill 渐进式披露 |
| Compress（压缩） | 保留信息量、减少 token | 摘要、结构化提炼、压缩式接续 |
| Isolate（隔离） | 把上下文切开、互不污染 | 子 Agent 独立窗口、沙箱、多会话 |
四个动作的顺序有讲究 先 Select（少放点）、再 Write（放不下的挪出去）、再 Compress（还是超了就压）、最后 Isolate（一个窗口装不下就分家）。反过来做——先上多 Agent 隔离，再回头发现其实只是没做好筛选——是很常见且昂贵的弯路。
稳定前缀与动态尾部：上下文装配的双通道
Claude Code 的系统提示词装配与动态附件通道提供了一个很有迁移价值的实现样本：
| 通道 | 适合放什么 | 设计目标 |
|---|---|---|
| 稳定前缀 | 身份、长期行为规则、稳定工具说明 | 内容和顺序尽量稳定，便于缓存复用与行为回归 |
| 动态尾部 | 工具/Skill/Agent 列表变化、Hook 结果、权限和任务状态 | 以增量方式注入，避免每轮重写前缀 |
这说明上下文工程不只是 RAG 结果排序，还包括指令来源、更新频率和缓存生命周期。每类动态注入都应回答：
- 是否真的需要本轮注入，而不是按需读取？
- 是否有 Token 预算、超限降级顺序和降级打点？
- 能否区分用户原话与系统追加内容？
- 内容是否可能携带间接提示词注入？
system-reminder 是实现细节，不是行业标准 基础教程应迁移“稳定前缀 + 动态尾部”的原则，不应依赖某个标签名或快照里的精确附件数量。
Compress 的两种形态
| 形态 | 做法 | 代价 |
|---|---|---|
| 截断（Truncation） | 丢掉最旧的消息 | 简单，但会丢关键早期约束 |
| 压缩（Compaction） | 摘要历史 + 用摘要重开窗口 | 保留结构，但摘要本身会丢细节且可能出错 |
Anthropic 对 compaction 的描述很直白：把接近上限的会话内容做摘要，然后用摘要重新初始化一个新窗口。产品含义是——压缩是一次有损转换，必须回答三个问题：
- 什么必须永不丢？（任务目标、硬约束、已确认的决策、待办）
- 压缩发生时用户看得见吗？（Claude Code 会显式提示，这是个好设计）
- 压缩后能不能回溯？（原始记录是否保留、能否恢复）
本仓已有三份直接对照材料：Pi 的压缩、Codex 的两条压缩路径，以及 Claude Code 的分层压缩案例。
压缩摘要是一份恢复合同
生产级压缩不应只要求“总结前文”，而应明确规定压缩后继续任务所需的最小状态：
- 用户原始目标与全部硬约束
- 用户后续纠正和已确认决策
- 已完成事项、待办和当前进行中的步骤
- 最近关键请求的逐字引用
- 原始 Transcript 或中间产物的回溯入口
压缩顺序遵循：可逆、便宜的先做；只清理可重新获得的信息；整段有损摘要最后做；真正超限后仍有被动兜底。 压缩组件本身也可能失败，因此要有递归守卫、连续失败断路器和部分结果退出。
不要背“五层”这个数字 Claude Code 拆解中的具体层数受版本和外部构建影响，其中部分实现只能从调用点推断。应该迁移的是分层顺序、恢复合同和失败保护，而不是把五层当成通用标准。
四、Context Rot：为什么加长窗口不解决问题
三个必须能解释的现象：
- 位置偏见：开头结尾好、中间差（Lost in the Middle）。实测中"第 5～15 位是死亡区间"是个好记的说法。
- 稀释：无关内容多了，相关内容的注意力份额被摊薄。
- 冲突与污染：上下文里同时存在两条矛盾信息时，模型的选择是不可预测的——它可能挑更靠后的、更具体的，或者干脆糅合成一条不存在的规则。
上下文污染是 Agent 特有的严重问题 单次问答里，上下文是你放进去的；Agent 里，上下文是它自己一步步攒出来的。一次错误的工具返回、一段过期的检索结果，会留在窗口里影响后续每一步，并且看起来完全合理。这就是阶段 10 必须做轨迹评测的原因——只看最终答案，看不出污染是在第几步进来的。
产品对策清单：
- 关键指令放开头或结尾，不放中间
- 检索结果去重，不要同一条规则的三个版本都塞进去
- 给上下文里的每段内容标注来源与时间，让模型能识别新旧
- 工具返回只回填必要字段，不要整个 JSON 原样塞
- 明确"当上下文里有冲突时该信谁"的规则，写进系统提示词
五、知识库、Wiki、知识图谱、搜索系统：职责边界
这四个词经常被混着用，但它们回答的是不同问题：
| 系统 | 回答什么 | 权威性 | 更新方式 |
|---|---|---|---|
| 原始文档（Source） | 事实本身 | 最高 | 人写 |
| 知识库 / 检索索引 | "哪些文档相关" | 派生 | 自动构建 |
| LLM Wiki | "这个概念是怎么回事"（编译后的概念文章） | 派生，可能有编译误差 | LLM 编译 |
| 知识图谱 | 实体之间的关系 | 派生 | 抽取 |
| 搜索系统 | 按关键词找到文档 | 派生 | 索引 |
派生层永远不能当权威源 这是本仓写进 CLAUDE.md 的硬规则：wiki 文章是导航起点，结论要回到 sources: 指向的原文核对；GBrain 是跨源语义召回，命中后要钻回原始 Outline/vault 文档；代码事实只认 vfticket codescope ask。
这条规则不是本仓的洁癖，它是 RAG 系统的通用铁律：检索层可以出错，事实层不能。
本仓的三层知识系统就是一个现成案例
| 层 | 系统 | 置信度 | 升级动作 |
|---|---|---|---|
| 一手 | Vault 原始文档 | 高 | — |
| 编译 | wiki/concepts/ | 中高 | 回原文核对 |
| 跨源检索 | GBrain（Outline/vault/sessions/研究摘要/需求实现日志） | 中 | 钻回原始文档 |
| 实时 | codescope（各仓最新分支问答） | 高 | — |
阶段 3 的一个实践就是把这张表画成关系图，并回答："同一个问题问四个系统，答案不一致时该信谁？"
六、回答格式：可核验的输出长什么样
一个可用于生产的知识问答输出，至少要有四个部分：
"未知声明"是最被低估的一项 用户能接受"我没查到"，不能接受"编了一条听起来很像真的规则"。让模型显式输出 missing / not_found 字段，比在提示词里写"不要编造"有效得多——这是把约束从措辞变成结构，也是阶段 2 结构化输出的直接应用。
七、常见误区清单
| 误区 | 纠正 |
|---|---|
| "上 RAG 就不会幻觉了" | RAG 把幻觉从"凭空编"变成"基于错误上下文自信作答"，后者更难发现 |
| "召回率高就好" | 召回多了会稀释；重排后的精度比原始召回率更重要 |
| "chunk 越小越精准" | 太小会切碎规则，太大会稀释；按结构切 + 重叠是基本功 |
| "换个更好的 embedding 就解决了" | Query rewrite 和元数据过滤的性价比通常更高 |
| "长上下文会取代 RAG" | 长上下文解决容量，不解决选择、成本、时效与权限 |
| "知识库和记忆可以合并" | 一个是共享事实、一个是私有历史，混合会造成跨用户污染 |
| "压缩是技术细节" | 压缩什么时候发生、丢什么、用户是否知情，都是产品定义 |
八、外部一手资料（阶段 3 精读，约 5 小时）
| 资料 | 出处 | 读它拿什么 |
|---|---|---|
| Effective context engineering for AI agents | Anthropic，2025-09-29 | 本阶段的主教材：上下文是有限资源、compaction、子 Agent 隔离 |
| Lost in the Middle | arXiv | 位置偏见的原始证据（阶段 1 已读，这里再看实验设计） |
| Building agents with the Claude Agent SDK | Anthropic，2025-09-29 | 自动压缩与子 Agent 隔离在一个真实 SDK 里的落地形态 |
| 各家 Rerank / Hybrid Search 官方文档 | 官方 | RRF 参数、重排模型的输入长度限制等实现约束 |
本仓已有资料：
- Pi：上下文工程
- Codex：指令到底从哪来（一份真实生产系统提示词的装配顺序）
- dsh：系统提示词的装配与压缩
- Claude Code：系统提示词装配
- Claude Code：动态附件通道
- Claude Code：分层压缩案例
- Claude 5 上下文工程新规则
- Karpathy LLM Wiki 方法论
- LLM Wiki 方法论与团队实践
四份 Harness 的“指令从哪来”放在一起读 Pi 展示极简装配，dsh 展示配置化分层，Codex 展示生产提示词顺序，Claude Code 展示稳定前缀、动态附件与缓存边界。它们回答同一个问题：上下文由哪些来源组成、何时重算、如何避免动态信息污染稳定前缀。
Related Documents
- 阶段 3 实践：召回对比与错误上下文注入
- 阶段 8 讲义：记忆
- 阶段 1 讲义
- 学习路线