阿里妹導讀
0x0 序
近段時間 DeepSeek 的服務火遍了全網，無論是使用網頁還是使用 App 都能享受到 深度思考 + 聯網搜尋 的至尊體驗。奈何免費的東西往往是需要排隊的，從年開始 DeepSeek 的服務就一度處於不可用狀態，就算是年後，網路搜尋也是經常處於不可用的狀態。
所以這個和模型配套的網路搜尋能力到底是什麼東西呢？他是模型自帶的？還是一種模型之外需要開發的附加功能呢？
趁著我國補的 Mac Mini 剛好到到貨，接下來就跟隨我的腳步來建立一個基於本地 DeepSeek R1 32b 的網頁搜尋服務。
0x1 本地模型環境建立
在 Mac Mini 上執行模型是一件非常簡單地事情，這裡我們直接使用 Ollama 配置一套本地 LLM 模型執行環境，並且將 DeepSeek R1 32b 下載到本地。
當然，這裡也可以使用 LM Studio 來建立本地的大模型環境，但就我個人的體驗，Ollama 還是 對於系統的開銷要稍微低一些，畢竟沒有 UI 介面嘛。考慮到我們後面的訪問實際上只會用到本地部署的大模型 API 介面，無謂的 GUI 對記憶體的佔據還是能不要就不要，等大模型跑起來，多一點記憶體那就能多加幾輪對話記憶了。
完成了大模型的執行 API 建設，接下來我們還需要建設一個 Docker 環境，接下來我們的網路服務配置都會用到 Docker。
Docker 的安裝也非常簡單，直接從官網下載 Docker 的應用安裝即可。
有了 Docker 環境，接下來我們需要再本地配置最強自定義 LLM 工具——Dify。
這裡非常推薦使用 Dify 官方提供的 docker compose 安裝方法。不過在執行 compose 命令之前，我們需要開啟docker-compose.yaml 對裡面的引數做一些修改。
這裡最好將 ARRAY 的最大值設定給大，並將超時時間也最好也加長，因為我們是在本地執行 LLM 大模型，不同於最佳化到極致的 API 服務，本地執行有模型載入時間，並且記憶體滿了之後還會 Swap，使得模型輸出結果時間被進一步延長，等之後本地完成除錯換回網路 API 可以再把這個超時時間改回去。
調整完引數，接下來按照 Dify 官方文件進行部署。
完成部署的狀態大概是這樣，compose 會自動拉取最近的映象並完成整個專案配置。然後我們就可以透過網頁來訪問 Dify 操作介面了。
開啟 Dify 的第一件事情就是需要將我們之前部署的 Ollama 新增到 Dify 的模型配置中。
填寫好 Ollama 伺服器地址和模型的完整名字，這裡就配置完成了。
至此，我們本地的大模型開發環境就假設完畢了，接下來我們會透過 Dify 建立一個聊天助手，並使用 Ollama 上的 DeepSeek R1 32b為主模型，建立一個具有聯網搜尋能力的聊天助手。
0x2 搜尋能力建立
判斷是否要進行搜尋
DeepSeek 的客戶端和網頁在使用者手動開啟了聯網搜尋的情況下，都是會識別使用者輸入，如果使用者輸入的內容僅透過模型已有的知識就可以回答，那麼就不需要耗費資源去進行網路搜尋，畢竟使用者說個“你好”還給搜一排沒意義的網頁並彙總，也顯得有點蠢。
所以在拿到使用者的輸入之後，我們先要讓模型判斷一下當前使用者的輸入是否需要進行網路請求：
這裡我透過 SYSTEM 資訊給模型賦予了角色，之後將使用者輸入透過指令包裹之後投餵給模型，並且規定了模型的反饋形式。
在後續的條件分支中，根據模型的返回我們可以選擇不同的執行路徑。
如果不需要進行搜尋的話，那就直接把使用者的輸入餵給模型並讓模型返回：
如果模型判斷自身的知識不足以回答使用者的問題，那麼接下來我們就要進行搜尋了。
生成搜尋關鍵詞
要進行搜尋，就需要有一個搜尋關鍵詞。當然我們可以將使用者的輸入直接當成關鍵詞丟給搜尋引擎，但現在大部分搜尋引擎可沒有大模型的理解能力，所以我們需要模型先根據使用者輸入整理一個適合的搜尋關鍵詞出來：
一般來說根據使用者的輸入，都能總結出一個搜尋關鍵詞，但使用者的輸入可能包含多個問題，比如說“今天天氣如何？去東方明珠是否合適？”這裡按照使用者的問題，就需要查詢當前上海的天氣的情況和東方明珠的票務情況，這兩個需要查詢的內容如果混合成一個關鍵詞可能無法搜尋到正確的網頁，比較合適的做法是將兩個需要獲取的資訊拆分成兩個搜尋關鍵詞。
這裡我圖方便就只生成一個關鍵詞進行一次搜尋。
進行搜尋
Dify 作為一個非常強大的 LLM 工具，內建了多個搜尋外掛：
谷歌搜尋這裡需要再谷歌的後臺生成搜尋 API，並且 Dify 所在的環境需要科學上網能力；Bing 的後臺我死活打不開，感覺被微軟拉黑了；DuckDuckGo 是最友好的搜尋，直接掛上就能用，搜尋結果也很精確。至於我這裡配置的 SEARXNG，是一個開源專案，這個專案會彙總數個平臺搜尋結果並整理成 JSON 返回給 Dify。
我本地剛好之前配置過 SEARXNG，所以這裡直接選擇，鑑於 SEARXNG 配置稍微有點複雜，動手能力強的同學可以參考我的配置。
網頁獲取
完成搜尋之後，我們會得到一個數組的網頁 URL，也就是我們的搜尋結果。如果直接把 URL 交給模型，模型可是不知道這 URL 對應的內容是什麼的，畢竟模型只能透過機率和引數進行輸入輸出，並不具備訪問網路能力。為了讓模型知道這些搜尋結果的 URL 對應的網頁內容是什麼，我們需要將網頁下載下來並提取其中的重要內容。
由於搜尋返回的是一個數組，所以我們需要一個迭代元件來對數組裡面的內容迴圈處理。
這裡下載網頁我使用了 HTTP 請求而不是 Dify 提供的網頁爬蟲外掛，因為在我實際操作下來，網頁爬蟲會直接將網頁的文字內容透過 python 庫直接脫離出來生成文字，可以說是基本在無解析的情況下直接將網頁的文字全部輸出，沒有任何過濾和主次處理。為了減少後續模型的 Token 消耗，我們這裡直接將原始的 HTML 原始檔下載到本地，稍後透過一點手段來進行主要內容提取處理。
需要注意的是這裡抓取網頁的迭代我開啟了並行模式，畢竟這裡只有網頁下載這一項功能，並行下載是一個正常操作。但如果一個迭代裡面存在模型呼叫的話，考慮到模型併發時實際上還是按照佇列執行，並且本地模型執行速度較慢，在這種情況下還是序列執行比較合適。
完成抓取之後，針對下載失敗的頁面需要進行一下篩選，再進入後面的流程。
網頁內容提取
網頁內容提取這塊流程大概是這樣的，這裡我使用了一個新的模型——Jina.ai 提供的 Reader-LLM-V2。經過我的測試，Reader-LLM-V2 對網頁的提取效果非常好，可以透過簡單的提示詞很快將網頁中的主要文字內容提取出來。並且這個模型只有 1.5b並支援 256k Token，所以可以將整個網頁原始碼都作為輸入餵給模型，佔用的記憶體也在可以接受範圍。
當然我們這裡由於是本地模型，執行起來時間消耗還是比較高的，後面可以考慮使用 Jina.ai 提供的服務來進行網頁內容提取。
提取完成之後，還需要交給模型，讓模型分析一下提取出來的內容和使用者一開始輸入的關聯性。只有減少無用的資訊，才能保證最終模型在有限的 Token 輸入下能得出最正確的結果。
這裡我讓模型根據網頁內容和使用者輸入給出一個相關評分，如果相關評分大於 5 則加入最終的輸入，如果小於 5 就忽略掉。
格式化輸入並讓模型給與返回
有了相關網頁的內容陣列，我們還需要組織一下最終輸入給模型的內容，需要讓模型知道我們進行了搜尋，並且搜尋有這麼些結果，讓模型根據搜尋結果提供的資訊對使用者一開始的輸入進行反饋。
這裡我簡單做了一個格式化，如果更加細化的話可以讓模型根據引用的內容標註出對應的網頁。
0x3 測試聊天助手
整個流程搭建完成，接下來就能進行測試了。
透過這兩個測試結果可以發現，這麼一套流程走下來，模型確實具有一些其內部不存在的知識，並能夠透過新增的知識進行總結輸出。
不過這個輸出似乎還是包含了一些不太正確的資訊。透過回溯整個執行流程，可以發現最後一次進行內容輸入時，由於缺少足夠的格式化，模型並沒有完全理解搜尋結果是作為被新增的資訊提供的。
當然還有個問題就是由於模型都在本地執行，所以網頁提取和模型執行時間都非常長，倒是搜尋結果給出的速度快的有點出乎意料。
0x4 最佳化
整套流程跑下來，我們可以看到其中還有不少的地方是可以最佳化的。
如果說不糾結於本地執行模型，或者說補充新的效能更強的模型執行裝置，相信在模型呼叫耗時上能夠減少一個數量級。
流程中的缺陷主要就是前面提到的搜尋關鍵詞生成和進行多次搜尋那塊。
這流程最大的問題，還是最後一次投餵時網頁內容過多。上面的兩個例子中，由於網頁下載失敗和提取問題，最終的 Token 數量並不是很多。但在最佳化完那部分處理之後，最後可能會有數十個網頁，這些網頁的文字內容加起來可能會導致最後輸入的 Token 超過模型承載。
這裡參考了一下 OpenWebUI 的實現，似乎可以建立一個由搜尋結果網頁內容組成的本地知識庫，透過 RAG 的形式，將知識庫內容進行 Embedding 之後傳遞給模型，來讓模型可以使用網頁裡面相關的知識。
0x5 總結
本文展示瞭如何從零開始搭建一個具備聯網搜尋能力的本地聊天助手，涵蓋了模型部署、搜尋邏輯設計、內容提取與整合等關鍵步驟。儘管存在一些效能和準確性上的挑戰，但透過進一步最佳化（如引入 RAG 技術），這套系統有望成為一個高效的問答工具。
（本文總結使用 Qwen2.5-Max 未開源版本生成）
如何快速使用ACK搭建微服務
本方案介紹如何高效、快速地在容器服務Kubernetes版ACK上編排與部署應用。
點選閱讀原文檢視詳情。