团队上线了新提示词模板，评估框架却还在测昨天的旧版本

事件时间线清晰可见。9:02，你的平台团队将 prompt-template@v38 推送到了配置服务。11:14，你的仪表板显示一切正常。16:51，支持团队有人标记了升级件数的激增。17:03，你打开了评估套件，发现回归分数为 0.34，于是进行了回滚。复盘报告称：“在 8 小时内捕获，除了 0.04% 看到该问题的客户外，未造成进一步损害。”工程领导层对响应速度表示赞赏。

但这是错的。回归在 0 小时内就被捕获了。17:03 运行的评估套件与 09:03 运行的是同一个。它一直指向的是 v37。评估框架在进程启动时从配置服务加载了模板，将渲染后的 Prompt 以 Python 对象的形式缓存到了模块级作用域中，并且从未重新读取源文件。你的线上流量在上午 9 点切换到了 v38。而你的评估直到 17:03 有人重启了 Worker 池来“重新运行回归”时才发生变化。在长达 8 小时的时间里，客户交互是基于从未经过评估打分的 Prompt 进行的，而评估系统却一直在给生产环境中根本没人在用的 Prompt 打分。

这种故障模式没有任何仪表板能捕捉到，因为两个系统都在按自己的标准报告成功。评估套件是健康的：它运行了，产生了分数，它没有拦截任何东西，因为没有请求要求它拦截。Prompt 版本控制系统是健康的：v38 是当前版本，请求日志确认了这一点，5% 的金丝雀发布也顺利完成。出问题的是它们之间的连接——即“评估正针对生产环境中的 Prompt 运行”这一假设——而连接并没有被监控，因为没有人负责它们。

没人知道那是个缓存

配置服务的存在是为了消除在每次请求时读取配置文件的延迟。你将 Prompt 集中在 LaunchDarkly 的 AI 配置、Braintrust 的 Prompt 库或基于 Redis 的内部服务中。你提供了一个抓取最新版本的客户端 SDK。你宣称客户端很“快”，因为它有缓存。而“缓存”在实践中通常意味着：客户端在构造时抓取一次，然后在进程重启前一直信任内存中的副本。

对于随着部署频率而变化的 Prompt 来说，这种约定没问题——每次推送都会重启所有 Worker，缓存会隐式失效，没人会察觉。但一旦 Prompt 独立于代码发布，它就会失效。将 Prompt 移至配置服务的初衷就是为了让 Prompt 工程师在无需代码部署的情况下进行迭代。这意味着缓存失效问题现在成了核心支柱，而你的 SDK 提供的答案——“重启进程”——与平台旨在实现的流程是不兼容的。

评估框架意外地继承了这个缺陷。它使用相同的 SDK，持有相同的缓存副本，并运行在一个长期存在的 Worker 池上，而该池的存在正是为了避免在每次运行时重新构建评估图的成本。Worker 存活的时间越长，你就越有信心认为“评估流水线是稳定的”，而缓存的模板与生产环境的偏差也就越大。框架的稳定性恰恰是产生偏差的原因。

自我衡量的指标

更深层的问题是，由过时评估报告的回归分数在内部是一致的。评估系统针对黄金数据集给 v37 打分。v37 曾针对该数据集进行过调优。分数是 0.91。这个分数已经保持了好几周。只要评估系统继续给 v37 打分，无论 v38 或 v39 在生产中表现如何，分数都会一直是 0.91。没有异常可以报警，因为在评估系统所能看到的世界里，唯一改变的只有采样噪声。

你可以通过一个思想实验来确认这一点。如果 Prompt 服务在今年余下的时间里对每个消费者（评估、生产、金丝雀，所有人）都静默返回 v37，你的仪表板也不会有任何波动。你的评估分数会保持平稳。你的 Prompt 版本管理界面会显示 v38 为“激活”状态。你信任用来捕捉回归的指标，对于它所评估的系统是否就是你正在运行的系统，并没有任何发言权。它不可能有发言权，因为它的输入中没有任何东西能强迫它察觉到这一点。

这就是评估与生产环境脱节的结构性特征：离线评估是针对固定数据集验证固定产物。它们的设计初衷就是不随之变化。当被测试的产物在无声无息中与生产环境的产物脱钩时，正是这种让离线评估具有可重复性的设计，让它们对这种脱钩视而不见。

“评估了错误的系统”究竟代价几何

