学习如何在尊重客户基础设施和变更控制的前提下，发布、监控、回滚并持续评测生产环境中的 AI 系统。
前面每一页都在让系统变得更好。这一页讲的是如何把它交付到客户的生产环境中，并在那里保持健康运行。这是从演示到生产这一鸿沟的运营层面，也是可用的原型最常夭折的阶段。对于 AI 系统而言，部署有一个连优秀的基础设施工程师都会栽跟头的变数：你交付的东西可能在没有改动任何一行代码的情况下变差。
为什么这就是这份工作的本质
FDE 要把系统交付到客户杂乱的真实数据上，嵌入他们的发布流程中，并满足他们的正常运行时间要求。一个在干净样本上运行良好的演示，现在要面对真实输入的完整分布。有两点让 AI 部署自成一派。第一，定义行为的产物不只是代码：一次提示词修改或模型升级，会在服务代码没有任何 diff 的情况下改变输出。第二，“正确”是概率性的，因此你的发布门禁不能是全绿的单元测试套件，而必须是针对代表性数据集的评测得分。一个像部署无状态 Web 服务那样部署 LLM 应用的工程师，会发布一次悄无声息的回归，直到客户发现才知情。
在继续阅读之前： 你的服务代码一个月没有动过，但用户说回答质量变差了。没有任何东西被“部署”过。发生了什么变化？本应该由什么来发现它？
非代码产物中的某些东西变了：模型供应商更新了模型，语料库被重新索引，或者提示词在上游被调整过。本应该发现它的是定时评测，即使代码没有变动也会运行，因为在 AI 系统中，决定行为的输入超出了你的代码仓库范围。
一个有据可查的静默漂移案例
本页的前提——系统可能在没有任何代码变更的情况下退化——有一个真实的凭证，正确解读它就是这堂课的一半。2023 年，研究人员在间隔数月的时间里测量了相同的 GPT-3.5 和 GPT-4 端点，发现同一服务的行为发生了变化（How Is ChatGPT's Behavior Changing over Time?，Chen、Zaharia 与 Zou，后发表于 Harvard Data Science Review）。该论文的第一个版本报告称，GPT-4 判断质数的准确率从 3 月的 97.6% 下降到 6 月的 2.4%，这个数字在互联网上流传，成为模型变差的证据。
更敏锐的解读随后出现。Arvind Narayanan 和 Sayash Kapoor 指出，该任务中的每个数字实际上都是质数，因此，一个仅仅改变了习惯的六月版模型——默认回答“不是质数”，并且不再像三月版答案那样写出逐步推导过程（该研究记录到平均答案长度从 638.3 个字符骤降至 3.9 个）——即使没有丧失任何算术能力，得分也会接近零。发生漂移的是行为，而能力损失从未被证实。作者随后围绕一组均衡的质数与合数修订了该研究，GPT-4 的得分从 84.0% 降至 51.1%：这是真实的退化，但远小于标题所暗示的程度。
对于 FDE 而言，由此可以得出两点。在提示词冻结不变的情况下，模型可能在你的脚下发生偏移，这正是上面发布门禁中无需改动代码即可运行的定期评测的价值所在。而当该评测确实亮起红灯时，质数事件是值得记住的警示：构建评测集时要使其能够区分行为变化与能力损失，因为针对其中一种问题的修复方案，往往不适用于另一种。
具体举措
- 对所有影响输出的内容进行版本管理。 提示词、模型标识符、检索索引、评测集和基线都是发布产物。将它们固定下来，记录哪些版本产生了哪些输出，这样你就能回答“什么变了？”并回滚到已知的良好组合。
- 分阶段推出。 先让少数真实用户在真实数据上进行试点，然后是有限群体，最后全面铺开。每个阶段都会暴露出上一阶段未发现的失败，因为真实的使用场景比任何测试都更广泛。Morgan Stanley 的合作项目正是出于这个原因，在全公司范围推出之前以评测作为门禁。
- 以评测作为发布门禁。 回归测试套件就是你的 CI：只有当评测结果与已提交的基线相符时，变更才能发布。这一机制把“我们改进了提示词”变成基线能够证实的声明。
- 保留回滚方案并在发布后持续监控。 部署不是终点；每次发布都要配备快速回滚机制，以及用于捕捉生产环境中质量退化的可观测性手段——仅靠正常运行时间是发现不了这些问题的。
易变技术栈的发布清单
在每次推出之前，重新审计那些会随时间老化的部分：确认固定的模型仍然受支持、索引仍然反映语料库的最新状态，然后针对最近的基线重新运行评测。新鲜度是发布门禁的一部分。
发布清单文件
版本管理的思路在你把它写成一个文件之前都是抽象的。下面是可观测性事故中研究图书馆助手某次发布所固定的内容：每个发布对应一份清单文件，与代码一起提交在服务旁边。（以下清单仅为示例。其中的版本、日期和分数都是虚构的；值得研究的是它的结构。）
# release-manifest.yaml — 一次发布的版本化工件（示例） release: 2026-06-14-a service_code: git 4f1a9c2 # 普通提交——往往一次发布到下一次发布都不变 prompt: version: v14 # 提示词模板，独立进行版本管理 model: id: frontier-large-2026-05 # 提供商的模型标识符；提供商会按计划弃用模型 retrieval_index: snapshot: idx-2026-05-31 # 嵌入语料库，固定为快照 built: 2026-05-31 # 构建日期，索引过期事故正是由此引发 eval_baseline: suite: research-library-v3 # 发布所依据的固定问题集 must_clear: 0.90 # 只有运行得分达到或高于此值时发布才会上线 rollback_to: 2026-05-20-b # 上一个已知良好的清单，随时可恢复
这份清单就是评审者要读的差异：五条定义行为的配置行，与往往没有变化的服务代码分离开来。它同时也是回滚目标：恢复一次发布意味着同时恢复提示词、模型和索引。这正好戳破了本页开头提到的那个谎言：
service_code
可以保持不变，而其底层的模型标识符或索引快照却在变动——这正是
stale-index regression.
分阶段推出，每一步都设卡把关
清单说明发布是什么；推出过程说明它如何一步步赢得面向所有人的资格。每个阶段都会运行固定的评测套件，并将得分与清单所承诺的基线进行比较。通过则扩大受众；出现回归则停止发布并恢复回滚目标。下面是研究库助手的
2026-06-14-a
发布的推出过程，模型升级为
frontier-large-2026-05
，自上而下阅读。（该轨迹为示例。群组、得分和时间均为虚构。）
release 2026-06-14-a · baseline research-library-v3 @ 0.90 (illustrative)
[pilot] 8 advisors, real questions, 2 days (t=0)
handpicked users on live data — the first contact with reality
[gate] eval research-library-v3 after pilot
score 0.93 vs baseline 0.90 → PASS
widen: pilot cleared, open to the limited cohort
[limited] 120 advisors, one desk, 3 days
a broader slice — questions the pilot never asked
[gate] eval research-library-v3 after limited cohort
score 0.86 vs baseline 0.90 → FAIL (−0.04)
the new model regressed on the fixed suite; below the line
[halt] rollout stops here — full audience never reached
restore rollback_to: 2026-05-20-b
prompt, model, and index revert together to the last known-good manifest
cost of the regression: one desk for part of one day, no wider评测得分是概率性系统所使用的关卡，而确定性系统只需看到一片绿色的测试套件即可。它在每个阶段都要运行，因为随着受众扩大，失败的代价也更高：试点阶段的
0.93
本可以通过，但有限群组阶段的
0.86
在每位顾问都继承这次回归之前就拦下了发布。
差 / 良 / 优 —— “你如何部署并让它持续运行？”
差 —— “我们部署服务并监控正常运行时间。” 你把它当成了普通的 Web 应用。正常运行时间说明不了答案是否依然良好，而且你没有对真正驱动行为的那些工件做任何版本管理。第一次静默回归对你而言是不可见的。
良 —— “分阶段推出，上线前先测试质量。” 真正的部署规范：上线前的质量检查和分阶段发布都很扎实。差距在于：一次性的上线前测试无法捕捉上线后模型或语料库的漂移，而且对非代码工件也没有版本管理的说法。
很好——“一切影响输出的东西都是可版本化的产物——提示词、模型、索引、评测基线——我按试点到限量再到全量的方式发布，每次发布都以评测是否守住基线作为门禁，保留回滚到已知良好版本集的能力，并按计划定期运行评测，这样即使没有代码变更的改动也能被发现。部署是一个持续的门禁，而不是一次性的上线事件。” 你把行为变成了可版本化的东西，让评测成为门禁，并针对静默回归这种故障模式做了设计。
面试中要带上的要点
当设计讲到“然后我们就上线”时，不要止步于发布。要说明你会版本化什么（提示词、模型、索引、基线，而不仅仅是代码），你会如何在真实数据上分阶段发布，以及你的发布门禁是按计划定期运行的评测，后面还有回滚机制。把 AI 部署当作一个持续的、以评测为门禁的过程——一个在代码首次上线后仍长期运行的过程——是每一次真实项目赖以运转的运营主轴。
相关： 评测（发布门禁）、可观测性（捕捉回归）以及 真实部署（在真实、杂乱的数据上部署）。
下一步： 客户成果 — 概览 — 生产工具箱已经完备；接下来是决定你用它构建什么的客户实战技艺。