宅中地 - 每日更新
宅中地 - 每日更新

贊助商廣告

X

一份跑通的評測報告,到底能證明什麼?

2026年09月08日 首頁 » 熱門科技

你有沒有遇到過這樣的場景:兩篇論文都說自己的模型在某個基準測試上"取得了最優結果",可你翻看細節才發現,它們用的評分方式、數據切分、甚至判斷勝負的標準完全不是一回事。

這不是個例。武漢大學的研究者秦曦一份跑通的評測報告到底能證明什麼對著一個叫 Inspect Evals一份跑通的評測報告到底能證明什麼 的評測代碼倉庫做了一次地毯式排查,這個倉庫收錄了各種 AI 智能體和大模型的評測任務,結果發現:124 個可以拿來分析的評測單元里,110 個根本沒法驗證它們聲稱的結論。

不是運行失敗,不是分數是零,而是壓根沒法回答"這個結論換個合理的評判方式還成立嗎"這個問題。

這篇論文的標題很直白:評測到底能證明什麼。答案可能會讓人有點意外。

**問題出在哪:評測跑通了,不等於結論站得住**

先說清楚一件事,評測代碼跑起來、給出一個分數,和這個分數背後的結論可以被驗證,是兩碼事。

舉個例子。一個智能體在某個任務上得了 85 分。這 85 分是怎麼算出來的?是不是所有樣本都參與了計算,還是有一部分因為格式錯誤被悄悄跳過了?評分的裁判是哪個模型,當時是什麼版本?如果換一種同樣合理的評分口徑,這 85 分會不會變成 70 分?

評測工件一份跑通的評測報告到底能證明什麼*:論文裡對"評測代碼 + 評分器 + 輸出的分數"這一整套產物的統稱,強調它只是一個正向計算流程,不天然攜帶驗證資訊。

如果這些問題都沒有答案,那這 85 分其實是一個孤證。它只是"這一次這樣跑,跑出了這個數",卻沒法回答"這個結論能不能被重新推導出來"。

論文把這個缺失的環節叫做"申領重放一份跑通的評測報告到底能證明什麼",英文是 claim replay。你可以理解成,一份評測結果想要真正站得住,得像一份可以被反覆驗證的科學論斷,而不是一次性的表演。

打個比方。你去飯店點了一道菜,老闆說這道菜"用了秘制配方,絕對正宗"。可你要是問他,這道菜用了什麼食材、比例是多少、換個廚子做出來味道還一樣嗎,他答不上來。那這道菜好不好吃是真的,但"正宗"這個說法就沒法驗證。如果不去問這些細節,你可能一直以為這道菜真的獨一無二,直到有一天吃到別家一模一樣的做法,才發現所謂"秘方"根本經不起追問。

評測領域正在發生類似的事情。一個模型在榜單上排第一,這個"第一"是真的跑出來的,但它是不是經得起換個評判角度重新檢驗,往往沒人問。

**三個變量:數據、家族、問題**

論文提出了一個三元組,用來把"能不能驗證"這件事變成可以機械檢查的東西。

這三個變量分別是:凍結的歷史證據 D,一組"合理的評判方式"的集合 F,以及要問的具體問題 q。

凍結證據一份跑通的評測報告到底能證明什麼*:指的是某次評測當時留下的全部原始材料,包括模型的輸出、評分依據、系統狀態等,一旦固定就不能再改動,任何後續分析都基於這份"證據鏈"。

舉個具體場景。假設你要評估三個 AI 模型在某個防禦攻擊任務上誰更強,D 就是這三個模型當時被攻擊時的全部記錄:哪次攻擊成功了、哪次沒成功、每一步的中間狀態。F 是所有"合理的評分方式",比如按發布的官方口徑算一次,按全部跑過的樣本重新算一次,按某個更嚴格的子集再算一次,這些算法可能得出不同的分數,但都算"講得通"的解讀。q 就是你真正關心的問題,比如"誰是贏家",或者"這三個模型的完整排名是什麼"。

