2026 年 7 月末至 8 月初
同一个问题，豆包 App 和 API 给出的信源重叠只有 1.3%
同题同问、逐题对齐比较豆包 App 实测与搜索 API 的实际引用源：URL 层池化重叠 1.3%，域名层 21.8%。API 采样不能替代真实用户环境的实测。
境迅研究团队
一个问题
做 AI 可见性监测,有两条取数路径。一条是在真实用户环境里逐题提问、逐题记录,慢、贵、难自动化;另一条是调用平台的搜索 API,快、便宜、可批量。
市面上多数监测工具走第二条。这引出一个必须回答的问题:API 采样能不能替代 App 实测?两侧看到的是不是同一个信源池?
数据与口径
- 设计:同题同问。一侧取自豆包 App 的真实用户环境实测记录,另一侧以同一批原题文本调用同平台的搜索 API,逐题对齐比较。
- 可比样本:两侧均给出引用的题目,逐题对齐;题量不对外披露。
- 比较口径:两侧均取"答案中实际引用的源 URL",不是检索池全量——API 侧的检索池不可获取,而对"能不能替代"这个问题,引用层就是有效层。
- 比较层面:URL 层(具体篇目)与域名层(同一网站)分别统计池化重叠率。
- 时间:两侧执行间隔 7 天,分别在 2026 年 7 月末与 8 月初。
发现
| 比较层面 | 池化重叠 |
|---|---|
| URL 层(具体篇目) | 1.3% |
| 域名层(同一网站) | 21.8% |
落到具体篇目,两侧几乎不重合。域名层还有约五分之一的交集,说明两者在相似的公网生态里检索;但 URL 层只有 1.3%,说明它们各自检索、各自排序,不共享同一个索引与排序结果。
最硬的一项单点证据:App 侧第一大引用源,在 API 侧一条都没出现。该平台自家短视频内容池在 App 侧是被引用最多的来源,而在 API 侧——即便显式配置了对应的内容源——产出为零。这意味着 App 大量消费的那部分内容,在 API 形态下不可达。
时间差解释被排除。两侧相隔 7 天,自然会有信源漂移。但同一平台 App 自身在相邻两轮测量之间的信源留存率在 45%–67% 区间——如果两者同源,7 天的漂移最多把重叠压到那个量级附近,压不到 1.3%。时间差不足以解释这个结果。
另有一项辅助观察:两侧的引用密度差异明显,App 侧一次回答给出的引用数量是 API 侧的数倍。
结论
API 采样不能替代真实用户环境的实测。两侧看到的不是同一个池子——用 API 数据向管理层汇报"用户在 AI 里看到了什么",汇报的不是同一件事。
这也是境迅的监测系统坚持走真实用户环境的原因。API 采样便宜、快、可自动化,唯独不能回答这个问题——它看到的不是用户看到的那个池子。
局限声明
- 单平台、单次实验。只在一个平台上做过一次,不外推到其他平台。其他平台的 App 与 API 是否同源,需要各自验证。
- 样本量受限。计划题量未跑满,实际以两侧均有引用的可比题出结论。URL 层 1.3% 的量级差距远超样本误差可解释的范围,但域名层的 21.8% 精度较低。
- 两侧模型不同。API 侧调用的模型与 App 线上模型不是同一个,引用密度的差异部分可归因于此。但"检索不到某个内容池"属于检索层差异,模型解释不了。
- 实测对象是该平台的联网检索接口,不是其独立的搜索产品。严格表述:本实验证明的是"App 与该接口不同源";推广到"App 与该平台全部 API 形态不同源"属于推断,不是直接实证。
- 口径为引用层而非检索池。若在检索池层面重叠更高而引用层不同,结论会缓和——但对"能否用 API 代理 App 测量"这个运营问题,引用层就是有效层。