#发布与版本管理：Prompt、模型、工具和评估集如何一起上线

传统软件发布通常围绕代码版本。LLM 应用不一样。

一次线上质量变化，可能来自 prompt 改了一句话、模型默认版本更新、温度参数调整、检索阈值变化、工具返回字段新增、schema 收紧、缓存失效策略变化，或者评估集没有覆盖新的用户输入。发布与版本管理的目标，是让这些变化不再散落在配置、后台和人工记忆里，而是成为可评审、可灰度、可回滚、可比较的生产资产。

#1. 提出问题

在一个客服回复助手里，团队每周都会优化 prompt。运营希望语气更友好，法务希望免责声明更严格，客服希望答案更短，工程团队又计划把主模型升级到新版本。与此同时，知识库索引和订单查询工具也在迭代。

某次上线后，客服反馈“回复更像人了”，但一周后投诉上升。排查发现：

• prompt 删除了一条“必须引用知识库证据”的约束。
• 新模型对同一 prompt 的输出更流畅，但更容易补充未验证信息。
• 订单工具新增字段后，模型把测试字段当成正式状态。
• 灰度期间只看了点赞率，没有看引用缺失率和人工修改率。
• 旧版本没有保留完整配置，无法一键回滚到上一个稳定组合。

这个问题不是某个人不小心，而是发布对象没有被当成一个整体管理。AI 功能上线时，真正发布的是一组资产：prompt、模型、参数、schema、工具、检索配置、缓存策略、评估集和监控阈值。

#2. 分析问题

发布管理要解决的是“变化是否可控”。

模型适合帮助生成候选 prompt、总结失败样本、辅助对比版本差异。但它不应该决定是否发布到生产。发布决策必须由评估结果、业务指标、风险等级和人工审核共同决定。

AI 发布需要同时关注四类兼容性。

• 行为兼容：新版本是否保持核心答案质量、引用要求和语气边界。
• 数据兼容：schema、工具返回和下游存储是否匹配。
• 成本延迟兼容：新模型或新上下文是否导致成本和延迟超预算。
• 回滚兼容：旧版本配置、缓存、索引和工具是否仍可恢复。

如果没有评估集和线上指标，发布只能靠主观体感；如果没有版本快照，即使知道新版本有问题，也很难准确回退。

#3. 列举方案

发布治理可以从简单版本号逐步升级到完整 release pipeline。

第一层是手工记录版本。早期至少给 prompt、模型和参数一个版本号，变更时写清原因、影响范围和回滚方式。

第二层是配置快照。把 prompt、模型、参数、schema、工具契约、检索配置、缓存策略和监控阈值打成一个可引用的 release bundle。线上请求日志记录 bundle 版本。

第三层是离线评估。每次发布前跑固定样本、近期失败样本、高风险样本和长尾样本，比较质量、schema 成功率、引用正确率、成本和延迟。

第四层是灰度发布。按内部用户、低风险租户、小流量或特定功能入口逐步放量。灰度不是只看“有没有报错”，还要看人工采纳率、引用缺失、fallback、成本和延迟。

第五层是线上监控。发布后要把新旧版本分组对比，避免总指标掩盖局部退化。

第六层是自动或半自动回滚。当错误率、成本、延迟或质量指标越过阈值时，可以关闭新版本、切回旧模型、恢复旧 prompt、禁用新工具或转人工。

第七层是反馈闭环。每次事故和灰度失败，都要沉淀为评估样本、发布检查项或工具契约测试。

简单 prompt 足够的场景，也需要基本版本和变更记录；一旦输出入库、调用工具或面向外部客户，就必须升级到评估、灰度和回滚。

#4. 决策判断

常见反模式：

第一，把 prompt 当文案，不当代码。prompt 会改变生产行为，必须有 diff、评审、版本、测试和回滚。

第二，只评估最终答案，不评估中间链路。新版本可能最终答案看起来不错，但引用缺失、工具调用变多、成本翻倍或 schema 失败率上升。

第三，模型升级跟 prompt 改动一起全量上线。多个变量同时变化，事故后很难归因。高风险场景应尽量一次只变一个主要变量，或用 release bundle 精确记录组合。

第四，没有保留旧配置。回滚不是“把 prompt 改回去”这么简单，还可能涉及模型、参数、检索索引、工具版本和缓存。

第五，反馈闭环只修复被投诉样本。生产发布需要防止局部过拟合，反馈样本应进入分层评估集，而不是成为单条 prompt hack。

#5. 结论收束

AI 发布管理的核心判断是：凡是会影响模型输入、模型行为、工具结果、输出结构、成本延迟或安全边界的东西，都应该进入版本和发布流程。低风险场景可以轻量记录；核心流程必须使用 release bundle、离线评估、灰度、监控和回滚。

上线前检查清单：

• 场景边界：本次发布影响哪些用户、租户、功能入口和业务流程。
• 版本资产：prompt、模型、参数、schema、工具、检索、缓存和监控阈值是否有版本。
• 变更说明：变更原因、预期收益、风险、回滚方式和负责人是否清楚。
• 离线评估：典型样本、失败样本、高风险样本和长尾样本是否通过。
• 质量指标：引用正确率、schema 成功率、人工采纳率、事实错误率是否对比旧版。
• 成本延迟：输入 token、输出 token、TTFT、总耗时和 fallback 率是否在预算内。
• 灰度策略：是否按低风险流量逐步放量，并能按版本分组监控。
• 回滚路径：是否能恢复旧 release bundle，是否处理缓存、索引和工具兼容性。
• 人工确认：高风险输出、工具写入和对外承诺是否保留确认或审批。
• 反馈闭环：灰度反馈、事故样本和人工修改是否进入下一轮评估集。