面向 AI+检索的 Context Engineering

00 导读：教程说明与学习路径

本教程基于 AI 搜索真实业务中的 RAG 与 Context Engineering 实践经验整理，分三篇：基础篇（01~03）、进阶篇（04~09）、全景篇（10~12）

教程服务一条主线：从 RAG（外部证据如何被找到）到 Context Engineering（模型每一步应该看到什么），讲清 AI 搜索/检索场景下「让 AI 真正懂业务」的关键技术链路。

这套教程适合谁

面向想系统学习相关技术、了解 AI 如何在真实业务场景落地的同学：

• 不需要你正在做 AI 搜索产品——教程会从背景概念讲起，再用两个真实业务案例（地图 AI 搜、百看配图）把方法落地；
• 如果你是一线工程师、想找可以直接抄的实施方案，本教程可能偏「讲理」——它更关注方法背后的为什么，以及这些经验为什么在真实业务里被验证有效。

章节地图

基础篇 · 外部证据（知识怎么找得到）

进阶篇 · 运行时上下文（模型该看到什么）

全景篇

建议读法：

• 零基础：按顺序线性读——基础篇建立 RAG 直觉，进阶篇进入 Context Engineering，全景篇拔高视野；
• 已有 RAG 基础：直接从 第四章 开始；
• 时间紧张：00-导读 → 06-核心度量-Context信噪比与优化x → 09-实战-百看配图的全链路Context设计 → 12-总结-清单与学习路线，抓「度量 + 实战」主线。

前置知识

• 用过大模型对话产品，知道 prompt 是什么；
• 不需要训练模型的经验；第三章 的动手部分需要能跑通 Python（会装包即可）。

标注约定

• [!info] 概念小课堂：为背景知识不足的同学补充的基础概念；
• [!abstract] 深层分析：围绕主线展开的深入分析（第十章整章为此类）；
• [!example] 重建示例：按业务实践中的描述重建的示例（如 prompt 模板）。

一条主线：RAG / GraphRAG 与 Context Engineering 的关系

读前需要先澄清一个常见疑问：这套教程里 RAG 和 Context Engineering 是什么关系？

一句话：RAG 是构造外部证据的一类技术；Context Engineering 是管理模型运行时可见信息的系统工程。

• RAG / GraphRAG 重点解决「去哪里找、怎样找、找回什么证据」——chunking、embedding、召回、rerank、实体关系、社区摘要、多跳检索等；
• Context Engineering 重点解决「模型当前这一步看到什么、看到多少、以什么顺序和形态看到」——检索证据只是 context 的一个来源，其他来源还包括系统规则、用户输入、事件流、规划结果、记忆、工具结果、SKILL、反馈与错误路径。

二者不是竞争关系，也不能被完全切成前后两个互不重叠的阶段。RAG 的索引与召回主要负责产生候选证据；当系统开始对候选证据做选择、去重、压缩、排序，并把它们与任务状态和其他信息组装进模型窗口时，就已经进入 Context Engineering。可以把两者的关系记成：

RAG：产生外部证据候选
          ↓
Context Engineering：选择、组织、压缩并动态更新模型可见的信息
          ↓
LLM：基于当前 context 规划、调用工具或生成答案

因此，基础篇先建立「证据怎么来」的直觉；进阶篇再讨论「证据与其他运行时信息怎么被模型有效使用」。第六章的 context 质量指标会同时受到两端影响：检索质量决定候选证据的上限，筛选与组织决定这些证据能否在有限窗口中发挥作用。

技术演进注记：RAG 在 2025~2026 年经历了一次定位迁移——长上下文与原生记忆吸收了部分「补丁型」需求（小语料问答、个人记忆检索），而企业级需求（规模、时效、权限、成本、可追溯）让 RAG 更多沉淀为知识供给底座，并向 Agentic RAG 演进。第一章 1.0 节有完整的演进梳理（截至 2026-08）。

场景选择建议：

• 单轮、文档型问答 → 基础篇的传统 RAG 往往足够，复杂的规划—反思闭环可能属于过度设计；
• 关系密集、多跳推理 → GraphRAG / KAG 可作为外部证据组织方式，与运行时 Context Engineering 叠加；
• 多步推理、工具调用、长期任务、系统内自我纠错 → 进阶篇与全景篇的主战场。

下一章：为什么需要 RAG →

01 为什么需要 RAG：大模型的局限与解法

本章是基础篇第一章。在讲 Context Engineering（进阶篇）之前，先建立外部证据与运行时上下文的区别：大模型本身有什么局限？RAG 为什么成为应用侧的重要解法？

1.0 长上下文时代，为什么还要学 RAG？

RAG 的经典材料多写于它的「补课」时代。读本章之前，先了解 2025~2026 年发生的一次定位迁移。

第一阶段：RAG 热是对上下文限制的补偿（~2025 初）。 早期模型上下文窗口很小（GPT-3.5 只有 4K tokens），「外挂知识库」是唯一出路：2022 年起 RAG 成为行业标准方案，2023 年向量数据库热潮达到峰值。当时 RAG 教程爆发式增长，教的就是这套「切块 + 向量 + top-k」的朴素流水线（Naive RAG）。

第二阶段：模型侧吸收了一部分需求（近年）。 上下文窗口冲到 1M~2M tokens（如 DeepSeek V4 把 KV Cache 压到上一代的 10%），消费级产品内置了跨会话记忆——「记忆检索」「小语料问答」这两类曾经必须自建 RAG 的场景，被模型和产品能力直接覆盖：几百页文档直接全贴进 prompt 就行。于是 2025 年下半年「RAG 已死」的论调集中出现，Chroma 创始人 Jeff Huber 甚至喊出「RAG 已死，上下文工程当立」。

第三阶段：剩下的需求被证明是结构性的，模型吃不下。

• Context rot（上下文腐烂）：Chroma 2025 年 7 月的研究（18 个前沿模型、19.4 万次调用）发现，所有模型的性能都随输入变长而下降，且远在窗口装满之前——很多任务上模型的「有效上下文」在 50K token 以内，部分任务甚至不到 10K，与标称窗口相差可达两个数量级；
• 成本与时延：工程测算显示，1M token 全量调用的单次成本约为一次 RAG 查询的千倍量级、时延高 30~60 倍；反过来，RAG 只检索 5 个相关片段，就能比全量塞入便宜 8~82 倍；
• 企业场景的五堵墙：成本、容量（中型企业文档数千万~数亿 token，装不下）、权限（按用户过滤不能靠塞 context）、精度（lost-in-the-middle）、更新（RAG 擅长差分更新，全量塞入每次都要重建）。

更准确的结论：RAG 没有消失，而是在系统中的位置发生了变化。

1. 被模型/产品吸收为内置能力：search 工具、file search、原生记忆——检索从应用层外挂变成模型的内置工具；
2. 与 Context Engineering 形成组合：检索逐渐从应用中的固定前置步骤，变成运行时可按需调用的证据来源；Context Engineering 再负责选择、组织和更新模型实际看到的信息；
3. 从单次流水线升级为 Agentic RAG：检索从「固定的第一步」变成「模型按需调用的工具」。2026 年中，所有主流 AI 搜索产品（Google AI Mode、ChatGPT Search/Deep Research、Perplexity、Gemini Deep Research）都已 agentic，一次用户查询内部触发 5~20 次子检索。但实践共识同样明确：默认先用线性 RAG，只在真正多跳/复杂的场景上 agentic（经验法则是约 80/20 的查询分流），并为 agentic 回路配齐「控制面」——迭代上限、token 预算、显式停止条件、调用追踪。

Naive RAG（切块+向量+top-k 当全部）确实死了；RAG 作为知识供给底座活着，并且从「架构决策」下沉为「成本与信噪比决策」——过去问「要不要 RAG」（不得不做），现在问「在这个环节检索一次，能省多少 token、提多少信噪比」。

这对学习本教程意味着：(1) 本章与 02、03 章的概念（分块、嵌入、召回、重排）没有过时——它们是所有新形态共享的词汇表，agentic 检索的每一次子调用依然是一次召回 + 重排；(2) 长上下文时代「信噪比」比「装得下」更重要，这正是进阶篇 第六章 的主线；(3) 带着「成本决策」的视角学基础篇——这是 2026 年学 RAG 和 2024 年学 RAG 的最大区别。

参考资料（节选）：

• 长上下文窗口、Agent 崛起，RAG 已死？— 机器之心/36氪（2025-10）
• Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma（2025-07）
• RAG 过时了吗？— 少数派（2026-03）
• 长上下文模型 vs. RAG：为什么 1M Token 上下文窗口并非万能 — tianpan.co（2026-04）
• RAG 已经过时了吗？长文本上下文时代的知识库设计 — ものしりAI（2026-04）
• DeepSeek V4 带入 1M 上下文时代：RAG 还需要吗？— 阿里云开发者社区
• RAG 已死？RAG 永生！——智能体时代的精准检索 — 火山引擎开发者社区（2025-11）
• Beyond RAG: Why every AI search platform is now agentic — Search Engine Land（2026-05）
• Agentic RAG: A Walkthrough of Retrieval as a Tool Call — SurePrompts（2026-04）

1.1 大模型面临的五个挑战

LLM 无处不在——它们在某些问题上的答案出奇地正确，在另一些问题上却得出非常有趣的错误结论。主要面临五个挑战：

① 知识截止 / 过时

LLM 是离线训练的，一旦训练完成就无法获取新的信息，因此无法回答训练数据时间点之后发生的事件，比如「今天的最新新闻」。

② 领域知识缺乏

大模型自身的知识完全源于训练数据，其训练集基本构建于网络公开数据，难以覆盖垂直行业的、非公开的、私域的数据。

③ 数据安全性

对企业来说数据安全至关重要，没有企业愿意承担数据泄露的风险——尤其是大公司，没人会把私域数据上传第三方平台进行训练推理。这导致完全依赖通用大模型自身能力的应用方案，不得不在数据安全和效果之间取舍。

④ 幻觉

LLM 出现幻觉的本质原因，是其基于概率的生成机制会优先输出「语义合理」而非「事实正确」的内容。即使是最新的旗舰模型，厂商也仍然强调：「在可靠性方面，可靠和完全可靠之间存在很大的不连续性」，建议用户仔细核对答案。

⑤ 缺乏事实依据与可追溯性

LLM 的不可追溯性源于其生成机制的本质：

• 知识存储是「黑盒」的：用于训练的海量知识被压缩为千亿甚至万亿级参数，参数化知识不可解析；
• 概率生成，而非事实检索。

举个例子：如果有人问「太阳系中哪个行星的卫星最多」，你想起读过一篇文章说是木星、有 88 颗卫星，便随口回答了。这个回答有几个问题：没有任何资料支撑（没有去寻找答案，仅凭记忆）；而且你已经很久没关注这个问题，答案可能已经过时。而如果你从 NASA 官方来源获取答案，就可以说「根据 NASA 最新的 xxx 报道显示」——科学家在不断发现新的卫星，数据一直在变化，而现在你的答案有了可信的东西为基础，并没有产生幻觉或编造答案。

[!abstract] 深层分析：五个挑战其实是两类问题

• 知识问题（①②③）：模型的知识不够新、不够专、不敢喂；
• 信任问题（④⑤）：模型的输出不敢信、没法查。

RAG 对两类问题给出的是同一个工程化解法：把知识从参数里外置出来——知识存在可更新的检索系统里，生成时临时取用，并标注来源。知识问题靠「外置 + 实时」解决，信任问题靠「事实锚定 + 来源」解决。

但有一个重要保留：RAG 只能压低幻觉，不能根除幻觉——检索结果本身是错的或无关的，生成照样会错（garbage in, garbage out）。这正是进阶篇 第六章 要花一整章讨论「context 信噪比」的原因。

1.2 RAG 是什么

一句话：RAG 把大模型从「聪明却不可靠的演讲家」升级为「随时查资料、句句有出处」的超级顾问。

RAG（Retrieval Augmented Generation，检索增强生成）是一种结合信息检索和文本生成的技术方案，通过从外部知识库检索相关信息来辅助大语言模型生成更准确、更丰富的文本内容。

基本流程：

1. 基于用户输入，从外部知识库（数据库、文档、网页）中检索与查询相关的文本片段，通常使用向量化表示和向量数据库进行语义匹配；
2. 将检索到的内容作为额外上下文输入 LLM；
3. LLM 结合检索结果和自身语言能力，生成最终答案并标注来源。

理解 RAG 的一个有效方式是类比开卷考试：

• 标准 LLM 像参加闭卷考试的优秀学生，只能依赖已记忆的知识（参数化记忆），虽可能对学科有深刻理解，但可能遗忘细节或不知新发现；
• RAG 系统 如同同一学生参加开卷考试：既利用自身智力与理解（参数化记忆）构建答案，又可查阅指定教材或笔记（非参数化记忆）获取具体事实、数据和引语，最终产出更准确、详细且可信的回答。

1.3 RAG 的优点

• 知识实时性：接入外部检索系统，生成前动态获取最新知识，突破训练完成后「知识冻结」的局限；
• 领域知识补充：接入企业私域知识库、行业文档、数据库等，覆盖训练集中缺乏的数据；
• 数据安全性：在本地私有知识库里检索领域数据、临时提供给大模型生成，既补充领域知识，又无需把数据上传训练；
• 减少幻觉：事实锚定生成——通过检索外部事实性文档，把生成限定在真实可验证的上下文中；
• 增强可追溯性：回答可附带引用来源文档或链接，用户可直接追溯，生成过程不仅「看起来合理」，还具备事实支撑和可验证性。

1.4 RAG 的缺点

• 系统架构复杂、性能延迟高：需要建立检索模块、向量数据库和生成模块，增加整体复杂性，引入额外推理延迟；
• 基础设施成本：可追溯性的背后是成本——文档需要转换为向量嵌入，向量嵌入需要存储在数据库中。

1.5 RAG、微调、提示词工程：三种优化手段的对比

RAG、微调与提示词工程都是 AI 模型优化的策略，但作用层面完全不同。

