1,368 起 AI 失效案例，以及它們對評估（evals）的啟示——Vishal Srivastava 與 Tanmay Sah，New York Life

Vishal Srivastava 專門研究 AI 失效，他主張 AI 評估應以風險為基礎、以系統為層級，而非以發生頻率為基礎、只看模型本身，因為相較於模型的技術性失效，部署控制與危害的關聯更強。在這場 19 分鐘的對談中，他與資深量化模型專家暨 AI 研究者 Tanmay Sah 對談，逐一說明一套 13 構面的失效分類法（建構自 AI 事故資料庫）、一套用來排序使用案例的重大性量表，以及一套取自 Peter Wason 確認偏誤研究的「建構、破壞、修復」評估迴圈。節目最後以單一航空客服機器人的仲裁案例收尾，說明只看模型的狹隘評估為何會完全漏掉這起失效。

兩位講者都從事 AI 失效調查與模型風險工作。以下簡報重建了他們的框架，細節足以讓讀者不必收聽節目，也能直接套用 13 個子構面、危害關聯排序與失效驅動的評估迴圈。標題所稱的「1,368 起 AI 失效」是這項研究的事故基數；真正的重點是建立在這之上的分類法與評估方法。

相較於模型的技術性失效，部署控制對危害的影響更大

核心實證發現是一個排序，而不是一個計數。兩位講者將事故對應到 13 個子構面，並把每個構面與危害的關聯程度（y 軸）對上它出現的頻率（x 軸）作圖後，發現與危害最相關的構面是人為中介（human-in-the-loop 的實際有效性）與危害偵測（是否設有監控控制）。規模與系統設計等構面出現頻率高，但與危害的相關性較低。實務上的指引是：依危害潛力而非失效模式的出現頻率來分配調查資源。

依最高層級分組，排序是部署控制優先、業務衝擊其次、技術失效最後。Vishal 的結論是：對高風險系統而言，事前把部署控制做對，比單獨檢視模型的技術失效模式更能提供保證。

| 層級 | 子構面 | 與危害的關聯 |
|---|---|---|
| 部署控制 | 人為中介、危害偵測／監控、決策許可權、曝險控制 | 最高 |
| 業務衝擊 | 財務衝擊、法律後果、規模（受影響使用者數） | 中等 |
| 技術強度 | 資料品質、系統設計、預測效度、公平性、失效模式、可解釋性 | 三者中最低，但其中數項出現頻率最高 |

這套框架建立在兩項結構性事實上。第一，AI 失效呈指數上升——Vishal 表示，過去四年、也就是基礎模型時代，出現「幾乎垂直」的跳升。第二，失效是多因的：在調查過的每起事故中，平均同時存在 13 個子構面中的六個。13 個構面合計涵蓋資料庫中 98% 的 AI 失效，兩位講者據此認為失效具有結構、可以被描繪，而非只能逐案處理。

13 構面分類法涵蓋 98% 已記錄的 AI 失效

這套框架把 AI 生命週期拆成三個階段——開發、部署、業務情境——並追問各階段可能出什麼錯。開發階段引入的錯誤會往後傳遞，但若部署控制足夠，就能在錯誤抵達業務情境之前將其攔下；一旦進入業務情境，錯誤就會變成聲譽、法律或財務風險。Vishal 的說法是：模型的技術強度「只是系統的一部分。我們必須整體地看這個系統。」

flowchart TD
    A["開發階段 — 技術強度"] --> B["部署階段 — 控制"]
    B --> C["業務情境 — 衝擊"]
    A --> A1["資料品質、系統設計、預測效度、公平性、失效模式、可解釋性"]
    B --> B1["決策許可權、人為中介、曝險控制、監控"]
    C --> C1["財務衝擊、法律後果、受影響使用者規模"]
    A1 -.->|"若未受控，錯誤會向外傳遞"| B
    B1 -.->|"在造成危害前攔下錯誤"| C

兩位講者特別強調部署層的子構面。決策許可權問的是：AI 是提供資訊給人，還是代替人行動。人為中介問的是：human-in-the-loop 實際上有多有效。曝險控制區分內部員工與外部顧客——內部員工看到錯誤還能攔下，外部顧客則身處「真實環境」，任何小問題都會快速擴散。監控問的是：生產環境中的問題是否被偵測到並受到控制。

重大性量表讓企業在分配審查量能前先排序使用案例

