Wiki Notes

Appearance

AI产品指标体系专题 ​

版本：v1.3

最后更新：2026-07-09

适用对象：正在做知识助手、客服 Agent、审批助手、语音助手、多模态系统和企业内部 Copilot，需要把“感觉效果还行”变成“知道到底好不好、为什么好不好”的产品、运营与平台同学

很多 AI 产品上线后，最容易出现的一个问题是：

  • 团队知道“它有点不对劲”
  • 但说不清到底哪里不对
  • 更说不清该先优化什么

本质原因通常不是模型太差，而是：

  • 没有建立一套像样的指标体系

这篇专题聚焦的是：

  1. AI 产品到底该看哪些指标。
  2. 这些指标之间如何取舍。
  3. 怎样避免只看单一指标做出错误决策。
  4. 怎样把离线评测、线上观测和业务指标接成一套体系。

根据 2026-07-09 可访问的 OpenAI Evaluation best practices / Evaluate agent workflows / Integrations and observability / Trace grading / Production best practices，以及 Google SRE 关于 SLO、告警和用户影响的资料，一个很值得先建立的共识是：

AI 产品指标体系不是给 dashboard 凑热闹，而是用来回答“有没有带来业务价值、哪里在退化、风险能不能接受、是否值得继续放量”。

1. 为什么 AI 产品更需要指标体系 ​

OpenAI 当前评测资料一直在强调：

  • 评测要持续
  • 指标要贴近真实任务
  • 工作流级问题不能只看最终输出

换到产品视角，就是：

  • AI 产品不是看一次“效果演示”就结束

因为 AI 产品往往同时具有这些特点：

  • 输出有概率波动
  • 质量很难只用一个分数描述
  • 用户体验、风险和成本彼此牵制
  • 请求看起来“成功”也可能业务上失败

因此 AI 产品更需要：

  • 多层指标
  • 分场景指标
  • 离线与线上结合

2. AI 指标不要只盯模型分数 ​

很多团队一开始最容易犯的错是：

  • 只看模型准确率
  • 或只看用户满意度

实际上，AI 产品更常见的指标层次通常包括：

  • 业务指标
  • 质量指标
  • 产品体验指标
  • 系统稳定性指标
  • 成本指标
  • 安全指标

一句话理解：

  • 模型分数只是产品指标体系的一部分，不是全部。

3. 业务指标回答的是“有没有带来价值” ​

业务指标不是为了证明模型聪明，而是为了回答：

  • 这个 AI 产品到底有没有解决业务问题

常见例子：

  • 工单分流准确率
  • 客服转人工率下降
  • 首次解决率提升
  • 内容生产效率提升
  • 销售跟进转化率提升
  • 审批时长缩短

3.1 为什么业务指标必须单独保留 ​

因为很多系统会出现一种错觉：

  • 技术指标很好看
  • 但业务结果没有改善

例如：

  • 回答更长了，但用户没有更快完成任务
  • 分数高了，但人工审批压力变大了

所以如果业务指标没改善，再漂亮的技术指标也可能只是“技术自嗨”。

4. 质量指标回答的是“输出本身好不好” ​

质量指标更关注回答、抽取、推理和工具动作本身是否正确。

常见包括：

  • 回答正确率
  • 引用命中率
  • 结构化字段完整率
  • 工具调用正确率
  • 任务完成率

OpenAI Evaluation best practices 当前文档强调：

  • 评测的目标是在输出存在波动时仍能稳定测试系统行为

工程上可以理解为：

  • 质量指标不能只靠感觉，要靠持续 evals 和样例治理

4.1 质量指标最容易犯的错 ​

  • 只看平均分
  • 不看失败桶
  • 不看高风险场景

这会导致关键退化被均值掩盖。

5. 产品体验指标回答的是“用户感知如何” ​

用户未必会说“你的模型准确率低”，但会直接感知这些问题：

  • 太慢
  • 太啰嗦
  • 误解意图
  • 总是需要重试
  • 回复不稳定

所以常见体验指标包括：

  • 首包延迟
  • 任务完成时长
  • 二次追问率
  • 重试率
  • 用户放弃率
  • 会话中断率

5.1 为什么体验指标和质量指标不能互相替代 ​

有些系统：

  • 质量很高
  • 但太慢，用户根本用不下去

也有些系统：

  • 回得很快
  • 但总要用户自己补救

所以体验和质量要分开看。

