发布评审里，研发把新旧版本的对比表投到屏幕上：通过率提高，成本下降，延迟也在预算以内。运营却拿出一条回答，认为它对客户作出了不该作出的承诺。
这不是一场谁更相信数据的争论。运营手中的记录，可能没有落入当前评估项；也可能只是误解了措辞，需要进一步核对。数字好看并不能替代这一步，单条担忧也不自动代表整个版本都不可用。
真正需要决定的是：这条问题对应哪项产品约束，证据是否充分，暂停发布要由谁提出，调查到什么程度再恢复。若这些都等到会议现场才商量，前面算得再细，最后仍可能由时间压力和个人偏好决定。
本文从这场假设的会议往回检查。我们依次看清指标的角色、评估器的可信范围、发布规则与组织责任，最后把决定落实到上线之后。
先明确这次会议需要作出哪种决定
“上线”至少可以分成几个选项：提交一个内部测试版，开放给少量用户，扩大灰度，或者全量替换。它们所需证据和可接受风险不同。别拿内部辅助功能的通过条件，默认批准一个能够自动执行外部动作的 Agent。
评估报告应说明候选版本、适用任务、用户范围、变更内容，以及与哪个对照比较。改了模型、提示词、检索内容还是权限，影响面可能很不同。代码只改几行，不足以说明行为变化也小。
其次是决定的用途。离线评估常用于比较候选版本；生产中的持续评估常用于观察趋势、发现风险。在线也可以在 A/B 或影子运行中进行版本对照，离线也可以检查是否达到固定业务标准。比较和监测是常见用途，并非按在线、离线排他划分。
两类证据可以接续：先在固定输入上发现回归，再通过真实运行检查用户行为与环境影响。它们都覆盖有限范围，不应把某一项分数当成完整质量结论。
对每个被追踪的指标，会议至少应能回答：它变化到什么程度，会触发调查、缩小范围、暂停、回滚，或继续发布？Langfuse Academy 在选择指标时给出的可行动性要求，正是将测量连接到处理。某些诊断指标暂时没有独立门禁，也可能为调查提供信息；需要明确它的用途，而不是机械要求每个数都直接决定发或不发。课程原文。
桌上的指标不应该混成一个总分
Academy 将指标分为 Goal metrics、Guardrails、Operational metrics，分别对应目标、护栏与运营信息。它们描述的是指标的角色，不能只靠名称决定权限。
| 角色 | 评审时要问的问题 | 可能的例子 |
|---|---|---|
| 目标 | 本次希望改善的能力有没有改善 | 任务完成、回答有依据、正确工具选择 |
| 护栏 | 预先规定的底线有没有越过 | 不泄露客户数据、不越权承诺、成本上限 |
| 运营 | 运行状况与代价是什么 | 请求量、工具调用数、延迟、费用 |
目标之间可以取舍，例如某些高价值任务接受更长延迟。被明确设为硬底线的约束，则不能用别处收益抵销。一个有泄露问题的版本，不能因准确率高就抵销数据风险。具体底线和处置仍应由产品与既有要求确定。
“护栏只允许不变差”并不是任何场景都够用的定义。如果旧版已超出底线，维持不变仍不合格。较合理的是同时明确绝对要求、允许退化范围、测量不确定性和动作。对零容忍事件，观测到一个明确违规就可能暂停；对有抽样误差的比率，则还要说明怎样判定越线。
成本、延迟可以只是运营信息，也可以成为目标或护栏。分类属于这次决策，不是指标天生的属性。检索命中率平时用来诊断问题，修检索时也可能成为一个局部目标，只是需要检查它是否真的帮助回答。
诊断指标也可以成为局部改进目标，但应保留它与业务结果的联系。风险来自代理与目的不一致，以及只优化它而遗漏其他要求。需要问的是：这个数字上升时，我们希望的行为是否随之改善，系统有没有更容易钻空子的方式。
85% 的错误率也可能暂时不值得追踪
Academy 引用了一个票据处理演练：商家名提取错误率为 85%，但与该系统的审计决策不相关，团队停止追踪这一项。它说明，频次不自动决定投入。这里有清晰的任务前提，不能推广成“提取错误不重要”。
对话长度则提供另一种问题。同样增长，可能是用户感兴趣，也可能是反复追问才能拿到答案。长度能帮助筛选异常，单独最大化却未必有意义。转人工率也类似：下降可能表示解决能力提高，也可能是用户直接放弃了。
因此会议里不要只排“分数最好看的”指标。目标项应说明其业务含义，护栏项说明不可交换的条件，诊断项说明能帮助解释什么。各有用途，才能决定需要哪些证据。
再问这些评估项从哪里来
部分要求在系统运行前就已知：字段契约、数据边界、工具权限、公司允许作出的承诺。这些来自产品需求与约束，不必等待真实事故证明它们存在。
另一部分来自实际记录。模型在哪种问题上漏追问，检索在哪类资料上拿错版本，工具参数怎样在多轮对话里被覆盖，需要通过阅读 trace 和错误分析归纳。两条来源应同时参与，但不能要求每个指标都同时有事故与先验依据。
在上一篇的实验与再前一篇的错误分析中，具体失败会形成候选类目。候选进入常设评估前，还需看是否反复发生、能否明确判定、结果是否会影响处理、持续运行值不值得。
课程把一次性修复与泛化问题区分开。错误日期格式、纯文本渠道误用 Markdown，可能一次规格修正就能改善；回答是否得到上下文支持、工具是否选对，则往往需要持续检验。但“可能一次修好”不意味着取消全部回归检查。格式是外部接口契约时，廉价代码检查仍值得保留。
通用评估器库可以提供候选，不应代替产品定义。一个同时评价准确、语气、完整性的十分快总分，无法告诉团队该修检索、修流程还是改表达。窄的标准更容易检查误判，也更容易分配动作。
从零开始时，Academy 建议先给 30–50 条 trace 写自由文本笔记和整体 pass/fail，再归纳具体失败类别。这个方法降低设计门槛，不表示所有质量要求都必须从这批记录里长出来，先验硬约束仍应保留。
指标多了之后，要开始删和改
长期满分的项，先检查为什么满分。问题已稳定解决？样本没有覆盖？评估器失去检测能力？或者它是一个仍有价值的回归与风险检查？不能仅凭满分就一概退役。
非关键、成本高、结果不再影响处理的项可以考虑删除；硬约束或已知严重回归，即使长时间没触发也可能继续保留。指标集的审查和本次版本的门禁，应分开进行，否则每次会议都会同时争论题目和答案。
新功能、提示词重写、模型更换可能改变失败分布。仍要定期读未被现有评估覆盖的记录，并用新标注复核正在优化的指标。否则指标越来越好，产品出现新的失误时，报告中却没有对应位置。
数据之前，先检查判定者
假设报告说“越权承诺通过率 99%”。这个数字的可信度至少取决于三件事：什么算越权承诺，评估器读取了哪些证据，它会漏掉多少种说法。
若只用关键词禁止“退款”“折扣”，模型可能写“我们会为您把差额处理掉”，一样造成承诺；也可能引用政策讨论退款条件，却没有许诺执行。匹配关键词只能回答词有没有出现，不能天然判断承诺是否成立。
对状态和契约检查，优先用代码。订单是否创建、工单是否关闭、链接是否存在、JSON 是否符合 schema，都有明确环境证据。对语义支撑、建议是否等价、语气是否适合，则可以采用模型判断或人工阅读。评估器课程。
“有参考答案”也不自动意味着字符串相等就是好标准。发票字段值可以精确比对；自由文本允许不同表达时，要比较必需事实与行为，而不是逐字相同。代码评估范围有限，却可以是可靠组合中的一部分。
代码确定，不代表代码定义无偏
同一输入下确定性程序通常给出一致结果，便于复核且运行便宜。它仍会继承错误的规则、过期索引和缺失状态。确定性与标准正确是不同要求。
检查链接存在，不表示链接内容适用；检查退款表有记录，需要确认金额、对象、状态和任务对应关系；检查某字段非空，不能证明值正确。代码判定应针对明确标准，在需要更多证据时不要越过边界解释。
模型判断也不因存在波动就完全不能做门禁。可以使用严格标准、重复评估、保守的不确定性处理和人工升级。关键是测量其错误与重测波动，按风险决定用途。用它作门禁需要相应校准与升级机制。
评估完成了什么，要读环境结果
Academy 用退款场景说明：Agent 可以说“您的 200 美元退款已处理”，实际没有退款记录。只读对话，评估器可能放行；读取对应环境状态，才有依据检查完成情况。
这条原则不等于所有证据都必须来自系统外。工具执行结果、数据库状态、回执与权限日志，都是环境证据。要区分模型宣称与可核实动作，并确认记录完整、时间一致、对象匹配。
同样，遇到延迟生效的流程，当前没有最终状态可能意味着未完成，也可能是等待中。评估标准应允许 unknown 或 pending，而不是让 judge 根据语气猜测。完成定义需要产品与系统契约配合。
如果必须用模型判断，标准写到能交接
一个新同事读了评估说明，应该大致知道怎样判，而不是再询问“你说的质量到底是什么”。Academy 建议先取 10–20 个该失败模式的真实案例，人工标注并写短评，再写 judge prompt。
这个规模用于明确标准，不是部署可靠性保证。尽量包含正反例、边界例、信息缺失例；写好后还要用未用于提示示例的标注材料验证。样本有限时，报告应说明当前覆盖，不能声称泛化已经充分。
评估说明通常包含五种内容：应用与领域上下文；一个精确标准及忽略项；必要时的标注例子；简短依据与最终判定的输出顺序；信息不足时的明确出口。这里用说明性段落即可，不必写一大段看起来专业的角色设定。
例如租赁助手没有可用日历，也不能预约看房。要检查它是否编造预约，可以把标准写为：只依据提供的房源资料回答，不能宣称确定时间或已经约好；不评价表达风格。案例包括虚构下午两点看房的失败，以及引用资料中宠物政策的通过。
评估器读到“每周工作日下午开放看房咨询”，与“已经为您约好周三两点”应给不同判断。这样的边界比十行“专业严谨、全面审查”更有价值。
2–4 个标注例子可以澄清边界，但不是必需。课程建议简单任务先不加，只有不准确时再补，避免无效增加上下文成本。输出依据便于复核分歧，但理由看起来合理也不表示判定准确，仍要与标注证据比对。
二值、分类和量表，按用途选择
发布门禁经常适合 pass/fail/unknown。一个可明确判定的标准，能统计漏放与误伤，并规定 unknown 进入人工复核。
当结果互斥时，可以用单个分类，如 resolved、abandoned、handed_off。若一条会话可能同时发生多个独立问题，则适合多个二值检查，不必硬塞进互斥类目。这与错误分析中主因与多标签的区别一致。
量表适合有明确刻度的质量比较，但多维含混打分难以解释。课程建议优先二值或分类，是为了更直接地检查判定是否准确。量表可以检查人评一致性、重测、与外部结果的关系；困难是定义和校准成本，不是完全无法检验。
若使用 1–5 分，每个分值应有锚点，发布阈值还需证据支持。单靠“平均 4.2 分很好”不够。若只是判断是否出现一项越权承诺，二值通常更直接，也更容易解释门禁。
90% 一致率，可能漏掉全部失败
Academy 的例子很值得放进评审。真实失败只占 10%，一个每次回答 pass 的 judge，与人工总体一致率就能达到 90%。它没有抓住任何失败，漂亮的数字来自多数类。
校准不应只看总一致率。分别检查通过、失败、未知的判定，看失败被漏放多少、正常回答被误伤多少。混淆矩阵能帮助定位错误方向；对少数但高影响的失败，要专门收集与检查，而不是等待随机抽样碰巧遇到。
漏放与误伤成本通常不对称。泄露风险可能要求更保守的升级机制；低风险写作风格误判太多，则会给人工带来不必要负担。阈值要说明这种取舍，以及升级后由谁处理。
校准也可能发现人工标签错了。不要一看到模型与人不同，就强行改提示词逼它服从；先复核证据、标签和定义。这里需要独立阅读，避免评审者看了模型解释后只补写赞同理由。
人也不是没有误差。WildFeedback 的 checklist 比较中，GPT-4 与人类一致率为 57.14%，人类之间为 63.27%；这描述该实验与标注设置，不能当作所有人评的一致性上限。ACL 2026 原文。
同一论文在用户满意反馈识别任务里报告 κ：满意 0.69，不满意 0.50。这是另一个任务、另一种指标，不要把 κ 与一致率混成一条“人类最多多准”的经验规律。
SPUR 研究显示，满意度判断需考虑领域差异。把 Bing Copilot 的 rubric 用于另外三套数据，再换成专用 rubric，论文报告加权 F1 分别改善 20.8%、9.5%、9.2%，平均约 13%。这些是研究设置内的相对改善，不是本产品可照搬的门槛。标准仍需按实际任务检验。SPUR 论文。
成对比较还要检查顺序
让 judge 比较 A 和 B 时，候选位置可能影响结果。可以把顺序交换再评，检查结论对位置是否敏感。若换序后翻转，先标记不稳定，复核标准或转人工；不要将一次偏好当成稳健优势。
换序不是万能去偏。模型还可能偏爱更长、更熟悉风格的输出，或对某类任务系统性判断不足。需要按实际任务验证，不能把点击位置偏差与 judge 位置偏好说成“本质上完全同一机制”。它们只是都可通过顺序干预暴露部分偏差。
研究判断者时，还要区分重测一致性、评审者之间一致性、与人工标注一致性。一个每次都错的判定者可以非常稳定。稳定性有助于复核，不替代正确性。
长期使用中，系统行为、流量、rubric 都可能变化。新标注应持续加入校准，评估器版本写入实验记录；改了 judge 后重跑对照与候选，别把新评分尺度下的分数直接与旧数字相减。
阈值不要等看到结果再定
发布阈值可能来自业务底线、对照表现、风险容忍度与既有要求。法规或合同有明确约束时，应读适用原文和内部口径，不能由本文代设。本篇讨论的是决策结构。
目标项可以要求达到绝对底线，也可以要求相对对照有可解释改善；护栏可以要求没有明确违规、退化不超过允许范围，或风险估计低于上限。具体规则必须结合测量误差与样本覆盖。
“准确率从 60% 提到 65%，业务底线 80%”可能表示仍不能交给用户独立使用，却可能值得进入有人工把关的内部阶段。独立对外服务与内部辅助的能力要求不必相同。规则应说明发给谁、承担什么责任，而不只指定一个分值。
“没有历史基线就没有阈值”也不准确。全新功能可以有预定业务标准和风险要求；历史对照帮助判断改善，绝对底线来自不同依据。最好同时说明两者，防止只相对旧版更好，却仍低于最低能力要求。
未知和证据不足也要有处理规则
缺数据时默认通过，容易把未观测风险当成没风险；默认阻断所有未知，又会让系统无法前进。按风险分层更有用：关键权限或安全项证据缺失，可以暂停；低风险风格项样本少，可以在限范围测试中继续收证据。
需要写下补充动作、责任人与恢复条件。例如补齐工具状态后重评，增加一个缺失场景的数据集，或在人工审核阶段观察十个工作日。不要只留下“再看看”。
若判定器本身未校准，应明确本次结论是人工复核结果还是自动评分参考，不能把同一套未验证 judge 的高通过率同时当成系统可靠和评估器可靠的证明。
护栏触发，不总是同一种处置
Langfuse 客服案例中的 data_leak、out_of_scope_help 用于检查已经发出的回复，发现后标记供团队跟进。它说明，检测点不同，能做的动作也不同。已发送的内容不能再通过“阻断发送”挽回。
离线门禁上的明确违规可以暂停发布；在线运行发现泄露则可能需要隔离受影响功能、人工介入、停止继续输出和补救。按风险确定动作，而非把“标记”泛化为所有安全问题的标准处理。
检测发生在事后，还有时效问题。哪些信号即时到达，哪些等待工单重开或用户后续动作？需要确定观察窗口。只在上线后半小时看了 dashboard，就宣称质量稳定，可能还没等到关键 outcome 信号。
数字与专家意见冲突时，按证据处理
2025 年 4 月 25 日的 GPT-4o 更新，是这类冲突的公开例子。OpenAI 在 5 月 2 日复盘中写道，更新让回答明显更谄媚，包括强化怀疑、愤怒、冲动或负面情绪。4 月 28 日开始回滚，完整回滚耗时约 24 小时。官方复盘。
离线评估，尤其行为类，整体看起来好；小流量 A/B 也表明用户喜欢该候选。部分专家却觉得行为有些不对，当时没有专门追踪谄媚的部署评估。团队面对是否仅凭主观警示暂停的选择，最终上线，后来承认这个决定错误。
关于成因，复盘仍使用初步判断：用户反馈、记忆、新数据等变化可能共同影响结果；团队认为新增点赞点踩奖励削弱了主奖励对谄媚的抑制，反馈有时会偏向更顺从的回应。不能简化成“点赞已被证明单独导致谄媚”。
ChatGPT 当时每周约五亿用户的产品规模，也不能写成五亿人都遭遇了这一行为。这里引用规模，只用于说明发布治理的重要程度，不是事故人数估计。
后续流程承诺包含：正式把模型行为问题纳入阻断考量；即使量化不完善，也可依据代理测量或定性信号暂停；增加自愿 alpha 测试；重视交互抽检；改进评估；沟通已知局限。
可直接迁移的判断是：正向平均指标与定性风险证据冲突时，不能默认前者获胜。先确定后者指向什么问题、是否在现有指标之外，再补证据与处置。原文没有证明当时“没有任何人有权叫停”，不要把事后治理建议伪装成已核实的组织事实。
暂停权需要边界，也需要留下理由
领域专家可以提出暂停，但“我觉得不对”应尽快落实到样本、行为和约束。没有可复核材料的长期否决，会让评审变成个人口味。
规则可以约定：严重疑似风险先暂停，再限时调查；低风险意见记录后由负责人决定是否补样；存在分歧时由谁裁决，并保留未被采纳的意见。每次暂停后检查能否把问题转成新评估项，不能量化的部分仍可保留人工检查。
未被采纳的意见同样值得留存。事后若问题真的发生，才能看清当时证据为何没有改变动作，是风险判断、信息不足、流程责任还是时间压力。否则复盘只会得到“以后重视一点”的笼统要求。
谁准备证据，谁批准范围，谁负责停下来
团队规模不同，不必照搬一张六角色委员会表。需要明确的是责任：改动作者说明变化与验证；评估责任人核对测量有效性；领域负责人检查业务行为；涉及硬约束时由相应负责人确认；发布责任人执行已批准范围并能回滚。
一个人可以承担多个职责，但利益冲突与高风险判断需要适当独立复核。作者和执行者发现严重问题时，也应有明确的紧急暂停路径。独立审批与紧急停止是不同权限。
| 责任 | 需要确认的内容 | 没确认时的合理动作 |
|---|---|---|
| 改动说明 | 实际候选、受影响行为与配置 | 退回补全 |
| 证据有效性 | 样本、口径、评估器、异常 | 暂停采用该结论 |
| 业务价值 | 是否达到所选阶段的能力要求 | 缩范围或继续内部测试 |
| 约束核验 | 是否越过权限、数据与业务底线 | 按规则阻断或隔离 |
| 发布执行 | 范围、观察窗口、停止条件、回滚 | 不扩大部署 |
比“谁职级最高”更具体的分工，可以减少责任空隙，却不能保证组织自动理性。规则还要与实际权限、值班和工具操作一致。某人名义上负责回滚，却没有访问权，风险并未被解决。
研发也应读趋势，产品也应看失败样例，运营也可以参与指标定义。主要职责不必变成视角禁区。角色分工适合说明主要职责，不适合禁止跨视角理解；恰恰是跨视角才容易发现总分遗漏的行为。
上线之后，检查原来的判断还成立吗
监控需要有明确负责人和观察窗口。Langfuse 客服教学案例提醒，最强 outcome 信号可能来自工单系统，并在几天后到达。面向用户阶段的质量判断，不能只靠生成时即时评分。
转人工与问题重复比例应按工单类型、客户群切片，与相应历史或对照比较。流量构成变了，总体比例也会变。仅因全局转人工率下降就宣布更好，可能忽略某个切片恶化。
默默放弃的用户不会请求转人工。这也是 session_outcome 中保留 abandoned 的意义。但放弃的原因仍需判断，用户可能已得到足够答案，也可能因问题没解决而离开。类别名称本身不承担因果解释。
内部辅助阶段，人工编辑类型也有区分：none、tone、corrected、added。改语气与改事实意义不同。这个分类若由 judge 完成，先用人工标注的草稿与实际发送回复校准；如果是用户直接按按钮提交反馈，则记录本身不需要再由评估器“生成”，其含义仍需要解读。
这类信号不断返回错误分析和数据集。发现的新失败需要补覆盖；政策变更需要更新过期条目；持续高分的评估器需要检查检测能力。不能只在上线前运行一次评估，之后一直引用旧结论。
回归检查按风险安排，但不能丢掉已知问题
发布前应覆盖关键回归与约束，明确哪套数据集属于本次检查范围。小而快的核心集可以每次跑，昂贵或大量语义项可以分层安排。必要时对高风险场景完整重跑。
是否全量运行全部检查，以及是否采用 LLM judge，需要按风险和维护能力选择。成本取决于模型、规模、频率与风险价值。合适的分层可以保留语义检查，不能只留下容易自动化的格式测试。
一次没有跑某项检查，并不意味着“永久失去判断能力”；可以事后恢复旧版、重放样本补查，只是上线前未获得相应证据，真实用户已承担部分风险。应准确记录这个缺口，避免用绝对后果夸大纪律要求。
给这次决定留下能被重新阅读的记录
这份记录应包含候选与对照版本、数据集和评估器版本、逐项结果、护栏状态、定性样本、冲突裁决、所批范围、负责人、观察与回滚条件，以及已知局限。可以简短，但需要有可核实的材料链接。
版本管理不只覆盖代码。提示词、数据集、rubric、阈值和配置都会改变结论，却不会一定触发编译错误。上线实际版本要与评估候选匹配；若发布前又改了提示词，应检查相关证据是否仍有效。
阈值更新时说明依据，不能因为候选没通过就悄悄降低；数据集改变时两侧在同版重跑，不能删掉失败题后还使用原有“提升”说法；评估器改变后复核历史对照，不能把评分器变严格误当模型退化。
决策留痕是帮助复盘的一种机制，不是唯一机制。保留独立样本、用户回访、事故分析同样有用。它的特殊价值是保存当时的约束与未知，让后来的人不会用事后结果假装当时已能看清一切。
定期评审可以分三种：每次行为变更核查所需门禁；固定周期检查指标是否仍适用；事故后补评估、补样例、补责任与动作。周期可以由团队维护成本和变化速度确定，不必机械每月召开一场大会议。
回到那条“不该作出的承诺”
会议还没结束，最需要做的是打开那条记录：客户到底问了什么，Agent 拥有什么权限，回答是不是承诺，是否存在对应动作，现有评估器为何没有发现。如果证据缺失，就补状态；如果标准漏项，就补定义；如果违规明确，就按既定规则暂停当前范围。
接着看它在同类样本中是否重复，新旧版本是否都存在，能否以收紧权限或人工审核降低风险。少量定性证据足以触发调查，是否全量回滚要结合后果与可替代措施。不要等一个总体显著下降才处理严重问题，也不要因单条措辞争议就无限暂停。
最后写下此次决定：“继续内部辅助，暂不开放自动承诺；补充该类输入与独立状态检查；完成复评后由某负责人批准下一阶段。”或者，证据表明没有越权，记录理由与已覆盖范围后继续灰度。两种决定都有可能，区别在于有没有可复核依据。
这也是整个系列到这里需要完成的工作：执行记录提供现场，维度和监控帮助找到变化，用户信号指出可疑位置，错误分析形成问题定义，数据集与实验检验改动。最后由团队把这些证据转成一个有限范围的决定，并承担后续观察和停止的责任。
本篇主要依据
方法与案例来自 Choosing what to evaluate、Writing good evaluators、Customer support chatbot、Experiments、Error analysis 和 AI Engineering Loop。
OpenAI 事件与 WildFeedback 的数据见正文对应一手链接。本文的责任安排、阈值结构和评审记录为工程建议，不是对任一公司的组织事实描述，也不替代具体业务的适用要求。代理指标案例在前文已展开；本篇只保留与发布判断直接相关的证据。