北京
很多人處理文檔時有個慣性假設：上傳的是PDF，就該用一套PDF提取方案。但文件真正打開后，現實往往更混亂——前兩頁是結構化表單，接下來五頁是帶表格的發(fā)票，然后是敘述性說明、簽字審批頁、幾張照片，最后還有一段密集排版的合同摘錄。用戶眼里這是一份提交材料，存儲層也只存了一個文件，但內容本身根本不是一回事。
表單、表格、自由文本承載信息的方式截然不同。表單要的是命名字段，表格重復的是行記錄，敘述段落靠上下文和論證結構傳遞含義。強行把三者塞進同一種格式，結果往往是：散文被擠進JSON字段，表格壓平成不可靠的文本，復選框消失在Markdown里，或者表單字段埋進一大段下游系統還得重新解析的內容塊。
真正該問的不是"怎么提取這份文檔"，而是"文檔的每個部分需要什么表示形式"。
表單的核心是命名值。業(yè)務流程通常需要特定事實：申請人姓名、出生日期、同意狀態(tài)、申請金額、保單號、會員ID、簽字日期、稅務狀態(tài)或所選權益。這些事實直接驅動工作流決策——創(chuàng)建案件、路由審核、確認資格、生成回復，或在缺少同意書時阻斷下一步。對這種內容，類型化字段才是合適的形態(tài)。字段名應對接目標系統，而非頁面上的標簽文字。復選框應轉化為"has_signed_consent"這樣的業(yè)務決策，而非模糊的標記；日期應說明是哪個日期；缺失值就該保持缺失，而不是變成看似有意的空字符串。
表單提取的難點不只是讀取方框，而是判斷某個字段能否安全驅動下一步。低置信度的可選備注或許可以接受，低置信度的付款授權則必須暫停流程。一個基本清晰的表單區(qū)塊可以生成部分記錄，同時讓某一字段等待復核。這使得表單提取既是解析問題，也是狀態(tài)問題——輸出必須保留置信度、引用來源、復核狀態(tài)和已批準值，否則工作流無法區(qū)分"用戶未提供""提取器不確定"和"復核員后來修正"這三種情況。
表格的邏輯完全不同，它建立在重復記錄之上。發(fā)票含明細行，銀行對賬單含交易記錄，供應商目錄含SKU，合規(guī)報告含發(fā)現項。表格提取的目標不是定位單個值，而是識別哪些單元格屬于同一行、哪些表頭對應哪些列，以及當表格跨頁時如何保持行的連續(xù)性。輸出形式通常是對象數組，每行一個條目，列名作為鍵。這里的挑戰(zhàn)在于結構一致性：有些表格有合并單元格，有些有嵌套表頭，有些在PDF里只是視覺上對齊而非真正的表格結構。錯誤的行分組或列映射會讓下游計算完全失真。
自由文本又是另一套規(guī)則。敘述性內容——事故描述、醫(yī)療記錄、合同條款、研究背景——的價值在于論證結構：段落如何展開，標題如何組織話題，句子如何建立指代關系。把這種內容壓平成鍵值對會丟失上下文，拆成獨立句子則會切斷指代鏈條。自由文本需要的是保留層級結構的格式，比如帶標題的Markdown或分節(jié)的JSON，讓下游系統能夠引用特定段落、檢測話題邊界，或在需要時重構完整敘述。
混合文檔的真正解法，是在提取前先做內容分類。不是按文件類型，而是按內容類型：這一頁是表單，這一區(qū)域是表格，這一段是敘述文本。每種類型走各自的提取路徑，生成各自的表示形式，最后在文檔層面組裝成統一輸出——表單字段、表格數組、文本區(qū)塊各自就位，同時保留頁碼、坐標和置信度等元數據，供下游路由和審核使用。
一刀切的時代早就該結束了。PDF只是容器，不是內容。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發(fā)布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
