第 20 章：线上监控、质量看板与多角色报告

20.1 离线通过以后，质量进入真实环境

以下是一个贯穿本章的假设案例，不代表真实线上结果。客服 Agent 的候选版本通过了离线评测。Golden Set 没有退化，Regression Set 中的退款、售后、物流场景也都达到了门禁要求。团队按计划进入灰度。

两天后，转人工率开始上升，用户投诉里出现了“政策说法前后不一致”的描述。离线评测报告看起来没有异常，线上业务却已经出现质量信号。

这类情况很常见。离线评测解决的是“已知任务集合上的可控验证”，线上监控解决的是“真实流量分布下的持续发现”。企业级评测体系不能在发布门禁处结束。上线后的用户反馈、工具调用、成本延迟、转人工、投诉、安全拦截和 Bad Case 回流，都是评测闭环的一部分。

线上监控不是把所有日志塞进看板。它要回答三类问题：

1. 质量是否正在退化。
2. 哪些能力、场景或版本正在贡献风险。
3. 线上问题如何回流到离线评测资产。

如果这三类问题回答不了，看板再多也只是数据陈列。

20.2 线上质量信号的四类关注面

线上质量信号可以按四类关注面组织：业务结果、用户体验、安全合规和系统运行。它们是并列观察维度，不是从低到高的层级，也不能互相折算。

关注面	关注问题	典型信号
业务结果	Agent 是否帮助业务完成任务	解决率、转人工率、退款处理成功率、订单查询完成率
用户体验	用户是否顺畅完成交互	用户追问率、重复提问率、负反馈率、投诉率、会话中断率
安全合规	是否触碰不可接受风险	隐私泄露、越权操作、敏感拒答、错误承诺、政策违规
系统运行	系统是否稳定、可控、经济	工具失败率、检索失败率、P95 延迟、单会话成本、超时率

这四类关注面不能互相替代。业务结果稳定，不代表安全没有风险；系统延迟稳定，也不代表回答质量正确。

客服 Agent 的线上监控至少要覆盖以下问题：

• 用户是否被迫反复描述同一个问题。
• Agent 是否把本应转人工的高风险场景继续自动处理。
• 工具是否频繁失败但最终回答仍然看似完整。
• 知识库政策更新后，回答是否仍沿用过期说法。
• 灰度版本是否在某些渠道、城市、商品类目上出现集中退化。

线上信号的价值不在于越多越好，而在于能否连接到后续动作。

20.3 线上质量信号字典

线上信号不天然等于真实质量标签。用户反馈可能有自选择偏差，投诉和转人工标签通常存在延迟，低频高风险事件又可能被总体均值淹没。因此，看板应同时展示信号来源、采样规则、标签延迟和缺失情况；相关性本身不足以证明某个离线指标导致了业务结果。

质量信号需要定义清楚。否则同一个“解决率”，产品、算法和运营可能有三种口径。

一个可用的线上质量信号字典至少包括：

字段	说明
signal_id	信号唯一标识
signal_version	信号定义版本，用于还原历史口径
name	信号名称
definition	计算口径
source	数据来源
direction	上升代表变好还是变差
baseline	基线窗口
alert_rule	告警规则
offline_mapping	对应的离线评测维度
sampling_rule	采样、过滤和去重规则
slice_dimensions	必须支持的版本、场景、渠道等切片
label_delay	标签产生与回补延迟
minimum_support	触发率类判断所需的最低有效样本或统计条件
response_action	触发后的控制、诊断或复核动作
owner	负责人

以客服 Agent 为例：

