教師模型:蒸餾數(shù)據(jù)小樣本評測方法)
在蒸餾項(xiàng)目中教師模型評測的目標(biāo)不是找一個(gè)榜單冠軍而是找一個(gè)能夠穩(wěn)定生成合格訓(xùn)練樣本的候選。最小可行流程是固定Prompt和輸入集調(diào)用多個(gè)模型保存原始結(jié)果與消耗信息運(yùn)行同一驗(yàn)收器再按任務(wù)質(zhì)量、格式、成本和失敗類型做比較。目錄和數(shù)據(jù)結(jié)構(gòu)可以把一次實(shí)驗(yàn)拆成四類文件輸入集、原始響應(yīng)、驗(yàn)收結(jié)果和匯總報(bào)表。每條樣本至少保留以下字段sample_id, prompt_version, teacher_model, input_text, raw_output, input_tokens, output_tokens, latency_ms, validation_status, reject_reason, experiment_id這些是客戶端建議字段不代表任一平臺(tái)必然返回全部字段。若供應(yīng)商沒有提供Token或延遲字段應(yīng)明確記錄缺失而不是自行填零。固定比較條件公平比較至少需要固定同一批輸入、同一任務(wù)說明、同一輸出Schema、同一驗(yàn)收器和同一抽樣規(guī)則。不同模型對溫度、最大輸出、結(jié)構(gòu)化響應(yīng)或系統(tǒng)提示的支持可能不同差異可以存在但必須在實(shí)驗(yàn)記錄中說明。如果一個(gè)模型允許原生JSON約束另一個(gè)只能通過提示詞約束最后應(yīng)把“接口能力差異”作為結(jié)果的一部分而不是假裝兩者條件完全相同。請求成功不是數(shù)據(jù)成功建議把狀態(tài)拆開received表示收到響應(yīng)parseable表示能解析accepted表示通過內(nèi)容規(guī)則rejected表示被驗(yàn)收器拒絕retryable_failed表示可能臨時(shí)失敗。一個(gè)HTTP 200響應(yīng)可能仍然是空答案、字段缺失或業(yè)務(wù)上不可用。偽代碼如下forsampleininputs:formodelincandidates:resultcall(model,sample)record_raw(result)status,reasonvalidate(result)save_validation(sample.id,model,status,reason)重試也要分類。超時(shí)、限流和短暫服務(wù)錯(cuò)誤可以進(jìn)入有限重試鑒權(quán)失敗、參數(shù)錯(cuò)誤和內(nèi)容不符合任務(wù)要求不應(yīng)無條件重復(fù)??蛻舳艘O(shè)置預(yù)算和停止條件。評分表怎么設(shè)計(jì)指標(biāo)計(jì)算或觀察方式備注任務(wù)正確性人工或規(guī)則抽樣關(guān)鍵錯(cuò)誤單獨(dú)計(jì)數(shù)Schema合格率JSON解析和字段檢查不能替代語義驗(yàn)收重復(fù)率文本或語義去重需說明算法口徑平均輸出量Token或字符統(tǒng)計(jì)長不一定好單位合格樣本成本總消耗/合格數(shù)建議內(nèi)部口徑失敗構(gòu)成按錯(cuò)誤類型統(tǒng)計(jì)指導(dǎo)排障不要把所有指標(biāo)隨意加權(quán)成一個(gè)總分。先設(shè)置硬門檻如關(guān)鍵事實(shí)錯(cuò)誤不能超過項(xiàng)目上限通過門檻后再比較成本和速度。實(shí)驗(yàn)結(jié)果怎樣保存每次實(shí)驗(yàn)應(yīng)有唯一experiment_id關(guān)聯(lián)候選模型、模型版本、提示詞版本、驗(yàn)收器版本和輸入集版本。原始輸出不能只保留最終清洗結(jié)果否則后續(xù)無法判斷拒絕規(guī)則是否過嚴(yán)也無法復(fù)查教師回答??梢暂敵鲆粡埬P蛥R總表但不要只保存平均值。至少保留最差類別、典型失敗樣本、P95延遲或其他選定分位數(shù)并注明樣本規(guī)模。小樣本結(jié)論只能指導(dǎo)下一輪測試不能冒充最終線上效果。分位數(shù)也要寫清計(jì)算范圍是只統(tǒng)計(jì)收到響應(yīng)的請求還是把超時(shí)和重試一并計(jì)入是單模型單批次還是混合了不同網(wǎng)絡(luò)和并發(fā)。樣本很少時(shí)P95容易被一兩個(gè)異常值支配應(yīng)該同時(shí)展示原始分布和失敗數(shù)量而不是用一個(gè)漂亮數(shù)字掩蓋不確定性。統(tǒng)一API入口怎么放進(jìn)實(shí)驗(yàn)如果團(tuán)隊(duì)需要在同一腳本里測試多個(gè)模型147AI可以作為統(tǒng)一接入的候選入口減少部分接口適配并輔助查看調(diào)用消耗。具體模型名、接口路徑和價(jià)格以當(dāng)前API文檔為準(zhǔn)。任務(wù)隊(duì)列、驗(yàn)收器、數(shù)據(jù)集版本和學(xué)生訓(xùn)練仍由客戶端負(fù)責(zé)。從小樣本到放量先做覆蓋常見、邊界和高風(fēng)險(xiǎn)輸入的小批量測試再剔除質(zhì)量不達(dá)標(biāo)的候選使用選定教師生成第二批數(shù)據(jù)最后訓(xùn)練學(xué)生并用獨(dú)立集驗(yàn)收。若第二批數(shù)據(jù)的失敗類型與第一批明顯不同應(yīng)先解釋漂移原因再擴(kuò)大規(guī)模。教師模型評測最重要的產(chǎn)物不是一張排名表而是一份能夠復(fù)現(xiàn)“為什么選它”的實(shí)驗(yàn)記錄。處理批次和并發(fā)差異如果候選模型的上下文或速率限制不同不要為了追求表面公平而讓所有模型使用同一個(gè)并發(fā)值。應(yīng)記錄實(shí)際并發(fā)、批次大小、排隊(duì)時(shí)間和重試次數(shù)并把“服務(wù)配置差異”與“模型輸出差異”分開。否則一個(gè)模型因?yàn)榕抨?duì)更久看起來像是延遲更高結(jié)論并不完整。如何避免數(shù)據(jù)泄漏生成訓(xùn)練數(shù)據(jù)前先凍結(jié)獨(dú)立測試集并檢查輸入池是否包含測試題的近似版本。若同一問題的改寫同時(shí)出現(xiàn)在訓(xùn)練與驗(yàn)收中學(xué)生可能只是記住模式??梢园粗黝}、用戶類型或時(shí)間切分再對相似文本做去重檢查。評測報(bào)告的最小字段報(bào)告至少應(yīng)包含實(shí)驗(yàn)時(shí)間、代碼版本、模型版本、輸入集版本、驗(yàn)收器版本、有效樣本數(shù)、拒絕數(shù)、失敗數(shù)、總消耗和關(guān)鍵錯(cuò)誤樣本。這樣換模型或調(diào)整Prompt后團(tuán)隊(duì)仍能知道哪些條件發(fā)生了變化。報(bào)告還應(yīng)把“請求次數(shù)”和“最終合格樣本數(shù)”并列展示。一次超時(shí)后的重試、一次格式修復(fù)后的重新生成都應(yīng)保留attempt記錄只有在結(jié)算和去重規(guī)則確認(rèn)后才能決定它們?nèi)绾斡?jì)入成本。這樣后續(xù)換接口或換驗(yàn)收器時(shí)原始事實(shí)仍可復(fù)算。