論文裡進一步把 F 拆成兩層,一層叫"主家族一份跑通的評測報告到底能證明什麼",是經過審核確認放心用的評判方式;另一層叫"審查信封一份跑通的評測報告到底能證明什麼",是那些有爭議、暫時不能算數、但也不排除以後能用的候選方式。這兩層的關係是包含的,主家族一定在審查信封裡面,但審查信封比主家族更大。

這個區分為什麼重要?因為如果只用主家族算出來的結論是穩的,一旦把有爭議的候選方式也加進來,結論可能就變了。論文用一句公式表達這件事:候選範圍越大,結論的不確定性只會增加不會減少。這話聽起來是廢話,但現實中很多論文默默地把有爭議的讀法混進主流結論里,讀者根本看不出來。

這裡論文給出了一個特別好的例子,叫 AgentDojo一份跑通的評測報告到底能證明什麼,是一個測試 AI 智能體抵禦攻擊能力的評測集。

研究者找到了五種"合理的讀法"來計算同一批攻擊結果的成功率,這五種讀法在"哪些樣本該被算進分母""怎麼聚合不同任務的結果"這些細節上有分歧。其中兩種讀法屬於官方認可的主流做法,另外三種屬於審查信封里有爭議的做法。

結果發現,在兩種主流讀法下,Claude 3.5 Sonnet一份跑通的評測報告到底能證明什麼 穩贏,而且三個模型的完整排名是唯一確定的。但如果把審查信封里那三種有爭議的讀法也放進來一起看,Claude 依然是贏家,可排名靠後的兩個模型 Gemini 2.0一份跑通的評測報告到底能證明什麼 和 GPT-4o-mini 誰高誰低,答案就不確定了,有的讀法說 Gemini 更差,有的讀法反過來。

這就是論文想說明的核心現象:一個評測結果可以同時支持一個確定的贏家、一個確定的主流排名,以及一個在更寬範圍下不確定的排名。三種結論共存,不矛盾。

**124 個評測單元,110 個卡在半路**

理論講完了,論文的重頭戲是拿真實數據說話。

研究者在 Inspect Evals 倉庫的一個固定代碼版本上,機械化地篩選出 124 個符合條件的評測單元。這個篩選過程完全按預先定好的規則來,不參考任何評測結果,保證公平。

結果是,只有 14 個單元真正走到了可以做"申領重放"分析的地步,剩下 110 個,全部在半路就被攔下來了,論文管這個叫"停止",英文是 STOP。

STOP*:論文對"某個評測單元因為缺少必要材料,無法繼續做claim-replay分析"這種終止狀態的專門稱呼,它不是評測失敗,也不是零分,而是一個"目前缺什麼東西"的診斷結果。

這 110 個停止里,原因分布很集中。有 47 個卡在"證據綁定失敗",就是沒法把評測源代碼和當時具體跑出來的原始數據對應上。有 35 個卡在"缺乏可比較的觀測數據",簡單說就是當時幾個系統的輸出結果壓根沒有被完整保存下來,沒法拿來橫向比較。還有 9 個卡在"缺少裁判痕跡",這類評測依賴一個 AI 模型來給答案評分,但當時那個裁判模型具體給出了什麼判斷、用了什麼提示詞,都沒留下來。剩下十幾個涉及更細碎的問題,比如指標類型對不上、缺失值處理規則沒聲明等等。

這裡有一個特別容易被誤解的地方,得說清楚。這 110 個停止,不是說這些評測代碼寫得差,也不是說這些評測本身不可信。論文反覆強調,Inspect 這個框架本身的日誌能力是很強的,理論上可以記錄下樣本級別的完整歷史。問題出在,當時具體那一次運行,該留的東西沒有被完整地公開保存下來。

這就好比你去醫院做體檢,機器本身精度很高,能測出很詳細的數據,但如果醫生當時忘了把某幾項檢測結果寫進病歷,那不是機器的問題,是記錄環節掉鏈子了。以後你想找人覆核這份體檢報告的某個結論,發現關鍵的原始讀數沒了,只剩下一個籠統的"正常"或"異常"。這時候你沒法重新驗證,但也不能說這台機器測不準,只能說這份記錄不完整。如果不把這個環節單獨拎出來講清楚,讀者很容易把"記錄不全"誤會成"評測方法有問題",兩者其實完全是兩回事。

