宅中地 - 每日更新
宅中地 - 每日更新

贊助商廣告

X

清華大學團隊教會AI「壓縮技能說明書」:讓智能助手又快又准地執行複雜任務

2026年06月18日 首頁 » 熱門科技

這項由清華大學電腦科學與技術系主導的研究成果,以預印本形式發布於2026年6月,論文編號為arXiv:2606.12203v1,感興趣的讀者可通過該編號在arXiv平台查閱完整論文。

**研究概要**

每當你打開一個AI助手,讓它幫你完成一項複雜任務——比如查詢資料庫、編寫代碼、或者按照特定步驟解決問題——背後往往有一份"技能說明書"在默默發揮作用。這份說明書告訴AI:面對這類問題,你應該先做什麼、再做什麼、調用哪些工具、注意哪些規則。

問題在於,這份說明書有時候非常冗長,動輒幾千個字。而AI每次處理任務,都需要把這整份說明書完整地"讀一遍"才能開始工作,就像一個廚師每次炒菜前都要把整本菜譜從第一頁翻到最後,哪怕今天只做一道簡單的番茄炒蛋。這種重複閱讀帶來了巨大的時間和計算成本,在大規模使用時尤為突出。

清華大學的研究團隊提出了一個解決方案,名叫SKIM(SKIll coMpression,技能壓縮)。這套方法的核心思路,是把冗長的技能說明書"濃縮"成一組精煉的"速記符號",讓AI能以少得多的處理量完成同樣質量的任務。壓縮後的說明書只有原來的30%到60%,但執行效果與完整版幾乎不相上下——有時甚至還略勝一籌。

---

**一、為什麼AI需要"技能說明書",壓縮它又有多難**

要理解這項研究解決了什麼問題,先得明白AI助手是怎麼工作的。

現代大型語言模型(就是GPT、Qwen、Phi這類AI大腦)天生有通用能力,但在特定領域往往需要額外的引導。於是,開發者們發明了一種叫做"技能"(Skill)的東西。技能通常是一個Markdown格式的文本文件,裡面寫清楚了:在什麼情況下啟動這項能力、具體操作流程是什麼、需要調用哪些外部工具、工具的參數格式是什麼、遇到什麼情況要注意什麼。

可以把技能想像成一份詳細的"操作手冊",而不是一本食譜。食譜告訴你"放多少鹽",操作手冊則告訴你"先檢查設備電源是否接通,若接通則按下啟動鍵,等待三秒鐘,如果指示燈變綠則進入下一步……"。這種手冊式的內容對執行順序和邏輯鏈條有極強依賴,少了任何一環,整個流程就可能崩潰。

圍繞技能的生態正在快速發展。類似"OpenClaw"和"ClawHub"這樣的平台,已經聚集了大量開發者共享和下載各類技能文件,就像一個軟體應用商店。研究數據顯示,平台上的技能平均超過2000個字符,有些甚至超過10000個字符。這意味著每次調用技能,AI都要在"思考區"里塞入幾千字的操作手冊,計算量相當可觀。

更重要的是,由於用戶可以自由修改這些技能文件並在不同設備上部署,傳統的"緩存重用"方法(把上次處理過的內容直接拿來用)幾乎不可行——每次文件稍有改動,緩存就失效了。

於是,"壓縮技能文本"的想法自然浮現。然而,現有的文本壓縮方法都是為另一類任務設計的。那些方法擅長壓縮"知識型文檔"——比如一篇百科文章,壓縮後只要保留關鍵事實就行。但技能說明書不是這樣的東西,它包含的是"程序性知識",是一環扣一環的操作邏輯。如果你把一份資料庫查詢操作手冊壓縮了,但把"先加載資料庫,再篩選日期,再提取欄位值"這個順序破壞了,整個查詢就會返回錯誤答案。

研究團隊用一個具體實驗說明了這個問題。他們用當時流行的上下文壓縮方法ICAE來壓縮一份咖啡期貨價格資料庫的查詢技能。當用戶問"這個資料庫包含哪些列"這種純事實性問題時,ICAE壓縮效果很好,能正確回答"Date、Open、High、Low、Close、Volume、Currency"。但當用戶問"2001年12月6日咖啡的開盤價是多少"這種需要按步驟執行資料庫操作的問題時,ICAE處理後的AI直接輸出了一個憑空捏造的數字"123.00",完全沒有按照手冊規定的流程去查詢。而SKIM處理後的AI則老老實實地執行了完整流程:先加載資料庫,再按日期篩選,再提取開盤價欄位,最終正確得出答案"42.75"。

