企業 AI 資料管道建置的前 30 天

企業 AI 的時程表在投影片上看起來清晰整潔。分明的階段、流暢的箭頭，一切都按計劃進行。現實卻更加混亂。資料的格式沒有人記錄在案。存取授權需要一週而非一天。原本應該全職配合的領域專家，只有每週四兩個小時可以配合。

以下是建置企業 AI 資料管道前 30 天的逐週實況。不是理想化的版本——而是真實的版本，包括哪裡會出問題以及如何應對。

---

第一週：資料稽核與範圍界定

預計發生的事

前置部署工程師到場（實體或虛擬），與團隊會面，並對資料環境進行全面稽核。目標是回答三個問題：存在哪些資料？資料在哪裡？資料的狀態如何？

同時，工程師與 IT 部門合作，取得環境存取權：運算資源、網路憑證、儲存空間存取、安全許可。

實際發生的事

第 1-2 天：介紹與存取申請。 工程師與各利害關係人會面，了解系統概況，並提交存取申請。在大多數企業中，這是第一個延誤發生的地方。在受監管環境中，安全審查、背景調查和存取授權可能需要 2-5 個工作日。良好的專案會在正式啟動前的準備階段就開始申請存取權。

第 3-4 天：資料探索。 工程師開始繪製資料來源地圖。這幾乎總是出乎意料的。客戶在銷售過程中描述的資料，只是實際存在資料的一部分。還有其他資料庫、遺留的檔案共用、三年前已停用系統的匯出，以及某人桌面上包含關鍵參考資料的試算表。

常見的發現：

• 資料分散在比任何人意識到的更多系統中
• 即使在同一個來源內，檔案格式也不一致
• 中繼資料不完整或不可靠
• 資料量是估計的 3-10 倍
• 部分資料格式需要專用解析器（掃描的 PDF、專有資料庫匯出、大型主機提取檔案）

第 5 天：範圍調整。 根據資料稽核的實際發現，修訂在銷售過程中根據客戶描述所定義的原始範圍。這不是範圍蔓延——這是範圍修正。工作量本來就是這麼大；只是估算時尚未知曉。

哪裡會出問題

存取延誤是第一週最常見的問題。如果工程師無法存取資料系統，一切都會停滯。解決方案是在正式啟動專案之前就開始申請存取授權。

第二個最常見的問題：主要利害關係人（購買專案的人）對資料的理解，與實際使用資料的人不同。利害關係人說：「我們的合約都在 SharePoint 資料夾裡。」合約團隊說：「嗯，最近的合約在 SharePoint。2022 年之前的在舊文件管理系統。修訂版在電子郵件裡。」

---

第二週：管道架構與資料擷取測試

預計發生的事

根據第一週的稽核，工程師設計管道架構並開始建置擷取層——從來源系統將資料提取到準備環境的部分。

實際發生的事

第 6-7 天：架構設計。 工程師規劃管道：來源連接器、轉換步驟、標籤工作流程、匯出格式。這與客戶技術團隊一起審查。本週做出的架構決策——在哪裡處理、如何處理錯誤、記錄什麼——決定了管道長期的可維護性。

第 8-9 天：擷取建置與測試。 建置並測試第一批連接器。這是資料格式問題變得具體的地方。PDF 解析器對 90% 的文件有效，但對 10% 的掃描圖像失效。資料庫連接器成功提取記錄，但時間戳記有三種不同格式。CSV 匯出中嵌入的換行符破壞了解析器。

每個問題都可以解決。但每個問題都需要時間，而且會累積。有過這種經驗的工程師不會感到驚訝。第一次遇到的工程師會低估所需工作量 2-3 倍。

第 10 天：第一個端對端資料流。 到第二週結束時，原始資料應該從至少一個來源系統流入準備環境。它不會是乾淨的，也不會有標籤。但它會動起來，這就是一切建立的基礎。

哪裡會出問題

與遺留系統的整合問題是第二週最常見的問題。現代 API 是可預測的。遺留資料庫匯出、專有檔案格式和沒有文件的系統則不然。如果您的資料存在於超過 10 年的系統中，請預留額外的時間。

效能也可能令人驚訝。在 100 個測試文件上幾秒鐘就能處理完的管道，在 100,000 個生產文件上可能會卡住。第二週就是這些瓶頸變得可見的時候。

---

第三週：清理規則、標籤模式與領域專家導入

預計發生的事