論文還專門強調了一點:現在重新跑一遍評測,並不能彌補這個歷史缺口。因為重新跑意味著換了一個新的模型版本、新的裁判、新的運行環境,這產生的是一份全新的證據,而不是把當年那份丟失的證據找回來了。就像案發現場的指紋,你沒法用今天的指紋去替代當年沒採集到的那份。

**當證據齊全時,會發生什麼**

論文裡還有一個不容易被一眼看穿,但特別關鍵的發現:就算證據齊全、能往下分析了,"結論是否穩定"這件事本身也是分層次的,不是簡單的一刀切。

研究者挑了三個案例做深度分析,除了前面提到的 AgentDojo,還有 AutoML Benchmark 和 BEIR SciFact 檢索評測。

在 AutoML Benchmark 這個案例里,研究者對比了五個自動化機器學習工具在多個任務上的表現,發現主流評判口徑下贏家和完整排名都是唯一確定的,H2OAutoML 穩居第一。可如果把兩種有爭議的評判方式(比如按任務排名取平均、只看表現最差的那個任務)也納入考慮,完整排名就變得不唯一了,雖然贏家還是沒變。

具體到數字上,主流口徑下十對系統之間的兩兩比較關係全部是穩定的,一旦擴大到審查信封,變成了九對穩定、一對不穩定,唯一鬆動的是排名中間的兩個系統誰高誰低。

BEIR SciFact 這個案例更極端一點。這是一個資訊檢索評測,比較三種不同參數設置的 BM25 檢索算法,用五種官方認可的指標(比如 NDCG、MAP、召回率等)去衡量。結果發現,不管用哪種主流的評判方式,贏家都是同一個,但完整排名從一開始就是不確定的,三對系統里只有兩對關係是穩定的,另外一對在不同指標下會翻轉。

這三個案例放在一起看,論文想傳達的意思其實很樸素:一個評測結論可以在"誰贏了"這個粗粒度問題上非常穩,同時在"完整排名"這個細粒度問題上完全不穩。這兩件事不衝突,也不該被簡單地打包成一個"這個評測靠不可靠"的是非判斷。

如果論文只報告一個籠統的"排名會變"或者"排名不會變",讀者拿到的資訊量其實很低。真正有用的是分層次地說清楚:哪一層是穩的,哪一層不穩,不穩的具體是哪兩個系統之間的關係。這就好比體檢報告不會只寫"你身體有問題",而是會具體到血糖、血壓、肝功能分別怎麼樣,哪幾項需要關注,哪幾項完全正常。籠統的結論看似省事,實際上把真正有價值的細節全部抹平了。

**一個正交的對照實驗:效應可以被"局部化"到一個規則**

論文附錄里還藏著一個特別有意思的對照實驗,雖然和 Inspect Evals 主體沒有直接關係,但很能說明這套框架的診斷能力。

研究者拿了另外兩個智能體診斷數據集(AgentRx 和 TELBench),對比兩種預測算法 PageRank 和 Earliest Anomaly 誰的表現更好。最初的一種統計口徑顯示,PageRank 比 Earliest 差了整整 43 個百分點,看起來是個很大的差距。

但研究者發現,這個巨大的差距,其實完全來自一個不對稱的規則:當某個候選對象缺失時,原始統計方式只在其中一邊的對比里把它刪掉,另一邊保留。換句話說,不是模型本身表現差了 43 分,而是計分規則本身對兩邊不公平。

研究者設計了兩種"對稱"的處理方式,一種是兩邊都保留缺失項,一種是兩邊都刪除,結果這個 43 個百分點的差距瞬間歸零。

這個例子特別值得琢磨。一個看起來巨大的性能差距,追查到底,居然完全是計分規則單邊傾斜造成的假象。這就像兩個人賽跑,裁判在其中一人快到終點時突然給他加了一段路,另一人卻沒有,最後說這人跑得慢,其實是賽道本身不公平。如果沒有人去拆開這個規則細看,這 43 個百分點的差距會一直被當成模型能力的真實差距被引用下去。