微调（Fine-Tuning）

微调是在一个已经过预训练、具备通用能力的模型基础上，再使用特定任务或领域的数据进行进一步训练，以适应新的任务或风格需求。由此，模型既保持原有的「广泛知识」，又在目标方向上获得「专项能力」——微调是模型层面上的能力改进。

微调的原理：以预训练模型的初始权重为起点，使用专门的「输入-输出」配对数据集做监督学习（比如为技术支持场景提供数千条客户查询与正确技术回答的配对），通过反向传播调整内部参数，最小化预测输出与目标响应之间的差异。这个过程不只是教模型新的事实，实际上是在修改它处理信息的方式、学习识别特定领域的新模式——所以当特别需要深厚领域专精的模型时，微调比较有优势。

[!info] 概念小课堂：灾难性遗忘与过拟合

灾难性遗忘——比喻：乐器演奏。你会弹钢琴（预训练），后来想学吉他（微调）。如果训练方法是「强制改掉手指肌肉记忆」，可能学了吉他但钢琴退步 → 遗忘；如果方法是「在已有音乐感上叠加新技能」，就能同时保留两种乐器。 本质：旧知识和新知识的参数空间重叠，新任务的梯度可能把旧能力「推走」。

过拟合——比喻：考试背题。微调数据就像一份模拟题答案：考试时遇到完全相同的题答得非常好；但换了一点点形式（比如改了问法）就答不上来 → 过拟合。 本质：小数据不足以代表真实分布，参数过度贴合这些「样本偶然性」（通常发生在训练集太小、模型过于复杂或训练轮次过多时）。

提示词工程（Prompt Engineering）

提示工程的基本原则是：好的提示等于好的结果。

提示词工程是指通过精心设计、优化输入给生成型 AI 的自然语言提示（prompt），以引导模型产生更准确、有用、高质量的输出。

问题：一个长方形的长比宽多5厘米，周长是38厘米。求这个长方形的面积。

思考过程：
1. 设宽为 x 厘米，则长为 x + 5
2. 周长公式：2 × (长 + 宽) = 38
3. 代入计算：2 × (x + x + 5) = 38
4. 展开：4x + 10 = 38
5. 解方程：4x = 28 → x = 7
6. 长 = 12，宽 = 7，面积 = 12 × 7 = 84
答案：84 平方厘米

（上面这种显式展开「思考过程」可以看作分步规划或思维链 CoT 的示例。工程上更重要的是产生稳定、可被后续模块消费的中间结果，而不一定要求模型暴露完整的隐式思考过程；第九章 会具体展示这种用法。）

优点：灵活、即时；无需训练，低成本。 缺点：寻找有效的提示需要大量试验和错误；无法扩展知识。

组合使用

三种手段并非互斥，实际中常常组合使用。考虑一个法律人工智能系统：

• RAG：实时检索法律案例库和最新法院判决文档，为模型提供当前可信的外部信息；
• 提示工程：以正确框架引导模型输出，包括法律文书格式、逻辑结构；
• 微调：在保留法律知识的基础上，注入公司专属政策条款、内部操作规范和术语。

[!abstract] 深层分析：三种手段的分层，以及它和本教程主线的关系

• 大模型的五个挑战 = 三类知识问题（截止/领域/安全）+ 两类信任问题（幻觉/不可追溯）；
• RAG = 检索增强生成：知识外置、实时取用、标注来源；记住开卷考试的类比；
• RAG 能压低幻觉但不能根除——检索质量决定上限（garbage in, garbage out）；
• 微调改参数、RAG 补知识、prompt 调行为：三者分层、常组合使用；
• RAG 不改变模型参数，而是产生外部证据；Context Engineering 再决定这些证据如何与其他运行时信息共同进入模型上下文。

思考题

1. 你手头的业务数据属于「公开知识」还是「私域知识」？这决定了你更需要微调还是 RAG 吗？
2. 「灾难性遗忘」和进阶篇 第五章 里「业务小模型被大模型升级抛弃」的现象，有什么内在联系？

参考

• 什么是微调？— IBM
• 什么是提示工程？— IBM
• RAG、微调与提示工程 — IBM
• RAG vs Fine-Tuning vs Prompt Engineering（视频）

← 导读 | 下一章：RAG 核心架构 →

02 RAG 核心架构：从分块到生成

本章是基础篇第二章。把 RAG 拆成两个阶段、五个环节：提问前（分块、索引），提问后（召回、重排、生成）。每个环节的选择都直接决定最终答案的质量上限。

2.1 数据准备阶段（提问前）

分块（Chunking）

将文档按照一定的规则和逻辑，划分为多个较小的、具有独立意义的文本单元——它们将成为知识库中用于检索和匹配的基本单位。

为什么分块：让 RAG 系统能更精准、高效地读取、检索并生成回答。合理的分段对回复效果有直接影响——分段太大，可能包含太多不相关的信息，降低检索的准确性；分段太小，可能丢失必要的上下文信息，导致生成的响应缺乏连贯性或深度。

常见的五种拆分策略：

① 固定大小分块（Fixed-size chunking）

最直观的方法：按预定义的字符、单词或 token 数量将文本分成统一的段。

特点：实现最简单；由于直接分割会破坏语义流，建议在相邻块之间保持一些重叠（图中蓝色部分）；块大小相同，简化了批处理。但有一个大问题：这通常会打断句子（或想法），重要的信息很可能分散到不同的块之间。

② 语义分块（Semantic chunking）

根据句子、段落或主题部分等有意义的单位对文档进行细分，为每个片段创建嵌入；然后从第一个片段开始：如果它与第二个片段的嵌入余弦相似度较高，两者合并为一个块；一直持续到余弦相似度显著下降——一旦发生，就开始新块并重复。这个过程有点像「合并区间」算法：

特点：与固定大小分块不同，这保持了语言的自然流畅并保留了完整的想法；由于每个块都更加丰富，提高了检索准确性，进而使 LLM 产生更连贯和相关的响应。小问题是：它依赖一个阈值来判断余弦相似度是否「显著下降」，而这个阈值在不同文档之间可能不同。

③ 递归分块（Recursive chunking）

首先根据固有分隔符（如段落或章节）进行分块；接下来，如果块的大小超出预定义的限制，就将其拆分成更小的块；如果符合限制，则不再进一步拆分。

如上图：先定义两个块（紫色的两个段落），然后第 1 段被进一步分成更小的块。特点：同样保持了语言的自然流畅并保留完整的想法，但在实施和计算复杂性方面有一些额外开销。

④ 基于文档结构的分块（Document structure-based chunking）

利用文档的结构信息（如标题、章节）进行分片。

特点：这种方法假设文档具有清晰的结构，但事实可能并非如此；块的长度可能超长，需要再递归拆分。

⑤ 基于 LLM 的分块（LLM-based chunking）

使用大语言模型判断语义边界，生成语义上孤立且有意义的块，进行动态分片。

特点：灵活性高，能适应复杂文档，可以确保较高的语义准确性；但是计算资源消耗大，而且 LLM 的上下文窗口是有限的。

[!abstract] 补充：Contextual Retrieval——给切块「补回上下文」（2026-08 更新）

上面五种策略都解决不了分块的一个根本副作用：chunk 失去文档级背景——「公司收入比上一季度增长了 3%」，单看这一块不知道是哪家公司、哪个季度。Anthropic 的 Contextual Retrieval 在分块与索引之间加了一步：先让模型为每个 chunk 生成一段简短的背景说明，再把「背景 + 原 chunk」一起做 embedding 和 BM25 索引。其报告的实验结果：top-20 检索失败率降低 35%（仅 Contextual Embedding）/ 49%（叠加 Contextual BM25），结合重排后还能进一步降低（厂商工程博客数据）。

这是性价比很高的增量环节：不换模型、不动架构，只改离线预处理。更多 2026 年的检索前沿见 第十一章。

索引（Embedding + 向量数据库）

索引就是通过 Text Embedding（文本嵌入）模型将片段文本转换为向量，并且将片段文本和片段向量存入向量数据库中。

Text Embedding：一种通过学习，将离散的、高维的数据映射到一个低维且连续的向量空间的方法，能够将原本庞大、稀疏或难以处理的输入表示成更简洁且便于机器理解的形式。文本嵌入捕捉了文本的语义特征——相似文本在向量空间中会更接近，从而实现语义上的相似性比较。

向量数据库（Vector Database）：一种专门用来存储和查询高维向量的数据库，Embedding 后的向量就放在里面，方便后续查询。

要注意：要存的不仅有向量，还有原始文本——只有这样，才能在通过向量相似度查询出相似的向量之后，把对应的原始文本也抽取出来发给大模型。所以一般的向量数据库表格里至少都有「原始文本」和「向量」两列内容：

2.2 检索生成阶段（提问后）

召回：高效检索相关文档

目标：从庞大的文档库中快速识别出与查询最相关的候选文档，以减少后续处理的负担。召回是一个粗筛的过程。

流程：用户的问题先发给 Embedding 模型转换为向量，然后把向量发给向量数据库，查询与问题最相关的 Top-K 个片段内容。

召回阶段有时不单单使用向量检索，也会结合传统的关键词检索，利用各自的优势提高检索效果。

特点：成本低、耗时短、准确率低。

向量相似度的计算方法：

• 余弦相似度：衡量两个向量之间夹角的余弦值，反映方向相似度。夹角越小，相似度越高；
• 欧式距离：计算两个向量在空间中的直线距离。距离越小，相似度越高；
• 点积：两个向量对应元素乘积的和。乘积越大，相似度越高。

向量相似度检索算法：根据向量库规模和维度，分为精确检索（小数据）和近似检索 ANN（大数据/高维）两类。

• 精确搜索（k-NN）：遍历所有向量，逐一计算与查询向量的相似度，返回 Top-K 结果。精确但计算复杂度高，O(N·d)（N 为数据规模，d 为维度）。
• 近似搜索（ANN）：在大规模或高维场景中，牺牲部分精度换取速度提升：

算法类别	代表算法	核心原理	特点
树结构类	KD-Tree、Ball-Tree	将向量空间递归划分为子区域（如 KD-Tree 按维度切分），检索时仅遍历目标子区域	低维数据（D<20）下效率高、易实现；高维数据（D>50）时「维度灾难」，效率骤降
哈希类	LSH（局部敏感哈希）	设计「哈希函数」，使相似向量大概率映射到同一哈希桶，检索时仅遍历同桶向量。与传统哈希追求最小冲突不同，LSH 希望最大化相似数据的碰撞概率	高维数据友好，查询速度快
量化类	PQ（乘积量化）、SQ（标量量化）	将高维向量拆分为低维子向量（PQ），或对每个维度单独量化（SQ），用「量化码」替代原始向量存储	内存占用极低（压缩比高），适合超大数据
图结构类	HNSW（Hierarchical Navigable Small World）	把近邻图做成多层结构：最底层包含所有数据点形成密集近邻图，上层仅包含底层点的子集、层级越高越稀疏。查询时先在顶层粗略「跳跃式」导航、快速缩小搜索区域，再逐层下沉到更密集的层做精排。	高维数据效率优，精度接近精确检索；构建图的时间成本较高，内存占用略高

重排：精细排序候选文档

目标：对召回阶段获取的候选文档进行精细排序，提升检索结果的相关性和准确性。重排是一个精排的过程。

常用方法：Cross-Encoder 模型——将查询和候选文档作为一对输入，使用预训练模型（如 BERT、RoBERTa）进行联合编码，计算两者的深度语义相关性得分。

特点：成本高、耗时长、准确率高。

召回就像简历筛选，重排就像对候选人进行面试。

智能体平台会将召回结果的得分直接展示给用户，容易获得用户信任：

生成

把重排筛出的 N 个片段和用户的问题，按照 prompt template 组成一个增强的 prompt——这一步叫上下文构建——发给大模型，产出最终答案。

2.3 全流程总结

1. 提问前（准备）：文档分片 → 所有片段交给 Embedding 模型产出对应向量 → 向量存入向量数据库。到这里，知识库就构建好了；
2. 提问后（回答）：用户问题 → Embedding 模型转为向量 → 向量数据库找到 K 个最相近片段（召回）→ Cross-Encoder 重排、从 K 个里筛出 N 个得分最高的 → N 个片段 + 用户问题做上下文构建 → 大模型产出最终答案。

[!abstract] 深层分析：这条流水线的每一环，都在做同一件事——提升信噪比

换个视角看五个环节：

• 召回求「全」：宁可多召回一些噪音，也不能漏掉关键信息（所以 Top-K 的 K 是「覆盖 vs 噪音」的第一个旋钮）；
• 重排求「准」：把粗筛的候选压缩成高信号的小集合（K → N，第二个旋钮）；
• 生成求「用」：上下文构建决定这些信息以什么形态进入模型。

整条流水线可以理解为从候选证据到可用 Context 的逐步收敛：分块和索引决定能否找到候选，召回与重排决定候选证据的质量，后续的筛选、压缩和组装则决定模型实际看到什么。第六章 会继续讨论如何用 x% 等代理指标评估这一过程；第十章 则把检索、Context 组装和生成放回完整的 AI 搜索链路。

另一个容易被低估的杠杆是分块：它是供给侧的第一质量关口。分块如果把关键信息切散了，后面向量检索、重排、生成整条链路都救不回来——垃圾进，垃圾出。

本章要点

• RAG = 两阶段五环节：分块、索引（提问前）；召回、重排、生成（提问后）；
• 分块五种策略各有取舍：固定大小 / 语义 / 递归 / 文档结构 / LLM；
• 召回（粗筛：便宜快，准确率有限）+ 重排（精排：贵但准）是检索的标准两段式；
• 向量检索算法：小规模用精确 k-NN，大规模用 ANN（实践中 HNSW 最常用）；
• 全流程是信噪比逐级提升的流水线——这是理解进阶篇的钥匙。

思考题

1. 为什么重排比召回准得多、却只能处理少量候选？（提示：想想 Embedding 双塔「各自独立编码、一次计算可复用」和 Cross-Encoder「查询-文档成对联合编码」的输入方式差异。）
2. 如果分块不小心把「广东好太太」和「江苏好太太」两家公司切进了同一个块，下游各环节会发生什么？（带着这个问题去读 第九章 的「同名多义」案例。）

