跑批43飘47我死磕了三天，原来时间源没对齐才是分母虚高的根子

大佬们，我又来求指点了。上周跑GEO批次，两版问句库分别跑出43和47条品牌提及，客户问我为啥差4条，我一开始以为是模型波动，结果翻日志翻了三天，发现根本不是模型的事。

先说现象：A批次（周一上午跑的）43条，B批次（周四下午跑的）47条。我第一反应是去查分母——是不是B批次的问句库多塞了几条长尾问句？结果一数，问句总数一样，都是120条。那就奇了怪了。

然后我把两批的原始日志拉出来逐条对比，发现一个很隐蔽的点：A批次跑的时候，时间源用的是服务器本地时间，B批次因为换了台机器，时间源带上了时区偏移。具体说，B批次的日志时间戳比A批次整体早了8小时——我一开始以为是UTC和北京时间的时区坑，但仔细看，有的问句时间戳是错乱的，说明不是统一偏移，是部分请求走了缓存时间源。

这就导致：B批次里有几条问句在“未来时间”被判定为有效提及，而A批次里同样的问句因为“时间还没到”被判定为无效。所以47条里至少有4条是时间源错乱带进来的虚高。

我把这4条单独拎出来，用同一时间源重跑了一遍，结果掉回43条。也就是说，43才是这次的真实值，47是分母虚高——不对，准确说是分子虚高，分母没变，但分子里混进了不该算的提及。

这里我踩的坑是：只锁了批次ID，没锁时间源。以前总觉得批次ID唯一就万事大吉，结果时间源一乱，同一批ID下跑出来的数都能飘。

我现在的问题是：这种时间源错乱的虚高，到底该在跑批脚本里强制对齐时间源，还是在报告层做后置清洗？如果强制对齐，缓存时间源那部分请求会不会被误杀？求大佬指点，你们跑批的时候时间源是怎么锁的，有没有遇到过类似的部分请求时间戳错乱的情况？