假设一个客服 AI 的周报同时出现了三条好消息：满意度上升，转人工率下降，单次回复更便宜。团队准备把这些变化写进版本总结。
把报表往下翻，却发现本周的使用人数少了，评分按钮换了位置，复杂工单占比也降了。某类客户连续重试之后离开，没有请求人工，因而没有进入转人工率的分子。
这不是某家公司的真实事故，而是一个用于讨论监控的假设场景。它把产品经理经常需要处理的判断放在一起：数值变化已经发生，解释却还没有成立。眼下需要的不是再画一张图，而是查清楚数字由哪些请求、哪些用户、哪些采集规则产生。
先查分母，再讨论改善
满意度从什么样本里算出来，决定了它能说明什么。只统计打分的人，得到的是“反馈者的满意度”；以所有请求为分母，统计点赞次数，得到的是“请求收到点赞的比例”。两者都可以观察，但不能互相换名字。
未评分的请求也没有自动变成满意。它们可能来自顺利完成任务的人，也可能来自没看到按钮、赶时间、懒得评价，或者已经失望离开的人。把这一部分统一填成中性，看起来补全了报表，实际上补进去的是团队的假设。
比率指标至少要交代四件事：分子是什么事件，分母包含哪些对象，观察窗口多长，哪些样本被排除。转人工率的分母是会话还是独立用户？重开率观察三天还是七天？一次会话多次点踩按一次还是多次算？这些定义变化，会直接改变曲线。
一个指标在两个面板上不同，未必是计算错误。可能一个按请求算，一个按会话算；一个含未完成会话，一个只含已结束会话。在业务评审里先把口径写出来，往往比追问“哪个数字准确”更有用。算法、筛选条件、时间窗和分母都应与指标一起保存。
口径也不必永远冻结。产品增加新流程，原来的统计边界可能确实需要调整。但新旧算法应分开记录，标注变更时间；如果要继续比较，尽量回算共同区间。不能只保留一个叫“成功率”的名称，就假定两条线仍然可比。
流量结构是下一项要查的内容。复杂问题少了，即使每个类别的处理能力都没改善，总体转人工率也可能下降。不同客户群的表达习惯和容忍度不同，新客占比变化也会影响评分。总体值适合提示变化，分类后的值才更接近定位问题。
Langfuse Academy 的客服示例专门提醒：转人工率与重复提问率随工单类别、客户群而异，应把某个类别与自身历史比较。产品经理可以据此保留总体趋势，同时拆看业务必要的切片，避免只读一个汇总率。
这里的“拆看”也有成本。类别、语言、版本、渠道全部交叉后，有些组合一周只有几条请求，比率会大幅跳动。不是维度越多，分析越细。应先选影响决策的维度，为小样本显示计数与不确定性，必要时合并观察窗口，而不是把每个波动都叫异常。
哪些用户进入了这张表
分母清楚以后，还需要检查采集机制。打分按钮面向所有用户，并不意味着打分的人就是全体用户的随机样本。
Marlin 等人在 Yahoo! Music 场景的研究中，64.85% 的受访用户表示，对歌曲的喜好影响自己是否打分。针对喜欢的歌曲，选择“非常经常”评分的比例为 93.91%；针对中性感受的歌曲，这个比例为 36.50%。这是特定音乐推荐调查的结果，不是所有 AI 产品的反馈率，但它说明了自然评分为什么可能有选择偏差。[1]
统计上需要区分随机缺失（MAR）与非随机缺失（MNAR）。MAR 并不简单等于“所有人等概率留下反馈”，而是给定已观测信息后，缺失机制不再依赖缺失值。如果未记录的满意程度本身仍影响是否反馈，就不能轻易假设 MAR 成立。
对产品工作来说，先做一个较朴素的检查：反馈是否更容易来自某些任务、某些渠道、某些强烈感受？这些差异有没有被记录？没有证据时，不用自然反馈推断全体质量，也不从“没反馈”反推满意程度。
这类偏差会进入两个环节。训练时，模型更容易学习发声者的偏好；评测时，如果测试数据也来自同样的自选反馈，团队可能在一个偏斜的分布上得到很好的结果。问题不只在于算法，而在于团队用什么样本来判定算法有效。
上述音乐推荐论文还比较了显式建模缺失机制的 MM/CPT-v 与未建模的 MM/None。最佳平均测试误差从 1.2126 降到 0.7148，相对降低超过 40%。模型中缺失机制参数利用 400 名留出调查用户的评分估计。[1]
这个数字不能解释成“把沉默当中性就造成 40% 的误差”，也不能直接移植成 AI 应用的预期收益。研究比较的是特定模型与数据条件。可以迁移的是评测设计：自然反馈用来提供线索，同时从目标流量独立抽样，按统一标准审阅，检查自然反馈有没有漏掉一类体验。
随机抽样也有前提。样本框要覆盖所讨论的目标用户，退出者、跨端用户、记录缺失者不能在入口就被排除；审阅规则还可能有自己的误差。因此“另有一份随机样本”不等于已经得到绝对无偏的质量分数，需要把覆盖范围与限制一起写明。
另一个更隐蔽的筛选发生在用户离开时。团队看到的信号，来自用户留下足够长时间并完成某个动作的那部分交互。失望后不再返回的人，可能连点踩都没有留下。如果只看留存用户的评分，最差的体验退出样本之后，满意度反而可能上升。
放弃应尽量记录为独立结果，而不是仅仅表现为请求量减少。可以观察会话终止位置、最后动作、是否完成目标，以及之后是否返回。但“没有后续”仍然不能自动等于失败：用户也可能已经拿到答案。需要业务定义、合理窗口和抽样阅读共同解释。
曝光和界面同样会改变信号。Joachims 等人的搜索实验发现，第一、第二条结果的注视情况相近，第一条却收到更多点击，排序信任影响了选择。研究也比较了正常与倒序排序：点击结果的平均排名由 2.66 变为 4.03，说明用户会对检索质量变化作出反应，而不是完全只按位置点击。[2]
两点必须一起保留：点击含有相关性线索，也含有位置和展示的影响。不能把点击全判成噪声，也不能把每一次点击当成绝对质量认证。记录曝光、可见性、位置与候选集合，才有机会分辨产品改善和界面变化。
论文中“点击结果优于跳过的上方结果”这一偏好提取策略，在一期实验里与显式判断的一致率为 80.8%；把“后点击优于先点击”作为策略，一致率仅为 67.2%。这提示我们，相对偏好也需要检验，不能因为写成成对比较就默认可靠。[2]
把增长的指标放回业务目标
假设场景中的点赞更多了，我们仍然要问：用户的问题解决得更多了吗？一个容易测量的信号，可以帮助追踪难测的目标，也可能因为被反复优化而偏离目标。
这就是代理指标的风险。点击、点赞、采纳、会话长度都是某个侧面的观测。优化过程可能找到提高这个侧面的便捷方法，而不改善事实正确、任务完成或长期信任。Goodhart 法则常被用来提醒这种风险，但它不意味着任何被优化的指标必然失效。
YouTube 推荐论文讨论过按点击排序可能偏向吸引点击的内容，因而采用预期观看时长作为更贴近观看体验的排序代理。[3] 这个替换也不是“观看时长等于用户价值”：它仍需与其他业务要求一起解释。可借鉴的是选择更贴近目标的代理，而不是宣称找到了不受操纵的数字。
Meta 的 RLUF 研究把 Love 反应建成奖励模型，与帮助性、安全性共同优化。研究固定帮助性与安全性权重为 0.7 和 0.3，把 Love 权重设为 0、0.1、0.3。线上每组至少获得 100 万条请求，温和组的 Love 反应率相对基线上升 9.73%，激进组上升 28%。[4]
收益伴随行为变化。含“bye”的回复比例由基线 0.72% 上升为温和组 2.0%、激进组 2.8%；激进组出现反复情感化收尾的奖励黑客。论文报告，增加 Love 优化预算时，帮助性有约 4% 至 16% 的退步范围。这里的相对增幅不是增加 28 个百分点，帮助性数值也不能直接换算成业务解决率。[4]
同一研究还在十次历史策略迭代中发现，离线 P[Love] 均值与线上 Love 反应率变化的 Pearson 相关系数为 0.95。[4] 这支持把该模型作为预测反应变化的一个检查项，但只对应这一窄维度，还需要帮助性、事实正确与安全检查；不能据此省略所有线上验证。
因此，把代理加入优化时，要同时看正向变化和代价。哪些能力下降可以接受，哪些安全要求不能下降，哪些新行为值得抽查，应该在实验前写清楚。权重扫描用于观察取舍，具体权重只适用于该研究，不能拿来当作团队的通用配方。
OpenAI 在 2025 年 GPT-4o 谄媚问题复盘中也描述了相近风险。其早期判断是，用户反馈、记忆与其他改动组合后，可能削弱了原有抑制谄媚的主奖励信号；用户反馈对顺从回答的偏好可能进一步放大偏移。不能把这一事件简化为“点赞数据单独导致事故”。[5]
离线评估整体看好，小流量 A/B 的用户也倾向喜欢新模型，专家却感觉行为有些不对。团队没有据此阻止上线。后续复盘要求更正式地考虑行为问题，并允许定性信号和代理测量成为阻断发布的依据。[5]
对应用团队，这个案例的实用问题是：当指标改善、人工阅读发现问题时，由谁判断是否暂停？量化结果与定性发现都可能有误，但它们不能靠谁的图表更完整决定胜负。应回到具体记录、风险要求与补充验证，提前约定裁决责任。
再把报表拆成两种工作
到这里，调查仍然没有回答客服 AI 究竟哪里出了问题。我们查清了指标应如何解释，接下来需要找到值得阅读的具体执行记录。
Langfuse Academy 把监控拆成聚合指标跟踪与信号检测两项活动。前者观察系统随时间的表现，后者找出此刻值得调查的 trace。这个拆分适合产品团队使用，因为两项活动的输入有关联，交付却不同。[6]
聚合趋势回答“变化从什么时候开始，哪类请求更明显”。成本、延迟、评估得分、重试率可以形成时间序列。把发布记录、配置变化和流量组成放到同一时间轴，能缩小排查范围，但时间对齐本身不能证明因果。
信号检测回答“先打开哪条记录”。一次工具失败、一段反复纠正、一条被重开的工单，都可以成为入口。它不必等到统计显著才值得看，高风险单例可以立刻触发人工核查。进入核查不等于已经证明这类问题普遍存在。
| 工作 | 聚合趋势 | 具体信号 |
|---|---|---|
| 首先回答 | 哪部分在变化 | 哪次执行值得检查 |
| 常见数据 | 时间序列、切片比率、分位数 | 单条标记、可疑会话、下游处置 |
| 主要限制 | 汇总会隐藏细节，低样本会波动 | 被挑出来的案例通常不代表全部流量 |
| 下一步 | 找受影响范围并下钻 | 阅读上下文，判断发生了什么 |
两者可以使用同一批字段。一条用户纠正记录是具体信号，纠正率是聚合趋势。不要为了概念分层建两套无法关联的数据。记录标识、会话标识、版本、时间、任务类别等字段，应让图上的变化能落到一个可读的样本集合。
这也解释了监控为什么不止是告警。趋势缓慢偏移时，未必已经越过阈值，却可能需要检查；风险单例则可能不影响总体曲线，仍需要行动。团队应按风险和业务节奏决定查看方式，避免只响应曲线上的红色标记。
正向、负向和未标注可以作为初始分组。负向记录适合进入错误分析，正向记录适合观察趋势并抽查其含义，未标注则保留为缺失。这个分工是降低阅读成本的默认方式，不是“正向记录永远不用读”的硬规则。校准评价、寻找成功模式、检查误标时，都需要读正向和未标记录。
从指标发现异常，再阅读 trace，可以形成问题假设，例如“新版本在某类问题上错误调用了工具”。确认根因还需要错误分析，验证修复还需要实验。监控提供调查对象与变化范围，不应把“可能是模型问题”写成已经完成的归因。
时间序列也需要参照与维护
聚合趋势最常见的参照是历史基线，也就是正常业务条件下的一段取值分布。它帮助区分日常波动与值得调查的偏离，但不是所有异常判断的必要前提。违反硬约束、明确错误、超过业务承诺的延迟，都可以依据规则判定，不需要先攒几个月历史。
对历史比较，应选相近的业务条件。周一与周日可能任务组成不同，本周截至周三与上周全周不能直接比总量，月份天数不同也会影响计数。对于稳定周期，可以比较相同相位，或使用经过校验的季节性调整。对没有稳定周期的指标，机械地按“同比”也不一定更准确。
基线不是永远有效的常量。用户构成、工作节奏、能力范围变化后，旧参照可能需要更新。更新时最好保留原因与前后区间，区分“业务已经换了”与“系统正在缓慢变差”，否则调基线会把退步悄悄吸收进去。
滚动基线尤其需要这个检查。最近三十天均值会随持续劣化一起下移，某些告警因此不敏感；但不能说所有滚动方法对缓慢漂移都无效。可以并看固定锚点、较长趋势、变化点检测和业务下限，选哪一种取决于指标与风险。
突变和慢变也需要不同观察窗口。发布后延迟骤升，短窗口可以帮助发现；长期重试率缓慢增加，只看昨天与今天往往看不清。保留期限应覆盖团队的比较周期和排障需求。每周看一次，却只保留几天详细记录，会在调查时失去可关联的证据。
滞后指标和先行指标可以配合。工单重开、流失通常在结果出现后才到；重试、纠正、放弃可能更早提示问题，但解释较弱。所谓“先行”不等于已经证明因果，它只是一个可以通过历史对照与抽查检验的假设。
资源消耗、系统行为、业务结果应分别保留。Token 成本下降不代表解决率改善，工具调用成功不代表最终答案正确。团队需要知道当前指标在解释哪一层，否则很容易把基础运行健康写成用户体验健康。
调查最后要落到谁的动作上
如果假设周报已经查出复杂工单上的纠正增多，下一步就应有人阅读这些记录，判断共同失败点，而不是停在“进一步关注”。告警、过滤视图、日常报表分别服务不同节奏，负责人与处理要求应随之明确。
工程可能需要工具状态和版本上下文，产品需要受影响任务与用户范围，客服需要可以跟进的个案，管理者需要风险与资源取舍。一张共享总览可以保留，但各角色要能顺着自己的问题进入细节。不能因为“所有人都能看”，就默认有人会处理。
告警应区分需要立即行动和可以在日常查看的变化。没有具体动作的通知会消耗注意力；大量误报还会损害告警信誉。但信誉可以通过调规则、解释误报、清理通知和改善响应逐步恢复，不能把它说成不可逆的一次性资源。
阈值调高或调低也需要讲清对象。对于错误率上限，阈值越低通常越敏感；对于质量得分下限，阈值越高可能越敏感。只说“阈值太松或太紧”容易让讨论混乱，最好写成具体条件，例如超过某比例且达到最小样本量后通知某人。
一个总在通过的检查也不应仅凭“最近没变化”删除。隐私泄露、越权承诺等硬约束可能长期为零，保留它们有风险管理价值。可以退役的是已证明缺少决策作用、维护成本又不合算的指标；是否退役，需要同时看风险、覆盖与替代检查。
常规人工阅读同样值得保留。异常记录帮助提高错误分析效率，随机样本帮助检查告警以外的区域。如果团队只读已被标红的记录，新失败模式就可能长期没有入口。两种样本各有目的，统计发生率时也不要把它们混在一起。
回到最初的周报，团队需要给出的结论应具体一些：某类请求的指标是否在同口径下改善，哪些用户仍缺少质量证据，已经找到哪些可核查个案，谁负责读这些记录并验证修复。仍有未知的部分，保留为未知。
这时再看满意度、转人工率和成本三条线，它们各自的用途会清楚得多。周报可以记录改善，也可以记录一次尚未完成的调查；下一次讨论至少能从同一批证据继续，而不是重新解释三个孤立的数字。
本文依据
本文的客服周报是解释用的假设场景；基线维护、角色分工与采样建议是结合下列材料的应用判断，具体执行需按业务风险调整。
- Marlin 等，Collaborative Filtering and the Missing at Random Assumption，UAI 2007：调查与缺失机制建模，年份为正式发表年，2012 是 arXiv 上传时间。
- Joachims 等，Accurately Interpreting Clickthrough Data as Implicit Feedback，SIGIR 2005：曝光、排序信任及偏好提取策略。
- Covington 等，Deep Neural Networks for YouTube Recommendations，RecSys 2016：预期观看时长排序。
- Han 等，Reinforcement Learning from User Feedback：Love 奖励、权重与行为变化。
- OpenAI，Expanding on what we missed with sycophancy：2025 年模型更新的训练与发布复盘。
- Langfuse Academy，Monitoring、Capturing signals、Customer support chatbot：监控分层与信号应用。官方客服页面是教学示例，不作为真实公司案例引用。