参考

• 5 Chunking Strategies for RAG
• RAG 工作机制详解——一个高质量知识库背后的技术全流程（视频）
• 相似度检索算法参考（arXiv:1603.09320）

← 上一章 | 下一章：动手实践 →

03 动手实践：Python 构建最小 RAG 与智能体平台对比

本章是基础篇最后一章。前两章讲了「为什么」和「怎么构成」，本章动手：先用约百行 Python 把 上一章 的五个环节逐个实现一遍，再明确「检索结果」如何进入运行时 Context，最后看两个成熟智能体平台（文心、扣子）把同样的能力做成了什么产品形态。

3.1 用 Python 构建最小 RAG

分块

读取一个 Markdown 文档，按照空行（两个换行符）将其分割成多个文本块：

from typing import List

## 文档分块函数，返回一个字符串列表
def split_into_chunks(doc_file: str) -> List[str]:
    with open(doc_file, 'r') as file:
        content = file.read()

    return [chunk for chunk in content.split("\n\n")]

chunks = split_into_chunks("doc.md")

for i, chunk in enumerate(chunks):
    print(f"[{i}] {chunk}\n")

索引

用 sentence-transformers 加载中文 Embedding 模型（shibing624/text2vec-base-chinese），把片段转换为 768 维向量：

from sentence_transformers import SentenceTransformer

## 使用 SentenceTransformer 对象加载一个 Embedding 模型
embedding_model = SentenceTransformer("shibing624/text2vec-base-chinese")

## 获取某个给定片段对应的向量
def embed_chunk(chunk: str) -> List[float]:
    # 使用刚才加载的 Embedding 模型来获取片段对应的向量值
    embedding = embedding_model.encode(chunk, normalize_embeddings=True)
    return embedding.tolist()


embedding = embed_chunk("测试内容")
print(len(embedding))
print(embedding)

循环调用，给所有片段都生成对应的向量，然后连同原文一起存入向量数据库（chromadb）：

embeddings = [embed_chunk(chunk) for chunk in chunks]

## 向量数据库：chromadb
import chromadb

## 创建 chromadb 客户端
chromadb_client = chromadb.EphemeralClient()
chromadb_collection = chromadb_client.get_or_create_collection(name="default")

## 把所有的片段内容和对应的向量都存入数据库中
## chunks - 片段内容列表
## embeddings - 片段向量列表
def save_embeddings(chunks: List[str], embeddings: List[List[float]]) -> None:
    for i, (chunk, embedding) in enumerate(zip(chunks, embeddings)):
        chromadb_collection.add(
            documents=[chunk],
            embeddings=[embedding],
            ids=[str(i)]
        )

save_embeddings(chunks, embeddings)

召回

## 召回函数
## query - 用户问题
## top_k - 要召回的记录数量
def retrieve(query: str, top_k: int) -> List[str]:
    # 将用户的问题转换为向量
    query_embedding = embed_chunk(query)
    results = chromadb_collection.query(
        query_embeddings=[query_embedding],
        n_results=top_k
    )
    return results['documents'][0]

query = "哆啦A梦使用的3个秘密道具分别是什么？"
retrieved_chunks = retrieve(query, 5)

for i, chunk in enumerate(retrieved_chunks):
    print(f"[{i}] {chunk}\n")

观察结果：答案在索引为 1 的片段中，但它没有排在最上面——向量数据库认为索引 0 的片段最匹配。看来向量相似度检测的准确性确实欠佳，这印证了上一章的判断：召回是一个粗筛的过程。好在包含答案的片段召回成功了，只是排序有问题。

重排

## 重排阶段使用 CrossEncoder 模型
from sentence_transformers import CrossEncoder

## 重排函数
def rerank(query: str, retrieved_chunks: List[str], top_k: int) -> List[str]:
    cross_encoder = CrossEncoder('cross-encoder/mmarco-mMiniLMv2-L12-H384-v1')
    # pairs 列表的每一个元素都是用户问题 query 加一个召回片段
    pairs = [(query, chunk) for chunk in retrieved_chunks]
    # 让 cross_encoder 模型给每一个片段打分（分值代表用户问题与对应片段内容的相似度）
    scores = cross_encoder.predict(pairs)

    # 将召回片段和对应分数存入列表
    scored_chunks = list(zip(retrieved_chunks, scores))
    # 列表按分数倒序（得分高的更靠前）
    scored_chunks.sort(key=lambda x: x[1], reverse=True)

    return [chunk for chunk, _ in scored_chunks][:top_k]

reranked_chunks = rerank(query, retrieved_chunks, 3)

for i, chunk in enumerate(reranked_chunks):
    print(f"[{i}] {chunk}\n")

重排后，包含答案的片段得分最高、排到了第一名的位置。重排阶段所使用的 CrossEncoder 模型，可以非常准确地识别哪些片段与用户的问题最为相关。

生成

把重排后的片段和用户问题按模板组成 prompt（上下文构建），调用大模型（示例用 gemini-2.5-flash，API key 在 Google AI Studio 获取）：

from dotenv import load_dotenv
from google import genai
from typing import List

load_dotenv()
google_client = genai.Client()

def generate(query: str, chunks: List[str]) -> str:
    prompt = f"""你是一位知识助手，请根据用户的问题和下列片段生成准确的回答。

用户问题: {query}

相关片段:
{chr(10).join(chunks)}

请基于上述内容作答，不要编造信息。"""

    response = google_client.models.generate_content(
        model="gemini-2.5-flash",
        contents=prompt
    )

    return response.text

answer = generate(query, reranked_chunks)
print(answer)

[!abstract] 深层分析：把代码映射回架构

代码函数	架构环节	关键旋钮
split_into_chunks	分块	切块规则（这里是最朴素的空行切分）
embed_chunk + save_embeddings	索引	Embedding 模型选型
retrieve(query, 5)	召回	top_k=5：覆盖 vs 噪音
rerank(..., 3)	重排	5→3：信噪比压缩
generate 里的 prompt 模板	生成（上下文构建）	「请基于上述内容作答，不要编造信息」

这个玩具系统虽然简陋，但旋钮一个不少：top_k、重排阈值、prompt 模板，每一个都对应 第六章 要深入讨论的「x%」优化点。另外注意 generate 里那句「不要编造信息」——这就是最原始的「事实锚定」指令，回应的正是 第一章 的幻觉问题。

3.2 从检索结果到运行时 Context

前面的代码已经完成了一个最小 RAG：文档被切成片段，片段被索引，问题召回候选，候选经过重排后交给模型生成答案。但这里还缺一个关键的概念桥：召回结果不等于模型最终看到的 Context。

在最小 RAG 中，Context 可能只是下面这样的一段拼接文本：

用户问题 + 重排后的若干片段

在真实 Agent 或 AI 搜索系统中，模型看到的内容通常还包括：

• 系统规则与输出约束；
• 用户当前问题和历史任务状态；
• 检索到的文档、结构化数据或多模态素材；
• 工具调用结果与执行错误；
• 当前规划、待办事项和已完成步骤；
• 记忆、领域 SKILL、反馈以及必要的重试信息。

因此，RAG 与 Context Engineering 的关系可以用下面的流程表示：

文档 / 数据源
    ↓
RAG：分块 → 索引 → 召回 → 重排
    ↓ 产生外部证据候选
Context Engineering：筛选 → 去重 → 压缩 → 排序 → 与任务状态组装
    ↓
模型：规划、调用工具、校验或生成答案

可以把两者的职责区别记成：

这个区别也解释了为什么「检索质量好」并不自动等于「模型回答好」：检索结果可能重复、过长、互相矛盾，或者没有和当前任务目标对齐。相反，Context Engineering 也不能凭空制造知识——如果外部证据没有被召回，后续的筛选和组织只能在有限信息上做更好的取舍。

从本节开始，教程会从「如何获得证据」逐步转向「如何管理模型实际可见的全部信息」。这就是后续 Context Engineering 章节的入口。

3.3 智能体平台的 RAG：文心 vs 扣子

知识库是智能体平台 RAG 能力的载体。 下面聚焦文心智能体平台与扣子知识库能力的核心结论与关键差异。

数据接入

数据处理能力：分段

两家都支持自动分段和自定义分段（分段方式、最大段落字符数、段落重叠字符数），差异在细节：

• 默认值：扣子的一个小优化细节是——自定义分段的三个字段都给了默认值，用户会顺着默认值点击；文心没有默认值，用户很多时候会纠结该给多大的数字；
• 重叠度单位：扣子的分段重叠度是百分比，文心是固定字符数——百分比重叠的上下文连贯性更好，而且更灵活；
• 按层级分段（扣子独有）：根据文档的目录结构、章节划分等层级信息切分文本单元；预览时支持拖拽调整层级结构、按层级合并为切片、删除切片等高级操作。对结构层次明确、需要按章节检索的文档非常有用，实操中召回效果远超预期；缺点是处理复杂度高、灵活性较低。文心目前不支持。

数据检索能力

智能体关联知识库后，通过检索和召回配置来解决「从哪里查、怎么查、返回几条」的问题。两家都支持召回配置：

一个值得注意的实测 case：文心平台按人设设定，能识别「这是前端相关问题、需要检索知识库」，也能识别「问题不属于前端范畴」——但不知道为什么还是检索了知识库：

扣子的按需调用则表现符合预期：前端问题则检索知识库，非前端问题则不检索。

总结

• 文心智能体平台支持多模态场景，能够兼容更多数据格式，在数据接入层面具备优势；
• 扣子在数据格式支持上相对精简，但架构灵活，在数据处理能力（分段、检索配置）方面表现更突出。

[!abstract] 深层分析：平台配置项背后的概念映射

不要把这些配置当成零散的产品功能——它们每一个都是 上一章 概念的产品化：

平台配置	对应概念
自定义分段 / 按层级分段	Chunking 策略（02 章五种策略的产品化子集）
混合检索 / 语义检索 / 全文检索	召回策略（向量 + 关键词混合）
结果重排开关	Cross-Encoder 精排
来源配置	RAG 的可追溯性（01 章）
调用方式（指令 / 强制 / 按需 / 自动）	触发策略——「该不该检索、该不该用知识库」

最后一行尤其值得注意：第十章 会把「触发层」列为 AI 搜索最被低估的策略点——哪些 query 该触发、以什么形态触发。智能体平台里的「调用方式」配置，正是触发策略在平台形态下的样子；而文心「不该检索却检索了」的实测 case，就是一次典型的触发策略误判。

本章要点

• 百行 Python 即可复现 RAG 五环节：分块、索引、召回（top_k）、重排（K→N）、生成（prompt 模板）；
• 实测印证理论：召回粗筛会排错序，CrossEncoder 重排能纠正；
• 平台对比：文心强在多模态数据接入，扣子强在分段与检索配置；配置项本质是 RAG 概念的产品化；
• RAG 负责产生外部证据候选，Context Engineering 负责把证据与任务状态组装成模型当前可见的上下文；
• 「调用方式」配置 = 触发策略的产品化形态——为 第十章 埋下伏笔。

动手练习

1. 跑通本章代码，把分块策略从「空行切分」换成「固定长度 + 重叠」，对比同一 query 的召回结果变化；
2. 把 top_k 从 5 调到 2，观察重排和生成的变化——体会「覆盖 vs 噪音」的权衡；
3. 在有平台条件的同学，把同一份文档分别用「自动分段」和「按层级分段」建库，对比同一批 query 的回答质量。

思考题

1. 文心「识别到非前端问题、却仍检索了知识库」，如果你来修这个 bug，你会从哪一层入手？
2. 平台把越来越多环节「默认化」（默认查询改写、默认重排），对用户是友好还是失控？边界在哪？

参考

• 文心智能体平台知识库文档
• 扣子知识库限制说明
• 使用 Python 构建 RAG 系统——用代码还原 RAG 系统的每个细节（视频）

← 上一章 | 下一章（进阶篇）：什么是上下文工程 →

04 什么是上下文工程：从 Prompt 工程到系统化信息管理

本章是进阶篇的第一章。基础篇（01~03）解决了「外部证据怎么找到」；从本章开始进入 Context Engineering 本体——模型每一步应该看到什么。先回答三个问题：为什么 Prompt 工程不够用、上下文工程到底是什么、它有哪些系统性手段。

4.1 为什么 Prompt 工程不够用

OpenAI 总裁 Greg Brockman 多次公开表示「2025 年是 AI 智能体的元年」，而决定智能体成败最关键的因素是上下文质量。当智能体需要进行数百轮复杂交互时，如何选择、压缩、排序和更新上下文，直接决定它的成败。

Prompt 工程本身没问题——它是一把好用的小锤子，但面对复杂任务会力不从心。五个结构性局限：

• 单轮静态：针对单次交互优化，缺乏对多轮对话和长期任务的系统性支持；
• 无持久记忆：无法在会话间保持信息，系统无法学习偏好、积累经验；
• 信息利用效率低：每次对话重复提供背景信息，浪费 token；
• 难处理多模态：主要局限于文本处理；
• 难支持长期任务规划：缺乏对任务分解、状态管理和执行监控的系统性支持。

两者不是替代关系：Prompt 工程控制「思维方向」，上下文工程提供「思维素材」——前者负责局部优化，后者负责全局协调。

4.2 定义与七组件

上下文工程（Context Engineering）是一门专注于优化大模型上下文窗口使用的技术学科：在扩展的上下文空间中有效地组织、结构化、检索和利用信息，最大化模型的理解能力和输出质量。四个核心要素：信息组织、动态管理、信息检索、质量优化。

上下文可以表示为 C = A(c₁, c₂, ..., cₙ)——A 是组装函数，cᵢ 是各类信息组件。它构建的是一个系统，而非一个字符串：最终提交给模型的完整输入，是这个信息系统运行的结果，而非一个静态文本模板。

典型上下文窗口由七种信息组件构成（标注本教程的对应深入章节）：

