模型评测到发布闸门的一生底层图谱

从评测目标、样本集、离线回放、Judge / 人工校准、风险切片、质量闸门、灰度实验、线上观测到回滚决策，理解 AI 模型怎样被允许进入生产

阶段	核心问题	证据	可能决策
Change Candidate	这次候选变更到底改变了什么	模型、Prompt、RAG 索引、工具 schema、护栏、路由规则的版本快照	进入评测 / 拆小变更 / 退回补说明
Eval Plan	用哪些样本、切片和阈值判断它能不能发	评测计划、风险分级、核心指标、阻断条件	批准测试 / 增加评测切片 / 要求人工验收
Offline Replay	在固定样本、历史坏例和红队集上是否退化	回放 trace、评分结果、差异样本、失败类型	通过 / 阻断 / 缩小灰度范围
Score Review	分数是否可信，Judge 和人工口径是否一致	Judge 输出、人工抽检、一致率、争议样本	接受分数 / 重跑 / 调整 rubric
Release Gate	质量、安全、成本、延迟、合规是否都过线	闸门报告、审批记录、回滚方案	灰度 / 阻断 / 降级能力 / 人工确认
Canary	真实流量里是否仍然更好	小流量指标、投诉、人工接管、成本和风险事件	放量 / 暂停 / 回滚 / 调整人群
Online Monitor	上线后是否持续稳定	请求级 trace、业务指标、SLO、异常告警	继续放量 / 熔断 / 触发复盘

计划项	要写清楚什么	常见错误
目标能力	这次变更想提升哪类任务，允许牺牲什么，不能牺牲什么	只写“整体质量提升”，没有具体任务和边界
影响资产	候选版本改了模型、Prompt、RAG、工具、护栏还是路由	同时改很多东西，评测失败时无法归因
样本范围	Golden Set、历史坏例、红队集、线上抽样、业务验收集分别覆盖什么	只看公开 benchmark 或少量成功案例
切片维度	按语言、场景、客户、人群、风险等级、长度、工具类型拆分	只看总分，掩盖高风险切片退化
阻断阈值	哪些指标低于阈值必须停止，哪些退化需要人工审批	结果出来后再临时解释“其实还可以”
回滚条件	灰度中出现哪些线上信号必须暂停或切回	没有提前定义，事故时各方争论是否回滚

样本来源	适合做什么	治理重点	继续下钻
历史线上请求	真实分布回放	脱敏、授权、采样偏差、trace 完整性	LLMOps / 可观测性
人工标注样本	业务口径定标和高风险验收	rubric、一致性、复核、争议样本	人类反馈 / 标注质量
坏例回流	防止事故复发	去重、归因、严重程度、修复状态	反馈闭环 / 数据飞轮
合成边界样本	补足长尾、攻击变体和格式扰动	抽检、来源标记、避免自循环污染	AI 数据工程

评分层	能给出什么证据	不能单独决定什么	复核方式
规则 / Schema	格式是否合法、字段是否齐全、工具参数是否可解析	答案是否真正有帮助	单测、解析器回放、结构化错误分桶
程序执行	代码、SQL、工具链路、工作流结果是否跑通	业务语气、风险边界、解释质量	测试用例覆盖、沙箱执行、结果断言
LLM-as-Judge	相关性、忠实度、风格、安全、偏好比较	绝对真理或监管责任	Judge 校准、顺序随机化、人工抽检
人工评审	复杂业务判断、高风险语境和真实责任边界	高频全量评分	一致性训练、双人复核、争议仲裁
线上指标	用户行为、投诉、接管、转化、留存和真实成本	根因归属	A/B、分人群切片、trace 回放

闸门结果	含义	动作
全绿	核心质量、安全、成本、延迟指标达标	进入灰度，不等于直接全量
局部黄	少数非关键切片轻微退化或证据不充分	缩小灰度范围，增加监控和人工抽检
关键红	高风险切片、核心任务或安全指标退化	阻断发布，回到误差分析
证据不足	样本覆盖、Judge 校准或 trace 不完整	补样本、补观测、重跑评测
收益不清	质量收益不足以覆盖成本、延迟或风险	推迟发布或只在特定人群启用

