GEO试跑别一上来就全量：我拿50条query先锁口径，三天迭代两版

上周有个做SaaS的朋友找我，说他们GEO项目跑了俩月，AI引用率一直上不去，问我是不是该换服务商。我让他把最近一周的喂料日志和引用记录拉出来，结果一看，问题根本不在服务商——他们从第一天就是全量500条query一起上，口径没锁，校时没做，分母里混着重复query和品牌词，引用率算出来就是一团浆糊。

我的做法一直是快速迭代，但迭代的前提是先把口径锁死。具体三步：

第一步，先切50条query做试跑池。 这50条要覆盖三类：品牌词（10条）、品类词（20条）、长尾场景词（20条）。别嫌少，50条足够暴露结构性问题了，全量上只会把问题放大500倍。

第二步，采样戳校时必须在喂料前做。 我见过太多团队把校时放在事后，结果日志里的时间戳对不上批次ID，归因窗口一拉就是错的。我们组现在的规矩是：每条query的采样戳、喂料批次ID、AI返回时间，三者在同一个表里对齐，差一秒都不行。上次有个批次的校时偏了12分钟，直接导致那批数据的引用率虚高了18%，幸亏前置校验卡住了。

第三步，分母去重按query指纹做，不按文本。 同一句话换个标点就算两条，这是最常见的坑。我们用的是query归一化后再哈希，品牌词和品类词分开算分母，不然品类词的引用率会被品牌词稀释得没法看。

这套跑下来，我一般给三天时间：第一天跑试跑池，第二天看数据修口径，第三天再决定要不要扩到200条。快速迭代不是瞎跑，是每轮都带着明确的假设去验。

你们试跑池一般切多少条？有没有人试过按query类型分层定样本量的？