信号	计算口径	异常含义	对应离线维度
transfer_to_human_rate	转人工会话数 / 总会话数	Agent 无法解决或用户不信任	任务完成、业务规则、体验
repeat_question_rate	用户重复表达同一意图的会话占比	理解失败或回答不可执行	指令理解、多轮状态
complaint_rate	投诉会话数 / 总会话数	高价值质量风险	安全、业务正确性、体验
tool_failure_rate	工具失败调用数 / 工具调用总数	工具链路或参数质量问题	Tool 调用、Agent 编排
unsupported_answer_rate	无证据回答占比	幻觉或引用缺失	RAG 忠实性、引用正确性
refusal_rate	拒答会话数 / 总会话数	可能过度保守或安全策略触发	安全拒答、误拒
latency_p95	会话关键路径 P95 延迟	用户等待成本上升	系统可用性
cost_per_session	单会话模型与工具成本	预算风险	成本效率

定义信号时要避免只写名字。没有口径、来源、基线和 Owner 的指标，无法用于决策。

20.3.1 基线与切片

线上指标需要基线。没有基线，团队无法判断“上升”是异常还是正常波动。

基线可以按以下维度切片：

切片维度	示例
时间	工作日、周末、活动期
渠道	App、网页、小程序、电话转接
场景	退款、物流、发票、投诉
用户类型	新用户、会员用户、高价值用户
版本	当前线上版本、灰度版本
风险等级	P0、P1、P2、P3

全局转人工率不足以说明客服 Agent 各场景的变化。会员部分退款场景的转人工率上升，可能被普通物流查询的大流量掩盖。看板需要支持按场景和版本下钻。

20.3.2 告警分级

线上质量告警沿用第 9 章的 P0—P3 风险严重度，不另造一套同名等级。分级对象是已观察事件或信号所代表的业务风险，不是告警渠道优先级。

告警级别	示例	动作
P0	隐私泄露、越权工具调用	立即回滚或阻断流量
P1	高风险退款误答、投诉率急升	暂停放量，启动归因
P2	转人工率、重复提问率明显上升	进入诊断和补充评测
P3	成本、延迟、回答长度轻微波动	观察趋势

告警分级要和发布门禁相连。P0 不应只发消息提醒，还要有明确的自动或人工处置流程。

事件型红线和聚合率告警应采用不同规则。经确认的隐私泄露、越权操作可以由单个事件触发；投诉率、转人工率等聚合信号则要声明基线、观察窗口、最低样本量和不确定性处理，避免从一次短时波动直接推断系统已经退化。

20.4 离线指标与线上信号的映射

线上指标不能替代离线评测，离线指标也不能预测所有线上问题。二者要通过映射关系连接。

第 15 章负责检验离线指标与线上结果是否具有稳定统计关系；本节负责把已选指标接入信号字典、看板、告警和处置流程，不重复承担相关性证明。

离线评测维度	对应线上信号	解释
意图识别准确率	重复提问率、转人工率	用户意图被误解时，线上会出现反复解释或转人工
RAG 忠实性	无证据回答率、投诉率	无引用或引用错误会导致用户不信任
工具调用正确率	工具失败率、任务失败率	参数错误、工具选择错误会直接影响任务完成
多轮状态保持	会话中断率、重复确认率	状态丢失会让用户重复输入信息
安全合规通过率	高危拦截、投诉、审核命中	安全问题线上可能低频但高损
拒答合理性	拒答率、误拒反馈	拒答过度会伤害体验，拒答不足会增加风险
成本延迟	P95 延迟、单会话成本	离线成本评测要接受线上真实负载验证

映射关系不是一次性配置。业务变化后，线上信号可能暴露离线评测集缺口。

客服 Agent 的退款政策变更就是典型例子。离线评测仍覆盖过去的退款规则，线上用户却开始询问新的“部分退款 + 会员权益补偿”政策。离线分数稳定，转人工率却上升，说明评测数据没有覆盖新的真实分布。

20.5 Bad Case 采集的目标是形成可诊断资产

本章负责从线上发现、脱敏、聚类并创建待诊断资产；第 21 章负责证据归因，第 22 章负责修复和防复发，第 17 章只提供承载这些流转的平台模块。