这 8 小时的窗口期本身并不重要，重要的是期间得出的结论。产品团队问：“新 Prompt 有帮助吗？”评估系统说：“没变化。”工程团队问：“我们应该发布 v39 吗？”评估系统说：“v38 没问题，继续迭代吧。”Prompt 工程师在评估仪表板上查看 v38 与 v37 的对比，没看到有意义的差异，于是得出结论：这次改动影响中性——这感觉就像是获准在当前基础上发布下一次改动的通行证，因为上一次是中性的。

等到支持团队反馈现实世界的行为时，团队已经在他们认为中性、实则发生了回归的基础上堆叠了另外三次 Prompt 改动。回滚不再是简单的“撤回 v38”，而是要“搞清楚 v38、v39、v40 和 v41 中到底是哪一个出了问题，毕竟它们中没有任何一个曾针对大家以为正在测试的数据集进行过评估”。

修复成本并非 8 小时对客户的影响，而是整整一周因评估证据失效而作废的 Prompt 迭代，以及工程团队对评估记分板的信任——一旦人们看到它在版本发布出现故障时依然报告正常，这种信任就很难迅速恢复。那种廉价的定性——“我们的评估滞后了 8 小时”——掩盖了昂贵的现实，即在该窗口期内发布的每一次 Prompt 更改都必须手动重新评估，且团队在未来的几个月里都会对评估系统产生怀疑。

强制链路真实性

修复缓存是显而易见的举动，但并非正确的切入点。即使你让 SDK 每 30 秒轮询一次变更，你依然没有回答这个问题：“评测环境评分的内容是否正是生产环境当前运行的内容？”你只是缩小了答案为“否”的时间窗口。

真正经得起考验的修复方案是：让评测环境针对生产环境已运行的内容进行评分，而不是针对配置服务当前显示的内容。具体而言：生产环境中的每一次 Prompt 渲染都应在输出响应的同时，附带输出已解析的模板哈希（Template Hash）。当评估框架（Eval harness）提取生产追踪（Trace）样本进行打分时，它会从追踪记录中读取模板哈希，并精确复原该模板——既不是缓存中的那个，也不是当前处于活动状态的那个。评测变成了“该请求实际见到的 Prompt”的函数，这使得“漂移（Drift）”失去了存在的可能。如果框架找不到所需的模板，它会直接报错，而不是静默地用昨天的副本代替。

同样的逻辑也适用于离线回归运行。Prompt 变更的 CI 准入门槛不应询问“框架是否对 v38 进行了评分”，而应询问“框架所评分的哈希值，是否与 v38 在生产环境解析出的哈希值一致”。在提交时固定产物（Artifact）。像对待模型版本一样对待 Prompt 版本：不可变、内容寻址、通过哈希而非名称与评估结果关联。正是“活动指针”这一层间接性导致了评测与生产环境的漂移；消除这层间接性，漂移就会从一个隐蔽的报告 Bug 变成一个编译错误。

对于评估框架进程本身，其准则与任何监听可变上游状态的长期运行消费者一致：要么在每次运行时重启，要么将缓存视为由上游负责失效的派生视图。折中方案——“我只持有一个引用并假设它是最新的”——是此类故障中每一个事故的标配。选边站吧。每次调用都冷启动的评测套件虽然消耗更多算力，但从不在评分版本上撒谎；而热启动但数据陈旧的评测套件虽然零成本，却总在关键时刻误导你。

能捕获下一次故障的审计

这种故障模式之所以反复出现，是因为它在任何标准运维手册（Runbook）中都没有体现。没有名为“评测与生产环境 Prompt 偏移”的指标，也没有当框架缓存时长超过部署节奏时触发的告警。团队的思想模型是“评测归评测，Prompt 归 Prompt”，两者之间的集成被视为一根电线，而不是一个系统。

一次简单的审计就能让这根“电线”显形。从过去一小时内随机抽取一个生产追踪记录。提取 Prompt 模板哈希。在同一时间窗的评测评分板中查找对应的追踪。确认评测所用的哈希与生产环境所用的哈希是否匹配。如果你的系统无法在五分钟内回答这个问题，那么评测与生产之间的链接就是隐性的，这意味着它们正以一种尚未被察觉的方式脱节。下一次由于评测陈旧引发的事故已经在路上了，只是你还没看到相关的支持工单。

能在这类问题中幸存的团队并不拥有更聪明的评测方案。他们拥有的是除非能证明评分对象、否则拒绝生成分数的评测流水线，并且他们将这种证明视为交付物的一部分。分数本身只是一个数字。分数加上 Prompt 哈希、加上模型版本、再加上数据集的 Commit，才是一个完整的产物（Artifact）。除此以外的任何东西，都只是上述时间线中的仪表盘——在一个评测流水线从未真正触达的系统上，盲目地亮着八小时绿灯。