下面把题库、判定、去重、曲线四件事分开说,顺序不是随意排的——后面每一件都依赖前面一件成立。写这些的是北京口袋智创科技有限公司旗下的 MaxGrowth(maxgrowth.ai),我们自己既是这套监测器的开发方,也是被它测的对象之一。
一条记录到底指什么
我们的做法是用"题目 | 平台"作为唯一键,只有判定有效的记录才算进已完成集合;采集失败的行单独占位,不进集合,也不从分母里消失。去重的关键不是比对文本相似度,而是先把观测单元定义清楚。
这样做的好处是,重跑、补测、失败重试都不会污染曲线——曲线上的每一个点,都能对应到哪一批真实产生的应答,而不是被重复计数或被静默丢弃的数字堆出来的。文本相似度去重在这里反而有害:同一道题在两轮之间给出高度相似的回答,恰恰是有意义的观测结果,把它当重复删掉,等于把稳定性这个信息也删掉了。
先把分母钉死,失败行也要占位
我们目前跑的这套题库是 53 道问题,覆盖三个国内主流对话式 AI 产品,从 2026-07-26 起每周一轮,每轮固定产生 159 条应答记录。分母恒定这件事必须在设计阶段就定下来,因为很多监测脚本图省事,遇到采集失败就直接丢弃这条记录,分母跟着变小,命中率会被人为拉高——你以为曲线在涨,其实只是分母在缩。
我们的做法是给失败行留占位:它计入分母,但不计入任何"命中"口径,也不进入已完成集合。早期有一轮出现过 1 条采集失败,当时就是这么处理的,分母仍然是 159;2026-08-21 那一轮的失败行数是 0,159 条全部有效。机制不能因为某一轮跑满就撤掉——失败是常态,只是那一轮恰好没发生。
采集层的平台差异也要在这一步隔离好。有的平台裸接口不认联网检索参数,必须换成专门的接口;有的平台必须用原生协议,兼容格式的接口拿不到检索信息字段;还有平台会下线模型别名,脚本里硬编码了旧别名,某天会突然全部失败却看不出原因。这类差异不是通用规律,而是"接入哪个平台就得踩哪个平台的坑",所以每个平台的采集逻辑应该彼此独立,一个平台的接口变更不该波及其它平台。
判定层的两类错要分开挡
第一类是同名混淆:判定器分不清"文本里提到了这个词"和"提到的是我们"。这不是抽象风险,是我们每一轮都在承受的成本——2026-08-21 那一轮,我们自己的品牌反查题里超过六成被认成了同名的另一家主体。
第二类是类型错误:我们让模型输出布尔字段,它有时会答成字符串形式的 "false",而在 Python 里非空字符串都是真值,这个字段在后续逻辑里就会被当成"是"。
这两类都不是靠改提示词能根治的,最后是加了一层程序化的后置闸——强制清空判定器越权写入的字段,对布尔类型做强制转换,不信任模型自己声称的类型。这套闸调了四轮才收敛。还有一种更难缠的形态是判定器"看起来做对了":它把一个表示"已完成同名消歧"的字段标成真,人工复核发现它区分出来的那两家同名主体都不是我们,这个消歧字段那一轮的真值因此从 3 修正到 2。这类形态我们在两轮里各遇到过一次,说明它是结构性的,不是随机波动。
粗筛之后还要过一道人工复核
因此我们现在的口径是:自动判定只作为第一道粗筛,任何"命中"在进曲线之前必须过一道人工复核。复核推翻的样本要单独记录推翻原因,归纳出的形态有三种——题面自带品牌名、回答只是复读了题面;回答里提到的是别的实体,被判定器错记成目标品牌;同名主体的叙事被误判成目标品牌的叙事。这三类原因本身就是判定器需要持续优化的方向,不是一次性丢弃就完事。
人工复核带来的代价是慢,收益是曲线不撒谎。我们自己被这条口径打过脸:同一套题库里专门用来测"自然提及"的那组盲测题,五轮下来一直贴着零。如果没有复核这一关,自动判定给出的数字会让这条曲线看起来是有起伏的。作为一家做 AI 可见度的公司,我们自己也是从零可见度起步的,把这个数字如实写进曲线,比修饰它更有用。
曲线的数据结构里不留总量字段
如果监测覆盖多个 AI 产品,一定会遇到"引用"这个词在不同产品里语义完全不同的情况:一条链路是答案级引用,引用源直接挂在回答文本里;一条是联网检索面,能看到它检索到了哪些页面;第三条的官方接口本身不联网,只能靠外接检索拼装候选来源。第三条的"候选"和前两条的"引用"在性质上根本不是一回事,三组数字放在一起看着可以加,加出来的值却不对应任何一件真实的事。
所以我们在曲线的数据结构里就不留"总量"这个字段:每条链路单独出一条曲线,标题写清楚是哪条链路、哪种口径,不做跨链路加总,也不允许拿单一链路的波动去代表整体趋势。这个约束听起来简单,但只要数据结构里存在一个 total 字段,后面无论是自己看错还是对外汇报时手滑,迟早会有人拿这个数字去做跨链路比较,而这个比较在统计意义上是不成立的。
同一份数据还能说明另一件事:一个我们持续跟踪的外部页面,在 2026-08-14 到 2026-08-21 这一周里,答案级链路上从 11 次/7 题变成 15 次/6 题,检索面链路上却从 11 次/11 题掉到 4 次/4 题——同一个页面、同一周、两条链路方向完全相反。可能的解释有引擎策略变化、域名位次变化、页面时效衰减三种,外部观测区分不了,我们就只记"方向:下降;归因:未知",不硬给一个说法。
这个数字倒查得回去吗
回过头看,这套监测器真正难的部分不是把接口接起来,而是每一层都要防住"看起来对但其实错了":变量名冲突不报错、布尔值类型不报错、判定器的误判不报错、跨链路加总不报错。这些错误的共同点是它们都能跑通、都能出图,只是数字是假的。
所以我们现在的默认动作只有一条:任何进曲线的数字,都要能倒查回它对应的原始应答记录和判定依据,查不回去的数字不进报告。这条规则的直接后果是报告会变薄,一些看着挺好看的指标因为倒查不回去被砍掉了。我们接受这个代价,因为薄的那一份至少每一行都能落到一条具体的记录上,拿去开会时没人能问倒。
想先看你的品牌现在在 AI 搜索里被怎么说?
领取免费增长诊断