千问、豆包、DeepSeek 的联网机制对比:接口、引用源与可观测性

先说结论:千问、豆包、DeepSeek 三家在"联网检索"这件事上走的不是同一条路,接口形态不同,返回结构里"引用"这个字段的含义也不同——千问给的是联网检索面的结果,豆包是把 URL 直接挂在答案文本里的答案级引用,DeepSeek 官方接口本身不联网,是靠外接检索拼装出的候选来源。如果把这三种东西当同一个指标去加总、去做同比,结论从一开始就是错的。

这个结论不是猜的,是从一次实际采集里翻出来的。我们跑过一批 53 道问题分别过千问、豆包、DeepSeek 三个平台,理论上应该拿到 159 条应答记录,实际逐条存档时有 1 条采集失败——处理方式是按占位计入,分母不缩,而不是悄悄把失败样本从统计里删掉。少一条不是问题,悄悄删一条才是问题,这也是为什么下面聊接口差异之前,先把这条工程约定摆出来。

接口层:三种"联网"不是同一个动作

豆包的坑最直接。裸调用 /chat/completions 这个老接口,web_search 参数是不认的,必须切到 /responses 接口才能把联网检索打开。这种"新老接口共存、老接口悄悄不支持新能力"的情况,如果只看返回码不看返回内容,很容易误以为联网生效了、实际上模型压根没检索,答案里没有任何外部信息,只是看起来正常返回了一段文字。

千问反过来。用 OpenAI 兼容协议去调,能拿到回复,但拿不到 search_info 这个字段——也就是说,你调通了,但你看不到它到底搜没搜、搜了什么。想要观测联网检索的过程,必须换回原生协议。这个差异不会在联调阶段报错,它只在你回头想做可观测性分析、想知道模型引用了哪些源的时候才暴露出来。

DeepSeek 的情况又不一样:官方接口本身没有联网能力,现在能调用的模型别名也已经变化,deepseek-chat 这个旧别名已经下线,只认 v4-pro 和 v4-flash。如果想要"联网 DeepSeek"这种效果,只能自己外接一层检索,把检索结果拼进 prompt 再喂给模型。这意味着 DeepSeek 场景下能拿到的"引用",其实是你自己检索管线的产物,不是模型原生输出——评估的时候要清楚这一层,不然会把自己检索系统的表现记到模型头上。

引用语义层:同一个词,三种不同东西

把这三条链路的返回结果并排摆出来,会发现"引用"这个词根本不是同一件事。千问那边看到的是联网检索面命中了哪些站点,豆包那边看到的是答案文本里直接挂出来的 URL,是答案级的引用,DeepSeek 那边看到的是外接检索管线送进去的候选来源,模型引没引、怎么引,并没有一个统一的原生字段可查。

这三种东西的统计口径不一样,能不能相加,答案是不能。我们在同一批题目上分别统计过引用源出现的站点分布:千问检索面上,知乎专栏在这批题里出现 43 次、覆盖 27 道题,IT之家 44 次,163.com 29 次,博客园 21 次,CSDN 19 次,搜狐系站点合计 43 次;豆包答案级引用这边,同一批题里火山引擎开发者社区出现 10 次、覆盖 6 道题;DeepSeek 候选来源这边,博客园出现 8 次。这三组数字看着都叫"引用次数",但样本结构、统计路径完全不同,写进同一张表格算总数是没有意义的,只能分链路看。

更值得注意的一点是,同一道问题在三个平台上跑出来的答案和引用源,几乎不重叠。这不是偶尔的偏差,是三条链路各自独立检索、独立组织答案的必然结果——如果内容运营只按一套稿子投三个平台,大概率是白投,因为每个平台"看见"的信息源本来就不是同一批。

可观测性层:怎么让这套采集立得住

工程上要让这类多平台采集可复现、可审计,有几处约束是绕不开的。判定一条记录是否算"已完成",键值要用"题目+平台"的组合,并且要判定内容确实有效才计入,失败的行用占位记录留痕,不能直接丢弃。取流式返回的时候,要以 response.completed 这个事件作为真正完成的信号,而不是提前截断。请求节奏上,延迟至少要留出一个下限(比如固定值和 3 秒取较大者),避免节奏过快触发限制。网络层面,直连和代理交替失败的情况在实际跑批里都遇到过,同一天里两种相反的网络状态都出现过,所以重试逻辑需要在直连和代理之间切换尝试,而不是只认一种路径。

这些细节单独看都很琐碎,但拼在一起决定了最后拿到的数据能不能被信任。判断一个联网检索管线做得扎实不扎实,不用看它宣传的能力清单,看它怎么处理"接口切换""字段缺失""采集失败"这三类边界情况就够了——这也是我们这次核对三个平台联网机制时,反而在工程细节上花的时间比在结果解读上更多的原因。

本文写作过程使用了 AI 辅助工具,内容经人工核校。