线上 Bad Case 采集不是简单保存差评对话。一个可用于后续诊断的 Bad Case 至少要包含：

• 用户问题和完成诊断所需的上下文。
• Agent 最终回答。
• 检索结果、工具调用、状态变更和可观测的中间决策证据；不要求记录模型隐藏推理过程。
• 触发的安全策略、业务规则和兜底策略。
• 用户反馈、转人工结果或人工客服处理结果。
• 版本、时间、渠道、业务线和流量实验信息。
• 脱敏状态和可复用等级。

第 21 章会展开根因归因。本章只关注采集和回流入口。

线上采集应经过五个步骤：

步骤	目标	关键要求
采样	从海量流量中选择候选问题	覆盖高风险、低频、灰度版本和负反馈
脱敏	移除个人信息和敏感业务数据	保留诊断所需结构，不保留无关隐私
去重	合并同类问题	避免同一问题反复污染评测集
聚类	形成问题簇	识别集中退化和新增场景
定级	决定处理优先级	按风险、影响面、复现性和业务价值排序

Bad Case 回流到离线资产时，要区分三种去向：

1. 进入待诊断池，用于后续根因分析。
2. 进入 Regression 候选池，经期望行为、Rubric 和审核补全后用于防止同类问题复发。
3. 进入数据生产候选池，用于后训练或偏好数据构建。

三种去向的质量要求不同，不能混为一个“线上样本库”。

20.5.1 Bad Case 回流工作台

线上回流需要一个工作台，而不是把样本丢进表格。

工作台至少包含：

模块	功能
候选池	接收负反馈、投诉、转人工、抽样和告警样本
脱敏队列	移除个人信息和敏感字段
聚类视图	按语义、场景、版本和风险聚类
定级面板	标注风险等级、影响面和优先级
归因入口	创建第 21 章中的分层归因任务
回归候选	判断是否进入 Regression Set
数据生产候选	判断是否进入训练或偏好数据流程

客服 Agent 的“会员部分退款”问题簇可以从工作台直接进入三个去向：一部分进入归因任务，一部分进入退款 Regression Set，一部分在完成归因和脱敏后进入后训练数据候选池。

20.5.2 线上样本可复用等级

不是所有线上样本都能进入离线资产。下面的 R0—R4 是本书用于表示 Reuse Readiness（复用就绪度）的工程示例，不是行业标准，也不同于第 14 章的沙箱保真度和第 21 章的归因证据成熟度。

等级	含义	用途
R0	含敏感信息，暂不可复用	仅用于受控人工诊断
R1	已脱敏，但期望行为不清楚	候选池
R2	已脱敏、已标注场景和风险	归因和聚类
R3	已有期望行为和 Rubric	Regression 或 Hard Case 候选
R4	已审核、可进入门禁	核心回归或红队

这个等级可以防止线上样本未经处理就污染评测集。

20.6 质量看板的信息架构

质量看板要服务决策，而不是展示所有数据。

一个企业级 AI 质量看板可以分为七个一级模块。第 20.11 节的交付物沿用同一结构，不再维护另一套看板分类。

一级模块	主要问题	典型内容
发布状态	当前版本是否可继续放量	当前版本、灰度比例、Gate Result 和发布决定
质量总览	系统当前是否健康或正在退化	核心指标、版本与渠道趋势、异常标记
安全红线	是否出现不可接受风险	隐私、越权、严重误导、误放与误拒
能力诊断	哪些能力正在变化	RAG、Tool、多轮、拒答和体验
Bad Case 闭环	问题是否被处理	问题簇、Owner、归因、修复与回归状态
成本性能	是否超出预算和时延要求	Token 成本、工具成本、P95/P99 延迟
报告中心	不同角色能否获得可行动结论	日报、周报、发布报告和事故报告

看板不应只有一个总分。总分适合管理层快速判断整体状态，但不能用于技术定位。

客服 Agent 看板可以设置三层入口：

