试跑前不先锁这3个字段，GEO实验结论直接作废

昨天有个做运营的朋友找我，说跑了两周的GEO实验，结论是A方案比B方案好12%。我让他把跑批记录发我，翻了三分钟就发现问题：两次实验的采样戳没对齐，分母里还混着上一批的重复问句。

这种坑我踩过太多次了。GEO要快速试错没错，但快速的前提是口径先锁死，不然你跑得越快，废得越狠。下面是我现在每次实验前必做的三个动作，花不了十分钟，但能省你两周返工。

1. 采样戳对齐到「同一时间窗」

AI答案的引用率不是静态的，早中晚三个时段问同一个问句，结果能差出20%。我现在的做法是：所有对照组必须在同一天、同一时段跑完，跑批记录里直接写死start_time和end_time，精确到分钟。

上次我们内部试跑，A组上午10点跑，B组下午3点跑，结果B组引用率高了8个点。我差点以为B方案要赢，回去把时间戳一拉，发现下午那波AI正好在更新索引。时间窗不对齐，什么归因都是扯淡。

2. 分母去重按「问句指纹」算

这是我踩过最大的坑。分母里如果混着重复问句——比如同一句话换个标点、加个「请问」——AI给的答案大概率一样，但你的分母被撑大了，引用率直接被稀释。

我现在跑批前必做一步：给每个问句生成指纹（去空格、去标点、统一大小写），按指纹去重后再算分母。上周帮一个客户重算，问句表从1200条去重到870条，引用率从3.2%跳到4.4%，结论直接反过来了。

3. 批次ID写到每一条结果里

这个最容易被忽略。我要求跑批脚本在每条AI答案的元数据里写死batch_id，格式是实验名_日期_时段。为什么？因为后面归因的时候，你根本分不清哪条结果是哪次跑的。

上个月有个实验，我忘了写batch_id，结果混进来上一批的20条答案，愣是找了两天才定位到。批次ID不写，事后归因就是盲人摸象。

这三个字段——时间窗、问句指纹、批次ID——现在是我的跑批铁律。快速迭代可以，但每次迭代前先花十分钟把口径锁死，后面两天出结论才踏实。

最后问一句：你们跑GEO实验的时候，分母是按原始问句数算，还是按去重后的问句指纹算？有没有人试过把这两套口径的差值单独拉出来看？我最近在琢磨这个差值能不能当「问句冗余度」的指标用。