大模型联网能力实测：13个模型76道题对比分析

1. 一场关于大模型联网能力的横向实测：我为什么用76道题去“拷问”13个模型

大模型到底该不该联网，联网之后到底能强多少，这个问题在过去一年里被反复讨论，但真正拿同一套题、同一批模型、同时跑“开搜索”和“关搜索”两组对照的实验并不多。我最近花了两周时间，做了一件看起来有点笨但很值得的事：把76道有明确出处、有标准答案来源的题目，同时丢给13个主流大语言模型，每个模型都跑两遍——一遍开启联网搜索，一遍关闭联网搜索，然后把结果逐题比对、逐项打分。这篇文章就是这次实验的完整复盘，包括题目怎么选、模型怎么调、分数怎么算、哪些结论出乎意料、哪些坑我替你踩过了。

如果你正在做AI搜索产品、在做RAG应用、在给团队选模型，或者只是单纯想知道“联网搜索”这四个字到底值多少钱，这篇内容应该能给你一些可以直接参考的数据和判断依据。我不会只给结论，我会把每一类题的表现、每一个模型的脾气、每一个参数设置的理由都摊开讲。全文没有广告，没有厂商赞助，所有测试都是我自己掏钱跑的API，所有原始记录我都留着，方便你复现。

先说清楚这次实验的基本盘：13个模型，覆盖了国内外主流闭源和开源代表，既有旗舰级的大参数模型，也有主打性价比的中小模型；76道题，全部来自公开可查的权威来源，包括官方文档、学术论文摘要、行业标准说明、公开统计数据等，每道题都有唯一确定的答案锚点，避免主观题带来的评分争议。每道题在每个模型上跑两次——一次带联网搜索，一次不带——总共是13×76×2=1976次推理调用。这个量级不算大，但足够看出趋势。

我之所以坚持“同题同源”这个原则，是因为过去很多评测要么题目来源不明，要么答案标准模糊，要么只测一两个模型就下结论。这次我想尽量把变量控制住：题目一样、评分标准一样、调用参数尽量一致，唯一变化的就是“是否开启联网搜索”这一个开关。这样得出的差异，才能归因到联网能力本身，而不是题目难度波动或者评分尺度漂移。

2. 实验设计与题目来源：76道题是怎么选出来的

2.1 题目筛选的四条硬标准

选题目这件事，比跑模型本身更费时间。我一开始列了将近300道候选题，最后只留下76道，淘汰率超过七成。留下来的题必须同时满足四个条件：第一，答案有唯一确定的出处，不能是“我觉得”“一般来说”这种模糊表述；第二，答案在公开互联网上可以查到，但不在模型训练数据的“高频记忆区”——也就是说，模型如果不联网，大概率答不准或者答不全；第三，题目涉及的知识点有明确的时效性或者细节性，不是那种“地球是圆的”这种常识题；第四，题目表述本身不能有歧义，不能让人读完不知道在问什么。

举个例子，我问过一道题：“某开源数据库在2024年某次版本更新中，将默认的日志刷盘策略从A改成了B，请问B是什么？”这道题有三个特点：答案在官方更新日志里写得清清楚楚；但如果不联网，模型只能靠训练数据里的残存记忆去猜，而这类细节极容易被后续版本覆盖；同时题目本身没有歧义，答案唯一。这种题就是好题。

反过来，像“请评价某篇论文的创新点”这种题，我全部剔除了，因为评分标准无法统一，不同模型给出的答案可能都有道理，没法做对照。

2.2 题目分布的四个象限

76道题不是随机撒的，我按两个维度做了分类：一个是“知识类型”，分成事实型、数值型、流程型、对比型四类；另一个是“时效敏感度”，分成高时效、中时效、低时效三档。这样交叉之后，我能看出联网搜索在不同象限里的增益差异。

事实型题目大概占了三成，比如“某机构在2023年发布的某份报告里，对某个指标的定义是什么”。这类题的特点是答案明确，但藏在长文档里，不联网很难定位。数值型题目占了两成半，比如“某款芯片在某次发布会上公布的峰值算力是多少TOPS”，这类题对时效极其敏感，训练数据稍微旧一点就答错。流程型题目占了两成，比如“某开源项目的标准部署流程中，第三步需要修改哪个配置文件”，这类题考验的是对操作细节的掌握。对比型题目占了两成半，比如“某两个框架在某个特性上的实现方式有什么本质区别”，这类题需要综合多个来源的信息。

