邊角案例(Edge Case)出貨教學:企業 AI 上線前最容易漏掉的例外處理

上個月我們接手一套已經「上線」四個月的合約審閱 Copilot。功能清單很漂亮:條款抽取、風險標註、逐條摘要,Demo 那天連法務長都拍手。我到現場翻使用紀錄,月活躍是 11 個人裡的 3 個。問題不在模型。問題在那 3 個人只敢丟制式的採購合約進去,一碰到中英混排的併購協議、掃描件、或是加了手寫批註的舊版本,系統就沉默、亂答、或直接把附件當成正文。使用者被雷過兩次之後,就默默回去用 Word 了。

這就是我想講的核心:AI 邊角案例處理,才是 Demo 到生產線之間真正的工作量。 我們內部的粗估是,一個能跑通 happy path 的原型,只完成了整個上線工程的 20%。剩下的 80%,幾乎全花在你 Demo 時故意繞開的那些例外上。

為什麼邊角案例決定採用率,而不是準確率

Demo 的邏輯是「展示它會什麼」。生產線的邏輯是「證明它不會在關鍵時刻出錯」。這兩件事的樣本分布完全不同。

Demo 用的是你精挑細選、格式乾淨、語意清楚的黃金案例。真實流水裡塞滿了什麼?半頁是表格的 PDF、OCR 辨識錯的數字、同一個欄位三種寫法、使用者把問題打成一句沒有主詞的口語、還有那種「這份合約到底適不適用」本身就模稜兩可的輸入。

關鍵在於信任是不對稱的。一個使用者被錯誤答案坑一次,他要用十次正確答案才願意回頭。所以決定採用率的不是平均準確率有多高,而是最差的那 5% 輸入會發生什麼事。你的 Demo 準確率 95% 聽起來很好,但如果那 5% 的失敗是無聲的、給出一個看起來很有信心的錯誤答案,採用率就會崩。

第一步:把邊角案例盤點出來,而不是等它爆

多數團隊處理例外的方式是「等使用者回報」。這是最貴的方式,因為每一個回報背後都是一次信任損耗。

我們進場第一週會做的,是主動撈一批真實資料來壓測。具體做法:從客戶過去半年的實際輸入裡,隨機抽 200 到 300 筆——不是抽乾淨的,是連髒的一起抽——一筆一筆跑過系統,把每個「輸出不對、不完整、或系統直接掛掉」的情況記下來。這一步通常兩到三天就能撈出 40 到 60 種不同的失敗形態。

盤點時我們會逼自己回答三個問題:這個輸入長什麼樣、系統實際吐了什麼、正確的行為應該是什麼。第三個問題最常被跳過,但它最重要——因為很多邊角案例的「正確行為」不是答對,而是體面地承認自己不確定。一個會說「這份文件我讀不完整,建議人工確認第 3 頁」的系統,遠比一個硬答的系統可信。

第二步:分級,決定哪些現在修、哪些先擋掉

盤點完你會有一張又長又嚇人的清單。這時候最忌諱的是想「全部修完再上線」,那你永遠上不了線。要分級。我們用兩個軸:發生頻率、以及答錯的後果。

這張表的價值不在分類本身,而在它讓你和客戶一起明確地決定不做什麼。P3 那一格是關鍵——承認「這個我們不修,並且我們知道我們不修」,比假裝系統無所不能誠實得多,也讓上線範圍變得可交付。

護欄級是最被低估的一格。你不需要讓系統答對每一種難題,你只需要讓它認得出自己不該答的題,然後乾淨地退回人工。這一格的投報率通常最高:一個好的「拒答與轉人工」機制,往往比多訓練三個月更能救活採用率。

第三步:逐一出貨,把例外處理變成節奏

分完級,剩下的是紀律。我們把 P1、P2 拆成一張看得見的待辦,每一條都寫成可驗證的形式:「輸入 X 時,系統應該做 Y」。然後每週固定出貨一批,修好一條就從壓測集裡挑對應的樣本回歸驗證,確認沒修好這個又弄壞那個。

這裡有個我們踩過的雷:不要口頭說「修好了」。每一個邊角案例都要有一筆對應的測試樣本進到回歸集裡,永久留著。因為 AI 系統改一個 prompt、換一版模型,舊的例外很容易復活。沒有回歸集,你就是在同一個坑裡反覆跌倒。

那套 11 人只有 3 人用的合約 Copilot,我們沒有重做模型。我們花三週把掃描件偵測、中英混排、和適用性拒答這三個 P0/P1 補上,再把十幾個 P2 排進每週迭代。第六週月活躍到了 9 人。變好的不是準確率,是使用者知道系統在什麼時候會老實舉手。

—

在 Tenten,我們做前線部署工程時的判準很簡單:Demo 很美不算數,要能撐住真實流水裡最髒的那 5% 輸入、而且有人天天在用,才算上線。所以我們進場的第一件事,通常不是加功能,而是把那 80% 沒人想碰的邊角案例,一筆一筆盤出來、分好級、排進出貨節奏。