我嘗試製作自己的（糟糕）LLM 基準來在逃脫房間中作弊

最近，DeepSeek 宣布了他們最新的模型 R1，隨後出現了許多文章讚揚它的性能和價格之間的關係，並且這種開放源碼模型的發布可能會真正改變大型語言模型 (LLMs) 的未來。這真的很令人興奮！不過，這個主題範圍太大，無法一一寫到……但當像 DeepSeek 這樣的模型突然出現，並且聲稱其性能與其他模型相似時，這裡的「性能」到底意味著什麼呢？

如果你關注人工智慧 (AI) 的發布，你一定見過這種情況。每個新模型都會發布圖表，顯示它在數學問題上如何比 GPT-4 更好，同時又更小、更高效。但這些基準測試究竟在測量什麼？它們是如何創建的？更重要的是，我們如何穿透這些炒作，為特定的使用案例創建自己的基準測試？

我想了解更多有關 LLM 基準測試的知識。

第一部分：什麼是基準測試？（3 秒內）

簡而言之——LLMs 的 SAT 考試（其實是多個）。

第一部分 1：什麼是基準測試？（超過 3 秒）

在我們深入探討具體的基準測試之前，讓我們先來了解一下「LLM 基準測試」的含義。因為稱它們為「AI 的 SAT 考試」聽起來既正確又有些過於簡化。

LLM 基準測試本質上是用來測量大型語言模型在某些任務上的表現的結構化測試。這些任務可以是從判斷一個陳述是否正確，到總結法律文件，再到生成有效的 Python 函數。可以把它們想像成 AI 研究人員特別設計的障礙賽，旨在測試這些模型的每一個相關能力。這些框架通常提供一組已知正確輸出的數據集，讓模型之間可以進行一致的比較。

現代基準測試使用各種評估方法。像準確度這樣的分類指標適用於有明確正確答案的任務，而基於重疊的指標（如 BLEU、ROUGE）則用於評估自由形式的文本生成。有些基準測試使用功能測試來評估代碼生成，或者使用其他 LLM 作為評判來評估回應的質量。

一個典型的基準測試通常包含：

• 一組標準化的問題、提示或任務（帶有正確或參考答案）。
• 一個評估協議，指定如何測量成功，例如準確度、F1 分數、文本生成的 BLEU/ROUGE，或編碼任務的通過/失敗率。
• 一個排行榜或某種形式的比較計分板，通常伴隨著華麗的圖表。

一些非常著名的基準測試包括 MMLU 用於測試多任務語言理解，TruthfulQA 用於評估事實準確性，以及 HumanEval 用於測量編碼能力。結果通常會在公共排行榜上發布，讓人們能夠進行透明的模型比較。

什麼是好的基準測試？

• 明確的任務定義：我們希望任務是明確的。挑戰越簡單、越具體，結果就越容易被信任。
• 數據完整性：測試集不應該在訓練數據中出現。如果模型之前見過同樣的問題 50 次，那麼評估的價值就不大了。
• 可量化的指標：你需要一個標準來評分性能——例如模型的代碼通過測試案例的次數，或生成的摘要與「真實摘要」的接近程度。
• 任務多樣性與難度：如果基準測試太簡單，大家第一天就能輕鬆通過，那我們就學不到任何東西。如果它太小眾（例如「我們只測試模型在 20 分鐘內計算圓周率的能力」），那也不太有幫助。

生活不只是成績

基準測試只捕捉了 LLM 能做的一部分。在現實世界中，你的聊天機器人可能需要處理領域知識、跟蹤對話上下文、遵守公司的政策，並且產生流暢且不冒犯的回應。沒有任何一個標準化的測試能完全涵蓋這些。正如我們在接下來的案例研究中將看到的，基準測試的設計和執行會深刻影響你對模型性能的理解……如果不小心測量成功，可能會導致誤解。

現在我們已經了解了 LLM 基準測試的設計目的（以及它們可能的不足之處），讓我們來探討幾個例子，看看人們實際上是如何構建和使用它們的——結果各不相同！

案例研究 #1：Leetcode 作為 LLM 基準測試

作為一名科技領域的學生，當我在尋找有趣的基準測試時，看到「Leetcode」這個詞讓我的血壓上升了不少。與 Leetcode 相比，論文「LLM 生成代碼在 Leetcode 上的性能研究」非常有趣——它提出了一個看似簡單的問題：我們可以使用 Leetcode 來基準測試 LLM 的代碼生成嗎？他們的發現揭示了這種方法的潛力和陷阱。

基準設計

