# 第 23 章 回归与迭代

## 本章目标

- **O1** 能够追踪“基线版本”“候选版本”“受影响回归”之间的前向与反馈路径（产物：版本回归比较表）
  - 证据: 版本回归比较表画出“基线版本”“候选版本”“受影响回归”的前向路径和返回路径
- **O2** 能够构造版本回归比较表，注明每轮输入、判断和回写证据（产物：版本回归比较表）
  - 证据: 版本回归比较表为每一环写明输入、判断、输出和负责人
- **O3** 能够控制版本变量并比较基线与候选的受影响回归（产物：版本回归比较表）
  - 证据: 产物列出模型、提示、上下文、工具、数据集和裁判版本及差异

## 学习路径

- **初学者**: 本章迁移任务是：能够控制版本变量并比较基线与候选的受影响回归。先按图中的“反馈闭环”关系完成版本回归比较表的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够控制版本变量并比较基线与候选的受影响回归。提交版本回归比较表后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: 版本回归比较表
- **图解类型**: regression-loop
- **关系语义**: 三环先沿前向路径产生结果，再由返回路径把观察写回；没有回写就不构成闭环。
- **核心概念**: 基线版本 · 候选版本 · 受影响回归

![第 23 章版本回归比较表教学图](/learning/diagrams/zh/chapter-23.svg)

沿前向与返回两条路径检查版本回归比较表，确认结果确实改变下一轮输入。

图先从“基线版本”前向经过“候选版本”到“受影响回归”，再以虚线返回起点。前向箭头产生结果，返回箭头承载观察和修正；若结果没有回写到下一轮输入，流程只是单程而不是闭环。

> **公开课程改编版。**正文依据内部教材整理，保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学，不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限；重试次数不自动触发恢复；恢复须先保护工作并确认目标、共享状态和外部数据影响。

## 课程讲解

### 23.1 变更触发的回归：谁变了，就跑哪一层

第 22 章结束时，你的工单分类助手已经有了 60 条的分层标注集和被校准过的 judge。两个月后的周一，新的考题来了：模型供应商发布了新一代模型，单价低 40%，客户的技术负责人在周会上问："我们为什么不换？"这不是"改一句话提示词"量级的问题了——换模型意味着输出分布整体移动，正确性、幻觉率、格式、成本、延迟五个维度全部要重新量一遍。

这就是本章的主题：变更之后，如何系统地重评并与基线对比，让"能不能换、该不该改"变成一次有数字依据的回归评估，而不是一次祈祷。

核心原则一句话：谁变了，就跑哪层。变更类型决定最小回归面——改一句措辞不需要跑全量，换模型也不能只跑十条。展开成一张变更触发矩阵：

| 变更类型 | 典型场景 | 影响面 | 至少跑 | 通过门槛 |
|----------|----------|--------|--------|----------|
| 提示词小改 | 措辞调整、口径微调 | 通常局部，但可能全局漂移 | smoke 层 | 全对才继续；错了停下排查后再跑回归层确认 |
| 提示词结构性重写 | 换角色设定、换输出框架 | 全局 | 回归层全量 | 总通过率不低于基线，且分类别通过率无塌方 |
| 换模型 / 模型升级 | 新版本发布、降本迁移 | 全局，五个维度重新权衡 | 回归层 + 对抗层 | 出通过率 + 幻觉率 + 格式遵循 + 成本 + 延迟的五维对比表，逐维决策 |
| 采样参数 | 温度、top-p 调整 | 输出分布整体移动 | smoke 层 + 回归层抽样 | 固定口径下复跑稳定，无系统性漂移 |
| 上下文工程 | 换检索策略、改工具定义、换文档批次 | 全局 | 回归层全量 | 同提示词结构性重写 |
| judge 配置 | 换 judge 模型、改 rubric | 尺子本身 | 先做人机一致率抽检，再重跑全量重建基线 | 新基线生效前，历史分数只作参考、不作对比 |
| 不影响模型行为的代码变更 | 经确认不改变输入、调用路径或用户可见模型行为的纯展示样式 | 代码行为 | 软件测试电网（第 25 章） | 测试全绿，且影响分析支持 eval 豁免 |

