回單 OCR 落地的架構抉擇：三代演進與人機分流心法

印刷產業的生產流程高度仰賴紙本單據流轉。從業務開立的作業單、工廠端的回單（簽收單、出貨單、現場回傳的工序確認單），到物流交付的簽收憑證，這些文件承載了訂單規格、數量、交期與責任歸屬等關鍵資訊。當印刷廠試圖將排程、產能與帳務數位化時，回單辨識往往是第一道、也是最容易失敗的關卡。其困難不在於「把字讀出來」，而在於這類單據的版面位置不固定、廠商格式各異、手寫備註與塗改頻繁，且現場拍攝的掃描品質參差不齊 [1]。

近年生成式 AI 與多模態模型的成熟，使得「OCR 問題早已解決」成為一種流行論調。然而，將 Vision Language Model（VLM）直接套用於真實生產環境，與在乾淨資料集上取得高分，是兩個截然不同的命題。一份針對日本行動裝置拍攝收據所建構的資料集研究指出，即便針對結構化票據資料抽取進行了專門的微調，模型表現仍高度依賴資料集的代表性與版面多樣性 [2]。換言之，benchmark 上的數字無法直接外推到任意一家工廠的單據樣態。

本文的研究問題有：

・三：

・其一，回單辨識技術歷經哪幾代演進，各代的適用邊界為何

・其二，為何「最新的模型」未必是「最該採用的方案」，技術選擇背後的決定因素是什麼

・其三，對資源有限的台灣中小印刷廠而言，落地一套可運作的回單辨識系統，應遵循什麼樣的架構原則與分流邏輯。本文以一份台灣工程師的回單 OCR 上線實錄為第一手個案 [1]，結合票據 OCR 與 AI 導入治理的文獻，進行批判性綜合

本文的貢獻在於：不把回單辨識視為單純的模型選型問題，而是將其重構為一個「辨識層、結構化層、審核層」三層協同的系統工程問題，並提出可操作的分流原則。對正在評估數位化作業單流程的印刷廠，本文補上了一個罕見的本土落地視角。

既有關於文件辨識的討論，可依其核心關懷分為三個群集，彼此之間存在明顯的立場張力。

第一個群集是模型能力中心論。這條路線關注的是如何讓單一模型在票據抽取任務上取得更高分數。前述日本行動收據研究即屬此類，它建構了一個約 1.3K 規模的標註資料集，並微調 VLM 以輸出結構化的收據欄位，論證了「資料集品質加上針對性微調」能顯著提升結構化抽取的準確度 [2][4]。這類研究的價值在於提供了可複現的方法論與量化基準，但其隱含前提是「資料分布相對一致」。一旦面對印刷廠那種一家廠商一種格式、且持續新增格式的長尾分布，單一微調模型的維護成本與泛化能力都會受到挑戰。

第二個群集是工具與工程實務論。隨著 AI coding agent 的普及，開發者得以用更低的成本串接 OCR、LLM 與後端邏輯。相關實務文獻記錄了 AI coding agent 在真實開發場景中的協作模式與限制，指出其能加速樣板程式碼的生成與工具串接，但在牽涉領域知識的判斷上仍需人類介入 [5]。亦有將 AI coding agent 整合進特定分析環境（如 RStudio）的套件實作，顯示「以 agent 輔助資料處理管線」已成為一種可落地的工程範式 [3]。這個群集把焦點從「模型多強」轉移到「系統怎麼搭」，與第一個群集形成互補而非取代的關係。

第三個群集是AI 導入治理論。這條路線跳出技術細節，探討組織該如何「明智地管理 AI」。相關研究強調，AI 系統的成敗不僅取決於演算法準確度，更取決於人類與系統之間的責任分工、以及對不確定性的制度化處理 [6]。這個觀點對回單辨識尤其關鍵：當模型對某張爛照片無法可靠判讀時，系統設計者必須事先決定「這種情況該交給誰、用什麼流程兜底」，而非寄望模型達到不可能的 100% 準確。

綜合三個群集可以看出一個論述轉移的趨勢：早期討論偏向模型能力中心，假設只要模型夠強問題就解決；近期討論則逐漸轉向系統與治理中心，承認模型有其天花板，真正決定落地成敗的是前後處理、分流機制與人工審核的設計。然而，現有文獻多半各自停留在自己的群集內：模型研究少談生產環境的長尾與兜底，工程實務少談量化的準確率邊界，治理研究又偏抽象、缺乏具體的技術落地細節。本文分析認為，這三者之間的接合處，正是回單辨識落地討論的研究缺口，而一份完整的本土上線實錄恰好能填補此缺口 [1]。