研究人員建立了一個三階段的驗證系統。地方測試捕捉基本錯誤，Leetcode 的評判驗證正確性，自定義基準設置測量性能。這一設置揭示了一個關鍵問題：基準測試代碼性能比看起來要困難得多。

當他們將地方測量與 Leetcode 的指標進行比較時，他們發現只有 0.28 的相關性。Leetcode 的測量顯示出更高的變異性（0.089 對 0.035）。更糟糕的是，Leetcode 的排名不穩定——相同的解決方案可能因提交時間的不同而從第 77 百分位降到第 54 百分位。

真正的問題

出現了三個主要問題，挑戰 Leetcode 作為基準的可行性：

• 數據污染：使用公共問題風險使 LLM 在訓練期間看到了解決方案。研究人員必須僅使用 2023 年的問題來減少這一風險。
• 平台不穩定：Leetcode 的指標隨時間漂移——記憶測量顯示與測試日期的相關性為 -0.24。這使得可重複的基準測試幾乎不可能。
• 測量可靠性：地方測量與平台測量之間的弱相關性引發了我們實際上在測試什麼的質疑。

這對 LLM 基準測試的意義

這項研究不僅批評了 Leetcode——它突顯了我們在代碼生成基準測試中需要的東西：可重複的測量、可靠的性能指標和保證的訓練-測試分離。在我們擁有專門為此目的建立的平台之前，我們需要對使用競賽平台作為基準測試保持極大的謹慎。

所以！我們知道並非所有基準測試都是可行的基準測試——那麼更主流的基準測試呢？

案例研究 #2：SuperGLUE——建立更好的語言理解基準

SuperGLUE 論文探討了 AI 基準測試中的一個有趣問題：當模型在你的測試中變得太優秀時該怎麼辦？當 GLUE 不再足夠（模型超越人類表現）時，研究人員不得不重新思考我們如何測量語言理解。

基準設計

SuperGLUE 的核心創新在於其任務選擇方法。研究人員從 NLP 社區收集任務提案，並通過嚴格的過程篩選：每個任務都需要明確的評估指標、公共訓練數據，最重要的是，機器和人類表現之間需要有顯著的提升空間。

這導致了八個任務（我簡化了文檔中的表格，雖然可讀性稍差，但你應該能理解問題的要求）：

這些任務的特別之處在於它們格式的多樣性。與 GLUE 專注於句子分類不同，SuperGLUE 包含了共指解析、閱讀理解和更複雜的推理任務。每個任務測量語言理解的不同方面，同時保持清晰、可量化的指標。

第二部分：讓我們建立一個物理推理基準：在逃脫房間作弊

在查看了一些基準測試（如 SuperGLUE 和 Leetcode）後，我有了一個想法：如果我們在完全不同的領域測試 LLM——物理推理……通過逃脫房間的謎題呢？

這是一個相當合理的想法——逃脫房間提供了可能性和失敗的後果——如果你搞砸了太多謎題，你的朋友會覺得你很笨，並把你 relegated 到觀眾的位置。不過，幸運的是，他們（或可憐的員工）不知道你可以偷偷把手機帶進逃脫房間——而且你知道該向誰詢問答案。今天，LLMs 將面對物理逃脫房間的謎題。

注意：這並不是一個嚴謹的學術基準（請不要在論文中引用這個，為什麼你會想這樣做？），甚至也不接近，只是測試 LLM 基準測試和評估的一種有趣方式。請不要毀掉我的提示，我知道它們很糟糕。

為什麼選擇物理推理？

說真的……大多數 LLM 基準測試專注於語言任務（如 SuperGLUE）或代碼生成（如 Leetcode）。這是有原因的——這些是定義明確的領域，具有清晰的評估指標。但現實世界的問題解決往往需要理解物理原則及其相互作用。著名的「GPT-4 能做物理嗎？」辯論通常集中在數學問題解決上，而不是實際的物理推理。

查看現有基準測試讓我學到了一些關鍵原則：

• 清晰的評估指標至關重要（來自 SuperGLUE 的任務特定分數）
• 問題應該有明確的解決方案（來自 HumanEval 的測試案例）
• 基準測試應該測試不同的能力（來自 MMLU 的學科分類）

設計問題

我選擇逃脫房間的謎題有兩個原因。首先，它們自然結合了物理推理和明確的目標。其次，它們有明確的成功條件——要麼你通過預期的方式解決它，要麼你沒有。第三，最重要的是，它們讓我可以加入「紅鯡魚」——無關的項目，測試 LLM 是否能識別出物理上重要的東西。第四，我真的很喜歡做逃脫房間（我之前提到過嗎？），

