PDF 轉 JSONL：為 AI 訓練構建企業資料準備管道

企業 AI 資料準備最常見的起點是一個資料夾——或一個共享磁碟機，或一個文件管理系統——裡面裝滿了 PDF。年報。技術手冊。臨床記錄。法律合約。工程規格書。數十年的機構知識鎖定在一個為人類閱讀設計、而非機器學習設計的格式中。

從那個 PDF 資料夾到可以微調的 JSONL 檔案，是一個五個階段的管道。如果您只處理過少量乾淨、現代的 PDF，每個階段的失敗模式都很容易被忽視。在企業規模——數千或數十萬份文件，多年積累，由使用不同軟體的不同團隊生成——每種失敗模式都會成為可靠性問題。

本指南介紹完整管道：每個階段發生什麼，可能出什麼問題，以及在輸出真正可用之前需要哪些品質檢查。

為何 PDF 是問題所在

估計非結構化資料佔企業資料總量的 80-90%。PDF 佔了其中相當大的份額——它們是需要在不同系統間保持一致外觀並長期保存的文件的事實標準格式。您的組織在過去 20 年中生成或接收的每一份合約、政策、技術規格、研究報告和法規備案很可能都在 PDF 中。

問題在於 PDF 是一種呈現格式。其內部結構描述了墨水應該如何出現在頁面上，而不是文字的含義或不同文字元素如何相互關聯。PDF 渲染器可以漂亮地顯示多欄技術文件。一個簡單的文字提取器會產生兩欄以錯誤順序交替出現的混亂片段。

在能寫入單個 JSONL 記錄之前，您必須解決：閱讀順序、表格結構、章節邊界、嵌入圖片、頁首頁尾、腳注、數學表達式，以及正文和說明文字之間的區別。這些都不是通過簡單調用文字提取庫來解決的。

第一階段：分類和路由

並非所有 PDF 都是一樣的。在解析之前，每個文件需要按類型分類，因為不同類型需要不同的處理管道：

• 帶可選取文字的原生 PDF：可以直接提取文字。仍然需要版面分析來確定閱讀順序。
• 掃描版 PDF（僅圖片）：沒有嵌入文字。每頁都需要 OCR。
• 混合 PDF：部分頁面是原生的，部分是掃描的（當文件被重新列印和重新掃描時，或手動添加了插頁時很常見）。
• 表單 PDF：互動式欄位、複選框和結構化表單資料需要與流動文字不同的提取邏輯。

將掃描 PDF 錯誤分類為原生——並跳過 OCR——會產生零文字輸出或充滿編碼偽影的文件。基於頁面圖像分析的自動分類應在路由到適當解析器之前進行。

第二階段：解析和提取

對於原生 PDF，提取使用版面感知解析，從頁面上文字元素的空間位置重建閱讀順序。多欄版面需要提取器在線性化之前按欄分組文字元素。頁首、頁尾和頁碼需要識別並單獨去除或標記。

對於掃描 PDF，OCR 品質取決於掃描品質、字體清晰度和頁面方向。常見問題：

• 傾斜的頁面（文件在掃描器中稍微放歪）會產生旋轉的文字，OCR 引擎難以識別
• 低解析度掃描（低於 200 DPI）會產生字元級錯誤，這些錯誤會累積成詞級錯誤
• 混有手寫標注和印刷文字需要單獨處理
• 蓋章、簽名和表單覆蓋遮擋了底層文字

表格需要特別注意。PDF 中的表格沒有明確的儲存格結構——只是位置在格線上的文字。正確提取表格需要偵測格線（或儲存格之間的空白）、將文字與儲存格關聯、保留行列關係，以及處理合併儲存格和多級標題。

對於企業資料集，表格提取失敗不是小問題。如果您的文件是工程規格書、財務報告或臨床結果表格，大量資訊存在於表格中——如果提取器將它們扁平化為非結構化文字，那些資訊就會丟失或損壞。

第三階段：清理和標準化

解析的輸出是原始提取的文字，可靠地包含：

• 編碼偽影：OCR 誤讀產生亂碼字元（fı 而非 fi，• 渲染為 •，捲曲引號渲染為 “）。
• 頁首頁尾污染：已作為正文提取的頁首頁尾和頁碼，在整個文件中反複出現。
• 連字符偽影：在換行處連字符的詞語，提取器保留為 infor-\nmation 而非 information。
• 空白不規則：過多的空行、不一致的段落間距和前後空白。
• 近似重複：同一章節多次出現，因為它在附錄中被引用，或者修訂後的文件與原始文件共享 90% 的內容。

