阿里巴巴的 SearchQwen3-8B，以及小型搜尋代理的價值

阿里雲 PAI 團隊在 Hugging Face 上以 Apache 2.0 授權釋出 SearchQwen3-8B，這是一個 81.9 億參數的模型，專為多跳搜尋與瀏覽而打造。它擁有 40,960 個 token 的上下文視窗，而且與其說它會生成自由文字，不如說它會發出由搜尋後端執行的結構化工具呼叫。

這樣的定位正是重點。這個模型是搜尋代理，不是搜尋引擎。它決定要查什麼、以什麼順序查，以及如何整合回傳的結果。後端由你提供。

這項區別之所以重要，是因為它把大多數 AI 搜尋討論中混為一談的兩件事分開。檢索是基礎架構問題：索引、排序函式、抓取最新內容的方式。規劃則是推理問題：判斷這個問題需要查三次、第四次是多餘的，以及前兩個來源彼此矛盾。SearchQwen3-8B 正是第二種系統，這也是它永遠無法獨自回答問題，以及它能直接嵌入現有檢索堆疊而無須將其取代的原因。

它是如何打造的

訓練方法是此處最有趣的技術細節。SearchQwen3-8B 使用 EasyDistill 2.0，以環境對齊且經求解器驗證的搜尋軌跡進行蒸餾。這個流程不是在人工撰寫的搜尋日誌上訓練，而是在實際環境中生成軌跡，並保留真正解決任務的那些。

求解器驗證是讓這套做法可行的關鍵。一條軌跡只有在收斂到正確答案時，才具有作為訓練資料的價值；而對許多搜尋任務而言，正確性是可以檢查的，開放式生成則不然。這讓整個流程有了可靠的過濾機制，也正是回報的效益如此顯著的原因。

體型較小的同系列模型 SearchQwen2.5-3B 也同時釋出，擁有 32,768 個 token 的上下文視窗，同樣以 EasyDistill 2.0 與 SynSearch-Data 蒸餾而成。

公布的數據

模型卡指出，在相同的工具呼叫介面下，相較於基礎版 Qwen3-8B，以 LLM 作為評審的準確率有所提升。在多跳問答上，工具呼叫準確率從 24.50 升至 35.42。在整體深度搜尋上，則從 40.31 提升至 50.31。

就 3B 模型而言，相對幅度更大：多跳問答為 48.58，基礎版 Qwen2.5-3B-Instruct 為 36.10；深度搜尋為 21.40，對比 7.05。

這些數字全都由公司自行公布，未經獨立評估；在一個評估特別容易被操弄的子領域裡，這一點格外重要。搜尋基準測試獎勵的是知道該信任哪些來源，而在經求解器驗證的軌跡上微調的模型，會針對求解器認定為正確的標準進行最佳化。能否在 GAIA、HotpotQA 等基準上取得獨立評估結果，才是值得觀察的訊號。

在任何人將其視為可投入生產之前，絕對數字也值得再多看一眼。多跳問答從 24.50 躍升至 35.42，是相當大的相對進步，但仍意味著在該評審標準下，模型大約三次嘗試中有兩次是錯的。在經過驗證的軌跡上進行蒸餾確實帶來實質效益，但並不會產出一個無須自身驗證步驟就能信任的系統。

小型搜尋代理為何重要

推出 8B 搜尋代理、並在一旁附上 3B 版本的策略邏輯，著眼於部署成本效益。搜尋代理會被頻繁呼叫，而且經常是平行呼叫，這使得每 token 的 API 成本成為實實在在的限制。一個能在普通硬體上執行、且每次呼叫不需花費任何成本的模型，改變了哪些應用可行。

客服團隊若想讓代理在內部文件與公開來源中研究客戶問題，可以在自家基礎架構上執行 SearchQwen3-8B。研究團隊若需要彙整眾多來源的發現，又不願把查詢送往第三方，同樣可以這麼做。這兩種情境都不需要前沿等級的推理能力，但都需要可靠的工具使用與低廉的邊際成本。

這裡也有治理層面的論點。自行託管的搜尋代理能將查詢模式留在組織內部，這對身處受監管產業、其提問會洩漏自身工作內容的人來說尤其重要。

問題在於，總持有成本還包含搜尋後端。這個模型需要外部的搜尋與瀏覽服務，而要把這項服務經營得好，本身就是一個專案。把便宜模型接上糟糕的檢索層，表現會不如搭配良好檢索的昂貴模型。

這個取捨值得直白地說清楚，因為它是這類部署最常見的失敗方式。團隊看到一個基準數字亮眼的 8B 模型，就以為難的部分已經完成。實務上，模型是簡單的那一半。檢索層決定了代理可能看到什麼證據，而無論規劃能力再強，都無法彌補一個回傳過時或不相關結果的後端。規劃模型決定何時去看，後端決定看能看到什麼。

工具呼叫介面才是真正的產品

這裡最具影響力的設計決策是輸出格式。模型發出的是結構化工具呼叫，而非散文式文字。這使它成為已經採用該介面的代理框架可直接套用的元件，也意味著模型的工作是規劃與整合證據，而不是給出答案。

這樣拆分工作對除錯有實際好處。當搜尋代理產出糟糕的答案時，你可以檢視工具呼叫的軌跡，判斷是模型選錯了查詢，還是後端回傳了糟糕的證據。直接寫出答案的單體式模型會掩蓋這項區別。在生產環境中，這種可觀測性正是「你能改進的系統」與「你只能替換的系統」之間的差別。

值得觀察的重點

有兩個訊號會決定這次發布是否重要。第一是獨立評估能否證實所公布的效益，因為蒸餾方法的價值取決於驗證機制是否真的站得住腳。第二是阿里 PAI 是否會釋出 SynSearch-Data 訓練集或 EasyDistill 2.0 框架。若兩者都公開，預期會出現一波來自其他團隊的蒸餾代理模型，這將使小型專用代理成為預設選項，而非小眾做法。

從時機點還可看出一種更廣泛的模式。阿里巴巴以寬鬆授權釋出專用小型代理，而前沿實驗室則把最好的模型留在 API 之後。這是刻意的策略：抓住那些在意部署自己可控東西的開發者，其餘的人就交由託管 API 的每次呼叫成本效益來處理。這套策略是否奏效，取決於自行託管在團隊實際運作的規模下是否真的省錢——一旦把基礎架構與前述的檢索工作算進去，答案並不顯而易見。

就目前而言，一個採用 Apache 2.0、以寬鬆授權釋出、且不收取每次呼叫費用的搜尋代理，是架子上相當實用的生力軍。它不會取代前沿模型來處理困難的推理，也不需要如此。大多數搜尋代理的呼叫都是例行性的，而例行性工作正是小型模型最適合的場景。