模型质量评估在离线样本上顺利获得，模型进入真实链路后仍可能因为超时、输出截断、上下文变化、依赖失败或版本漂移而不可用。离线评测回答“在受控输入下能否完成任务”，生产门槛还要回答“面对真实请求和异常时能否持续交付可接受结果”。两组证据没有打通，评测高分就无法直接转成上线放行。

核心口径：将任务结果、运行完整性和业务风险分开观察，再顺利获得同一请求与版本关系把它们连接起来。

先把“答得好”拆成三个可观察问题

第一层是任务结果。输出是否完成目标、关键字段是否存在、依据是否充足、格式是否可被下游处理，都属于质量判断。它适合顺利获得固定任务集、规则检查和人工复核建立离线基线。

第二层是运行完整性。请求是否完整到达、流式输出是否中断、超时后是否重复调用、依赖失败时是否降级、响应是否被网关或后处理截断，会直接改变用户收到的结果。模型本身可能生成正确内容，链路却只交付了一部分。

第三层是业务风险。同样的错误在不同场景中后果不同。一般文案措辞偏差或许可人工修订，审批建议遗漏关键条件则可能阻断上线。风险判断必须由业务和责任团队定义，不能交给一个通用分数自动决定。

三层之间不能互相替代。服务没有报错，不代表答案可用；离线答案正确，也不代表真实链路稳定；平均质量较高，更不能冲抵少量严重风险。生产门槛需要为三层分别设置证据和处理动作。

离线基线负责稳定比较，不负责模拟全部生产

离线评测应固定模型版本、数据集、提示、参数、评分规则和执行环境，让团队能够比较一次变更前后的差异。它特别适合发现明显回归、验证格式和规则、积累已知失败样本，以及在上线前筛掉不合格版本。

但离线任务通常无法覆盖真实输入分布。生产请求可能更长、更嘈杂，包含历史上下文、权限差异和外部依赖；流量也会在时间、部门和场景之间变化。若测试集长期不更新，它会越来越擅长验证过去，却看不到新的失败。

企业可以参考 大模型评测落地方法 组织任务集、自动指标与人工复核。进入生产准入时，还要给每条评测结果加上适用范围：覆盖哪些任务、哪些语言、哪些输入边界，哪些依赖没有进入测试。

离线门槛应同时保留硬阻断和趋势观察。关键字段缺失、权限越界或不可接受的事实错误可以作为阻断；表达质量、长尾样本和轻微波动可进入人工复核。具体阈值应依据业务风险和历史基线确定，不存在脱离场景的统一数字。

生产门槛需要两组同时创建的证据

一组证据来自离线效果，另一组来自运行表现。它们顺利获得模型版本、提示或配置版本、请求标识和发布时间关联，才能判断问题发生在哪个阶段。若运行监控只显示服务名称，而评测只记录模型名称，双方可能根本没有观察同一个对象。

运行验证至少要覆盖正常完成、超时、拒绝、截断、重试、依赖失败和降级。流式场景还应观察用户取消、连接中断和部分输出的处理。涉及检索或工具时，模型结果、依赖结果和最终业务响应应能够区分，避免把所有失败都记到模型头上。

这并不要求上线前模拟全部生产。更实际的做法是根据风险选择影子、回放、小流量或受控用户验证。对有副作用的工具调用，不能直接复制真实请求执行；应使用隔离环境、只读动作或人工确认点。数据权限也必须在验证方式确定前完成检查。

生产验证的重点不是证明永不失败，而是确认失败可见、影响可控、责任可接。 如果异常发生后无法定位版本、无法限制流量或无法切回稳定方案，即使平均质量满足要求，也不宜扩大范围。

质量信号要和运行事件使用同一条时间线

生产中的质量反馈可能来自用户评价、业务抽检、规则拦截、人工复核或故障工单。每条信号都应尽量关联请求、应用、模型版本、提示版本和依赖状态。只统计“差评数量”而无法回到当时条件，就很难判断是模型变化、数据变化还是链路故障。

时间线还要包含发布事件。模型、提示、知识库、检索配置、安全策略和网关路由都可能改变结果。发布记录若与质量监控分离，团队只能凭经验猜测哪次变化造成波动。关联并不意味着所有对象由一套系统管理，但它们必须共享可解析的版本和时间关系。

反馈本身也需要治理。用户评价可能受界面、响应速度和期望差异影响；人工抽检可能存在评分偏差；规则拦截只能发现预先定义的问题。分析时应区分信号来源、样本范围和置信边界，不把单一反馈渠道当成质量真相。

