跳转到主要内容

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

阅读需 1 分钟Tian PanTian Pan

一位资深工程师将 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 的用户组、重新锚定或固定评估基准,并显示任何下游契约依赖项以供操作员确认。

会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 10 分钟

每个租户的提示词编译:当你的系统提示词变成构建产物时

多租户 AI 团队在面对每个租户的提示词差异时,会意外地变成编译器工程师 —— 而运营账单会在第 6 个月如约而至。本文探讨了为什么大规模的提示词应该是构建目标,而不是配置文件。

insider
prompt-engineering
阅读需 8 分钟

无法回滚的功能开关:提示词

提示词的修改会瞬间改变所有用户的生产环境行为,既没有金丝雀发布,也没有有效的回滚机制。本文将探讨提示词和模型版本固定为何脱离了发布规范,以及将其重新纳入规范的五个原语。

insider
llmops
阅读需 10 分钟

LLM 升级的金丝雀发布:为什么模型上线与代码部署的失效方式完全不同

替换 LLM 版本并非简单的代码部署。输出语义会发生偏移,下游解析器会因为细微的结构差异而崩溃,等你的监控告警响起时,成千上万的用户可能已经遭遇了失败。本文将介绍让模型升级变得可预测的工程规范。

insider
llm
阅读需 10 分钟

Prompt 金丝雀部署:像资深 SRE 一样发布 Prompt 变更

Prompt 修改与代码部署一样危险 —— 但几乎没有人以这种方式对待它们。本文介绍了流量切分、质量监控和回滚纪律,这些实践将那些能在用户发现之前捕获性能退化的团队,与那些通过 Twitter 才知道出问题的团队区分开来。

llmops
prompt-engineering
阅读需 11 分钟

那些被你的提示词工程师转变为生产环境 Few-Shot 示例的评估集

当提示词工程师将精心挑选的评估示例重新用作 Few-shot 演示时,一种团队级的数据泄漏正潜伏在指标不断攀升的评估仪表盘背后。本文将探讨为什么这种污染是隐形的,真正的独立性究竟需要什么,以及谁必须被赋予说“不”的权力。

insider
ai-engineering