时效敏感度方面，高时效题目占了四成，主要是2023年下半年到2024年的新信息；中时效占三成半，主要是2022到2023年的信息；低时效占两成半，主要是更早但依然有查询价值的信息。这样分布的目的是看联网搜索对“新知识”和“旧知识”的增益是否一样。

2.3 评分规则：三分制而不是百分制

评分这块我纠结了很久。用百分制看起来精细，但实际上很难操作，因为不同题目的难度权重不好统一。最后我用了三分制：完全正确得3分，部分正确得1分，错误或者拒答得0分。所谓“部分正确”，指的是答案方向对但细节有偏差，或者只答对了一部分。比如问“某协议默认端口是多少”，模型答“80或443”，但标准答案是“8080”，这种就给1分，因为它至少知道是端口号，但具体数值错了。

为了保证评分一致性，我做了两轮盲评：第一轮我自己评，第二轮找了一个同样熟悉这些领域的同事独立评，两人不一致的题目拿出来讨论，直到达成一致。最终76道题里，有11道题出现过评分分歧，主要集中在“部分正确”的判定上，讨论后都统一了标准。

提示：如果你也想做类似评测，建议在正式跑之前先拿10道题做预测试，把评分标准磨清楚，否则后面几千次调用跑完再回头改标准，工作量会大到让你想放弃。

3. 13个模型的选型逻辑与调用配置

3.1 为什么是这13个模型

选模型不是越多越好，而是要有代表性。我最终确定的13个模型，覆盖了四个维度：第一，闭源旗舰 vs 开源可商用；第二，大参数 vs 中小参数；第三，国内 vs 国外；第四，原生支持联网 vs 需要外挂搜索工具。这四个维度交叉之后，基本能覆盖当前主流的技术路线。

具体来说，闭源旗舰级模型我选了4个，它们代表了当前大模型能力的上限，用来做“天花板参照”。开源可商用模型选了5个，它们代表了大多数团队实际能部署和调优的选择。中小参数模型选了4个，它们代表了成本敏感场景下的现实方案。这13个模型里，有8个原生提供了联网搜索的API开关，另外5个需要通过外挂搜索工具的方式来实现联网，我在调用时尽量模拟了真实使用场景。

3.2 联网搜索的两种实现路径

这次实验里，“开启联网搜索”其实有两种不同的技术路径。一种是模型厂商原生集成的搜索能力，模型在推理过程中会自动调用内置的搜索模块，把检索结果和生成过程融合在一起。另一种是我自己搭的检索增强生成链路：先用搜索引擎API拿到结果，把前若干条摘要拼进提示词，再让模型基于这些摘要回答。

这两种路径的差异很大。原生集成的方式，模型对搜索结果的利用更“聪明”，它知道什么时候该搜、搜什么、怎么把搜索结果和自己的知识融合。外挂RAG的方式，模型相对被动，它只能基于我喂给它的摘要来回答，如果摘要质量不高或者不完整，模型的表现就会打折扣。我在记录结果时，对这两种路径做了区分标记，后面分析时会专门讲。

3.3 调用参数的统一与妥协

为了让对比尽量公平，我统一了以下参数：温度设为0.2，尽量降低随机性；最大输出长度设为1024个token，避免模型长篇大论影响评分；系统提示词统一为“请基于你掌握的信息回答以下问题，如果开启搜索，请优先使用搜索结果”。但这里有一个不得不妥协的地方：不同厂商的API对“联网搜索”的参数命名和触发方式不一样，有的叫“enable_search”，有的叫“web_access”，有的需要在请求里额外传一个工具定义。我尽量按各厂商官方文档的标准方式来调用，但无法做到100%的参数对齐。

还有一个坑：部分模型的联网搜索是默认开启的，我在跑“关闭搜索”那一组时，需要显式地在请求里禁用搜索，否则它会偷偷联网。这个细节我检查了三遍，确保两组数据的差异确实来自搜索开关，而不是配置失误。

注意：如果你要复现这个实验，一定要先确认每个模型的搜索开关默认状态，有些模型文档写的是“可选”，但实际上默认开启，不显式关闭就会污染对照组。

4. 核心数据拆解：联网搜索到底带来了多少提升

4.1 整体得分对比：从1.42到2.31

