企業 AI 專案在資料階段失敗——而非模型階段

65% 的企業 AI 部署正在停滯。這個數字三年來大致保持不變，這意味著問題是結構性的，而非偶然的。新一代基礎模型沒有解決它。更好的 MLOps 工具、更多 ML 工程師人員或更高的高管支持也沒有。

傳統診斷指責了錯誤的階段。當企業 AI 專案未能交付時，事後分析通常集中在模型選擇（「我們應該使用不同的架構」）、基礎設施（「我們的雲端設置不正確」）或組織準備（「我們需要更多 AI 素養」）。這些並非總是錯的。但它們幾乎總是不完整的——而且往往是在嫁禍給錯誤的罪魁禍首。

企業 AI 專案停滯的真正原因幾乎總是相同的：資料沒有準備好，沒有人分配時間或工具來讓它準備好。

數字並不模糊

研究是一致的，多年來一直如此。

行業共識——來自 MIT、麥肯錫、Gartner 和大規模從業者——將 ML 專案時間的 60 到 80% 放在資料準備上，而非模型訓練。不是部署、不是評估、不是基礎設施配置。是資料準備。

Forrester 在 2024 年與 Capital One 聯合進行的一項對 500 名企業資料負責人的調查中，發現 73% 將資料品質和準備列為 AI 成功的首要障礙。不是模型品質。不是計算成本。不是治理。是資料品質和準備。

IBM 和 MIT 的研究一致發現，80 到 90% 的企業資料是非結構化的——文件、電子郵件、圖像、PDF、手寫記錄、傳統資料庫匯出。這是大多數企業 AI 系統需要從中學習的資料，也是需要最多準備才能讓任何訓練或檢索系統使用的資料。

只有 30% 的組織使用 AI 進行自動化資料準備。其餘 70% 是手動處理、使用自訂腳本，或根本不處理。

這些數字加起來構成了清晰的圖景。大多數企業組織的大多數資料都是 AI 無法直接消費的格式。他們大多數 ML 專案時間都花在試圖解決這個問題。他們大多數仍然未能按時交付可運作的 AI 系統。

團隊告訴自己的故事

在企業 AI 團隊解釋失敗或停滯專案的方式中，有一個可預測的模式。這個故事經歷了幾個階段。

第一階段：樂觀。 試點獲批准。使用案例清晰。識別了資料來源。團隊選擇了模型、設置了基礎設施並開始工作。

第二階段：摩擦。 資料比預期的更混亂。檔案是管道無法解析的格式。標籤不一致。領域專家無法操作標注工具。合規審查標記了基於雲端的工具。時間表推遲。

第三階段：轉向。 面對進展緩慢，團隊嘗試不同的方法：不同的模型、不同的提示策略、更多計算、更多工程師。這些感覺像是行動。它們很少能解決實際問題。

第四階段：停滯。 幾次轉向後，專案超出預算、超出時間表、低於預期。原始資料問題沒有得到解決——它被繞過了，產生了技術債務和可靠性問題。

第五階段：事後分析。 結論通常是關於組織準備、模型限制或基礎設施挑戰的內容。如果有的話，只是簡短地提及底層資料問題。

資料問題在事後分析中被低估的原因是它感覺不像是策略失敗。它感覺像是執行失敗——一個骯髒、毫無光彩的問題，應該由團隊中的某人解決。承認資料準備階段是瓶頸感覺像是承認你沒有做基礎工作。所以團隊尋找更複雜的解釋。

為何模型被指責而資料才是原因

模型性能是最常見錯誤診斷的原因。

模型品質是可測量的。你可以計算準確度、F1、BLEU 分數、人類偏好評分。當模型表現不佳時，指標會清楚地告訴你。資料品質更難測量——尤其是在訓練之前，當問題是潛在的。

低品質的訓練資料產生的模型看起來在工作，直到它們不工作。在不一致標注的資料上訓練的模型看起來會學習，並產生看似合理的輸出。不一致性表現為性能上限——無論超參數如何變化，模型在某一點之後都不會更好。但這個上限從外面看起來像模型限制。團隊尋求更大的模型、不同的架構或更多訓練計算。這些都不起作用，因為它們都沒有解決根本原因。

同樣適用於資料量。認為自己有資料品質問題的團隊有時嘗試用資料量解決它：收集更多示例、生成合成資料、運行更多標注輪次。如果底層資料有雜訊或標注不一致，更多的資料只是放大了問題。模型在相同品質的更大資料集上訓練，產生相同（有時更差）的結果。

五種失敗模式

在我們合作過和交談過的組織中，企業 AI 在資料階段的失敗分為五種可識別的模式。

1. 在資料準備好之前開始

最常見的模式就是在訓練資料被充分準備之前開始模型訓練。這通常是時間表壓力問題：里程碑需要可展示的進度，「我們仍在準備資料」對利害關係人來說感覺不像進度。

