先講結論:三個數字,但可信度唔同
如果只想快速掌握 Claude Opus 4.7 的公開 benchmark,現時最清晰可以歸納為三個數字:SWE-bench Verified 87.6%、GPQA 94.2%、SWE-bench Multilingual 80.5%。當中,SWE-bench Verified 87.6% 是最穩陣的參考點,因為有多個公開來源提到同一個數字。[4][
5]
不過,benchmark 唔等於實際生產表現。尤其係團隊要揀模型、做 API 遷移、或者將 AI agent 放入真實軟件工程流程時,分數只係第一層篩選,最後仍然要靠自己 repo、自己工具鏈、自己驗收標準去試。
核心 benchmark 一覽
| Benchmark | Claude Opus 4.7 公開提及分數 | 點樣理解來源可信度 |
|---|---|---|
| SWE-bench Verified | 87.6% | 今次資料入面最有力的 coding benchmark 參考點;同一數字被多個來源提及。[ |
| GPQA | 94.2% | LLM-Stats 有清楚列出,但現有 Anthropic 摘要未見完整 benchmark 表可直接引用。[ |
| SWE-bench Multilingual | 80.5% | 另一來源提到,並指 Opus 4.6 為 77.8%;但來源較薄,要保守看待。[ |
呢張表刻意採取保守做法:只收錄目前公開資料中明確出現的數字。對企業採購、模型遷移或者生產系統選型而言,佢唔應該取代內部測試。
點解 SWE-bench Verified 最值得優先睇
SWE-bench Verified 的 87.6%,係目前關於 Claude Opus 4.7 最有來源支撐的 benchmark 數字。無論係遷移/benchmark 文章,定係 LLM-Stats,都提到同一個 87.6% 分數。[4][
5]
LLM-Stats 亦將 87.6% 解讀為較 Opus 4.6 高 6.8 個百分點。[5] ALM Corp 亦形容 Opus 4.7 在困難 coding 同 agentic workflows 上有更強表現。[
6]
對做 software engineering workload 的團隊嚟講,SWE-bench Verified 可以作為公開比較的起點。它有用,但唔好將它當成終點:真實情況要睇模型能否處理你哋自己的 codebase、測試框架、CI/CD、工具調用、code review 標準同安全要求。
GPQA:分數亮眼,但要多一層核實
GPQA 的 94.2% 在 LLM-Stats 裡面有清楚列出。[5] 同時,Anthropic 官方頁面作為一手來源當然重要;但在目前可見摘要中,較明確可確認的是開發者可以透過 Claude API 使用
claude-opus-4-7,未見完整 benchmark 表可在這裡直接引用。[7]
所以,GPQA 可以視為 Claude Opus 4.7 的重要補充訊號,但可信度權重應該低過 SWE-bench Verified。若果 GPQA 會影響採購、遷移或者模型路線決定,最好再對照官方完整材料,或者用自己題庫和工作流重新測試。[5][
7]
SWE-bench Multilingual:對多語言 codebase 有參考價值
如果團隊維護多語言 codebase,或者工程環境唔只用英文,SWE-bench Multilingual 80.5% 會幾值得留意。有來源提到 Claude Opus 4.7 在 SWE-bench Multilingual 升至 80.5%,並對比 Opus 4.6 的 77.8%。[9]
但限制亦要講清楚:呢個數字在現有來源中冇 SWE-bench Verified 咁廣泛出現。所以它可以作為初步參考,特別係國際化 codebase、混合語言 stack、或者非英文開發環境;但仍然唔應該取代實測。[9]
Benchmark 以外,實際使用仲要睇咩?
Claude Opus 4.7 唔只係一堆分數。VentureBeat 形容它是 Anthropic 當時公開發布的最強大型語言模型。[1] ALM Corp 則將 Opus 4.7 描述為已一般可用的 Opus 模型,面向高要求的 coding、agent、文件同 vision 工作流。[
6]
對實際選型嚟講,以下產品特性可能同 benchmark 一樣重要:
- Context window: LLM-Stats 提到 Claude Opus 4.7 有 1 million tokens context window。[
5]
- Vision: LLM-Stats 提到其 vision 處理支援 3.3 倍更高解像度。[
5]
- Effort level: LLM-Stats 同 ALM Corp 都提到新增
xhigheffort level。[5][
6]
- Tokenizer: ALM Corp 指出更新後的 tokenizer 可能令同一段 input 產生更多 token。[
6]
呢幾點會直接影響成本、延遲同結果質素。尤其 tokenizer 改動,遷移前一定要試清楚,因為它可能改變你原本對 token 用量、budget 同 max token 設定的估算。[6]
團隊應該點樣用呢啲數字?
如果主要做 coding: 可以用 SWE-bench Verified 做公開比較基準。87.6% 是目前資料中最有支撐的分數。[4][
5]
如果做 agent workflows: 除咗 benchmark,亦要睇模型對困難 coding、長時間 agent 任務,以及 xhigh effort level 的支援。[5][
6]
如果重視 general reasoning: GPQA 94.2% 有參考價值,但現有資料中未有 SWE-bench Verified 咁多來源互相確認。[5][
7]
如果有多語言 codebase: SWE-bench Multilingual 80.5% 可以作為提示,但因為來源較薄,最好配合內部測試。[9]
如果準備上 production: 唔好只跑接近 benchmark 的題目。應該一併測試長 context、工具調用、vision case、token 消耗、延遲、錯誤處理同回歸測試。Context window、vision、effort level 同 tokenizer 變動,都可能明顯影響實際使用體驗。[5][
6]
總結
最保守而可引用的講法是:Claude Opus 4.7 目前公開資料中出現的主要 benchmark 包括 SWE-bench Verified 87.6%、GPQA 94.2%、SWE-bench Multilingual 80.5%。[4][
5][
9]
當中,SWE-bench Verified 87.6% 是最強參考點,因為有多個來源提到同一分數。[4][
5] GPQA 同 SWE-bench Multilingual 都係有用訊號,但來源支撐相對較少。對真正要落地的團隊而言,公開 benchmark 最好用嚟做初步篩選;最後決定,仍然要靠自己 workflow 的實測結果。




