Prodigy + Docling + 自訂腳本：真實企業技術棧稽核

真實的企業 AI 資料準備技術棧是什麼樣的？不是架構投影片上的示意圖——而是一個 ML 團隊日常運作的工具、腳本和應急方案的實際狀況。

這是對一個具代表性技術棧的稽核：Prodigy 用於標注，Docling 用於文件解析，自訂 Python 腳本 用於處理其他一切。每個工具在其類別中都廣受好評。摩擦點在於它們之間的空隙。

技術棧

Prodigy（Explosion AI）：永久授權，$390 起，截至 2026 年 8 月

Prodigy 可以說是 NLP 任務中最好的標注工具。它快速、可腳本化、本地運行（對敏感資料很重要），並支援主動學習。它是那些用過其他所有工具的 ML 工程師通常最終選擇的工具。

它擅長的：

• 極其高效的標注介面（為速度而設計）
• 完全本地運行——無雲端依賴，無需 Docker
• 主動學習：建議標籤，從修正中學習
• 可自訂的 Python API
• 支援 NLP（命名實體識別、文本分類、跨度）和電腦視覺任務

它不做的：

• 沒有文件解析——期望文本輸入，而非 PDF
• 沒有資料清理或品質評分
• 沒有合規稽核軌跡（為生產力而設計，而非治理）
• 單用戶為中心——團隊功能需要自訂編排
• 沒有多格式導出（輸出 Prodigy 的內部格式）

Docling（IBM Research）——免費/開源

Docling 是一個強大的文件解析器。它處理 PDF、Word 文件和其他格式，具有良好的表格提取和版面偵測功能。

它擅長的：

• 97.9% 的表格提取準確率（與商業工具相當）
• 版面感知解析（標題、段落、列表、表格）
• 多種輸出格式（Markdown、JSON、文本）
• 開源，由 IBM Research 積極維護

它不做的：

• 沒有標記功能
• 沒有資料清理、去重複或品質評分
• 沒有個人識別資訊偵測或編輯
• 沒有稽核軌跡
• 沒有 GUI——只有命令列介面

自訂 Python 腳本——「免費」

Docling 和 Prodigy 之間的一切——以及 Prodigy 之後的一切——都是自訂代碼：

• docling_to_prodigy.py — 將 Docling 輸出轉換為 Prodigy 的輸入格式
• clean_extracted_text.py — 去重複、品質過濾、標準化
• pii_detection.py — 基於正規表達式和命名實體識別的個人識別資訊偵測
• prodigy_export.py — 將 Prodigy 標注導出為訓練格式
• quality_check.py — 標注者間一致性、標籤分佈分析
• prepare_training_data.py — 最終格式化以供模型訓練

總計：約 3,000-5,000 行 Python 代碼，分佈在 8-12 個腳本中

摩擦點

摩擦點一：Docling → Prodigy 格式轉換

Docling 將文件輸出為帶有章節、表格和元資料的結構化物件。Prodigy 期望帶有 text 欄位的 JSONL 格式記錄流。

轉換腳本必須：

• 將文件結構扁平化為適合標注大小的區塊
• 決定區塊化策略（按頁面？按章節？按段落？）
• 將元資料（源文件、頁碼、章節）保留為 Prodigy 的 meta 欄位
• 處理表格（轉換為文本？Markdown？跳過？）
• 處理多頁文件（每頁一個 Prodigy 任務，還是合併？）

這個轉換器中的決策不是技術性的——而是特定領域的。 按章節還是按段落分塊影響標注品質。是否包含表格影響模型覆蓋範圍。這些決策應由領域專家做出，但它們被編碼在一個由 ML 工程師維護的 Python 腳本中。

摩擦點二：手動品質管道

在 Docling 提取和 Prodigy 標注之間，資料需要清理：

• 去重複（相同文件在多個資料夾中）
• 品質過濾（OCR 置信度低於閾值 → 標記或排除）
• 個人識別資訊偵測和編輯（在標注者看到資料之前）
• 標準化（編碼問題、空白、特殊字元）

這是 1,000-2,000 行自訂 Python 代碼，沒有人想寫，沒有人想維護，也沒有人全面測試過。

摩擦點三：稽核軌跡缺口

對於受監管行業，稽核軌跡看起來是這樣的：

• Docling：記錄解析事件（如果配置了日誌記錄）
• 自訂腳本：記錄開發人員記得記錄的任何內容（通常是：沒有有用的內容）
• Prodigy：記錄帶有時間戳記和會話 ID 的標注事件

缺少的：

• 格式轉換何時運行？由誰運行？
• 個人識別資訊偵測配置是什麼？哪些內容被編輯了？
• 使用了每個腳本的哪個版本？
• 品質閾值是如何設定的？誰批准了它們？

這些缺口是 EU AI Act 及類似法規下的合規風險。

摩擦點四：公車因素

在大多數使用這個技術棧的企業中，一位 ML 工程師理解整個管道。他們編寫了腳本，配置了工具，並處理處理過程中出現的邊緣案例。

如果這個人離職：

• 自訂腳本的文件記錄極少
• Prodigy 配置有未記錄的慣例
• 邊緣案例處理是部落知識
• 下一位工程師需要 4-8 週才能理解管道

這不是 Prodigy 或 Docling 的缺陷——它們都是有良好文件記錄的個別工具。公車因素風險在於連接它們的自訂整合層。

摩擦點五：領域專家被排除在外

Prodigy 非常適合 ML 工程師。它是一個以 Python 為主的命令列工具：

prodigy ner.manual my_dataset blank:en ./data.jsonl --label PERSON,ORG,DATE

需要標記特定領域資料的律師或醫生，在沒有 ML 工程師設置和運行會話的情況下無法使用它。這造成了瓶頸標記吞吐量的依賴關係。

統一平台改變了什麼

上述摩擦點不是由糟糕的工具引起的——而是由工具邊界引起的。每個工具都很強大，但設計上沒有考慮與其他工具協作。

像 Ertas Data Suite 這樣的統一平台消除了這些邊界：

• 文件解析直接輸入清理（無需格式轉換）
• 清理直接輸入標記（無需自訂腳本）
• 標記包含品質審查（無需單獨的品質管道）
• 導出生成合規文件（無稽核軌跡缺口）
• 領域專家與 ML 工程師使用相同的介面（無無障礙障礙）

取捨：您失去了 Prodigy 特別出色的標注速度和 Docling 特別出色的表格提取能力。您獲得了管道連續性、稽核軌跡完整性和領域專家可及性。

對於受監管行業的企業生產管道，管道層面的好處通常超過工具層面的取捨。對於研究和實驗，個別工具可能仍然是更好的選擇。

這個技術棧很好。工具之間的空隙才是成本所在。