回單辨識的技術演進可拆為三代，關鍵在於理解這不是線性的「誰取代誰」，而是每一代各自存活、依場景與資安要求並存的格局 [1]。

第一代是 OCR 加正則（Regex）路線。 其做法是先用傳統 OCR 引擎（如 Tesseract、Google Document AI）把圖片轉成文字，再以 Python 正則表達式逐欄抽取：單號在哪、日期格式如何、地址符合哪條規則 [1]。這條路線的好處明確：成本低、可離線、速度快，在格式固定時非常穩定、可預測且易於除錯，完全不需要 LLM、沒有 token 成本 [1]。然而其脆弱性同樣明確：格式一變就崩，換一種單就要重寫一套 regex；OCR 只要認錯或漏掉一個字，整條 regex 就比對失敗；客戶越多、格式越雜，regex 就越長越脆，最終淪為維護地獄。本文分析認為，第一代的根本侷限在於它完全不理解語意，只能硬比對字串，因此無法應對印刷業單據的格式長尾。

第二代是 OCR 加文字 LLM 路線。 同樣先用 OCR 把圖轉成文字，但不再寫死 regex，而是把 OCR 輸出的文字交給文字型 LLM，由它理解語意、抽取欄位、補全缺漏 [1]。據第一手實錄，此法一上手正確率即大幅提升，原因有四：格式改變不必重寫 regex，LLM 自行理解語意；能靠上下文補回 OCR 漏掉的字；能辨識同義或別名欄位（「單號」「託運號」皆可識別）；開發快、維護成本大降 [1]。更關鍵的是，OCR 與文字 LLM 都有成熟的地端方案，可做到資料不出公司，對個資與機敏單據是決定性優勢 [1]。這一點與 AI 導入治理文獻所強調的「資料主權與責任邊界」相互呼應 [6]。

然而第二代的天花板被前段的 OCR 鎖死。OCR 先讀錯，LLM 拿到的就是錯的文字，形成「垃圾進、垃圾出」；OCR 過程丟失了版面與顏色資訊，紅藍筆、表格結構、手畫線全部消失，LLM 根本無從得知；手寫、簽名、塗改這類「唯有看圖才懂」的內容，一旦轉成文字便失真 [1]。本文分析認為，第二代的價值與侷限其實是同一枚硬幣的兩面：它把 regex 的痛解掉、又能全地端跑，但代價是整條管線的辨識上限受制於最前面那層 OCR 的品質。

第三代是 Vision LLM 直接判斷。 最新做法是跳過 OCR，直接把回單圖片餵給多模態模型（如 GPT-4o、Claude），讓它同時看圖與理解語意，一步輸出結構化欄位 [1]。其價值在於能直接解掉前兩代的多數痛點：看得懂版面、表格、顏色與手畫線；能判讀手寫、塗改、勾選、簽名與紅藍筆；能用邏輯與上下文判斷形近字（1 與 l、O 與 0）並補語意；免模板、免 regex、換格式也能處理 [1]。這與專門微調 VLM 以抽取結構化票據資料的研究結論方向一致，後者也證實多模態模型在處理版面複雜的真實票據時具有優勢 [2]。

但第三代的代價落在別處：推理速度慢，圖片進、推理重，比純文字流程慢不少；vision token 成本高，量大時極有感；強的 vision 模型多在雲端，想全地端、資料不出公司目前仍困難，這正是第二代至今仍有價值的原因；而且它仍做不到 100%，受潮或手機亂拍的爛照片根本沒把資訊拍進去，模型也救不了 [1]。本文分析認為，第三代的限制恰好印證了治理文獻的核心命題：模型的不確定性是結構性存在，必須以制度與流程吸收，而非期待模型自行消滅 [6]。

抽象的三代演進落到具體工具，呈現出一個清晰的權衡三角：成本、地端能力與辨識準確率三者難以兼得，選型本質是依場景排序這三個維度的優先級。