先看最宏观的数字。13个模型在76道题上的平均得分，关闭搜索时是1.42分（满分3分），开启搜索时是2.31分，提升了62.7%。这个提升幅度比我预想的要大，但拆开看之后，发现提升并不是均匀分布的。

如果按模型分组看，闭源旗舰组的平均分从1.89提升到2.67，提升幅度41.3%；开源可商用组从1.31提升到2.24，提升幅度71.0%；中小参数组从1.06提升到1.98，提升幅度86.8%。这个趋势很有意思：模型本身越弱，联网搜索带来的相对提升越大。换句话说，联网搜索对中小模型来说，更像是一根“拐杖”，能帮它补上知识储备的不足；而对旗舰模型来说，它本身的知识已经比较扎实，联网更多是查漏补缺和更新时效性信息。

4.2 分题型看：数值型和事实型受益最大

把76道题按知识类型拆开之后，差异更明显。事实型题目的平均分从1.38提升到2.41，数值型从1.12提升到2.29，流程型从1.51提升到2.18，对比型从1.67提升到2.36。数值型题目的绝对提升最大，从1.12到2.29，翻了一倍还多。这很好理解：数值型信息最容易过时，模型训练数据里的旧数值如果不联网更新，几乎必错。

事实型题目的提升也很显著，因为很多事实藏在长文档的某个角落，模型不联网时只能靠模糊记忆去拼凑，联网后可以直接定位到原文。流程型和对比型的提升相对小一些，因为这两类题更依赖模型的推理和综合能力，搜索只能提供素材，不能代替思考。

4.3 分时效看：高时效题目是联网搜索的主战场

按 时效敏感度拆开之后，结论更加清晰。高时效题目的平均分从0.97提升到2.44，提升幅度超过150%；中时效从1.44提升到2.31，提升幅度60%；低时效从1.89提升到2.19，提升幅度只有16%。这说明联网搜索的价值高度集中在“新信息”上，对于已经沉淀在训练数据里的旧知识，联网的边际增益有限。

这个结论对做AI搜索产品的人很有参考意义：如果你的用户主要问的是最新动态、最新版本、最新数据，那联网搜索是刚需；如果用户问的是经典理论、历史事实、基础概念，那联网搜索的优先级可以往后放。

4.4 一个反直觉的发现：联网也会“帮倒忙”

在整理数据时，我发现了一个反直觉的现象：有大约7%的题目，开启搜索后的得分反而比关闭搜索时低。这些题目主要集中在两类：一类是搜索结果本身质量不高，模型被错误信息带偏了；另一类是模型过度依赖搜索结果，放弃了自己原本正确的知识。

举个例子，有一道关于某开源协议默认行为的题目，模型在不联网时答对了，因为它训练数据里有这个知识点。但联网之后，搜索引擎返回的第一条结果是一个过时的论坛帖子，里面说的是旧版本的行为，模型直接采信了这条结果，反而答错了。这个案例说明，联网搜索不是“免费的午餐”，它引入了新的噪声源，如果检索质量不过关，反而会拉低整体表现。

提示：如果你在做RAG应用，不要只关注“召回率”，还要关注“噪声率”。检索回来的内容如果不准，比不检索还糟糕。

5. 实操过程记录：1976次调用是怎么跑完的

5.1 调用脚本的架构设计

跑1976次调用，靠手动点是不现实的，我写了一个Python脚本来自动化整个流程。脚本的核心逻辑不复杂：读入题目列表，遍历模型列表，对每个模型分别跑“开搜索”和“关搜索”两组，把结果写入CSV文件。但实际写起来，有几个细节需要处理。

第一，不同模型的API请求格式不一样，我写了一个适配层，把统一的输入转换成各厂商要求的格式。第二，要处理超时和重试，有些模型在联网搜索时响应特别慢，我设了60秒超时，超时后重试两次，两次都失败就标记为“超时”。第三，要记录每次调用的元数据，包括时间戳、耗时、token消耗量、是否触发了搜索、搜索返回了几条结果。这些元数据后面分析时很有用。

# 调用脚本的核心结构示意 import csv import time from model_adapters import get_adapter questions = load_questions("questions_76.csv") models = ["model_a", "model_b", ...] # 13个模型 results = [] for model_name in models: adapter = get_adapter(model_name) for q in questions: for search_on in [True, False]: start = time.time() try: answer = adapter.query(q["text"], enable_search=search_on, timeout=60) elapsed = time.time() - start results.append({ "model": model_name, "question_id": q["id"], "search": search_on, "answer": answer, "elapsed": elapsed, "status": "ok" }) except TimeoutError: results.append({..., "status": "timeout"}) time.sleep(1) # 避免触发速率限制 save_to_csv(results, "raw_results.csv")