四个特点：

• 它是一个系统，而非一个字符串；
• 它是动态的：为当前任务即时组装——某个请求需要日历数据，另一个可能需要邮件内容或搜索结果；
• 强调在恰当时机提供恰当信息与工具：核心任务是确保模型不漏掉关键细节（谨记「垃圾进，垃圾出」），只在必要且有益时才提供知识和工具；
• 注重格式：简洁的摘要远胜于原始数据罗列，清晰的工具接口定义远胜于模糊指令。

4.3 四种失效模式

更长的上下文不一定产生更好的响应。上下文过载时，应用会以意想不到的方式失败——四种典型失效模式：

• 上下文污染（Context Poisoning）：幻觉或错误内容进入上下文并被反复引用 → 解法见 第六章（信噪比）与 第十章（验证三层）；

• 上下文干扰（Context Distraction）：上下文太长，模型过度关注上下文，反而忽略训练期学到的内容；

• 上下文混淆（Context Confusion）：模型使用上下文中的多余信息生成低质量响应；

• 上下文冲突（Context Clash）：上下文中的部分内容相互矛盾 → 解法见 第九章（隔离与解耦）。

[!info] 概念小课堂：这不是洁癖，是物理约束。

长上下文的有效利用远低于标称窗口——Chroma 2025 年的 Context Rot 研究显示所有受测模型的性能都随输入变长而下降（详见 第一章 1.0 节）。所以「管理上下文」不是可选项，而是必选项。

4.4 管理策略总览：写入、选择、压缩、隔离、组装

业界（LangChain 等）把上下文管理归纳为四类策略；加上「组装」，正好对应本教程后续章节——可以把本节当作进阶篇的地图：

压缩一栏的具体技术值得在这里补一句（后续章节不再展开）：

• 上下文摘要：用 LLM 把检索信息压缩成摘要再进窗口——省 token，但可能丢失细节或引入错误概括；
• 上下文修剪：用专门模型按问题剪掉无关句子（如 Provence，arXiv:2501.16214，几行代码即可调用）；
• 基于模型的先进压缩：gist tokens（把长指令蒸馏成几个前缀 token）、IC-Former（交叉注意力压缩成摘要向量，独立于主模型运行，速度极快）。

4.5 记忆架构：三层记忆与八种策略

LLM 天生无状态——每次交互都是独立的，除非我们把过去的信息显式放入当前窗口。这是全教程唯一系统讲记忆的一节。

三层记忆：

• 短期记忆：对话缓冲区，保存当前会话历史。防窗口爆炸的两种策略：滚动窗口（只留最近 N 轮）、摘要缓冲（定期用 LLM 摘要旧对话）；
• 长期记忆：跨会话持久化（用户偏好、重要事实、会话摘要），通常用向量数据库实现——像 RAG 一样按当前对话检索注入；也可以由 LLM 在会话结束时自动生成摘要入库；
• 暂存区（Scratchpad）：单个复杂任务的工作记忆——中间思考、计算结果写在主上下文之外，后续步骤选择性读回。既避免冗长思考链污染主上下文，又保留完整推理轨迹。Anthropic 多智能体研究系统的例子：主研究员把计划保存到内存，因为上下文超过 200K token 会被截断，而保留计划非常重要。

八种记忆策略对照：

[!abstract] 深层分析：记忆策略就是「触发层 + 信噪比」在跨会话场景的应用

分层记忆的「晋升机制」决定什么该写入长期库——这是一个触发决策（参见 第十章 触发层与 BabeL-O 案例：默认不写入、显式 cue 才触发）；「检索哪些记忆注入当前窗口」是信噪比决策（第六章）。记忆不是独立的新问题，而是教程主线在跨会话场景的延伸。

4.6 安全与一致性

• 上下文净化：PII（个人身份信息）脱敏与策略检查，确保敏感信息被安全处理；
• 基于角色的访问控制：只让授权角色访问对应信息——企业场景的刚需；
• 提示注入缓解：防范操纵模型行为的恶意输入——注意检索回来的内容同样是不可信输入；
• 隔离：严格隔离不同任务、子智能体、会话线程的上下文，防止干扰和「上下文冲突」。

4.7 评估与理论（指针）

上下文管理的指标体系（上下文准确性、相关性/精确率、完整性/召回率、时效性、效率，以及 Ragas 四指标）已系统整理在 第十章 反馈层的 L1/L2/L3 速查表，本章不重复展开。

[!info] 概念小课堂：认知科学视角。

上下文管理可以参考 Baddeley 的人类工作记忆模型：中央执行器（注意力控制与协调）、语音回路（语言信息）、视觉空间画板（视觉信息）、情景缓冲器（多源整合）——分层记忆架构正是「长短期记忆分层管理」的工程对应物。

本章要点

• Prompt 工程控制思维方向，上下文工程提供思维素材；后者是系统而非字符串；
• 上下文七组件，每种在本教程都有对应深入章节；
• 四种失效模式（污染/干扰/混淆/冲突）是后续章节要解决的对象；
• 管理策略 = 写入/选择/压缩/隔离/组装；记忆是其中最易被忽视的一块（三层记忆 + 八种策略选型）；
• 安全（PII、注入、权限、隔离）是生产级上下文工程的底线。

思考题

1. 用七组件盘点一个你熟悉的 AI 应用：它缺哪个组件？缺的那块是不是它当前效果的瓶颈？
2. 你的场景该选哪种记忆策略？如果今天只能选一种起步，你选哪个、为什么？

← 上一章 | 下一章：为什么聚焦 Context，而不是训练模型 →

05 为什么应用团队通常优先聚焦 Context，而不是训练基础模型

本章回答：优化 AI 应用效果时，资源应该优先投向基础模型训练、领域微调，还是 Context Engineering？这里不是要证明「训练模型没有价值」，而是建立一套适用于应用团队的路线判断框架。

一道面试题：从 0 训练一个 32B 模型要多少钱？

从 0 训练一个模型，成本不只包括 GPU 租赁，还包括数据清洗、训练基础设施、实验失败、评测、部署和后续维护。以 Chinchilla 缩放定律给出的经验配比做一个量级示意：32B 参数模型如果按约 20 倍参数量准备训练 token，训练数据规模大约是 640B tokens，理论计算量可写成：

FLOPs ≈ 6 × 参数量 × 训练 token 数

这个公式可以帮助我们理解成本量级，但不能直接当成普适报价。实际费用会受到硬件型号、并行效率、训练轮数、数据质量、失败重跑次数以及是否包含完整工程团队等因素影响。一个常见的量级估算是 350 万 ~ 1000 万 RMB，应理解为特定假设下的估算，而不是所有 32B 模型训练项目的固定价格。

更重要的问题不是「能不能训练」，而是：一个应用团队是否应该把最稀缺的人力投入到和基座模型竞争的资产上？ 如果任务分布变化快、基座模型迭代快、领域知识需要频繁更新，那么自训基础模型很可能在上线后迅速折旧。

[!info] 概念小课堂：Chinchilla 缩放定律与「6」的来源

Chinchilla（DeepMind，2022）的核心结论是：在给定算力预算下，模型参数量和训练数据量需要大致协调扩张。经验值约为训练 token 数是参数量的 20 倍，但它描述的是特定训练目标与假设下的计算最优关系，不等于每个业务微调项目都必须遵守的配方。

FLOPs 公式中的 6 是一个常用的训练计算量近似：正向传播约 2 FLOPs/参数/token，反向传播约 4 FLOPs/参数/token，合计约 6 FLOPs/参数/token。它用于做量级估算，不能替代真实的集群测算。

先区分四种路线：不要把「训练」和「Context」当成二选一

应用团队面对的通常不是简单的「训练基础模型 vs 不训练」，而是几种不同层级的选择：

这几条路线可以组合使用。例如，一个系统可以用 RAG 提供最新政策，用 SKILL 注入判断标准，用大模型完成规划，再用小模型做高频相关性判断。选择重点不在于“哪条路线永远正确”，而在于当前瓶颈在哪一层。

业务小模型为什么容易被抛弃

地图团队的踩坑复盘印证了一个常见现象：过去 2~3 年训练的部分业务小模型（8B/32B），随着业界基座模型升级而逐步退出主链路。常见原因有三类：

1. 无法高效享受基座模型升级的红利——自训模型锁定在某个能力代际，而基座模型持续迭代；
2. 迭代效率低——样本构建、训练、评测、部署和回滚链路，通常比调整 prompt、Context 或工具策略更长；
3. 新场景泛化不足——模型在初始任务上表现不错，但新需求、新表达或新工具出现后，很快被更强的通用模型追平。

这并不意味着业务小模型没有价值，而是要问：它是否在一个足够稳定、足够高频、且对性能足够敏感的环节中创造了确定收益？ 如果答案是否定的，早期投入更适合优先沉淀到执行框架、评测集、SKILL、差异化工具和高质量数据上。

判断标准：产品的性能容忍度与任务稳定性

「性能容忍度」是一个重要标准，但不应是唯一标准。建议至少从以下几个维度判断：

• 时延与成本：是否必须端侧运行？是否处于高频、低延迟路径？
• 任务稳定性：输入分布是否稳定，评价标准是否长期不变？
• 知识更新频率：知识是否经常变化，是否要求实时更新和可追溯？
• 泛化要求：是否需要处理大量长尾、开放域和新场景？
• 数据与评测能力：是否有持续产生高质量样本和可靠评测的能力？
• 部署与合规：是否必须私有化、离线化或完全自主可控？

一个实用的决策顺序是：

先确认产品约束与当前瓶颈
          ↓
能否通过更好的 Context、检索、工具和评测解决？
          ├─ 能 → 优先做应用层工程
          └─ 不能 → 判断是否需要微调、蒸馏或小模型
                         ↓
              只有在任务稳定、收益可验证时再扩大训练投入

如果性能和成本仍在可接受范围内，通常可以先使用能力更强的模型，优先把效果上限打出来，再通过控制生效影响面、缓存、路由、压缩和小模型替换逐步摊薄成本。不要在还没有确定效果上限之前，就过早地为了成本牺牲结果质量。

深层分析：这是「苦涩的教训」在应用工程中的一次复现

有一张流传很广的图叫「奇技淫巧不敌通用方法」，它可以和 Rich Sutton 的 The Bitter Lesson（苦涩的教训） 对照理解：长期来看，依赖人工固化知识的专门方案，往往会被依赖算力、数据和通用学习能力的方案追上。

换一个资产折旧的视角看，会更清楚：

所以「训练 vs Context」本质上是投资组合问题：把人力投向哪些资产，能在基座模型升级后继续产生价值？

什么时候训练仍然值得

以下场景中，微调、蒸馏或小模型训练可能是合理选择：

• 极端时延或成本约束：端侧、超高频判别、传统搜推内部的 query 理解和相关性判断等；
• 任务分布高度稳定：输入、输出和评价指标都相对固定，且有足够样本支持持续评测；
• 已有成熟数据飞轮：线上反馈能稳定转化为训练样本，模型收益可以被量化验证；
• 合规与部署约束：必须私有部署、离线运行或不能依赖外部模型 API；
• 需要稳定风格或格式：微调比复杂的运行时指令更容易提供一致输出。

最终仍然要回到一个问题：训练带来的增益，是否足以抵消数据、部署、维护和模型折旧成本？

本章要点

• 不要把基础模型训练、微调、RAG 和 Context Engineering 简化成互斥路线；
• 对多数以应用落地为目标的团队，先做 Context、检索、工具、评测和数据供给，通常比训练基础模型更容易验证价值；
• 业务小模型不是天然错误，关键看任务稳定性、时延/成本约束、数据飞轮和可验证收益；
• 「性能容忍度」是重要判断标准，但还要结合知识更新、泛化、合规和维护能力；
• 更好的投资目标，是沉淀能随基座模型升级继续产生价值的应用资产。

思考题

1. 你所在的业务当前真正的瓶颈是模型能力、检索供给、Context 组织、工具执行，还是评测反馈？为什么？
2. 盘点一下你所在团队的资产：哪些会随着大模型升级而升值，哪些会快速折旧？
3. 如果一个小模型能把时延降低 80%，但只能覆盖 70% 的请求，你会如何设计路由和兜底？

← 上一章：动手实践 | 下一章：核心度量 →

06 核心度量：Context 质量、信噪比与「优化 x%」

本章回答：AI 搜索的优化目标到底是什么？——如何把模糊的「效果更好」拆成可度量、可归因、可持续迭代的工程指标。

从一个设问开始

怎么优化 AI 搜的回答质量和幻觉问题？直觉答案往往是：

• 通过强化学习优化 planner 的规划？
• 优化 writer 的对齐？
• 更换更强的模型？

地图团队给出的经验是：当系统瓶颈位于证据供给、筛选和组织时，提升 Context 质量是最直接有效的优化方式。

这个限定很重要：Context 不是所有问题的唯一答案。如果问题来自模型能力不足、工具执行错误、产品交互不合理或评价目标本身错误，只提高 Context 质量并不能根治。但在 AI 搜索中，错误、过时、重复或缺失的证据经常是结果不满足的直接来源，因此 Context 通常是优先排查的杠杆。

技术抽象：优化 x%

提升 AI 搜效果的一个有效技术抽象是：优化 x%。

这里的 x% 不应被理解成天然存在、可以直接测量的唯一真值，而应理解为：

团队围绕 Context 质量定义的一组代理指标，以及一次改动相对基线带来的可验证增益。

不同业务可以有不同的 x：检索证据有效率、窗口内有效 token 占比、关键事实覆盖率、引用支持率、冗余率下降、单位 token 的答案贡献度，或者由多项指标组合而成的评分。

[!info] 概念小课堂：什么是 Context 的「信噪比」？为什么不能无限堆？

把 context 窗口想成模型的「工作记忆」。与当前任务直接相关、能补充证据、帮助消歧或约束行为的信息，可以视为信号；无关、重复、过时、错误或彼此冲突的信息，则可能成为噪音。

不能靠「无限堆料」解决问题，原因有三：