两个容易忽略的纪律。第一，judge 配置变更在矩阵里是特殊行：第 22 章讲过，换 judge 会让所有历史分数失去可比性——所以它的动作不是"跑一遍看分数"，而是先重新校准尺子、再重建基线。第二，eval 豁免取决于行为影响，不取决于模型是否更换：编排代码会改变检索、工具调用、重试、输入组装或上下文顺序，应按影响面跑对应 eval，同时跑软件测试。只有确认不影响模型输入、调用路径和用户可见模型行为的代码变更，才可只走测试电网。矩阵的意义恰恰是把"不必跑的"也写下来，回归纪律才守得住。

跑的时候要固定可比口径，否则跑出来的数字没有意义：

1. 记录实际运行配置：使用与拟发布方案一致的采样设置，声明温度、top-p、模型版本；若接口支持，记录 seed 与 system_fingerprint。固定 seed 可减少波动，但不保证确定性，不能为了分数稳定而偷偷改成生产不用的零温度；
2. 同版本对比：与基线比较时，golden set 版本与 judge 版本必须一致（23.2 节展开）；
3. 区分波动与退化：报告分类别的样本数、失败数和重复运行结果，按预先约定的复跑次数与判定阈值作决定。小批次中某类别下降是调查信号，不自动证明真实退化；禁区失败则先触发门禁处置，不能以等待统计确认推迟阻断。

每次重跑留一条台账记录：变更内容、golden set 版本、judge 版本、各层结果。台账不需要复杂工具，一张表即可，但 23.2 节的基线锁定和 23.3 节的反馈闭环都拿它做原料。

### 23.2 版本化与基线锁定：模型输出的防退化契约

回归评估要成立，前提是"跟谁比"是确定的。这要求三样东西全部版本化：

- golden set 版本。用例集本身就是代码级资产：进 git，改用例走与改代码同样的 review，每次增删带着变更说明（新增了哪次事故的回流、归档了哪些失去区分度的用例）。用例集偷偷变动而版本不动，通过率的每次涨跌都无法解释。
- judge 配置版本。judge 模型、rubric 文本、校准例三者捆在一起算一个版本，任何一项变更都升版本号。第 22 章末尾的那条纪律在这里兑现。
- 结果基线。每次变更通过回归验收并发布时，把当次全量结果快照锁定为基线。后续一切比较都对着它，而不是对着"上次记得好像是 91%"。

由此得到可比性法则：任何两次 eval 结果要构成"对比"，必须同 golden set 版本、同 judge 版本、同运行口径。三者缺一，数字就不可比。典型事故长这样：团队换了 judge 模型，同一系统的通过率从 87% 涨到 92%，周会上庆祝质量提升——其实系统一行没动，只是尺子变了。正确的动作是 judge 升版本后，先用新 judge 把基线那次的全量结果重跑一遍，重建可比基线，再谈新旧对比。

这套做法与第 25 章的"防退化契约"是同一个思想在两个世界的投影——那边锁代码行为，这边锁模型输出：

| | 代码防退化（第 25 章） | 模型输出防退化（本章） |
|---|---|---|
| 守什么 | 代码行为不退化 | 模型输出质量不退化 |
| 锁什么 | commit hash | 基线快照（golden set 版本 + judge 版本 + 运行口径 + 结果） |
| 证明什么 | 新代码 ≥ 基线：测试不减少、覆盖率不下降 | 新配置 ≥ 基线：通过率不倒退、分类别无塌方 |
| 资产如何生长 | bug 修复沉淀为测试用例 | 失败案例回流为 golden set 用例（第 22 章的完成定义） |
| 退化后如何恢复 | 回滚到基线 commit | 回滚到基线的 prompt / 模型配置版本 |

最后一行值得强调：prompt、模型选择、采样参数都要像代码一样可回滚——配置进版本控制，基线版本可一键恢复。代码世界没人会把生产配置只存在某个聊天窗口里，模型配置同理。

还有一个节奏问题：基线何时晋升。答案是"变更通过回归验收并发布之时"——发布即锁新基线。不晋升的代价是隐性漂移：每次都与越来越旧的基线比，中间若干次小变更的累积偏移无人察觉，直到某天与基线差了十几个点，已经说不清是哪一步走歪的。

