GEO测试集灰度发布，我踩了三个坑：时源、分母、批次ID

上周搞了个GEO测试集灰度发布，想快速验证新问句库的效果，结果三天跑下来，数据全废。不是AI不配合，是我自己口径没锁死。

先说时源。我图省事，直接用产品后台的默认时间戳，结果AI抓取日志和问句触发时间差了整整6分钟。就这6分钟，导致一批问句被算进了前一个实验组，归因全歪。后来我现场读加锁时间戳，才把批次对上。

第二个坑是分母。灰度发布时，我把新旧问句库混在一个分母里算采纳率，结果新库的提升被老库的基数稀释了。后来把分母拆成「灰度组」和「对照组」两个独立口径，才看清真实差异——新库被采纳率其实高了11个点，但混着算只显示3个点。

第三个坑最隐蔽：批次ID写入时机。我们是在问句生成后才写批次ID，但AI抓取是异步的，导致部分请求抓取时批次ID还没落库，直接成了孤儿数据。后来改成在问句入队时就写批次ID，问题才解决。

这三个坑让我明白一个道理：GEO快速迭代没问题，但先锁时源、再锁分母、最后锁批次ID，顺序不能乱。否则跑得越快，数据越脏。

你们灰度发布时，批次ID是在哪个环节写入的？有没有遇到过孤儿数据？