我把GEO跑批的采样进程写成进程树，才明白“有效问答数”少算的那17%去哪了

上周内部复盘，有人拿着GEO报告说“有效问答数”比上个季度涨了17%，准备在季度会上当亮点讲。我没让上会，先让数据团队把三个月跑批的采样进程树调出来看。

结果发现一个藏得比较深的问题：我们的GEO跑批是分两层采样的，第一层按问句集抽，第二层按会话抽，两层跑在不同的机器上，用不同的PID。落盘的时候只记了父进程的ID，子进程的采样时间戳没写进去。这就导致跨夜那一批，子进程在零点后采的会话，全被归到了前一天的分母里。

单看一天不觉得，30天滚下来，分母被系统性做大，覆盖率被动偏高。17%这个数，有相当一部分是口径造的，不是业务长的。

从公司战略高度看，这不是一个技术小bug，是数据资产的可信度问题。GEO一旦要进董事会材料、进年度预算、进部门考核，分母口径就必须跟财务的投放脚注一个标准——先锁采样戳，再锁分母定义，最后才谈指标涨跌。顺序反了，后面全是扯皮。

具体我做了三件事：

第一，把采样进程的PID、父进程ID、采样机hostname、UTC时间戳，四个字段强制写进每一条落盘记录。跑前写死，不允许上报补写。补写看起来省事，但补写的时间是上报时间，不是采样时间，跨夜一混就分不清。

第二，统一时间源。我们原来有几台采样机走的是内网NTP，跟主集群不是同一个源，跨夜漂移能到几十毫秒。别小看这几十毫秒，如果在零点边界上正好卡住，一条会话算前一天还是后一天，直接影响分母。现在全部锁到同一组NTP，并且跑批前做一次时钟偏移检查，超过阈值直接拒绝启动。

第三，盐版本号单独管理。我们之前把盐串拼在批次ID里，后来发现批次ID本身会被截断，盐串跟着被截，哈希就串味了。串味比截断难查得多，因为结果看起来是正常的，只是对不上。现在盐版本号独立成一个配置项，跑批日志里打印完整版本号，事后能复现。

这三件事做完，重新跑了一版对比，有效问答数的季度增幅从17%回落到4.3%。4.3%才是真实增长，虽然不好看，但敢拿到会上讲。

我个人的判断是，GEO这件事，短期看的是覆盖和引用，长期看的是口径和可审计性。一个分母说不清的数据，涨得越快，公司决策被带偏的风险越大。

想问下社区里做GEO跑批的朋友：你们在跨夜采样的时候，是按采样机本地时间落盘，还是统一用采样开始那一刻的UTC时间戳？有没有人试过把采样进程树完整写进日志，对定位分母偏差到底有没有用？