去重複值得特別關注。企業文件檔案不是精心策劃的，而是積累的。同一合約範本出現 300 次，只有微小差異。同一技術規格有 12 個修訂版本。如果您在 30% 的內容是近似重複的資料集上訓練，模型將學習以誇大的置信度重現該內容，而表面上的訓練集大小將具有誤導性。

近似重複偵測需要比較文件指紋（MinHash、SimHash 或基於嵌入的相似性）而非精確字串匹配，因為沒有兩個近似重複是逐字逐句相同的。

對於受監管行業，此階段還包括個人識別資訊和受保護健康資訊的偵測和編輯。姓名、地址、電話號碼、電子郵件地址、政府 ID 號碼、帳號，以及（對於醫療保健）病歷號碼、診斷代碼和患者識別符，必須在資料用於訓練之前被偵測和編輯。

第四階段：為目標格式構建結構

JSONL 是一種格式，而非模式。每個 JSON 物件內部的內容完全取決於您在訓練什麼。

對於指令微調，每條記錄需要一個提示和一個補全：

{"prompt": "Summarize the following contract clause: [text]", "completion": "The clause establishes..."}

對於對話微調，每條記錄是一個對話：

{"messages": [{"role": "user", "content": "..."}, {"role": "assistant", "content": "..."}]}

對於 DPO（直接偏好優化），每條記錄需要一個選擇的和一個拒絕的回應：

{"prompt": "...", "chosen": "...", "rejected": "..."}

對於 RAG 管道，資料不是訓練對的 JSONL——而是帶元資料的分塊文字，格式化後用於攝入向量存儲：

{"text": "...", "source": "document_id", "page": 12, "section": "Section 4.2"}

格式的選擇必須在標記開始之前做出，因為標記策略會根據格式改變。在不知道目標格式的情況下標記資料的團隊，往往在意識到格式錯誤時不得不重新標記。

第五階段：導出前驗證

最終導出前的驗證可以發現在訓練失敗或模型行為意外之前看不見的問題。

最少驗證檢查：

• 模式驗證：JSONL 中的每條記錄都符合預期的欄位結構和類型
• 長度分佈：對於訓練設置來說太短（低於 50 個 Token）或太長（超過上下文視窗）的記錄
• 標籤分佈：對於分類任務，資料集中的類別分佈——顯著的不平衡將產生在多數類別上表現良好但在少數類別上表現差的模型
• 去重複通道：最終檢查確保沒有近似重複漏過
• 編輯完整性：個人識別資訊/受保護健康資訊偵測覆蓋的樣本稽核，特別是標準模式未涵蓋的欄位（自訂識別符、非正式姓名）

粗略基準：對於原生 PDF 語料庫，預計通過第 1-3 階段，每 1,000 份文件需要 2-8 小時的處理時間，取決於文件複雜性。對於掃描 PDF，根據 OCR 難度乘以 3-5 倍。標記時間（第 4 階段）主要由標注任務的複雜性和領域專家的可用性決定——對於複雜標注，每條帶標籤記錄預算 2-10 分鐘。

在企業規模出錯的地方

在小規模可管理的問題在大規模會成為可靠性問題：

• 100 份文件中 0.5% 的 OCR 錯誤率是 50 個壞字元。跨 100,000 份文件，可能是數千條損壞的記錄。
• 漏掉 5% 重複項的近似重複偵測系統，在小資料集中留下可接受的雜訊。在規模上，它產生對常見內容的系統性過度代表。
• 在驗證中捕獲 95% 識別符的個人識別資訊編輯系統可能漏掉 5%——當資料集包含醫療或財務記錄時，這個數字代表真實的暴露風險。

另一個擴展問題是工具。大多數 PDF 解析、清理和格式化工具是為實驗和小規模運行設計的。它們不能優雅地處理 400,000 份文件，不產生稽核軌跡，也不以讓您隨時間監控管道輸出品質的形式暴露品質指標。

Ertas Data Suite 原生處理這個管道——從單個專案中解析、清理、去重複、個人識別資訊編輯、標記和導出到 JSONL——對每次轉換進行完整稽核日誌記錄，資料不離開機器。

---

相關閱讀

• How to Convert Unstructured Enterprise Documents into AI Training Data — 涵蓋 PDF 之外的完整企業文件格式範圍。
• The Five Stages of an Enterprise AI Data Pipeline — 每個管道階段的結構化分析，包含常見失敗點。
• The Enterprise Guide to AI Data Preparation — 企業資料準備的全面概覽，從原始文件到訓練就緒資料集。