大模型联网搜索的短板与突破之路

大模型联网搜索的功能，是指大模型通过实时的进行互联网搜索来获取实时信息，然后做出更准确和合理的回复；联网搜索的功能，主要是为了弥补大模型预训练知识库存在时效性导致实时知识滞后性的问题，可以认为是一种额外的工具，帮助大模型获取实时信息后，作为输入传入给大模型，大模型再结合额外的信息做出回复；比较常见的联网搜索功能的场景有当前时间、天气、新闻、商品价格等受实时因素影响大的场景，这些细节凭大模型本身的知识库无法回答或是回答不准确，就需要借助外部工具-联网搜索；

例如以下是一个大模型用联网搜索实时天气的典型例子：

 

在这一“当天天气”的问答中，这个问题可以拆分成两个子问题，“今天是什么日期，星期几”和“杭州这个日期的天气情况”；很明显，这两个实时性问题凭大模型自己的知识库无法回答，大模型会使用联网搜索进行回答；

联网搜索，本质上是一个 工具函数 ，而工具函数是大模型智能体（Assistant API）中重要的大模型外部知识能力，用户可以通过自定义的工具函数，让大模型实现用户想要实现的 自定义操作 ，只需通过用户输入的指令，大模型会选择合适的工具执行，例如以下的这个简单的翻译工具函数，我自定义一个实现翻译功能的工具函数translate_text，然后封装成大模型tool的形式，其中包括函数名（name）、描述(description)、入参数(properties)，其中描述是大模型选择是否使用这个工具的标准；然后当输入大模型的提问中包含了翻译相关的指令，大模型认为输入指令和这个翻译工具的描述相近，就会启用这个tool，实际执行translate_text的结果，输出翻译后的文本；

