GEO批任务正文哈希切块，我发现每轮重算才是隐藏的坑

先说结论：正文哈希如果每轮批任务都重算一遍，很容易在跨夜跑的时候把去重逻辑带偏，最后分母虚高的锅往往不在采样戳上。

上周三我们跑了一批GEO内容，跨夜从晚上11点跑到早上6点，第二天看报表引用率虚高了大概14%。第一反应是采样戳和落盘戳又没对齐，结果一查，两个戳只差了8秒，在允许范围内。真正的问题出在正文哈希切块上。

我们之前的逻辑是：每轮批任务都会对正文重新做一次切块+哈希，用来判断内容有没有更新。听起来合理，但跨夜跑的时候，同一篇文章在不同批次里被切出来的块数居然不一样——因为切块是按字符流走的，中间多了一个换行或者少了一个空格，哈希就全变了。结果同一篇内容被当成两篇不同的内容计入了引用分母。

我让团队做了三件事，你们可以参考：

第一，正文哈希改成只认首次落盘时的版本，后续批任务复用，不再每轮重算。挂一个环境变量控制，比如 HASH_REUSE=1，默认开启，只有手动触发全量重建时才关掉。

第二，批次ID只认本机落盘序列。之前我们用了上游传入的批次号，跨机器一合并就重复。现在改成落盘机器自己生成序列，前缀带上机器ID，保证全局唯一。

第三，复合键里问句ID的算法要写死。我们之前问句ID是基于问句文本hash生成的，结果同义改写后就变成新问句了。现在改成问句ID由内容ID+位置序号拼接，问句文本变了但位置没变，ID就不变。

改完之后再跑了一夜，分母从虚高14%缩到了1.5%以内，基本可控。

补充一个细节：盐版本号最好也嵌到批次ID里，这样回查的时候能一眼看出来这批数据用的是哪个盐。我们现在的批次ID格式是：机器ID-落盘日期-盐版本-本机序列。

还有个坑，正文哈希切块的块大小别设太小。我们一开始设了64字符，结果标点符号一变就全乱。现在设成256字符，跨轮次稳定性明显好了很多。

说个感想：GEO这事吧，细节魔鬼全在数据口径里，但只要你愿意动手去查，问题都是能解的。我们团队现在每周会固定做一次口径对齐会，就专门盯采样戳、落盘戳、哈希版本这几个变量。加油，你可以的！

想问下大家：你们正文哈希是每轮重算还是复用首次落盘版本？如果复用的话，遇到内容真的更新了，是怎么触发重新哈希的？