ARTICLE · 1324354

五家AI搜索 API 实测:问文档和问政策,不该用同一家

发布时间：2026-11-07 07:47:15 最近访问：2026-11-07 07:47:16

给 Agent 接搜索，一开始我的标准很朴素：能返回结果就行。直到它写一篇 AI 监管的稿子，引了三条百家号，点开全是同一篇营销稿的变体——我才意识到，"有结果"和"有可用来源"是两件事。

于是我把同一批 query 打给五家AI搜索 API，跑了两轮。排榜单没什么意义，我想搞清楚的是：当我让 Agent 去查一件事时，它到底从哪拿答案。

▍一、先破一个认知：返回 8 条，不等于 8 个来源

现在这些 API 几乎都会把 count 填满。13 条 query、五家源、两轮下来，只要不报错，返回数基本都是 8 条。看起来都很"能干"。

但问"2026年11月中国 CPI 同比数据"，百度给的 8 条里，有 4 条是同一篇《2026年11月资产配置报告》在不同站点的转载，跟 CPI 没有关系。问 Mac Studio 规格，DeepSeek 的前三条是同一张 Apple 支持页面，分别来自澳洲、印尼、希腊的区域版本——内容没错，但三个位置只提供了一条独立信息。

返回条数是个伪指标。 真正该看的是：命中几个一手源、有几个不同的站点、两轮之间结果稳不稳。

▍二、怎么测的

被测的五家：Brave、Tavily、Parallel、百度千帆、DeepSeek。前四家原本就在我的接入池里，DeepSeek 是 2026 年 10 月才开放的独立搜索接口，按成功请求 $0.75/1000 次计费，不烧模型 token。

我自建了一个聚合服务，平时 /search 是链式短路——第一个源命中就返回。评测必须绕开这个逻辑，让每条 query 真正并发打到每一家：

docker run --rm --network host --env-file .env -e TZ=Asia/Shanghai \
  -v "$PWD:/app" -w /app jim-search:latest \
  python scripts/eval_providers.py --top 8

13 条 query，中英文各半，覆盖五类需求：时效数据、中文政策、官方文档、硬件规格、购物评测。每家每轮 top=8，两轮间隔约 8 小时，共 130 次有效调用。

有个细节必须先说清楚，否则延迟表会看歪：所有请求都先进入本机 Clash，再按规则分流。抓 Clash 的 /connections 能看到：

源	实际出口
Brave / Tavily / Parallel	美国节点
百度 / DeepSeek	DIRECT（命中 GEOIP,CN 规则）

所以 0.3 秒和 4 秒的差距里，混着国际链路和代理开销。这是国内网络下的真实体验，但不是厂商 API 的纯响应时间——拿它跟官方 benchmark 比没有意义。

▍三、数据：延迟、稳定性、互补性

源	两轮平均延迟	两轮自重合	权威域占比	单次成本
DeepSeek	362 / 403ms	0.97	23%	$0.00075
百度	893 / 552ms	1.00	15%	¥0.036（100 次/天免费）
Brave	2654 / 2631ms	0.78	22–23%	$0.005
Parallel	3565 / 2621ms	0.73	37–43%	按 credit
Tavily	3816 / 4397ms	0.63	28%	$0.008

"两轮自重合"是同一个 query 两次结果 top8 URL 的 Jaccard。百度 1.00，因为它基本是确定性索引；DeepSeek 0.97；Tavily 只有 0.63——早上问和晚上问，来源会换掉三分之一以上。

"权威域占比"是结果落在 gov.cn / edu.cn / wikipedia / github / 官方文档站的比例，只是个粗糙代理，不是质量评分。成本按各家公开价目折算，额度以官方为准。但它能解释一件事：为什么 Parallel 慢，我还留着它——英文官方文档题它首屏就给你官网。

再看互补性。五家两两 Jaccard 最高只有 0.13（Brave–Tavily），多数组合 ≤0.05，百度和 DeepSeek 同为中文源，重合度是 0.00：

	Brave	Tavily	Parallel	百度	DeepSeek
