阿里妹導讀
本文作者詳細分析了當前大模型在聯網搜尋功能中存在的幾個主要問題，並提供了具體的案例和解決方案。
一、背景和原理
大模型聯網搜尋的功能，是指大模型透過即時的進行網際網路搜尋來獲取即時資訊，然後做出更準確和合理的回覆；聯網搜尋的功能，主要是為了彌補大模型預訓練知識庫存在時效性導致即時知識滯後性的問題，可以認為是一種額外的工具，幫助大模型獲取即時資訊後，作為輸入傳入給大模型，大模型再結合額外的資訊做出回覆；比較常見的聯網搜尋功能的場景有當前時間、天氣、新聞、商品價格等受即時因素影響大的場景，這些細節憑大模型本身的知識庫無法回答或是回答不準確，就需要藉助外部工具-聯網搜尋；
例如以下是一個大模型用聯網搜尋即時天氣的典型例子：
在這一“當天天氣”的問答中，這個問題可以拆分成兩個子問題，“今天是什麼日期，星期幾”和“杭州這個日期的天氣情況”；很明顯，這兩個即時性問題憑大模型自己的知識庫無法回答，大模型會使用聯網搜尋進行回答；
聯網搜尋，本質上是一個工具函式，而工具函式是大模型智慧體（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如下的明顯問題：
2.1 搜尋來源不可查證
在新聞搜尋的測試中，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能直接給出搜尋到的網址，這是基模在指令遵循的差異；
2.2 搜尋內容胡編亂造
qwen-max在測試中還有一個輸出的文字編造的問題，這個情況一般和“來源無法查證”同時出現；當來源網址是404無效連結時，大模型回覆的內容也存在編造的情況；
以下是在天氣查詢的測試中，大模型生成虛假內容的結果，總共10輪測試：
|
模型
|
虛假內容數
|
虛假內容率
|
|
qwen-max
|
5
|
50%
|
|
doubao-1.5-pro-256k
|
1
|
10%
|
|
deepseek-v3
|
0
|
0%
|
虛假內容指的是大模型的回覆和實際情況不符；從結果上看，qwen的虛假內容率明顯比其他兩個模型高，以下是3月5日杭州市天氣的實際例子:
qwen
不僅天氣和實際情況完全不同，給出的來源連結也並非杭州市的天氣，而是吉林省某地的天氣情況；
doubao
給出的來源有效且真實
deepseek
給出的來源有效且真實
原因分析：
造成虛假回覆天氣的情況從根本上說是大模型理解和搜尋策略的問題，無論是哪種大模型，能夠使用的搜尋來源和搜素引擎都是固定的，搜尋3月5日杭州的天氣從理論上說各個搜尋引擎都會獲取到差不多的結果，那麼唯一的區別就在於大模型的內容理解差異和搜尋策略差異；
內容理解差異是指大模型傳給搜尋引擎的內容是根據使用者輸入的內容生成的，比如提問大模型“今天杭州的天氣”，大模型會理解這個問題，然後生成“今天的日期是幾月幾日，杭州在x月x日的天氣情況”，再把這個輸入進搜尋引擎搜尋，那麼這個理解的過程會因為基模語義理解能力的差異而產生不同的結果，比如qwen犯錯的這個問題中，我推測大模型沒有正確的生成“今天是3月5日”的結果，導致後面天氣直接錯誤；
搜尋策略差異是指大模型對搜尋結果的召回策略，大模型會對搜尋結果做一個相似性判斷，比如返回10個搜尋結果，大模型會判斷結果和原始問題的相似性，然後重排序，把相似性高的結果放在前面，然後再整合起來做答覆；這個重排的計算邏輯不同的模型不一樣，會導致召回的順序也不一樣，比如在上述問題中，大模型的召回結果中包含三個結果：1“今天的天氣是10-15C”，2“3月5日的天氣是6-8C”，3“2月5日的天氣是0-2C”，原始提問是“今天杭州的天氣”，如果重排後結果2放在最前面，那麼大模型會回覆正確的天氣結果，如果結果1放在前面，就會產生虛假回覆；
2.3 搜尋指令難以遵循
在實際測試過程中，對於搜尋相關的指令遵循能力也做了測試，設計了限定搜尋來源的指令，限制大模型只能搜尋新浪新聞、新華網、鳳凰新聞的新聞來源平臺，對比不同模型的表現，在提示詞中加入了##限制：只能搜尋新浪新聞平臺，嚴禁搜尋其他平臺的新聞；
新聞搜尋
##角色你是一個搜尋專家，能快速從網際網路上搜索資訊##任務，搜尋新聞用網際網路搜尋引擎搜尋2025年1月的前3個重大民生新聞，給出新聞的來源網站##限制只能搜尋新浪新聞平臺，嚴禁搜尋其他來源；##輸出格式標準json，{"news1":"xx","link1":"xx","news2":"xx","link2":"xx", "news3":"xx","link3":"xx" }以下是模型的結果：
qwen
qwen在提示詞中明確限定了搜尋來源的條件下，仍然存在返回其他來源的情況；
doubao
所有來源全部來自新浪新聞；
deepseek
所有來源全部來自新浪新聞；
原因分析：
對於模型無法從指定來源搜尋的情況，本質和基礎模型的指令遵循能力有關，在上述的新浪新聞的例子中，大模型應該在搜尋結果召回階段，對不屬於新浪新聞的網址連結過濾，保留sina.com的結果；那麼最終給出的回覆只會保留新浪新聞，但在qwen的表現中，顯然大模型在搜尋召回策略中對新浪新聞的搜尋結果不敏感，原本來自新浪的連結應該和原始問題非常相似，但模型的相似度匹配沒有把新浪連結重排在前面，未來可能需要模型進一步提升網址本身的域名在相似度匹配中的權重，而不是僅對網站的文字內容做匹配；
三、最佳化方向
針對上述測試中，qwen-max表現出來的問題，經過原因分析，其實要從根本上來解決這些聯網搜尋的問題，還需要基礎模型的語義理解和指令遵循能力的進一步提升，以及對聯網搜尋工具函式、召回策略的最佳化；
那麼站在客戶角度的應用側，如何在模型呼叫時儘量的減少聯網搜尋內容和來源的“不靠譜”，讓結果更具有可信度，我根據測試和相關專案中的經驗，從最佳化提示詞、內容後處理、最佳化搜尋工具的幾個方面總結了聯網搜尋的最佳化方法；
3.1 提示詞強化輸出概要網站
我在測試實驗中發現，qwen會存在根據內容編造虛假的來源網址的情況，這類編造的網址例如https://www.caixin.com/2025-01/gdp-growth有個特點，前面的域名www一般是可信的，但後面的具體路徑開始編造，針對這一特點，可以對查詢來源做一個取捨，犧牲一些精確性，但要保證可信度，那麼可以讓大模型在輸出時儘量輸出前面的域名www，這樣點選來源連結一般會進入域名首頁官網，絕大部分是可訪問的，首先保證連結不是一個404的無效連結，然後使用者可以在這個首頁官網在根據大模型的生成內容去手動搜尋，操作上更加複雜，為了提升可信度做出的最佳化；
具體可以在提示詞裡給大模型做輸出指令的限制，讓大模型在網址中查詢不到實際資訊時，輸出官網域名首頁，嚴禁自己編造網址，例如以下是對提示詞做的改進，增加了限制要求；
新聞搜尋
##角色你是一個搜尋專家，能快速從網際網路上搜索資訊##任務，搜尋新聞用網際網路搜尋引擎搜尋2025年1月的前3個重大民生新聞，給出新聞的來源網站##限制如果實際網址中沒有資訊，輸出實際網址對應的可訪問的域名首頁，嚴禁自己編造來源；##輸出格式標準json，{"news1":"xx","link1":"xx","news2":"xx","link2":"xx", "news3":"xx","link3":"xx" }對提示詞做改進後，qwen-max的表現有了明顯改進，同樣做了30次新聞搜尋的測試，因為現在我們限制了輸出官網域名，93.3%的來源都是可訪問的新聞官網，雖然官網上會展現大模型搜尋到的內容的機率較低，只有10%，但至少保證了絕大多數情況下使用者得到的是有效連結，增加了可信度，後續可能需要使用者手動在官網上搜索相關內容；
|
模型
|
有效連結數（非404網址）
|
網址有效機率
|
真實連結數（網址內容和新聞對應上）
|
網址真實率
|
|
qwen-max
|
28
|
93.3%
|
3
|
10%
|
以下是一個實際的例子：
qwen
給出的三個來源全部是官網域名，並且全部有效訪問；
3.2 對輸出內容作後處理
在測試中，基於qwen編造虛假來源的問題，前面講到新聞官網首頁一般是有效的，但整體的連結是無效的，針對這一情況，我們可以新增一個工具指令碼，對輸出的網址做後處理，提取網址域名首頁的地址，替換原有結果；同時可以對域名做校驗，檢查首頁域名是否有效；
#從大模型返回的結果，一個json，包含三個新聞text和來源linkres=response.output.choices[0].message.content#對域名做後處理，替換為首頁域名links=[res['link1'],res['link2'],res['link3']]for link in links:if'http' in link or'https' in link or'www' in link: temp=link.split('/')if len(temp)>=3: new_link='/'.join(temp[:3]) new_links.append(new_link)#校驗域名import requestsdef check(url):try: response = requests.get(url)if response.status_code ==200:return Trueelse:return False except requests.RequestException:return Nonefor new_link in new_links:if check(new_link): print(new_link)經過上面指令碼的處理，像之前編造的網址例如https://www.caixin.com/2025-01/gdp-growth會替換成https://www.caixin.com，這是可訪問的有效連結；這個指令碼會過濾掉一些可能無效的網址，需要大模型返回更多的文字和連結來保證輸出數量；
3.3 自定義搜尋工具函式
除了上述兩種方法來改進大模型輸出的來源網站外，還可以從搜尋策略層面直接最佳化，讓大模型搜尋到的內容保證真實有效，那麼大模型輸出的內容和來源也一定是真實有效的，這可以從搜尋工具函式入手，不用qwen內建的搜尋工具，我自己定義一個召回搜尋結果的工具函式，來實現比內建工具更強的搜尋效果，從而提升大模型的回覆質量；
根據大模型聯網搜尋的原理，整體流程是使用者輸入一個原始問題，大模型判斷後使用網路搜尋工具，傳入搜尋引擎關鍵詞來搜尋相關網址內容，然後對返回結果做相似度排序，重排結果後再整合進提示詞輸入大模型，最後給出回覆；這個過程中可以最佳化的地方在重新自己設計相似度排序演算法並引入網址校驗機制來提升排序的精確性，保證大模型給出回覆的真實有效，以下是示例的最佳化工具函式，採用gte-rank模型來對搜尋結果重排和驗證連結有效性和網址內容中包含原始query的最佳化策略；
from llama_index.core.data_structs import Nodefrom llama_index.postprocessor.dashscope_rerank import DashScopeRerankfrom langchain_core.tools import Toolfrom langchain_google_community import GoogleSearchAPIWrapperimport requests##定義一個工具函式def google_search(text): #獲取top20搜尋引擎結果 search = GoogleSearchAPIWrapper() tool = Tool( name="google_search", description="Search Google for recent results.", func=search.run, topk=20 ) result = tool.run(text) #校驗網址 new_result=[] keywords=text.split(',')for each in result: content=each['content'] link=each['url'] response = requests.get(link)if response.status_code ==200: find=Truefor key in keywords:if key not in content: find=Falsebreakif find: new_result.append((content,link)) #相似度排序 nodes=[]for content,link in new_result: nodes.append(Node(text=link+'&'+content)) dashscope_rerank = DashScopeRerank(top_n=3) results = dashscope_rerank.postprocess_nodes(nodes, query_str=text) temp_res=[]for res in results: temp_res.append(res.node.get_content(),res.score) temp_res.sort(key=lambda x:x[1],reverse=True)return temp_res##定義工具的呼叫方式和引數規範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])重新最佳化後的搜尋工具讓qwen的輸出精確性進一步提升，在30次新聞搜尋的測試中，返回的來源網址全部有效，提升到100%，真實連結的機率也提升到90%，這個自定義的搜尋工具比qwen內建的搜尋工具效果更優；
|
模型
|
有效連結數（非404網址）
|
網址有效機率
|
真實連結數（網址內容和新聞對應上）
|
網址真實率
|
|
qwen-max
|
30
|
100%
|
27
|
90%
|
參考：
1.百鍊官方文件
https://help.aliyun.com/zh/model-studio/developer-reference/call-example?spm=a2c4g.11186623.0.i1#d101e2f6163ag
2.火山引擎官方文件
https://www.volcengine.com/docs/82379/1285209
3.deepseek官方文件
https://api-docs.deepseek.com/guides/function_calling
無縫整合 MySQL，解鎖秒級 OLAP 分析效能極限
在資料驅動決策的時代，一款效能卓越的資料分析引擎不僅能為企業提供高效的資料支撐，同時也解決了傳統 OLTP 在資料分析時面臨的查詢效能瓶頸、資料不一致等挑戰。本方案推薦透過 AnalyticDB MySQL + DTS 來解決 MySQL 的資料分析效能問題。
點選閱讀原文檢視詳情。