1. 业务总览：今天是否可继续放量。
2. 质量诊断：哪个场景、能力、版本出现异常。
3. 问题闭环：每个高优 Bad Case 是否有人处理，处理后是否回归验证。

这样看板才能从“观察屏幕”变成“行动入口”。

20.6.1 看板下钻路径

质量看板应支持从宏观指标下钻到具体证据。

推荐路径是：

总览指标异常
  ↓
场景 / 版本 / 渠道切片
  ↓
问题簇
  ↓
代表性 Bad Case
  ↓
Trace / 检索 / 工具证据
  ↓
归因任务 / 回归样本 / 修复动作

例如，转人工率上升不应停留在趋势图。团队需要继续下钻：是否集中在灰度版本、是否集中在会员部分退款、是否对应某个知识库更新、是否伴随 RAG 召回失败和工具未调用。只有能下钻到证据，看板才有工程价值。

20.6.2 从看板异常到处置任务

看板如果不能创建处置任务，就很容易停留在“大家看到了”。线上质量系统应把异常转成可跟踪任务。

异常处置任务沿用第 19.4.1 节定义的十个通用治理字段：record_id、record_type、source_id、affected_scope、owner、status、deadline、evidence_links、created_at 和 updated_at。在此基础上只增加以下线上诊断字段；若初步归因被证据确认，再由第 22 章修复工单承接，不在异常任务中重复维护完整修复方案。

字段	说明
trigger_signal	触发信号和阈值
representative_cases	代表性 Bad Case
initial_hypothesis	初步归因假设
action_type	回滚、暂停放量、补测、归因、创建修复工单
verification	如何确认问题解除

例如，会员部分退款转人工率异常后，系统不只让看板变红，还应自动或半自动生成问题任务：关联灰度版本、抽取代表性对话、绑定客服 Agent 质量负责人，并在项目约定时限内给出归因初判。若用 24 小时作为假设配置，也要按风险和团队响应能力校准；修复后再触发 Regression Set。

20.6.3 看板角色权限

不同角色看到的数据粒度不同。

角色	可见信息
管理层	风险等级、影响范围、发布建议
产品负责人	场景趋势、用户反馈、体验指标
算法和工程	Trace、检索、工具、版本差异
安全负责人	高危样本、权限、红队和审计
运营团队	高频问题、人工接管、话术和流程

线上样本中可能包含用户隐私，不能因为做看板就扩大数据访问范围。

20.7 多角色报告

同一份评测结果，算法、产品、安全、业务和管理层关心的问题不同。

角色	最关心的问题	报告重点
算法 / 工程	为什么变差，改哪里	归因线索、版本对比、失败样本、Trace
产品	用户体验哪里受损	场景分布、用户反馈、转人工、交互阻塞
安全 / 合规	是否触碰红线	高危样本、拦截策略、误放与误拒
运营 / 客服	哪些话术和流程要调整	高频问题、政策解释、人工兜底建议
管理层	是否影响发布和业务目标	风险等级、影响范围、决策建议、负责人

因此，企业级评测报告应具备“同一证据，不同视图”的能力，一张统一大表无法满足所有角色。

例如，退款政策误答对不同角色的表达应不同：

• 给算法：检索结果没有召回最新政策片段，且生成阶段没有触发拒答。
• 给产品：用户在补偿规则上连续追问三轮后转人工。
• 给安全：错误承诺可能构成不当权益承诺。
• 给管理层：灰度版本在会员退款场景存在 P1 风险，建议暂停扩大流量。

报告的本质是把质量证据翻译成角色可行动的信息。

报告提供证据、影响和行动建议，但不替代第 19 章的发布决定。若报告建议暂停放量、回滚或继续发布，责任流程需要创建或更新独立的发布决定记录，并引用相应 Gate Result、线上信号版本和报告；报告不得覆盖历史 Gate Result，也不得代替审批人作出决定。