1. 注意力会被稀释：模型对长 context 中不同位置的信息利用并不均匀，关键证据可能被埋没；
2. 噪音会主动误导：错误或过时的检索结果不是单纯「没用」，而可能成为错误生成的依据；
3. 成本随长度增长：更多 token 意味着更高时延、推理费用和缓存压力。

但真实信息并非总能被二分成信号和噪音。一条证据可能不被最终答案直接引用，却承担了消歧、校验或规划作用。因此，信噪比更适合作为指导筛选和压缩的工程抽象，而不是简单统计「使用/未使用」的比例。

Context 质量至少包含八个维度

如果只优化「相关性」，很容易得到一组看似相关、实际重复且缺少关键事实的材料。一个更完整的 Context 质量框架至少包括：

所以 x% 的本质不是单纯「越短越好」，而是：

在有限的窗口、时延和成本预算下，提高完成当前任务所需信息的有效覆盖，并降低重复、错误和无关内容。

这个抽象带来三个推论：

• 重视差异化内容的积累——如果供给中没有关键事实，筛选层无法凭空创造；
• 重视搜索效果的优化——召回与重排决定候选证据的质量上限；
• 把 Context 质量作为训练或策略优化的重要奖励信号之一——但不能让它替代最终答案质量和用户价值。

三层指标：Context、答案与业务结果

为了避免把代理指标当成最终目标，建议建立三层评测：

三层不能互相替代：

• Context 指标提升但答案没变，可能是模型没有正确使用证据；
• 答案离线分数提升但线上满意度没变，可能是评测集或判分标准脱离真实需求；
• 线上短期指标上涨但 Context 质量下降，可能是在透支可信度或只优化少数高频 case。

健康的迭代方式是：Context 层快速定位和归因，答案层验证端到端效果，业务层确认真实价值。

深层分析：x% 工程化，难在「归因」

「优化 x%」听起来像一句口号，把它变成工程机制，难点在于：最终答案是规划、检索、筛选、工具执行和生成共同作用的结果。

当答案出现幻觉或不满足时，需要回答：

• 是任务理解错了，还是搜索词构造错了？
• 是关键证据没有被召回，还是被阈值过滤掉了？
• 是某条错误证据进入了 Context，还是 writer 没有遵循证据？
• 一条没有被答案直接引用的信息，是噪音，还是承担了消歧和校验作用？

不能归因，x% 就只是一个整体分数——知道它涨了跌了，却不知道下一步应该改谁。一个可运转的评测机制通常包含四部分：

还要特别注意：离线 x% 与线上满意度是两层指标。 离线提升最终要在线上兑现，否则可能是在优化一个与用户感受脱节的代理目标。

本章要点

• 当瓶颈位于证据供给和组织时，优先优化 Context，通常比直接调模型更快见效；
• 「优化 x%」是业务自定义的工程代理指标，不是天然存在的唯一公式；
• Context 质量至少包含相关性、覆盖度、证据强度、互补性、时效、权威、一致性和 token 效率；
• 评测要分成 Context、答案、业务三层，代理指标最终必须兑现为用户价值；
• 工程化的核心难点是过程可观测和错误归因。

思考题

1. 如果让你为手头的 AI 应用定义一个 x%，你会选哪些 Context 指标？为什么？
2. 一条没有出现在最终答案里的证据，什么情况下仍应算作有效信息？
3. 你见过哪些「离线指标上涨、用户感知却没变化」的情况？问题可能出在哪一层？

← 上一章 | 下一章：架构选择 →

07 架构选择：事件流单智能体 vs 权职分离多智能体

本章回答：context 应该怎么组织？——借助 Manus 与 Claude Deep Research 两个案例，理解「连续事件流」和「上下文隔离」两种组织范式，以及它们背后的权衡。

这不是两套可以直接照抄的标准答案，也不是比较谁更先进。案例的价值在于暴露设计变量：任务是否可拆、错误是否需要共享、上下文是否连续，以及成本和时延是否允许。

7.1 单智能体路线：Manus 的事件流 + KV cache

个人理解，最精髓的是围绕事件流设计极致的 context 组织方式：

<event_stream>
1. Message: 用户输入信息
2. Action: 工具调用 (Function Call)
3. Observation: 工具执行结果
4. Plan: 规划器生成的思考路径 (System Generated)
5. Knowledge: 检索到的外部知识 (System Generated)
6. Datasource: 数据源 API 文档
...

[!info] 概念小课堂：为什么「事件流」和「System Prompt 位置」是性能问题？

大模型推理时，会对已经处理过的 token 缓存中间计算结果（KV cache）。只要 prompt 的前缀不变，前缀部分就不用重算；一旦前缀变了，后面全部要重新计算。

所以「在 prompt 尾部不断追加事件流」不只是组织信息的审美选择——它让每一步的历史前缀都能命中缓存，大幅降低延迟和成本。同理，System Prompt 写错位置（比如插在动态内容之后），会导致缓存频繁失效。这是「低级问题有显著影响」的原因。

在地图业务应用后，明确有帮助的实践有四条：

① 在 prompt 尾部不断追加事件流，用不同事件流替代子智能体分工。

[流程图 6b7c5989d20c4a2e8181f58b42b074a6 mxGraph]

② 必要处重写 todo list。（长任务中定期把「接下来要做什么」显式重写进 context，把任务焦点拉回来，对抗多轮后的焦点漂移。）

[流程图 a74141706c004641a2ea3bab504f2918 mxGraph]

③ 保留错误执行路径，提升错误恢复能力。（不要把失败的尝试从 context 里删掉——模型看到「这条路走过、失败了」，才知道换一条路，否则会原地打转。）

④ 「低级」问题也许会有显著影响：你的 System Prompt 写在哪儿？

[流程图 f15f0d1c9d294cdd96261481e3155604 mxGraph]

7.2 多智能体路线：Claude Deep Research 的权职分离

在地图业务应用后，明确有帮助的实践：

• 权职分离的多智能体架构：上下文分离、任务解耦、小模型工程化友好；
• 按任务难度分配不同的资源和执行路径：straightforward、depth-first、breadth-first。

7.3 单智能体还是多智能体？

结合两条路线的特点，可以给出一个参考判断：

• 任务边界清晰、可拆解为独立子任务、希望用小模型降低成本 → 优先权职分离多智能体；
• 任务上下文连续性强、依赖长程推理与错误恢复 → 优先事件流单智能体；
• 两者不互斥：第九章的实战案例中，主链路用「规划 + 反思」保持上下文连续，筛选侧用多智能体做任务解耦——这正是混合架构。

深层分析：单 vs 多，本质是三组权衡

权衡一：上下文连续性 vs 上下文隔离。 单智能体的一切历史都在一个 context 里，利于长程依赖和错误恢复，但错误和噪音也会累积污染；多智能体互相隔离，子任务的失败不会污染主线，但跨智能体的信息传递本身就是损耗。Manus 用「追加事件流」买连续性，Claude 用「权职分离」买隔离——没有免费的午餐。

权衡二：涌现空间 vs 可控性。 单智能体把更多决策留给模型，涌现空间更大，但出了问题难以定位「是哪一环错了」；多智能体把系统切成可独立迭代的小块，哪个子智能体效果不好就改哪个——工程上友好得多，代价是整体设计预支了对任务结构的假设。

权衡三：单点大模型成本 vs 小模型工程化。 权职分离架构里，简单的子任务可以换成小模型，成本结构更优；单智能体则每一步都依赖最强模型的全量 context。这也呼应了 第五章 的性能容忍度判断：架构选择本质是效果、时延、成本三者的分配方案。

一个常见的实践结论：主线（需要连续推理和纠错的规划-执行）走事件流单智能体；可原子化的旁路任务（筛选、校验、格式化）拆成隔离的子智能体。先按这个默认形态起步，再按瓶颈调整。

本章要点

• 单/多智能体不是立场之争，核心是 context 的组织方式：事件流买连续性，权职分离买可解耦、可工程化；
• 事件流路线的四个落地要点：尾部追加、重写 todo、保留错误路径、System Prompt 位置（KV cache）；
• 多智能体路线的两个落地要点：上下文分离、按任务难度分级分配资源；
• 默认形态：主线单智能体 + 旁路可原子化任务拆子智能体。

思考题

1. 你手头（或见过）的 Agent 系统里，有没有「子智能体之间信息传递损耗」的具体例子？当时怎么解决的？
2. 如果把你最熟悉的一个多步骤任务改成事件流单智能体，哪些环节会因为上下文污染而出问题？

← 上一章 | 下一章：SKILL 注入 →

08 SKILL 注入：第一波收益与堆叠陷阱

本章回答：领域知识怎么注入给模型？——SKILL 能快速拿到收益，但盲目堆叠会让 Agent 退化成 workflow。度的把握是本章的核心。

8.1 从没有 SKILL 到有 SKILL，可以拿到第一波收益

以医院地点查询场景为例，注入回答 SKILL：重点关注当前地点的医疗特色、医疗性质、擅长领域或科室、就诊指南、评价如何、交通便利等方向。

在该业务、该评测口径和该阶段中，优化后极致满足快速提升 20PP。这是一个具体案例的阶段性收益，用来说明「从无到有」的第一波价值，不应外推为所有 SKILL 注入都能获得相同幅度。

[!info] 概念小课堂：什么是 SKILL？它和 system prompt、工具有什么区别？

SKILL 可以理解为一份「场景化的知识与行为指南」，在命中对应场景时注入 context：它告诉模型这类问题什么是好答案、该关注哪些维度。

为了避免把 SKILL 与其他运行时机制混在一起，可以先做一个粗略分工：

• System prompt：全局、恒定的角色与规则，永远在场；
• SKILL：按场景注入的判断标准和领域知识，按需在场；
• 工具（Tool/Function）：模型可以主动调用的能力，用来获取信息或执行动作；
• Memory：跨步骤或跨会话保留的状态、事实与偏好；
• Workflow / Policy：显式规定执行顺序、权限和运行时约束。

医院例子里，SKILL 注入的不是「数据」（数据由检索工具提供），而是「评价一家医院地点的回答该覆盖哪些维度」这种判断框架。

8.2 不能陷入盲目堆叠 SKILL 的陷阱

第二阶段的问题：SKILL 越做越细、越做越多，出现冲突、选择困难，甚至让模型回答固化、智能性下降——反而从 Agent 退化到 workflow。

• 场景是无穷多的：人群 × 时间 × 行业；
• 固化的流程和步骤看似能解决 case，但实际让模型失去了涌现能力；
• 本质上是在用昂贵的大模型能力，重新打造脆弱的规则流程系统。

8.3 更合理的迭代方式

1. 定义一系列无歧义、正交的工具边界（关键）；
2. 在典型场景，解决「怎么合理地调度起这些工具」；效果不好的时候，解决「怎么做错误恢复」；
3. 剩下的交给模型自己涌现。

深层分析：为什么「固化流程」是亏本的买卖

第一笔账：机会成本。 写死「第一步做什么、第二步做什么」，等于把大模型最贵的能力——泛化推理——裁掉不用，只用它的文本填充能力。这与 第五章 的资产折旧视角一脉相承：写死的流程不随模型升级而升值，模型越强，这些流程越可能成为束缚。

第二笔账：维护成本。 场景是组合爆炸的（人群 × 时间 × 行业），每个细分 SKILL 都要维护，SKILL 之间还会冲突。规则系统的历史教训是：规则只会增加、很难删除，最终没人说得清系统为什么这样行为。

SKILL 的正确角色：注入 know-what，而不是 know-how。

• know-what（判断标准、领域知识、什么是好答案）——模型缺这个，注入了就有收益，医院案例正是这一类；
• know-how（操作步骤、流程编排）——模型自己就会，写死了反而限制它。

一个可操作的检验：这条 SKILL 是在帮模型「判断」，还是在替模型「决策」？ 前者留下涌现空间，后者把它变成 workflow 节点。

正交性的检验方法：两个工具/SKILL 边界能否各用一句话说清？能否互相替代（能替代说明没拆干净）？组合起来是覆盖场景还是重叠场景？——「无歧义、正交」不是洁癖，是为了让模型（以及维护者）在任何场景下都知道该用哪个。

工具太多怎么办：把 RAG 用到工具描述上。 当工具数量持续增长，连「选哪个工具」本身都会成为负担——工具描述挤占 context、模型选择困难。RAG-MCP（arXiv:2505.03275）的思路是把检索用在工具选择上：先按任务检索出最相关的少量工具描述，再让模型在小集合里选。正交边界让「该用哪个」说得清，检索让工具规模可扩展——两者互补。

本章要点

• SKILL 是注入领域知识的高效手段；案例中的「极致满足 +20PP」说明了从无到有的阶段性收益，但不是普适幅度；
• 堆叠陷阱：场景组合爆炸 → 冲突、固化 → Agent 退化成 workflow，等于用昂贵模型重建规则系统；
• 健康迭代三原则：正交工具边界（关键）、典型场景的调度与错误恢复、其余交给模型涌现；
• 判断标准：SKILL 注入 know-what（判断标准），不注入 know-how（操作步骤）。

思考题

1. 找一个你见过「规则越加越多、效果反而变差」的系统，分析它的规则是在注入 know-what 还是 know-how？
2. 如果要为你的业务写第一条 SKILL，它命中的场景边界怎么用一句话说清？

← 上一章 | 下一章：百看配图实战 →

09 实战：百看配图的全链路 Context 设计

本章是整套教程的实战核心：一个没有用户多轮交互的 AI 搜子系统，如何靠系统内部的上下文管理把效果做出来。建议先读 第六章、第七章 和 第八章。

9.0 业务背景与场景特点

百看：一种 AI 搜产品形态，通过 RAG 方式总结全网内容、快速提供满足答案。

[流程图 ed42e97addf044809ebc8d090905f0ce mxGraph]

百看配图：理解用户 Query 和 AI 生成答案，精确配图，展现在卡内不同位置，重点关注头部图片。配图系统需要解决三个主要问题：

[流程图 9b8852afccab4dc2981614ff557fe9b2 mxGraph]