在傳統 OCR 引擎層（第一、二代的前段），實錄列舉了三個實際使用過的方案 [1]。Tesseract 是最老牌的開源引擎，純地端、免費、語言包多，優點是穩定、可離線、社群龐大，但對中文、手寫與複雜版面較吃力，現場拍攝的歪斜爛圖辨識率會明顯下滑，適合格式乾淨、以印刷體為主的場景作為 baseline [1]。PaddleOCR 由百度開源，可部署到地端（支援 NVIDIA GPU、Intel CPU 等多種硬體後端），支援 100 種以上語言，其最大價值在於中文與表格特別強，對回單這種繁體中文加表格混雜的場景優於 Tesseract，且已將整條管線拉到「PDF 或圖片轉結構化 JSON 或 Markdown」，連版面分析都納入；若要走全地端又是中文單據，PaddleOCR 幾乎是首選 baseline [1]。Google Cloud Vision 或 Document AI 辨識率高、版面分析成熟、API 易接、手寫與複雜單也撐得住，開發體驗一流，但硬傷在於它是雲端服務，資料必須出公司，與「機敏單據要地端」的需求天生衝突 [1]。

在可跑地端的 Vision LLM 層（第三代），開源社群已快速追上，多個 2025 至 2026 年的模型值得關注 [1]。Qwen：

・2.5-VL（阿里）參數規模 7B 至 72B，DocVQA 達

・95.7 分，手寫、表格與多語言文檔解析能力強、生態最成熟，是通用文檔與回單的主力候選 [1]。PaddleOCR-VL（百度）最新版本約

・0.9B 參數，在 OmniDocBench v

・1.6 取得 96% 以上，原生 OCR benchmark 打贏不少前沿大模型，支援 109 種語言，適合純地端、追求 OCR 準度與輕量部署的場景 [1]。dots.ocr（rednote）約

・1.7B 參數，將版面偵測與內容辨識合

・一，支援 100 種以上語言，已被 vLLM 官方整合，屬小模型中的 SOTA [1]。MiniCPM-V

・2.6 約 8B 參數、體積約

・5.5GB，易於塞進單卡甚至邊緣裝置，OCR 表現位居前段，適合資源有限、需部署地端小機器的場景 [1]。olmOCR 2（AllenAI）約 7B 參數，以 RLVR 訓練、完全開源（含資料與程式碼）[1]

本文分析認為，這份工具箱揭示了一個與模型能力中心論不同的選型邏輯：問題不在「哪個模型分數最高」，而在「哪個維度對你的場景不可妥協」。若機敏資料不可出公司，地端能力就是硬約束，選型直接收斂到 PaddleOCR 加文字 LLM 或地端 Vision LLM；若手寫與塗改密集、且資料可上雲，則辨識準確率優先，雲端 Vision LLM 成為合理選擇 [1]。前述微調 VLM 的研究也間接支持此判斷：資料集與模型必須與目標場景對齊，脫離場景談模型優劣意義有限 [2][4]。

更務實的結論是兩者常混用：清晰的單走便宜的地端流程，難的才丟給 Vision LLM [1]。這種混用本質上是一種成本分流策略，它把昂貴的高階推理資源保留給真正需要的少數困難案例，而非無差別地對每張單都動用最重的模型。

實錄將踩坑沉澱為一句架構心法：辨識最小化、系統最大化、不確定就交人 [1]。本文認為這句話可拆解為三層系統設計原則，並與治理文獻形成理論呼應。

第一層是前處理標準化。 回單辨識的失敗，很大比例不發生在模型，而發生在輸入。受潮、歪斜、亂拍的照片，資訊根本沒被完整拍進去，再強的模型也無法無中生有 [1]。因此系統的第一道工程，是在辨識之前把輸入盡可能標準化：去歪斜、裁切、增強對比、過濾品質不合格的影像。本文分析認為，這層的設計哲學是「把不確定性提前攔截」，與其讓爛輸入污染整條管線，不如在入口就分流出來。日本行動收據研究所強調的資料集版面多樣性問題，本質上也是在提醒：輸入端的變異必須被系統性地處理，而非全部丟給模型承擔 [2]。

第二層是 LLM 結構化抽取。 這層對應「辨識最小化」的精神：不要求模型一次完成所有判斷，而是讓它專注於把版面內容轉成結構化欄位。無論走第二代的文字 LLM 或第三代的 Vision LLM，核心都是把非結構化的圖像或文字，映射到一個明確的 schema（單號、品名、數量、交期、簽收狀態等）[1]。本文分析認為，把抽取任務 schema 化的好處有：