6. 稳定性与系统指标回答的是“它能不能持续跑” ​

AI 产品的“稳定性”不只是接口不报错，还包括：

  • 工作流有没有卡住
  • 工具有没有超时
  • 长流程有没有反复重试
  • 某一类请求是否持续退化

常见系统指标包括：

  • 请求成功率
  • 平均延迟
  • P95 / P99 延迟
  • 工具失败率
  • fallback 触发率
  • session 中断率

6.1 为什么 AI 稳定性更需要场景切片 ​

因为很多问题只会集中在某类链路：

  • 某个工具
  • 某个租户
  • 某种长上下文请求

如果只看全局平均值，往往看不出来。

7. 成本指标回答的是“值不值得持续做” ​

AI 产品很容易出现一种幻觉：

  • 功能做出来了，就算成功

但只要成本不可控，很多产品很难真正扩张。

常见成本指标包括：

  • 单次请求平均成本
  • 每类任务平均 token 消耗
  • 每类 workflow 成本分布
  • 高价值与低价值请求成本比
  • 人工接管后的综合成本

7.1 这里最容易漏掉的一层 ​

很多团队只算模型 token，不算：

  • 工具调用
  • 重试
  • 人工审批
  • 人工返工

这会直接低估真实业务成本。

8. 安全与风险指标回答的是“哪里不能退” ​

一旦产品进入真实业务，这一层不能缺。

常见包括：

  • 越权调用率
  • 安全拦截率
  • prompt injection 命中率
  • 人工审批触发率
  • 高风险输出误放率

8.1 安全指标为什么不能只放到安全团队看 ​

因为很多安全问题最后会直接变成：

  • 业务事故
  • 审批积压
  • 用户信任下降

所以这层指标也应进入产品指标体系，而不是变成孤立看板。

9. 指标体系应该怎么分层 ​

更实用的做法通常是三层：

9.1 北极星指标 ​

回答：

  • 产品整体有没有创造核心价值

例如：

  • 首次解决率
  • 工单自动闭环率
  • 任务完成率

9.2 诊断指标 ​

回答：

  • 哪一层在拉低北极星指标

例如：

  • 引用正确率
  • 工具成功率
  • 转人工率
  • 二次追问率

9.3 护栏指标 ​

回答：

  • 哪些底线绝不能退

例如：

  • 高风险误放率
  • 权限误召回率
  • 审批漏触发率
  • 成本超预算率

10. 北极星指标为什么不能选错 ​

一个常见错误是把“模型表现”当北极星，而不是“业务结果”。

更稳的选择原则通常是：

  • 能体现真实业务目标
  • 能长期稳定观察
  • 不是纯局部技术信号

比如一个客服助手更适合的北极星，往往是：

  • 首次解决率

而不是：

  • 平均回答长度

10.1 北极星指标最好绑定“关键用户旅程”，不要只绑定单轮回答 ​

很多团队会选一个看上去很顺手的指标当北极星，例如：

  • 回答采纳率
  • 平均会话长度
  • 工具调用成功率

但 AI 产品真正创造价值的，往往不是单轮输出，而是一段完整旅程：

  • 用户提问
  • 系统检索和推理
  • 工具执行
  • 是否转人工
  • 是否真正解决任务

所以更稳的北极星设计通常会先问一句：

  • 这条产品最关键的用户旅程是什么

再决定指标。

例如：

  • 客服助手更适合看首次解决率或任务闭环率
  • 审批助手更适合看正确触发审批后的闭环时长
  • 销售 Copilot 更适合看有效跟进完成率

否则很容易出现：

  • 单轮回答分数变好了
  • 但整条用户旅程反而更差

11. 指标一定要按场景切片 ​

OpenAI Evaluate agent workflows 当前文档强调：

  • 用 traces、datasets、graders 和 eval runs 找工作流级问题

这件事放到产品指标上，一个很直接的启发是：

  • 指标不能只看总盘，必须按场景切

常见切片方式包括：

  • 用户分层
  • 任务类型
  • 风险等级
  • 租户
  • 工具依赖强弱
  • 长上下文 vs 短上下文
  • 是否需审批

12. 为什么“请求成功”不等于“任务成功” ​

很多系统会把：

  • 200 返回
  • 有文本输出
  • JSON 合法

当成“成功”

但对 AI 产品来说，真正更重要的是：

  • 用户任务有没有完成
  • 系统有没有真的帮到人
  • 有没有把风险转嫁给人工

