第 20 章：线上监控、质量看板与多角色报告
第 20 章：线上监控、质量看板与多角色报告
20.1 离线通过以后，质量问题才真正进入真实环境
客服 Agent 的候选版本通过了离线评测。Golden Set 没有退化，Regression Set 中的退款、售后、物流场景也都达到了门禁要求。团队按计划进入灰度。
两天后，转人工率开始上升，用户投诉里出现了“政策说法前后不一致”的描述。离线评测报告看起来没有异常，线上业务却已经出现质量信号。
这类情况很常见。离线评测解决的是“已知任务集合上的可控验证”，线上监控解决的是“真实流量分布下的持续发现”。企业级评测体系不能在发布门禁处结束。上线后的用户反馈、工具调用、成本延迟、转人工、投诉、安全拦截和 Bad Case 回流，都是评测闭环的一部分。
线上监控不是把所有日志塞进看板。它要回答三类问题：
- 质量是否正在退化。
- 哪些能力、场景或版本正在贡献风险。
- 线上问题如何回流到离线评测资产。
如果这三类问题回答不了，看板再多也只是数据陈列。
20.2 线上质量信号的四个层级
线上质量信号可以分为四层：业务结果、用户体验、安全合规和系统运行。
| 层级 | 关注问题 | 典型信号 |
|---|---|---|
| 业务结果 | Agent 是否帮助业务完成任务 | 解决率、转人工率、退款处理成功率、订单查询完成率 |
| 用户体验 | 用户是否顺畅完成交互 | 用户追问率、重复提问率、负反馈率、投诉率、会话中断率 |
| 安全合规 | 是否触碰不可接受风险 | 隐私泄露、越权操作、敏感拒答、错误承诺、政策违规 |
| 系统运行 | 系统是否稳定、可控、经济 | 工具失败率、检索失败率、P95 延迟、单会话成本、超时率 |
这四层不能互相替代。业务结果稳定，不代表安全没有风险；系统延迟稳定，也不代表回答质量正确。
客服 Agent 的线上监控至少要覆盖以下问题：
- 用户是否被迫反复描述同一个问题。
- Agent 是否把本应转人工的高风险场景继续自动处理。
- 工具是否频繁失败但最终回答仍然看似完整。
- 知识库政策更新后，回答是否仍沿用过期说法。
- 灰度版本是否在某些渠道、城市、商品类目上出现集中退化。
线上信号的价值不在于越多越好，而在于能否连接到后续动作。
20.3 线上质量信号字典
质量信号必须定义清楚。否则同一个“解决率”，产品、算法和运营可能有三种口径。
一个可用的线上质量信号字典至少包括：
| 字段 | 说明 |
|---|---|
| signal_id | 信号唯一标识 |
| name | 信号名称 |
| definition | 计算口径 |
| source | 数据来源 |
| direction | 上升代表变好还是变差 |
| baseline | 基线窗口 |
| alert_rule | 告警规则 |
| offline_mapping | 对应的离线评测维度 |
| 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 告警分级
线上质量告警也应分级。
| 告警级别 | 示例 | 动作 |
|---|---|---|
| P0 | 隐私泄露、越权工具调用 | 立即回滚或阻断流量 |
| P1 | 高风险退款误答、投诉率急升 | 暂停放量，启动归因 |
| P2 | 转人工率、重复提问率明显上升 | 进入诊断和补充评测 |
| P3 | 成本、延迟、回答长度轻微波动 | 观察趋势 |
告警分级要和发布门禁相连。P0 不应只发消息提醒，必须有明确自动或人工处置流程。
20.4 离线指标与线上信号的映射
线上指标不能替代离线评测，离线指标也不能预测所有线上问题。二者要通过映射关系连接。
| 离线评测维度 | 对应线上信号 | 解释 |
|---|---|---|
| 意图识别准确率 | 重复提问率、转人工率 | 用户意图被误解时，线上会出现反复解释或转人工 |
| RAG 忠实性 | 无证据回答率、投诉率 | 无引用或引用错误会导致用户不信任 |
| 工具调用正确率 | 工具失败率、任务失败率 | 参数错误、工具选择错误会直接影响任务完成 |
| 多轮状态保持 | 会话中断率、重复确认率 | 状态丢失会让用户重复输入信息 |
| 安全合规通过率 | 高危拦截、投诉、审核命中 | 安全问题线上可能低频但高损 |
| 拒答合理性 | 拒答率、误拒反馈 | 拒答过度会伤害体验，拒答不足会增加风险 |
| 成本延迟 | P95 延迟、单会话成本 | 离线成本评测要接受线上真实负载验证 |
映射关系不是一次性配置。业务变化后，线上信号可能暴露离线评测集缺口。
客服 Agent 的退款政策变更就是典型例子。离线评测仍覆盖过去的退款规则，线上用户却开始询问新的“部分退款 + 会员权益补偿”政策。离线分数稳定，转人工率却上升。这不是离线评测失效，而是评测数据没有覆盖新的真实分布。
20.5 Bad Case 采集的目标是形成可诊断资产
线上 Bad Case 采集不是简单保存差评对话。一个可用于后续诊断的 Bad Case 至少要包含：
- 用户问题和完整上下文。
- Agent 最终回答。
- 检索结果、工具调用、状态变更和中间推理可观测信息。
- 触发的安全策略、业务规则和兜底策略。
- 用户反馈、转人工结果或人工客服处理结果。
- 版本、时间、渠道、业务线和流量实验信息。
- 脱敏状态和可复用等级。
第 21 章会展开根因归因。本章只关注采集和回流入口。
线上采集应经过五个步骤：
| 步骤 | 目标 | 关键要求 |
|---|---|---|
| 采样 | 从海量流量中选择候选问题 | 覆盖高风险、低频、灰度版本和负反馈 |
| 脱敏 | 移除个人信息和敏感业务数据 | 保留诊断所需结构，不保留无关隐私 |
| 去重 | 合并同类问题 | 避免同一问题反复污染评测集 |
| 聚类 | 形成问题簇 | 识别集中退化和新增场景 |
| 定级 | 决定处理优先级 | 按风险、影响面、复现性和业务价值排序 |
Bad Case 回流到离线资产时，要区分三种去向：
- 进入待诊断池，用于后续根因分析。
- 进入 Regression Set，用于防止同类问题复发。
- 进入数据生产候选池，用于后训练或偏好数据构建。
三种去向的质量要求不同，不能混为一个“线上样本库”。
20.5.1 Bad Case 回流工作台
线上回流需要一个工作台，而不是把样本丢进表格。
工作台至少包含：
| 模块 | 功能 |
|---|---|
| 候选池 | 接收负反馈、投诉、转人工、抽样和告警样本 |
| 脱敏队列 | 移除个人信息和敏感字段 |
| 聚类视图 | 按语义、场景、版本和风险聚类 |
| 定级面板 | 标注风险等级、影响面和优先级 |
| 归因入口 | 创建第 21 章中的分层归因任务 |
| 回归候选 | 判断是否进入 Regression Set |
| 数据生产候选 | 判断是否进入训练或偏好数据流程 |
客服 Agent 的“会员部分退款”问题簇可以从工作台直接进入三个去向：一部分进入归因任务，一部分进入退款 Regression Set，一部分在完成归因和脱敏后进入后训练数据候选池。
20.5.2 线上样本可复用等级
不是所有线上样本都能进入离线资产。可以给样本设置可复用等级：
| 等级 | 含义 | 用途 |
|---|---|---|
| L0 | 含敏感信息，暂不可复用 | 仅用于受控人工诊断 |
| L1 | 已脱敏，但期望行为不清楚 | 候选池 |
| L2 | 已脱敏、已标注场景和风险 | 归因和聚类 |
| L3 | 已有期望行为和 Rubric | Regression 或 Hard Case |
| L4 | 已审核、可进入门禁 | 核心回归或红队 |
这个等级可以防止线上样本未经处理就污染评测集。
20.6 质量看板的信息架构
质量看板要服务决策，而不是展示所有数据。
一个企业级 AI 质量看板可以分为六个区域：
| 区域 | 主要问题 | 典型内容 |
|---|---|---|
| 总览区 | 系统当前是否健康 | 核心质量分、风险等级、告警数量、版本状态 |
| 红线区 | 是否出现不可接受风险 | 隐私、越权、严重误导、合规命中 |
| 趋势区 | 是否发生退化 | 核心指标按版本、渠道、时间趋势 |
| 能力区 | 哪些能力正在变化 | RAG、工具、多轮、拒答、安全、体验 |
| 成本性能区 | 是否超出预算和时延要求 | Token 成本、工具成本、P95/P99 延迟 |
| 闭环区 | 问题是否被处理 | Bad Case 数量、Owner、修复状态、回归状态 |
看板不应只有一个总分。总分适合管理层快速判断整体状态，但不能用于技术定位。
客服 Agent 看板可以设置三层入口：
- 业务总览：今天是否可继续放量。
- 质量诊断：哪个场景、能力、版本出现异常。
- 问题闭环：每个高优 Bad Case 是否有人处理，处理后是否回归验证。
这样看板才能从“观察屏幕”变成“行动入口”。
20.6.1 看板下钻路径
质量看板应支持从宏观指标下钻到具体证据。
推荐路径是：
总览指标异常
↓
场景 / 版本 / 渠道切片
↓
问题簇
↓
代表性 Bad Case
↓
Trace / 检索 / 工具证据
↓
归因任务 / 回归样本 / 修复动作
例如，转人工率上升不应停留在趋势图。团队需要继续下钻：是否集中在灰度版本、是否集中在会员部分退款、是否对应某个知识库更新、是否伴随 RAG 召回失败和工具未调用。只有能下钻到证据，看板才有工程价值。
20.6.1.1 从看板异常到处置任务
看板如果不能创建处置任务，就很容易停留在“大家看到了”。线上质量系统应把异常转成可跟踪任务。
一条异常处置任务至少包含：
| 字段 | 说明 |
|---|---|
| incident_id | 异常或问题簇标识 |
| trigger_signal | 触发信号和阈值 |
| affected_scope | 版本、渠道、场景、用户群 |
| representative_cases | 代表性 Bad Case |
| initial_hypothesis | 初步归因假设 |
| owner | 处理负责人 |
| deadline | 响应和修复时限 |
| action_type | 回滚、暂停放量、补测、归因、修复 |
| verification | 如何确认问题解除 |
例如，会员部分退款转人工率异常不应只在看板上变红，而应自动或半自动生成问题任务：关联灰度版本、抽取代表性对话、绑定客服 Agent 质量负责人、要求 24 小时内给出归因初判，并在修复后触发 Regression Set。
20.6.2 看板角色权限
不同角色看到的数据粒度不同。
| 角色 | 可见信息 |
|---|---|
| 管理层 | 风险等级、影响范围、发布建议 |
| 产品负责人 | 场景趋势、用户反馈、体验指标 |
| 算法和工程 | Trace、检索、工具、版本差异 |
| 安全负责人 | 高危样本、权限、红队和审计 |
| 运营团队 | 高频问题、人工接管、话术和流程 |
线上样本中可能包含用户隐私，不能因为做看板就扩大数据访问范围。
20.7 多角色报告
同一份评测结果，算法、产品、安全、业务和管理层关心的问题不同。
| 角色 | 最关心的问题 | 报告重点 |
|---|---|---|
| 算法 / 工程 | 为什么变差，改哪里 | 归因线索、版本对比、失败样本、Trace |
| 产品 | 用户体验哪里受损 | 场景分布、用户反馈、转人工、交互阻塞 |
| 安全 / 合规 | 是否触碰红线 | 高危样本、拦截策略、误放与误拒 |
| 运营 / 客服 | 哪些话术和流程要调整 | 高频问题、政策解释、人工兜底建议 |
| 管理层 | 是否影响发布和业务目标 | 风险等级、影响范围、决策建议、负责人 |
因此，报告不能只是一张统一大表。企业级评测报告应具备“同一证据，不同视图”的能力。
例如，退款政策误答对不同角色的表达应不同：
- 给算法：检索结果没有召回最新政策片段，且生成阶段没有触发拒答。
- 给产品：用户在补偿规则上连续追问三轮后转人工。
- 给安全：错误承诺可能构成不当权益承诺。
- 给管理层：灰度版本在会员退款场景存在 P1 风险，建议暂停扩大流量。
报告的本质是把质量证据翻译成角色可行动的信息。
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 聚类，发现新增问题集中在：
- 会员部分退款是否影响积分。
- 使用优惠券后退款金额如何计算。
- 退款后权益补偿是否自动发放。
这些问题都来自近期政策更新，但离线评测集没有覆盖。
因此，第一个动作不是调整模型，而是：
- 将相关线上对话脱敏后进入待诊断池。
- 补充“新退款政策”离线 Case。
- 将新政策场景接入 Regression Set。
- 暂停灰度放量，补测通过后再继续。
线上监控在这里发挥的作用，是发现离线评测没有覆盖的真实需求变化。
20.10 交付物一：线上质量信号字典
| 字段 | 示例 |
|---|---|
| signal_id | refund_transfer_to_human_rate |
| name | 退款场景转人工率 |
| definition | 退款场景中转人工会话数 / 退款场景总会话数 |
| source | 会话日志、人工客服系统 |
| direction | 上升代表质量风险增加 |
| baseline | 过去 14 天同渠道同场景均值 |
| alert_rule | 连续 3 小时超过基线 20% |
| offline_mapping | 任务完成率、多轮状态、业务规则正确性 |
| owner | 客服 Agent 质量负责人 |
这个字典应作为平台配置管理，和指标口径、看板、告警、报告共享同一套定义。
20.11 交付物二：质量看板信息架构
| 一级模块 | 二级模块 | 使用者 |
|---|---|---|
| 发布状态 | 当前版本、灰度比例、门禁结果 | 管理层、产品 |
| 质量总览 | 核心指标、趋势、异常标记 | 全部角色 |
| 安全红线 | 高危事件、误放、误拒 | 安全、管理层 |
| 能力诊断 | RAG、Tool、多轮、拒答、体验 | 算法、工程 |
| Bad Case 闭环 | 问题簇、Owner、修复状态 | 质量、研发、产品 |
| 成本性能 | Token 成本、工具成本、延迟 | 工程、业务 |
| 报告中心 | 日报、周报、发布报告、事故报告 | 全部角色 |
看板设计要支持从总览下钻到样本，从样本回到版本、能力和 Owner。
20.12 交付物三：多角色评测报告模板
## 质量结论
- 决策建议：
- 风险等级：
- 影响范围：
## 关键证据
- 离线评测：
- 线上指标：
- 代表性 Bad Case：
## 角色视图
### 算法 / 工程
- 主要异常：
- 初步线索：
- 需要补充的诊断：
### 产品 / 业务
- 用户体验影响：
- 受影响流程：
- 建议产品动作：
### 安全 / 合规
- 红线风险：
- 误放 / 误拒：
- 审核建议：
### 管理层
- 是否继续发布：
- 是否扩大灰度：
- 资源和排期需求：
## 后续动作
| 动作 | Owner | Deadline | 验证方式 |
| --- | --- | --- | --- |
| | | | |
模板的关键不是格式统一，而是强制报告给出可执行结论。
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 之后，如何分类、归因并找到真正的根因。