這個對比揭示了核心挑戰:壓縮技能說明書,不是在刪減次要資訊,而是在保全一個完整的操作邏輯鏈條。

---

**二、SKIM是怎麼工作的:把說明書翻譯成"暗語"**

SKIM的設計思路可以用一個比喻來理解:把詳細的操作手冊翻譯成一套老員工之間才懂的"行話暗語"。新員工需要看完整的手冊,但一個經過專門訓練的老員工,聽到幾句簡短的暗語就知道該怎麼做了。

具體來說,SKIM的核心結構由四個部件組成,彼此協作完成"翻譯"工作。

第一個部件是"壓縮器",本質上是一個語言模型,負責閱讀原始技能說明書。它在閱讀過程中會遇到一組特殊的"槽位符號",這些符號沒有固定意義,是專門學出來的占位符,就像那些行話暗語的載體。壓縮器讀完說明書後,會把關鍵資訊"吸收"進這些槽位符號里,形成一組密集的"隱藏狀態"向量。

第二個部件是"投影器",它是一個三層的小型神經網路,負責把壓縮器生成的隱藏狀態向量,轉換成目標AI大腦能直接理解的格式。因為不同的AI大腦有不同的"語言體系",投影器相當於一個翻譯官,確保暗語被正確理解。

第三個部件是"軟標記前綴",也就是最終壓縮結果——一組連續數值向量,不是人類能讀的文字,而是AI大腦能直接解析的數學表示。這些向量被預先計算好,儲存起來,等到用戶發起請求時直接加載,無需重新計算。

第四個部件是"LoRA適配器",一個輕量級的參數調整模組,附加在目標AI大腦上。它的作用是讓目標AI學會"讀懂暗語"——即使接收到的是壓縮後的軟標記而非原始文字,也能正確理解並執行相應的操作流程。

這四個部件的協作流程是這樣的:在系統部署前,壓縮器讀取技能說明書,生成軟標記向量,儲存好。用戶發起請求時,系統直接加載預存的軟標記,激活LoRA適配器,把軟標記和用戶問題一起送給目標AI,AI就能在更短的"閱讀"時間裡完成高質量的任務執行。

---

**三、多解析度設計:根據說明書的複雜程度選擇不同的壓縮力度**

不同的技能說明書複雜程度差異極大。有的技能只有幾條簡單規則,有的則包含十幾個步驟、多種工具調用和複雜的條件判斷。把它們都壓縮到同樣大小,就像把一本薄薄的自行車組裝說明和一本厚厚的汽車維修手冊都塞進同一個小抄——前者綽綽有餘,後者肯定裝不下。

為此,SKIM引入了"多解析度"機制。系統支持兩種壓縮預算:256個軟標記和512個軟標記。256個標記是較激進的壓縮,512個標記保留了更多細節。在訓練階段,系統同時在兩種預算下進行優化,使得壓縮器學會產生一種特殊的向量序列——取前256個是低解析度版本,取全部512個是高解析度版本,兩個版本都能有效工作。

這個設計有個很妙的工程優勢:只需要儲存一份512標記的向量文件,需要低解析度時直接截取前半段即可,不需要為每種壓縮率單獨存一份文件。

在實際部署時,系統還會針對每一份技能說明書自動選擇合適的壓縮解析度。這個過程叫做"離線自判斷",具體方法是:先讓目標AI基於完整原版說明書回答10道測試題,記錄這些"標準答案";然後分別用256和512軟標記版本回答同樣的測試題;再由AI自己比較壓縮版答案和標準答案的吻合程度,計算每種壓縮率的準確率。如果256標記版本的準確率達到90%以上,就選256;否則嘗試512;如果兩者都不達標,就回退到使用完整原版說明書文本。這整個檢驗過程在伺服器上線前完成,用戶請求到來時不會增加任何額外延遲。

這種"因材施教"的策略效果顯著。對於邏輯推理類任務(如LogicBench),大量技能只需要256個軟標記就夠用了;而對於代碼生成類任務(如BigCodeBench),由於技能內容複雜,系統會更多地保留512標記甚至回退到完整文本。

---

**四、三階段漸進式訓練:從認字到理解到會用**

SKIM能如此精準地保留操作邏輯,背後是一套精心設計的三階段訓練體系。可以把這三個階段想像成培訓一名新員工的過程:先讓他熟悉公司所有的操作手冊(認字階段),再讓他練習回答實際工作中的操作問題(理解階段),最後讓他在真實任務上接受考核(實戰階段)。