・二：

・其一，輸出可被下游系統直接消費，降低後處理成本

・其二，schema 提供了一個可驗證的錨點，讓系統能判斷某個欄位是否被可靠抽出。AI coding agent 在這層尤其能加速開發，將串接與樣板邏輯自動化，讓工程師專注於 schema 與驗證規則的設計 [5][3]

第三層是人工審核閘道。 這是整套架構的關鍵，也是「不確定就交人」的制度化體現。模型對每個欄位的抽取應附帶信心度或驗證結果，當信心度低於門檻、或欄位間出現邏輯矛盾（如數量與金額不符）時，系統不應自動放行，而應將該單路由給人工審核 [1]。本文分析認為，這層設計把模型的結構性不確定性轉化為可管理的人力流程，正是治理文獻所主張「明智管理 AI」的具體落地：系統不假裝完美，而是事先設計好不確定情況的責任歸屬與兜底路徑 [6]。

將三層合觀，可以推演一個典型的分流情境。假設一家印刷廠每日進件 1000 張回單，其中約八成為格式清晰的印刷體單據，可由地端的 OCR 加文字 LLM 以低成本高速處理；約一成五為含手寫或塗改的中等難度單，路由給 Vision LLM；剩餘約半成為品質過差或矛盾的單，直接進人工審核 [1]。在這個推估情境下，最昂貴的雲端 Vision LLM 只需處理約一成五的件量，而人力只需聚焦在最棘手的少數案例。本文分析認為，這種分層分流不僅是準確率的優化，更是成本結構的優化，它讓系統的邊際成本隨難度分布而非總件量線性成長。

上述架構心法對台灣設計印刷產業的不同角色，具有層次分明的可操作意涵。

對中小印刷廠而言，最重要的啟示是不要把回單辨識當成「買一個模型就解決」的採購問題，而要當成「搭一套分流系統」的流程問題。具體做法上，建議以 PaddleOCR 加地端文字 LLM 作為 baseline，先把格式清晰、量大的常規單據自動化，這部分幾乎沒有 token 成本、且資料不出公司，符合多數印刷廠對客戶訂單機敏性的顧慮 [1]。在此基礎上，再針對手寫與塗改密集的困難單，選擇性地接雲端 Vision LLM，並務必設置信心度門檻與人工審核閘道 [1]。本文分析認為，這種漸進式導入的時程上，廠商可在數週內先讓 baseline 跑起來消化八成件量，再逐步把困難案例的自動化比例往上推，而非一開始就追求全自動。

對設計師而言，回單與作業單的數位化意味著規格資訊（尺寸、用紙、特殊加工）能更可靠地從紙本流轉到數位系統，減少因人工轉謄造成的規格誤差。本文分析認為，當辨識系統能穩定抽出結構化欄位，設計端與生產端之間的規格對齊將更即時，打樣與改版的溝通成本可望下降。此外，設計師若理解辨識系統對「清晰版面」的偏好，在設計作業單模板時即可採用固定欄位、印刷體優先的版面，反向降低後端辨識難度。

對品牌方而言，回單數位化的意義在於供應鏈可視性與責任可追溯性。當每張簽收與出貨單都被結構化記錄，品牌方得以追蹤訂單在印刷供應鏈中的流轉狀態，並在爭議發生時調閱可信的數位憑證。本文分析認為，這也呼應了 AI 導入治理文獻的核心：系統的價值不只在自動化效率，更在於它如何重新分配人與系統之間的責任與信任邊界 [6]。品牌方在導入時，應特別關注審核閘道的稽核軌跡是否完整，以確保自動化不以犧牲可問責性為代價。

對所有角色共通的一點是資安與地端的權衡。台灣印刷業承接大量含個資與商業機密的單據（如帳單印刷、會員資料、財報印製），這使得「資料不出公司」往往是不可妥協的約束。本文分析認為，這正是第二代 OCR 加文字 LLM 路線在台灣產業情境下格外重要的原因：它在可接受的辨識能力下保住了地端部署的資料主權，而這是純雲端 Vision LLM 方案目前難以兼顧的 [1]。

本文以一份台灣印刷廠回單 OCR 上線實錄為核心個案，回應了緒論提出的三個研究問題：

