OpenCompass：把模型評測拆成資料集、模型與評分器三層設定
OpenCompass is an LLM evaluation platform, supporting a wide range of models (Llama3, Mistral, InternLM2,GPT-4,LLaMa2, Qwen,GLM, Claude, etc) over 100+ datasets.
秒懂
- 它是什麼？
- OpenCompass 是 Apache-2.0 的 LLM 評測平台，用設定檔組合資料集、模型與評分器。這篇談它的實際機制、啟動指令、以及什麼情況下你應該改用別的方案。
- 適合誰用？
- 如果你需要在一台或一組機器上跑多個模型對多個資料集的橫向比較，而且願意接受設定檔驅動的工作流，OpenCompass 值得先跑一次 examples 目錄裡的單一資料集範例再決定。若你只需要在 CI 裡對單一模型做幾十題的煙霧測試，這套依賴與設定層數會比自寫腳本更重。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是評測流程的可重組問題，不是分數本身
自己寫評測腳本的人很快會遇到同一個瓶頸：模型換了要改推論程式碼，資料集換了要改前處理，評分方式換了要重寫比對邏輯，三件事糾纏在同一支檔案裡。OpenCompass 的做法是把這三層拆成可獨立替換的設定：模型設定描述怎麼呼叫模型，資料集設定描述題目與提示模板，評分器設定描述怎麼把輸出變成分數。README 的 Breaking Change Notice 提到 0.4.0 版把原本散在 ./configs/datasets、./configs/models、./configs/summarizers 的設定檔整併進 opencompass 套件內，使用者需要更新設定引用路徑。這個改動本身說明了它的設計重心：設定是套件的一部分，不是使用者專案裡的散檔。
適用對象因此相當明確。一是要對多個模型跑同一組基準、產出可比較表格的團隊；二是要反覆調整提示模板或評分規則、想知道改動造成多少差異的研究者。反過來說，只想驗證自家微調模型有沒有退化的工程師，未必需要這一整套抽象。
推論與評分是兩個可分別觸發的階段
從 repository 的目錄與近期公告可以看出它的執行模型。推論由 GenInferencer 這類 inferencer 負責，把資料集題目轉成提示、送進模型、把輸出落盤；評分則由 evaluator 負責，讀取落盤的輸出後計分。2026.03.20 的公告指出它支援跨任務的並行推論與 evaluation watching，讓已完成的推論任務被監看並觸發後續評分，並提到 parallel inferencers、task monitoring 與 heartbeat 機制。這個切分的實際好處是：模型呼叫很貴、評分相對便宜，兩階段分離後你可以重跑評分而不重跑推論。
評分端的擴充點是 CascadeEvaluator，2025.04.01 的公告說它讓多個 evaluator 依序工作，用來組出客製化的評分流程。另一個相關設計是 RawPromptTemplate，2026.03.17 的公告說它讓原始基準提示與結構化對話不經過非預期的格式轉換就送到模型，支援 API 模型與 ChatML 資料集，並可在模型端附加額外提示內容。這一點對重現論文分數很關鍵：提示模板多一層包裝，分數就未必能與原始基準對齊。
多模態是後來才接上的。2026.08.25 的公告說它整合 VLMEvalKit，可原生載入多模態資料集、透過 OpenAI 相容 API 推論、並使用 VLMEvalKit 的官方指標評分，並指向 examples/eval_mmbench_vlmevalkit.py 與 examples/eval_mmmu_pro_vlmevalkit.py 兩個範例。這代表多模態路徑實際上是把評分外包給另一個專案，而非在 OpenCompass 內部重寫。
安裝與最小啟動路徑
README 把安裝導向 docs 的 installation 頁面，並未在 README 內文中列出安裝指令，所以具體安裝步驟要以官方文件為準，我不會在此虛構指令。可以確定的是它是一個 Python 套件，預設分支為 main，授權為 Apache-2.0。
設定引用方式在 0.4.0 之後要指向套件內的 opencompass/configs 路徑。公告中直接點名的設定檔可作為起點：多輪指令跟隨用 opencompass/configs/datasets/MultiIF/MultiIF_gen.py，多模態用 examples/eval_mmbench_vlmevalkit.py 與 examples/eval_mmmu_pro_vlmevalkit.py，特定模型則有 examples/eval_intern_s1_pro.py 與 examples/eval_scireasoner.py。這些是公告列出的實際檔案路徑，拿它們當第一個可跑範例，比從零拼設定檔務實。
模型端在 2026.07.28 的公告中擴充了 OpenAI Responses API 與 LiteLLM AI Gateway，並更新 Gemini 與 Anthropic 到較新的 SDK 介面，對應檔案為 opencompass/models/openai_response.py、opencompass/models/litellm_api.py、opencompass/models/gemini_sdk_api.py、opencompass/models/claude_sdk_api.py。若你要評測的是閉源 API 模型，這幾個實作決定了你能不能用上供應商的新介面。
另外有一個容易忽略的工具：tools/analyze_repeat.py，2026.05.25 的公告說它用來偵測現行評測任務或既有結果中的重複內容與迴圈輸出。跑長輸出的推理模型時，這類失敗模式會直接汙染分數。
LLM-as-judge 會把成本與不確定性一起帶進來
GenericLLMEvaluator 是 2025.02.15 公告中提到的 LLM-as-judge 評測工具。用模型當評審能處理沒有標準答案的開放式題目，代價是每次評分都要再打一次 API，而且評審模型本身的版本變動會讓歷史分數失去可比性。CascadeEvaluator 讓多個 evaluator 依序執行，彈性更大，但鏈條越長，你越難回答某個分數究竟由哪一環決定。
這不是實作缺陷，而是這類方法的固有性質。使用前該確認的是：評審模型是否固定版本、評分提示是否隨版本改動、以及是否有規則式評分可以先用來交叉檢查。若你的題目大多有客觀答案，硬套 LLM-as-judge 只是多花錢。
限制與不適用的情況
第一，設定檔驅動的框架有學習曲線。0.4.0 把設定整併進套件並要求使用者更新引用路徑，這種破壞性變動在 0.x 版本還會再發生。把 OpenCompass 設定寫死在 CI 裡的團隊，升級時要預留修正路徑的時間。
第二，資料集覆蓋廣不等於每個資料集都被同等維護。README 開頭說支援 100+ 資料集，但近期公告的重心明顯偏向多模態、多輪指令跟隨與特定模型（Intern-S1、SciReasoner、DeepSeek-R1 教學）。冷門資料集的指標是否與原論文一致，需要自己核對，這件事無法從 README 判斷。
第三，專案首頁與 CompassRank 是公開排行榜，README 也直接邀請使用者按 star 以接收 release 通知。若你的用途是內部模型選型、不希望分數外流，要確認評測流程是否會把結果上傳或發布到任何公開端點。這一點在提供的材料中沒有說明，請自行查證後再跑。
第四，多模態評分依賴 VLMEvalKit。你要同時接受兩個專案的版本相容關係，升級其中一個就可能影響另一個。
替代方案：lm-evaluation-harness 的取捨不同
最常被拿來對比的是 EleutherAI 的 lm-evaluation-harness。兩者的差異在抽象層的位置。lm-evaluation-harness 以任務（task）為中心，把提示模板、few-shot 範例與評分函式綁在同一個任務定義裡，新增基準就是新增一個任務檔，模型端則透過統一的介面接上 HuggingFace 或 API。它的重心是把大量學術基準以一致方式跑完。
OpenCompass 把模型、資料集與評分器拆成三份設定再組合，並把推論與評分切成兩個可分別觸發的階段。這個切法在「同一批模型跑很多資料集、且要重跑評分」時更省事，代價是設定層數更多、路徑引用更容易在版本升級時斷掉。反過來，若你只想把某個既有基準跑一次並與論文數字對齊，lm-evaluation-harness 的任務定義通常更直接。
選擇的判準不是哪個更強，而是你的工作量落在哪一側：橫向比較多個模型、需要客製評分鏈，OpenCompass 的結構更合適；單一基準、單一模型、要求與原論文一致，另一邊的摩擦更小。
維護成本與授權
授權是 Apache-2.0，允許商業使用與修改，需保留版權與授權聲明，並包含專利授權條款。這是寬鬆授權，對內部工具或商業產品整合都不構成授權障礙。但這不是法律意見，涉及再散布或商標使用時請找法務確認。
維護成本主要來自版本節奏。從近期 release 看，0.5.2 在 2026.02.14、0.5.3 在 2026.06.29、0.5.4 在 2026.08.26，大約每季一次小版本，且 0.4.0 出現過破壞性設定路徑變動。實務上的做法是把評測設定與 OpenCompass 版本一起鎖住，升級時先跑一個小資料集確認設定路徑沒有失效，再跑完整評測。這個檢查用 examples 目錄裡的單一範例即可，不需要動用完整基準。
另一個成本是模型 API 費用。用 API 模型跑大規模基準時，推論與 LLM-as-judge 評分會各產生一次呼叫量，兩階段的帳單要分開估算。
編輯結論
如果你需要在一台或一組機器上跑多個模型對多個資料集的橫向比較，而且願意接受設定檔驅動的工作流，OpenCompass 值得先跑一次 examples 目錄裡的單一資料集範例再決定。若你只需要在 CI 裡對單一模型做幾十題的煙霧測試，這套依賴與設定層數會比自寫腳本更重。動手前先確認三件事：你的模型是否已有現成的模型設定可直接引用、你要用的資料集是否在 opencompass/configs/datasets 底下、以及你的評分是否需要 LLM-as-judge 而帶來額外的 API 成本。
社群筆記