評測集漂移：為什麼我們每週的模型排名會悄悄換位

上個月我們盯着一份跑了兩週的評測結果，發現一個尷尬的事實：同一批模型，上週 A 排在 B 前面，這週 B 反超了。分數差 1.7 分，工程師們爭論了一下午，誰也說服不了誰。

我們花了三天排查，最後確認：不是模型變了，是評測集變了。

問題出在哪

我們的評測流程是這樣的：客戶場景去識別化後整理成問答對，每週由一位工程師手動補充新案例。看起來挺合理——評測集應該跟着業務走。

但問題恰恰在這裡。「跟着業務走」意味著每週的評測分佈都在變：週一補的案例偏諮詢類，週三補的偏操作類，週五補的偏長文生成。分數本身沒變，變的是分數的「座標系」。

最隱蔽的一個案例：我們連續三週觀察到某模型「長文品質下滑」。排查後發現，每週補充的新案例裡恰好都包含 2000 字以上的長文本任務，而這兩週的舊案例裡有大量短問答被歸檔了。短問答是那個模型的強項，它被移出評測集後，平均分自然往下走。模型什麼都沒變。

還有一個更隱蔽的漂移來源：去識別化。客戶案例去識別化時，我們會把具體產品名、內部系統名替換成佔位符。同一個業務場景，第一週去識別化成「某 CRM 系統」，第三週換了位工程師去識別化，寫成了「客戶關係管理系統」。案例表面變了，評測匹配邏輯也跟着變。我們後來把去識別化詞表固定成一份受控文件，替換規則寫死，不允許臨時發揮。

我們改了什麼

**第一，評測集分層，固定權重。** 把評測案例按任務類型分成五層：短問答、多輪對話、長文生成、程式碼輔助、結構化抽取。每層設定固定佔比，比如短問答 30%、長文 25%。每週補充案例時，只往對應層裡加，不改各層佔比。這樣即使案例總數在漲，分佈是穩的。

**第二，新增案例必須標註「進入哪一層」。** 補充案例的工程師在提交時寫清楚類型，不能丟進一個大池子。這條規則很輕，但堵住了大部分漂移入口。

**第三，保留一份額不變的「錨點集」。** 我們從評測集裡抽 100 條案例凍結，只增不刪、不改。每次跑評測時，錨點集分數和全量分數分開出。如果錨點集分數穩定但全量分數波動，基本可以判斷是新案例引入的分佈問題，而不是模型退化。

**第四，分數對比要帶信賴區間，不能只看均值。** 以前我們看的是「82.3 分 vs 84.0 分，提升 1.7 分」。現在改成分層出分，並要求每個分層的案例數不低於 30 條，不足的分層直接標註「樣本不足，不做結論」。那條 1.7 分的爭論，如果當時按層拆開看，會發現差異集中在長文層，而長文層案例只有 12 條——本來就不該下結論。

一個容易忽略的坑

分層的時候我們踩過一個坑：案例的「類型」不是按輸入長度分的，是按任務意圖分的。一條 50 字的提問如果要求輸出完整 SQL，它屬於結構化抽取層，不屬於短問答層。最初我們按輸入字數分層，結果 SQL 類案例散落在三層裡，分層統計完全失真。後來改成按標注意圖分層，問題才解決。

小結

評測集不是資料庫，不能只增不審計。它的分佈就是模型的座標系，座標系漂了，排名就失去了意義。分層 + 錨點集 + 最小樣本量，這三個動作加在一起，投入大概一個人天，但讓我們從「每週爭論一次分數」變成了「分數異常時才介入」。

兩週後再看，錨點集分數波動壓到了 0.4 分以內，全量分數的週際波動也從平均 2 分降到了 0.8 分。之前那種「A 還是 B」的爭論，現在只有當分層分數真的越界時才會出現——而且通常打開案例一看，答案十分鐘內就能給出來。