醫療 AI 的評測一直是個難題。臨床情境複雜、專業門檻高、語言多元、風險不對稱——一個回答「聽起來合理」和「臨床上可執行」之間的距離，可能是一條人命。
OpenAI 在 2026 年 4 月發布 HealthBench，試圖把這個模糊的評測問題結構化：5,000 段多輪對話、48,562 條評分標準、262 位執業醫師、60 個國家——這個規模，在公開醫療 AI 基準裡目前沒有先例。
HealthBench 的核心設計
規模與結構
| 維度 | 數字 |
|---|---|
| 對話數量 | 5,000 段 |
| 評分標準（rubric） | 48,562 條 |
| 參與醫師 | 262 位 |
| 覆蓋國家 | 60 個 |
| 主要語言 | 英文 + 西班牙文 + 葡萄牙文（85%） |
| 其他語言 | 29 種 |
每段對話都是多輪的，模擬真實的醫療問診或諮詢流程，而不是單一 Q&A。每段對話都附有醫師手寫的評分標準，說明「一個好的回答應該包含什麼」以及「哪些回答是危險的」。
雙角色設計：一般人與臨床醫師
HealthBench 明確區分兩種使用者角色：
- Layperson（一般民眾）：不具備醫學背景，詢問症狀解釋、藥物用途、生活保健等問題
- Clinician（臨床醫師）：具備專業知識，詢問鑑別診斷、治療選項、藥物交互作用等問題
這個設計承認一個現實：同樣的問題，由不同背景的人提出，好的回答長得完全不一樣。一個關於「高燒要不要去急診」的問題，對一般民眾和兒科醫師的最佳回答是兩件不同的事。
評測架構：GPT-4.1 當裁判
評分流程是：把 LLM 的回答和醫師寫的 rubric 一起交給 GPT-4.1，讓 GPT-4.1 判斷這個回答有沒有滿足各條標準。每條標準有正分（滿足加分）和負分（有害回答扣分）兩種方向。
這個設計把評測本身也變成了 AI 系統的一部分，不可避免地引入了 GPT-4.1 本身的判斷偏差。OpenAI 在報告裡正視了這個問題，但並未完全解決。這是目前所有「LLM-as-Judge」評測架構的共同局限。
主要評測結果
HealthBench 主要模型分數（示意，以官方報告為準）
GPT-4.1 在自己主導建立的基準上取得最高分——這個結果本身就值得保持懷疑。一方面，評測設計方有能力（有意或無意地）讓基準偏向自家模型的優勢；另一方面，GPT-4.1 同時也是評分裁判，裁判和選手是同一家公司的產品，這個結構性問題不容忽視。
HealthBench 公開了完整資料集和評測程式碼，讓第三方可以自行驗證。這是值得肯定的做法，也是讓這份評測有意義的前提條件。
為什麼這個基準比以前的設計更難
過去的醫療 AI 評測大多是選擇題——USMLE、MedQA、MedMCQA。這類基準的問題很清楚：醫師在臨床上做的事，幾乎從來不是從四個選項裡挑一個。
HealthBench 的難點在三個地方：
多輪對話：患者不會一次說清楚所有症狀。模型必須在有限資訊下追問，整合多輪線索，而不是在一個完整問題上產生答案。
開放式生成：回答沒有標準答案，只有「是否滿足 rubric」的判斷。這更接近真實的臨床評估，但也讓評測結果更難解釋。
多語言：85% 的對話是英文加西班牙文和葡萄牙文，另外 29 種語言涵蓋非洲、東南亞、中東市場。這直接測試模型在非英語醫療場景下的能力，而不是讓英語能力強的模型佔便宜。
資料與程式碼的開放程度
HealthBench 在幾個層面上是真正公開的：
- 完整資料集：5,000 段對話 + 所有 rubric 發布在 Hugging Face
- 評測程式碼：發布在 GitHub，任何人可以跑自己的模型
- 評分標準透明：rubric 的設計邏輯和醫師協作流程在論文中有完整說明
這讓 HealthBench 不只是一份排行榜，而是一個可以被研究社群獨立使用和批評的工具。
這個評測的限制
直接說幾個明顯的問題：
語言代表性不足：29 種「其他語言」加起來只佔 15%。對於中文、阿拉伯文、印地文這些使用人口龐大的語言，樣本數量可能還不夠做可靠的子群分析。
臨床情境 vs 急性照護：5,000 段對話再多，也覆蓋不了所有醫療專科和緊急情境的長尾。一個在常見內科問題上得分很高的模型，在稀有病、急救流程、或兒科用藥上的表現，可能完全不同。
靜態基準的老化問題：醫學指南會更新，治療標準會改變。一個今天在 HealthBench 上高分的模型，三年後可能因為訓練資料沒跟上最新臨床建議而出錯。
不測量「不作為」的成本：現有 rubric 評分偏向回答的正確性，但醫療 AI 的一個重要問題是「什麼時候應該說不知道、建議去看醫生」。過度自信的模型可能在這個評測上反而得分更高。
對 AI 工程師的實際意義
如果你在做醫療相關的 LLM 應用，HealthBench 給了幾個可以直接用的東西：
rubric 設計的參考框架：醫師寫 rubric 的方式——把「好的回答要包含什麼」和「危險的回答是什麼」分開描述——這個思路可以直接用在你的應用評測設計上。
多語言醫療對話資料集：Hugging Face 上的資料集本身就是有價值的訓練材料，尤其是非英語對話部分。
LLM-as-Judge 的一個具體實作範例：用 GPT-4.1 對照 rubric 評分的流程，是目前可擴展的開放式生成評測裡設計較完整的一個，值得研究其 prompt 設計。
結語
HealthBench 不是醫療 AI 評測的終點，但它把標準推到了一個更難的地方。從選擇題到多輪開放式對話、從單一語言到 32 種語言、從學術題庫到執業醫師手寫標準——這些都是正確的方向。
更重要的是，它是公開的。任何人可以拿自己的模型去測，任何研究者可以批評它的設計缺陷，任何工程師可以參考它的評測架構。這種開放性，比排行榜上的具體分數更值得關注。