GEO跑批的批次ID我没按时间戳生成，重跑分母直接翻倍

兄弟们，凌晨一点四十，我又来自曝了。

这次踩的坑是批次ID。上周跑GEO批处理，我图省事，让技术用 时间戳+随机数 生成批次ID，想着反正每次跑都是新批次，能区分就行。结果这周做数据复盘，发现同一个批次的两次重跑，分母从 12 条虚高到 24 条，直接翻倍。

我是怎么发现的？周五下午拉数据，看到一条异常曲线：同一个问句ID，在同一个批次里出现了两次，分母被算了两遍。一开始以为是去重逻辑挂了，逼着技术把去重键打印出来，才发现问题出在批次ID——两次重跑生成了两个不同的批次ID，系统把它们当成了两个独立批次，分母自然就翻倍了。

坑的具体位置：我们的GEO跑批流程是 输入问句 -> 采样 -> 归一化 -> 写入落盘，批次ID是在采样前生成的。因为是时间戳，每次重跑都会变。而下游的统计逻辑是按批次ID聚合分母的，所以重跑一次，分母就膨胀一次。

我现在的解法是：批次ID用输入数据的哈希值生成，保证同样的输入永远得到同样的批次ID。改完之后，重跑分母从 24 掉回 12.3，虚高条数从 12 条降到 0.3 条——那 0.3 是采样边界噪声，我暂时忍了。

但这里还有个没想明白的点：哈希盐值到底该拼在归一化前还是归一化后？ 我试了两种，归一化前拼盐，分母稳定在 12.3；归一化后拼盐，分母波动到 13.1。差了 0.8，虽然不大，但我觉得这 0.8 背后是归一化过程中某些字段被改写了，导致哈希输入不一致。

所以我想问社区里跑过批处理的老哥：

1. 你们的批次ID是谁生成的？是采集方赋戳，还是落盘方赋戳？我们现在是采集方赋，但落盘方又改了一次，导致两边对不上。
2. 哈希盐值你们拼在归一化前还是后？有没有人做过A/B，差异到底来自哪里？

不搞GEO，等死吗？但搞GEO，细节不抠，也是等死。这分母的坑，我真是踩一次骂一次。