跨職能 AI 資料團隊：ML 工程師 + 領域專家 + 合規

大多數企業 AI 資料準備工作由一個職能部門負責：ML 工程師團隊。他們設計管道、解析文件、標記資料（通常標記得很差，因為缺乏領域專業知識）、檢查品質（僅針對技術指標），以及匯出資料集。領域專家偶爾被諮詢。合規人員在最後審查一次輸出，並且常常要求需要返工的修改。

這種單職能方法產生三種可預測的失敗：

技術上正確但領域不準確的資料集。 標記醫療記錄的 ML 工程師會正確識別「SOB」是縮寫，但可能不知道在臨床上下文中它意味著「呼吸急促」。在這些標籤上訓練的模型在技術上是功能性的，但在臨床上是錯誤的。

準確的標籤但無法擴展。 當領域專家被引入時，他們產生高品質的標籤，但無法維持所需的量。在週二標記 20 個示例然後消失三週的心臟科醫生，不是一個可擴展的資料操作。

迫使返工的合規審查。 當合規官審查完成的資料集，發現 PII 沒有得到適當處理，或資料來源文件不完整時，整個管道必須重新運行。這種返工通常花費 3 至 6 週。

解決方案不是職能之間的順序交接——而是一個跨職能團隊，其中 ML 工程師、領域專家和合規官同時在資料準備管道上工作，具有明確的角色和適當的工具。

三個角色

ML 工程師：管道架構師

ML 工程師在資料準備中的角色是架構和自動化，而不是手動資料工作。

職責：

• 設計資料準備管道：擷取 → 解析 → 標記 → 品質 → 匯出
• 配置品質指標和閾值（標注者間一致率目標、去重比率、類別平衡要求）
• 設置自動化：從資料源自動擷取、對傳入資料的自動品質檢查、自動匯出排程
• 建立和維護以所需格式生成訓練就緒資料集的匯出配置
• 監控管道健康：吞吐量、錯誤率、處理延遲
• 分析品質指標並識別系統性問題（標注者分歧模式、資料分佈偏移）

他們不應該做什麼：

• 標記資料。他們缺乏領域專業知識，他們的時間最好花在工程上。
• 定義標記指南。他們對領域了解不夠深入。
• 做出合規決策。他們不知道監管要求。

時間分配： ML 工程師 30 至 40% 的項目時間應用於管道架構和監控。其餘 60 至 70% 用於模型訓練、評估和部署。如果他們在資料管道工作上花費超過 40%，管道需要更多自動化。

領域專家：準確性權威

領域專家的角色是確保資料集根據其專業標準是正確的。

職責：

• 撰寫反映專業標準和領域知識的標記指南
• 標記示例——通常每天 20 至 30 分鐘，每次會話產生 15 至 30 個標記示例
• 審查其他標注人員標籤的樣本以確保品質（如果涉及多個標注人員）
• 識別管道處理有誤的邊緣案例——文件類型、術語或自動步驟弄錯的場景
• 根據專業標準驗證最終資料集：「我是否信任在這些資料上訓練的模型來處理我的案例？」

他們不應該做什麼：

• 配置管道。他們不需要知道文件如何被解析或資料如何被匯出。
• 定義品質指標。他們應該驗證 ML 工程師選擇的指標是否有意義，但定義 Cohen's kappa 閾值不是他們的責任。
• 處理合規文件。他們產生標記資料；合規人員追蹤治理。

時間分配： 活躍標記階段每天 20 至 30 分鐘。品質驗證階段的定期審查會話（每週 1 至 2 小時）。這對繁忙的專業人士來說是可持續的，並且對大多數項目產生足夠的量。

合規官：治理守護者

合規官的角色是確保資料準備管道符合監管和組織政策要求。

職責：

• 驗證審計追蹤是完整的：每個文件的來源、每個轉換、每個標記決定都被追蹤
• 審查資料治理政策：資料保留、存取控制、刪除權、跨境傳輸限制
• 確保 PII/PHI 處理符合適用法規（GDPR、HIPAA、歐盟 AI 法案第 10 條）
• 在資料集用於訓練之前審查和批准資料來源文件
• 驗證存取控制：誰可以看到哪些資料，誰可以修改標籤，誰可以匯出資料集

他們不應該做什麼：

• 標記資料。他們沒有領域專業知識。
• 設計管道。他們指定要求；ML 工程師實施這些要求。
• 等到最後才審查。到那時，合規問題已嵌入整個資料集，補救工作代價高昂。

時間分配： 活躍資料準備期間每週 2 至 4 小時。在初始管道設置期間（配置治理政策時）和在資料集匯出前最終審查期間，時間更高。

團隊結構選項

嵌入式小組（推薦用於 1 至 3 個項目）

專門用於特定 AI 項目的單個跨職能團隊。小組包括：

• 1 名 ML 工程師（項目全職）
• 2 至 3 名領域專家（兼職，每天 30 分鐘）
• 1 名合規官（兼職，跨 2 至 3 個小組共享）

優勢： 緊密溝通、快速決策、明確的責任。團隊坐在一起（實體或虛擬）並實時解決問題。

劣勢： 超過 3 至 4 個項目後，需要複製 ML 工程師和合規人員配置，才能擴展。

矩陣模型（用於 4 至 10 個項目）