所以指标体系里必须同时保留：

  • 技术成功率
  • 任务成功率

13. 离线指标和线上指标怎么分工 ​

更成熟的做法通常不是二选一，而是各司其职：

13.1 离线指标 ​

更适合：

  • 版本比较
  • 高风险样例回放
  • 回归测试
  • 变更前评估

13.2 线上指标 ​

更适合：

  • 用户真实影响
  • 运行退化
  • 成本变化
  • 审批和人工接管压力

如果没有离线指标，很多问题只能等线上暴露。 如果没有线上指标，很多离线“高分版本”会在生产翻车。

13.3 前置指标和滞后指标最好拆开管理 ​

很多团队的问题不是没有指标，而是把不同时间尺度的指标混在一起看。

更适合 AI 产品的拆法通常是：

  1. leading indicators 例如引用命中率、工具成功率、trace grader 分数、人工接管触发率。
  2. lagging indicators 例如首次解决率、投诉率、复访率、转化率、事故率。

前置指标更适合：

  • 发布前评估
  • 灰度早期观察
  • 快速止损

滞后指标更适合：

  • 判断长期业务价值
  • 验证是否真的改善了用户结果

如果这两类不拆开，团队就很容易：

  • 想等业务结果出来再处理，结果发现已经晚了
  • 或者只看前置技术信号，就误以为业务一定会变好

14. 指标体系一定要和版本治理绑定 ​

如果不知道指标对应的是：

  • 哪版模型
  • 哪版 Prompt
  • 哪版工作流
  • 哪版检索
  • 哪版审批规则

很多结论都会失真。

所以更可执行的做法通常是：

  • 每个关键指标切片都能关联到版本元数据

14.1 版本对比最好优先看 matched cohort，而不是粗暴比较两个总盘 ​

很多版本对比看起来很直观：

  • 老版本这周成功率 78%
  • 新版本这周成功率 80%

但这种比法经常不稳，因为两周的流量结构可能已经变了。

更稳的做法通常是优先看：

  • matched cohort

也就是尽量让新旧版本比较落在可比样本上，例如：

  • 同一类任务
  • 同一类租户
  • 同一类风险等级
  • 同一类工具依赖
  • 同一批高价值回放样本

OpenAI 当前 Evaluate agent workflows、Trace grading 和 Evaluation best practices 都在强调用数据集、trace 和 grader 做可重复比较。放到产品指标里，本质上就是要让版本对比尽量建立在可重复 cohort 上，而不是受随机流量波动影响。

15. 为什么总平均值特别容易误导 ​

AI 产品最容易出现一种情况：

  • 总体平均还行
  • 但高价值场景已经明显恶化

所以很多关键指标都不应只看平均：

  • 延迟要看 P95/P99
  • 风险要看高风险桶
  • 质量要看失败桶
  • 成本要看 top-cost 桶

16. 一个可执行的指标设计顺序 ​

如果团队现在还没有成熟指标体系，建议先按下面顺序建立：

  1. 先定义一个北极星业务指标。
  2. 再定义 3 到 5 个诊断指标。
  3. 再定义 3 到 5 个护栏指标。
  4. 再为高风险场景单独建切片。
  5. 最后把离线回放和线上看板接起来。

16.1 每个关键指标至少要补 6 个元字段 ​

很多团队会列出一串指标名，但没有把指标定义补完整，最后常见问题是：

  • 不同人算出来不一样
  • 指标异常时没人知道该看哪里
  • 发布门禁里根本无法自动判断

更稳的做法通常是给每个关键指标补齐这 6 个元字段：

  1. owner 谁对这个指标负责解释和推进。
  2. formula 分子、分母和排除条件是什么。
  3. granularity 按请求、会话、任务、审批单还是租户统计。
  4. slice keys 允许按哪些维度切片。
  5. refresh cadence 多久刷新一次，多久复核一次。
  6. action playbook 这个指标异常后第一步该看什么、谁来处理。

这样指标体系才从“名词表”变成真正可执行的治理对象。

17. 什么样的指标最该进入告警 ​

不是所有指标都适合告警。

更适合进入告警的一般是：

  • 用户影响明显
  • 可行动
  • 短时间内恶化会造成损失

例如：

  • 高风险误放率
  • 审批积压
  • 人工接管暴增
  • 高价值场景成功率突降

而不是所有 dashboard 曲线都要变成 pager 告警。

