
資料準備差距:為什麼 ML 團隊在訓練開始前就花費了 80% 的時間
為什麼 60% 到 80% 的資料準備統計數字持續存在——碎片化的工具、排除領域專家、缺失的審計追蹤,以及對專用資料準備工具的結構性投資不足。
這個統計數字現在幾乎是老生常談:ML 團隊將 60% 到 80% 的時間花在資料準備上。它已在調查、博客文章和會議演講中被引用了十多年。然而——沒有任何改變。這個百分比沒有移動。
這種持續性值得深究。ML 團隊效率低下嗎?他們過度設計了他們的資料管道嗎?還是業界處理資料準備的方式有些結構性的東西,保證了這個結果?
答案是結構性的。而修復方法不是更好的 ML 工程師——而是解決根本原因的專用工具。
為什麼這個百分比沒有改變
原因 1:碎片化的工具
大多數企業的資料準備工作流涉及 3 到 7 個不相連的工具:
- 解析:Docling、Unstructured.io、Marker 或自訂腳本
- 清理:使用 Pandas 的 Python 腳本、自訂去重複邏輯
- 標記:Label Studio、Prodigy 或 Argilla
- 品質評分:Cleanlab、自訂驗證腳本
- 增強:Distilabel、自訂合成生成
- 匯出:另一個 Python 腳本來格式化輸出
每個工具都有自己的:
- 安裝和設置過程
- 資料 格式要求(輸入和輸出)
- 學習曲線和文件
- 更新週期(會發生破壞性更改)
- 日誌記錄方式(或缺乏)
這些工具之間的整合是自訂 Python 代碼——沒有人想寫、沒有人想維護、當它們中斷時沒有人想調試的「黏合腳本」。
這種碎片化在每個邊界處都會增加工作量。格式轉換、錯誤處理、資料驗證和審計追蹤連續性都需要不直接提高資料品質的工程時間。
原因 2:排除領域專家
知道資料是否被正確標記的人——醫生、律師、工程師、會計師——通常無法使用 ML 資料準備工具。Label Studio 需要 Docker 部署。Prodigy 需要 Python。Cleanlab 是一個 Python 庫。
這造成了一個瓶頸:領域專家有知識,ML 工程師有工具訪問權,而他們之間的交接降低了速度和品質。
典型流程:ML 工程師提取資料,將其格式化到標記工具,向領域專家解釋標記架構(領域專家在監督下使用工具或通過試算表提供標籤),ML 工程師導入標籤,運行品質檢查,並迭代。每次交接都增加了延遲和錯誤潛力。
如果領域專家可以直接標記資料——不需要 Docker、Python 或 ML 工程師作為中間人——標記階段所需的時間將會是現在的一小部分。
原因 3:沒有審計追蹤架構
大多數資料準備管道沒有內建的審計追蹤。當出現問題時——標記錯誤的資料、缺失記錄、品質下降——調試需要手動追蹤多個工具和自訂腳本以找到問題的起源。
沒有審計追蹤,品質問題被發現得很晚且修復成本很高。團隊花時間重新處理已經錯誤處理的資料。他們重新標記在清理過程中丟失的記錄。他們重新運行整個管道階段,因為他們無法識別哪些特定記錄受到了錯誤的影響。
在受監管行業,審計追蹤不只是調試的便利——它是合規要求。醫療保健、法律和金融領域的團隊花費額外時間手動記錄他們的管道步驟,以滿足整合系統會自動處理的監管要求。
原因 4:資料準備被視為旁支任務
在大多數組織中,資料準備被視為通往模型訓練「真正工作」的預備步驟。它沒有專門的人員配置、專門的工具預算或專門的項目管理。
ML 工程師被僱來建立模型。他們根據模型性能進行評估。他們對架構創新和訓練技術感到興奮。資料清理是他們在做他們被僱用的工作之前必須做的不光鮮的工作。
這種結構性的低估導致了投資不足:
- 團隊不購買專用的資料準備工具(他們「只用 Python 腳本」)
- 用於標記的領域專家時間沒有被正式分配
- 資料品質指標沒有被追蹤或報告
- 資料管道維護不是任何人的主要責任
原因 5:複雜性是不可化簡的(但可以更好地管理)
一些資料準備工作確實是不可化簡的:
- 文件格式多樣性是真實的——企業有幾十種格式
- 領域專業知識要求是真實的——只有專家才能正確標記
- 合規要求是真實的——審計追蹤和隱私保護需要努力
- 資料品質差異是真實的——原始企業資料有真實的品質問題
但不可化簡的複雜性並不意味著當前方法是最優的。60% 到 80% 中的大部分不是花在困難問題上——而是花在整合、格式轉換、工具維護和解決工具限制上。
實際上能解決這個問題的是什麼
資料準備差距不會通過僱用更多 ML 工程師或更快工作來縮小。當結構性問題被解決時,它才會縮小:
1. 統一平台
用單一平台取代 3 到 7 個工具鏈,處理攝取、清理、標記、增強和匯出。不是因為每個工具的個別能力被超越,而是因為整合成本是最大的效率消耗。
2. 領域專家訪問
建立領域專家可以直接使用的資料準備工具——有視覺介面的原生桌面應用程式,而非 Python 庫和 Docker 容器。
3. 內建審計追蹤
使日誌記錄自動化且全面。每次轉換、每個標籤、每個品質決定都被記錄下來,無需手動文件記錄工作。
4. 資料準備作為一級功能
將資料準備視為核心能力,而非預處理步驟。專用工具、專用時間、專用品質指標。
Ertas Data Suite 建立在這些原則上:一個覆蓋所有五個管道階段的統一平台,通過原生桌面介面對領域專家可訪問,具有自動審計追蹤和合規文件。60% 到 80% 的統計數字持續存在,是因為工具沒有改變。當工具改變時,數字也會跟著改變。
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading

Why Your AI Project Is Stalling — It's Not the Model
Most failed AI projects blame the model when the real failure was at the data stage. Here's why data preparation is where enterprise AI projects actually stall.

The Annotation Bottleneck: When Only 3 People in Your Org Can Label Data
Most enterprises have 2-3 ML engineers who can operate annotation tools. Meanwhile, dozens of domain experts sit idle with the knowledge needed for high-quality labels. This bottleneck is killing AI timelines.

EU AI Act Article 10 vs. Article 30: What Your Data Team Needs to Know
A detailed comparison of EU AI Act Articles 10 and 30 — the two most critical provisions for AI training data governance, documentation, and compliance.