这个场景有一个关键约束：从 Query 到配图完成是一次性自动完成的，系统不能等待用户多轮纠正。 因此，配图系统需要在内部构造一个「虚拟多轮」：先规划，再根据反馈反思和重做，最后把规划结果交给解耦的筛选模块。

配图系统中的 Context Engineering 可以拆成三类动作：

1. 生成有效 context：用结构化分步规划和 few-shot，把模糊 Query 转成可执行的图片需求；
2. 更新 context：用带方向的 feedback 驱动重做规划，逐步收敛歧义；
3. 裁剪 context：给筛选智能体只提供它完成子任务所需的信息，避免原始 Query 和答案全文造成干扰。

[!info] 概念小课堂：为什么「无用户交互」是个硬约束？

常见 chatbot 场景里，Agent 可以从多轮对话中持续获得用户反馈来校准自己——说错了用户会纠正，偏了用户会拉回。配图系统没有这个机会：从 Query 到配图完成是一次性自动完成的，所有纠错所需的 context 都必须由系统自己构造出来。

这正是本章的价值：它演示了当外部反馈缺失时，如何用「规划 → 反思 → 筛选」在系统内部模拟出纠错闭环。与常见 chatbot 不同，这里更关注系统内部的上下文管理。

9.1 全链路总览：在线决策与离线供给

先看完整链路，再分别放大每个局部机制：

用户 Query + AI 生成答案
          │
          ▼
┌────────────────────────────┐
│ 需求规划器                  │
│ 意图 / 是否需要图 / 图片类型 │
└────────────────────────────┘
          │
          ▼
┌────────────────────────────┐
│ 反思与重规划                │
│ last_plan_result + feedback │
└────────────────────────────┘
          │
          ▼
┌────────────────────────────┐
│ 候选素材供给                │◄── 离线图片理解、结构化字段、质量标注
└────────────────────────────┘
          │
          ▼
┌────────────────────────────┐
│ VLM 匹配与质量筛选          │
│ 只消费与子任务直接相关的计划 │
└────────────────────────────┘
          │
          ▼
┌────────────────────────────┐
│ 热度 / 歧义校验与呈现        │
└────────────────────────────┘
          │
          ▼
      卡内配图结果

可以把系统分成两条相互配合的链路：

在线 Context Engineering 决定“这一次应该选什么”，离线知识生产决定“系统手里有什么可选”。两者不能互相替代：在线筛选无法补齐不存在的素材，离线供给也不能自动理解每次 Query 的当前诉求。

9.2 首轮规划：把 Query 变成图片需求

整体机制是：需求规划 → 反思多轮，让模型从模糊判断走向相对明确的图片需求。

[流程图 6d2ebf3d68ef435ca08ac6f55aa14f34 mxGraph]

以 Query = 「好太太和千年舟哪个好」为例，三轮思考交互过程：

轮次	思考交互过程
第 1 轮	[流程图 c82959098245458fb24a9de977f01b12 mxGraph]
第 2 轮	[流程图 fd86d98b816f45e2b16747472152dd8c mxGraph]
第 3 轮	[流程图 fd7cdb006ce949c19c0ca1276f257789 mxGraph]

首轮规划的两个关键设计：

① 结构化分步规划

这类设计常被称为思维链 CoT。工程上更重要的不是要求模型暴露完整的隐式思考过程，而是让它产生稳定、可被后续模块消费的中间状态。规划可以拆成四步：

• step1：意图分析——用户真正要解决什么问题？
• step2：图片必要性判断——诉求满足是否依赖图片信息？
• step3：需求图片分析——需要什么图片类型，图片能带来什么增益？
• step4：规范格式输出——把结果压缩成下游可消费的字段。

② 样例引导（few-shot）

不要只堆数量，要选能定义边界的典型示例：

• 正向示例：引导模型理解任务要求；
• 反向示例：告诉模型哪些看似相关的 Query 实际不应该配图。

[!info] 概念小课堂：为什么分步规划和反向示例有效？

分步规划给模型提供中间状态，减少一步到位猜答案的压力；反向示例则补上正例缺少的边界。只有正例时，模型容易把所有 Query 都套入配图模板；正反例结合，才构成相对完整的任务定义。

[!example] 重建示例 prompt（按业务实践中的描述重建，非生产原版）

```md 你是配图需求规划器。请按以下步骤分析用户 Query，并输出配图规划：

step1 意图分析：用户的主需问题是什么？问题背景是什么？ step2 图片必要性判断：该诉求的满足是否依赖图片信息？ step3 需求图片分析：需要什么类型的图片？图片的增益点是什么？ step4 规范格式输出：按「实体 + 类型 + 图片需求描述」格式输出。

正向示例： Query: 好太太和千年舟哪个好 输出: 千年舟 | 家居板材品牌 | 品牌Logo或板材产品展示

反向示例（错误示范，请勿模仿）： Query: 北京天气 输出: 北京 | 城市 | 城市风景图 错误原因：天气类诉求的满足不依赖图片，应判定为无需配图。 ```

9.3 反思多轮：用带方向的 Feedback 重做规划

首轮规划之后，引入 last_plan_result + feedback 做重做规划：

• 保留规划路径和中间结果，让模型知道之前做过什么判断；
• 明确 feedback 的动作类型：是纠偏，还是在原方向上细化；
• 让反馈包含预期修改方向，不要只给一个没有解释的分数。

以千年舟为例，需求可以逐轮演进：

千年舟 | 家居板材品牌 | 品牌Logo或板材产品展示
    ↓ 纠偏 / 收敛歧义
千年舟 | 家居板材品牌 | 品牌Logo图
    ↓ 细化规格
千年舟 | 家居板材品牌 | 品牌Logo透明底 方图

[!abstract] 深层分析：Feedback 的本质是「编辑指令」，不是「打分」

注意千年舟例子里 feedback 的形态：它不是「这轮规划 70 分」，而是「把『Logo 或产品展示』收敛为『Logo 图』」这种带方向的修改指示。没有修改预期，模型只能猜哪里不满意，可能把正确方向改错。

给 Agent 设计反馈机制时，至少要区分：

• 纠偏：改变任务理解或目标方向；
• 细化：保持方向不变，收紧类型、规格或质量要求；
• 补充：增加之前遗漏的约束或事实。

9.4 全局上下文：让三类信息共同驱动决策

单靠配图规划还不够。最终决策至少需要三类全局上下文：

1. Query 的原始需求上下文：主需问题、问题背景——来自 UIAPI/AIAPI + Reader 模块；
2. AI 生成答案的语义上下文：核心观点、逻辑结构、重点内容——来自文本答案 + references；
3. 图文适配的场景上下文：风格一致性——来自意图分类 + 领域垂类。

三类上下文的职责不同：

核心要义是：用全局上下文驱动决策，而不是让单一指令承担所有判断。 反馈也应当对齐规划步骤：

• 意图合理性：double check 用户主需；
• 图文相关性：检查图片和生成答案是否一致，指出冲突点；
• 风格一致性：检查图片组合是否满足整体呈现要求。

数据驱动，知识蒸馏：

[流程图 1a4eb54b0df543459720e3c386560440 mxGraph]

9.5 供给与筛选：离线生产，在线解耦

离线知识生产、在线筛选应用：

[流程图 3e78a46b2e91462887c15e9eea8e1223 mxGraph]

① 需求匹配度

VLM 筛选侧首先要回答：这张图片是否满足当前规划出的需求？

Context 选取是多智能体任务解耦的关键：

• 原始 Query + answer 全文？NO；
• plan results？YES。

筛选智能体只对规划结果负责，可以避免无关内容干扰，也能让规划和筛选分别迭代、分别归因。注意这不是说原始 Query 和答案永远没有价值，而是说它们不应默认全部注入筛选上下文；如果某个筛选任务确实需要其中的字段，应按最小必要原则显式传入。

一套模型，两种 Prompt 应用：不同的图片类型、不同的质量标准，应使用不同的判断提示，避免把实体图与 AIGC 图的评价标准混在一起。

实体图	AIGC 图

离线素材理解供给：先把图片转成适合在线筛选的结构化字段，根据场景提供实体、类型、文字、风格、质量等信息。

[流程图 a9fb2f55c8934701aa45a2199e9893d4 mxGraph]

② 热度校验与歧义消解

当规划不够明确时，候选集本身可以提供反向线索：候选分布在一定程度上体现了系统对不同实体或方向的置信度。通过理解多图之间的相似性和数量分布，可以帮助选取头部结果。

不过，热度是统计先验，不是事实真值。它可以辅助同名多义消歧，但不能替代权威来源核验；当候选分布本身受到供给偏差影响时，也可能把热门误当成正确。

[!abstract] 深层分析：两个值得记住的设计原理

「plan results？YES」体现的是 Context 最小必要原则。 筛选智能体如果同时看到原始 Query、答案全文和大量执行历史，判断会被与配图无关的信息干扰，而且规划智能体与筛选智能体的错误会纠缠在一起。只喂 plan results，是把筛选子任务裁剪到最小完备上下文。

热度校验本质是用统计先验消歧。 当 Query 本身存在同名多义时，候选图片集的分布携带了额外信息。但统计先验只能帮助排序和选择，不能自动证明某个实体就是用户意图；因此需要结合来源、答案语义和业务规则共同判断。

9.6 失败模式与可观测性

要让这条链路可持续迭代，不能只保存最终图片，还应记录每一步的中间状态：

• 规划器输出了什么，使用了哪些示例；
• 每轮 feedback 属于纠偏、细化还是补充；
• 哪些候选被召回、过滤和淘汰，原因是什么；
• VLM 使用了哪些字段和质量标准；
• 热度校验是否改变了原始排序；
• 最终图片是否被展示、替换或被用户反馈否定。

典型失败模式可以按链路归因：

这一步把第 05 章的「优化 x%」落到了具体业务：只有记录过程、保留候选和明确失败原因，Context 质量才有可能被评估和持续改进。

本章要点

• 无用户交互场景的 Context Engineering，本质是在系统内部构造「虚拟多轮」：规划给指令，反思给反馈，筛选做解耦；
• 首轮规划 = 结构化分步规划 + few-shot 正反例；反思 = last_plan_result + 带明确预期的 feedback；
• 在线决策和离线知识供给必须分开设计：前者负责当前任务，后者决定可选证据的上限；
• 决策用三类全局上下文驱动（原始需求 / 答案语义 / 图文场景），而非单一指令；
• 筛选侧遵循最小必要 Context 原则，热度可以辅助消歧，但不能替代权威核验；
• 过程日志和失败归因是这条链路能够持续优化的前提。

思考题

1. 「只喂 plan results」这个设计，迁移到你熟悉的场景里会是什么样？哪些信息该裁掉，哪些字段必须保留？
2. 配图的「反思多轮」和 第七章 里 Manus 的「保留错误路径」，在纠错机制上有什么异同？
3. 如果候选集的热门分布与真实意图冲突，你会让系统优先相信热度、答案语义，还是权威来源？如何降级？

← 上一章 | 下一章：策略优化全景 →

10 深层分析：把 Context 放回 AI 搜索全链路

本章是基于行业实践的展开分析。前面各章集中讲 Context Engineering；本章退一步，把 Context 放回完整的 AI 搜索系统，说明它与触发、规划、检索、生成、反馈和内容供给之间的关系。

核心论点：策略优化没有消失，目标函数变了

一个常见误解是「有了大模型，传统搜索那套策略优化就不重要了」。更准确的说法是：AI 搜索没有消灭策略层，而是改变了各层的目标函数——从“排给人看”扩展为“选给模型读，并让模型据此完成任务”。

以下两条判断已经指向这一点：

• AI 搜索的竞争归根到底仍然是信息密度的竞争；
• 搜索满足度依然是最关键的环节之一。

Context Engineering 是当前最直接的工程杠杆之一，但不是独立于系统其他部分的单一模块。完整链路可以拆成六个在线环节 + 一个供给底座：

用户 Query
  │
  ├─ 0. 触发：该不该出 AI 答案、该不该检索？
  ├─ 1. 规划：任务怎么拆、调什么工具、走多深？
  ├─ 2. 检索：去哪找、找多少、如何保证覆盖？
  ├─ 3. 筛选与组装：哪些信息进入当前 Context？
  ├─ 4. 生成：如何基于证据完成答案或下一步行动？
  └─ 5. 反馈：怎么度量、归因、回放和迭代？

贯穿全链路的底座：6. 供给（内容、知识、数据与多模态素材）

Context Engineering 横跨其中多个环节：

• 在规划层，Context 决定模型看到哪些任务状态、工具说明和历史事件；
• 在检索与筛选层，Context 决定证据如何被选择、压缩和排序；
• 在生成层，Context 决定规则、证据和输出约束如何组装；
• 在反馈层，Context 需要被记录、回放和归因；
• 供给层则决定 Context 中可能出现什么内容。

因此，本章不是讨论「Context 之外的事情」，而是回答：Context 在整个系统中由哪些上游决定，又会影响哪些下游。

本章多处使用内容搜索场景作例子：用户输入「主题名」或「完整化需求」，由 Agent 调用搜索 API 获取信息。搜索服务主要提供召回与基础排序；query 构造、结果降噪、意图确认、上下文组装和最终生成仍需要调用方设计。

0. 触发层：先决定是否值得进入昂贵链路

传统搜索可以对每个 Query 返回列表，但 AI 答案并不一定对所有请求都是正收益。导航类、简单事实类请求可能更适合直接结果；开放域、聚合类、需要多步研究的请求更可能受益于 AI 生成。

触发层要回答两个问题：

1. 要不要触发 AI 答案？
2. 要不要调用检索、记忆或其他昂贵工具？

触发的第一步是理解输入形态：

• 精准意图：用户已经用一句相对完整的话说明需求，检索可以围绕明确目标展开；
• 探索意图：用户只给出主题名或宽泛方向，系统需要主动界定范围并做 query fan-out。

两类输入不应共用同一套策略：精准意图适合单点检索与精确匹配；探索意图需要扩展多个角度，否则后续结果会被用户偶然使用的措辞限制。