Vishal 提出的動機是量能：企業的 AI 使用案例數量，遠超過逐一審查的能力。重大性量表依風險排序 AI 使用案例，讓資源流向重大性最高者。重大性「直接依使用案例相關的危害排序」，且量表可以依公司量身訂做。風險被拆成四個成分：模型出錯的頻率、該錯誤是否觸及真實決策、是否未被攔下、後果有多嚴重。同一個模型可能因部署方式不同而承擔不同風險，這也是為什麼評估必須涵蓋部署配置，而不只是模型。

代理式系統擴大了測試邊界，但測試邏輯不變

Tanmay Sah 的論點是延續，而非斷裂。傳統 ML 本來就會測試假設、輸入資料與壓力下的行為；把這套紀律延伸到整個部署系統，只是在同一標準下提出新問題：

• 檢索是否取回正確資訊？
• 工具失效時會發生什麼？
• 人工審查能否抓到錯誤？
• 代理是否守在自己的許可權邊界內？
• 系統能否復原？

他對比的是兩種測試：一種是在留出資料上用準確率、AUCROC 等指標測試模型；另一種是測試代理式系統，其部署面涵蓋大量可能的輸入、工具回應與動作序列（軌跡或 rollout）。代理式測試只抽樣選定情境，有時由另一個 AI 代理或 AI 評審生成或評判——而評審本身可能出錯，測試也可能漏掉重要失效。因此他的結論是：「評審者是系統中我們要治理的那一部分。」對評審者的檢查包括：它是否可靠、它的證據涵蓋什麼、以及它是否針對實際部署的系統。

評估應該試圖否證，而非確認——把 Wason 的 2-4-6 問題套用到 AI

Vishal 從認知神經科學借來方法。Peter Wason 提出確認偏誤，並做了 2-4-6 數列實驗：受試者被要求預測下一個數字，多數人給出 8、10 等偶數，但規則其實只是「任何遞增數列」。Vishal 引用資料指出，受測者中有 79% 答錯。由於 AI 系統以人類產生的資料訓練，他主張評估必須否證，而非確認。

由此得出的迴圈是建構、破壞、修復，反覆進行直到建立信心：

flowchart TD
    A["陳述系統主張"] --> B["主動設法破壞它"]
    B --> C["找出主張失效之處"]
    C --> D["修復 — 限縮範圍或補上支援性控制"]
    D --> E["重新測試"]
    E -->|"信心仍不足"| B
    E -->|"已有信心"| F["描繪失效區域，依可靠度與重大性分流"]

產出是一張失效區域圖：可信區、不確定區與高風險區。對於被評為高風險的系統，AI 只應在團隊有信心的區域內運作。

航空客服機器人案例：狹隘評估如何漏掉政策失效

Tanmay 的例項：一名顧客因家人過世需要出行，向航空公司的客服機器人詢問優惠票價。機器人告訴他先買一般票，並在 90 天內申請折扣。他照做，航空公司卻以政策不允許為由拒絕，最後仲裁判定航空公司須負責。失效鏈很清楚——錯誤建議送達顧客、顧客據以行動、組織承擔後果。

套用建構—破壞—修復：先立下「建議必須符合核准政策」的要求，再用出行後退款等問題挑戰機器人；若浮現錯誤建議，就加上政策檢查或轉接人工，然後重新測試，確認控制能在錯誤送達顧客前攔下它。只看模型的評估只會衡量機器人在留出對話上的流暢度或準確率，根本不會測到真正失效的那條政策邊界。

結語處方：以風險為基礎，而非以頻率為基礎的評估

Vishal 的最後一頁把方法濃縮成一個順序：把系統拆解為技術失效、部署控制與業務情境；以公司專屬量表評估使用案例的重大性；進行系統層級的壓力測試；然後才做部署決策，因為在缺乏這份信心的情況下部署「可能代價太高」。他的總結是：「依風險評估整個 AI 系統，而不只是其中一個元件。」

「AI 失效是有結構的。我們必須把它描繪出來，並依這些子構面採取行動。」——Vishal Srivastava

這套框架最脆弱的接點，正是兩位講者點出卻未解決的地方：代理式評估依賴本身可能出錯的 AI 評審，而他們提出的補救——把評審者當成系統的一部分加以治理——只是多加一層評估，卻沒說明誰來評估評審者。98% 的涵蓋率也是在 AI 事故資料庫上的回溯配適，而非前瞻驗證，因此它對新企業部署的預測力仍未經檢驗。值得持續關注的是：重大性量表是否會以其他公司可採用的形式公佈，以及隨著基礎模型時代的事故基數成長，危害關聯排序是否依然成立。