
當 AI 系統在沒有您的情況下運行:沒有人談論的生產失敗模式
最危險的 AI 失敗不是戲劇性的。它們是安靜的錯誤,隨著時間的推移複合,因為沒有人在看。以下是應該讓 AI 團隊夜不能寐的生產失敗模式。
獲得報道的 AI 失敗故事是戲劇性的那些。聊天機器人說了冒犯性的話。自動駕駛汽車做出了災難性的決定。圖像生成器產生了不應該的東西。這些失敗是真實的,但它們也是監控捕獲的失敗——它們產生信號。它們是可見的。
應該讓企業 AI 團隊更擔心的失敗是那些看不見的。不產生信號的錯誤。那些在每個儀表板顯示綠色時靜默地複合數百萬個決策的錯誤。您在六個月後發現的那些,當監管機構提出您無法 回答的問題,或者當建立在您的 AI 輸出之上的下游系統將相同的系統性錯誤編碼到其基礎中。
大多數企業沒有為這些失敗模式做好準備。他們沒有準備,因為他們對 AI 失敗的心理模型是戲劇性的那個——他們建立的治理系統旨在防止那些。
以下是五種不戲劇性的失敗模式。它們是實際發生的那些。
失敗模式 1:分佈偏移而未被偵測
您的模型是在特定時間段和特定輸入群體的資料上訓練的。世界在變化。您的模型在生產中看到的輸入逐漸與訓練時的輸入偏離。它的準確率下降——不是災難性的,而是穩定地。沒有人注意到。
這就是分佈偏移。它不是一個錯誤。它是所有機器學習系統的屬性。問題是您的組織是否偵測到它。
具體範例:一個醫療編碼 AI 是在 2022-2023 年的臨床文件上訓練的。2024 年,美國醫學協會為遠程醫療服務、數字治療和遠程患者監控引入了 200 個新的 CPT 代碼。AI 從未見過這些代碼。當它遇到這些新服務的文件時,它將它們映射到最近的現有代碼——有時正確,通常不正確。
新代碼類型的錯誤率為 34%。在舊代碼類型上,模型仍然有 91% 的準確率。總體上,準確率看起來 像 88%——比 91% 下降,但在大多數團隊設置警報的容忍度內。計費團隊注意到一些不尋常的付款方拒絕,但假設這是付款方政策的變更。六個月的錯誤編碼後,合規稽核揭示了這個模式。補救成本——重新提交、上訴、潛在的 OIG 調查——是實質性的。
如果有一個人每月審查一批 AI 輸出,他們會在第一個月看到新代碼錯誤。沒有監控系統標記它,因為沒有人在看輸出——只有掩蓋問題的總體準確率統計。
預防措施:輸出分佈監控——不僅追蹤總體準確率,還追蹤跨類別輸出的分佈,並為意外出現或增長的類別設置警報。以及人工審查抽樣:無論是否有指標觸發警報,合格人員定期審查隨機樣本的 AI 輸出。
失敗模式 2:反饋迴路污染
AI 輸出被用來創建未來的訓練資料。AI 正在悄悄地、靜默地將其自身的錯誤編碼到其下一個版本中。
這種失敗模式需要特定的管線條件:AI 生成的內容或分類被收集並用作下一個模型的訓練資料,在 AI 輸出和訓練標籤之間沒有人工驗證步驟。
具體範例:一個合同審查 AI 部署在一家律師事務所。AI 分類為「標準——沒有問題」的合同被路由到一個共享文件夾,知識管理 團隊用它來構建事務所的「好合同」庫。當下一個模型被訓練時,這個庫被包含在訓練集中,作為可接受合同的範例。
原始模型有一個系統性的盲點:它持續忽略 2023 年後在 SaaS 協議中越來越常見的一種與 IP 所有權相關的特定免責條款。帶有這個條款的合同被分類為「標準」。這些合同進入了好範例庫。在那個庫上訓練的下一個模型學到了這個條款是可以接受的。盲點現在是永久的。
沒有人引入新的錯誤。模型將其現有錯誤繁殖到其繼任者中。這在沒有任何可見失敗事件的情況下發生——管線看起來在工作。
預防措施:進入訓練數據集的每一塊 AI 生成的內容在用作訓練標籤之前都需要人工驗證。人工不是審查 AI 在這個個別案例上是否正確——他們是在管理訓練資料管線。Ertas Data Suite 正是為這個角色構建的:坐在 AI 生成的標籤和訓練資料之間的標注工具,讓人工專家在每個標籤被提交到數據集之前進行驗證。
失敗模式 3:置信度校準漂移
模型對實際錯誤的案例報告高置信度。這比在錯誤案例上的低置信度更糟,因為您的 HITL 系統將高置信度的輸出路由到自動批准。
置信度校準是模型報告的置信度與其實際準確率之間的關係。一 個校準良好的模型說它有 90% 的置信度,大約 90% 的時候是正確的。校準不良的模型可能報告 90% 的置信度,而實際上只有 70% 的時候是正確的。
隨著分佈偏移,模型的校準會退化。模型是在其訓練分佈上校準的。隨著生產輸入偏離訓練輸入,模型的準確率下降——但其置信度分數是由相同的機制計算的,這個機制不知道世界已經改變。置信度保持高位。準確率下降。您的 HITL 閾值是根據置信度設置的,將越來越多的錯誤輸出路由到自動批准。
具體範例:一個欺詐偵測模型通過置信度校準 0.94 的驗證——在第 90 百分位的置信度,模型 94% 的時候是準確的。自動批准閾值設置在 0.88 的置信度,預計約 8% 的誤批准率。
六個月後,出現了一種新的欺詐模式(使用在資料洩露中獲得的真實社會保障號碼的合成身份欺詐)。模型從未見過這個模式。它對合成身份案例的準確率為 51%——幾乎與隨機相比好不了多少。但它對這些案例的置信度分數平均為 0.89,因為輸入在表面上類似於其訓練資料中的合法帳戶。
這些案例正在被自動批准。欺詐團隊看到損失增加,但將其歸因於經濟狀況。模型的總體準確率為 86%——比 94% 下降,但在看起來像正常漂移的範圍內。校準失敗是不可見的。
預防措施:生產中的校準監控——不僅是準確率,還有跨置信度十分位數的準確率-置信度關係。再次強調:人工抽樣自動批准的輸出。每週審查 50 個隨機選擇的自動批准案例的審查員會在幾週內看到合成身份模式。
失敗模式 4:邊緣案例聚類
模型對某些輸入類型處理不善。這些輸入類型不是在您的用戶中隨機分佈的——它們以不成比例地影響特定群體的方式聚類。在總體指標中,聚類是不可見的。對於受影響的群體,錯誤率是 100%。
具體範例:縣社會服務機構部署的福利資格 AI 總體準確率為 91%。總體準確率隱藏了什麼:對於在輸入之前被機器翻譯的非英語書寫的申請,模型的準確率為 72%;對於來自地址驗證資料稀少的農村郵政編碼的申請,準確率為 68%。
來自非英語家庭的申請人被拒絕他們有資格享受的福利的比率比說英語的申請人高 2.5 倍。來自農村地區的申請人被拒絕的比率是城市申請人的 2.8 倍。模型從未在這些維度上進行過不同影響的稽核。91% 的總體準確率足以部署。
這是由不可見的錯誤聚類造成的系統性歧視問題。沒有對統計分層樣本的人工審查——不僅是總體,而且跨相關人口統計維度檢查結果——它可能永遠不會被偵測到,直到民權投訴浮出水面。
預防措施:分解的效能監控。不僅總體追蹤準確率,而且跨所有可能與受保護特徵相關的輸入維度:地理區域、語言、提交 渠道、文件品質。為超過定義閾值的準確率差異設置警報。並要求人工審查抽樣是分層的——不僅僅是隨機的,而是旨在揭示少數輸入群體中的錯誤聚類。
失敗模式 5:供應商誘導的行為變更
AI 供應商更新了底層模型。您的生產系統現在行為不同。您的監控沒有捕獲它,因為您的監控在測試輸入,而不是輸出。
這種失敗模式特定於通過 API 使用 AI 的組織,其中模型是第三方提供的服務。「gpt-4-turbo」端點、「claude-3-opus」端點、「gemini-pro」端點——這些都沒有固定到特定的模型版本,除非您明確固定它們。供應商持續更新模型,有時通知,有時不通知。
您的整合是對特定模型行為進行驗證的。該行為已經改變。語調、推理、輸出格式或拒絕某些輸入的傾向上的微妙變化可能對下游系統產生重大影響。
具體範例:一家金融服務公司使用 LLM API 生成不利行動通知的白話解釋——為什麼信用申請被拒絕,用申請人能理解的術語。該模型通過供應商在季度發布中更新的版本化端點訪問。
更新後的模型在金融話題上有更強的安全訓練。它現在在某些情況下拒絕生成具體的拒絕理由,而是產生一個通用的解釋,不符合 FCRA 對不利行 動具體原因的要求。公司的 QA 過程驗證輸出存在且長度正確。它不驗證內容。在法律審查捕獲它之前,14,000 份帶有不合規內容的不利行動通知被發送出去。
預防措施:輸出驗證——不僅僅是存在性檢查,還有針對定義要求的輸出內容的語義驗證。在可用的情況下固定模型版本。對於高風險應用,運行您自己的微調模型而不是供應商 API。當您擁有權重時,您控制模型何時以及是否改變。
OpenAI/DoD 連接
在企業環境中,這五種失敗模式產生錯誤發票、遺漏欺詐、不正確的福利拒絕和監管違規。在國防環境中,相同的失敗模式產生不同的後果。
目標系統中的分佈偏移意味著隨著操作環境的變化,模型開始識別錯誤的目標。置信度校準漂移意味著高置信度的目標推薦在不應該的情況下被採取行動而沒有人工審查。供應商誘導的行為變更意味著軍方驗證的 AI 不是他們正在運行的 AI。
這是 Anthropic 拒絕了 OpenAI 接受的國防合同的部分原因。失敗模式是相同的。後果在類別上是不同的。這些失敗模式只能通過在個別決策層面的人工監督來管理——HITL,而不是 HOTL。
如何偵測和防止這些失敗
所有五種失敗模式的共同線索:它們對總體指標是不可見的,對不包括人工審查代表性輸出樣本的自動化監控也是不可見的。
具體對策:
- 輸出分佈監控:不僅追蹤總體準確率,還追蹤跨類別和維度的輸出分佈。為分佈變化設置統計過程控制警報。
- 人工審查抽樣:合格人員在定義的時間表上審查生產輸出的隨機樣本——至少每週,高風險系統每天。不是為了捕獲個別錯誤,而是為了偵測模式。
- 分解的效能追蹤:跨所有相關子群體測量準確率。在差異成為法律風險之前浮現差異。
- 校準監控:在生產中追蹤準確率-置信度關係。當校準退化到驗證基線以下時發出警報。
- 模型版本固定:確切知道您在運行什麼模型。不要使用在您控制之外更新的 API 端點。
- 明確的重新訓練治理:進入訓練管線的每一塊資料都需要人工驗證。生產輸出和未來訓練資料之間的反饋迴路必須有一個人工門控。
擁有您的模型,擁有您的失敗模式清單
供應商誘導的行為變更失敗模式是您可以通過擁有自己的模型權重完全消除的那個。您本地運行的微調模型有一個您控制的版本。您選擇何時更新。您在任何更新投入生產之前重新驗證。供應商在您不知情的情況下無法更改您的模型。
Ertas Fine-Tuning 正是為此構建的:在您的資料上微調一個模型,將其下載為 GGUF,在本地運行它。您的模型。您的版本。您控制何時以及是否改變。
對於生產資料準備和治理層,Ertas Data Suite 提供了稽核追蹤、人工標注門控和操作員記錄,防止反饋迴路污染,並創建您的訓練資料管線有有意義的人工監督的記錄證據。
請參閱什麼是人在迴路 AI?了解解決這些失敗模式的治理框架,以及如何設計人在迴路工作流了解實施細節。
讓 AI 系統保持安全的失敗是可見的那些。讓您陷入麻煩的是安靜的那些。監視機器——或者建立為您監視它的系統,由知道要尋找什麼的人。
查看早鳥定價 →,用於 Ertas Fine-Tuning——您擁有的模型權重,您控制的版本,在沒有您授權的情況下不會改變的行為。
Ship AI that runs on your users' devices.
Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
Keep reading

The Cost of AI Failure Without Human Oversight: Documented Cases and What They Teach
Abstract arguments for HITL are less persuasive than concrete numbers. Here are documented AI failures, their costs, and the human oversight gaps that allowed them to happen.

What Is Human-in-the-Loop AI? A Practical Guide for Enterprise Teams
Human-in-the-loop AI keeps humans in the decision chain — but the details matter. Here's what HITL actually means in practice and why it's non-negotiable in regulated industries.

Human-in-the-Loop vs. Human-on-the-Loop vs. Human-out-of-the-Loop: What's the Difference
Three terms that sound similar but represent fundamentally different risk profiles. Understanding the distinction matters more than ever as AI moves into high-stakes decisions.