意图不明时，可以采用「推断 → 默认策略 → 澄清追问」的分层：

1. 先推断：利用时间词、任务类型、会话状态等信号；
2. 再默认：推断不出时按业务先验选择可撤销的默认策略，并向用户暴露关键假设；
3. 最后澄清：只有歧义会导致结果本质不同时，才增加一轮交互。

这也解释了 第九章 的价值：无用户交互场景无法追问，只能用系统内部的规划、反思和统计先验完成纠错。

[!abstract] 横向案例的三条可迁移启示

其他 Agent 系统中的记忆检索、工具调用也有类似问题。无论具体业务是什么，触发层都应尽量做到：

1. 触发或跳过都记录原因，让决策可以回放；
2. 高风险能力依靠权限和运行时约束，而不是只靠 Prompt；
3. 模型分类器需要规则、阈值或矛盾检测兜底，不能把所有决策都交给一次生成。

1. 规划层：Query 理解从「匹配」变成「调度」

传统 query 理解关注分词、改写和意图分类；AI 搜索中的 planner 还要完成：

• 拆解子问题；
• 决定调用哪个垂类或工具；
• 选择执行深度；
• 管理预算、依赖关系和停止条件。

第七章 中 straightforward / depth-first / breadth-first 路径，本质上是规划层的难度路由：简单 Query 走便宜路径，复杂 Query 才使用更多模型调用和检索预算。

规划层更靠前的杠杆是搜索词构造：

• 短「主题名」通常需要 fan-out 成多个角度；
• 长「完整需求」通常需要拆成若干可验证子任务；
• 过精确的搜索词会漏召，过宽的搜索词会引入噪音；
• 关键词检索与向量检索偏好的语言形式不同，query 的表达方式本身会改变召回结果。

规划层的关键指标不只是「计划看起来合理」，还要看它是否提高了后续证据覆盖、减少了无效调用，并在预算内完成任务。

2. 检索层：从“人会不会点”到“证据能否完成任务”

传统搜索排序常以用户点击和结果满意度为目标；面向模型的检索还需要评估：一条结果进入 Context 后，对最终答案有没有独特贡献。

由此产生几个更重要的策略问题：

• 覆盖度 vs 冗余：十条同质结果对人是选择，对模型可能只是重复 token；
• 证据密度 vs 表面相关性：页面标题相关，但正文缺少可验证事实，仍然是低价值证据；
• 时效与权威：旧信息和低质量来源会成为错误生成的直接原料；
• 多样性与子问题覆盖：复杂问题需要不同来源覆盖不同子任务，而不是只提高单条相似度。

所以，检索质量是 Context 质量的重要上限：筛选层可以减少噪音，但无法从候选集中创造不存在的关键事实。

2026 年的研究给了这句话一个量化注脚：BrowseComp-Plus 在固定语料库上把「Agent 能力」与「检索器能力」分离评测——同一个 GPT-5，仅把检索器从 BM25 换成更强的 Embedding 检索器，准确率从 55.9% 升到 70.1%，搜索调用次数反而减少。Agent 不变，检索器质量独自拉开了 14 个百分点（详见 第十一章）。

3. 筛选与组装层：x% 所在，但不只是压缩

第六章 的「优化 x%」主要落在这一层：从候选信息中选择进入当前窗口的子集，并与系统规则、用户问题、历史状态、工具结果、记忆和 SKILL 组装。

典型降噪漏斗是：

候选召回
  ↓ 阈值过滤
相关性 / 质量重排
  ↓ 去重与多样性控制
Top-k 或 token 预算截断
  ↓ 时效、权威与冲突处理
当前轮 Context

三个工程边界需要特别注意：

1. 噪声水平不只由搜索词决定：主题供给丰度、同名歧义和语言错配都会改变噪声；
2. 过滤必须配套降级策略：阈值过高会误杀唯一答案，无有效结果时应放宽阈值重试、返回证据不足或回退规划，而不是硬生成；
3. 低置信本身是信号：它可能说明任务定义或检索词有问题，需要回到规划层，而不是继续堆更多低质量结果。

这一层还承担 Context 的顺序、格式和预算分配：哪些规则放在稳定前缀，哪些事件追加在尾部，哪些长文应该压缩，哪些错误路径必须保留。它是 RAG 与 Agent 运行时真正接上的地方。

4. 生成层：优先级可以降低，但不能被忽略

「先优化 planner 或 writer」这一反面设问，是为了纠偏“出了问题先调模型”的惯性，并不意味着生成层不重要。

在 Context 质量到位后，生成层仍有独立目标：

• 事实一致性：结论能否被给定证据支持；
• 引用对齐：引用是否真的支持对应陈述；
• 完整性：关键子问题是否都被回答；
• 指令遵循：是否满足格式、边界和拒答要求；
• 不确定性表达：证据不足或冲突时是否明确说明。

在传统搜推内部，用生成式小模型替代部分判别式模型，也可以视为生成层或策略层的模型升级。关键仍然是让它服务于可量化的系统目标，而不是为了“使用生成模型”而使用。

5. 反馈层：离线可迭代，线上可验证

反馈层把前面所有环节串起来。没有分环节评测，每一层的优化都可能在自说自话。

[!abstract] 验证的三个层次：结果、答案、过程

AI 搜索的验证对象正在从单层扩展为三层，且下层是上层的前提——底层出错时，上层只是「在错误信息上做更复杂的推理」：

L1 检索结果是否准确：文档是否相关、关键证据是否被覆盖、Recall/Precision 是否足够、是否存在大量相似但无用的内容。这是传统 IR/RAG 就关注的基础。

L2 答案是否被证据支持：每个结论是否有对应证据、引用是否真支持该论断、是否遗漏反例或限定条件、是否「检索正确但生成错误」。很多系统只检查「答案像不像正确」，没有严格检查「引用是否支持每一个具体说法」。

L3 检索过程本身是否可靠（Agentic Search 带来的新层）：问题拆解是否正确、子查询是否有效、信源选择是否合适、子问题是否全覆盖、是否根据结果发现信息缺口、矛盾证据是否核查、是否陷入重复搜索、何时继续何时停止、是否在预算内完成。

为什么 L3 必须独立验证：结果正确 ≠ 过程可靠。 Agent 可能搜错方向却碰巧找到正确网页；可能只搜支持某结论的材料而不搜反例；可能做了几十次无效搜索、靠巨大 token 消耗堆出答案；最终答案对了，引用却不指向真正支撑的来源。这类「侥幸正确」在线上分布偏移时会批量翻车。

但过程验证远未成熟，五个难点：① 可靠路径不唯一——不同查询顺序都能得到正确答案；② 无单一指标——搜索次数少不一定好、多不一定坏；③ 过程质量依赖任务目标——新闻核查、学术综述、企业问答对深度和来源的要求不同；④ 可能出现「看似合理」的轨迹——有规划、有反思、有引用，关键证据依然错误；⑤ 成本高——多轮搜索、并行 agent、反思机制显著增加 token 与时延。

下面的三类评测可以看作这套框架的工程化：决策评测主要覆盖 L3 的行为决策，过程评测覆盖 L1 的产物质量与 L3 的中间过程，端到端评测覆盖 L2。

建议建立三类评测：

• 决策评测：触发、工具调用、检索路由是否正确，把误触发和漏触发分开衡量；
• 过程评测：搜索词、候选集、过滤结果、最终 Context 是否达到覆盖与降噪目标；
• 端到端评测：最终答案质量是否兑现为线上满意度、留存、转化、时延和成本收益。

落地到指标，可以按三层组织一张速查表：

两个让这张表落地的工程机制：

• 多裁判分层评分（Agent-as-a-Judge）：用多个专职裁判模型（规划裁判、引用校验裁判、事实核查裁判）按结构化打分规则，分别评轨迹日志与最终输出，离线异步执行——比单一「总分裁判」更可归因；
• 确定性环境快照：公开互联网内容实时变动，会让过程评测无法复现。前沿基准的做法是抓取并固化网页快照构建沙箱（BrowseComp-Plus 的固定语料库即此思路）——自建评测集时，同样建议固化检索快照。

[!info] 概念小课堂：Ragas 四指标怎么读。

开源框架 Ragas 把 RAG 评测拆成四个基本无需参考答案的指标：Context Precision（检索到的内容信噪比高不高）与 Context Recall（回答所需的信息找全了没有）——评检索，对应 L1；Faithfulness（答案忠实于证据，还是在捏造）与 Answer Relevancy（答案是否切题）——评生成，对应 L2。它的价值在于把「检索错」和「生成错」分开定位，而不是只给一个总分。

工程前提是可观测性：每一步都要保存输入、输出和决策原因。至少应记录：

触发原因
规划与子问题
搜索词与数据源（含改写轨迹）
候选文档与分数
被选中 / 被拒绝的证据及原因
过滤、去重和截断原因
停止搜索的理由
最终 Context
生成答案与引用（结论-引用映射）
用户反馈或线上结果

有了这些日志，「该不该检索」「哪条证据导致错误」「哪一步丢掉了答案」才能被标注、回放和归因。

6. 供给底座：最慢、最贵，也最难复制

「信息密度的竞争」最终会落到内容供给：

• 自有数据与独家合作内容；
• 结构化知识图谱和领域数据库；
• 高质量、多模态素材；
• 权限、时效、版本和来源治理；
• AIGC 内容的质量控制与去污染。

相较于容易被复用的编排技巧，差异化内容、高质量数据和成熟的知识治理通常更难被复制。百看配图中的图片文本化、素材结构化和离线知识生产，就是供给底座的一部分。

全景总结：四层 CE 主线、六个在线环节、一个供给底座

前面几章可以用两套互补视角总结。

Context Engineering 的四条学习主线

AI 搜索的系统视角

各层关系：乘法，而不是替代

这些环节是乘法关系：

• 触发层决定资源花在哪些请求上；
• 规划层决定系统是否在做正确的任务；
• 检索层决定候选证据上限；
• 筛选与组装决定有限窗口中的有效信息密度；
• 生成层决定模型是否正确使用证据；
• 反馈层决定迭代速度；
• 供给底座决定系统长期上限。

Context Engineering 不是其中一个孤立方框，而是一套贯穿运行时的信息管理纪律。在本教程讨论的 AI 搜索场景中，规划、筛选与组装通常是最直接的杠杆，但最终效果仍取决于整条链路。

思考题

1. 用「六个在线环节 + 一个供给底座」分析一个你熟悉的 AI 搜索产品：它明显重投了哪一层，忽略了哪一层？
2. 「排给人看 → 选给模型读」这个目标变化，在你所在的技术领域有类似现象吗？
3. 如果离线 Context 指标提升，但线上满意度没有变化，你会从生成、评测集还是产品触发层开始排查？为什么？

← 上一章 | 下一章：前沿瞭望 →

11 前沿瞭望：2026 搜索技术进展——六层框架的证据检验

本章（2026-08 据公开论文与产业资料整理）把 第十章 的六层框架放到最新证据下检验——哪些判断被证实、哪些获得了具体形态、哪些仍悬而未决。

引用数据按三级可信度标注：顶会论文 > 预印本 / benchmark > 厂商自报（厂商数字是工程参照，不是行业共识）。

一句话总览：从「找到相关文档再生成答案」，转向「模型主动规划搜索、动态调用工具、反思检索结果，并以最终答案质量反向优化检索器」。竞争重点从 embedding、向量数据库，转向搜索策略、检索决策和推理过程的联合优化。

11.1 检索层：训练目标从「相似」到「有用」

• （论文）Agentic-R（arXiv:2601.11888）：检索器同时优化局部 query-passage 相关性和「该 passage 对最终答案正确性的全局贡献」，并与搜索 agent 交替迭代——agent 产生的高质量查询回流，继续训练检索器；
• （论文）BrowseComp-Plus（arXiv:2508.06600）：用固定、人工核验的语料库把「agent 能力」与「检索器能力」分离评测。同一个 GPT-5：配 BM25 准确率 55.9%，换 Qwen3-Embedding-8B 升到 70.1% 且搜索调用更少；而 Search-R1 + BM25 只有 3.86%。

这是 第十章 检索层「目标函数从排给人看变成选给模型读」的研究实证：agent 不变，检索器质量独自拉开 14 个百分点——「检索质量是 Context 质量上限」有了量化注脚。

11.2 规划层（上）：query 工程成熟为基础设施

• 查询改写、拼写纠错、对话历史补全、查询分解、多查询 fan-out，已成为企业级搜索的标配预处理。微软 Azure AI Search 的 agentic retrieval 即此形态（厂商自报复杂查询相关性 +16pp、结果率 +15pp，未见独立复现，谨慎引用）；
• Anthropic 的 Contextual Retrieval 解决「切块丢上下文」：为每个 chunk 生成文档级背景再索引，top-20 检索失败率降低 35%（仅 Contextual Embedding）/ 49%（叠加 Contextual BM25），结合重排可再降（厂商工程博客数据）。参见 第二章 分块一节。

11.3 规划层（下）：Search-RL——与第五章并不矛盾

• （论文）Search-R1（arXiv:2503.09516）：把搜索引擎当作强化学习环境，搜索调用与思考交错、支持多轮检索、对检索 token 做特殊处理稳定训练、直接用最终答案做奖励；Qwen2.5-7B/3B 比同设置 RAG 基线分别提升约 24% / 20%；
• （论文）Search-o1（EMNLP 2025）：把「推理」和「读文档」分两阶段——独立的 Reason-in-Documents 模块先分析压缩长文档，再把有用证据注入推理链。本质是「先降噪、再进 Context」；
• （论文）WebSeer（ICLR 2026）：自反思数据 + RL，14B 单模型在 HotpotQA / SimpleQA 达 72.3% / 90.0%；
• （论文）DeepResearcher（EMNLP 2025）：在真实开放网页环境中训练，比 prompt 基线最高 +28.9pp；训练后自发出现规划、交叉验证、研究方向切换和「不确定时保持诚实」的行为。

[!abstract] 怎么和 第五章 调和？