第一階段叫"技能重建"。系統從網際網路上收集了大量技能文件(共約6萬份,均來自GitHub倉庫,過濾掉短於500字符的低質量文件)。在這個階段,目標AI保持凍結狀態不參與訓練,系統主要訓練壓縮器和投影器,目標是讓它們能把一份技能說明書壓縮成軟標記,然後由目標AI從這些軟標記中重建出原始文本。這就像訓練一個翻譯員,先確保他的"翻譯"能完整還原原文,而不會遺漏關鍵資訊。訓練損失函數要求在多種解析度下同時最小化重建誤差,迫使系統學會能適應不同壓縮率的表示。

第二階段叫"程序性問答預熱"。這一階段面臨一個數據稀缺問題:真正帶標註答案的技能執行數據非常少,而訓練需要大量樣本。研究團隊巧妙地借用了WikiHow數據集——這是一個包含數十萬篇"怎麼做XXX"文章的大型數據集,每篇文章標題就是問題,文章正文是操作說明,摘要就是簡短答案,天然構成了"操作文檔+問題+答案"的格式,共處理了約21.4萬個訓練樣本。這個階段目標AI仍然凍結,主要訓練壓縮器學會把程序性內容(如何一步步操作)壓縮成能支持問答的形式,而不僅僅是能重建文字。這相當於讓翻譯員不只能逐字翻譯,還能從翻譯中回答"第三步要做什麼"這類問題。

第三階段叫"技能任務對齊"。這是最關鍵也是最複雜的階段,目標是讓整個系統真正勝任實際技能任務。這一階段使用了約6萬個基於真實技能文件生成的訓練樣本,每個樣本包含一個實際技能說明書、一個相關用戶問題和一個詳細答案(或多輪推理軌跡)。目標AI在這個階段開啟LoRA參數更新,壓縮器、槽位符號和投影器也同時繼續訓練。

為了生成這些訓練樣本,研究團隊動用了GPT-5.2作為質量評估員,讓它先篩選出真正包含有價值操作知識的技能文件,再生成有實際意義的用戶問題,並標註該技能是否涉及工具調用、是否適合多輪推理等屬性。

針對技能中常見的工具調用場景(比如查詢資料庫、調用API),研究團隊合成了ReAct風格的多輪推理軌跡——即"思考→行動→觀察→思考→行動→觀察……"的交替格式。由於無法真正接入各種外部工具,研究團隊用目標AI自身來模擬工具的響應:給定工具的接口定義、當前問題和已執行的操作記錄,讓AI生成"如果真的調用了這個工具,它應該返回什麼"。雖然是模擬的,但這種方式讓系統學會了正確的工具調用流程和格式。

針對"多技能組合"場景(即一個問題需要同時用到多份操作手冊),研究團隊採用了一種"自頂向下拆分"策略:把一個複雜的技能說明書拆分成多個獨立的子技能說明書,每個子技能單獨壓縮成軟標記,然後把這些軟標記序列拼接起來送給目標AI。這樣訓練出來的系統,在推理時面對真實的多技能場景也能正確處理。

整個第三階段完成後,LoRA適配器被"凍結"成一個共享模組,對所有技能通用,包括訓練期間從未見過的新技能。這意味著當有人上傳一個全新的技能文件時,系統只需要用壓縮器做一次前向計算生成軟標記,不需要重新訓練任何參數,整個更新過程非常輕量。

---

**五、實驗驗證:真實任務上的全面比拼**

為了驗證SKIM的效果,研究團隊在五個各具特色的任務數據集上進行了測試,覆蓋了代碼生成、數學推理、邏輯推理、定理問答和工具使用問答等不同類型,並與多種基線方法進行了詳細比較。

這五個數據集分別是:BigCodeBench(1140道代碼生成題,每題平均需要2.76份技能說明書)、CHAMP(223道競賽級數學推理題)、LogicBench(760道邏輯推理題)、TheoremQA(747道定理問答題)和ToolQA(1430道需要工具交互的問答題)。所有數據集的技能內容均來自SRA-Bench項目提供的標準金標註,確保了比較的公平性。

測試使用了兩個目標AI:Qwen3-8B(壓縮器也是Qwen3-8B)和Phi-4 14B(壓縮器是更小的Phi-4-mini-instruct 3.8B)。這兩個配置代表了不同模型家族和不同體量的組合。

