LLM評估得分忽高忽低？不是模型退化，是你沒分清兩類噪聲

我們跑完基準測試，得到一個 84% 的分數。改了提示詞再跑，掉到 81%。團隊立刻停下手頭所有工作，回滾改動、逐行檢查日志、懷疑某個依賴庫的版本不對。兩天后重新跑一次——分數反彈到 87%。那一刻我們意識到，過去一周的調試全是白費力氣。分數在跳舞，而我們的代碼什么都沒做。

這不是某個基礎設施故障導致的偶然事件。這是 LLM 評估系統自帶的體質。一旦你把一個“看起來像測試”的東西硬塞進大型語言模型的評估流程里，你會反復摔進同一個坑里：把噪聲當成信號，把測量誤差當成回歸，把隨機波動當成提示詞優化的成敗依據。

在傳統軟件工程里，測試是二值的。紅燈變綠燈，世界就太平。這套反饋回路統治了我們幾十年。但 LLM 帶來的改變不是“測試更難了”，而是它徹底擊碎了“測試即確定性”這個前提。你跑同一套評估兩次，會得到兩個不同的分數。沒有任何代碼改動。沒有任何 prompt 變更。甚至沒有任何你能用肉眼看到的原因。

我們的團隊在構建內部 LLM 評估框架的早期，幾乎把所有精力都賭在“跑出一個干凈分數”上?；鶞蕼y試 → 給個分 → 改 prompt → 再看分。掉幾分就是退化，漲幾分就是進步。這套思維習慣在傳統軟件世界里相當合理，放到 LLM 評估里卻會直接導致決策癱瘓。因為我們花了數周時間去追逐一個根本不存在的東西——一個不受噪聲干擾的單一確定性分數。

真正的問題是：我們對評估的期待本身就是錯的。LLM 評估不是測試，它是測量。工程師一旦愿意接受這一點，整個評估系統的架構就開始變得清晰起來。你要處理的不是“如何消除噪聲”，而是“如何區分兩種完全不同的噪聲源”——一種來自你要評估的對話任務本身，另一種來自你選用的評估器。

這才是最容易被忽略的設計要害：所有評估分數的波動，在它成為一個結論之前，首先是一個提問——“這次波動到底是誰的鍋？” 對話場景本身就模棱兩可？還是打分的那位 LLM 法官自己舉棋不定？如果你把所有波動都當成同一個問題來處理，你的評估體系遲早會失去所有人的信任。

先看第一種情況。想象你的 AI 助手遇到一個用戶輸入，對方只扔過來兩個字：“明天”。

這一刻，助手該怎么做？是理解成“明天有什么日程”，還是“告訴我明天的天氣”，或者“把明天的會議推遲”？沒有任何額外上下文的情況下，這些解讀全都合理。即使是找幾個真人評審坐下來打分，他們之間也會彼此爭論。這跟你的模型強不強沒關系，跟你 prompt 優化到不到位也沒關系。這種模糊性從用戶發出這兩個字的那一刻起，就已經刻進對話的基因里了。

統計學家給這類不確定性起了一個拗口的名字：aleatoric 不確定性。術語不重要，工程含義才致命。如果噪聲本來就長在對話里面，那你不管怎么微調評估器、怎么換 LLM 法官的提示詞模板，都解決不了問題。你在優化系統里那個根本沒犯錯的部分，而真正沒信息量的原始輸入，你動不了它一根手指頭。因為你無法通過 debug 或者代碼，把一條本身就缺乏確定性信息量的輸入，強行變得只有唯一正確答案。

這也就意味著，當你在看板前盯著一條突然下跌的評估曲線，在動手排查模型之前，必須先問自己一句話：“這次的任務本身，是不是本身就模糊到讓任何合理答案都只能算‘部分正確’？” 如果答案是 yes，那你該修的就不是模型，而是你給任務定義的驗收標準，或者是測試用例的信息完整度。

處理這類對話層面的噪聲，工程師能做的事情其實很有限，歸結起來往往只有幾個方向：重新審視你對“正確回答”的判斷寬嚴程度，給測試用例補足必要的上下文，或者在任務設計階段就主動剔除那些信息不足、連人類評審都意見撕裂的極端樣本。這跟你優化模型精度，完全不是同一類工作。