隨著資料流入管道，焦點轉移到轉換：標準化資料的清理規則，以及領域專家將用來為模型訓練標注資料的標籤模式。

實際發生的事

第 11-13 天：清理與轉換規則。 工程師建立清理原始資料的規則：去重、標準化、處理缺失值、格式標準化、PII 偵測與刪除（如適用）。這是反覆進行的——規則被編寫、針對樣本資料測試、精煉，然後再次測試。

關鍵洞見：清理規則編碼了領域知識。「如果日期欄位包含 'TBD'，視為空值」是一個領域決策，而不是技術決策。這就是為什麼需要領域專家參與，而不只是工程師。

第 14-15 天：標籤模式設計。 工程師與領域專家合作定義標籤模式——將套用於資料的類別、標籤或標注。這是專案中在智識上最具挑戰性的部分。

好的標籤模式：

• 詳盡（涵蓋資料中的所有情況）
• 互斥（沒有模糊的重疊）
• 實用（標注者可以一致地套用標籤）
• 與下游模型任務對齊

壞的標籤模式事後看來很明顯，但在設計時卻不可見。「合約類型」看起來像個清晰的標籤，直到您遇到一份既是修訂版又是續約的文件。「嚴重程度」看起來很直觀，直到兩位領域專家對某個發現是「中等」還是「高」意見不一。

第 15 天繼續：領域專家導入。 領域專家在標注介面和標籤模式上接受培訓。他們標注一組樣本。測量標注者間一致性。如果一致性低，模式需要修訂。

哪裡會出問題

領域專家的可用性是第三週的關鍵風險。如果領域專家太忙而無法參與，標籤模式將由不了解領域的工程師設計，由此產生的訓練資料將是平庸的。

另一個常見問題：標籤模式分歧。不同的領域專家有不同的心智模型。資深律師與初級律師對合約的分類不同。心臟科醫師和放射科醫師對同一份影像報告的解讀不同。解決這些分歧需要時間和外交手腕。

---

第四週：驗證、品質指標與合規設置

預計發生的事

管道完成。第四週是關於測試、測量和文件記錄。

實際發生的事

第 16-18 天：管道驗證。 整個管道以生產規模的資料進行端對端執行。測量品質指標：

• 擷取完整性： 來源記錄成功擷取的百分比是多少？
• 清理準確性： 轉換產生正確結果的百分比是多少？
• 標籤品質： 標注者間一致性是多少？黃金標準樣本的精確率/召回率是多少？
• 匯出完整性： 輸出格式是否符合規格？下游 ML 框架能否無錯誤地擷取它？

目標因使用案例而異，但典型基準：99% 以上的擷取完整性、95% 以上的清理準確性、85% 以上的標注者間一致性（Cohen's kappa 超過 0.7）。

第 19 天：合規文件。 對於受監管行業，審查並記錄管道的稽核追蹤：資料血緣報告、存取日誌、轉換歷史、PII 處理記錄。這份文件是合規團隊最關心的交付物——也是最常被跳過或匆忙完成的。

第 20 天：交接與培訓。 工程師進行結構化交接：管道說明、設定文件、維護程序、故障排除指南。客戶的技術團隊應該能夠在這次會議之後獨立執行、監控和修改管道。

哪裡會出問題

驗證常常揭示需要修改管道的問題。在樣本資料上有效的清理規則，在規模上會產生不正確的結果。在設計過程中看起來清晰的標籤類別，在實踐中卻模糊不清。匯出格式有一個下游框架無法處理的邊緣情況。

這不是失敗。這正是驗證的目的。風險不在於問題浮現——而在於第四週沒有足夠的緩衝時間來解決問題。良好的專案計劃在第四週至少預留 2 天的返工時間。

---

第 30 天之後

管道上線。您的團隊擁有它。供應商的工程師可以提供 30-60 天的遠端支援，但系統是您的，由您來運營。

前 30 天是最難的。資料帶來的意外已經過去了。整合問題已解決。領域專家知道如何使用系統。從這裡開始，工作從建置轉向運營——執行管道、監控品質，並隨著需求的演變將其擴展到新的資料來源或使用案例。

---

規劃您的前 30 天

如果您正在為 AI 資料管道建置做準備，想了解您的具體資料和環境的第一個月會是什麼樣子，請與 Ertas 預約探索通話。我們將了解您的資料環境，標記可能出現的第一週意外，並為您提供一個現實的時程表——而不是投影片上的版本。