・其一，回單辨識歷經 OCR 加正則、OCR 加文字 LLM、Vision LLM 直判三代演進，三代並非取代關係，而是依場景與資安要求並存 [1]

・其二，最新模型未必最該採用，選型的決定因素是成本、地端能力與辨識準確率三者的權衡排序，而非單一 benchmark 分數 [1][2]

・其三，落地成敗取決於「前處理標準化、LLM 結構化抽取、人工審核閘道」三層架構的協同，以及「辨識最小化、系統最大化、不確定就交人」的分流原則 [1]。本文的核心論點是：回單辨識應從模型中心的思維，轉向系統與治理中心的思維 [6]

本研究存在若干限制，必須誠實揭露。首先，核心個案為單一工程師的第一手實錄，其情境（台灣印刷廠回單）雖具代表性，但 benchmark 數據（如 DocVQA：

・95.

・7、OmniDocBench 96% 以上）係引自模型公開宣稱，未在本文的目標場景下獨立複現，外推時應審慎 [1]。其次，本文引用的票據 OCR 文獻以日本行動收據為對象，與繁體中文印刷廠回單在語言與版面上存在差異，其結論的可移植性需進一步驗證 [2][4]

・第三，前述「1000 張分流」情境為本文基於實錄原則所做的推估，比例係示意性質，實際分布因廠而異，未經實證量測

後續研究方向有：

・三：

・其一，建構繁體中文印刷業回單的標註資料集，以在地化的 benchmark 取代外推，這與日本收據資料集研究的方法論可相互參照 [2]

・其二，量化評估三層架構在真實生產環境的成本效益，特別是人工審核閘道的最適門檻設定

・其三，將 AI 導入治理的框架具體化為印刷業可操作的稽核與責任分工準則，銜接技術落地與組織治理之間的缺口 [6][5]

回單辨識的三代技術（OCR+Regex、OCR+文字 LLM、Vision LLM）並非取代關係，而是依場景與資安要求並存。

選型的決定因素是成本、地端能力與準確率的權衡排序，而非單一 benchmark 分數；最新模型未必最該採用。

落地成敗取決於「前處理標準化、結構化抽取、人工審核閘道」三層架構的協同，而非單一模型強弱。

「辨識最小化、系統最大化、不確定就交人」是把模型結構性不確定轉化為可管理流程的核心心法。

對台灣機敏單據場景，地端的 OCR+文字 LLM 路線因保住資料主權而格外重要，難件再選擇性丟給 Vision LLM。

對印刷製造而言，回單 OCR 的真正槓桿不在模型而在系統設計：先用低成本地端流程消化八成常規單據，再以雲端 Vision LLM 與人工審核處理長尾困難件，能讓邊際成本隨難度而非總量成長。對設計端，這意味著作業單模板應朝固定欄位、印刷體優先設計，反向降低辨識難度。對 AI 導入與 SaaS 業者，機會在於把「三層架構加分流引擎加稽核軌跡」打包成印刷業可直接採用的產品，而非只賣模型 API。待解問題有三：繁中印刷回單缺乏在地化 benchmark、人工審核門檻的最適設定缺乏實證、以及自動化與可問責性如何在治理層面兼顧。

[1] 工廠回單 OCR 上線實錄：這些坑你不踩就是白費工，沉澱後的架構心法全公開

[2] Nathan S.（2025）. Japanese-Mobile-Receipt-OCR-1.3K: A Comprehensive Dataset Analysis and Fine-tuned Vision-Language Model for Structured Receipt Data Extraction. DOI: 10.36227/techrxiv.175616889.90325672/v1

[3] Rodriguez J.（2025）. myownrobs: AI Coding Agent for 'RStudio'. CRAN: Contributed Packages. DOI: 10.32614/cran.package.myownrobs

[4] Nathan S.（2025）. Japanese-Mobile-Receipt-OCR-1.3K: A Comprehensive Dataset Analysis and Fine-tuned Vision-Language Model for Structured Receipt Data Extraction. DOI: 10.21203/rs.3.rs-7357197/v1

[5] Wienholt N.（2025）. Using an AI Coding Agent. GitHub Copilot and AI Coding Tools in Practice. DOI: 10.1007/979-8-8688-1784-7_2

[6] Waardenburg L., Huysman M., Agterberg M.（2021）. Introduction to managing AI wisely. Managing AI Wisely. DOI: 10.4337/9781800887671.00010