看到這個文件處理案例，我最在意的不是一年省下 3,600 工時，而是它把「模型偶爾會自信地錯」當成系統設計前提。區域預拌混凝土公司每天最多要處理 1,500 張非結構化 PDF 供應商票據，版型超過 30 種。團隊先拿 300 多張真實票據，評測 8 個以上的 LLM 與文件工具，才決定如何組合流程。這個順序很重要，因為 demo 上看似能讀懂一張發票，不代表面對長尾版型、欄位缺漏或不同供應商命名時仍然可靠。

案例最後採用 multimodal、multi-model consensus。直覺上，讓多個模型互相核對，似乎就能消除幻覺，但我認為不能把 consensus 當成魔法。若所有模型都讀到同一個模糊欄位，或共享同一個錯誤的 mapping，它們可能只是一起同意錯誤答案。因此真正值得複製的不是「多叫幾個模型投票」，而是把共識放進可驗證的系統契約裡。

第一個契約是可追溯性。每個抽取欄位都應保留來源 PDF、頁碼或區域、原始文字、使用的模型與版本、信心資訊，以及後續修正紀錄。application journal 不是除錯時才翻的 log，而是日常營運的一部分。沒有這些證據，80% 直通率只是一個漂亮的結果數字，無法知道剩下 20% 是哪些版型、哪些欄位、哪些錯誤類型。

第二個契約是實體對應。供應商名稱、品項、稅務欄位與內部會計主檔之間，不能只靠模型自行猜測。案例提到可由使用者維護的對照表，這其實是在把 domain knowledge 從 prompt 移到可管理的資料層。當財務人員新增或修正一筆 mapping，系統應能留下誰在何時做了什麼變更，並讓後續文件使用同一套規則。這比不斷調 prompt 更容易審核，也更適合長期維護。

第三個契約是人機例外處理。低信心、欄位互相矛盾、找不到對照實體，或規則驗證失敗的文件，應該進入明確的 review queue，而不是硬塞進下游 ERP。人工處理結果要回寫成可重用的規則或對照資料，並能區分「模型抽錯」與「原始文件本身不完整」。這裡的 human in the loop 不是退回人工，而是把人工判斷集中在真正需要判斷的例外。

上線 30 日處理 24,058 張票據，80% 直通，成本約每張 0.0585 美元，說明這套方法已經跨過概念驗證。但若要在別的企業複製，我會先建立一組代表長尾情況的測試集，再定義欄位準確率、直通率、例外處理時間、人工修正率與可追溯性完整度。事件驅動管線負責穩定運送資料，multi-model 負責降低單點失誤，application journal、mapping 與 review queue 則負責讓結果能被理解、修正和追責。真正可上線的文件 AI，不是模型說得比較像人，而是每個不確定性都有去處。