### 23.3 eval 驱动的反馈闭环：从"证明没改坏"到"决定下一步"

前两节解决的是防守：变更之后证明没改坏。但 eval 的价值不止于门禁。OpenAI 旧金山 FDE 岗位说明把生产采用、可衡量的工作流影响以及能改变产品和模型路线的评估反馈作为成功依据，并要求工程师向产品与研究团队反馈模型在现场的表现。这里转述的是该公司岗位要求，不是所有 FDE 的统一标准。对本课程而言，评估应形成能指导后续决策的证据，而不只是一张通过率报表。

这条反馈闭环有两个环。外环通向模型方与产品方——把现场 eval 证据反馈给供应商的产品与研究团队，影响模型与产品的演进方向，那是第 29 章"知识外循环"的主题。内环通向你自己：评估结果驱动你的方案迭代决策。本章先把内环转起来：先判严重性与禁区，禁止失败先阻断发布或撤回／回滚；以下四个出口均服从这条前置规则：

| 回归结果 | 决策 | 动作 |
|----------|------|------|
| 全面不低于基线 | 采纳 | 发布，晋升基线，台账留痕 |
| 总体持平、局部塌方 | 先判严重性，再定向修 | 触及禁区先阻断发布，已发布则撤回或回滚；其余在批准边界内修复，重测失败类别及受影响回归层 |
| 明显低于基线 | 回滚 | 恢复基线配置；变更作废但结论入库 |
| 多轮迭代仍不达标 | 升级 | 问题可能不在提示词而在方案——换模型、换架构或缩小承诺范围，带 eval 数据向客户与团队摊牌 |

所有出口之前先判严重性与禁区：即使总通过率持平，越权、敏感信息泄露等禁止失败也不能放行；第 39 章拒绝配置 B 就遵循这条优先规则。未发布则阻断，已发布则按风险撤回或回滚，再安排有限修复。通过率只是后续选择依据，不能覆盖硬门禁，也不能通过降低验收标准把失败改成 PASS。

第三行常被浪费：回滚的变更也是资产。"新模型在我们的工单数据上幻觉率翻倍、不适合"是一条负面知识，写进台账，三个月后有人再想试同一个模型时它直接省一轮迭代。不记录负面结论的团队会反复为同一个死胡同付费。

内环的真正纪律是：迭代决策必须引用数字。方案评审会上，"我觉得新模型更好"不是合格发言；"回归层 94% 对基线 91%，但幻觉率 3.1% 对 1.8%、P95 延迟增加 800 毫秒，建议只把它用在分类环节、生成环节维持原模型"才是。第 21 章说"在 evals 上爬坡"，爬坡的具体动作就是这一个一个带数字的决策点。

还有一环通向客户。eval 趋势是客户沟通的硬通货：周报里一张通过率与幻觉率的趋势图，配上每次变更的标注，胜过十句"系统运行良好"。这也回答了本章开头客户技术负责人的问题——换不换模型，最终你递给他的是一张五维对比表和一个带条件的建议，而不是一个感觉。

### 23.4 eval 接入六步工作法：验收双轨

第 7 章的六步工作法——拆解 → 下发指令 → 编码 → 验收 → 分支判断 → 更新图纸——是针对代码交付设计的。本节把它接上 eval，接法不是再造一套流程，而是扩展第四步"验收"的对象：代码验收 + 模型输出验收，双轨并行。

| | 代码验收轨 | 模型输出验收轨 |
|---|---|---|
| 验收对象 | AI 生成的代码 | 变更影响下的模型输出 |
| 工具 | 五维清单（功能 / 代码 / 边界 / 安全 / 蓝图）+ 测试电网 | smoke / 回归层 eval 与基线对比（第 21–23 章） |
| 结论 | PASS / NEEDS_FIX / REBUILD | 同样三值：不低于基线 / 局部塌方 / 明显低于基线 |
| 触发条件 | 每个里程碑 | 仅当里程碑触及模型行为：改提示词、调采样参数、改上下文、换模型 |

双轨的接入点分布在前四步，每步只加一点：