17.1 护栏指标最好对应 SLO / burn rate 心智，不要只设静态阈值 ​

Google SRE 关于 Implementing SLOs 和 Alerting on SLOs 的实践，对 AI 产品有个很有用的启发：

  • 不是所有波动都该立刻告警
  • 更应该关注“错误预算正在以多快速度被消耗”

放到 AI 产品里，一些更适合 burn rate 心智的指标包括：

  • 高风险误放率
  • 人工接管率异常上升
  • 高价值场景成功率突降
  • 审批积压持续上升

这类指标如果只用一个固定阈值，常见问题是：

  • 短时尖峰误报太多
  • 缓慢持续退化又报警太晚

更稳的做法通常是同时看：

  • 当前值
  • 短窗口趋势
  • 长窗口趋势
  • 是否正在消耗本周期可接受预算

18. 为什么指标体系和组织分工有关 ​

不同角色更关注的指标不同：

  • 产品更关注北极星与体验指标
  • 平台更关注稳定性、延迟和成本
  • 安全更关注风险和误放
  • 运营更关注人工接管和投诉回流

如果一套指标体系没人对应负责，最后就会变成：

  • 每个人都看一点
  • 但没有人真正负责优化

18.1 指标 owner 最好和“能动手改的人”一致 ​

很多团队会给指标分 owner，但 owner 只是“看报表的人”，不是“能改系统的人”。

这会带来一个常见问题：

  • 异常有人发现
  • 但没人真正能改 workflow、prompt、tool、审批规则或发布策略

更稳的分工通常是：

  • 北极星指标 owner 更接近产品 owner
  • 诊断指标 owner 更接近对应平台或应用 owner
  • 护栏指标 owner 更接近安全、审批或运行 owner

同时还要明确：

  • 谁能拍板降级
  • 谁能暂停放量
  • 谁能触发回滚

否则指标体系会停在“看到了问题”，但无法真正形成闭环。

19. 常见反模式 ​

  • 只看模型分数，不看业务结果
  • 只有总平均值，没有关键切片
  • 指标很多，但没有北极星
  • 指标只在事故后看，不进发布门禁
  • 安全和成本指标被排除在产品指标体系之外
  • 不记录版本元数据，导致指标变化无法解释
  • 指标定义没有分母口径、owner 和处置动作
  • 指标长期没人下线，历史债越积越多

19.1 指标债要定期清理，不然看板会越来越吵 ​

AI 团队很容易不断加指标，但很少删指标。

结果通常会变成：

  • 看板越来越长
  • 真正关键的指标被噪音淹没
  • 告警越来越多，但没人信

更成熟的做法通常会定期做一次：

  • metric debt review

重点回答：

  • 这个指标还有没有决策价值
  • 有没有重复指标
  • 有没有长期没人看的指标
  • 有没有应该并入切片、而不是单独存在的指标

如果不做这一步，指标体系最后很容易变成信息垃圾场。

20. 一个最小但能落地的指标模板 ​

如果现在要给一个 AI 产品补第一版指标体系，建议至少先列出：

  1. 北极星业务指标
  2. 核心质量指标
  3. 用户体验指标
  4. 成本指标
  5. 风险护栏指标
  6. 高风险场景切片

这六类已经足够支撑第一轮产品治理。

20.1 第一版指标模板最好再补一个“版本门禁页” ​

如果团队已经开始做灰度和回放，第一版模板里最好再多一页：

  • release scorecard

至少包含：

  • 本次版本号
  • 北极星指标预期影响
  • 关键诊断指标变化
  • 护栏指标阈值
  • 当前 matched cohort 结果
  • 是否允许继续灰度 / 放量 / 回滚

这样指标体系才会真正进入发布流程，而不是留在周会汇报里。

21. 推荐搭配阅读 ​

22. 重点官方资源 ​

以下资源已按 2026-07-09 做过可访问性检查：

23. 落地检查清单 ​

  • 是否同时覆盖业务、质量、体验、稳定性、成本和安全六层指标
  • 是否为高风险场景建立了单独切片，而不是只看平均值
  • 是否把离线评测、线上看板、matched cohort 和版本元数据关联起来
  • 是否明确了哪些指标是北极星，哪些是诊断指标，哪些是护栏指标
  • 是否为关键指标补齐 owner、公式、粒度、切片和处置动作
  • 是否让指标真正进入发布、灰度、告警和优化闭环