用 AI 辨識不動產登記文件:模型負責讀,規則負責對

這是一個替地政承辦人員做的內部系統:上傳一整疊不動產贈與登記案件的掃描件,系統逐頁判斷這是申請書、契約書、身分證明還是稅單,把每份文件抽成結構化資料,再跨文件核對——契稅有沒有算對、當事人姓名前後是否一致——最後交給人複核到可送件。

九天做出可試點的版本,十一種文件範本、十三條勾稽規則。以下是過程中最值得記下的幾個決策。

決策一:資料不出網,所以模型要選「繁中最強」而不是「規模最大」

需求書上寫得很硬:嚴禁雲端、資料不得離開內網。所以視覺語言模型必須跑在地端。我們的選型依據不是參數量,而是繁體中文文件的實測榜單——結論是:模型規模不等於繁中能力,關鍵在訓練語料裡繁中佔了多少。最後選了在繁中榜上最強的開源視覺模型,用 vLLM 部署。

同時保留三種供應商的抽象層,雲端 API 只在開發階段使用,並用一個環境變數在政策層直接擋掉雲端呼叫——工程紀律要靠設定強制,不能靠人記得。

決策二:結構化輸出一律走 tool calling

不要請模型「輸出一段 JSON」然後自己解析——它會加一句客套話、會少一個逗號、會把欄位名改掉。我們讓所有抽取都透過 tool calling 走 schema,模型只能填格子;不支援 tool 的端點才退回 JSON 模式備援。

Prompt 設計上,每種文件範本都帶兩段提示:「版面特徵」幫助分類,「抽取規則」約束行為——民國年原樣保留、被遮罩的欄位填 null 不准猜、手寫存疑的寫進備註、跨頁資料要整合成一份。分類用縮圖(省成本),抽取用原圖(保精度),併發上限八路。

決策三:正確性不交給 VLM

這是整個系統最重要的設計。跨文件勾稽引擎是純函式、零模型:十三條規則全部是確定性的一致性檢查與算術驗證,例如「契稅 = 核定價 × 稅率」。這意味著它可以離線驗證、可以寫測試、可以抓到「憑證金額少讀了一位數」這種模型最容易犯、也最難自己發現的錯。

模型負責讀,規則負責對。這個分工讓「AI 準不準」從一個令人不安的黑盒問題,變成一個可以被規則兜住的工程問題。

決策四:座標不信模型估的

複核介面需要在掃描件上框出每個欄位的位置。模型估的框不可靠,所以我們加了一個純 CPU 的 OCR sidecar:在 OCR 的字元 token 上定位欄位值,取得像素級座標;失敗就自動降級,不阻斷流程。純 CPU 是刻意的——內網環境不一定有 GPU 可以分給這件事。

決策五:交叉驗證只加分、不扣分

一開始我們讓 OCR 結果與模型抽取值做字面比對,不一致就標紅送複核。結果複核佇列被灌爆——因為模型正確地把日期正規化了,OCR 保留了原樣,兩者字面不同但都對。修正後的規則是:OCR 一致時提高信心度,不一致時不扣分。這條邊界寫進了回歸測試,以免日後有人「優化」回去。

信心度也分成兩種制度:有跨文件勾稽可依據時,一致性是主訊號;只有單一來源時,模型自評的信心度權重很低——因為它的自評校準得很差。

誠實的現況

這是一個成熟的概念驗證與內部試點,不是上線品:沒有正式的準確率報告、管線不支援多實例、部分端點的認證還是既有缺口。我們寫下來的是方法,而方法已經被驗證。

對想做產品的領域專家來說,這篇的意義在於:那十三條勾稽規則,是懂地政的人告訴我們的。工程團隊做的,是把專家腦中的規則變成確定性的程式——這正是「領域 know-how × 工程」該有的分工。

---

想聊聊你的產品想法,歡迎來信。