1. 拆解：给每个里程碑加一个标注——"是否触及模型行为"。在拆解时标注，而不是到验收时才想起来。
2. 下发指令：触及模型行为的里程碑，把 eval 通过标准直接写进指令。第 7 章的"验收标准本身就是最好的指令"在模型侧同样成立——"改完后 smoke 层 15 条全对，回归层分类别无塌方"写进指令，迭代方向从一开始就被约束住。
3. 编码：不变。AI 改提示词与改代码一样，你只观察不打断。
4. 验收：代码轨照旧；模型轨跑 23.1 的触发矩阵——小改动 smoke 层，结构性变更回归层。

第五步"分支判断"先检查严重性与禁区：禁止失败先阻断或撤回／回滚。只有硬门禁通过，且所有约定条件满足时，才将不低于基线映射为 PASS；非关键局部问题可在批准范围内进入 NEEDS_FIX，修复后重测失败类别、受影响回归层和 smoke，不能只跑 smoke；明显低于基线则 REBUILD，恢复基线配置。第六步"更新图纸"同样扩展：基线晋升、回滚的负面结论，都写进蓝图——它们和架构决策一样，是下个会话需要的项目记忆。

同样重要的是不做什么：不触及模型行为的里程碑（经影响分析确认的纯展示样式）只走代码轨，不要为跑而跑。双轨验收的目的是把验证成本花在真实风险上，而不是给流程增加仪式。

到此，第七部分的三块拼图合上了：第 21 章让模型输出可度量，第 22 章让度量可信任，本章让度量可回归并接入日常工作流。评估体系守住了 AI 系统质量中不属于代码的那一半。

【自检清单】回归与迭代自查

- [ ] 我的团队有一张写下来的变更触发矩阵吗——每类变更至少跑哪层、门槛是什么？
- [ ] judge 配置变更后，我们是先重建基线再对比，还是直接拿新旧分数比？
- [ ] 是否记录与拟发布方案一致的运行配置、受支持的 seed/fingerprint，以及减少波动仍不保证确定性的限制？
- [ ] 单条失败与类别塌方，我有区分波动与退化的复跑规则吗？
- [ ] golden set、judge 配置、结果基线三者是否都有版本，且比较双方版本一致？
- [ ] prompt 与模型配置在版本控制里吗？基线版本能一键恢复吗？
- [ ] 最近一次回滚的变更，结论入库了吗——还是改完就翻篇？
- [ ] 方案评审会上，最近一个"该不该换模型"的决策引用了哪几个数字？
- [ ] 六步工作法里，触及模型行为的里程碑是否在拆解时就被标注、指令里就带 eval 通过标准？

### 【练习】给一次模型迁移做完整的回归评估

题目：延续第 22 章练习的 60 条分层标注集，假设供应商发布新模型、客户要求评估迁移。按 23.1 的触发矩阵跑一次完整回归：固定运行口径，新旧模型按预先约定的复跑次数分别运行回归层与对抗层，产出五维对比表（通过率 / 幻觉率 / 格式遵循 / 成本 / 延迟）；按 23.3 的四个决策出口给出结论并写一段给客户技术负责人的建议（中文版不超过 200 字，英文版不超过 200 words，均须包含依据、条件与下一步）；无论结论是采纳还是回滚，都补一条台账记录。

引导：重点体验两个落差。①对比落差：五个维度几乎不可能全面占优——当你发现新模型通过率更高但延迟不可接受时，你会被迫回答"哪个维度对客户是刚性的"，这个取舍过程就是评估从技术问题变成交付问题的时刻。②口径落差：第一次跑完两组数字后，试着改动一个用例再跑一遍，观察通过率如何被用例集本身的变动污染——你会立刻理解 23.2 的可比性法则为什么必须是硬约束。

参考方向（供讲师参考）：评阅主要看四点。口径是否固定（温度、seed、用例集版本有没有在报告里声明）；五维是否齐全且分别给数（只报一个综合分的视为不合格）；决策出口是否先判严重性与禁区（局部失败也可能必须阻断或回滚），有限修复后是否重测失败类别和受影响回归层；给客户的建议是否有条件、有边界（"全面换"与"不换"两个极端都值得追问依据）。常见反例是对比表很漂亮、但没有声明用例集版本——这样的数字经不起一次追问。

---

