大模型应用发布流程应该怎么设计？

简化版

大模型应用发布对象不只是代码，还包括模型、Adapter、Prompt、Tokenizer、检索索引、工具 Schema、安全策略和推理配置。任何一项变化都要形成不可变版本清单，才能评测、灰度和整体回滚。

标准流程是：变更评审 → 离线质量/安全/性能门禁 → 兼容性检查 → 影子流量 → 小比例 Canary → 分阶段放量 → 观测窗口 → 全量。回滚依据不仅是 5xx，还包括任务成功率、事实性、安全违规、TTFT/TPOT、成本和人工接管率。

详细版

发布产物应有 Manifest：

release:
  app: app-v42
  model: model-v7
  prompt: prompt-v18
  index: kb-2026-09-18
  policy: safety-v12
  serving: engine-v9

门禁使用固定 Golden Set、红队集、性能回放和 Schema 契约；线上先做不影响用户的 Shadow，再按 1%→5%→20%→50%→100% 放量。每阶段必须有足够样本和自动停止条件，同时保留旧版本、兼容数据与一键路由回切。

完整版教学

1. 为什么 LLM 发布比普通代码复杂

回答行为由多个独立资产共同决定。代码不变但 Prompt 或索引更新，质量也会变化；模型升级还可能改变 Tokenizer、工具格式和成本。

因此发布单元应是完整组合，而非单一镜像标签。日志要记录组合版本，才能复现线上结果。

2. 用 Manifest 固化发布对象

Manifest 包含代码、模型权重、Adapter、Prompt、Tokenizer、索引、Embedding、重排、安全策略、工具和推理引擎版本。

每项使用不可变 ID 或内容哈希，禁止生产直接引用 latest。Manifest 经审批后不可覆盖，只能创建新版本。

3. 变更风险怎样分级

文案微调、模型切换、权限策略和写工具开放的风险不同。可按影响面、可逆性、数据敏感度和是否有外部副作用分级。

风险级别	示例	发布要求
低	非核心提示措辞	自动回归、小流量灰度
中	检索参数、量化	质量性能评测、Canary
高	新模型、安全策略	红队、审批、长观察
极高	新写工具	沙箱、人工确认、演练

风险越高，放量越慢，回滚与人工值守要求越严格。

4. 离线质量门禁包含什么

Golden Set 覆盖常见、困难、边界和历史失败样本，报告任务成功、事实性、引用、格式和拒答。不能只看单一平均分。

评测器也需版本化，并对关键样本人工抽检。新版本提升平均质量但严重回归关键场景时不得放行。

5. 安全与合规门禁

运行提示注入、越权检索、敏感信息、工具滥用和有害内容测试；检查数据驻留、许可证与模型卡限制。

安全指标通常是独立红线，不能用帮助性提升抵消。涉及高风险动作时，确认最小权限、幂等、审计和人工确认链路。

6. 性能与容量门禁

使用真实输入/输出长度和并发回放，比较 TTFT、TPOT、P99、吞吐、显存、冷启动和成本。新模型更大时还要验证故障余量。

性能测试固定硬件与配置，结果按长度桶报告。短 Prompt 的平均值不能代表长上下文线上容量。

7. 兼容性检查为什么必要

模型可能更换 Chat Template、Tokenizer 或工具调用格式；索引更新可能与 Embedding 维度不兼容；旧会话 KV 也不能跨模型复用。

producer schema -> compatibility test -> consumer parser
model/tokenizer -> cache namespace change
embedding model -> full index compatibility

不兼容变更应使用新命名空间和双写/重建，而非原地覆盖。

8. Shadow 流量解决什么

影子请求复制真实流量给候选版本，但结果不返回用户，可验证分布、性能和错误。写工具必须禁用或沙箱化，避免副作用执行两次。

Shadow 会增加成本和后端负载，应采样并脱敏。它能发现问题，但不能完全替代用户行为 A/B。

9. Canary 如何分阶段

先选内部或低风险租户，再按稳定哈希分配 1% 到候选，经过观察窗口后逐级扩大。会话型应用应保持同一会话版本一致。

每阶段设置最低样本数、最长观察时间和停止阈值。只按时间等待而样本不足，统计结论不可靠。

10. 发布期间监控什么

同时看基础设施错误、任务成功、质量代理、安全、TTFT/TPOT、Token、成本、Fallback 和人工接管。按版本分组，并与同期控制组比较。

全局指标会稀释小流量 Canary 问题；缺少 release_id 标签就无法准确归因。

11. 回滚为什么要按组合执行

模型回滚但保留新 Prompt 或新索引，可能仍不兼容。路由应能一键切回上一份完整 Manifest，并保留其权重、缓存命名空间和解析器。

数据迁移若不可逆，要提前设计双写、版本化读或补偿。回滚演练必须实际执行，而非只写文档。

12. 如何处理长会话

发布中途切换模型可能改变语气、工具格式和 KV 兼容性。使用 session 粘性让已开始会话留在旧版本，新会话进入新版本。

旧版本下线前设置最大排空期限；必须迁移时清除不兼容 KV，并向用户说明上下文可能重建。

13. 自动化与审批如何平衡

可重复的评测、Schema 检查、签名和灰度应自动化；风险接受、安全例外和高危工具仍需责任人审批。

流水线保存证据：输入资产哈希、评测结果、批准者、放量记录和回滚事件，满足审计与复盘。

审批结果必须机器可验证，例如带有效期的签名门票，并绑定准确的 Manifest 哈希；否则审批的是版本 A，实际流水线却可能发布版本 B。紧急通道也要限定权限、自动过期，并在事后补齐评测与复盘。

14. 发布后如何闭环

稳定观察一段时间后再关闭旧容量，线上失败样本经脱敏进入评测集。复盘哪些门禁未发现问题，并更新测试与阈值。

发布完成不等于指标不再看。流量分布漂移和缓存逐渐填充，可能在数小时或数天后才暴露退化。

可安全发布的前提，是你能准确说出线上运行的完整版本组合，并能把它整体切回。

15. 常见误区与追问

• 误区：模型文件上线就是发布完成。 Prompt、索引、策略和工具也属于产物。
• 误区：离线分数提升即可全量。 线上分布、性能和用户行为仍需灰度验证。
• 误区：Shadow 可以直接测试写工具。 必须禁用或沙箱，避免重复副作用。
• 误区：回滚只需要切回旧模型。 完整依赖组合都要兼容或一起回退。
• 误区：Canary 没报错就能扩量。 还需满足样本量、质量、安全和成本门槛。
• 追问：长会话如何处理？ 使用会话粘性与旧版本排空。
• 追问：何时自动回滚？ 明确错误、安全、质量或 SLO 超过阈值时。

16. 加强记忆

1. 先列资产：代码、模型、Prompt、索引、策略、工具、引擎。
2. 再固化 Manifest：不可变、可追溯、拒绝 latest。
3. 再过门禁：质量、安全、性能、兼容。
4. 再走流量：Shadow、Canary、逐级放量。
5. 再看多维指标：错误、质量、安全、延迟、成本。
6. 再保回退：旧组合、会话粘性、数据兼容。
7. 最后闭环：失败样本进入评测，发布证据可审计。