模型上线最怕两件事：一是只看离线评测分数就直接切流量，二是出了问题以后没有明确回退路径。模型和普通代码版本不一样，它的变化可能来自权重、提示词、推理参数、工具链路或外部知识源，所以发布流程必须比普通应用更严格。
模型发布流程的重点，不是“发出去”，而是“发出去之后还能稳稳收回来”。 这意味着评测、审批、灰度、监控和回滚必须连成一条线，而不是分散在不同团队手里。
先把发布对象定义清楚
模型发布不是单一动作，通常包括几类变化：权重版本更新、推理引擎参数调整、Prompt 模板变更、工具调用策略修改、知识库索引更新。不同变化的风险不同，不能套用同一种流程。
比如权重更新会影响回答风格和知识边界，Prompt 更新会影响输出格式，推理参数更新会影响性能和稳定性。发布前先确认变更对象，后面才知道该做哪种评测、灰度和回滚。
评测阶段要先定门槛
离线评测不是为了证明模型“很强”，而是为了证明它“可以进下一步”。因此，评测门槛要结合业务场景来定：准确率、召回率、幻觉率、拒答率、格式稳定性、工具调用成功率，至少要选和业务最相关的几个。
如果模型涉及生成式输出，光看一个总分很危险。更好的方式是把评测拆成不同维度：知识正确性、格式符合度、安全性、时延和成本。这样才知道模型是“整体变好”还是“某一项变好了，另一项变差了”。
灰度不是简单按比例放量
很多团队把灰度理解成 10%、30%、100% 的流量切换，但对于模型来说，按比例放量只是最表层的控制。真正要看的是按什么用户、什么场景、什么请求类型放量。
更稳妥的做法是先挑低风险场景，例如内部测试、低优先级问答、单一意图流程，再逐步扩展到复杂请求和关键业务。灰度期间要观察回答质量、失败率、延迟变化和用户反馈，不能只看服务是否没报错。
回滚条件要提前写死
模型发布最怕现场拍脑袋。回滚条件最好在发布前就定好，比如：
- 幻觉率明显上升
- 工具调用失败率超阈值
- 用户投诉或人工介入增加
- 延迟超过约定区间
- 输出格式连续不稳定
只要触发条件成立，就应快速回滚到上一个稳定版本，而不是等问题扩大。回滚也不只是切换权重版本，有时还要一起回退 Prompt、索引或推理参数。
审批和审计不能缺位
模型发布的审批重点，不是走形式，而是把责任边界写清楚。谁确认评测通过，谁批准灰度，谁拥有紧急回滚权限，都要有记录。这样出了问题，团队知道该找谁，也知道该回看哪些证据。
审计至少要记录版本号、评测集、发布人、审批人、灰度范围、切流时间、监控指标和回滚动作。对生产环境来说，这些信息比“上线成功”四个字更重要。
监控要能区分模型问题和链路问题
模型发布后如果效果变差，不一定是模型本身的问题。也可能是检索服务慢了、工具接口挂了、推理资源紧了，或者上游 Prompt 变了。因此，监控必须把模型、网关、检索和资源层分开看。
如果只看总成功率，问题会被掩盖；如果能拆到模型版本、场景类型和调用路径，就能更快判断到底该回滚模型，还是修别的链路。
POC 建议按 5 个问题验证
在验证模型发布流程时，可以直接问 5 个问题：
- 是否能在发布前定义明确评测门槛
- 是否支持按用户或场景做灰度
- 是否能快速回滚到稳定版本
- 是否能记录完整审计链路
- 是否能区分模型问题和链路问题
如果这 5 个问题里有一项答不上来，说明流程还没闭环。
常见问题
模型发布和普通应用发布有什么不同？
普通应用主要看代码和配置，模型发布还要看权重、Prompt、检索、工具和推理参数。变化面更大，所以回滚和评测都要更细。
灰度阶段最该看什么？
最该看业务质量和失败模式，而不是只看有没有报错。比如回答是否稳定、工具是否正常、延迟是否可接受。
回滚只需要切回旧模型吗？
不一定。很多问题来自 Prompt、索引或参数配置，回滚时要把相关依赖一起纳入考虑。
下一步建议
如果团队准备上线新模型，最好先把评测集、灰度对象、回滚阈值和审批人固定下来。流程先定清楚，再谈模型效果，生产环境会稳很多。
原创声明：本文为 Alauda 原创技术内容，非商业转载须注明出处：https://www.alauda.cn/blog/1506/。
文中图示和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
