Back to blog
    27 個企業 AI 團隊告訴我們的資料準備問題
    researchdata-preparationenterprise-aithought-leadershipdiscoverysegment:enterprise

    27 個企業 AI 團隊告訴我們的資料準備問題

    基於跨受監管行業的 27 次探索通話,在微調、RAG 或代理甚至能開始之前,一個問題不斷浮現:資料準備。以下是我們聽到的內容。

    EErtas Team·

    我們在六個月內跨受監管行業進行了 27 次探索通話。對話涵蓋了工程和建築公司、醫療機構、法律事務所、金融服務團隊、設備端 AI 新創公司,以及為企業客戶構建的 AI 代理商。

    我們詢問了 AI 採用目標、當前工具、阻礙因素,以及時間實際花在哪裡。我們預期會有各種不同的答案,卻得到了一個一致到幾乎令人不安的模式。

    九個不同的 ICP 將資料準備命名為他們的第一大 AI 痛點——在我們直接詢問之前就主動說出來了。具體問題各不相同:文件格式、監管限制、標注複雜性、基礎設施限制。但根本原因始終相同:在原始業務資料和 AI 就緒訓練資料之間存在一個缺失的層,沒有人有好的答案來彌補它。

    以下是他們告訴我們的。

    我們交談的團隊

    27 次通話大致如下分佈:

    • 工程和建築公司(4 家): 管理大型文件檔案——工程量清單、規範、工程圖紙、專案報告——多年積累的 PDF、掃描文件和遺留格式資料。
    • 醫療機構(5 家): 臨床筆記、病患記錄、放射報告、計費資料。HIPAA 合規要求意味著雲端工具實際上不在考慮範圍內。
    • 法律事務所和法律科技公司(4 家): 合約庫、案件文件、監管申報。資料特權和客戶保密性制造了與醫療類似的限制。
    • 金融服務和金融科技(3 家): 交易記錄、合規文件、風險評估。監管稽核軌跡要求在標準 AI 工具之上增加了一層複雜性。
    • 設備端和邊緣 AI 公司(4 家): 構建設計為在本地硬體上運行的 AI 產品。他們自己的資料準備管道正在阻礙產品開發時間表。
    • AI 代理商(5 家): 為企業客戶構建 AI 系統。他們報告的問題通常是客戶問題的代理——他們自己在吸收資料準備複雜性。
    • 早期 AI 新創公司(2 家): 筆記、文件智慧、知識管理。較小的團隊,但同樣的資料問題,壓縮在創始人時間裡。

    在所有這些中,9 個團隊將資料準備命名為 AI 專案的主要瓶頸——在模型選擇、基礎設施或合規審查之前。在大多數情況下,他們已經解決了其他那些領域。資料是仍然存在的問題。

    「資料準備」對每個細分市場實際上意味著什麼

    更有趣的發現之一是,「資料準備」根據行業確實意味著不同的事情——但痛苦的體驗是相同的。

    對工程和建築公司而言,資料準備意味著將 700GB 的 PDF 規範、手繪工程文件和掃描工程量清單的檔案轉換為結構化資料,以訓練模型提取行項目、數量和成本估算。這些公司之一的 AI 負責人直白地說:

    「問題不在於微調,而在於清理和準備多樣化的資料。」

    多樣性是挑戰。單個專案可能涉及帶有嵌入式表格的 PDF、掃描藍圖、專有格式的 Excel 文件和手寫筆記。從那裡到乾淨的標注資料集,需要解析、標準化、去重和專家標注——沒有單一工具能夠處理整個鏈。

    對醫療團隊而言,資料準備意味著不同的事情:在任何處理開始之前進行 PHI 編輯,然後從用非標準速記撰寫的臨床筆記中提取結構,然後由不是資料科學家的臨床醫師進行標注。合規要求不是附帶的——它決定了哪些工具是允許的,哪些不是。

    對法律團隊而言,挑戰類似,但增加了特權的複雜性。你不能將客戶文件發送到雲端 API 來解析它們。你需要在本地運行的解析工具、領域專家(律師,而非 ML 工程師)實際上能夠操作的標注工具,以及能夠在法律揭露中存活的稽核軌跡。

    對邊緣 AI 公司而言,資料準備正在阻礙產品時間表。他們的問題是標注吞吐量——目標類別隨著產品發展而變化,標注工具需要 ML 工程才能操作,以及對工程師來說本質上是領域專家任務的依賴,正在使一切放緩。一家邊緣 AI 新創公司的團隊告訴我們:

    「資料標注是主要挑戰——目標類別頻繁變化。」

    最後那一點——目標類別頻繁變化——被低估了。在企業 AI 中,標注模式不是固定的,而是隨著團隊更多地了解問題而發展。每次變化時,標注工具都需要重新配置,這需要 ML 工程時間。這使問題是動態的,而不只是龐大的。

    對 AI 代理商而言,問題是他們自己在吸收客戶的資料問題。一位代理商創始人告訴我們:

    「企業醫療和法律領域的客戶更可能關心本地解決方案。」

    代理商不是直接處理資料——他們是在設計將要處理資料的系統。但客戶的本地需求塑造了每個技術決策,而可用工具的碎片化格局使設計過程比必要的難得多。

    五種資料準備問題類型

    在 27 次通話中,出現了五種截然不同的資料準備問題類別。大多數團隊至少有兩種,幾個有全部五種。

    1. 攝入問題

    原始資料以 AI 訓練管道無法直接消費的格式存在。PDF、掃描圖像、遺留資料庫匯出、專有文件格式、手寫文件。在任何清理或標注可以進行之前,這些文件需要被解析成結構化文本或結構化資料。

    這比聽起來難。適用於乾淨數字 PDF 的 PDF 解析在掃描文件上失敗。適用於印刷文本的 OCR 在手寫筆記上失敗。適用於簡單表格 PDF 的表格提取在複雜多列工程規範上失敗。典型企業文件檔案中的文件格式多樣性是巨大的,沒有單一解析工具能可靠地處理所有格式。

    2. 清理問題

    原始解析的文本是嘈雜的。OCR 錯誤、格式偽影、文件間的重複部分、跨團隊或時間段的不一致術語。在資料可以被標注之前,它需要被清理——而企業規模的清理需要大量手動工作或大多數團隊沒有的複雜工具。

    一家設備端 AI 公司的 CTO 很好地描述了標準期望:

    「使資料清理過程顯著更容易,即使只是 80% 自動化,也將是一個巨大的推動力。」

    注意「80%」——這不是對完美自動化的要求。團隊知道總是需要一些人工審閱。他們需要的是前 80% 不需要 ML 工程師撰寫自訂 Python 腳本。

    3. 標注問題

    對於監督學習和指令微調,資料需要被標注。最適合標注的人——領域專家——通常技術性不足,無法在沒有大量設置和支援的情況下操作可用的標注工具。這造成了 ML 工程師必須運行本應在領域專家時間上運行的標注管道的依賴。

    我們在醫療(需要標注臨床筆記的醫生)、法律(需要標注合約條款的律師)和建築(需要識別和分類工程量清單行項目的工程師)中遇到了這種模式。在每種情況下,標注工具本身是瓶頸,而非標注者的專業知識。

    4. 合規問題

    在受監管行業,資料無法移至雲端進行處理。HIPAA、GDPR、法律特權和內部資料治理政策都對資料可以去哪裡以及誰可以看到它施加了限制。大多數商業 AI 資料準備工具是雲端原生的。這意味著受監管的企業要麼接受合規風險、構建自己的工具,要麼退回到手動流程。

    一家網路安全公司用清晰的術語表達了這個限制:

    「大多數 AI 工具通過雲端處理推理,使資料基本上成為公開的。」

    這不是邊緣關切,而是大多數 AI 工具設計方式與受監管企業資料所在之間的結構性不相容。後果是受監管組織要麼以不同方式做 AI,要麼根本不做 AI。

    5. 整合問題

    對於已經組裝了工具鏈的團隊——這裡一個解析器、那裡一個標注工具、上面一個清理庫——問題是將它們拼接在一起。沒有共享資料格式,沒有共享稽核軌跡,在任何單個工具更新時崩潰的自訂膠水代碼,ML 工程時間花在維護管道而非構建模型上。

    這是從外面看起來已解決但在內部主動消耗資源的問題。一位筆記 AI 新創公司創始人簡單地告訴我們:

    「資料是最大的問題。」

    不是訓練,不是推理,不是部署。資料。他們已經嘗試了碎片化工具方法。

    為何模型訓練幾乎從未是陳述的問題

    當我們退後一步審視整體時,這是最讓我們驚訝的發現。

    模型訓練——在 AI 媒體中獲得最多關注、最多風險投資和最多工程人才的活動——很少被提及為瓶頸。團隊沒有說「我們需要更好的基礎模型」或「我們需要更好的訓練基礎設施」。他們說的是:我們無法開始訓練,因為我們的資料還沒準備好。

    這與更廣泛的研究一致。業界共識將 60% 到 80% 的 ML 專案時間放在資料準備上,而非模型訓練。Forrester 和 Capital One 對 500 位企業資料領導者進行調查,發現 73% 將資料品質和準備視為 AI 成功的第一大障礙。我們在 27 次通話中看到的模式,與研究在規模上顯示的一致。

    原因是結構性的:模型訓練在工具成熟、基礎設施存在、過程被充分理解的意義上是已解決的問題。資料準備不是已解決的。它在泛化工具處理不好的方面是特定領域、特定格式、特定合規和特定組織的。

    團隊目前在做什麼

    當我們詢問團隊目前如何處理資料準備時,答案分為三類:

    第一類:拼接工具鏈。 三到七個單獨工具,每個處理管道的一部分,通過 ML 工程師撰寫和維護的自訂代碼連接。最常見的堆疊:文件解析器(通常是 Docling 或 Unstructured.io)、標注工具(通常是 Label Studio)和清理庫(通常是 Cleanlab 或自訂腳本)。需要時的合成資料生成添加了 Distilabel 或類似工具。每個工具都有自己的設置、自己的資料格式、自己的維護負擔。

    第二類:手動流程。 在工具鏈方法遇到合規障礙的受監管行業中,團隊退回到試算表、手動審閱和逐個文件的處理。這有效,但在小型試點之外無法擴展。

    第三類:尚未開始。 幾個團隊根本還沒有開始資料準備。他們有 AI 採用目標,對所需訓練資料有粗略了解,在第一步就被阻礙了。工具格局過於碎片化、過於技術性,或過於依賴雲端,以至於他們找不到入口點。

    這些團隊沒有一個將其當前方法描述為令人滿意的。拼接工具鏈的團隊希望減少工程開銷。手動流程的團隊希望移動得更快。尚未開始的團隊希望有個起點。

    缺失的層

    27 次通話揭示了企業 AI 工具格局中缺失的清晰圖景:一個為受監管行業設計的統一本地資料準備環境。

    單個組件存在。文件解析器存在。標注工具存在。品質評分庫存在。不存在的——或在這些通話時不存在的——是一個單一環境,能夠處理完整管道(攝入、清理、標注、擴充、匯出),無需 ML 工程將工具粘合在一起,不在組織外部發送資料,也不要求領域專家學習操作開發者工具。

    這不是任何單個工具中的功能差距,而是生態系統尚未構建的一個層。

    對企業 AI 採用的影響

    這 27 次通話描繪的圖景,是一個限制因素很少是媒體關注焦點的企業 AI 格局。不是模型能力,不是計算可用性,不是組織意願。

    而是組織擁有的資料與 AI 系統所需的資料之間的差距——以及在受監管的本地環境中設計用來縮小這一差距的工具的缺失。

    目前陷入停滯的 65% 企業 AI 部署,大多數在這個層面上停滯。成功的組織要麼大量投資 ML 工程來構建和維護自訂管道,要麼在雲端工具可接受且資料已經相對乾淨的細分市場中運作。

    對於其他人——受監管行業、擁有複雜文件檔案的組織、需要領域專家參與標注的團隊——工具差距是真實的。清晰地承認它是縮小它的第一步。


    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.

    相關閱讀

    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