我知道這不止兩個原因，但如果 LLM 不能計算出草莓中有多少個 r，我也可以偶爾犯錯。

以下是我結構化的五個核心問題：

流體動力學 (FLUID_001)（乒乓球卡在管子裡）

• 測試浮力和流體位移的理解
• 靈感來自經典物理問題，但在實際情境中
• 包括故意無關的項目（如軟食模型）

光的特性 (UV_001)（紫外線燈在推號鎖上）

• 測試對紫外線螢光和材料特性的理解
• 結合多個物理原則（光、材料科學）
• 需要理解環境條件

機械理解 (CIPHER_001)（一個密碼環）

• 測試空間推理和機械對齊
• 沒有紅鯡魚——測試將撥號盤與密碼輪相關聯的能力
• 需要理解旋轉對稱性

力的應用 (VAC_001)（罐子卡在洞裡）

• 測試對真空力和表面附著力的理解
• 多種可能的解決方法
• 需要理解力的放大

協作物理 (COLLAB_001)（兩個人能否一起動一把鑰匙？）

• 測試在多代理場景中的物理約束理解
• 需要結合多個物理原則
• 測試工具創造和摩擦的理解

聽起來真的很高級……但這些只是一些基本的物理謎題。你可以在我的 GitHub 上訪問它們。

技術部分

基準實現有三個主要組件：

問題定義層

問題以結構化的 JSON 格式定義，以強制執行一致的評估：

{

    "problem_id": "FLUID_001",

    "setup": {

        "scenario": "一個乒乓球在一根狹窄的管子底部...",

        "available_items": ["水瓶", "軟食模型"...],

        "constraints": ["管子太窄，無法手動取出"]

    },

    "physical_principles": ["浮力", "流體位移"],

    "red_herrings": ["軟食模型", "牛奶盒"],

    "solution": {

        "steps": ["將水倒入管中", "讓球浮起"],

        "key_insights": ["水排開空氣", "乒乓球的密度較小"]

    }

}

這個結構借鑒了 SuperGLUE 的設計——每個組件都清晰分開且機器可讀。physical_principles 字段明確列出正在測試的內容，而 red_herrings 有助於評分 LLM 忽略無關信息的能力。

2. 評估框架

評估系統使用 Python 的 asyncio 進行並發測試，並具有重試邏輯，以提高 API 的穩定性：

@retry(stop=stop_after_attempt(3), wait=wait_exponential(min=1, max=10))

async def evaluate_response(self, criteria: JudgingCriteria) -> Dict:

    """使用 GPT-4 作為評判來評估模型的回應。"""

    async with aiohttp.ClientSession() as session:

        # ... 評估邏輯

評分系統考慮三個組件：

• 物理理解分數 (PUS) ∈ [0,2]
• 測量相關物理原則的理解
• 計算為展示原則的標準化總和

• 解決方案路徑分數 (SPS) ∈ [0,2]
• 評估解決步驟的完整性和正確性
• 考慮提議解決方案的實際可行性

• 紅鯡魚處理 (RHH) ∈ {0,1}
• 避免使用無關項目的二元分數
• 測試專注於物理相關因素的能力

是的，還有很多其他的評分方法，可以用得更好或更差！例如，RHH 可以是解決方案中使用的無關項目的數量，或者可以是使用的可行性……重點是選擇這些指標往往是相當任意的，但對於使你的基準測試可信至關重要，而我的基準測試並不可信。

此外，我不想在之後重寫任何代碼。告我吧。

3. 模型介面層

基準測試通過通用介面支持多個 LLM 後端：

class ModelInterface:

    """不同 LLM API 的介面。"""

    async def generate_response(self, prompt: str) -> str:

        raise NotImplementedError



class GPT4Interface(ModelInterface):

    async def generate_response(self, prompt: str) -> str:

        # GPT-4 特定實現

class ClaudeInterface(ModelInterface):

    async def generate_response(self, prompt: str) -> str:

        # Claude 特定實現

兩個模型……我真的無法再負擔更多了，請理解。

讓我們測試一下！

所以在重新填充 API 餘額後，我準備好了。我運行了基準測試，經過完全沒有浪費信用的 5 次錯誤後，結果出爐了。結果是……有趣的！我使用了 GPT-4 和 Claude 3.5 Haiku（我知道這些模型的規格不相同）作為我們的受試者。

挑戰：一個罐子卡在一個幾乎與其體積完全匹配的洞裡。罐子底部寫著一組需要取出的組合。

