把評估跑進 CI：一次模型升級引發的翻車與修復

上週我們做了件很常規的事：把本地推理閘道器後面掛載的主模型從 32B 換成 70B，推理框架小版本也順手升了一個號。按慣例，我們只跑了「冒煙測試」——三條典型問答，答案看起來都對，就合上了 PR，把閘道器切到了生產環境。

四十分鐘後，工單進來了：三個用戶的批次翻譯任務，輸出格式全部錯亂。

復盤的時候我們翻出當年的驗證記錄，發現「冒煙測試」測的恰好是模型最穩的領域：知識問答。而真正出問題的批次翻譯，用的是另一套提示詞模板，還要求嚴格的 JSON 輸出。更大的 70B 參數對長指令裡的格式約束更「較真」了——它開始把解釋性前綴也塞進 JSON 欄位裡，下游解析器直接拋錯，任務整批失敗。

問題不在模型變笨了，而在我們的評估集裡根本沒有這類 case。

這次之後我們立了三條規矩，成本都不高，但把同類問題擋在了上線前：

**第一，評估集按「提示詞模板」而不是按「功能模組」組織。** 我們線上的呼叫其實是 11 套模板：翻譯、抽取、摘要、改寫……每套模板單獨掛一組評估用例，至少 20 條真實去識別化樣本。換模型或改推理參數時，全量 11 套都要跑，任何一套通過率掉 2 個百分點以上就阻斷發布。這一點寫進了 CI 的硬性門禁，不是「建議」。

**第二，格式類斷言和語義類斷言分開打分。** JSON 輸出先過 schema 校驗，通過才進語義評分。這樣做的好處是翻車時定位極快：schema 挂了說明是格式問題，跟模型智商無關，直接查提示詞和解析器；schema 過了但語義分掉了，才輪到懷疑模型本身。上次那種「答案看著挺對但批次任務全挂」的模糊地帶，基本不會再出現。

**第三，給評估腳本留了「唯讀生產流量採樣」的開關。** 我們把線上脫敏後的輸入範例（不碰輸出，避免標註成本）每週自動落一份到評估倉庫，作為下一輪 case 的來源。模型對什麼輸入過敏，生產流量最清楚。

**第四，模型切換不再一刀切，走影子流量。** 新模型先在閘道器後掛成影子節點，接 5% 的真實流量，只記錄不返回。影子側的輸出和主節點逐條比對，格式類欄位嚴格 diff，語義類欄位算相似度。影子期至少跑滿 48 小時，覆蓋一個完整的業務高峰谷，任何一類欄位的劣化超過閾值就自動回滾影子節點並告警。這次 70B 走的就是這套流程——影子期第二天早上就抓到了翻譯模板的 JSON 污染，是告警拉了我們一把，不是用戶工單。

有人可能覺得 11 套模板 × 20 條 × 全量跑，成本不低。實際算下來，本地 70B 跑一輪評估約 18 分鐘，機器是現成的，沒有額外開銷。相比之下，一次生產事故的排查加回滾，上次花了三個小時，還搭上了用戶信任。

最扎心的一條經驗：我們曾經以為「答案正確」就等於「系統正確」。對 LLM 流水線來說，答案只是眾多輸出屬性中的一個，格式、長度、語言純度、拒答行為，每一個都是獨立的風險面。評估集覆蓋了哪一面，你就在哪一面上有免疫力。

這次升級最終還是上了線——修完那套翻譯模板的格式約束後，11 套評估全部通過。只是從此以後，「看起來都對」這句話，在評審會上再也過不了關了。