大語言模型驅動的 Agent 正在變得司空見慣，但一個容易被忽略的瓶頸在於：當技能庫膨脹到幾百個條目時，Agent 到底應該如何決定載入哪些技能、按什麼順序執行？把所有技能一股腦塞進上下文，不僅開銷巨大，也無法提供任何執行順序上的結構。最近 arXiv 上的一篇論文（編號 2608.06196）直接對比了兩種主流檢索方案，結論頗為反直覺：精心構造的知識圖譜，並沒有打敗一個樸素的混合排序器。
兩種路線的正面交鋒
論文在包含 690 個技能的語料上評估了兩套系統。第一套是 混合排序器，將詞法匹配與稠密向量檢索結合，做稀疏的按需載入。第二套是 型別化知識圖譜，把前置條件、資料流、先後順序等工作流關係編碼成帶型別的邊，並讓 LLM 生成這些邊。研究者用了 117 個現實且非回顯的查詢——所謂非回顯，是指查詢不是直白地抄技能名，而是以自然語言描述一個具體任務，這顯然更貼近實際使用場景。
結果顯示，混合排序器把正確技能排進前五的比例是 73.5%±8.0，意味著大約四分之一的查詢沒有被覆蓋。而如果按照設計意圖，把圖譜鄰居作為額外結果替換進排序器的輸出（保持 token 預算一致），圖譜的表現反而顯著變差，差距達到 11.2 個百分點（p=0.0007）。換句話說，在同樣成本下，圖譜不但沒有帶來增益，還拖了後腿。
為什麼圖譜沒有想象中管用
論文給出了一個很機制化的解釋：圖譜的候選邊其實是從排序器已經搜尋過的嵌入鄰域裡抽出來的。統計顯示，98.6% 的型別化邊連線的都是排序器早已同時召回的技能。也就是說，圖譜能做的只是重新描述排序器已經發現的關係，並沒有把檢索的邊界向外推哪怕一步。LLM 生成的邊緣層也沒能帶來增量，其貢獻比不過直接用本地嵌入得到的鄰居。
更值得警惕的是評估方法帶來的幻覺。研究者發現，如果用作者自己編寫的查詢來測，hit@5 會被高估最多 44 個點——這個差異足以掩蓋一個方案的完全無效，讓看似合理的結論變得毫無說服力。論文認為，他們的核心貢獻是提供了一個機制性的說明：為什麼把結構加到強排序器上並不能提升召回，以及在什麼條件下結構依賴才會真正有益。
理解「為什麼沒用」有時候比「什麼有用」更有價值。這篇論文的嚴謹之處在於，它把圖譜的侷限歸結為預過濾拓撲邊界，並公開了所有對比資料。
對 Agent 開發者的三個落點
- 先打磨排序器：在技能檢索這件事上，一個訓練良好的混合排序器可能已經拿到了大部分收益，投入圖譜之前先確認檢索基線的上限。
- 別讓圖譜變成迴音壁：只有當圖譜的邊能引入排序器接觸不到的外部資訊（比如跨技能的經驗規則）時，結構才值得付出額外成本。
- 用真實查詢做評估：隨手寫幾個查詢來驗證方案，很容易得出高估的結論。儘量收集真實使用中產生的請求，或者使用非回顯的自然語言任務。
這篇文章沒有推翻任何已有系統，但它給出了一個非常實用的基線資料：在大規模技能庫場景下，一個不錯的混合檢索器可能已經解決了絕大部分問題，額外的結構化知識需要拿出更有說服力的收益來證明自己。對於正在為 Agent 設計技能層或記憶機制的團隊，這是一篇值得精讀的實證參考——至少可以幫你省下幾個月的彎路。
評論
暫無評論
成為第一個評論的人