為什麼手寫 Regex 撐不住 17 萬份文件？談自癒式 AI 提取的實戰演進

大多數企業的文件自動化專案，都是從一段 Regex 開始的。

一開始成效很好。針對某一種固定格式的單據，手寫規則可以做到 95% 以上的提取成功率，成本幾乎是零，速度也快。問題出在第二個月——供應商換了模板，某個欄位前面多了一個空格，成功率就從 95% 直接掉到 23%。

這不是假設，是我們在處理 17 萬份 FDA 510(k) 醫療器材文件時真實遇到的狀況。

脆化，是規則式提取的宿命

手寫規則的根本問題不是「寫得不夠好」，而是它假設世界不會變。真實世界的企業文件有幾個特性，讓這個假設必然失效：

• 格式漂移：同一家供應商在不同年份、不同系統匯出的檔案，欄位順序與空白處理都不一樣
• 長尾變異：80% 的文件長得很像，剩下 20% 每一份都有自己的脾氣
• 維護成本累積：每修一個新格式就多一條 if，半年後沒有人敢動那份程式碼

所以問題不該是「怎麼寫出更強的規則」，而是「當規則失效時，系統能不能自己修好」。

不要讓 AI 提取資料，讓 AI 寫程式來提取資料

這是我們整套架構的核心判斷。

直接把文件丟給 LLM 讀取、要它回傳結構化欄位，看起來最直覺，但在企業場景有三個致命問題：每份文件都要付一次 token 成本、結果不可重現、而且無法稽核。第三點在醫療與金融場景幾乎是一票否決——你沒辦法跟稽核人員解釋「這個數字是模型讀出來的」。

我們的做法反過來：讓 AI 去寫那段提取程式碼，然後把程式碼固化下來重複使用。

一旦程式碼寫出來並通過驗證，後續一萬份同格式文件的處理成本就回到接近零，而且結果完全可重現、可稽核——因為跑的是確定性的 Python，不是機率性的模型輸出。

三層分層防線

實際架構上，我們用成本由低到高的順序排出三道防線：

層級	處理比例	成本	說明
Tier 1 規則引擎	55%	$0	已知格式直接命中，10 秒超時就放行給下一層
Tier 2 地端 LLM	20%	$0	Llama 3 處理隱私敏感案件，資料不出機房
Tier 3 雲端 LLM	20%	低	交給雲端模型處理複雜推理
Self-Heal Agent	5%	較高	最棘手的變異格式，交給自癒迴圈

重點在於：最貴的那條路只服務 5% 的案件。很多企業導入 AI 失敗，是因為把 100% 的流量都送進最貴的那條路，結果 POC 很漂亮、上線後帳單無法接受。

自癒迴圈實際上在做什麼

那最後 5% 進到 LangGraph 自癒 Agent 之後，流程是這樣：

1. Coder Agent 讀取這份未知結構的文件，撰寫一段候選的 Python 提取程式
2. 沙盒執行：程式在隔離環境中跑，捕捉例外與 traceback
3. 自癒迭代：把錯誤訊息回傳給 Coder Agent，讓它根據真實報錯修正程式碼，重複直到通過
4. 回歸測試：新程式要先通過 100 份 Gold Cases，確認沒有弄壞既有格式
5. 金絲雀發布：通過後才固化成線上通用腳本

第 4 步是最容易被忽略、但最關鍵的一步。沒有回歸測試的自癒機制不叫自癒，叫做每次修好一個問題就弄壞三個舊功能。

實測結果

在 17 萬份 FDA 文件的實戰中：

• 單份處理時間從人工 120 分鐘降到 5 秒——1,440 倍效率提升
• 單份成本從約 $40 降到$0.05
• 準確率達到 99.4%，符合金融醫療級要求
• 內建反幻覺覆核與數字白名單：AI 只能引用真正查詢到的數據，無法自行編造

給正在評估的企業幾個建議

如果你正在評估類似的專案，有幾個判斷點值得先想清楚：

• 先算最壞情況的單位成本。POC 只跑 100 份很便宜，上線跑 10 萬份呢？
• 問清楚結果可不可以稽核。如果稽核人員問「這個數字哪來的」，你答得出來嗎？
• 要求看回歸測試機制。任何宣稱會自我修復的系統，都必須同時證明它不會愈修愈糟。
• 不要一次做完。先挑一個高頻、規則明確、痛感強的場景做 30 天 MVP，證明 ROI 之後再擴。

導入 AI 的瓶頸，往往不是模型不夠聰明，而是舊系統改不動、業務單位不會用。真正有效的做法，是用最輕量的外掛架構，讓 AI 產生實際的商業 ROI——而不是先花半年重構整套系統。