第五章反对的是「跳过底座和评测、直接训练业务模型」，不是训练本身。这轮 Search-RL 的成熟实践顺序恰好反向印证了它：先检索底座 → 查询路由 → 攒够轨迹和评测集之后再训搜索策略。且推荐的奖励设计（答案正确性 + 证据支持度 + 引用准确性 + 查询效率 − 重复搜索 − 无效调用）正是 第六章「context 质量是最佳奖励函数设计方式之一」的落地形态。

11.4 难度路由的具体形态：test-time compute 分配

（论文）ICLR 2025《Inference Scaling for Long-Context RAG》研究给定预算下如何分配「检索文档数量 × 生成推理步数」：合理分配时 RAG 性能近似随推理资源线性增长，优化后比标准 RAG 最高 +58.9%。

路由器的现实形态：

短事实问题   → 低成本单次检索
多跳问题     → 查询分解 + 多轮搜索 Agent
小型语料     → 长上下文直接读
大型文档     → 分层检索 + 压缩
高价值任务   → 更多 test-time compute + 交叉验证

第十章规划层的「难度路由」，从概念变成了「预算约束下的计算分配问题」。

11.5 触发层与产品形态：Deep Research 化

• （产业观察）2026 年中，主流 AI 搜索（Google AI Mode、ChatGPT Search / Deep Research、Perplexity、Gemini Deep Research）已全部 agentic，单次用户查询内部触发 5~20 次子检索（参见 第一章 1.0 节）；
• （厂商自报）OpenAI Deep Research：多步研究 + 浏览器 + Python 工具 + MCP 连接 + 可限制只搜可信站点 + 过程可实时查看和中断调整；
• （厂商自报）Anthropic Research 系统采用 orchestrator-worker 多智能体：内部评测比单 agent 提升 90.2%，代价是 token 消耗约为普通聊天的 15 倍——这是 第七章 单/多智能体权衡的具体价格标签；
• （厂商发布）Google I/O 2026：搜索向「持续执行信息任务的系统」演进（信息监控 agent、agentic booking、可生成交互式页面）。

11.6 筛选与组装层：证据压缩与引用校验成为标准动作

检索后压缩（剪掉不支持答案的段落、只保留回答所需句子）与 citation verification（引用是否真正支撑论断）进入默认管线。这与 第十章 的降噪漏斗、第九章 筛选侧「子智能体只对 plan results 负责」一脉相承——都指向同一个原则：进窗口的每条信息都要有「存在理由」。

11.7 反馈层：评测从「答对了吗」到「过程可靠吗」

• （论文）LiveResearchBench（ICLR 2026）：100 个专家设计任务，要求实时搜索与长报告生成，评内容覆盖、报告质量、引用准确性和可追溯性；配套 DeepEval 套件检查引用是否真正支撑论断；
• （预印本）BrowseComp-ZH（arXiv:2504.19314）：289 个中文互联网原生多跳问题、覆盖 11 个领域——多数模型准确率低于 10%，最佳系统（DeepResearch）也只有 42.9%。中文信息生态（平台分散、命名不一致、内容深藏于百科/问答/政府/垂直站点、省略指代多）是独立难题，英文检索策略不能简单平移；
• 开源工具侧，Ragas / DeepEval（RAG 评测框架）与 ALCE（引用评测）是当前主流代表；过程侧指标（子问题覆盖、查询冗余度、停止决策、成本效益）的完整速查表见 第十章 反馈层。
• 结论呼应 第十章 反馈层的「分环节归因」：现在连「引用与论断的对应关系」都要单独评。把验证对象组织成「结果 / 答案 / 过程」三层框架的做法（L3 即「过程可靠性」），见第十章反馈层的「验证的三个层次」。

11.8 供给层：多模态与图谱融合

（论文）M³KG-RAG（CVPR 2026）构建多跳多模态知识图谱，用分模态检索 + 证据支持评估 + 冗余剪枝，改善 MLLM 的多模态推理与 grounding。GraphRAG 的方向正在从「问题 → 找相关节点」变成「问题 → 实体对齐 → 多跳关系遍历 → 证据支持评估 → 冗余剪枝 → 生成」。

11.9 仍未解决的问题（诚实清单）

1. 检索正确但证据不完整；2. 多轮搜索中的错误累积；3. 引用与论断不一致；4. 搜索成本和延迟过高；5. 开放网页内容动态变化；6. SEO 垃圾、重复内容与低质来源；7. Agent 过度搜索或无限搜索；8. 中文等非英语生态的检索质量；9. 如何为「搜索过程」设计可靠奖励；10. 如何公平地区分模型、Agent、搜索引擎和检索器各自的贡献。

11.10 落地路线：与教程章节的对应

第一阶段 检索底座：文档结构化 + Contextual Chunking + 混合召回 + 重排 + 证据压缩
        → 基础篇 01~03 章
第二阶段 查询路由：按任务类型与难度分流执行路径
        → 第十章 触发层 / 规划层
第三阶段 搜索策略训练：有了轨迹和评测集之后，再做 Search-RL
        → 第五章路线判断 + 本章 11.3
第四阶段 真实评测：分环节指标 + 引用精度 + 中文原生 benchmark
        → 第六章 x% + 第十章反馈层

注意顺序本身：不要一开始就做 Agent RL——很多系统的主要问题其实是 chunk 切坏、缺关键词索引、没有重排、元数据没进检索。

本章要点

• 前沿没有推翻教程框架，而是在逐层填证据：检索目标「从相似到有用」、难度路由「预算化」、评测「过程化」、形态「Deep Research 化」；
• Search-RL 与第五章不矛盾：先底座、再评测、后训练；
• 引用厂商数字（90.2%、15 倍 token、+16pp）时保留可信度分级；
• 中文检索是独立难题，不能平移英文策略（BrowseComp-ZH 最佳系统仅 42.9%）。

参考（精选）

• Search-R1: Training LLMs to Reason and Leverage Search Engines with RL（arXiv:2503.09516）
• Search-o1: Agentic Search-Enhanced Large Reasoning Models（EMNLP 2025）
• DeepResearcher: Scaling Deep Research via RL in Real-world Environments（EMNLP 2025）
• WebSeer: Training Deeper Search Agents through RL with Self-Reflection（ICLR 2026）
• Agentic-R: Learning to Retrieve for Agentic Search（arXiv:2601.11888）
• BrowseComp-Plus: A Fair and Disentangled Evaluation Benchmark for Deep Search Agents（arXiv:2508.06600）
• Contextual Retrieval（Anthropic 工程博客）
• Inference Scaling for Long-Context RAG（ICLR 2025）
• LiveResearchBench（ICLR 2026）
• BrowseComp-ZH（arXiv:2504.19314）
• M³KG-RAG（CVPR 2026）
• How we built our multi-agent research system（Anthropic，厂商自报）
• Introducing deep research（OpenAI，厂商自报）
• Azure AI Search agentic retrieval（微软，厂商自报）

← 上一章 | 下一章：总结与学习路线 →

12 总结：清单、迭代路线与下一步学习

12.1 一句话回顾：从证据供给到运行时 Context

整套教程的主线可以压缩成三步：

RAG / GraphRAG：外部证据如何被找到和组织
                  ↓
Context Engineering：模型当前这一步看到什么、看到多少、如何更新
                  ↓
AI 搜索系统：触发、规划、检索、筛选、生成、反馈如何协同

RAG 不是 Context Engineering 的竞争者，也不只是一个独立的前置模块：它产生外部证据候选；Context Engineering 再把证据与任务说明、历史状态、工具结果、记忆、SKILL 和反馈组装成模型当前可见的信息。

12.2 核心行动清单：提有效 Context，降无用 Context

提有效 Context

1. 先定义任务，不要直接堆材料：明确用户目标、子问题、输出格式和停止条件；
2. 保证证据覆盖：检索结果应覆盖关键子问题，而不只是与 Query 表面相似；
3. 注入判断标准：用 SKILL、规则和 few-shot 告诉模型什么是好结果、边界在哪里；
4. 保留必要状态：规划、待办、关键工具结果、失败路径和反馈应支持后续纠错；
5. 用结构化中间结果连接模块：让下游消费明确字段，而不是反复理解上游长文本；
6. 建立反馈闭环：feedback 要包含纠偏、细化或补充方向，而不是只给分数。

降无用 Context

1. 遵循最小必要原则：子智能体只接收完成当前子任务所需的信息；
2. 去重与多样性并重：不要让 Top-k 被同质内容占满；
3. 压缩长内容，但保留证据和约束：摘要不能抹掉关键条件、来源和冲突；
4. 隔离无关历史与错误污染：连续性强的主线保留状态，可原子化的旁路任务拆开；
5. 离线换在线：图片理解、知识结构化、字段抽取等重工作尽量离线完成；
6. 低置信时降级，不要硬生成：回退规划、放宽阈值重试、追问或明确证据不足。

让 Context 可评、可回放、可归因

1. 保存规划、搜索词、候选集、过滤原因和最终 Context；
2. 把 Context、答案、业务结果分成三层指标；
3. 对触发、检索、筛选和生成分别评测，不只看最终答案；
4. 模型判分器负责规模化，人工抽审负责校准；
5. 每次优化都要验证是否在真实用户指标上兑现。

12.3 两套互补地图：四条 CE 主线 + 六个在线环节

Context Engineering 的四条主线

AI 搜索的六个在线环节 + 一个供给底座

这两套地图回答的是不同问题：

• 四条 CE 主线适合指导学习和能力建设；
• 六个在线环节适合做系统设计、故障定位和团队分工；
• 供给底座决定整条链路可以获得的内容上限。

完整全景见 第十章。

12.4 路线判断：先找瓶颈，再决定是否训练

路线之争的收尾判断：

更稳健的结论不是「永远用最大模型」或「永远不要训练」，而是：

1. 先确认问题来自模型能力、证据供给、Context 组织、工具执行还是评测；
2. 如果更强模型的时延和成本可接受，先用它验证效果上限；
3. 通过路由、缓存、Context 压缩、控制生效影响面和小模型旁路逐步优化成本；
4. 当任务稳定、数据飞轮成熟、性能或合规约束明确时，再评估微调、蒸馏或小模型训练。

值得长期沉淀的资产包括：执行框架、评测集、SKILL、差异化工具、可信数据和内容供给。它们通常比绑定某一代基座模型的临时方案更能跨代复用。

12.5 后续优化方向

1. 全局多轮 → 全局 + 局部多轮：主链路保留全局连续性，局部子任务独立重试，提高效率并减少污染；
2. 知识库建设：支持业务扩展和反思结果留存，用 RAG / KAG / GraphRAG 实现场景复用和知识扩展；
3. 过程可观测性：记录规划、候选、筛选和反馈，让每次失败可以归因；
4. 评测分层：Context 指标、答案质量和线上业务结果分别衡量、相互校验。

12.6 动手建议：从单点实验走向小型闭环

教程读到头，不如动手做一遍。建议按下面顺序进行：

1. 搭一个最小 RAG
   跟着 第三章 的代码完整搭一遍，再换一种分块策略、调整 top_k，观察召回变化。记录「候选证据」和「最终 Context」的区别。

2. 定义一组 Context 质量指标
   选 20~50 个典型 case，为相关性、覆盖度、冗余、时效和 token 成本定义评分。不要一开始追求一个完美总分，先建立能定位问题的指标集。

3. 写一条只注入 know-what 的 SKILL
   选一个熟悉的细分场景，按 第八章 的标准注入判断标准，对比注入前后的输出。再故意加入一条过细的操作步骤，观察模型是否开始固化。

4. 复现迷你版「规划 → 反馈 → 重规划」
   拿一个真实 Query，让模型输出结构化计划；再分别构造纠偏、细化、补充三类 feedback，对比三轮结果是否沿正确方向收敛。

5. 做一次 Context 消融实验
   分别移除检索证据、SKILL、历史事件、错误路径或 few-shot，观察答案质量变化。消融比单纯加料更容易判断每类信息的真实贡献。

6. 建立最小可观测闭环
   保存搜索词、候选集、过滤原因、最终 Context、答案和判分结果。让一个失败 case 可以被完整回放，而不是只剩最终答案。

12.7 延伸阅读

想继续深入，可以沿着教程中的关键概念继续阅读：

• RAG 分块策略：5 Chunking Strategies for RAG——第二章 分块部分的扩展；
• Chinchilla 缩放定律：Training Compute-Optimal Large Language Models（arXiv: 2203.15556）——第五章 成本估算的理论背景；
• The Bitter Lesson（Rich Sutton）——「奇技淫巧不敌通用方法」的思想来源；
• Anthropic：How we built our multi-agent research system——第七章 权职分离多智能体的一手资料；
• Manus：Context Engineering for AI Agents: Lessons from Building Manus——事件流与 KV cache 设计的一手资料；
• Lost in the Middle——理解长上下文中信息位置与利用率问题；
• Search-R1（arXiv:2503.09516）——用 RL 训练「怎么搜索」的代表作，见 第十一章；
• BrowseComp-Plus（arXiv:2508.06600）——检索器与 Agent 能力的分离评测；
• BrowseComp-ZH（arXiv:2504.19314）——中文网页检索为何是独立难题；
• A Survey of Context Engineering for LLMs（arXiv:2507.13334）——上下文工程的系统化综述，对应 第四章；
• How Long Contexts Fail（Drew Breunig）——四种上下文失效模式的出处，对应第四章；
• Context Engineering for Agents（LangChain 博客）——写入/选择/压缩/隔离四策略的出处，对应第四章。

素材来源

• 厂内 BIT「AI 原生研发圆桌会」分享：《地图AI搜索Context Engineering的教训和思考》《百看配图业务的Context Engineering实践》；
• MEG 叶文文「生成式搜索系统」厂内分享（技术抽象来源），石岱庭提供深入指导；
• 「熵减」分享（路线之争配图来源）；
• 基础篇《RAG全面解析：突破大模型局限，落地智能体平台构建与应用》；
• 教程中的补充内容已按 导读 的标注约定标出（概念小课堂 / 深层分析 / 重建示例），不代表分享者观点。

← 上一章 | 回到导读