https://yennj12.js.org/yennj12_blog_V4/tags/textract/Recent content in Textract on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSun, 19 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part2-intelligent-document-processing-zh/Sun, 19 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part2-intelligent-document-processing-zh/大部分人處理「一堆掃描的 PDF」:先找個 OCR 套件,發現表格全亂掉;再寫一堆正則去抓欄位,換一家供應商的發票格式就全爆;最後放棄,回去用人工 key-in。 AWS 原生的作法是把這件事拆成一條流水線:Textract 負責把像素變成有版面、有表格、有 key-value 的結構;Comprehend 認出裡面的實體與分類;Bedrock 用 LLM 把它們變成你要的乾淨 JSON;Step Functions 把這幾步串成一個可重試、可觀測、可分岔到人工複核的狀態機。 沒有一台 OCR 伺服器要你養,單頁到上千頁的合約都能吞,失敗的頁面自動重試、信心分數太低的自動轉人工。 這是 Part 2:當文件很髒、很多、很不規則時,AI 系統長什麼樣。 一、情境與痛點:結構化的世界之外 Part 1 的 RAG 有個隱藏前提:你的文件已經是乾淨的文字。但真實世界的企業文件長這樣: 保險公司:每天幾萬張理賠單、診斷證明、收據——掃描件,手寫加印刷混雜。 供應鏈:上百家供應商、上百種格式的發票,每張要抓出品項、數量、稅額、到期日。 法務/金融:幾百頁的合約 PDF,要抽出關鍵條款、當事人、金額、生效日。 這些文件的共同特徵:非結構化、格式不一、量大、還常常是圖片(掃描件)。你沒辦法直接 read() 出文字,更別說塞進 RAG。 傳統作法的死法很固定: 通用 OCR:能出文字,但表格結構、欄位對應全丟失——發票的「單價」跟「數量」被拆成兩串沒關係的文字。 正則/模板抽取:對「固定格式」有效,但供應商一改版面就整組壞掉,維護地獄。 人工 key-in:準,但慢、貴、無法擴張。 IDP(Intelligent Document Processing)要解的就是這個:把非結構化文件,自動變成可查詢、可入庫的結構化資料,而且要能容忍格式的多樣性。 二、系統目的:功能與非功能需求 功能需求: 支援 PDF、PNG、JPG、TIFF;單頁到上千頁。 抽出:純文字、表格、key-value 對(表單欄位)。 辨識實體:人名、公司、日期、金額、地址;支援自訂實體(如保單號)。 依文件類型分類(發票 / 合約 / 理賠單…),不同類型走不同萃取邏輯。 用 LLM 把抽取結果正規化成固定 schema 的 JSON。 信心分數低的文件自動轉人工複核,不是靜默出錯。 非功能需求: 面向 目標 為什麼 吞吐 尖峰每小時數萬頁 月結、季報時會爆量 大檔 支援 1000+ 頁,不 timeout 合約、財報很長 冪等 同一份文件重送不會重複入庫 事件驅動一定會有重送 可觀測 每份文件跑到哪一步、為何失敗,可查 出錯要能追 準確 低信心自動轉人工,不硬吞 錯誤的金額比沒答案更糟 成本 按頁計費,離峰接近零 流量高度不均 「大檔不 timeout」跟「尖峰爆量」這兩條,直接決定了架構必須是非同步 + 事件驅動 + 狀態機編排,而不是一個 Lambda 從頭跑到尾。