"VAC_001": {

        "problem_id": "VAC_001",

        "setup": {

            "available_items": [

                "尺子",

                "筆記本",

                "吸盤",

                "紫外線燈"

            ],

            "constraints": [

                "罐子太緊，無法用手抓住",

                "洞的直徑與罐子相同",

                "罐子乾淨且乾燥"

            ]

        },

        "physical_principles": [

            "真空吸力",

            "表面附著力",

            "力的放大"

        ],

        "red_herrings": [

            "尺子",

            "筆記本",

            "紫外線燈"

        ],

        "solution": {

            "steps": [

                "檢查吸盤和罐子表面",

                "確保罐子表面乾淨",

                "將吸盤緊緊按在罐子頂部",

                "創建真空密封",

                "用吸盤拉出罐子"

            ],

            "key_insights": [

                "吸盤創建真空密封",

                "真空力允許提取",

                "其他物品無法提供必要的力量"

            ]

        }

GPT-4 的解決方案

物理原則：這個解決方案涉及的主要物理原則是空氣壓力差的概念，這也是吸盤能夠黏附在表面上的原理。吸盤外側的空氣壓力高於內側，這種壓力差使得吸盤黏附在表面上。

解決步驟：

• 將吸盤附著在罐子頂部。罐子的平坦表面應該能提供良好的接觸，使吸盤能夠黏附。
• 一旦吸盤牢牢附著，輕輕向上拉。空氣壓力差應該會使吸盤（因此也包括罐子）從洞中被提起。
• 一旦罐子從洞中取出，將吸盤從罐子頂部移開。
• 使用紫外線燈照亮罐子底部寫的組合。有些墨水只有在紫外線燈下才會顯現，因此這一步是必要的。
• 將組合寫在筆記本上，以確保不會忘記。

所需物品：

• 吸盤：這是必需的，用來黏附在罐子上並將其拉出洞，因為罐子太緊，無法用手抓住。
• 紫外線燈：這是必需的，用來顯示罐子底部寫的組合，因為它可能是用只有在紫外線燈下才能顯現的墨水寫的。
• 筆記本：這是必需的，用來記錄組合，一旦它可見，確保不會忘記。

不錯！GPT-4 能夠理解解決方案背後的物理原則（即使表達得很冗長），並逐步描述如何解決問題。它確實使用了紫外線燈和筆記本，但這更多是我這邊的問題，沒有足夠懲罰使用不必要的物品。此外，這些物品的用途似乎相當合理……所以為什麼不呢！

Haiku-3.5 的解決方案

物理原則：這個場景中涉及的關鍵物理原則是體積的概念和使用吸力將罐子從洞中提取出來。由於罐子幾乎完全適合洞，因此它可能因為緊密的配合和缺乏任何空氣間隙而卡住。這種緊密的配合產生了類似真空的效果，使得抓住並拉出罐子變得困難。

解決步驟：

• 使用尺子測量罐子的直徑。這將幫助確定洞的大小，並確認罐子是否緊密適合。
• 檢查罐子的底部以找到寫在上面的組合。使用紫外線燈照亮罐子底部，使組合可見，如果它尚未清晰可見。
• 將吸盤附著在罐子頂部。吸盤將在罐子的表面創建一個臨時密封，讓你能夠抓住並將其拉出洞。
• 輕輕用吸盤向上拉罐子。吸力應該足夠強大，以克服類似真空的效果，將罐子從洞中提取出來。
• 一旦罐子取出，將罐子底部寫的組合記錄在筆記本上。

所需物品：

• 尺子：用來測量罐子的直徑，確認它在洞中緊密適合。
• 紫外線燈：用來照亮罐子底部，使組合可見，如果它尚未清晰可見。
• 吸盤：用來在罐子的表面創建臨時密封，提供必要的抓握力以將罐子拉出洞。
• 筆記本：用來記錄罐子底部寫的組合。

另一方面，Haiku 的解決方案……確實是一個解決方案。

首先，它想用尺子測量罐子的直徑？？？為了確定洞的大小並確認罐子是否緊密適合？我們為什麼需要這樣做？我們真的需要尺子嗎？

其次，它告訴我們檢查罐子底部以找到組合，但整個問題都是關於無法以常規方式將罐子拉出洞。這可能只是順序的問題，但現在我真的理解了我的朋友們每次我告訴他們「就這樣修好它」時的感受。

但它最終確實得到了解決方案。所以……也不是最糟糕的。

這裡有一個華麗的雷達圖顯示結果！

我們看到這兩個模型在能力上非常相似，GPT-4 在物理理解和解決路徑上稍微好一些，而 Haiku 在紅鯡魚處理上稍微好一些。總的來說，這兩個模型都不太好。真糟糕。

而且只有……5 個問題。

如果你想看看完整的問題範圍，它們在我的 GitHub 上。

LLM 作為評判

順便提一下，我用來生成評估的方法，LLM 作為評判，在 AI 社區中獲得了相當大的關注，特別是在 Zheng 等人 2023 年的論文「LLM 作為評判的評估」之後。這種技術已被證明非常有效，在從代碼評估到對話質量評估的任務中，與人類評估者的協議達到 80% 以上！

這裡是我的實驗變得有趣的地方（可以說，也許，主觀上）——我使用這種方法讓 GPT-4 評估其他 LLM 的物理推理能力。是的，我在用 AI 來評判其他 AI。

為什麼這樣有效？因為評估一個回應實際上是一個比生成回應更簡單的任務。當 GPT-4 生成一個物理謎題的解決方案時，它需要：

• 理解涉及的物理原則
• 計劃一系列步驟
• 考慮所有約束條件
• 生成一個連貫的解釋

但在評估時，它只需要檢查現有解決方案是否滿足特定標準。評估提示非常集中：

def _create_evaluation_prompt(self, criteria: JudgingCriteria) -> str:

    return f"""你是一位專家評判，正在評估 LLM 對物理推理謎題的理解。



    根據三個標準進行評估：

    2. 物理理解分數 (0-2)：解決方案是否正確應用相關的物理原則？

    3. 解決方案路徑分數 (0-2)：步驟是否完整且可行？

    4. 紅鯡魚處理 (0-1)：是否避免使用無關項目？

    情境：{criteria.scenario}

    需要的物理原則：{criteria.correct_principles}

    給出的解決方案：{criteria.model_response}

    """

為了驗證這種方法，我遵循了 Zheng 等人建議的驗證框架，對 GPT-4 的評估進行了隨機檢查，與我自己的判斷進行對比。令人驚訝的是（或者也許不驚訝，考慮到 LLM 評估的更廣泛研究），它在識別正確的物理理解和錯誤推理方面非常一致。

這完美嗎？絕對不是。用一個 LLM 來評估另一個 LLM 在哲學上有些奇怪。但在實踐中，它可以意外地運作得相當好——就像我在 Masterchef 上對一道菜的視覺呈現抱怨時，卻在廚房裡試圖微波加熱熱狗，卻把廚房燒了。

我學到了什麼

建立這個基準測試讓我學到了幾件關於基準設計的事情：

• 清晰的指標很重要：即使對於像物理推理這樣複雜的任務，你也需要明確的評分標準。
• 紅鯡魚的威力：包括無關項目可以揭示很多關於 LLM 推理過程的資訊。
• 上下文控制很難：確保 LLM 不會「幻覺」出額外的物理上下文是具有挑戰性的。

這是一個完美的基準測試嗎？遠非如此。請不要再提了。它在科學上嚴謹嗎？絕對不是。但這是一個有趣的探索，讓我們了解 LLM 的能力，有時候我們能學到的最好東西來自於嘗試並看看會發生什麼。

現在，如果你能原諒我，我將在我的下一個逃脫房間中偷偷帶入一部連接到互聯網的手機，原因我法律上無法透露。

[1] L. Zheng, W.-L. Chiang, Y. Sheng, S. Zhuang, Z. Wu, Y. Zhuang, Z. Lin, Z. Li, D. Li, E. P. Xing, H. Zhang, J. E. Gonzalez, I. Stoica, “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena,” Proceedings of the 37th Conference on Neural Information Processing Systems (NeurIPS 2023), Datasets and Benchmarks Track (2023)

[2] T. Coignion, C. Quinton, R. Rouvoy, “A Performance Study of LLM-Generated Code on Leetcode,” In 28th International Conference on Evaluation and Assessment in Software Engineering (EASE 2024), Salerno, Italy (2024)

[3] A. Wang, Y. Pruksachatkun, N. Nangia, A. Singh, J. Michael, F. Hill, O. Levy, S. R. Bowman, “SuperGLUE: A Stickier Benchmark for General-Purpose Language Understanding Systems,” In 33rd Conference on Neural Information Processing Systems (NeurIPS 2019), Vancouver, Canada (2019)

[5] DeepSeek-AI, D. Guo, D. Yang, H. Zhang, J. Song, R. Zhang, R. Xu, Q. Zhu, S. Ma, P. Wang, X. Bi, X. Zhang, X. Yu, Y. Wu, Z.F. Wu, Z. Gou, Z. Shao, Z. Li, Z. Gao et al., “DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning,” arXiv preprint arXiv:2501.12948 (2025)

[6] 除非另有說明，所有圖片均由作者創建。