失败表里的样例必须是原文——看原文常常一眼就看出原因。
日志很多，"洞察"很少
AI 系统通常不缺日志 ✗，缺的是每周固定看的三张表 ✔。
没有固定节奏，就只能在出事后临时捞数据 ✗ —— 那时往往已经晚了 ✔。
建议每周看三张表 ✔：质量表、成本表、失败表 ✔。
表一：质量表（按功能）
```
功能 ｜ 调用量 ｜ 成功率 ｜ 校验通过率 ｜ 负反馈率 ｜ 该拒答却作答率
```
看什么 ✔：
· 该拒答却作答率（编造倾向 ✔）—— 这条最该严 ✔；
· 负反馈率的变化（不是绝对值 ✔，是趋势 ✔）；
· 某个功能的成功率突然下降 → 大概率是上游或版本变化 ✔。
表二：成本表（按功能 × 租户）
```
功能/租户 ｜ 调用量 ｜ 单位成本 ｜ 总成本 ｜ 占比 ｜ 重试占比
```
看什么 ✔：
· Top 3 占比（集中度太高说明有异常使用 ✔）；
· 重试占比（纯浪费 ✔）；
· 单位成本周环比（> 20% 要查 ✔）。
表三：失败表（按失败类型）
```
失败类型 ｜ 次数 ｜ 占比 ｜ 环比 ｜ 样例（1 条）
```
看什么 ✔：
· 哪一类在涨（不是总量 ✔）；
· 有没有新类型（新增的坏模式最危险 ✔）；
· 样例必须是原文（不要只给统计 ✔）—— 看原文常常一眼就看出原因 ✔。
三张表的三个纪律
1. 同一口径、同一周期 ✔（否则无法比较 ✔）；
2. 每张表有一句结论 ✔（"本周编造占比从 4% 升到 7%，主要来自长文档场景" ✔）；
3. 结论要转成待办 ✔（谁、什么时候、怎么验证 ✔）。
怎么开始（不用等数据平台）
· 第一周：从现有日志里手工捞三张表 ✔（一条 SQL 或一段脚本 ✔）；
· 第二周：把手捞的脚本固定下来 ✔，每周同一时间跑 ✔；
· 第三周：把结论与待办记进同一份文档 ✔（便于看历史 ✔）；
· 之后再考虑做看板 ✗（不要一开始就做 BI 项目 ✔）。
一条判据
> 每周一早上，有没有人能在 15 分钟内拿出这三张表 ✔（且与上周同口径 ✔）？
> 不能，说明观测还停在"出事再查" ✗。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：AI 功能的成本可视化：看得见、分得清、能追责
下一篇：AI 与人工的分工线怎么划：效率与风险的平衡 →
第 83 / 171 篇