比較對象包括:不使用任何技能說明書的"裸跑"模式(Naive)、使用完整原版說明書的"全文"模式(Full Text),以及三種壓縮方法——LLMLingua-2(刪減離散文本標記的"硬壓縮"方法)、ICAE(軟標記壓縮方法)和500xCompressor(另一種軟標記壓縮方法)。

實驗結果呈現出幾個清晰的規律。

首先,使用完整技能說明書普遍比不用技能更好,證明技能內容確實有價值。但代價是每道題平均要多讀幾百到幾千個標記,計算開銷不小。

其次,ICAE和500xCompressor這兩種為事實性文檔設計的軟壓縮方法表現很差,在多個任務上甚至比不用任何技能還糟糕,充分說明技能壓縮不能簡單套用知識壓縮的方法。

再看LLMLingua-2的表現:這種方法通過刪減不重要的詞來縮短文本,在壓縮率為30%時(即保留30%原文)效果相當有限,在55%和70-75%時效果有所提升,但在相同標記預算下,它的任務完成率系統性地低於SKIM。

SKIM的三種配置(固定256標記、固定512標記、自適應選擇)都明顯優於LLMLingua-2。以Qwen3-8B在CHAMP數學推理任務為例:全文模式準確率為68.16%,SKIM自適應版本達到65.92%,而同等標記預算下的LLMLingua-2僅為57.40%。SKIM自適應版在只用全文模式約73%的標記數量下,取得了與全文模式相差不到3個百分點的準確率。

在BigCodeBench代碼生成任務上,Qwen3-8B的全文模式準確率為49.30%,SKIM自適應版本達到46.93%,而ICAE和500xCompressor分別只有29.47%和0.18%,LLMLingua-2中等配置(55%壓縮率)為43.60%。

工具使用任務ToolQA展示了SKIM在多步驟推理場景中的優勢。Qwen3-8B上,SKIM自適應版本達到46.92%,幾乎追平全文模式的47.97%,而ICAE和500xCompressor均接近0%,說明這類方法完全破壞了工具調用的操作流程。

研究還特別測試了一個"壓力場景":在每個問題的標準技能集合中,額外添加通過語義檢索得到的干擾技能,直到每個問題有五份技能說明書(其中大多是干擾項),以此模擬真實系統中的噪聲干擾和超長上下文。結果顯示,在這種壓力場景下,SKIM在可比標記預算下仍然優於LLMLingua-2。對於Phi-4模型,由於其上下文窗口較短(16k標記),完整加載五份技能說明書已經幾乎占滿上下文,導致全文模式反而不如高解析度SKIM壓縮版本——這正體現了SKIM在緩解上下文壓力方面的實際價值。

---

**六、消融實驗:逐一檢驗每個設計決策**

為了驗證SKIM各個組成部分的必要性,研究團隊進行了一系列"拆解實驗",逐一檢驗每個設計選擇是否真的起到了作用。

在訓練階段的消融實驗中,研究團隊分別去掉三個階段中的某一個,觀察性能變化。結果表明,單獨使用技能重建階段或程序性預熱階段,並不足以支撐下游任務;必須有第三階段的技能任務對齊,系統才能真正學會執行實際的技能相關任務。同時,即便保留第三階段,去掉第一或第二階段也會導致明顯的性能下降,說明三個階段是相互依賴、缺一不可的。

另一個有趣的測試是:如果把第三階段的技能任務數據替換成HotpotQA(一個多跳問答數據集),而不是技能相關的數據,性能明顯下降,說明系統確實需要在技能場景下進行專門的訓練。此外,如果用GPT-5.2生成的高質量答案替換目標模型自己生成的答案作為訓練標籤,效果反而更差——這說明訓練數據應該來自目標模型本身的分布,而非更強模型的"越級指導"。

關於多解析度設計,研究團隊測試了64、128、256、384、512這五個標記預算,其中只有256和512在訓練時使用過,其餘三個是通過截取向量前綴得到的"零樣本"解析度。結果顯示,即使是從未在訓練中出現過的128標記預算,其表現也明顯高於完全不使用技能的裸跑模式,說明多解析度表示具有良好的泛化能力。隨著標記數量從64增加到512,準確率穩步提升,在接近512標記時逼近全文模式水平。

關於LoRA適配器的必要性,研究將目標AI完全凍結(不使用LoRA)與不同秩的LoRA設置進行比較。凍結目標AI時,性能明顯低於任何LoRA配置,說明目標AI確實需要適應軟標記這種新型輸入格式。小秩LoRA(rank=4)已經能恢復大部分性能提升,更大秩的LoRA帶來的額外增益有限,說明rank=16是性價比不錯的選擇。

---

