Data-Juicer：把資料清理變成可組合的基礎設施，但先看清楚它的邊界

它解決的不是「清洗資料」，而是「清洗資料的流程」

多數團隊處理 LLM 訓練資料時，用的是散落的 Python 腳本：一個去重、一個過濾、一個正規化，每個都獨立維護，參數寫死在程式碼裡。Data-Juicer 把這個過程重新框架成可組合的基礎設施。它的核心抽象是運算子，超過 200 個，涵蓋文字、圖片、音訊、影片與多模態資料。運算子分為 filter 與 mapper 兩類，前者篩選樣本，後者轉換內容。你可以單獨用一個運算子，也可以串成管線，或把整條管線寫成 YAML recipe。Recipe 可以像程式碼一樣版本化、分享、fork，這是它與臨時腳本最根本的差異。它的目標使用者不是偶爾清理一次 CSV 的資料分析師，而是需要重複處理大量語料、且流程必須可重現的工程團隊。文件裡提到它涵蓋預訓練、微調、RL、評估級資料整理，也涵蓋 agent 互動軌跡清理與 RAG 索引準備，這表示它把自己定位在整個 AI 生命週期，而不只是某一個階段。

NestedDataset 與 process 方法：管線的實際運作方式

從 README 的 Python 範例可以看出 Data-Juicer 的資料流設計。它使用 NestedDataset，這不是單純的 HuggingFace Dataset 包裝，而是支援巢狀結構的資料集，因為多模態資料常有巢狀欄位，例如一段文字對應多張圖片。你從 dict 建立資料集，然後呼叫 ds.process，傳入一個運算子列表。process 會依序套用每個運算子，filter 決定樣本去留，mapper 改變樣本內容。範例中 TextLengthFilter(min_len=10) 會丟棄短於 10 個字元的文字，WhitespaceNormalizationMapper 則把連續空白縮減為單一空格。這個設計讓運算子可以任意組合，不需要為每個新流程寫新的迴圈。值得注意的是，process 的執行順序就是列表順序，這表示你必須自己想清楚 filter 與 mapper 的先後關係。例如先做 whitespace normalization 再做 length filter，跟反過來，結果可能不同。文件沒有提到自動排序或依賴分析，所以這是一個需要使用者自行承擔的責任。

YAML recipe 與 dj-process：從互動到批次執行的距離

除了 Python API，Data-Juicer 提供命令列工具 dj-process。安裝方式很直接：uv pip install py-data-juicer，然後 dj-process --config demos/process_simple/process.yaml。這表示管線設定完全由 YAML 檔案驅動，Python 程式碼只是載入與執行。Recipe-first 是它反覆強調的設計哲學。YAML 裡應該包含運算子名稱、參數、執行順序、輸出路徑等。v1.6.0 加入了 config validation，會在處理前檢查無效的運算子設定，以及 executor 與 schema 的不匹配。這是一個重要的改進，因為資料處理管線最常出的錯就是參數拼錯或型別不對，等到跑完幾百 GB 才發現。但文件也說 reader 的預設值現在會一致地套用到執行與分析，這暗示之前可能有執行與分析行為不一致的問題。對新使用者來說，第一個門檻是理解 YAML 的 schema，例如 filter 的 min_len 是包含還是排除邊界。文件沒有提供完整的 YAML 範例，只有 demos 目錄的路徑，所以實際使用時你必須去翻範例檔。

規模宣稱背後的條件：70B 樣本與 5TB 去重

README 給出兩個具體數字：在 50 個 Ray 節點、6400 核心上，2 小時處理 70B 樣本；用 1280 核心在 2.8 小時內去重 5TB 資料。這些數字寫在專案自己的說明裡，不是獨立評測。它們的意義在於顯示 Data-Juicer 是為 Ray 叢集設計的，不是單機工具。v1.6.0 的 cluster-aware partitioning 讓分割數量自動根據 Ray 叢集的即時資源決定，這解決了手動設定 partition 數量時可能浪費資源或負載不均的問題。v1.5.5 加入了 HDFS I/O 與 Ray Data 最佳化，v1.5.4 有 batch-local stage fusion，這些都指向同一個方向：這個專案在持續降低大規模處理的開銷。但對多數讀者來說，真正該問的問題是：你的資料量有沒有大到需要 Ray？如果你的語料是幾 GB 到幾十 GB，單機 pandas 或 Spark 可能更簡單。Data-Juicer 的複雜度來自 Ray 的部署與管理，如果你沒有叢集，它的優勢就無從發揮。

Juicer 模型：自然語言指令與結構化輸出的橋樑，但依賴外部服務

v1.6.0 釋出了 Juicer 模型，這是一個 35B 參數的模型（Juicer-35B-A3B），部署在 HuggingFace 與 ModelScope。它的用途是把清理指令、過濾規則、語意標註需求轉成結構化輸出。換句話說，你可以用自然語言描述「把含有 email 的樣本移除」，Juicer 可能幫你產生對應的運算子設定或直接輸出結構化規則。這是一個有趣的設計，因為它把資料處理的介面從程式碼提升到語言層級。但這裡有幾個實際限制。第一，35B 參數的模型即使是 A3B（active 3B）也需要相當的 GPU 記憶體，不是每台筆電都跑得動。第二，如果你透過 API 呼叫，資料會離開你的環境，這對敏感資料可能是問題。第三，模型輸出需要驗證，你不能假設它產生的規則永遠正確。文件提到 LiteLLM backend 可以讓 prepare_api_model 選擇不同 provider，但 OpenAI-compatible backend 仍是預設。這表示 Juicer 的整合還在早期，不同 backend 的行為差異需要實測。