現在切換到另一種截然不同的場景。你有一條干凈清晰的測試用例，輸入信息充分，沒有歧義。被測模型給出的回答也明顯正確，挑不出毛病。你把它扔給你的 LLM 法官，法官打出一個 4 分（滿分 5 分）。

五分鐘后，你什么都沒改，重新跑一次同樣評估。這一次法官卻給了 5 分。

被測模型的輸出紋絲未動，分數卻憑空漲了一檔。這次鍋不在對話，而在那個你以為是“公正第三方”的評估器身上。統計學家把這類現象叫做 epistemic 不確定性——任務本身是穩定的，但測量過程不是。翻譯成工程語言就是：你的基準測試沒問題，你的評估基礎設施出毛病了。

這種場景才真正刺痛工程師的神經。因為前一種噪聲你至少還能歸因到“輸入太爛”，后者卻意味著你每一條干凈用例都可能被隨機打分。昨天還是 4 分的回應，今天忽然變成 5 分，明天可能又掉回 3 分。而你什么證據都拿不到——沒有版本記錄，沒有配置變更，沒有環境差異，只有一次叫你開始懷疑自己眼睛的評估面板。

把評估器噪聲單拎出來處理，這不是精度的微調問題，它關乎你整個評估流水線的可信度。如果法官本身溫度偏高、打分不穩定，那你所有針對 prompt 改動做出的“效果對比”就都建立在流沙上面。上周你慶祝的那個“提分優化”，很可能只是法官那天心情好，多給你開了幾分。

遺憾的是，很多團隊在意識到評估器存在噪聲之后，第一反應往往不是去診斷噪聲類型，而是直接加大評估輪次——同樣的評測跑三遍，取平均值。這種做法看似“更嚴謹”，實際上只是把兩種不同性質的噪聲強行糊在一起，喂給統計公式。最終你得出的分數確實可能會穩定一些，但你再也說不清楚：這個“穩定”到底是因為你的任務變清晰了，還是僅僅因為法官的隨機誤差被均值平滑掉了。

這也正是為什么我們要一再強調：在 LLM 評估體系里，所有分數波動在被當成結論之前，都必須先經歷一次“噪聲審訊”。它到底是對話端的 aleatoric 不確定性，還是評估器端的 epistemic 不確定性？前者只能通過任務設計和數據質量來收斂，后者必須通過評估器本身的可靠性工程來解決——比如提高溫度參數的可控性、引入多次采樣一致性檢測、或者干脆在關鍵場景切換到更穩定的結構化評分協議。把這兩個問題混為一談的代價，是你永遠在對著錯誤的方向用力。

一旦你接受了“評估即測量”這個心智模型，整個架構就變得幾乎是自明的。你不再要求一個唯一的分數，而是要求一份能夠清晰區分噪聲來源的診斷報告。你不再對著單一數字做回歸決策，而是開始追問：這條評估曲線跳動的時候，波動的大頭，究竟是任務側的模糊度在震蕩，還是法官側的置信度在漂移？

遺憾的是，市面上大部分早熟的 LLM 評估工具，恰恰是在這個環節上選擇了“偷懶”——要么把所有波動統一標記為“評估誤差”，要么用平均分把底層方差一巴掌拍平。結果就是評估面板看起來很干凈，但一回到生產環境，用戶的真實體驗和面板上的數字完全對不上。

我們團隊最終停止追逐那個幻想中的干凈分數，是從一個非常簡單的動作開始的：在每一次跑完評估之后，不先去看總分，而是先去翻那些分數變化最大的單條用例。然后給每一條波動打上標簽——究竟是“任務本身模糊導致任何合理答案都難以穩定拿分”，還是“評估器自己在左右橫跳”。

這個標簽打了幾輪之后，一個我們之前始終不想面對的事實就浮了出來：相當一部分所謂“模型表現不穩定”的告警，根本不需要動模型，甚至不需要動 prompt，只需要把那些連人類評審都吵不出結果的糟糕用例從評估集中清掉。而另一部分看似嚴重的分數下滑，也根本不是什么架構退化，只是評估器的溫度配置在一次無關服務更新中被意外覆蓋了。

這才是 LLM 評估應該交付的價值：不是讓你對每一個數字波動都緊急響應，而是讓你在看到波動的時候，能越來越快地說出，“這次不關我們的事”。