对于敏感输入，不应默认保存完整提示和响应。可以使用受控抽样、脱敏内容、风险标签和授权回查机制，在可诊断与数据最小化之间取得平衡。证据不足时应标记未知，而不是用更多无边界日志弥补。

灰度阶段要预先定义暂停、回滚和复测

灰度不是把流量比例逐步调大这么简单。每个阶段都需要明确观察窗口、质量信号、运行信号和停止条件。若出现高风险错误、异常无法关联版本、回滚链路失效或依赖产生副作用，应暂停扩围，并保留现场证据。

发布和回滚关系可参考 模型发布流程 的评测、灰度与回退思路。质量门槛应把离线报告、灰度观察和回滚对象绑定到同一版本，避免回退时只切换模型，却遗漏提示、知识库或网关策略。

暂停后先判断问题类别。离线未覆盖的质量错误要补入任务集；运行中断要检查服务和依赖；配置漂移要恢复版本一致性；业务规则变化则需重新确认判定标准。不同原因对应不同修复路线，不能统一用“再跑一次评测”结束。

例外放行必须限定范围、期限和责任人。例如某个低风险部门可以在人工复核下继续使用，但这不代表模型已经满足全量生产条件。例外到期后应重新评估，避免临时措施变成无记录的长期状态。

用三类结论替代一个上线分数

第一类是可放行：离线效果满足已定义门槛，运行演练覆盖关键异常，监控与回滚链路可用，责任人确认适用范围。结论必须附带版本和条件。

第二类是条件放行：核心任务可用，但某些边界需要限制流量、人工复核或关闭特定能力。限制应能由配置和权限实施，并设置复测条件。仅在文档中写“谨慎使用”无法形成有效控制。

第三类是退回补测：关键错误未解释、版本关系不清、异常证据缺失或回滚不可用。补测要指向具体缺口，不能用增加更多正常样本替代故障和风险验证。

这三类结论比综合分更适合跨团队协作。业务团队看到适用任务，安全团队看到阻断风险，运维团队看到运行与回退要求，发布负责人据此做出有条件的决策。

下一步如何建立第一版门槛

选择一个已有离线评测集的模型版本，补充三类运行场景：正常、可恢复异常和必须停止的高风险异常。为请求、模型、提示与发布事件建立关联，在受控流量中观察输出完整性和反馈。最后让业务、安全、平台和运维共同签认可放行、条件放行或补测，不用一个平均分替代四方责任。

常见问题

运行表现是否应该纳入模型质量评估？

应该纳入生产准入，但不必把所有运行问题都归因于模型。用户最终收到的结果受模型服务、网关、检索、工具、网络和后处理共同影响，任何一层中断都可能破坏任务完成。生产质量关注的是端到端结果，因此必须观察运行表现；故障定位时则要保留分层证据，明确责任位置。

更合适的做法是同时维护模型质量和交付质量两组指标。前者关注任务、事实、格式和风险，后者关注完整响应、超时、截断、重试和依赖状态。两组顺利获得请求与版本关联，既能避免模型替所有链路背锅，也不会用“服务正常”掩盖输出不可用。

影子流量能替代正式灰度吗？

不能完全替代。影子或回放可以在不影响用户的情况下观察真实输入分布和模型结果，适合发现离线样本没有覆盖的问题。但它通常无法真实反映用户交互、后续业务动作、权限变化和有副作用工具调用，也可能因为脱敏或重放方式改变上下文。

影子结果适合作为灰度前证据，正式灰度仍需在受控用户、可回退入口和明确停止条件下进行。涉及写操作时，应避免影子请求重复执行，可使用隔离目标、只读验证或人工确认。两种方式都要遵守数据授权，不能为了真实性绕过安全边界。灰度结束后还要核对用户实际收到的结果，不能只比较服务端生成内容。判断是否进入灰度，可看用户反馈、权限路径和副作用是否只能在真实交互中观察；这些证据缺失时，影子顺利获得只能缩小补测范围。

质量门槛多久需要重新评审？

不应只按固定日历判断。模型或服务版本变化、提示和知识库调整、业务流程变化、输入分布明显漂移、出现新的严重错误，都会触发重新评审。即使没有大版本发布，长期趋势也可能显示原有样本和阈值已不再代表真实场景。

团队可以设置周期复盘作为底线，同时建立事件触发机制。每次门槛调整都应记录原因、影响范围、生效版本和批准人，保留旧规则对应的历史结论。这样既能持续改进，也不会用新标准无痕改写过去的放行证据。复盘时应抽取已放行版本重新执行关键样本，确认规则与运行控制仍然一致。还可建立变更触发清单，抽查最近一次提示、知识或路由更新是否命中复评；漏触发比日历频率偏低更值得优先修复。