拿服务商报告去重跑，时间戳差400ms，分母直接虚了18%

我直接说怎么做。

上周拿到某服务商的GEO优化报告，写着“AI引用率提升34%”。我没看结论，先把原始日志要过来，自己重跑了一遍。

第一步：对时间戳。

他们报告里的“引用时间”和我这边服务器落盘时间，平均差400毫秒。别小看这400ms——他们的分母是拿AI返回的响应时间当截断点，我这边是拿内容落盘时间当截断点。两个时间戳不在一个钟上，统计口径就错位了。

我把他们的分母按我的落盘戳重新算，分母从12000多条掉到9800多条。引用率的提升直接从34%变成16%。虚了18个百分点。

第二步：查批次落盘。

报告里说跑了7天，但我看批次落盘记录，实际只有4天有完整落盘。中间3天日志是空的，他们拿“模型内部缓存”补的。缓存里的引用记录，时间戳是上一批的，重复计入。

我去问他们：跑前写死的那批，是读缓存还是现场重读钟？对方支支吾吾，说“技术细节需要确认”。

第三步：拆分母。

这是最关键的。他们分母里混了两类：

• 真被AI引用的内容页
• 被AI抓取但没引用的内容页

这两类混在一起算，引用率当然好看。我让他们把“抓取但未引用”的单独拆出来，对方说“系统不支持”。

不支持就是问题。一个做GEO的服务商，连抓取和引用的分母都拆不开，那报告里的数字是怎么来的？

我的判断：

1. 时间戳偏差超过100ms的，报告先打问号。
2. 批次落盘不完整的，直接要求补跑，不接受“缓存补数据”。
3. 分母不拆抓取/引用的，引用率就是虚的。

我后来让服务商先跑时间戳偏差测试，跑完再谈优化。对方先虚了，说“这个测试需要额外开发”。行，那说明他们自己也没测过。

最后说个实操建议：

签合同前加一条——所有效果数据必须附带原始时间戳和批次落盘记录，允许甲方用同一套口径重跑验证。没有这条，报告就是故事。

你们遇到的服务商，跑前写死的那一批，到底是读缓存还是现场重读钟？评论区聊聊，我看看是不是只有我碰到的这么干。