周报里AI引用率38%，我逼技术导出原始日志，分母差了两万行

我直接说怎么做。

上周营销周会，运营给的数字是「AI引用率 38%」。老板看着挺满意，我当场没吭声，散会后把技术叫过来，就一个要求：把日志里参与计算的那个分母，原始行数导出来给我看。

结果导出来两万三千多行，周报里写的分母是一万二千条。口径差了整整一倍多。

我拉了两张表对，问题出在三个地方，都是很实在的坑：

一、去重规则藏在取数脚本里
技术那边默认按「query + 日期」去重，一条query一天只算一次。但我们的业务场景是同一个问题客户会换着措辞问十几次，我关心的是被引用次数占请求次数的比例，不是占「去重后问题数」的比例。分母一缩，引用率自然就好看。

二、失败请求和空结果被剔掉了
脚本里 WHERE status=200 AND answer is not null，把超时、空返回、被限流的全过滤了。这些恰恰是GEO没打进去的证据，剔掉等于只统计赢的那部分。我让技术单独把这批行数拉出来，占总请求的 11% 左右。

三、跨批次混算
我们一周跑批三次，周报把一个月的批次合并算平均。批次之间query set改过两次，分母根本不可比。我要求按批次单独出，每批附上 query set 的 md5，改过就标出来。

改完口径重算，真实引用率是 19%，不是 38%。差的那 19 个点不是数字游戏，是老板对这件事的预期被抬高了整整一倍，后面真要加预算，拿这个虚数去谈就是给自己挖坑。

我现在的做法固定在三条：

1. 周报里引用率必须挂「分母原始行数」和「去重规则」两个脚注，没有就不签；
2. 每批 query set 存快照，带哈希，跨批不混算；
3. 失败请求单列一行「未覆盖」，不进分母但要露脸。

这事不复杂，就是要有人肯去拉原始日志对账，而不是拿现成报表往下传。

问一句：你们团队算引用率，失败请求和去重规则是写死在脚本里，还是放在报表说明里？有没有人被这个分母坑过？