> 本章业界事实的来源说明：有关生产采用、工作流影响与评估反馈的说明，转述自 2026-09-28 核验的 OpenAI 旧金山 FDE 岗位页，非逐字引用；"在 evals 上爬坡"的表述出自 The Pragmatic Engineer 2025 年 8 月对 OpenAI FDE 负责人的采访记录（见第 21 章来源说明）。本章关于变更触发矩阵、版本化与基线锁定、反馈闭环四个出口、验收双轨的内容，属于本书的方法论展开，不归属特定公司的内部实践。本章未另引行业统计；未标明来源的案例、数字、复跑次数与节奏均为教学假设，应由项目数据和预先约定的门槛替换。关于 seed 仅尽力复现、仍可能不确定的技术限定，参见 [OpenAI Cookbook](https://developers.openai.com/cookbook/examples/reproducible_outputs_with_the_seed_parameter)。

---

> 第七部分完成。你已经能回答本部分开头的那三个问题：改了提示词怎么知道没改坏——变更触发矩阵加基线对比；换了新模型怎么知道该不该换——五维对比表加四个决策出口；客户问"系统到底行不行"拿什么回答——可重跑的数字与趋势。评估体系守住了模型输出这一半质量；下一部分（第 24–26 章）守住另一半——质量与风险治理：红线、门禁、测试电网与风险度量。其中第 25 章的测试电网与本章的 eval 回归，正是同一份防退化契约在代码世界与模型世界的两道对偶防线。

---

## 独立练习

使用虚构或已获授权的脱敏材料，先独立作答，再查看参考。将产物保存为 `chapter-23.md`，写上版本、决定、证据和缺项。

比较基线与候选分类器，记录代码、提示、模型、数据和裁判版本。假设裁判升级后分数提高，写可比较重跑方案。

<!-- chapter-artifact-requirement -->
### 本章必交产物：版本回归比较表

以下证据必须出现在本次独立练习的提交物中；正文原有问题用于提供内容，不能替代这些验收项。

- O1: 版本回归比较表画出“基线版本”“候选版本”“受影响回归”的前向路径和返回路径
- O2: 版本回归比较表为每一环写明输入、判断、输出和负责人
- O3: 产物列出模型、提示、上下文、工具、数据集和裁判版本及差异

<details>
<summary>查看参考反馈（先独立作答）</summary>

## 参考反馈

先用新裁判重评基线和候选的同一输入及保存输出，明确重新生成输出是否另一个实验。查看逐例变化、红线和成本，不只看均分。数据或模型变化时重建可比基线；不得将换尺造成的涨分宣称为产品提升。

### 自评与下一步

对照本章目标检查：决定是否明确，依据是否能复现，未知项是否如实记录。参考给出一种判断方式，不是唯一答案；若不同结论能提供同等证据，可请同伴复核。缺少证据的部分记未完成，再回到对应步骤补充。

</details>

## 来源与边界

登记来源只支持本章涉及的外部事实；版本回归比较表、示例数字和练习情境属于课程内部教学设计，必须在实际项目中重新验证。

- [建立成功标准与评估](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests) — Anthropic, 2026-09-17. 评估应从可观察成功标准、用例和版本化证据开始。
- [GitHub Actions 官方文档](https://docs.github.com/en/actions) — GitHub, 2026-09-17. 仓库工作流可以自动执行构建、测试和持续集成任务。
- [使用 seed 获得尽力复现的输出](https://developers.openai.com/cookbook/examples/reproducible_outputs_with_the_seed_parameter) — OpenAI, 2026-09-17. seed 与系统指纹可提高复现性，但不保证完全确定。
- [FDE 的起源、角色区分与 OpenAI 工作阶段访谈](https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers) — The Pragmatic Engineer, 2026-09-17. 该访谈报道 FDE 起源脉络、OpenAI 的 SA/FDE 区分、客户项目三阶段及团队知识分享节奏；属于二手访谈材料，不代表行业通用标准。
- [Forward Deployed Engineer 旧金山职位说明](https://openai.com/careers/forward-deployed-engineer-(fde)-sf-san-francisco/) — OpenAI, 2026-09-28. 该岗位涵盖发现、技术定界、系统设计、构建、上线、采用和现场反馈；这是 OpenAI 的岗位说明，不是行业统一标准。