Brave	-	0.13	0.05	0.01	0.02
Tavily	0.13	-	0.06	0.01	0.01
Parallel	0.05	0.06	-	0.00	0.01
百度	0.01	0.01	0.00	-	0.00
DeepSeek	0.02	0.01	0.01	0.00	-

这就是多源并存的全部理由：没有任何一家能同时覆盖中英文、官方文档和社区讨论。

▍四、分场景看，差距比总表更明显

CPI 数据题

只有 Parallel 把国家统计局的原发布页放在前两位，Tavily 第三位也命中统计局，但被商业站压住。百度前五全是财经自媒体。DeepSeek 给的是 investing.com 和一份带预测区间的研报——不算错，但不是一手数据。

AI 监管新规

DeepSeek 首条就是 cnis.ac.cn 的 GB/T 47863-2026 国标全文解读，第二条是工信部加强智能体终端进网管理。Parallel 给财新和发改委的立法口径。百度第三条是"金融贷后催收新规"——"新规"这个词被它按泛新闻处理了。

英文官方文档（PostgreSQL 18）

Brave、Tavily、Parallel、DeepSeek 首屏全是 postgresql.org。DeepSeek 用 438ms 做到这个结果，代价是 18.0 / 18.1 / 18.3 三个版本各占一条。百度一条官网都没有，全是二手解读。

购物评测

Brave 给 RTINGS、Tom's Hardware、PCMag；百度给抖音带货和阿里商品页。不是谁好谁坏，是索引的意图完全不同。

这些样本说明一件事：搜索源的差异，说到底在"默认给你什么"。默认给营销稿的源，你加多少关键词都救不回来。

▍五、结论：不同类型，用不同的源

最后我没选"最好的一家"，也没搞平均轮转。轮转解决的是"额度用不完"，路由解决的是"这次问的是什么"——两件事。

按上面的实测，源该按类型分工：

查询类型	首选	备选	实测依据
英文官方文档 / API / 版本	Parallel	Brave	首屏命中 postgresql.org、playwright.dev，权威域 37–43%
英文评测 / 购物 / 新闻	Brave	Tavily	RTINGS、Tom's Hardware、PCMag 直接出现在首屏
中文政策 / 时政 / 标准	DeepSeek	百度	国标全文（cnis.ac.cn）、工信部动作，362ms
中文技术 / 社区 / 百科	百度	Brave	知乎、CSDN、百科覆盖；代价是来源偏软
时效统计 / 数据	Parallel	Tavily	CPI 题把国家统计局原发布页放在前两位

判断类型不需要模型：先看语言，再看意图词（release notes / specs / review / 政策 / 标准 / 同比）。命中不了就退回默认顺序，不硬猜。剩下的源按这条顺序兜底：

environment:
- JIM_SEARCH_ROUTING=true                  # 按类型选链首
- JIM_SEARCH_PROVIDER_ORDER=brave,tavily,parallel,baidu,deepseek  # 补齐/兜底顺序
- JIM_SEARCH_FALLBACK_PROVIDERS=deepseek   # 主链全失败后的兜底位
- JIM_SEARCH_LOG_DIR=/app/logs             # 每次请求落 JSONL

这张表是 13 条 query 逼出来的，不是通用配方。换行业、换语言，得重新跑一轮。

搜索与抓取仍然分离：/search 只出 title/url/snippet，正文按需 /scrape，不为"可能不看"的页面付抓取成本。

但真正让我敢调源顺序的，是那次顺手加的请求记录。每次搜索都会落一行 JSONL，路由名、每个源的耗时和条数、命中链、完整结果都在里面。这是线上 /search 链式请求的真实日志：

{"ts":"2026-11-06T23:57:05.829","query":"Apple M5 Ultra Mac Studio specs",
"route":"en_docs",
"chain_planned":["parallel","brave","tavily","deepseek","baidu"],
"attempts":[{"provider":"parallel","ms":2648,"count":3}],
"chain_used":["parallel"],"elapsed_ms":2648,"result_count":3,
"results":[{"rank":1,"title":"Mac Studio - Technical Specifications - Apple",
"url":"https://www.apple.com/mac-studio/specs/"}]}