##定义一个工具函数def translate_text(text, target_language):    """    将文本翻译成指定的目标语言。    这是一个使用预定义翻译的简单演示。
    参数：        text (str): 需要翻译的文本        target_language (str): 目标语言代码（例如：'zh'、'es'、'ja'）
    返回：        str: 翻译后的文本或错误信息    """##定义工具的调用方式和参数规范translation_tool = {    "type": "function",    "function": {        "name": "translate_text",        "description": "将文本翻译成指定的目标语言",        "parameters": {            "type": "object",            "properties": {                "text": {                    "type": "string",                    "description": "需要翻译的文本"                },                "target_language": {                    "type": "string",                    "description": "目标语言代码（例如：'zh'、'es'、'ja'）"                }            },            "required": ["text", "target_language"]        }    }}# 创建 Assistantassistant = Assistants.create(    model='qwen-plus',    name='翻译助手',    description='一个能够在不同语言之间进行文本翻译的助手',    instructions='你是一个翻译助手。当用户请求翻译时，使用 translate_text 函数来帮助他们。',    tools=[translation_tool])

从流程角度来考虑，用户输入一个问题，大模型会先根据 问题和工具描述的相似度 判断是否需要调用工具，如果判断无需工具，那么直接根据大模型本身的知识库去回答问题；如果判断需要调用工具，那么会从问题中 提取出工具函数的入参数 ，然后执行工具函数，得到函数结果再整合进大模型中，在给出回答； 

 

再回到联网搜索的工具，逻辑类似，联网搜索本质上也是一个工具，这个工具要实现的功能就是把输入的内容通过 互联网搜索引擎搜索 ，获取搜索的topk个结果链接，然后再返回这些链接中的内容；整体流程是用户输入一个原始问题，大模型判断后使用网络搜索工具， 传入搜索引擎关键词来搜索相关网址内容 ，然后对返回结果做 相似度排序 ，重排结果后再 整合进提示词 输入大模型，最后给出回复，如下：

 

把这个定义好的搜索工具封装成tool，实现大模型的联网搜索功能；以下用谷歌搜索引擎(需要谷歌云api key和id)为例，展示一个大模型实现谷歌搜索的工具：

from langchain_core.tools import Toolfrom langchain_google_community import GoogleSearchAPIWrapper
##定义一个工具函数def google_search(text):    search = GoogleSearchAPIWrapper()    tool = Tool(    name="google_search",    description="Search Google for recent results.",    func=search.run    )    result = tool.run(text)    return result
##定义工具的调用方式和参数规范search_tool = {    "type": "function",    "function": {        "name": "google_search",        "description": "当需要搜索实时性信息时，使用此搜索工具",        "parameters": {            "type": "object",            "properties": {                "text": {                    "type": "string",                    "description": "提问的问题"                },            },            "required": ["text"]        }    }}# 创建 Assistantassistant = Assistants.create(    model='qwen-plus',    name='搜索助手'




    
,    description='一个能够在谷歌搜索的助手',    instructions='你是一个搜索助手。当用户输入的内容需要搜索时，使用 google_search 函数来帮助他们。',    tools=[search_tool])

在这个谷歌搜索工具中，当输入的问题涉及实时性信息时，大模型会调用这个搜索工具进行谷歌搜索，把谷歌中搜索到的网址取topk个链接，获取其中的内容，这就是联网搜索的参考来源，然后这些参考来源会和问题一起输入大模型，大模型然后给出最终回复。 

联网搜索本身是一个很有用的功能，是对大模型知识能力的强大补充，但实际的使用通义模型中发现联网搜索的结果存在一些问题，让搜索的结果看起来不太靠谱，影响搜索本身的可信度，下面我会比对当前主流的通义千问、deepseek和豆包的联网搜索实际效果，来展示当前联网搜索的问题；

在这一实验中，三种模型对比情况如下：

三种模型全部采用当前主力系列模型，在性能上互相对标，qwen-max, doubao-1.5-pro-256k，deepseek-v3；全部在本地的python sdk环境测试，qwen直接调用基模，并开启enable_search=True，doubao调用应用bot，并开启应用里的search_tool开关，deepseek直接调用基模；为保证答案的确定性，temperature全部设置为0.01；

全部采用两个测试问题新闻搜索和天气情况，以下是输入大模型的指令：

新闻搜索

##角色你是一个搜索专家，能快速从互联网上搜索信息
##任务，搜索新闻用互联网搜索引擎搜索2025年1月的前3个重大民生新闻，给出新闻的来源网站
##输出格式标准json，{"news1":"xx","link1":"xx","news2":"xx","link2":"xx", "news3":"xx","link3":"xx" }

天气情况

##角色你是一个搜索专家，能快速从互联网上搜索信息
##任务，搜索天气用互联网搜索引擎搜索今天杭州市西湖区的天气情况，给出天气的来源网站
##输出格式标准json，{"weather":"xx","link":"xx" }

在实际测试的过程中，发现qwen-max如下的明显问题：

在新闻搜索的测试中，qwen-max暴露了一个最明显也是最常见的问题：给出的来源网站看似真实有效实际却是无效链接；

我经过10轮测试提问，总共让大模型返回30条新闻和对应链接，结果如下所示：

有效链接指的是返回的链接能直接访问，而不是无法访问的404链接； 真实链接指的是该链接不仅能有效访问，而且其中的内容和对应的新闻文本能对应上； 从结果中看出qwen-max的网址有效率只有1/3，而真实率只有0，这从用户的角度来说，网络搜索完全“ 不靠谱 ”，而相对的doubao和deepseek能做到很准确的结果；

例如以下是第一轮测试中三大模型的对比结果：

qwen-max

 

链接1跳转至官网，但官网无任何中国GDP相关新闻；链接2和链接3无法访问；

    

doubao

 

链接1、2、3全部是真实有效的链接

 

deepseek

 

链接1、2、3全部是真实有效的链接

  

原因分析：

通义为什么出错：从技术角度看，大模型的生成过程本质是一个迭代式的生成过程，当前词的生成是 根据前文序列的语义特征生成的 ，深入去分析通义给出的网站，比如https://www.caixin.com/2025-01/gdp-growth; 首页的地址caixin.com是可信的，但后面2025-01/gdp-growth， 相比一个真实链接（可能包含哈希码、数字校验等），此处更像一个对新闻内容的翻译，而 编造出来的简单网址 ，从大模型生成特征看，输入给大模型的内容是我的原始问题（查找2025年1月新闻）+网络搜索到的新闻，新闻的长文本内容的序列特征会影响后文网址的生成，因为要拟合前文的特征而产生了编造的虚假链接，但是我们通过搜索工具搜索出的新闻不仅包含新闻文本，同时也会返回网址链接，那么大模型为什么 不直接回复这个查询到的链接 而是自己编造一个虚假的链接，这个问题涉及到 基础模型的指令遵循能力 ；大模型在进行网络搜索时，应该直接返回搜索到的来源网址，而不应该自己编造，这需要在预训练阶段做好强化，需要产研同学进一步支持；另外我还尝试了在通义的C端界面做网络搜索，给出的来源是有效的，说明网址结果在C端做过处理，在前端呈现一个好的效果，但b端调用百炼基模结果不太靠谱，还要对基模的指令遵循做优化；

为什么豆包和deepseek表现好：豆包的结果明显好于通义最大的原因在于字节的 内容生态和大模型是捆绑的 ，在测试的30个搜索结果中，大部分的链接都来自今日头条（字节的内容应用），说明今日头条在豆包大模型的联网搜索工具里是一个权重很高的内容来源，所以豆包的全网搜索更近似一种“ 对自己内容生态的搜索 ”；deepseek的结果则体现了 基模能力的更优表现 ，其实大模型的联网搜索工具的功能性差不多，本质上是一个调用搜索引擎搜索+整理搜索结果的工具函数，产生差异的原因在于基模对于这些搜索结果是怎么处理的，前面讲到的通义指令遵循能力导致模型没有直接输出搜索到的网址而是编造虚假网址，而deepseek能直接给出搜索到的网址，这是 基模在指令遵循的差异 ；

qwen-max在测试中还有一个 输出的文本编造 的问题，这个情况一般和“来源无法查证”同时出现；当来源网址是404无效链接时，大模型回复的内容也存在编造的情况；

以下是在天气查询的测试中，大模型生成虚假内容的结果，总共10轮测试：

qwen

 

不仅天气和实际情况完全不同，给出的来源链接也并非杭州市的天气，而是吉林省某地的天气情况；

doubao

 

给出的来源有效且真实

  

deepseek