這個附錄實驗雖然不在 Inspect Evals 的正式統計里,但它給整篇論文提供了一個非常紮實的旁證:很多看起來嚇人的性能差異,值得回頭去查一查,是不是計分規則本身出了問題。

**這套方法解決了什麼根本矛盾**

回到最開始的問題,評測到底能證明什麼。

論文給出的答案是一個可執行的契約。它要求,任何一個想要被認真對待的評測結論,都應該同時公開四樣東西:當時的歷史觀測數據,允許的評分口徑變體,一個類型明確的問題,以及最終得出的這些評分口徑下的結論集合。

如果這四樣東西湊不齊,系統應該誠實地給出一個"停止"標記,並且說明具體缺了什麼、最少補上什麼材料才能繼續分析,而不是硬湊一個數字糊弄過去。

這套設計解決的根本矛盾是:評測行業長期以來把"跑出一個分數"和"這個分數經得起驗證"混為一談。前者是工程問題,後者是科學問題。論文想做的,是把兩者拆開,讓每一份評測結果都帶著自己的"信用等級"出場,而不是所有分數看起來都一樣可信。

如果不這麼做,會發生什麼?最直接的後果是,不同論文之間沒法真正比較。你說你的模型贏了,我說我的模型贏了,可能我們倆用的評分口徑壓根不是一回事,讀者卻以為大家在討論同一件事。長期來看,這會侵蝕整個領域對"評測結果"這四個字的信任。

寫在後面

讀這篇論文的過程中,最觸動我的不是那個 110/124 的比例,而是論文反覆強調的一句話:停止不是失敗。

這句話聽起來簡單,但仔細想想,它其實在糾正一個很普遍的直覺。我們習慣把"跑不出結果"等同於"這個方法不行",可這篇論文告訴你,很多時候跑不出來的不是方法,是記錄。方法可能完全沒問題,只是當年該留的證據沒留下來。這個區分乍看是文字遊戲,實際上決定了你接下來該做什麼:是去懷疑模型,還是去改進發布流程。這兩件事的解決方案完全不一樣。

另一個讓我反覆琢磨的細節,是那個 43 個百分點憑空消失的對照實驗。它提醒我一件很樸素的事:任何一個巨大的、讓人震驚的數字,背後都值得去問一句"這個數字是怎麼算出來的,規則對兩邊公平嗎"。這種習慣不只適用於評測論文,幾乎適用於任何你看到的對比數據,不管是產品評測、政策效果統計,還是新聞里的百分比。

論文還留了一個沒解決的問題,就是這套"申領重放"契約到底能不能真的減少未來的"停止"數量,論文自己也承認這是留給未來的驗證性研究,現在還沒人真正做過這個對照實驗。這個問題我倒覺得挺值得追問下去:如果真的強制要求所有評測發布時都附帶這四樣材料,評測圈子的工作量會增加多少,又有多少團隊願意為了這份"可驗證性"去多做這份額外的記錄工作。

Q&A

Q1:Inspect Evals評測框架的124個評測單元里,為什麼有110個無法得出確定結論?

A:不是評測代碼運行失敗,而是這些單元缺少必要的歷史證據、裁判記錄或語義標準,導致無法驗證結論是否能在合理的評判方式變化下依然成立,論文稱這種狀態為"停止",並非零分或失敗。

Q2:AgentDojo評測里贏家為什麼在不同讀法下都不變,排名卻會變?

A:AgentDojo用五種合理讀法計算攻擊成功率,主流兩種讀法下Claude 3.5 Sonnet穩贏且完整排名唯一,但加入三種有爭議讀法後,贏家依然是Claude,排名靠後的兩個系統的先後順序卻會翻轉。

Q3:為什麼重新跑一次評測不能彌補歷史證據缺失的問題?

A:重新運行會產生新模型版本、新裁判、新環境下的全新數據,這是一個全新的證據集,而不是找回當年那次評測缺失的原始記錄,所以論文裡110個"停止"的單元不會因為重跑而被解決。

宅中地 - Facebook 分享 宅中地 - Twitter 分享 宅中地 - Whatsapp 分享 宅中地 - Line 分享
相關內容
Copyright ©2026 | 服務條款 | DMCA | 聯絡我們
宅中地 - 每日更新