从日志到洞察：每周该看的三张表

AI 系统通常日志很多但洞察很少。本文给出每周固定要看的三张表（质量/成本/失败）、每张该看什么、三条纪律，以及不等数据平台的起步方法。

日志很多，"洞察"很少

AI 系统通常不缺日志 ✗，缺的是**每周固定看的三张表** ✔。

没有固定节奏，就只能在出事后临时捞数据 ✗ —— 那时往往已经晚了 ✔。

建议每周看三张表 ✔：**质量表、成本表、失败表** ✔。

```

功能｜调用量｜成功率｜校验通过率｜负反馈率｜该拒答却作答率

```

看什么 ✔：

**该拒答却作答率**（编造倾向 ✔）—— 这条最该严 ✔；

**负反馈率的变化**（不是绝对值 ✔，是趋势 ✔）；

某个功能的成功率**突然下降** → 大概率是上游或版本变化 ✔。

```

功能/租户｜调用量｜单位成本｜总成本｜占比｜重试占比

```

看什么 ✔：

**Top 3 占比**（集中度太高说明有异常使用 ✔）；

**重试占比**（纯浪费 ✔）；

**单位成本周环比**（> 20% 要查 ✔）。

```

失败类型｜次数｜占比｜环比｜样例（1 条）

```

看什么 ✔：

**哪一类在涨**（不是总量 ✔）；

**有没有新类型**（新增的坏模式最危险 ✔）；

**样例**必须是**原文**（不要只给统计 ✔）—— 看原文常常一眼就看出原因 ✔。

1. **同一口径、同一周期** ✔（否则无法比较 ✔）；

2. **每张表有一句结论** ✔（"本周编造占比从 4% 升到 7%，主要来自长文档场景" ✔）；

3. **结论要转成待办** ✔（谁、什么时候、怎么验证 ✔）。

第一周：从现有日志里**手工捞**三张表 ✔（一条 SQL 或一段脚本 ✔）；

第二周：把手捞的脚本**固定下来** ✔，每周同一时间跑 ✔；

第三周：把结论与待办记进同一份文档 ✔（便于看历史 ✔）；

之后再考虑做看板 ✗（不要一开始就做 BI 项目 ✔）。

> 每周一早上，有没有人能**在 15 分钟内**拿出这三张表 ✔（且与上周同口径 ✔）？

> 不能，说明观测还停在"出事再查" ✗。