Prompt 回滚不像代码：为什么 git revert 是错误的原子操作

一位资深工程师将 Prompt 的更改通过 10% 的灰度发布（canary）推送到生产环境。到了第二天早上，灰度组的有用性评分（helpfulness score）下降了四个点，值班人员发现了这一点，团队做了每个团队都会做的事情——撤回提交（revert commit）并重新部署。仪表板没有恢复。第二天也没有恢复。三天后，一份复盘报告显示，看到糟糕 Prompt 的那一组用户仍然在看到退化的输出，因为他们的对话历史中现在包含了由已撤回的 Prompt 生成的助手回复，而模型正基于这些回复进行预测。提交已经消失了，但损害仍在。

这是 LLMOps 中“像对待代码一样对待 Prompt”这一建议悄悄跳过的部分。代码回滚是文本替换，用于恢复确定性的过去状态。Prompt 回滚必须处理一系列副作用——缓存、历史记录、评估基准、实验分组、下游契约——这些都是糟糕的 Prompt 已经印刻在生产环境中的。git revert 翻转了文本，但它没有翻转后果。

代码回滚恢复状态，Prompt 回滚只恢复文本。

Web 应用部署的心理模型是：提交发布，Bug 出现，你撤回提交，Bug 消失。这个模型之所以有效，是因为应用程序在请求之间大多是无状态的，而它确实保留的状态（数据库行、缓存）要么对代码更改是不变的，要么是由部署管道显式迁移的。当你回滚时，下一个请求会针对相同的状态执行旧代码，并产生旧的行为。

Prompt 同时在五个地方违反了这一假设。

对话历史。多轮对话产品存储由实时 Prompt 生成的助手消息。这些消息在下一轮用户对话时作为上下文的一部分发送回模型。在对话持续期间，退化的 Prompt 会教会模型它是一个什么样的助手。回滚 Prompt 并不会重写历史；模型在下一轮仍然会看到自己之前的糟糕消息，并倾向于保持在那个人设中。

Prompt 缓存。现代供应商 API 和自托管的 KV 缓存以 Prompt 的精确前缀作为键。Prompt 的更改会使缓存失效。Prompt 的回滚 同样 会使缓存失效——但在两者之间的窗口期内，看到新 Prompt 的用户组已经针对新前缀建立了一个全新的缓存。回滚时该缓存会蒸发，该组用户突然在每个请求中都要承担完整的 Prompt 缓存缺失成本，导致在团队试图稳定局势的时刻出现延迟飙升。更糟糕的是，基于响应嵌入（response embeddings）的语义缓存现在充满了糟糕 Prompt 的输出，而这些输出正被提供给回滚后的 Prompt 使用。

评估基准。将 Prompt 更改挂钩在评估（evals）上的团队，当新 Prompt 的得分更高时，会重新锚定基准。一周后，新 Prompt 被回滚，但评估基准仍然反映新 Prompt 的分布。下一次 Prompt 更改现在是针对错误的参考标准进行评分的，原本应该捕获问题的绿色评估条现在失准了。

A/B 测试分组。新 Prompt 通过粘性分配暴露给 10% 的用户。这些用户拥有标记了实验分支的事件流。当 Prompt 回滚时，分配服务静默地停止将他们路由到新分支——但已经归因于新分支的事件仍在仓库中。新分支的指标现在混合了“回滚前”和“回滚后”的行为，方差激增，实验变得无法解释。统计学家称之为污染（contamination），大多数团队则称之为“实验挂了”。

下游契约。新的 Prompt 经过调优以输出略有不同的 JSON，而下游服务已经更新以消费新的格式。回滚 Prompt 会恢复旧的输出格式并破坏下游服务。管道现在有两个故障——糟糕的 Prompt 和现在损坏的解析器——值班人员必须决定是也要回滚解析器，还是对 Prompt 进行向前修复（forward-fix）。

这些故障中的每一个都是伪装成配置缺陷（config bug）的状态机缺陷（state-machine bug）。通过代码化管道发布 Prompt 的团队对于其中任何一个都没有相应的元语（primitive）。

Prompt 修订版不是提交，它们是发布状态。

解决方法是停止假装 Prompt 修订版是一个单一的人工制品。它是一个元组——(text, rollout_state, baseline_id, cohort_id, downstream_contract_version)——而回滚必须走遍该元组的每一个分支。

Prompt 状态模型明确地阐述了这一点。每个 Prompt 修订版都携带元数据：它暴露给哪些流量百分比、哪个评估基准锚定到了它的输出分布、哪些下游功能依赖于它的输出模式。回滚工作流会咨询元数据并执行五件事：翻转文本、使相关的缓存区域过期、决定如何处理看到糟糕 Prompt 的用户组、重新锚定或固定评估基准，并显示任何下游契约依赖项以供操作员确认。

加载中…