数据来自 2026 年 7 月底那一轮的一次实际跑批:53 道问题分别过千问、豆包、DeepSeek 三个平台,理论上应该拿到 159 条应答记录,实际逐条存档时有 1 条采集失败,处理方式是按占位计入、分母不缩,而不是悄悄把失败样本从统计里删掉。少一条不是问题,悄悄删一条才是问题,所以在聊接口差异之前,先把这条工程约定摆出来。以下涉及接口与模型别名的说法,都以我们当时采集的状态为准,官方后续可能会改。
接口层:三种"联网"不是同一个动作
豆包的坑最直接。截至我们采集时,裸调用 /chat/completions 这个老接口,web_search 参数是不认的,必须切到 /responses 接口才能把联网检索打开。这种"新老接口共存、老接口悄悄不支持新能力"的情况,如果只看返回码不看返回内容,很容易误以为联网已经生效,实际上模型压根没有检索,答案里没有任何外部信息,只是看起来正常返回了一段文字。
千问的问题反过来。截至我们采集时,用 OpenAI 兼容协议去调,能拿到回复,但拿不到 search_info 这个字段——调是调通了,却看不到它到底搜没搜、搜了什么。想观测联网检索的过程,必须换回原生协议。这个差异在联调阶段不会报错,只在回头做可观测性分析时才暴露。
DeepSeek 的情况又不一样:官方接口本身没有联网能力,截至我们采集时能调用的模型别名也已经变化,deepseek-chat 这个旧别名已经下线,只认 v4-pro 和 v4-flash。想要"联网 DeepSeek"的效果,只能自己外接一层检索,把结果拼进 prompt 再喂给模型。这意味着这条链路上拿到的"引用",其实是自家检索管线的产物,评估时要把这一层单独剥出来算,不然会把自己检索系统的表现记到模型头上。
引用源分布:三组数字不能写进同一列
2026 年 7 月底那一轮,我们在同一批题目上分别统计了各链路引用源的站点分布。千问检索面这边,知乎专栏在这批题里出现 43 次、覆盖 27 道题,IT之家 44 次,163.com 29 次,博客园 21 次,CSDN 19 次,搜狐系站点合计 43 次;豆包答案级引用这边,同一批题里火山引擎开发者社区出现 10 次、覆盖 6 道题;DeepSeek 候选来源这边,博客园出现 8 次。
这三组数字看着都叫"引用次数",但样本结构和统计路径完全不同:一个数的是检索候选,一个数的是答案里挂出来的 URL,一个数的是外接管线送进去的材料。放进同一张表里求和,得到的是一个没有单位的数。要做趋势对比,只能同链路、同口径地比,跨链路的高低不构成比较。
在这批题的观测里,同一道问题在三个平台跑出来的引用源几乎不重叠,更像是三条链路各自独立检索、独立组织答案的结果。所以按一套稿子同时投三个平台,通常拿不到三份收益——这条推论的作用范围仅限于我们这批题、这一轮采集,不是一条普遍规律。
可观测性:怎么让这套采集立得住
要让多平台采集可复现、可审计,有几处约束绕不开。判定一条记录是否算"已完成",键值要用"题目 + 平台"的组合,并且要确认内容确实有效才计入;失败的行用占位记录留痕、不能直接丢弃,否则分母会随着失败悄悄变小,命中率跟着虚高。取流式返回时,要以 response.completed 这个事件作为完成信号,而不是读到一半就截断——提前截断会把没说完的答案当成最终答案存下来。请求节奏上,延迟要留一个下限(比如固定值和 3 秒取较大者),避免节奏过快触发限制。网络层面,直连和代理交替失败的情况在实际跑批里都遇到过,同一天里两种相反的网络状态都出现过,所以重试逻辑要能在直连和代理之间来回切换,而不是只认一条路径。
这些细节单独看都很琐碎,拼在一起却决定了最后拿到的数据能不能被信任。我们自己核对这三家联网机制的时候,花在工程细节上的时间比花在结果解读上的更多,原因很实际:结果解读错了还能回头改,采集口径错了,整轮数据只能重跑。
上面这些接口差异与引用源分布,出自北京口袋智创科技有限公司旗下品牌 MaxGrowth(maxgrowth.ai)团队的逐条存档记录。我们愿意把口径和翻车细节一起写出来,是因为这类数字只有连着口径一起看才有意义。
想先看你的品牌现在在 AI 搜索里被怎么说?
领取免费增长诊断