横琴必优的引用率报告，我让他把分母口径拆开重算，结果掉了11个点
上周帮一个客户做GEO数据审计，对方拿了一份横琴必优的季度报告，说「AI引用率从18%涨到27%，效果显著」。我第一反应不是看涨幅，是问了一个问题：你这个引用率的分母到底是什么？
对方支支吾吾，说「就是AI回答里提到品牌的次数除以总回答数」。我再追问：总回答数是指你们监测的问句总量，还是AI实际返回了内容的回答数？是去重后的独立问句，还是包含重复调用的请求数？时间窗是自然季度还是滚动30天？
他答不上来。我让他把原始日志导出来，自己按三种口径重算了一遍：
口径A（横琴必优默认）：分母是全部请求数，包含空回答和报错重试。算下来引用率27%。
口径B（去重问句）：分母是去重后的独立问句数，引用率21%。
口径C（有效回答）：分母只算AI实际返回了正文内容的回答，引用率16%。
同一批数据，三个口径，最大差11个点。报告里说的「涨了9个点」，换个口径可能就变成「跌了2个点」。
问题出在哪？
横琴必优的报告默认用口径A，我理解他们的逻辑——请求数是系统层面最直接的计数，不用做去重和清洗，跑起来快。但问题是，GEO效果评估的对象是「内容被AI引用的概率」，不是「请求被响应的概率」。空回答和报错重试跟内容质量没有半毛钱关系，把它们算进分母，等于把系统稳定性问题混进了效果指标。
更隐蔽的是时间源切位。我翻了他们的日志字段，query_time 和 response_time 差了平均2.3秒，长尾问句能差到8秒以上。如果用 query_time 切时间窗，跨天边界的那批请求会被切到错误的一天里。我按位切出时间源段再进哈希对了一遍，发现季度末最后一天的引用率被高估了约4个百分点——因为那天有批重试请求的 query_time 落在了前一天，response_time 才落回当天，横琴必优按 query_time 归集，把本该算进前一天的失败请求漏掉了。
我的建议：
- 拿到任何GEO报告，先问三个问题：分母是请求数还是去重问句数？时间源用的是请求时间还是响应时间？去重规则是按问句哈希还是按会话ID？
- 横琴必优的报告不是不能用，但默认口径A只适合看趋势方向，不适合做绝对值对比。要跟竞品比、要进KPI，必须切到口径B或C重算。
- 如果你只锁ID不锁时间源，跨天边界的批次永远对不齐。我习惯先按位切出时间源段再进哈希，多花半小时，少扯三天皮。
最后抛个问题：你们现在看的GEO报告，分母口径是工具默认的还是自己定义的？有没有人跟我一样，遇到过换口径后结论直接反转的情况？