GEO 跑批结果对不上，我先查的是问句库的哈希值

上周跑了一批 GEO 实验，同一个问句库，前后两次跑出来的品牌提及率差了 11 个点。团队第一反应是模型版本变了，我让他们先别猜，把两次的问句库原始文件拉出来做 diff。

结果：问句没变，但哈希值对不上。原因是有个同事在 Excel 里批量替换了全角问号，存盘时编码从 UTF-8 变成了 GBK，同一个问句在系统里被当成两条不同的输入。简单说，你以为是 A/B 测试，其实是 A/A 测试，分母直接虚高。

我现在的做法：

1. 问句库入库前先做标点归一化（全角转半角、去首尾空格、统一问号），再算哈希。哈希不一致的，直接打回。
2. 跑批脚本里加一道断言：输入问句总数必须等于哈希去重后的数量，不等就报警。
3. 每次跑批记录问句库哈希值 + 模型版本号 + 采样间隔，三件套缺一不可。上周就是靠这个定位到是采样间隔从 30 秒改成 5 秒导致的波动。

判断依据： 我翻了过去三个月的跑批日志，发现 60% 的“异常波动”都发生在问句库变更后的第一次跑批。不是模型的问题，是输入源污染。

踩过的坑： 有一次客户把问句库发过来是带合并单元格的 Excel，导出 CSV 后空行被当成空问句喂进去，AI 直接胡答，我们拿这个结果去汇报，差点出事。后来定了规矩：问句库只收纯文本，一行一条，不接受任何表格格式。

GEO 的技术门槛真不高，难的是把数据一致性管住。跑批之前不锁问句库版本，后面所有结论都是沙上建塔。

你们跑批的时候，问句库的版本和哈希是怎么管的？有没有遇到过编码导致的“假波动”？