**七、實際部署:像發布軟體包一樣分發壓縮技能**

SKIM的設計不只考慮了性能,還充分考慮了在真實生態中的可用性。

從開發者的角度來看,當一個新技能文件上線或現有技能被修改時,更新流程非常簡單:用壓縮器做一次前向計算,生成新的軟標記向量,儲存好。如果修改內容較大,再跑一遍離線自判斷選擇合適解析度。整個過程不涉及梯度計算,不需要GPU集群,普通機器上幾秒鐘就能完成——這與之前的TokMem方法形成了鮮明對比,TokMem需要對每一個新技能進行昂貴的梯度優化,在技能頻繁更新的社區環境下幾乎不可用。

從系統架構的角度來看,SKIM的軟標記文件可以像一個預編譯的軟體包一樣分發。一個技能文件的發布者,可以為不同主流AI大腦各生成一份對應的軟標記包(因為不同AI有不同的嵌入空間,投影器需要特定於目標模型),打包發布到ClawHub之類的平台。下載者不需要處理原始文本,直接加載軟標記包即可在本地運行該技能,就像下載一個已編譯好的應用程式而不是源代碼。

在線推理時,現代推理引擎(如vLLM)支持動態加載和切換LoRA適配器,開銷極小。對於不需要任何技能的普通查詢,系統可以關閉LoRA適配器,回到基礎模型模式,保持原有能力不受影響。

當然,這套設計也有其局限性。由於投影器和LoRA適配器是針對特定目標AI訓練的,一份壓縮好的軟標記包無法直接在不同AI大腦間通用。如果一個技能需要支持多個不同的目標AI,就需要為每個目標AI各維護一份軟標記包。研究團隊也在論文的局限性部分坦承了這一點,並提出了未來可以研究"統一壓縮器+目標特定投影器"的架構,以降低儲存開銷。

---

歸根結底,SKIM解決的是一個非常現實的效率問題:當AI助手需要大量技能來完成複雜任務時,每次都讀完整的操作手冊既慢又貴。而SKIM給出的答案是——不必讀完整手冊,只需讀一份精煉的暗語版本,效果幾乎一樣好,有時甚至更好。

這項研究的價值不只在於技術方法本身,更在於它清晰地指出了一個長期被忽視的問題:壓縮"怎麼做"和壓縮"是什麼",是兩件完全不同的事情。就像壓縮一道菜譜的"烹飪步驟",和壓縮一段介紹菜品歷史的文字,需要的不是同一套方法。

隨著AI智能體系統越來越普及,技能生態的規模也會持續擴大。如何讓這些技能在保持高效的同時不犧牲準確性,會是一個持續重要的課題。對這個方向感興趣的讀者,可以通過arXiv編號2606.12203查閱完整論文,代碼也已在GitHub上公開(倉庫名:bebr2/SKIM)。

---

**Q&A**

Q1:SKIM壓縮後的技能說明書,AI真的能完整執行原本的操作流程嗎?

A:SKIM專門針對操作流程的保留進行了訓練,通過三階段漸進式訓練,尤其是第三階段的技能任務對齊,讓AI學會從壓縮後的軟標記中還原操作邏輯。實驗結果顯示,在ToolQA這類需要多步工具調用的任務中,SKIM的準確率接近使用完整原文的水平,而普通壓縮方法的準確率幾乎為零。

Q2:SKIM的軟標記文件可以在不同AI模型之間通用嗎?

A:不能直接通用。由於每個AI大腦有不同的內部向量空間,SKIM需要為每個目標AI單獨訓練投影器和LoRA適配器,生成的軟標記包也只能用於對應的目標模型。如果一個技能要支持多個AI,就需要為每個AI分別生成一份軟標記包,儲存開銷會相應增加。

Q3:SKIM和普通文本壓縮方法(比如LLMLingua-2)相比有什麼本質區別?

A:最根本的區別在於壓縮目標的不同。LLMLingua-2通過刪除不重要的詞來縮短文本,保留的是顯式的語言內容,但容易破壞操作步驟之間的邏輯連接。SKIM則把技能內容轉換成連續的數值向量(軟標記),通過專門的訓練確保這些向量攜帶完整的操作流程資訊,目標AI通過LoRA適配器學會解讀這些向量並正確執行對應的任務。

宅中地 - Facebook 分享 宅中地 - Twitter 分享 宅中地 - Whatsapp 分享 宅中地 - Line 分享
相關內容
Copyright ©2026 | 服務條款 | DMCA | 聯絡我們
宅中地 - 每日更新