職能團隊（ML 工程、領域專業知識、合規）為資料準備項目貢獻成員。ML 工程師可能同時支援兩個資料準備項目。

優勢： 更有效地使用專業人才。ML 工程師和合規官跨項目共享。

劣勢： 注意力分散。支援兩個項目的 ML 工程師優先考慮其中一個，另一個停滯不前。需要強大的項目管理來防止這種情況。

緩解措施： 錯開項目階段。如果項目 A 處於標記階段（ML 工程師需求低），而項目 B 處於管道設置（ML 工程師需求高），同一工程師可以支援兩者。

中心輻射式（用於 10 個以上項目或持續操作）

由 2 至 4 名 ML 工程師和 1 名合規官組成的中央資料操作團隊（中心）維護資料準備平台並處理管道架構。來自整個組織的領域專家貢獻者（輻射）根據項目參與標記和審查。

優勢： 可擴展到多個項目。中心團隊在資料準備方面發展深厚的專業知識。領域專家只在需要其特定知識時才被引入。

劣勢： 中心團隊可能成為瓶頸。領域專家感覺主人翁意識不強，因為他們在過程中處於邊緣。

緩解措施： 自助標記。中心團隊設置項目並配置品質檢查，然後領域專家獨立存取其標記佇列，無需中心團隊的參與。

溝通節奏

資料準備團隊的每日站會是浪費的。資料準備工作在很大程度上是獨立的——標注人員標記示例，ML 工程師監控品質，合規官審查文件。沒有足夠的內容可以每天討論。

每週同步（30 分鐘）： 三個角色每週開一次會審查：

• 標記進度：本週標記的示例、品質指標趨勢
• 管道問題：解析錯誤、品質檢查失敗、標注人員問題
• 合規狀態：任何新要求、審計追蹤完整性
• 下週的優先事項

非同步審查頻道： 用於即時問題的 Slack/Teams 頻道。領域專家發佈模糊示例（「我應該如何標記這個？」）。ML 工程師發佈品質指標警報。合規官標記文件空白。

每月回顧（1 小時）： 審查整個資料準備過程。什麼有效？什麼慢？瓶頸在哪裡？這是識別和規劃過程改進的地方。

衝突解決

三個角色之間存在需要明確解決機制的自然張力。

「更多資料」vs.「最小化資料」

ML 工程師希望更多訓練示例以提高模型性能。合規官希望最小化資料收集和保留。兩者在各自領域都是正確的。

解決方案： 定義最低可行資料集——實現性能目標的最小資料集。收集那個量，加上 20% 的緩衝用於品質過濾。記錄收集量的理由。這滿足了 ML 工程師的性能需求，同時符合合規官的資料最小化要求。

「速度」vs.「品質」

ML 工程師希望快速推進——「這週標記 1,000 個示例然後開始訓練。」領域專家堅持仔細審查——「我需要思考每個示例。」

解決方案： 設定標記會話的時間限制（每天 20 分鐘），但設置在訓練開始前必須達到的品質閾值。這防止了兩個極端：ML 工程師無法在品質標準之前倉促完成標記，領域專家也無法通過每個示例花費 15 分鐘來無限期地延遲項目。

「全面文件記錄」vs.「快速交付」

合規官希望對每個資料處理決策進行完整的文件記錄。ML 工程師希望訓練模型並迭代。

解決方案： 將文件記錄融入工具，而不是單獨的過程。如果平台自動記錄誰標記了什麼、何時標記的，以及資料如何在管道中流動，合規文件就作為工作的副產品生成——而不是作為增加摩擦的額外步驟。

擴展模型

隨著組織成熟，跨職能團隊模型也在演變：

第 1 階段（第一個項目）： 臨時跨職能協作。ML 工程師聯繫願意合作的領域專家。合規人員在最後審查。這在第一次有效。

第 2 階段（2 至 5 個項目）： 具有明確角色和溝通節奏的正式化嵌入式小組。合規從一開始就參與。標記指南被記錄和重用。

第 3 階段（5 至 15 個項目）： 中心輻射式模型。中央資料操作團隊、領域專家貢獻者網路、共享合規官。標準化的工作流程和模板。

第 4 階段（15 個以上項目）： 資料準備即服務。中央團隊操作平台，管理品質標準，並為項目團隊提供自助能力，讓他們在治理護欄內設置自己的資料準備工作流程。

每個階段需要不同的工具能力。第 1 階段可以使用基本工具。第 3 至 4 階段需要帶有基於角色的存取控制、工作流程模板、自動品質監控和合規報告的平台——全部在一個系統中。

Ertas Data Suite 支援所有三個角色的基於角色的工作流程。ML 工程師配置管道、品質指標和匯出設置。領域專家存取為非技術使用者設計的簡化標記界面——無需代碼、無需終端機、無需設置。合規官存取審計追蹤、資料來源報告和存取控制儀表板。每個角色只看到他們需要的內容，具有適當的權限。平台在本地運行，提供合規官要求的資料駐留保證。

---

延伸閱讀

• ML 團隊中的資料準備差距 — ML 團隊為何在資料準備中掙扎，以及組織結構如何導致這個問題。
• 領域專家被鎖在 AI 資料之外 — 現有工具如何排除 AI 最需要其知識的人。
• 企業 AI 資料準備指南 — 企業 AI 項目完整資料準備生命週期的全面演練。