Dopamine Agent Lab
0/47
学习地图 阶段 3
Stage 03 · Reasoning, Retrieval & Context

推理、知识与上下文

模型「想不清楚」和「不知道」是两类不同的问题:前者靠推理与规划模式,后者靠检索与知识注入。 这一阶段再加一层——把所有信息按预算放进上下文,而不是能塞就塞。

4 节 约 2 小时 前置:阶段 2 RAG 是重点
本阶段进度 0 / 4

时效性提示:推理模型(内置长思考的模型)普及后,CoT 提示的收益与风险都发生了变化; 原文的框架仍然成立,但「必须手写 Let's think step by step」已不是默认最佳实践。详见审计台账对应行。

3.1

推理与规划:四种模式,各有代价

约 30 分钟 概念 + 选型 对照原文 ↗

学习目标

为不同任务选择 CoT / ReAct / Plan-and-Execute / ToT,并说明每种模式的成本与失败风险。

前置知识

2.2 模型原理;阶段 1 的循环概念。

核心要点

  • CoT 让模型显式写出中间步骤,适合数学/逻辑题;但它是提示技术,不保证推理正确,也会增加 token。
  • ReAct 把思考与工具调用交织,适合「步骤不多、需要外部信息」的任务;长任务容易上下文超载。
  • Plan-and-Execute 先出计划再逐步执行,适合可分解的长任务;最大风险是计划错了却不回头。
  • ToT / 反思 通过多路径探索或自我批评提升质量,代价是成倍调用;没有外部信号时,「自我反思」可能只是自我肯定。
  • 推理模型时代:内置长思考的模型已把 CoT 内化,默认不必再手写「一步步想」;是否加提示应由评测决定,并关注推理预算带来的成本与延迟。
  • 选型口诀:路径确定用工作流,路径不确定用 ReAct,任务长且可拆用计划,质量优先且预算足才上树搜索。

动手任务(30 分钟)

给三个任务各选一种模式并写 2 行理由 + 1 个失败风险:①查明天天气写一条朋友圈;②把一个 800 行的模块拆成三个文件;③规划 5 天北京行程(预算 5000)。写完后和同学/同事交换,看对方是否会选不同模式。

自检

Plan-and-Execute 最大的风险是什么?
计划阶段错了,执行阶段可能一路错到底;而且执行者通常看不到全局,无法判断「计划本身不合理」。缓解方式是设置检查点、允许重规划,并给执行者上报异常的通道。
用了推理模型,还需要 CoT 提示吗?
通常不需要再手工要求「一步步想」,模型已内置思考过程;更重要的是给出目标、约束、可用工具和验收标准。是否额外提示应通过评测决定,而不是照搬旧模板。

补充 · 推理模型时代的 CoT 取舍

  • 先测默认行为:内置长思考的模型通常不需要再写「Let's think step by step」;加提示前先跑同一批用例,比较正确率与成本。
  • 把「推理预算」当成参数:低预算跑简单任务,高预算只留给难题,不要全局拉满。
  • 区分「可见推理」与「内部推理」:要求输出完整思维链会增加 token,也可能泄露敏感信息;对外只需结论 + 关键依据。
  • 推理过程自洽 ≠ 事实正确:仍要用检索、计算工具或人工抽检做外部验证。
进度保存在本机浏览器
3.2

向量数据库:语义检索的能与不能

约 25 分钟 概念 对照原文 ↗

学习目标

解释 embedding 为什么能命中「换了一种说法」的内容,并判断什么场景该用向量库、什么场景该用关键词或 SQL。

前置知识

2.5 的 token 概念;基本的数据库查询经验。

核心要点

  • embedding 把文本映射成高维向量,语义相近的文本距离更近;相似度常用余弦或内积。
  • 向量检索是近似检索:HNSW / IVF 用召回率换速度,参数会影响「该找到的没找到」。
  • 元数据过滤(时间、权限、来源)必须和向量检索一起设计,否则会召回不该看的内容。
  • 纯向量不擅长精确匹配(型号、订单号、人名)——生产系统通常是混合检索:BM25 + 向量 + 重排。
  • 维度、索引类型、更新频率、成本要一起评估;小数据量(几千条)用内存暴力检索往往足够。

动手任务(25 分钟)

给你熟悉的 10 条 FAQ,写 3 组「用户问法不同但语义相同」的查询(例如「怎么退款」vs「钱能退回来吗」),判断向量检索能否命中;再写 1 条只有关键词能命中的查询(如错误码 E1024),说明为什么需要混合检索。

自检