結果是可預測的。團隊在不完美的資料上訓練，看到不完美的結果，在訓練而非資料上反覆迭代，並花費數月在由資料品質而非模型能力設定的上限上做邊際改進。

MIT Sloan 研究發現，獲勝的 AI 計劃顛倒了典型的支出比例，在任何訓練開始之前，將 50 到 70% 的專案時間表用於資料就緒。這令人不舒服，因為它延遲了可見輸出。它也顯著提高了成功率。

2. 碎片化工具堆疊

大多數企業團隊使用三到七個工具進行資料準備：用於攝入的文件解析器、用於標注的標注平台、用於清理的品質評分庫、可能用於擴充的合成資料工具。每個工具在單獨使用時都很有能力。它們之間的整合是失敗所在。

沒有共享資料格式意味著每個轉換點的自訂轉換代碼。沒有共享稽核軌跡意味著你無法通過單個血統報告證明合規性。當任何單個工具更新時，自訂膠合代碼就會崩潰。本應用於構建模型的 ML 工程師時間用於維護管道。

3. 沒有稽核軌跡

在受監管的行業——醫療保健、法律、金融服務、國防——AI 系統需要可證明的資料溯源。這個訓練示例來自哪裡？誰標注了它？它被修改了嗎？標注時使用的是哪個版本的標注架構？

大多數資料準備工具堆疊無法在整個管道中回答這些問題。個別工具可能有內部日誌，但沒有跨越從攝入到匯出的統一血統記錄。這不只是合規風險——它是品質信號。無法將訓練資料追溯到源文件的團隊無法自信地識別錯誤在哪裡進入了管道。

4. 領域專家差距

最有能力生成高品質標籤的人是領域專家：臨床資料的醫生、法律文件的律師、技術規格的工程師。可用於標注的工具是為資料科學家和 ML 工程師建立的——它們需要 Python 環境、Docker 設置、命令列熟悉度或複雜的 Web 應用程式配置。

結果是領域專家要麼完全被排除在標注過程之外（並被不那麼有資格判斷領域特定正確性的 ML 工程師取代），要麼他們需要大量支持才能使用工具，以至於領域專業知識的吞吐量優勢被設置和操作開銷所消耗。

5. 合規封鎖器

對於受監管的行業，雲端原生工具通常不被允許。HIPAA 限制患者資料可以在哪裡處理。GDPR 控制跨境資料傳輸。法律特權規則限制客戶文件處理。內部資訊安全政策增加了額外限制。

大多數商業資料準備工具是雲端原生的。受監管行業的團隊要麼接受合規風險（接受他們可能沒有完全了解的責任），要麼建立自己的工具（昂貴且緩慢），要麼退回到無法擴展的手動流程。

改變方法的樣子

成功駕馭企業 AI 採用的組織有幾個特徵，使他們與那些停滯的組織區別開來。

他們將資料準備視為主要專案階段，而非初步步驟。 他們不是將 10% 的專案時間用於資料、90% 用於模型開發，而是顛倒了這個比例。資料準備是里程碑。訓練是資料準備好時發生的事情。

他們在訓練之前測量資料品質。 這意味著對標注資料集進行品質稽核、檢查標籤一致性率、驗證訓練資料分佈是否與預期的生產分佈匹配，以及驗證解析品質在範圍內所有文件格式中是否足夠。

他們從一開始就讓領域專家參與標注。 這需要領域專家可以在沒有 ML 工程支持的情況下操作的工具——安裝得像應用程式而非開發環境的工具。領域專家標注的生產力和品質收益一致地超過工具設置投資。

他們在整個管道中建立單一稽核軌跡。 這不只是合規要求——它是工程衛生要求。能夠將任何訓練示例從源文件追溯到匯出，以及應用的每個轉換的記錄，對於調試模型失敗和滿足監管審計員至關重要。

他們在受監管環境中使用本地工具。 對於醫療保健、法律和金融服務組織，這不是可選的。它是從一開始就塑造每個工具選擇決定的限制。

關於企業 AI 時間表令人不舒服的真相

企業 AI 專案的時間表預期系統性地校準失誤。

當一個組織開始以在內部文件上微調模型為目標的企業 AI 專案時，典型的初始估計是三到六個月。現實的估計，考慮到資料準備階段，通常是九到十八個月——額外的時間幾乎完全在資料準備中。

這不是絕望的忠告。這是一個將工作前置的論點。分配現實時間進行資料準備並投資使這種準備高效的工具的團隊可以在九到十二個月內完成專案。試圖壓縮資料準備並過早開始訓練的團隊通常花費十二到二十四個月才能達到相同的品質閾值——或者他們永遠達不到。

數學並不複雜。以正確的順序做的紀律是困難的。

Your data is the bottleneck — not your models.

Ertas Data Suite turns unstructured enterprise files into AI-ready datasets — on-premise, air-gapped, with full audit trail. One platform replaces 3–7 tools.

Book a Discovery Call Learn about Ertas Data Suite →