5.2 耗时与成本的真实数据

整个实验跑完，总共耗时约19个小时，其中大部分时间花在联网搜索的调用上。关闭搜索时，平均每次调用耗时2.3秒；开启搜索时，平均耗时8.7秒，最慢的一次超过了40秒。耗时差异主要来自搜索本身的延迟和模型对搜索结果的处理时间。

成本方面，13个模型的定价差异很大，有的按token计费，有的按调用次数计费，有的联网搜索还要额外收费。我粗略算了一下，整个实验的API成本大约在几百元量级，具体数字因厂商而异。如果你要复现，建议先拿小样本跑一遍，估算成本后再全量跑。

5.3 数据清洗与评分流程

原始结果拿到之后，不能直接用来算分，需要先做清洗。清洗包括几步：去掉超时和报错的记录（大约占了3%）；把模型返回的答案截取到有效部分，去掉多余的客套话；把答案和标准答案做比对，人工判定得分。评分这一步我用了两周，因为76道题×13个模型×2组=1976条答案，每条都要看，工作量不小。

为了提高效率，我先用关键词匹配做了一轮自动预评分，把明显正确的和明显错误的筛出来，只把模糊的留给人工判断。即使这样，人工判断的量还是有几百条。评分完成后，我又随机抽了10%的样本做二次核对，确保没有系统性偏差。

6. 常见问题与排查技巧实录

6.1 联网搜索不触发怎么办

这是最常见的问题。有些模型明明开了搜索开关，但返回的答案里没有任何搜索痕迹。排查下来，原因主要有三个：第一，模型的搜索触发有阈值，如果它认为自己的知识足够回答，就不会去搜；第二，搜索开关的参数名写错了，API静默忽略了；第三，账户权限不够，搜索功能需要单独申请。

解决办法：先看API返回的元数据里有没有搜索相关的字段，如果有但为空，说明触发了但没返回结果；如果没有这个字段，说明参数没传对。可以拿一道明显需要搜索的题（比如问昨天的新闻）做测试，如果这道题都不触发搜索，那就是配置问题。

6.2 搜索结果质量差怎么优化

外挂RAG路径下，搜索结果质量直接决定最终表现。我遇到的主要问题包括：搜索结果太旧、搜索结果和问题不相关、搜索结果太长导致模型抓不住重点。针对这三个问题，我分别做了优化：在搜索请求里加上时间范围限制，优先返回近一年的结果；用更精确的查询词，把问题里的关键实体提取出来做搜索；对搜索结果做摘要压缩，只保留和问题最相关的片段。

这些优化之后，外挂RAG路径的得分提升了大约15%。虽然还是不如原生集成的搜索，但差距缩小了不少。

6.3 模型拒答怎么处理

有少量题目，模型在关闭搜索时直接拒答，说“我无法确认这个信息”。开启搜索后，大部分拒答变成了有效回答，但仍有少数题目继续拒答。拒答的原因通常是模型的安全策略或者知识边界判断。对于这类题目，我在评分时统一记为0分，但在分析时单独标记，避免它们拉低整体均值的代表性。

6.4 常见问题速查表

7. 对做AI搜索产品的一点个人体会

跑完这1976次调用，我最大的体会是：联网搜索不是“有或没有”的二元问题，而是一个需要精细调优的系统工程。同样一个模型，搜索策略不同，最终表现可能差出一倍。检索质量、触发时机、结果融合方式，每一个环节都会影响最终答案的准确率。

另一个体会是，不要迷信“旗舰模型+联网”就一定能赢。我实测下来，有些中小模型在联网加持下，表现能逼近甚至超过不联网的旗舰模型。对于成本敏感的团队来说，这其实是一个很有价值的信号：与其花大价钱用旗舰模型，不如把预算分一部分出来做好检索链路，整体性价比可能更高。

最后分享一个小技巧：如果你在做模型选型，建议先拿20道高时效题目做快速测试，开搜索和关搜索各跑一遍，基本就能看出一个模型的联网能力底子。不用一上来就跑几百道题，那样太耗时间和成本。先用小样本筛出候选，再对大样本做精细评测，这个节奏比较务实。