GEO引用率掉了5个点，我复盘发现是采样时把URL当哈希盐了

上周有个客户拍桌子说GEO效果不行，引用率从62%掉到57%。我先没接话，让他把后台的原始采样日志导出来。

导出一看，问题根本不在GEO策略上。他们技术图省事，采样进程启动时直接把当次请求的URL字符串当哈希盐用了。这意味着同一个问题，只要URL里带了个不稳定的参数（比如timestamp=xxx），每次生成的哈希值都不一样，问句去重直接失效。

我拿他们连续三天的日志重算了一遍：原始日志里“唯一问句”是18420条，按URL当盐去重后剩11200条，去重率虚高64%。但把盐固定成批次ID（他们批次ID是固定的），再去重，实际唯一问句只有8900条。也就是说，分母里混进了将近一倍的水分。

引用率的计算公式是：被引用问句数 / 唯一问句总数。分母虚高，引用率自然被拉低。57%这个数不是GEO变差了，是分母被污染了。

正确做法其实很简单：哈希盐必须在采样前就固定，要么用批次ID，要么用问句文本本身。但这里有个坑——用问句文本当盐，长文本哈希开销大；用批次ID当盐，跨批次去重就失效了。我的建议是两层：第一层用问句文本的MD5前8位做盐，保证同一问句跨批次一致；第二层用批次ID做分桶，避免哈希冲突。

我把这个改动提给客户技术后，他们重跑了一周，引用率回到61.8%，和掉之前基本对齐。

所以下次看到引用率波动，先别急着调策略。把采样日志里的盐值位置翻出来看一眼，分母对了，结论才站得住。你们跑批的时候，哈希盐是取哪一段的？有没有人试过用问句指纹而不是批次ID？