同一批GEO内容，两次跑引用率差9个点，先别急着换模型

上周做了个对照实验，同一批 40 条内容页，同一套 prompt，同一个模型版本，前后隔了 36 小时跑了两轮。第一轮引用率 21%，第二轮 30%，差了 9 个点。

团队第一反应是「模型更新了」，要去调 prompt 结构。我把两轮的采样日志拉出来对了一遍，先排掉了这个可能。

先锁时源，再谈别的。

第一轮跑的时候是下午，用的本地机器采样戳；第二轮是凌晨挂到另一台机器上跑的，那台机器走的是 NTP 校时。两台机器本地钟差了多少？我现场读了下：0.4 秒，而且第二轮那台机器的落盘戳中间回跳过两次。

这 0.4 秒本身不致命，致命的是它导致跨批次的引用归属错位。我把两轮里被引用的 URL 按批次 ID 分组，发现第二轮有 7 条引用被算到了前一批的账上，也就是说那 9 个点里，大概 2-3 个点是分母口径被换了导致的。

分母先看干净没有。

我重新按「同一时源 + 同一去重口径」跑了一遍归因：

1. 采样戳统一换成 NTP 校过的钟，本地钟只做备份记录
2. 跨批次的引用按批次 ID 严格切分，不允许跨批贴标签
3. 出口 IP 换池那段单独拉出来看，确认没有因为换池导致同一请求被计两次

重算完，两轮真实差距是 4.1 个点，不是 9 个点。

4 个点也不是小数字，但它指向的问题不一样了。

如果是 9 个点，说明模型或内容策略有系统性问题，值得停下来重构。但 4 个点更像采样噪声 + 时段效应：第二轮是凌晨跑的，并发低，请求排队少，模型响应更稳。这种情况下，该动的是采样策略，不是模型。

我现在的做法是：

• 同一批内容至少跑 3 轮，取中位数，不取单轮
• 每轮记录采样钟源（本地/NTP）、批次 ID 写入时机、出口 IP 池编号
• 分母去重口径写死在脚本里，不靠人工判断

小步快跑不等于乱跑。 快速迭代的前提是每一轮的数据能对上，对不上就重跑，别拿带噪声的数字去改模型。改模型一次成本多高，重跑一次才多少。

你们跑 GEO 批次的时候，采样戳用的是本地钟还是 NTP 校过的？有没有遇到过跨批次引用归属错位的情况？