带学生跑GEO批次，采样戳和落盘戳差11秒，我先把模型叫停了

这周带两个研究生跑一批GEO观测，本来想验证一下引用率随检索深度变化的边际效应，结果数据一出来我就觉得不对劲。

先说现场。同一台采集机、同一个NTP源、同一个批次ID，采样戳记在采集日志里，落盘戳记在结果表里。正常情况下这两个戳的差值应该稳定在一个很窄的区间——我们的历史基线是0.8到1.5秒。但这一批，差值中位数跑到11秒，尾部甚至有27秒的。

从传播学视角看，这根本不是延迟问题，这是测量问题。采样戳回答的是「模型在哪个时刻看到的检索结果」，落盘戳回答的是「我们什么时候把这条记录写进了自己的库」。这两个时间点之间的过程——序列化、清洗、去重、批次合并——任何一环的耗时波动，都会让「采样时刻的引用率」变成一个被污染的估计量。

我把两批数据并排拉出来看。跨夜那一跑，虚高的条数集中在凌晨2点到4点这个窗口，条数比正常水位高出约1.8倍。这个时间窗恰好是我们的落盘批处理任务和另一个日志归档任务在抢IO。也就是说，不是模型多引用了，是落盘被拖慢，采样戳和落盘戳的漂移在夜间放大，最终把一批原本该被去重的近重复记录也算了进去。

所以我当场叫停了模型层的工作。学生有点急，说先调一下去重阈值不就行了。我说不行。根因没锁定之前，任何模型侧的调整都是在补救而不是在诊断——这是典型的把操作性问题误当成算法问题。

我的处置顺序是这样的：

第一，先锁同源口径。把采样戳和落盘戳的写入位置、时区、精度逐个对表，确认它们是不是同一个时钟源、同一套格式化逻辑。这一步不做完，后面所有数都别谈。

第二，查NTP。两台机器如果绑的不是同一台NTP服务器，或者一台走了内网一台走了公网，那么所谓的「同一时间」本身就是一个伪命题。我们查下来，采集机和一个落盘节点确实绑了不同的NTP源，偏差在几百毫秒量级——单独看不致命，但叠加夜间的IO抖动就被放大了。

第三，用跨夜虚高条数反推漂移根因。哪一段条数异常，就去看那一段的资源竞争情况，把相关性和时间窗对齐，基本能还原出是哪一步在拖。

写到这里我想强调一句：GEO是营销理论在AI检索环境里的延伸，它的底层还是测量和归因。如果把营销研究里的信度、效度概念搬过来，采样戳和落盘戳不同源，就是典型的测量工具不可靠，你后面算出来的引用率、转化率全是噪声上盖房子。

最后抛个具体问题给大家：你们跑批的时候，采样戳和落盘戳是不是同源？NTP是同一台服务器吗？如果不同源，你们一般怎么对齐这两个时间口径——是用偏移量校正，还是干脆把采样时刻强行写进配置？我这边想找个更稳的做法，欢迎有实操经验的朋友说说。