假設你現在要裝修房子，找裝修隊。你打開一個平台，輸入"我要裝修廚房"，平台給你推薦了十個裝修隊。你點開一看，發現這十個里有八個都是專門做瓷磚鋪貼的，剩下兩個是水電改造和櫥櫃定製。問題來了：廚房裝修光有瓷磚師傅是不夠的，你還需要水管工、電工、油漆工、櫥櫃安裝工,這些活兒一個都不能少。但平台的推薦算法只會按"跟你需求的匹配度"評分，瓷磚師傅因為都寫著"廚房裝修專家"所以匹配度最高,結果你的候選名單里全是同質化的選項,真正需要的其他工種反而被擠了下去。
這不是一個虛構的場景,這正是當下大語言模型智能體在調用外部技能時面對的真實困境。
大語言模型智能體：
大語言模型智能體（LLM Agent）指的是基於大語言模型構建的能自主完成任務的系統,它不僅能生成文字,還能調用外部工具、腳本、文檔等"技能"來完成更複雜的工作。
想讓AI幫你處理一份財務報表、生成一段可視化圖表,或者操作一個複雜的自動化流程,單靠語言模型本身的"嘴巴"是不夠的,它需要藉助外部技能庫,就像人類工作時需要打開各種軟體工具一樣。這幾年,隨著技能庫越做越大,一個新問題冒出來了：從幾萬個技能里,怎麼挑出最合適的那一小把?
問題到底難在哪
早期的工具調用研究,比如讓語言模型學會調用API的Toolformer,已經證明了模型可以學會"什麼時候該用工具"。後來出現的HuggingGPT讓一個大模型充當調度員,把任務拆解成子任務,分配給不同的專家模型去執行。ToolLLM則把這套思路擴展到了上萬個真實世界的API上。這些工作都在說一件事：外部工具能極大擴展語言模型的能力邊界。
但工具用多了,新的麻煩就來了。
當技能庫里躺著幾萬甚至幾十萬個技能時,你不可能把它們全部塞進模型的上下文窗口裡,那樣既浪費資源又會分散模型的注意力,讓它更容易做出錯誤判斷。於是"技能路由
"這個新的研究方向誕生了,核心問題就是：怎麼從海量技能里精準挑出跟當前任務相關的那一小批。
SkillRouter這個基準測試直接把這個問題擺上檯面。它構建了一個大約八萬個技能的候選池,發現完整的技能實現文本里藏著比單純名字和描述更豐富的路由信號。另一個叫SkillsBench的工作則進一步驗證了：精心挑選的技能確實能提升智能體的表現,但這個提升幅度很依賴任務類型和技能質量本身。
這些發現共同指向一個結論：技能選擇正在變成智能體系統里越來越關鍵的一環。
但現有的技能路由方法幾乎都用同一套思路：把每個候選技能拿去跟用戶的請求單獨評分,按分數從高到低排,取前幾個。這套邏輯對付"只需要一個技能就能搞定"的簡單任務沒問題,因為只要找到那個唯一正確的答案就行。
真正的麻煩出在複合型任務上。一個用戶請求往往需要好幾個技能配合完成,比如先解析文檔,再提取資訊,然後做數據轉換,最後生成可視化圖表。這時候如果還是各評分、各排名,很可能出現這樣的情況：幾個功能相似、描述相近的技能因為都跟查詢"沾親帶故",分數都很高,結果把候選名單擠得滿滿當當,而那些真正需要但描述風格不同的技能反而被排到了後面,根本擠不進最終的候選名單。
上下文窗口被浪費在了重複功能的技能上,而任務真正需要的互補技能卻被漏掉了,這就是問題的本質。
從"排名"到"選集合"：DPP登場
面對這個問題,研究者們想到了一個跳出常規排序思路的辦法：既然問題出在"獨立評分、各自為戰",那就換個角度,把選技能這件事看成一個"選出一組互補且不重複的組合"的問題,而不是簡單地"選出分數最高的幾個"。
這種思路在資訊檢索、推薦系統、文本摘要等領域早已有先例,統稱為多樣性感知檢索,核心目標是選出的東西既要個個有用,又要彼此不重複。
行列式點過程（Determinantal Point Process，簡稱DPP）：這是一種概率模型,專門用來解決"選一組東西,既要質量高又要互相不重複"這類子集選擇問題,數學上通過矩陣的行列式來同時刻畫"每個元素單獨有多好"和"元素之間有多相似"。
DPP這個工具聽起來抽象,但用一個招聘場景就能理解它的價值。假設你要組建一個五人的產品團隊,如果你只按"簡歷評分"挑人,可能會挑出五個背景高度相似的候選人,五個都是做前端開發出身,團隊裡沒人懂產品設計、沒人懂用戶研究、沒人懂後端架構。DPP的思路是,在挑選每一個新成員時,不僅看這個人本身夠不夠優秀,還要看他跟已經選進團隊的人有多"像"。如果這個人和已經在團隊裡的人技能重疊嚴重,即使他簡歷分數很高,也會被適當"打折"；如果他能帶來團隊裡還沒有的能力,即使原始分數沒那麼驚艷,也會被優先考慮。這就是DPP要解決的核心矛盾：單純的高分排序會讓"同質化的強者"扎堆,而適度的多樣性考量能讓整個團隊的綜合戰鬥力更強。
不過,把DPP直接搬到技能路由上,並不是拿來就能用的。這裡藏著一個微妙的陷阱：兩個技能之間的"相似",可能有兩種完全不同的原因。
第一種,它們是真正的功能重複,比如兩個都是"翻譯文檔"的技能,選一個就夠了,選兩個純屬浪費。
第二種,它們恰好都跟同一個查詢相關,但各自負責任務里不同的環節,比如"解析Excel表格"和"清洗數據列"這兩個技能,雖然都屬於同一個數據分析任務的範疇,乍一看語義上有些接近,但它們分工完全不同,都需要保留。
如果按照標準DPP的做法,對所有的相似性一視同仁地進行懲罰,那第二種情況會被誤傷,那些本該共同出現的互補技能反而會被排擠出局。這個陷阱不解決,DPP在技能路由上就是個半成品。
DSR：把"因查詢而相似"和"真的重複"分開算
針對這個陷阱,研究團隊提出了自己的方案,叫DSR。
Diverse Skill Routing（多樣化技能路由，簡稱DSR）：這是一個基於DPP的重排序框架,核心目標是在挑選技能候選集時,同時兼顧"跟查詢相關"和"技能之間不重複"這兩個訴求。
DSR的整體流程分成幾步走。第一步,用一個編碼器檢索器從全量技能庫里先撈出一批候選技能,這一步純粹靠語義相似度,速度快但不夠精細。第二步,用一個更強大的重排序模型給每個候選技能打一個質量分,這個模型能看到更豐富的資訊,比如技能的完整實現代碼,不只是名字和簡單描述。第三步,也是最關鍵的一步,不再簡單按分數排序取前幾個,而是用DPP從候選集裡挑出一個既高質量又不冗餘的最終子集。
這個三步走的設計本身就體現了一種權衡思路：先用便宜的方法篩出一個不大的候選池,再用貴的方法在小範圍內精細評分,最後用DPP做最終的組合優化。如果一開始就對全部八萬個技能跑複雜的DPP計算,那計算量會大到無法承受,這就好比在超市里買菜,你不會把整個倉庫的貨品都搬到收銀台前一件件比較,而是先按類別走到對應的貨架前(檢索),再在有限的幾個品牌里精挑細選(重排序和多樣性優化)。如果省略了第一步的粗篩,直接在幾萬個選項里做精細的兩兩比較,時間成本會呈爆炸式增長,這套系統根本無法在實際場景中運行。
而DSR真正的創新點,在於它怎麼定義"兩個技能到底有多相似"這件事。
查詢殘差多樣性核（Query-Residual Diversity Kernel）：這是DSR提出的一種計算技能相似度的新方法,核心做法是先把兩個技能表示中"跟當前查詢相關的那部分"去掉,只在剩下的"殘差"部分里計算相似度,這樣能避免把"因為都跟查詢相關而顯得相似"錯誤地當成"真正的功能重複"。
具體的數學操作是這樣的：假設每個技能都有一個向量表示（embedding）,可以理解成用一組數字描述這個技能"長什麼樣"。DSR先算出這個技能向量里跟查詢方向"重合"的那一部分,然後把這部分從技能向量里減掉,剩下的就是"殘差"，也就是這個技能里跟當前查詢無關的、體現它獨特功能的那部分。之後,DSR不是完全只用殘差來算相似度,而是把殘差和原始向量按一定比例混合（論文裡這個混合係數設為0.85,也就是大部分權重給殘差,小部分權重保留原始資訊以保證穩定性）,再重新歸一化。最終用這個混合後的向量算兩個技能之間的相似度,作為DPP多樣性懲罰的依據。
這個設計如果換成一個更貼近生活的類比來理解,會更清楚它解決的問題所在。想像你在給一個家庭聚會挑選菜品,你已經知道這次聚會的主題是"川菜"。如果你只看"這道菜是不是川菜"這個維度去判斷兩道菜有多像,那麼水煮魚和麻婆豆腐都會顯得"很像",因為它們都屬於川菜,都辣。但如果你把"是不是川菜"這個共同屬性先剝離掉,只看剩下的部分,水煮魚是水產類,麻婆豆腐是豆製品類,它們其實是完全不同的菜品,搭配在一起才是一桌豐富的宴席。查詢殘差核做的正是這件事：先把"都跟這次查詢相關"這個共性剝離掉,再看剩下的功能差異有多大。如果不這麼做,直接拿原始向量算相似度,水煮魚和麻婆豆腐會因為"都是川菜"被系統誤判為冗餘,其中一個會被踢出候選名單,結果你的餐桌上可能同時出現兩道魚、卻漏掉了豆製品這個品類。
實驗說了什麼
DSR團隊在SkillRouter這個基準測試上做了系統的驗證,這個測試集包含75個經過專家驗證的查詢,覆蓋55個領域、8個大類,技能候選池大約八萬個。查詢分成兩類，24個是單技能查詢(只需要一個正確答案),51個是多技能查詢(需要兩到五個技能配合)。
召回率（Recall）：衡量在返回的前k個結果里,真正需要的目標技能被找到了多少比例。
完全覆蓋率（Full Coverage）：衡量一個查詢所需要的所有目標技能是否都被完整地包含在了前k個結果里,這個指標比召回率更嚴格,因為漏掉任何一個必需技能都算不合格。
為什麼完全覆蓋率格外重要?因為在多技能任務里,少一個環節整個流程就斷了。就像做菜的時候,少了一味調料可能不影響能不能吃,但少了一道關鍵工序,這道菜可能就做不出來。
實驗結果顯示,在全部75個查詢上,DSR相對於強力的SkillRouter基線（這個基線本身已經用了一個學習出來的重排序模型,不是簡單的向量匹配）,在前20個結果里把召回率從0.754提升到了0.768,完全覆蓋率從0.560提升到了0.573。這個提升幅度看起來不算驚艷,但要注意,DSR並沒有改變底層的檢索模型和評分模型,只是改變了"怎麼把打好分的候選組合起來"這一步,單靠這一步就能拿到提升,說明選擇策略本身確實存在優化空間。
真正讓差距拉開的是更長的候選列表。在前50個結果里,DSR把整體召回率從0.754提升到了0.808,完全覆蓋率從0.560提升到了0.633，多出7個百分點。而在多技能查詢這個子集上,差距更明顯：完全覆蓋率從0.458提升到了0.551,提升了將近10個百分點。
這個數據背後的含義是：當任務越複雜、需要的技能越多樣,DSR相對傳統方法的優勢就越大。這跟設計初衷是吻合的,因為單技能任務本身就不存在"冗餘"問題,只有一個正確答案要找,DSR和普通排序方法在這種任務上表現幾乎一樣(前10個結果里,兩者的召回率和完全覆蓋率完全相同,都是0.875)。
研究團隊還做了細緻的消融實驗,用來驗證"查詢殘差核"這個設計到底有多關鍵。他們把DSR里的多樣性計算換成最普通的原始餘弦相似度核（也就是不做任何殘差處理,直接拿兩個技能的原始向量算相似度）,結果在多技能查詢上,前10個結果的完全覆蓋率從0.441狠狠跌到了0.254,幾乎打了對摺。
這組對比數據說明了一件很重要的事：如果直接套用標準的多樣性算法,不做殘差處理,效果反而比不用DPP還要糟糕。因為標準餘弦核會不分青紅皂白地懲罰所有相似性,把那些"因為都跟查詢相關而略顯相似,但功能完全互補"的技能一併踢出局,這正是前面提到的那個陷阱在實驗數據里的具體體現。
如果把這個消融實驗換個角度理解會更直觀。假設你在挑選團隊成員時用了錯誤的"多樣性"標準,比如你覺得"性別不同就算多樣",於是刻意避開跟你性別相同的候選人,結果可能選出一群性別各異但專業能力高度雷同的人。這種表面上的"多樣性"完全沒有解決實際問題,反而可能因為矯枉過正把真正合適的人選給排除了。DSR的查詢殘差核想解決的,正是"用錯誤的維度去衡量多樣性"這個陷阱。
論文還比較了不同排序策略的表現，包括純向量檢索、零樣本大模型重排序（直接讓Qwen3-8B這個模型對候選技能評分排序,不做額外訓練）、學習出來的SkillRouter重排序模型,以及DSR。結果顯示零樣本大模型重排序的效果反而不如專門訓練過的重排序模型,說明單純依靠通用大模型的判斷力,在面對成千上萬個高度相似的候選技能時,精細辨別能力還是不夠的。
這套方法留下的問題
DSR的整套方案建立在一個前提之上：檢索階段已經把真正需要的技能撈進了候選池裡。如果一開始的粗篩就漏掉了某個關鍵技能,後面無論多樣性算法設計得多精妙,都沒辦法把它撈回來。這就好比你去菜市場買菜,如果你壓根沒有走到賣豆腐的那個攤位,那不管你在已經走到的攤位前怎麼精心搭配,豆腐永遠不會出現在你的菜籃子裡。DSR解決的是"從已有候選里怎麼選"的問題,不是"候選池本身夠不夠全"的問題,這兩者是不同層面的挑戰。
另外,論文用的評估指標是召回率和完全覆蓋率,這些都是"技能有沒有被找到"層面的指標,並不直接衡量智能體最終任務完不完成。就算所有需要的技能都被正確檢索出來了,智能體在實際執行時仍然可能因為工具用錯了順序、規劃出了問題,或者技能之間的指令產生衝突而失敗。這中間還隔著一層沒有被這篇論文覆蓋的距離。
從更早期的工作看,這個研究方向的演進路徑其實挺清晰。2023年的Toolformer和HuggingGPT解決的是"模型要不要用工具、怎麼用一個工具"的問題,規模都不大。2023年底的ToolLLM把工具數量擴展到了上萬個,開始觸及規模化的門檻。而SkillRouter把這個規模又提高了一個量級到八萬,同時明確指出了"完整技能實現比名字描述更有資訊量"這個此前被忽略的細節。DSR站在這些工作的基礎上,往前邁的這一步是把"選技能"從單純的相關性排序問題,重新定義成了一個需要兼顧多樣性的組合優化問題。這個思路上的轉變,可能比某個具體的技術實現更值得記住。
寫在後面
讀這篇論文時,最觸動我的其實是那個"查詢殘差"的設計細節,它解決的不是一個高深的數學難題,而是一個非常樸素的認知陷阱：我們太容易把"因為相關而相似"和"因為重複而相似"混為一談。這個陷阱不只存在於技能路由里,幾乎存在於任何需要"挑選一組東西"的場景中,比如你在Netflix上被推薦了五部風格接近的電影,系統可能覺得它們都"符合你的口味",卻沒意識到你可能只是最近看了一部懸疑片,系統把"懸疑"這個共性當成了你的核心偏好,反而漏推了你真正想看的其他類型。
論文裡那組消融實驗的數據也值得單獨說一說：完全覆蓋率從0.441掉到0.254,幾乎是腰斬。這說明"加了多樣性算法"這件事本身不一定帶來提升,如果多樣性的衡量標準是錯的,反而可能比什麼都不做還糟糕。這個反直覺的結果提醒人,好的想法如果實現細節出了岔子,效果可能比原始方案更差,這在很多工程實踐里都是容易被忽視的一課。
這套思路還留下一個沒被回答的問題：當技能庫繼續膨脹到百萬級、千萬級規模時,現在這套"先粗篩再精排"的兩階段流程還能撐住嗎?候選池的粗篩環節本身要不要引入多樣性考量,而不是只在最後一步做?這個問題目前還沒有答案,但順著這篇論文往前想,似乎是個繞不開的方向。
Q&A
Q1：Diverse Skill Routing（DSR）是什麼？
A：DSR是一種面向大語言模型智能體的技能路由框架,它用行列式點過程（DPP）在候選技能中挑選出既跟用戶查詢相關又互相不重複的技能組合,而不是像傳統方法那樣只按相關性分數排序取前幾個。
Q2：DSR相比傳統的技能排序方法有什麼優勢？
A：在SkillRouter基準測試上,DSR在多技能查詢的完全覆蓋率上比傳統重排序方法高出近10個百分點,尤其在需要多個技能配合完成的複雜任務上優勢更明顯,單技能任務上兩者表現基本一致。
Q3：查詢殘差多樣性核解決了什麼問題？
A：它解決了"因為都跟查詢相關而顯得相似"和"真正功能重複"被混淆的問題。如果直接用普通相似度算法懲罰所有相似技能,會把本該保留的互補技能誤刪,實驗顯示這會讓完全覆蓋率從0.441跌到0.254。
