在很長一段時間里大家討論大模型落地時重心都放在“提示詞工程”。同一道題換個措辭效果可能天差地別。于是出現(xiàn)了各種長篇模板、CoT 鏈、Few-shot 示例堆疊。這種方法在小規(guī)模驗證時很有效但一旦進入生產(chǎn)環(huán)境問題就暴露了上下文越來越長、單次調(diào)用越來越貴、推理延遲越來越高而且模型對提示詞的微小擾動非常敏感。圍繞這些問題業(yè)界開始嘗試另一條路線把技能蒸餾進權重而不是寫進提示詞。這個思路的技術表達是 “Distill Skills into Weights, Not Prompts”其核心是讓模型在訓練階段就把可復用的抽象技能內(nèi)化到參數(shù)中推理時不再依賴冗長的提示詞描述。本文將圍繞這一主題拆解其中的關鍵概念抽象技能、特權信號、在線策略自蒸餾以及它們的組合方式。會先解釋概念本身再給出一套可落地的訓練流程示意最后聊一聊工程化過程中常見的坑。1. 背景提示詞工程的邊界在哪里1.1 提示詞方案的三個硬傷先看一個典型場景。假設業(yè)務上需要模型完成“從用戶對話中提取結構化訂單信息”的任務。用提示詞方案通常是寫一段很長的描述告訴模型字段含義、抽取規(guī)則、輸出格式然后在線調(diào)用時把這段描述拼到輸入前面。這樣做的第一個問題是Token 成本。描述本身可能占幾百甚至上千 Token每次請求都要重復攜帶。如果業(yè)務流量是每天幾百萬次調(diào)用這部分開銷會被急劇放大。第二個問題是上下文長度。提示詞越長留給真實用戶輸入的空間就越少。尤其在需要結合多輪對話、歷史記錄、知識庫片段時提示詞模板和業(yè)務數(shù)據(jù)會互相爭搶上下文窗口。第三個問題是穩(wěn)定性。提示詞本質(zhì)上是在“約束”模型的行為但模型的注意力分布并不完全可控。順序換一下、標點改一下、示例數(shù)量變一下結果可能就不一樣。開發(fā)團隊需要不斷調(diào)試措辭維護成本很高。1.2 把技能固化到權重一種更本質(zhì)的做法如果換個思路在離線訓練階段把“如何抽取訂單信息”這個過程變成模型參數(shù)里的一種先驗。推理時模型不再需要看到一段長描述而是直接“會做這件事”。這就是把技能蒸餾進權重。從工程角度看這種做法的優(yōu)勢非常直觀推理時不再攜帶大量模板上下文更短成本更低技能的觸發(fā)更加自動化不再依賴用戶措辭碰巧命中提示詞行為一致性由參數(shù)保證而不是由提示詞臨場約束。當然這條路也有代價訓練成本更高、數(shù)據(jù)準備更復雜、模型迭代周期更長。因此理解其原理比復制一行代碼更重要。2. 核心概念技能、特權信號與自蒸餾要理解 “Distill Skills into Weights, Not Prompts”先要理清三個概念抽象技能、特權信號、在線策略自蒸餾。2.1 抽象技能是什么技能Skill在這里不是指某個具體回答而是指“面對一類狀態(tài)時采取的一系列決策動作”。它面向的不是單次問答而是可復用的行為模式。舉一個例子在修 bug 的場景中“先定位日志異常、再縮小函數(shù)范圍、接著修復并回歸測試”這是一個技能在數(shù)據(jù)分析場景中“先了解字段語義、識別缺失值、分布異常再建模”也是一個技能。抽象技能Abstract Skill則是把這類行為模式從具體實例中提煉出來去掉細節(jié)只保留可遷移的策略骨架。比如“根據(jù)報錯關鍵字搜索代碼位置”這個技能既可以用于 Python 項目也可以用于 Java 項目。在蒸餾框架中抽象技能通常不是人工逐條編寫的而是通過數(shù)據(jù)聚類、自動歸納或者由更強模型從軌跡中總結得到。2.2 特權信號Privileged Signals特權信號這個詞來自機器人控制和模仿學習領域原意是指訓練時可以利用、但推理時拿不到的信息。舉一個直觀的例子。訓練一個自動駕駛模型時如果給模型看“障礙物的精確坐標”來學習避障這就是特權信號——真實部署時攝像頭只能給像素給不了精確坐標。但在訓練階段這些信號可以加快模型收斂。放在自蒸餾場景里特權信號可以指全局最優(yōu)策略給出的動作訓練時對未來環(huán)境的“提前觀察”由更大模型產(chǎn)出的高質(zhì)量中間決策軌跡級別的人工標注反饋。關鍵是特權信號只在教師側使用不進入學生模型推理時的輸入。2.3 在線策略自蒸餾蒸餾Distillation通常指把大模型/教師模型的知識遷移到小模型/學生模型。而在線策略自蒸餾On-Policy Self-Distillation有幾個特點教師和學生不是完全固定的訓練過程中會同步更新訓練數(shù)據(jù)是模型自己在環(huán)境交互/采樣過程中產(chǎn)生的也就是在線策略學生不僅學教師的輸出還從自身的探索反饋中學習并讓技能逐漸內(nèi)化。這種方式不同于離線蒸餾使用靜態(tài)數(shù)據(jù)集它更接近強化學習中的自我對弈模型一邊探索一邊把探索到的好行為蒸餾進自己的參數(shù)。3. 為什么“蒸餾進權重”優(yōu)于“寫進提示詞”前面講了概念這一節(jié)做更細致的對比。可以用一張表快速看清楚兩條路線的差異對比維度提示詞方案權重蒸餾方案推理成本每次攜帶長模板Token 開銷大無模板開銷上下文更短推理延遲長上下文導致預填充耗時增加輸入更短首 Token 延遲更低行為一致性受措辭影響波動較大參數(shù)固化穩(wěn)定性更好技能維護模板散落在代碼和配置中集中在訓練數(shù)據(jù)和評估流程中可解釋性可直接閱讀提示詞需要額外解釋性工具更新代價修改提示詞即可速度快需要重新訓練/微調(diào)周期長泛化能力依賴提示詞覆蓋度技能抽象程度決定泛化邊界從這張表可以看到提示詞方案的最大優(yōu)勢是“快”改一行文本就能上線。而權重蒸餾方案的優(yōu)勢在于“穩(wěn)”和“省”一旦技能固化生產(chǎn)環(huán)境里的表現(xiàn)會更可靠單位請求成本也更低。從技術演進的角度看兩者并不是完全互斥的。很多團隊的實際落地路徑是先用提示詞做原型驗證驗證技能的可行性后再收集數(shù)據(jù)、蒸餾到權重中最終在推理階段去掉長提示詞。4. 在線策略自蒸餾的技術框架理解了概念下面看具體的訓練框架拆解。這里的框架不限定具體某個模型庫而是給出通用的抽象結構方便讀者對照自己的項目進行調(diào)整。4.1 整體流程整個訓練流程可以分成五個階段定義技能空間確定模型需要具備哪些可復用技能。這一步可以由專家梳理也可以用聚類算法從軌跡數(shù)據(jù)中挖掘。準備在線采樣環(huán)境模型在任務環(huán)境中持續(xù)交互產(chǎn)生軌跡數(shù)據(jù)。這部分數(shù)據(jù)是“在線策略”的來源。生成特權信號在每條軌跡上利用教師模型或全局信息標注“該狀態(tài)應該使用哪個技能”“這個步驟的理想輸出是什么”。蒸餾訓練學生模型不僅要學習復制教師輸出還要學習“技能路由”——即在什么狀態(tài)下選擇什么技能。路由信息和技能執(zhí)行一起被蒸餾進參數(shù)。評估與迭代用評測集驗證技能是否真正內(nèi)化并針對失敗案例補充數(shù)據(jù)或調(diào)整技能空間。4.2 技能路由一個被忽略的關鍵模塊很多初學者只關注“模型輸出對不對”卻忽略了一個更關鍵的問題模型怎么知道當前該用哪個技能在提示詞方案中技能選擇靠的是用戶顯式指定或者模型從上下文中自己判斷。而在蒸餾方案中技能選擇需要被“內(nèi)化”成一個隱式的路由策略。這個路由策略的訓練依賴特權信號。比如在訓練數(shù)據(jù)中每個狀態(tài)節(jié)點都被標注了“當前應執(zhí)行技能 A”學生模型在學習時不僅要學會技能 A 的決策邏輯還要學會在相似狀態(tài)下自動激活技能 A。從實現(xiàn)層面看這通常意味著模型需要額外學習一種“隱式意圖識別”的能力。它不直接輸出“我要使用技能A”這樣的文本而是通過參數(shù)表達這種狀態(tài)到技能的映射。4.3 蒸餾損失的設計思路蒸餾訓練中損失函數(shù)通常包括兩個部分。第一部分是輸出蒸餾損失目標是讓學生模型的輸出分布逼近教師模型L_output KL( student_output || teacher_output )第二部分是技能路由損失目標是讓學生模型在對應狀態(tài)下激活正確的技能L_skill CrossEntropy( student_skill_logits, privileged_skill_label )在實際實現(xiàn)中兩個損失會加權組合L_total alpha * L_output beta * L_skill其中 alpha 和 beta 是超參數(shù)。alpha 過大會讓學生只模仿教師的“形”而忽略技能的抽象遷移beta 過大會讓學生過度依賴技能標注失去在未知狀態(tài)下的泛化能力。5. 實戰(zhàn)示意搭建一個技能蒸餾訓練流程這一節(jié)給出一個可運行的示意代碼。說明一下由于不同團隊使用的模型庫、訓練框架差異較大以下代碼是偽代碼風格的最小實現(xiàn)重點在于展示整體流程布局不能直接復制到生產(chǎn)環(huán)境運行。讀者需要將其適配到自己的訓練框架中。5.1 項目結構建議按下面的結構組織代碼skill_distill/ ├── config.py ├── skill_lib.py ├── teacher_model.py ├── student_model.py ├── sampled_trajectory.py ├── train.py └── evaluate.py5.2 技能庫定義# skill_lib.py # 技能庫維護技能列表以及每個技能的描述 SKILL_LIBRARY [ { skill_id: 0, name: code_error_locate, description: 根據(jù)異常堆棧定位代碼位置并給出修復建議 }, { skill_id: 1, name: data_quality_check, description: 檢查數(shù)據(jù)集字段缺失、類型異常和分布傾斜 }, { skill_id: 2, name: sql_optimization, description: 分析慢查詢執(zhí)行計劃并優(yōu)化索引和SQL結構 } ]5.3 特權信號標注在采樣軌跡中每個狀態(tài)節(jié)點需要附帶一個特權標簽。這里用簡潔的字典結構表示一個軌跡片段# sampled_trajectory.py # 一條在線采樣軌跡的示例 trajectory { state: [ 用戶輸入: 系統(tǒng)報錯 OutOfMemoryError, 當前代碼堆棧: Java heap space, 運行環(huán)境: 生產(chǎn)環(huán)境批次任務 ], privileged_skill_id: 0, # 特權信號當前應該使用 code_error_locate 技能 teacher_action: 先檢查堆棧中重復分配的對象再排查大對象緩存, reward: 1.0 }# 在 collect_trajectory 中特權信號來自全局信息或教師模型的離線標注 def collect_trajectory(env, teacher_model): observations [] state env.reset() done False while not done: # 教師模型根據(jù)特權信息給出動作 privileged_action, skill_id teacher_model.act(state, privilegedTrue) observations.append({ state: state, privileged_action: privileged_action, privileged_skill_id: skill_id }) state, reward, done env.step(privileged_action) return observations5.4 學生模型與訓練循環(huán)# train.py # 在線策略自蒸餾訓練循環(huán)示意 import torch import torch.nn as nn from skill_lib import SKILL_LIBRARY from sampled_trajectory import collect_trajectory class StudentModel(nn.Module): def __init__(self, vocab_size, hidden_size, num_skills): super().__init__() self.backbone nn.TransformerEncoder(...) self.output_head nn.Linear(hidden_size, vocab_size) self.skill_head nn.Linear(hidden_size, num_skills) def forward(self, input_ids): features self.backbone(input_ids) logits self.output_head(features) skill_logits self.skill_head(features) return logits, skill_logits def compute_distill_loss(student_logits, teacher_logits, student_skill_logits, privileged_skill_id, alpha0.7, beta0.3): # 輸出蒸餾損失讓學生的輸出分布逼近教師 output_loss nn.KLDivLoss(reductionbatchmean)( nn.LogSoftmax(dim-1)(student_logits), nn.Softmax(dim-1)(teacher_logits) ) # 技能路由損失學習特權信號中的技能選擇 skill_loss nn.CrossEntropyLoss()( student_skill_logits, torch.tensor([privileged_skill_id]) ) return alpha * output_loss beta * skill_loss def train_online(): env create_task_environment() teacher load_teacher_model() student StudentModel(...) optimizer torch.optim.AdamW(student.parameters(), lr1e-5) for step in range(10000): # 1. 在線采集 batch collect_trajectory(env, teacher) # 2. 學生模型前向 input_ids batch[state] student_logits, student_skill_logits student(input_ids) # 3. 教師模型前向教師使用特權信號 teacher_logits teacher(input_ids, privilegedTrue) # 4. 蒸餾損失 loss compute_distill_loss( student_logits, teacher_logits, student_skill_logits, batch[privileged_skill_id] ) # 5. 反向傳播 optimizer.zero_grad() loss.backward() optimizer.step() if step % 100 0: print(fstep {step}, loss {loss.item():.4f})5.5 推理階段的變化訓練完成后推理階段不再需要教師模型和特權信號也不再需要把技能描述寫進提示詞。模型直接根據(jù)用戶輸入內(nèi)部完成技能路由和技能執(zhí)行# inference.py # 推理時只需要學生模型和用戶輸入 def inference(student_model, user_input): input_ids tokenizer.encode(user_input) with torch.no_grad(): output_ids, _ student_model(input_ids) return tokenizer.decode(output_ids)這個階段的核心區(qū)別是全程不出現(xiàn)技能描述文本也不出現(xiàn)長提示詞模板。6. 常見問題與排查思路在實際應用中把技能蒸餾進權重的方案會遇到一些典型問題。這里整理一份排查清單。問題現(xiàn)象常見原因排查思路蒸餾后模型在通用任務上變差災難性遺忘技能訓練擠壓了原有能力在蒸餾損失中加入通用任務數(shù)據(jù)或使用回放機制技能切換不準確該用技能A時用了技能B特權信號噪聲大技能邊界模糊檢查標注質(zhì)量細化技能定義增加過渡狀態(tài)樣本模型只會模仿教師輸出無法舉一反三輸出蒸餾損失權重過高忽略技能路由調(diào)高 beta讓技能路由損失發(fā)揮更大作用訓練損失下降但推理效果波動大在線采樣分布和推理分布不一致增加在線采樣環(huán)境的多樣性避免策略陷入局部最優(yōu)技能庫過大導致路由混亂技能數(shù)量過多區(qū)分度不足重新做技能聚類保持每個技能之間有明確邊界訓練數(shù)據(jù)不干凈教師信號包含錯誤動作對教師輸出增加置信度過濾低置信度樣本不入庫下面挑選三個最常遇到的問題展開說明。6.1 災難性遺忘怎么解決技能蒸餾本質(zhì)上是利用任務數(shù)據(jù)做持續(xù)學習。如果新技能數(shù)據(jù)占比過高模型在通用能力上的表現(xiàn)會明顯退化。解決辦法通常是在蒸餾數(shù)據(jù)中混入一定比例的通用語料或原任務數(shù)據(jù)使用參數(shù)隔離技術例如 LoRA 等低秩適配模塊讓技能相關的參數(shù)與原參數(shù)解耦定期回到通用評測集上做回歸測試監(jiān)控遺忘程度。6.2 技能邊界模糊怎么辦技能蒸餾的成敗很大程度上取決于技能空間的劃分。如果兩個技能之間經(jīng)常出現(xiàn)難以判斷的樣本學生模型學到的路由策略就會不穩(wěn)定。遇到這種情況建議先回頭審視技能定義本身。技能不是越細越好也不是越粗越好。判斷標準是一個技能是否對應一套穩(wěn)定、可復用的決策邏輯。如果某個狀態(tài)下的決策邏輯經(jīng)常有兩種截然不同的走向說明它可能橫跨了兩個技能。6.3 在線采樣的分布漂移在線策略蒸餾里學生模型在更新采樣的軌跡分布也在變化。如果采樣環(huán)境太單一模型很快就會過擬合到少數(shù)狀態(tài)上如果環(huán)境太開放訓練又很難收斂。一個折中的做法是用“課程學習”的思路先讓模型在受限環(huán)境中訓練逐步擴大狀態(tài)空間。7. 工程化落地的幾點建議7.1 先提示詞驗證再蒸餾權重對一個團隊來說最穩(wěn)妥的落地路徑不是一上來就做權重蒸餾而是分兩步走用提示詞方案快速驗證技能定義是否合理。把抽象技能寫成提示詞模板讓模型在少量評測集上跑出基線效果。確認技能有效后再收集數(shù)據(jù)、構建蒸餾訓練集把技能固化進權重。這樣做的好處是可以在早期快速驗證業(yè)務假設避免在訓練上浪費大量資源。7.2 用評估集守住技能邊界技能是否真正被蒸餾進權重需要一套專門的評估集來衡量。建議每個技能都有獨立的評測用例并記錄以下指標路由準確率模型是否在正確狀態(tài)下觸發(fā)正確技能技能執(zhí)行成功率觸發(fā)技能后任務是否順利完成遷移能力在未見過的輸入分布上技能是否依然可用。7.3 理智看待“提示詞 vs 權重”的取舍有些場景依然適合提示詞方案。比如技能內(nèi)容頻繁變動、單次需求不需要長期復用、或者對推理成本不敏感。而權重蒸餾更適合那些“長期穩(wěn)定、高頻復用、對成本和延遲敏感”的技能。一個比較務實的判斷標準是同一個技能如果被調(diào)用超過一定次數(shù)就值得蒸餾成權重。具體閾值取決于團隊訓練成本與推理成本之間的平衡。7.4 數(shù)據(jù)質(zhì)量優(yōu)于模型結構設計最后想強調(diào)一點在這個方案里數(shù)據(jù)質(zhì)量往往比模型結構更決定最終效果。特權信號標注是否準確、采樣軌跡是否覆蓋充分、技能劃分是否合理這些因素疊加起來影響遠大于某個網(wǎng)絡層的設計。如果你準備在業(yè)務中落地這套思路建議從一個小而完整的技能開始。先選擇一個邊界清晰、數(shù)據(jù)容易獲取、效果可量化的技能走通“在線采樣 → 特權信號標注 → 蒸餾訓練 → 推理部署”的全流程再逐步擴大技能庫。訓練過程中重點觀察兩條曲線一條是蒸餾損失的收斂情況另一條是技能路由準確率的變化。后者更關鍵因為它直接反映了模型是否真正學會了“在什么狀態(tài)下用什么技能”。