20.8 报告标准：结论、证据、影响、动作

一份可执行的质量报告至少包含七个部分：

部分	要回答的问题
结论	当前版本能否继续发布或放量
证据	哪些数据和样本支持结论
影响	影响哪些用户、场景、渠道和业务目标
风险等级	风险是 P0、P1、P2 还是观察项
归因线索	当前初步指向哪一层，但不替代深度归因
建议动作	放行、阻断、灰度、回滚、补测或人工复核
Owner / Deadline	谁处理，什么时候给出结果

报告里最容易缺的是动作。很多报告写到“指标下降，需要关注”就结束了。这样的报告无法改变系统质量。

更好的写法是：

灰度版本 refund_agent_2026_07_08 在会员退款场景中转人工率较基线上升 18%，负反馈集中在“部分退款与权益补偿”问题。建议暂停从 10% 扩到 30%，补充新政策场景离线评测，并将相关线上样本加入待诊断池。Owner 为客服 Agent 质量负责人，24 小时内完成归因初判。

这段文字同时给出结论、证据、影响、动作和 Owner。

20.8.1 报告节奏

不同报告有不同节奏。

报告类型	触发	重点
发布报告	发布前或灰度前	离线评测、门禁、风险和放量建议
灰度日报	灰度期间	线上信号、Bad Case、是否继续放量
质量周报	稳定运行阶段	趋势、问题闭环、数据回流
事故报告	P0 / P1 事件	影响、根因、修复、防复发
体系体检报告	月度或季度	指标、数据、Evaluator 和线上相关性

报告节奏要服务决策频率。灰度期间需要更高频，稳定运行后可以转为趋势和闭环管理。

20.8.2 告警闭环验收

告警不是发出通知就结束。每个 P0、P1 和持续性 P2 告警都应有闭环验收。

阶段	验收问题
响应	是否有 Owner 接收并确认影响范围
控制	是否暂停放量、回滚、限流或转人工兜底
归因	是否形成可验证根因假设
修复	是否完成系统、数据、Prompt、RAG、工具或流程修复
回归	是否加入 Regression、Red Team 或线上监控规则
复盘	是否调整指标、阈值、样本或门禁策略

没有闭环验收，告警会逐渐失去权威。团队会习惯性忽略告警，或者把每次异常都当成临时运营问题处理。线上监控需要把“发现异常”连接到“降低复发概率”。

20.9 案例：转人工率上升但离线分数不变

客服 Agent 灰度后，质量看板出现如下信号：

指标	基线	灰度	判断
Golden Set 任务完成率	91.2%	91.0%	稳定
Regression Set 通过率	98.5%	98.7%	稳定
转人工率	14.0%	19.8%	异常
重复提问率	8.5%	13.1%	异常
投诉率	0.7%	1.4%	异常

离线结果没有异常，线上体验指标明显退化。

团队进一步查看线上 Bad Case 聚类，发现新增问题集中在：

• 会员部分退款是否影响积分。
• 使用优惠券后退款金额如何计算。
• 退款后权益补偿是否自动发放。

这些问题都来自近期政策更新，但离线评测集没有覆盖。

因此，第一个动作是核对证据链，而非直接调整模型：

1. 将相关线上对话脱敏后进入待诊断池。
2. 补充“新退款政策”离线 Case。
3. 将新政策场景接入 Regression Set。
4. 暂停灰度放量，补测通过后再继续。

线上监控在这里发挥的作用，是发现离线评测没有覆盖的真实需求变化。

20.10 交付物一：线上质量信号字典

20.3 定义信号字典的字段和口径，本节只给出一条可直接复用的完整填写示例，不维护第二套字段定义。

下表中的 14 天、3 小时和 20% 均为假设配置，用于展示字段关系；团队应根据流量、业务周期、标签延迟和可接受风险校准。

