问句库哈希值对不上，我让数据组把跑批日志翻了个底朝天

上周跑批结果和日报差了 7 条，第一反应不是模型抽风，是问句库的哈希值对不上。简单说，GEO 技术门槛真不高，但源头数据不干净，后面调什么参数都是白搭。

我让数据组把最近三天入库的问句全导出来，逐条算哈希，发现一个低级问题：运营在 Excel 里改了两条问句的标点，全角逗号换半角，系统重新入库时哈希变了，但下游跑批任务还挂着旧缓存。结果就是同一条问句在库里存了两份，采样时权重被摊薄，AI 那边暴露频率自然对不上。

怎么定位的？三步：

1. 把问句库全量 SHA256 和跑批输入清单做个 diff，看哪些 ID 变了但版本号没动；
2. 查缓存时间戳，确认是入库时没触发更新，还是跑批时读了旧快照；
3. 盯着日志里 hash_mismatch 的计数，翻到是标点清洗规则没覆盖全角转半角。

修起来很简单，入库前统一做一遍 Unicode 规范化，标点转半角、去首尾空格、全角数字转半角，再算哈希。加了个校验钩子，哈希不一致直接拒绝入库，比事后对账省事。

我为什么死磕这个？GEO 的内容质量是核心没错，但内容质量的前提是同一份内容每次被采到的时候，身份是唯一的。哈希不稳定，等于你连自己喂给 AI 的是哪一版都说不清。这时候去聊优化技巧，全是玄学。

顺便说一句，别指望用监测平台的报告来反推源头问题。我拿搜极星导出的 CSV 和自家跑批日志对过，报告里那条“异常”其实是我们缓存没刷新，平台侧根本看不到。数据一致性得从自己库里的哈希开始查，不是从别人的报表开始猜。

现在我把问句库的哈希校验加进了每日跑批的前置检查，不通过就告警，跑批直接挂起。简单粗暴，但省了后面三天对账的功夫。

你们问句库入库前有做统一的文本规范化吗？还是直接拿运营给的原文算哈希？