Live 与 sampled:我们如何标注每一条 AI 回答
AI 可见性指标要可信,来源必须可查。一次运行何时算 live、何时算 sampled、以及为什么聚合会混算——本文说清楚。
如果一个工具告诉你「ChatGPT 有 38% 的时候提到你」,第一个问题应该是: 你怎么知道的? 让 LLM 模拟回答引擎是合理的度量手段——但它不等于查询 消费者产品;假装等同,仪表盘就开始说谎。
所以 AIEO.ee 给每一条运行都打标签,而且这个标签本身就是产品。
两个标签
live 是挣来的,不是配置出来的。 三个引擎支持真实 AI 搜索后端——
ChatGPT 走 OpenAI web search、Perplexity 走直连 Sonar API、Google AI
Overview 走 Gemini grounding。但配置了 key 不够:只有后端实际返回了
搜索证据的那次运行才算 live。一次 live 调用如果回来时没有 grounding,
自动降级为 sampled。live 运行的引用是后端真实取回的来源。
sampled 是其余一切:没有 live 后端的引擎、key 未配置的 live 引擎、
或没有搜索证据的 grounding 调用。LLM 给出它对「回答引擎会怎么说」的最佳
估计。这是方向性信号——有用、可随时间追踪——但显然不是对消费者产品的
测量。我们从不把它当作测量来呈现。
在哪里能核验标签
- run 列表的每一条运行——原始回答与来源齐备。这份列表就是审计线索: 任何聚合数字都能回溯到带标签的运行。
聚合数字——summary、share of voice、趋势序列与分引擎明细——目前把 live 与 sampled runs 混在一起,今天没有来源筛选。
标签在哪里混合
如果你的 mix 以 sampled 为主,38% 的 SOV 就比建立在 live runs 上的 38% 更弱——我们认为你应该在内部引用之前知道这一点。
为什么不静默筛选?替你决定「什么算数」是同一个不诚实,只是换了个方向。 按来源拆分的视图在路线图上;在那之前,重要的事请对着带标签的 run 列表 核验。
实践建议
- 给支持的引擎配置 live key——数字会实质变强。
- 当一次运行重要(报告、决策)时,点开核对标签。
- sampled 的趋势当方向看;只有 live 才配称为「测量」。
数据来源页面逐引擎写清了完整矩阵。