字段	示例
signal_id	refund_transfer_to_human_rate
signal_version	v1.0
name	退款场景转人工率
definition	退款场景中转人工会话数 / 退款场景总会话数
source	会话日志、人工客服系统
direction	上升代表质量风险增加
baseline	过去 14 天同渠道同场景均值
alert_rule	连续 3 小时超过基线 20%
offline_mapping	任务完成率、多轮状态、业务规则正确性
sampling_rule	排除测试流量；按会话去重；保留灰度版本标识
slice_dimensions	版本、退款子场景、渠道、用户类型
label_delay	转人工事件实时回传；人工结案标签次日回补
minimum_support	达到项目约定的有效会话数后才判断率类告警
response_action	暂停放量并创建归因任务；P0 事件直接执行红线流程
owner	客服 Agent 质量负责人

这个字典应作为平台配置管理并实施版本化，和指标口径、看板、告警、报告共享同一套定义。历史报告需要保留所引用的 signal_id 和 signal_version，不能在信号口径变化后用新定义重算并覆盖旧结论。

20.11 交付物二：质量看板信息架构

一级模块	二级模块	使用者
发布状态	当前版本、灰度比例、Gate Result 和发布决定	管理层、产品
质量总览	核心指标、趋势、异常标记	全部角色
安全红线	高危事件、误放、误拒	安全、管理层
能力诊断	RAG、Tool、多轮、拒答、体验	算法、工程
Bad Case 闭环	问题簇、Owner、修复状态	质量、研发、产品
成本性能	Token 成本、工具成本、延迟	工程、业务
报告中心	日报、周报、发布报告、事故报告	全部角色

看板设计要支持从总览下钻到样本，从样本回到版本、能力和 Owner。

20.12 交付物三：多角色评测报告内容契约

本节只定义报告的内容契约，避免与项目工作表 08 维护两套格式。可直接填写的完整模板以“项目工作表 08：线上质量报告模板”为准。

字段	需要回答的问题
quality_conclusion	当前版本能否继续发布或放量，风险等级和影响范围是什么
key_signals	哪些离线证据、线上信号及其定义版本、切片和有效样本支持结论
offline_mapping	线上异常对应哪些离线评测维度，映射是否已验证
bad_case_summary	哪些问题簇和代表性 Bad Case 需要进入诊断或回归候选
role_views	算法、产品、安全、运营和管理层分别需要采取什么行动
actions	采取什么动作，由谁负责，何时完成，如何验证
data_notes	信号来源、采样、标签延迟、最低有效样本、不确定性和缺失是什么

这七个字段把第 20.8 节的结论、证据、影响和动作落实为可复用报告契约。格式可以因角色和节奏变化，但不能删掉决策、责任与证据边界。

20.13 线上监控的常见误区

20.13.1 只看平均值

平均转人工率稳定，不代表高价值场景稳定。客服 Agent 需要按场景、渠道、版本和用户类型切分。

20.13.2 把用户负反馈等同于质量真相

用户反馈重要，但不等于全部真相。有些高危错误用户不会发现，有些负反馈来自产品规则不符合用户预期。

20.13.3 只采集最终回答

没有检索、工具、状态和版本信息，后续很难诊断。线上采集需要保留可解释证据链。

20.13.4 看板没有 Owner

没有 Owner 的指标异常，只会变成群里的讨论。每个核心信号都要有明确负责人。

20.13.5 线上样本直接进入评测集

线上样本要经过脱敏、去重、聚类、质量检查和标注，才能进入稳定评测资产。

20.14 本章小结

上线后的质量体系要完成三件事。

第一，建立可行动的线上质量信号，覆盖业务、体验、安全和系统运行。

第二，把线上信号映射回离线评测维度，识别评测集缺口和真实分布变化。

第三，让看板和报告服务不同角色的决策，并把 Bad Case 回流到后续诊断和回归体系。

从下一章开始，我们进入质量改进闭环：线上发现 Bad Case 之后，如何分类、归因并验证根因。