灰度阶段	看什么	停止条件	放量条件
影子流量	候选链路输出、成本、延迟和风险命中，不影响用户	关键质量或安全明显差于现网	候选结果稳定优于或不差于现网
内部灰度	真实使用反馈、明显坏例、人工验收	出现不可解释错误或高风险输出	内部任务完成率和体验达标
1% Canary	投诉、人工接管、拒答率、工具失败、P95、单位成本	超过预设阈值或出现严重风险事件	核心指标稳定一个观察窗口
分人群放量	客户类型、语言、行业、权限等级和任务类型切片	任一高价值切片明显退化	目标人群收益明确，风险可控
全量后监控	长期漂移、反馈分布、成本水位和新坏例	持续退化、攻击升级、供应商异常	进入常规运营和反馈闭环

差异问题	为什么重要	怎么做
赢在哪里	确认收益是否来自目标能力，而不是无关样本	按任务、场景、语言、用户类型和风险切片看胜负
输在哪里	避免总分提高掩盖关键切片退化	列出 top regression 样本，做人工复核和 trace 分析
为什么赢	判断收益来自模型能力、Prompt、RAG 还是路由	拆分链路实验，保持单变量变更
为什么输	决定修复方向和是否能灰度	按检索、上下文、工具、输出、护栏、后处理分桶
代价是什么	质量收益是否值得成本、延迟和风险增加	质量差异表和成本性能表一起审

模块	应该包含	用途
变更摘要	版本、资产、变更目的、影响范围、负责人	让所有人知道这次发的是什么
评测范围	样本集、切片、Judge / 人工比例、红队范围、线上回放窗口	说明证据覆盖了什么，也没覆盖什么
核心结果	质量、安全、成本、延迟、业务指标的前后对比	支撑发布或阻断决策
Regression 列表	退化样本、严重度、根因分桶、是否接受风险	防止平均分掩盖坏例
灰度计划	人群、流量、时间窗、监控指标、停止条件	把发布从一次动作变成可控实验
回滚方案	旧版本、切回步骤、数据/索引恢复、负责人、验证方式	保证出事时能恢复，而不是临场猜
后续动作	补样本、补护栏、补观测、进入反馈闭环的问题	让评测和发布积累成组织能力

闸门报告项	写入生产证据包	线上必须回填	回滚 / 复盘时回答
变更摘要	change_id、asset_versions、owner、risk_tier	release_version、enabled_features、affected_tenants	这次上线到底改变了哪些 AI 资产，影响哪些人群？
评测结果	eval_run_id、dataset_version、judge_version、slice_scores、known_regressions	online_slice_metrics、feedback_labels、new_failure_tags	线上退化是否落在已知风险切片，还是评测漏掉了新问题？
发布闸门	release_gate_id、gate_decision、approver、risk_exception、blocker_waiver	gate_violation_alerts、manual_review_events	当时为什么允许灰度或全量，是否有人批准了风险例外？
灰度计划	canary_cohort_id、traffic_percent、stop_condition、rollback_owner	cohort_metrics、complaints、incident_candidates	问题是否集中在某个灰度批次，是否触发过停止条件？
回滚方案	rollback_target、revert_steps、data_restore_plan、validation_cases	rollback_executed_at、recovery_metrics、fixed_version	恢复动作是否按预案执行，修复版是否通过原坏例验证？

例外节点	必须记录的字段	上线后必须盯什么
未通过项	failed_gate_id、failed_slice、metric_delta、severity、affected_users	风险集中在哪个能力、用户群、语言、成本或安全切片？
放行理由	waiver_id、business_reason、risk_acceptance_owner、expiry_time	这是临时业务取舍，还是被误当成永久通过？
缓解动作	mitigation_plan、guardrail_change、traffic_cap、manual_review_scope	上线时是否有足够的限流、护栏、人工复核和停止条件？
监控回填	online_metric_id、alert_threshold、feedback_tag、incident_playbook	线上是否专门盯住了这次例外风险，而不是只看总盘指标？
到期复审	review_date、required_fix_version、rollback_anchor、closure_evidence	例外有没有被关闭、修复、回滚或升级成正式策略？