醫院 AI 不能只看基準測試——為什麼上線使用需要不同的監控

一句話。 公開基準測試是別人的考卷。在醫院裡，臨床人員在真實責任與流程壓力下提出不可預測的問題。近期同儕審查的部署經驗反覆押韻：監控必須跟著上線使用走——而不只看排行榜。

兩個不同的問題

問題	它回答什麼	它漏掉什麼
「模型在共享測試上分數高嗎？」	相對同儕的粗略能力	你的 SOP、語言、權限、拒絕規則
「這裡、這週是否安全又有用？」	上線接受、拒絕、站不住腳的宣稱	靜態套件幾乎沒見過的一切

買家常聽到第一個答案，卻以為買到了第二個。

當臨床人員驅動提示時，什麼變了

在真實醫療中心，「使用者」不是乾淨的基準提示：

• 問題出現在查房中、寫紀錄中、交接中。
• 同一句話依角色與部門可能代表不同工作。
• 回饋稀疏——沉默的拒絕可能是唯一訊號。
• 責任落在人與機構身上，不在排行榜名次上。

因此系統可以在紙上很強，卻仍在現場產出站不住腳的宣稱或無用答案。這不是要恐慌 AI，而是要看部署，而不只看行銷 PDF。

冷靜買家清單

釐清	夠好的答案聽起來像…
流程	「我們評估的是這些臨床任務，而不只是公開套件。」
監控	「上線後我們會記錄拒絕、升級，以及站不住腳宣稱的模式。」
誰能問什麼	「存取依角色範圍；評估用了相同範圍。」
何時停下	「若監控觸發，我們會限流、棄權或回滾——劇本在這裡。」
誠實	「這些是我們已見過的失敗模式——不會藏起第一週。」

軟橋接 OrchAI（一小段）

OrchAI Eval 是套件的品質檢查概念：在變更到達使用者前，用約定套件檢查 AI 介面。出貨狀態仍是 Partial（監控／CI 閘門框架）——因此這篇是識字，不是功能手冊。有用的習慣比任何產品名都老：在你實際跑的流程裡評系統。

這篇文章不是什麼

• 不是任何單一醫院機密結果的摘要。
• 不是 AiHPC 評估過 ChatEHR 或任何具名臨床堆疊的宣稱。
• 不是香港醫管局／衞生署計畫。
• 不是醫療建議。

另見

• 策略筆記：Stanford ChatEHR 部署評估 · W34 摘要
• 姊妹識字：排行榜 vs 你的工作 · 同一個 API 名稱 ≠ 同一個模型
• 系列主頁：科普方向