v1.6.0 的熱修復清單：哪些地方容易出錯

每個版本的 release notes 都是學習專案弱點的好材料。v1.6.0 的 robustness fixes 提到 fused-filter cache isolation、MinHash state reuse 與 empty inputs、deduplicator execution-mode declarations、empty text chunks、gzip JSONL HPO sampling、pandas extension-dtype handling。這些聽起來都很技術性，但它們揭露了幾個真實的失敗模式。MinHash state reuse 表示去重運算子可能在多次執行之間共用狀態，導致結果不正確。empty text chunks 表示某些 filter 可能沒有處理空字串。pandas extension-dtype 表示當資料來源是 pandas DataFrame 且有特殊型別時，可能出錯。對採用者來說，這些修復代表你必須謹慎對待邊界情況。如果你的資料有空值、極短文字、或來自 pandas 的 nullable 型別，你應該在正式跑之前用小樣本測試。另外，config validation 是 v1.6.0 才加入的，這表示之前版本可能讓錯誤設定跑到一半才失敗。如果你要升級，這些修復是升級的理由，但它們也提醒你：這個專案還在快速變動，行為可能在不同版本間改變。

替代方案與真正的差異：不是所有資料工具都走 recipe 路線

Data-Juicer 最接近的替代品是 HuggingFace 的 datasets 函式庫加上自訂處理腳本，或是 Apache Spark 的資料轉換。HuggingFace datasets 提供 map、filter、select 等方法，也能處理大量資料，但它沒有 Data-Juicer 那種 200 多個預建運算子的生態系。你用 datasets 時，去重、語意過濾、多模態對齊這些邏輯都得自己寫。Spark 則擅長超大規模分散式處理，但它對非結構化文字與多模態資料的支援較原始，你需要自己實作許多 NLP 相關的轉換。Data-Juicer 的差異在於它把「資料處理的領域知識」封裝成運算子，例如 image_ohem_selector 這種針對高損失影像樣本的選擇器，這在通用資料工具裡不會出現。另一個差異是 recipe 的版本控制：YAML 檔可以放進 git，但 Spark 或 datasets 的處理邏輯通常散在程式碼裡。如果你需要的是可稽核、可重現的資料處理流程，Data-Juicer 的 recipe 是真正的優勢。但如果你只需要簡單的過濾與正規化，datasets 的學習曲線更低。

授權與維護成本：Apache-2.0 的彈性與快速變動的風險

Data-Juicer 採用 Apache-2.0 授權，這表示你可以自由使用、修改、商用，只要保留著作權聲明。這對企業採用是友善的，沒有 copyleft 的包袱。但授權寬鬆不代表維護成本低。最後一次 push 是 2026-09-09，v1.6.0 在 2026-09-09 釋出，v1.5.5 在 2026-08-07，v1.5.4 在 2026-07-23。這表示專案大約每個月有一個 minor release，變動速度很快。快速釋出有兩個含義：第一，bug 修復很快，例如 v1.5.4 的 robustness fixes；第二，API 可能不穩定，運算子行為可能改變。文件提到「documentation refresh」與「added documentation for 28 existing operators」，這暗示之前有許多運算子沒有文件，你必須讀原始碼才能理解參數。對一個 200 多個運算子的專案來說，文件覆蓋率是實際的維護成本。另外，v1.5.5 加入 external OP plugins，這表示你可以寫自己的運算子並動態載入，但 plugin 的 API 穩定性沒有保證。如果你要長期使用，你應該固定版本，不要追最新，並在升級前閱讀 release notes 中的 robustness fixes。

編輯結論

Data-Juicer 適合已經有明確資料處理需求、願意用 YAML recipe 把流程程式碼化的團隊，尤其是要處理文字、圖片、音訊、影片混合資料的人。它不適合只想快速跑一次簡單清理、不想學習運算子語義與 Ray 部署的個人使用者，也不適合對資料隱私極度敏感、不能把資料送到外部 API 的場合。採用前應先驗證三件事：第一，你需要的運算子是否存在於 200 多個清單中，文件說有 28 個運算子是新補的文件，舊的運算子可能文件不足；第二，v1.6.0 的 config validation 是否真的能攔截你的設定錯誤，因為它只檢查「invalid operator settings」與 executor/schema mismatch，不保證語意正確；第三，如果你要用 Juicer 模型做自然語言指令轉結構化輸出，先確認它的 HuggingFace 或 ModelScope 部署成本與延遲是否符合你的管線預算。Data-Juicer 的價值在於把資料處理從一次性腳本變成可版本控制的 recipe，但它的規模數字與效率宣稱來自專案自己的 README，不是第三方基準，你必須用自己的資料與叢集重新測量。

官方來源

1. datajuicer/data-juicer on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases