從視覺語言模型到第一線申辦流程，展現 AI 系統整合與落地實力
一、案例摘要：讓 AI 能力進入日常工作
AI 世代，技術的價值，體現在每天的工作現場。
我們與臺北市政府民政局合作，將視覺語言模型（Vision-Language Model，VLM）導入戶政及申辦文件辨識，串接資料擷取、人工覆核與申請表產製。這是我們與民政局雙方合作的首個 VLM 應用案例，也是團隊累積多模態 AI、文件智慧化與實務部署經驗的重要里程碑。
專案以第一線承辦作業為出發點，處理戶口名簿、身分證、銀行與郵政存摺等文件，將影像內容轉換為可供業務系統使用的結構化資料，並應用於重陽禮金、幼兒數位卡證與健保退保等申請表單。
從需求拆解、模型選型、影像前處理、欄位解析，到推論服務部署、效能測試與修正回饋，我們建立一套可持續改善的文件處理流程。客戶可以從本案看到：團隊具備將 AI 模型整合進既有作業、面對真實文件差異，並解決部署問題的完整工程能力。
二、專案執行：從業務需求到可交付系統
2.1 以申辦流程定義開發目標
第一線承辦人員需要閱讀民眾提供的紙本資料，核對姓名、出生日期、身分證字號、戶籍地址及帳戶資訊，再填入不同申請表。這些作業同時涉及多份文件、多個欄位與不同表單格式。
專案將工作拆解為「選擇申請項目 → 掃描或上傳文件 → AI 辨識 → 人工確認與修正 → 表單套印與輸出」，讓辨識結果直接銜接工作產出。人工覆核保留在正式流程中，承辦人員可對照原始文件完成確認。
2.2 逐步推進的開發路徑
| 執行階段 | 核心工作 | 累積成果 |
| 需求分析與概念驗證（PoC） | 拆解戶政欄位、建立影像輸入與辨識介面、比較初期技術路線 | 建立可運作的文件辨識雛形及結構化輸出 |
| 多引擎評估 | 比較傳統 OCR、深度學習 OCR 與 VLM，建立標準答案與評測流程 | 形成依文件類型、速度與資源條件選型的依據 |
| 場景優化 | 處理雙欄版面、家庭成員欄位、存摺版型及日期地址格式 | 累積臺灣文件專用解析規則與版型資產 |
| 流程整合 | 串接掃描、欄位確認、表單預覽與 PDF 套印 | 完成由文件輸入至申請表輸出的操作流程 |
| 部署與驗證 | 調整 CPU／GPU 環境、Windows／Linux 相容性與推論服務參數 | 累積正式部署、比較環境與硬體限制的處理經驗 |
| 產品化延伸 | 建立統一引擎介面、ONNX 推論路徑與打包機制 | 發展可因應不同客戶環境的部署版本 |
2.3 以評測支撐迭代
團隊建立 Ground Truth（標準答案）及欄位評測腳本，將辨識結果與基準資料比對，追蹤不同文件、欄位與版本的表現。針對解析規則或模型參數調整，以回歸測試（Regression Testing）確認改善是否伴隨其他欄位退步。
這套執行方法讓開發取捨具有可追溯依據。例如，曾調整存摺欄位覆寫規則，卻在評測中發現整體退步，因此回復原有策略。工程決策以實測結果為基礎，持續收斂可用的組合。
三、技術背景：從 OCR 延伸至多模態文件理解
3.1 OCR、VLM 與 IDP 的角色
光學字元辨識（Optical Character Recognition，OCR）負責將影像中的文字轉換為數位文字。面對戶口名簿等文件，還需要辨識欄位標籤、閱讀順序與成員區塊，才能將文字正確放入業務欄位。
視覺語言模型（VLM）結合影像與語言處理能力，為文件版面與內容解析提供另一條技術路徑。本案採用 VLM 文件辨識，再結合版面解析、區域補辨識與規則校驗，形成混合式文件處理架構（Hybrid Document Processing Pipeline）。
整體應用可歸納為智慧文件處理（Intelligent Document Processing，IDP）：串接影像輸入、文字辨識、關鍵資訊擷取（Key Information Extraction，KIE）、資料驗證與業務流程。模型輸出經過程式解析與人工確認，成為申請表可使用的資料。
3.2 本案的技術定位
本案的核心成果是模型應用整合、文件領域調校與系統工程。團隊評估並整合既有 OCR 與 VLM 模型，將臺灣文件的版面特性與業務規則納入處理流程；本文件所述 VLM 成果不代表從零訓練自有基礎模型。
在不同開發與評估版本中，技術路線涵蓋 Tesseract、EasyOCR、Surya、，並探索 CRNN 架構與 ONNX 推論。這些路線具有不同成熟度與用途，依各版實作和評測選用，並非全部同時用於正式服務。
3.3 核心技術詞彙與實際用途
| 技術詞彙 | 本案中的用途 |
| Multimodal AI／多模態 AI | 透過影像與語言處理能力進行文件辨識 |
| Document Layout Analysis／文件版面分析 | 處理戶口名簿雙欄、多成員區塊及閱讀順序 |
| ROI／Region of Interest | 擷取帳號、姓名或右欄等重點區域，進行局部辨識 |
| Structured Data Extraction／結構化資料擷取 | 將辨識文字轉換為姓名、日期、地址與帳戶等欄位 |
| Hybrid Pipeline／混合式處理流程 | 整合 VLM、OCR、版型比對與規則解析 |
| Human-in-the-Loop／人員參與覆核 | 由承辦人員確認與修正 AI 帶入的資料 |
| Model Serving／模型推論服務 | 以 vLLM 等後端提供推論能力，再由應用服務整合 |
| ONNX Runtime／跨平台模型推論 | 在產品化支線建立 CPU／GPU 推論路徑 |
| Observability／可觀測性 | 透過請求、耗時、失敗及修正紀錄了解系統運作 |
| On-premises Deployment／地端部署 | 將應用與推論服務配置於指定主機或機關環境 |
四、技術能力：建立完整的文件 AI 處理鏈
4.1 影像前處理與電腦視覺
針對掃描品質、文件傾斜、背景干擾與印章等因素，系統整合 OpenCV 影像前處理，包括文件邊界偵測、透視校正（Perspective Correction）、去斜（Deskew）、灰階化、二值化及區域裁切。
對存摺版型，採用 ORB 特徵點與 RANSAC 幾何估計進行版面對齊，再依銀行模板定位欄位。這類電腦視覺技術協助縮小辨識範圍，讓模型聚焦於帳號、戶名等目標資訊。
4.2 多引擎整合與欄位補強
不同模型在戶口名簿、身分證與存摺上的表現並不一致。本案建立多引擎評估及路由能力，並在特定處理流程中，以全頁辨識取得主要資訊，再透過局部裁切與其他 OCR 路徑補充缺漏欄位。
存摺處理則結合銀行版型、欄位格式與字典比對。補辨識與欄位合併採明確條件，並透過回歸測試檢查效果。這項能力讓系統可以針對場景調整，而非僅依賴單一模型的原始輸出。
4.3 臺灣文件領域解析
本案累積的領域調校（Domain-specific Adaptation）包含：
- 戶口名簿的戶籍資訊、戶長與成員區塊解析。
- 民國日期、分段地址與常見欄位標籤正規化。
- 身分證字號格式與檢查碼（Checksum）校驗。
- 銀行、分行與郵政資訊的字典比對及模糊比對（Fuzzy Matching）。
- 常見中文字形混淆、標籤斷行與欄位串接的後處理。
這些規則協助偵測格式異常與改善常見誤讀；校驗通過仍需配合原始文件覆核，尤其姓名、地址及帳號等重要資訊。
4.4 API 與業務流程整合
後端以 FastAPI 提供辨識、掃描與表單輸出等 API，將模型推論與前端作業流程串接。辨識資料透過欄位對應與格式轉換，帶入既有 PDF 範本，並處理日期拆分、地址分段及逐格套印。
系統亦已實作單一登入（SSO）票證驗證與 Session 管理介接程式，以及管理、統計與紀錄查詢介面。這些能力提供與機關既有環境整合的基礎；SSO 的實際啟用與驗收狀態需依部署環境確認。
4.5 推論部署與效能工程
團隊處理 Windows Server、Linux、WSL2、CUDA 與 vLLM 等環境整合，調整 GPU 記憶體配置、上下文長度（Context Length）、輸入影像解析度與並發序列數。
在產品化支線，進一步建立引擎抽象層（Engine Abstraction Layer）與 ONNX Runtime 推論流程，讓應用介面與底層模型解耦。不同客戶可依硬體資源與文件需求配置方案，並透過各自的測試結果選擇部署組合。
4.6 可觀測性與改善回饋
開發階段已建立請求紀錄、失敗案例分析與欄位修正分析工具，累積辨識品質調校經驗。依專案方確認，實際交付系統不留存可識別民眾身分的個資，僅留存去識別化資料，供分析、統計與報表使用。
這構成資料驅動改善流程（Data-driven Improvement Loop）：以去識別化的分析與統計掌握處理表現，再配合核准測試資料驗證改善效果。統計用途不等同保存可識別民眾的原始文件，也不代表系統會自動重新訓練模型。
五、實務經驗：在真實限制中累積的工程判斷
5.1 複雜版面需要分層處理
戶口名簿包含密集文字、多位成員與左右欄資料。開發過程曾遇到欄位混行、成員資料錯置及右欄資訊缺漏，透過全頁解析、區域裁切與欄位補辨識逐步改善。
這項經驗讓團隊具備將辨識問題拆分為影像品質、版面結構與欄位解析三個層次的能力，能更精確地定位問題來源。
5.2 解析度與速度需要一起驗證
高解析度會增加運算負擔，縮小影像又可能損失細字資訊。專案調整全圖解析度，並保留原始圖供小區域辨識使用，處理整體速度與局部細節之間的取捨。
這類影像尺度管理（Image Scale Management）也涉及裁切座標映射，必須確保縮放後的欄位位置仍能正確對應原始圖。
5.3 硬體相容不等於服務可用
部分舊型 GPU 評估中，即使完成推論框架啟動，仍因記憶體與運算核心相容性等限制，出現推論過慢或請求逾時。團隊因此累積對 CUDA 版本、GPU 架構、數值精度與推論後端相容性的處理經驗。
部署判斷需觀察完整請求能否在可接受時間內完成，並同時評估辨識品質、資源占用與穩定性。
5.4 模型版本與解析程式必須共同管理
多引擎評估發現，推論服務版本變動可能改變模型的輸出格式，讓原有解析流程失效。團隊以固定已驗證版本組合、比對原始輸出及重跑評測的方式釐清問題。
這項經驗形成版本鎖定（Version Pinning）與升版回歸驗證的實務基礎。模型、推論框架與解析程式需要作為一組相依系統管理。
5.5 並發參數需要實測取捨
在 GPU 壓力測試中，增加並發序列數未必帶來更快處理，可能因運算資源競爭而拉長完成時間。團隊透過不同參數組合，觀察平均等待與全部請求完成時間，選擇適合該硬體的配置。
這些經驗支撐容量規劃（Capacity Planning），也為未來多據點與多窗口擴充提供基礎。
六、開發成果與量化驗證
6.1 已完成的應用成果
| 面向 | 成果 |
| 文件處理 | 實作戶口名簿、戶籍謄本、身分證正反面及存摺辨識路徑；各類別驗證充分程度依樣本而異 |
| 表單應用 | 完成重陽禮金、幼兒數位卡證與健保退保 PDF 套印流程 |
| 操作流程 | 整合掃描／上傳、結果確認、人工修正、預覽及輸出 |
| VLM 整合 | 建立 VLM 推論服務與文件解析流程，並有正式部署交接紀錄 |
| 品質管理 | 建立標準答案、欄位評測、失敗案例與修正分析 |
| 產品化延伸 | 建立統一引擎介面、ONNX 推論、版本與打包機制 |
6.2 代表性測試結果
| 驗證項目 | 紀錄結果 | 條件與解讀 |
| 主專案整體欄位評測 | 約 89.9%（196／218） | 2026-06-25 交接基準；為專案欄位評分，非整份文件完全正確率 |
| 主專案戶口名簿評測 | 約 94.4% | 同期版本紀錄；只代表該次樣本與解析管線 |
| 24 筆並發請求測試 | 24／24 完成；全部完成 54.8 秒，平均等待 22.8 秒 | 2026-06-09，RTX 4060 Ti 16GB 比較環境；請求成功不等於辨識內容全對 |
| 產品化支線 CPU 評測 | 欄位評分 86.70%；每張耗時 1.6 秒 | 2026-07-06，i7-11700F、28 張樣本、218 個欄位分 |
| 產品化支線 GPU 評測 | 欄位評分 86.70%；每張耗時 0.71 秒 | 同次評測，RTX 3050 8GB；屬UOCR 路線成果，非 VLM 推論速度 |
不同測試使用的樣本、版本、引擎與硬體不完全相同，不能直接視為同條件性能比較。2026-07-06 評測採欄位子字串匹配與關鍵欄位加權；以上成績不等同逐字精確匹配率，也不構成所有客戶環境的服務保證。
目前資料可支持文件處理、流程整合與技術測試成果；尚無足夠紀錄量化全市使用規模、整體申辦時間縮短比例、人力節省或長期服務可用率。
七、對客戶的價值：把技術成果轉化為工作能力
7.1 讓資料從文件走入業務系統
系統將辨識結果帶入表單，減少承辦人員逐欄重新鍵入的需求。客戶可沿用既有表單與確認程序，逐步導入 AI 輔助作業。
7.2 以場景與設備條件選擇技術
從 GPU VLM 到 CPU OCR，團隊具備比較不同技術組合的能力，可依文件複雜度、處理量、設備與維運條件進行評估，形成具體的部署選項。
7.3 讓品質問題可以被追蹤與改善
評測基準與去識別化統計協助辨識系統性問題，讓改善工作能聚焦於特定欄位、文件版型或處理步驟，並以回歸驗證確認效果。
7.4 累積可延伸的技術資產
文件解析規則、版型設定、API 介面與部署經驗，可作為新增文件與服務的基礎。延伸應用仍需要新場景樣本與驗證，但能沿用既有工程架構，降低重新建置的需求。
八、資安與個資保護：以去識別化兼顧個資保護與營運分析
本案系統不留存可識別民眾身分的個資，僅留存去識別化資料，供分析、統計與報表使用。 文件辨識與申請表產製以當次承辦作業為目的，將 AI 能力帶入業務流程，同時以個資保護與去識別化分析作為本案的重要資安特色。
上述個資與資料用途原則依專案方確認；具體去識別化方法、暫存方式與清除時點，以交付版本與驗收結果為準。
8.1 資料最小化與隱私設計
本案的個資保護原則可由隱私設計（Privacy by Design）與資料最小化（Data Minimization）說明：AI 處理聚焦於當次辨識、欄位確認與表單輸出，系統不留存可識別民眾身分的個資，僅保存供分析統計報表使用的去識別化資料。
辨識結果由承辦人員確認後用於申辦作業。輸出的申請表交由承辦流程管理；下載或列印後的文件保管屬於機關既有文件管理範圍，與辨識系統本身是否留存個資分別界定。
這項設計讓客戶能清楚掌握 AI 的用途及資料處理邊界（Data Boundary），也使後續擴充必須延續相同個資原則。
8.2 地端推論與資料流向
專案具備地端部署（On-premises Deployment）及指定主機推論能力，可將 OCR 與 VLM 辨識安排於機關管理的環境。承辦端提交文件後，由指定應用與模型服務處理，再回傳欄位結果供覆核及表單產製。
地端部署與不留存個資是互補的兩個面向：前者界定資料在哪裡處理，後者界定系統是否保存民眾個資。正式落地時，應以資料流向圖確認應用主機、模型端點、SSO 服務及輸出位置，避免僅以主機位於內網推定整體資料流向。
如需離線辨識，可預先備妥模型與依賴套件，將推論端點限定於核准環境，並透過斷網及網路流量測試確認；SSO 與套件更新的連線需求則另行規劃。此為可規劃的落地方式，不表示所有部署版本均已完成完全離線驗證。
8.3 身分驗證與角色權限
現有程式已實作 SSO 票證驗證、具有有效期限的 Session、HttpOnly Cookie，以及部分管理端點的管理員角色檢查與權限異動紀錄，提供身分與存取管理（Identity and Access Management，IAM）的整合基礎。
正式導入需將角色型存取控制（Role-Based Access Control，RBAC）落實於後端操作與資料存取，定義承辦人、管理員及維運人員的操作範圍，並驗證未登入、停權與跨角色請求的限制。機關入口網的登入資格與本應用的使用授權應分別確認。
8.4 安全傳輸與服務隔離
部署指南已有 IIS 反向代理路徑，可將 HTTPS／TLS、入口存取限制與服務轉送整合於機關環境。正式部署需限制應用與模型後端的可達範圍，避免使用者繞過受保護入口，並確認 Cookie 安全設定、服務帳號權限與金鑰配置。
網路分區（Network Segmentation）、最小權限（Least Privilege）及機密管理（Secrets Management）可作為導入設計的控制項目。SSO 金鑰、憑證與維運權限獨立管理，避免將敏感設定混入一般交付檔案。
8.5 去識別化分析、統計與報表
系統僅留存去識別化資料供分析、統計與報表使用，讓管理者掌握服務運作及辨識表現，同時避免留存可識別民眾身分的個資。這也是可觀測性（Observability）與資料治理（Data Governance）在本案的結合。
依需求可規劃的報表指標包含處理量、文件類型分布、辨識耗時、成功與失敗比例、欄位修正次數及資源使用量。這些是適合的分析方向，實際欄位與報表內容以交付範圍為準。
去識別化（De-identification）需要考量直接識別欄位及資料組合後的再識別風險。技術上可依需求採用欄位移除、資料泛化（Generalization）、彙總統計（Aggregation）與小樣本群組抑制等方式；上述為可採用的方法，不宣稱本案已實作每一種。單純遮罩姓名或將識別碼雜湊，不宜直接描述為不可再識別的匿名資料。
報表與匯出仍需權限管理及用途限制，並定義去識別化資料的保存期限。正式驗收應確認原圖、原始辨識文字、修正前後值及模型服務紀錄，不會在例外處理、Debug 或備份流程中形成非預期個資留存。
8.6 AI 輸出與人工覆核
文件內容與模型輸出應視為待驗證資料。既有流程透過欄位解析、格式校驗與 Human-in-the-Loop 人工覆核，將資料帶入申請表。姓名、帳戶等關鍵資訊仍由承辦人員對照文件確認。
未來若串接代理式流程，需另行設計輸出 Schema 驗證、允許操作清單及人工確認點，確保文件中的文字不會直接成為系統指令。這項信任邊界（Trust Boundary）設計，能讓 AI 能力的擴充與權限控制共同推進。
8.7 資安能力與驗證範圍
| 面向 | 本案基礎 | 導入驗證重點 |
| 個資保護 | 專案方確認不留存可識別民眾的個資，僅留存去識別化統計資料 | 交付版本的暫存、例外處理、紀錄與備份行為 |
| 資料位置 | 地端及指定主機推論路徑 | 實際模型端點、資料流向與連外依賴 |
| 身分權限 | SSO、Session、部分管理角色檢查 | 全端點授權、停權與跨角色測試 |
| 傳輸與隔離 | 反向代理部署路徑 | TLS、Cookie、入口保護與後端埠隔離 |
| 系統維運 | 評測、請求統計與版本經驗 | 統計不含民眾個資、更新回復與故障處理 |
| 軟體供應鏈 | 套件清單、版本與打包紀錄 | 弱點掃描、模型來源、依賴與授權確認 |
上述為專案原則、實作基礎與導入設計的整理，不宣稱已取得特定資安認證或完成全面滲透測試。
九、落地方案：依場景與設備選擇部署架構
三種方案均以不留存可識別民眾身分的個資、僅留存去識別化分析統計資料為交付原則，差異在運算位置、模型路線與維運分工。
9.1 方案 A：機關內網集中式 VLM 服務
適用情境：多個窗口共用辨識能力，機關具備可集中管理的 GPU 主機。
承辦端透過瀏覽器與掃描設備提交文件，由內網應用服務處理請求，呼叫 GPU 主機上的 VLM，再將結構化欄位回傳至承辦畫面，確認後輸出表單。
資料流向：承辦端 → 受保護的應用入口 → 內網應用服務 → 內網 GPU 推論服務 → 欄位解析 → 人工覆核 → 表單輸出。
此方案可集中管理模型與版本，承辦端不需各自安裝大型模型。需要規劃尖峰併發、網路傳輸、排隊時間與服務中斷時的作業方式。既有 VLM 部署與 24 筆並發測試可作為評估起點；多據點負載平衡及高可用能力仍需另外建置。
9.2 方案 B：單點地端 GPU 部署
適用情境：單一據點希望由指定設備完成主要辨識作業。
將應用與模型服務配置於同一台或同據點專用主機，可沿用 Windows 搭配 WSL2 推論服務，或依環境採 Linux 部署路徑，縮小文件傳輸範圍。
此方案需要逐點管理 GPU、驅動、模型與更新。硬體選型應驗證 GPU 架構、顯示記憶體與推論後端的相容性；既有低容量 GPU 評估曾出現逾時，因此採購配置應由代表性文件的端到端測試確認。
9.3 方案 C：CPU 輕量化文件辨識
適用情境：既有設備無 GPU、工作量有限，或希望先導入固定文件與表單。
採用產品化支線的 ONNX Runtime OCR 路徑，沿用欄位解析、人工覆核與表單產製流程。此為延伸自專案的輕量化方案，底層引擎與 VLM 方案不同。
既有 CPU 評測提供可行性依據，實際導入仍需確認客戶設備的耗時、記憶體與辨識品質。未來若增加複雜文件，可再評估銜接集中式 GPU 服務。
9.4 部署方案比較
| 面向 | 集中式 VLM | 單點地端 GPU | CPU 輕量化 |
| 運算位置 | 機關內網共用 GPU 主機 | 據點專用 GPU 主機 | 指定 CPU 主機或工作站 |
| 維運重點 | 集中版本、網路、容量與故障處理 | 每點設備、驅動與更新 | CPU 資源、文件適配與版本 |
| 擴充方式 | 增加推論節點與流量調度，需另行建置 | 增設或更新據點設備 | 增加節點或銜接 GPU 服務 |
| 既有依據 | VLM 部署與並發測試 | Windows／WSL2 與 GPU 評估經驗 | ONNX 產品化與 CPU 評測 |
| 個資原則 | 僅留存去識別化分析統計資料 | 僅留存去識別化分析統計資料 | 僅留存去識別化分析統計資料 |
9.5 從試點到交付的執行步驟
| 階段 | 執行工作 | 交付結果 |
| 需求盤點 | 確認文件、欄位、表單、角色與工作量 | 需求清單、資料流向圖、權限矩陣 |
| PoC 與選型 | 以具代表性的核准樣本比較引擎與硬體 | 欄位評測、效能報告與部署選項 |
| 系統整合 | 串接掃描、SSO、表單與指定網路 | 可操作測試系統、部署與操作文件 |
| 小規模試行 | 由承辦人員驗證作業流程與例外情境 | 使用者驗收（UAT）與問題修正紀錄 |
| 上線準備 | 驗證不留存個資、權限、負載與更新回復 | 驗收結果、維運手冊、版本與回復套件 |
| 持續改善 | 以核准測試資料與不含個資的統計評估更新 | 回歸評測、版型改善與更新紀錄 |
9.6 以完整工作流程驗收
品質可觀察關鍵欄位精確匹配率、人工修正率與表單產製成功率；效能可觀察冷啟動、暖機後耗時、P95 回應時間及尖峰併發。門檻由業務需求與 PoC 結果確定，既有樣本成績用作參考。
資安驗收包括未授權存取及不留存個資的情境測試。維運則驗證服務重啟、設定與模型版本回復，備份內容需排除民眾個資。服務不可用時，承辦人員可循既有人工程序處理。
如需多節點部署，另行設計 Session 共用、流量分派與狀態一致性；現有記憶體型 Session 不直接代表已具備多節點同步。高可用（High Availability）、災難復原及 RTO／RPO 目標需依機關需求規劃，並透過演練驗證。
十、展望及未來：從單一場景走向文件智慧化平台
以下為基於既有成果提出的發展方向，尚不代表已完成或已承諾交付的功能。
10.1 近期：擴充資料覆蓋與品質評測
持續增加文件版型、掃描品質與難辨識字形的測試覆蓋，並建立更細緻的欄位品質指標。導入信心度校準（Confidence Calibration）與品質門檻設計，可望讓需人工覆核的項目更容易被辨識。
同時區分逐字精確匹配、欄位正確率與整份文件正確率，讓客戶能依實際業務要求評估品質。
10.2 中期：跨文件核對與業務系統串接
延伸跨文件一致性檢查（Cross-document Validation），比較申請表、身分證與存摺中的姓名或識別資訊，提示需要人工確認的差異。
透過 API 串接與流程編排（Workflow Orchestration），可進一步將確認後的資料帶入收件或案件管理系統。是否寫回資料、需要哪些覆核與授權，應由各業務流程定義。
10.3 中期：發展可配置的文件處理平台
將文件類型、欄位 Schema、校驗規則與表單模板逐步配置化，搭配引擎抽象層，形成可擴充的文件處理平台。
若擴展至多據點，可規劃集中模型服務、工作佇列（Job Queue）、負載平衡（Load Balancing）與監控機制，並以實際尖峰量測進行容量規劃。
10.4 長期：模型生命週期與知識輔助
將核准測試資料版本、模型版本、評測結果與部署組態納入 MLOps（機器學習維運）管理，建立更完整的版本追蹤與更新驗證機制。
在需要查閱申辦規範的場景，可另行評估檢索增強生成（Retrieval-Augmented Generation，RAG），協助承辦人員取得有來源的作業說明。此方向需新增知識庫、權限與答案品質驗證，與既有文件辨識功能分別設計。
如評估 Agentic Workflow（代理式工作流程），宜先由文件分類、缺件提示等可覆核任務起步，明確定義人工確認點，再逐步評估更進一步的流程自動化。
十一、對外主文摘要
AI 走進政務第一線：以 VLM 串接文件辨識與申辦服務
我們與臺北市政府民政局合作，完成雙方首個運用視覺語言模型（VLM）的文件智慧化案例。以戶口名簿、身分證與存摺為起點，整合多模態 AI、OCR、文件版面分析與結構化資料擷取，串接人工覆核及申請表自動套印，應用於重陽禮金、幼兒數位卡證與健保退保等場景。
從模型選型、影像前處理、領域規則調校，到 GPU 推論服務、地端部署與並發測試，團隊在真實文件與現場限制中累積完整的 AI 工程經驗。透過可追蹤的評測與修正回饋，持續改善辨識品質，將模型能力轉化為承辦人員日常可用的工具。
本案系統不留存可識別民眾身分的個資，僅留存去識別化資料，供分析、統計與報表使用；並具備地端與指定主機推論能力，讓 AI 應用兼顧業務整合、資料邊界與維運需求。
這次合作建立了延伸至更多政府與企業文件流程的技術基礎，也展現我們以業務需求驅動、以工程實作交付 AI 應用的能力。
讓 AI 的每一次辨識，都往完成一件工作更近一步。
附錄：內部來源與引用邊界
本附錄供文案查核使用，對外版本可移除。本文依本地文件與程式整理，未重新執行模型評測或查驗遠端服務現況。
| 來源 | 支持內容 |
| tpeocrcsa/docs/HANDOVER.md | 系統用途、正式部署交接、辨識流程與 89.9% 基準 |
| tpeocrcsa/CLAUDE.md | 同期分文件成績、引擎路由與部署調校 |
| tpeocrcsa/PROGRESS.md | 多引擎比較、並發測試、影像優化、失敗管理與修正分析 |
| tpeocrcsa/HANDOFF.md | 櫃檯三步驟流程、表單套印與地址處理 |
| tpeocrcsa/docs/bankbook_pipeline.md | ORB／RANSAC、版型 ROI、字典比對與欄位合併 |
| tpeocrcsa/docs/client_ocr_eval_20260619.md | 舊型 GPU 評估與推論限制 |
| tpeocrcsa/app/services/validator.py | 格式、日期及身分證檢查碼校驗 |
| tpeocrcsa/app/services/sso_service.py | SSO 票證驗證與 Session 介接實作 |
| tpeocrcsa/app/services/privacy.py、app/main.py | 遮罩工具、統計、紀錄與清理介面 |
| tpeocr-product/PLAN.md | 引擎抽象化、ONNX Runtime 與產品打包 |
| tpeocr-product/docs/118_eval_20260706.md | 28 張樣本的多引擎比較、速度、評分方式與版本敏感性 |
| tpeocr/OCR_FLOW.md、tpeocrcodex/household_ocr_poc/README.md、tpeocrv2/codex/tw-doc-ocr-poc/README.md | 初期 PoC、CRNN 探索與文件解析演進背景 |
「首個 VLM 案例」依專案方說明，限定為我們與臺北市政府民政局雙方合作的首例；不延伸為臺北市政府或全臺首例。產品化支線成果與 VLM 主專案各自標示；本文件不宣稱所有技術均已於機關正式啟用，也不宣稱第三方模型為自有基礎模型。
交付環境與開發版差異（內部查核）
專案方已確認實際方案「不留存可識別民眾身分的個資，僅留存去識別化資料供分析統計報表使用」，本文依此更新。此原則來自專案方說明，本次未連線查驗正式服務，也未測試去識別化或清除程序。
本地開發版 app/main.py 的失敗案例流程會複製原圖並寫入結果，修正紀錄會寫入 OCR 與最終欄位值；privacy.py 有遮罩工具，但不能僅憑工具存在就推定所有紀錄均已去識別化。交付版本需與本地開發版差異核對，確認正式環境已停用、改寫或隔離相關留存流程。
本地程式另有上傳與前處理圖片靜態路徑、部分端點權限範圍、首次 SSO 登入自動授權，以及 Cookie 未明確設定 Secure 等需與實際入口控制核對的項目。這些為文件查核觀察，不代表本次完成資安稽核或已修正程式。對外版本可移除此內部附錄。