向量数据库能替代传统数据库吗?
不能。它擅长相似度检索,不擅长事务、精确条件、聚合统计。常见做法是业务数据留在关系库,向量库存切片与引用,再用元数据关联。
召回结果「看起来都对」,但回答还是错,问题可能在哪?
可能在排序(最相关的块没进 top-k)、在拼接(上下文顺序或冲突)、在生成(模型忽略证据)。要分段定位,而不是只调相似度阈值。
进度保存在本机浏览器
3.3

RAG:把「不知道」变成「查得到」

约 35 分钟 核心 对照原文 ↗

学习目标

画出离线索引与在线查询两条流水线,并在回答错误时定位是「切分 / 检索 / 拼接 / 生成」哪一步出的问题。

前置知识

3.2 的向量检索;2.5 的上下文预算。

核心要点

  • 离线:解析 → 清洗 → 切分 → embedding → 写入索引;在线:改写查询 → 检索 → 重排 → 拼接 → 生成 → 引用。
  • 切分决定上限:块太大引入噪声,太小丢上下文;重叠用于防止边界截断,常见做法是 10%–20% 重叠。
  • 检索到 ≠ 用得好:需要重排(rerank)、去重、按时间/权限过滤,并控制注入上下文的顺序与长度。
  • 没有答案时必须能拒答;要求模型引用片段编号,便于人工核查。
  • RAG 的评估要分开看:召回率(该找到的找到没)、忠实度(是否依据证据)、答案质量(是否有用)。

动手任务(35 分钟)

拿一篇 3 页的文档,手工切成 8 块(每块 ≤300 字,相邻重叠约 50 字)。为 2 个问题分别标出「应该命中的块」,再标出「容易误召回的块」。这一步不写代码,但能让你后面调参时知道该看什么。

自检

检索到了正确片段,回答却还是错的,优先查什么?
先看拼接:片段是否被截断、是否互相矛盾、顺序是否让模型误解;再看生成指令:是否要求「只依据资料」、是否要求引用;最后才怀疑模型能力。
为什么块切得太小反而更差?
小块语义不完整,检索命中后模型拿不到必要条件(主语、前提、例外),容易拼凑出错误结论。父子块(小块检索、大块返回)是常见折中。
进度保存在本机浏览器
3.4

上下文工程:把窗口当预算,而不是垃圾桶

约 30 分钟 核心方法 对照原文 ↗

学习目标

为一个真实 Agent 做上下文预算表,并解释「工具描述」和「历史压缩」为什么常常是最大开销。

前置知识

2.5;阶段 1 的循环与记忆。

核心要点

  • 上下文分五块:系统提示、工具定义、检索内容、历史记录、用户输入;还要留输出与缓冲。
  • 工具定义常被低估:几十个工具的 schema 可能比你的系统提示大一个数量级。
  • 历史压缩有三种主流策略:截断(最便宜)、摘要(丢细节)、结构化状态(最可控,需要设计 schema)。
  • 「少即是多」:无关上下文会稀释指令、增加成本,还可能引入冲突信息。
  • 隔离与动态注册:用子 Agent 隔离大段检索、按阶段动态注册工具,能把上下文与工具选择错误一起降下来。
  • 长任务要把中间结果外置(文件 / 笔记 / 数据库),用「读取」代替「一直带着」。

动手任务(30 分钟)

为你的一个 Agent 场景填预算表:系统提示 / 工具定义 / 检索内容 / 历史 / 用户输入 / 输出预留,总和 100%。写一句取舍理由,例如「工具多但只用 3 个,改为按阶段动态注册,工具预算从 35% 降到 12%」。

自检

为什么工具描述要精简,哪怕模型「看得懂」?
它既占 token,也参与决策:描述越多、越相似,模型越容易选错工具或填错参数。精简 + 分组 + 明确参数约束通常比堆文档更有效。
摘要压缩有什么风险?
摘要由模型生成,可能丢掉关键约束、数字或否定条件,而且错误会被后续轮次继承。对必须精确的信息应改为结构化字段保存,而不是自然语言摘要。

补充 · 四个能立刻降本的做法

  • 子 Agent 隔离:把「读 20 个网页」交给子 Agent,只回传 ≤500 token 的结构化摘要(结论 / 证据 / 未决问题),主线程不保留原始材料。
  • 动态工具注册:按阶段只暴露 3–5 个工具;工具 schema 从 20 个降到 5 个,通常比优化提示更能减少选错工具。
  • 结构化状态:用 JSON 保存目标、已完成、待办、阻塞、证据;自然语言摘要只做叙述,不作为唯一状态。
  • 压缩后校验:摘要或截断后重新注入「不可丢约束」(目标、禁止项、输出格式),并用 3 条 checklist 检查。
进度保存在本机浏览器