本地端資料準備管道中的多客戶專案隔離

當你為一個企業客戶提供資料準備服務時，隔離很簡單——只有一個資料集。當你同時管理五個、十個或二十個客戶專案時，隔離就成為一個運營問題，如果處理不好，會產生法律、合規和品質風險。

這是一份面向同時為多個企業客戶運行本地端資料準備管道的 ML 服務提供商的技術指南。它涵蓋隔離為何重要、存在哪些方法，以及如何在不隨客戶數量線性擴展的運營開銷下實施專案分離。

為什麼客戶隔離很重要

法律分離

每個企業客戶合約都在合約下運作——MSA、SOW、NDA 或全部三者。這些合約通常規定客戶的資料不會與其他客戶的資料混合。如果客戶 A 的訓練資料意外地包含在客戶 B 的匯出中，你就違反了合約。在受監管的行業，這也可能是監管違規。

資料保密性

企業資料默認是保密的。醫療保健客戶的臨床記錄、律師事務所的特許文件、金融機構的交易記錄——這些都不應該對在不同客戶專案上工作的人可見。即使在你自己的團隊中，存取也應該限定在專案範圍內。

訓練資料交叉污染

這是容易被低估的技術風險。如果來自客戶 A 的資料洩漏到客戶 B 的訓練資料集中，生成的模型就被污染了。它可能包含來自客戶 A 領域的模式、術語或信息。這不是假設性的——當管道共享中間存儲、當匯出腳本從錯誤的專案目錄提取，或當標記隊列沒有正確過濾時，就會發生這種情況。

稽核追蹤獨立性

每個客戶的資料沿襲必須是獨立可匯出的。當客戶 A 要求顯示應用於其資料的每個轉換的稽核報告時，該報告必須只包含其資料——不引用其他客戶、沒有共享處理日誌、沒有模糊的來源記錄。

客戶隔離的方法

每個客戶單獨安裝

最保守的方法：為每個客戶安裝完全獨立的每個工具實例。單獨的機器、單獨的存儲、單獨的用戶帳號。

優點： 最大隔離。沒有共享狀態、沒有共享存儲、沒有共享配置。

缺點： 運營開銷線性擴展。十個客戶意味著十個安裝需要維護、十組更新需要應用、十個環境需要監控。對於管理許多專案的小型團隊，這變得難以操作。

單一工具內的專案級隔離

帶內置專案分離的單一安裝：每個客戶的資料存在於命名的、隔離的專案中。專案不共享資料、標籤、配置或匯出輸出。用戶被指派到具有明確權限的專案。

優點： 運營開銷無論客戶數量如何都是恆定的。一個安裝需要維護。一組更新。專案切換很快。

缺點： 需要工具在專案級別實際執行隔離——不僅僅在 UI 中，而且在存儲層和稽核追蹤中。並非所有工具都這樣做。

RBAC（基於角色的存取控制）

在共享基礎設施之上疊加存取控制。用戶只看到他們被授權存取的專案。管理員看到所有專案。

優點： 靈活。支援一些人跨多個客戶工作的團隊結構。

缺點： RBAC 本身不能防止管道級別的資料交叉污染。它防止未授權的 UI 存取，但如果底層管道共享存儲或處理隊列，RBAC 是一個 UI 護欄，而不是資料隔離保證。

檔案系統隔離

每個客戶的資料存在於單獨的檔案系統路徑、分區或磁碟區中。管道腳本被參數化以在特定路徑上操作。

優點： 實施簡單。適用於任何工具。

缺點： 依賴紀律。一個配置錯誤的路徑參數，資料就會在專案之間洩漏。沒有內置強制執行——隔離只與團隊的注意力一樣好。

運營挑戰：5-20 個同時進行的專案

大多數 ML 服務提供商在從 2-3 個並發專案擴展到 5-20 個時遇到隔離問題。在這種規模下，單獨安裝的每個客戶開銷變得昂貴，但共享基礎設施方法的風險變得真實。

實際問題是：你如何管理 15 個客戶專案而不需要 15 個獨立環境，同時仍然保證客戶 A 的資料永遠不會接觸客戶 B 的管道？

這需要工具原生隔離——不是加在上面的檔案系統約定或 RBAC 覆蓋層，而是構建到工具資料模型中的隔離。每個專案應該是一個具有以下自己特性的一等實體：

資料存儲（攝取的文件、中間轉換、最終匯出）
標記配置（分類法、指南、標記員分配）
管道配置（清理規則、增強設置、匯出格式）
稽核追蹤（僅針對該專案的獨立可匯出沿襲）
命名（客戶標籤、專案識別符、合約參考）

自製隔離 vs 工具原生隔離

維度	自製（Docker + 腳本）	工具原生隔離
每個專案設置時間	2-4 小時（容器配置、磁碟區掛載、腳本參數化）	幾分鐘（創建專案、分配團隊）
交叉污染風險	中等（取決於腳本正確性）	低（由工具架構強制執行）
每個客戶的稽核追蹤	自訂（必須構建匯出邏輯）	內置（每個專案的沿襲匯出）
10 個專案時的維護	高（10 個容器、10 個配置）	低（一個安裝，10 個專案）
團隊背景切換	慢（切換容器、重新加載狀態）	快（在工具中切換專案）
合規證據	必須從日誌中組裝	每個專案的單一報告

自製方法在小規模有效。當並發專案數量超過團隊可靠維護基礎設施的能力時，它就會崩潰。

稽核追蹤要求

對於受監管行業的企業客戶，稽核追蹤不是可選的——它是一個可交付物。每個客戶需要看到：

什麼資料進入管道——源文件、格式、時間戳
應用了什麼轉換——清理規則、遮蔽步驟、增強操作
誰應用了它們——手動步驟（如標記）的用戶歸屬
什麼資料被匯出——輸出文件、格式、時間戳、行數
什麼被排除及原因——未通過品質檢查的記錄、無法解析的文件

這個沿襲必須可以在不引用其他客戶的資料或操作的情況下按客戶匯出。如果你的稽核追蹤是涵蓋所有專案的單一日誌文件，你需要在交給客戶之前進行過濾和遮蔽——這本身就引入了自己的錯誤風險。

在實踐中實施隔離

如果你自己構建這個，這是最低可行的隔離架構：

每個客戶專案一個目錄根。 所有資料——原始的、中間的和匯出的——都存在於那個根下。沒有任何東西與其他專案根共享。
每個專案的管道配置。 清理規則、標記分類法和匯出設置存儲在專案目錄中，而不是全局存儲。
每個專案的稽核日誌。 每個操作都記錄到專案目錄中的文件。全局日誌應該引用專案 ID，但不包含來自專案本身的資料。
存取範圍化。 團隊成員被分配到專案。他們的工具和儀表板只顯示他們被分配到的專案。
匯出驗證。 在向客戶交付資料集之前，驗證匯出中的每條記錄都追溯到正確的專案根，且不包含外來記錄。

這可以通過自訂基礎設施實現。它也是 Ertas Data Suite 等工具原生處理的那種管道工作。Ertas 支援帶有客戶標記專案的多專案管理、每個專案的稽核追蹤和內置資料沿襲——所有這些都在本地端運行，無需網路依賴。對於管理許多並發合約的服務提供商，這消除了否則需要自訂工程的隔離基礎設施。

適用場景

客戶隔離是資料準備服務實踐的運營基礎。沒有它，從幾個客戶擴展到許多客戶會引入不可接受的風險。有了它，並發專案的數量受限於團隊能力，而不是基礎設施限制。