GEO跑批的"异常占比"，我先让团队把分子分母的口径写死在配置里

我直接说怎么做。

上周三凌晨跑完一批GEO，早上到公司打开后台，异常占比显示11.3%。我当时就觉得不对劲，因为前一批同样的问句集，异常占比才4%出头。差了快三倍，不可能是模型波动能解释的。

我把负责跑批的同事叫过来，问了一句：这个11.3%的分子是什么、分母是什么？他愣了一下，说后台直接给的。我说那不行，你得拆开看。

拆完发现问题了。

分母的口径，后台用的是"全部请求数"，包括那些因为网络超时自动重试的请求。而分子的口径，只算了"最终返回异常"的次数，没算重试里那部分。结果就是：重试的请求把分母推高了，但分子没跟着涨，比例按理说应该被稀释。可实际上反过来了——因为重试里有一批是连续失败三次才被标记为异常的，这批被算进了分子，但对应的原始请求只算了一次分母。

分子被重复计了一次，分母被重复计了三次，一进一出，比例就飘了。

这跟当年做SEO统计404率一个道理。日志里一条URL被蜘蛛抓了五次，你不能算五次访问一次404，得看唯一URL维度。GEO这边也是一样，重试机制让请求和结果不是一对一，直接拿后台给的比值就是在拿错的口径说事。

我让团队做了三件事。

第一，在跑批脚本的配置里，把"异常占比"的分子分母定义写死，注释清楚：分子=唯一问句ID中最终状态为异常的个数，分母=唯一问句ID总数。重试不算独立请求。

第二，每个批次跑完，先导出一份唯一问句ID的明细表，用脚本按这个口径重算一遍，跟后台的数字对一遍。对不上就查，不放过。

第三，把这个口径写进需求文档，后面换人跑批，照着配置走，不能再靠"后台直接给的"。

改完之后重跑同一批数据，异常占比从11.3%掉到4.7%，跟前一批基本对齐了。多出来的那6.6个点，全是重试把口径搅浑了。

我的判断就一句话：GEO跑批里任何带"占比""率"的数字，你不把分子分母的口径写死在配置里，它早晚会给你上课。

现在我想问的是：你们跑GEO批任务的时候，后台给的"异常占比"，分母到底算的是唯一问句还是总请求？有没有人拆过你们自己后台这个数，跟明细对过？