反對在企業數據準備中使用 Python 的理由

Python 是訓練機器學習模型的正確工具。它擁有最好的 ML 庫、最大的研究社群，以及最成熟的模型開發生態系統。本文不是關於用於模型訓練的 Python。

本文是關於用於數據準備的 Python——訓練數據集的標注、清洗、格式化、驗證和整理。在這種情況下，Python 會積極地損害企業 AI 項目。它把本應做這項工作的人排除在外，創造了拖慢項目的維護負擔，並引入了完全可以避免的失敗模式。

可及性問題

反對使用 Python 進行數據準備最直接的論點是算術。在一個有 AI 計劃的典型企業中：

• 2-5 人可以編寫 Python
• 20-100 人具備正確準備數據的領域專業知識

當數據準備需要 Python 時，95% 有能力做這項工作的人無法參與。剩下的 5% 成為組織中每個 AI 項目的瓶頸。

這不是關於 Python 難以學習。這是關於學習 Python 需要 3-6 個月才能達到數據工程任務所需的熟練程度——不是「打印 hello world」的熟練程度，而是「解析不規則的 CSV、處理編碼問題、管理數據框操作和調試神秘錯誤消息」的熟練程度。

沒有任何組織會讓 50 個領域專家通過 6 個月的 Python 培訓項目，只是為了讓他們標注數據。這在經濟上行不通。將臨床醫生、律師或工程師從他們的主要角色中抽出幾個月的機會成本是巨大的。而在培訓結束時，大多數人仍然是產出脆弱代碼的新手程序員。

替代方案很簡單：使用不需要代碼的工具。

維護噩夢

Python 數據準備腳本有半衰期。它們在編寫時有效，然後迅速退化。

依賴腐爛。 一月份編寫的數據準備腳本使用 pandas 2.1、numpy 1.26 和自定義解析庫的特定版本。到六月，pandas 發布了 2.2，其中對腳本依賴的方法進行了破壞性更改。numpy 版本與更新的 pandas 不再相容。自定義庫已被重構。運行原始腳本會產生錯誤或靜默的不同結果。

我們在 2025 年調查了 30 個企業 ML 團隊。其中 23 個報告了至少一個事件，其中一個以前工作正常的數據準備腳本在依賴更新後產生了不同的結果。其中 8 個直到在損壞的數據上訓練模型之後才發現不一致。

部落知識。 數據準備腳本積累了只存在於作者腦海中的隱式假設。為什麼第 47 行跳過 C 列為空的行？因為原始作者知道空的 C 列表示來自特定源系統的不完整數據輸入——但這沒有文件記錄。當另一個工程師六個月後修改腳本時，他們移除了跳過，因為它看起來像個 bug。訓練數據現在被不完整的記錄污染了。

筆記本無序。 Jupyter 筆記本是數據準備最常見的環境，它們隨著時間的推移有複合的結構性問題：

• 儲存格執行順序沒有強制執行。亂序運行儲存格會產生不同的結果。
• 變量狀態在儲存格之間持續存在，創建不可見的依賴關係。
• 筆記本無法通過標準差異工具進行有意義的代碼審查。
• 版本控制將整個筆記本視為單個 blob，使更改追蹤不切實際。

微軟研究院 2024 年的一項研究發現，GitHub 上 36% 的 Jupyter 筆記本無法從頭到尾成功執行。在企業環境中，筆記本在擁有不同環境的團隊成員之間共享，失敗率更高。

無稽核追蹤。 當數據準備在 Python 腳本和筆記本中進行時，沒有關於對數據應用了哪些操作、以什麼順序、由誰、使用什麼參數的結構化日誌。如果模型產生意外結果，團隊需要追溯問題到數據準備步驟，他們必須閱讀代碼、重建執行歷史，並希望筆記本的儲存格執行順序與實際發生的情況相符。

可重現性問題

Python 中的可重現性依賴於環境管理——虛擬環境、conda 環境、requirements.txt、lock 文件。理論上，這些工具確保相同的代碼產生相同的結果。在實踐中，企業環境定期打破這個約定。

系統級依賴。 一些 Python 庫依賴於系統包（libffi、openssl、用於文字處理的 ICU）。不同的操作系統，或同一操作系統的不同版本，提供這些包的不同版本。在數據科學家的 MacBook 上工作的腳本在 Ubuntu 服務器上產生不同的文字標準化結果，因為 ICU 版本不同。

硬體相關行為。 浮點算術在不同 CPU 架構之間有所不同。涉及數值操作的數據準備步驟（標準化、閾值計算、統計過濾）可以在不同硬體上產生微妙的不同結果。這些差異通常在小數點後第 15 位——但它們可以通過管線複合並翻轉分類決策。

時間相關行為。 下載參考數據、調用 API 或使用當前時間戳的腳本在不同時間產生不同結果。過濾「過去 90 天」記錄的腳本每次運行都產生不同的數據集。事後看來這是顯而易見的，但我們見過帶有這種模式的生產數據管線。

帶有可視化界面的原生應用程序通過設計消除了大多數這些問題。用戶點擊按鈕，選擇選項，並通過確定性 UI 應用操作。沒有代碼可以破壞，沒有環境需要管理，沒有儲存格執行順序需要強制執行。

Python 擅長什麼（並應繼續做）

這不是全面反對 Python 的論點。Python 是以下任務的正確工具：

模型訓練。 PyTorch、TensorFlow、Hugging Face Transformers——模型訓練生態系統就是 Python，應該繼續如此。訓練是由精通 Python 的 ML 工程師執行的技術任務。複雜性是有道理的。

自定義模型架構。 設計新穎的模型架構、實現自定義損失函數、編寫具有特定優化策略的訓練循環——這是受益於 Python 靈活性和 ML 庫生態系統的代碼。

生產推理管線。 部署模型進行推理、構建 API 包裝器、與後端服務整合——這是屬於代碼的工程工作。

探索性數據分析。 對於探索新數據集的 ML 工程師和數據科學家——理解分佈、識別模式、測試假設——Python 筆記本是有效的。受眾是技術性的，工作是探索性的，輸出是洞察，而非生產管線。

區別在於：Python 是 ML 工程師執行任務的正確工具。它是應該由領域專家執行任務的錯誤工具。

無代碼替代方案不是降格

對無代碼數據準備工具有一個常見的反對意見：「它們對真正的工作太有限了。」五年前這是對的。今天不是。

現代無代碼數據準備工具可以處理：

• 具有層次類別、多標籤分類和關係注釋的架構感知標注
• 具有完整性、一致性和領域特定約束的可配置規則的數據驗證
• 具有可調整相似度閾值和人在環中解決的去重
• 常見 ML 訓練格式（JSONL、CSV、Parquet、框架特定格式）之間的格式轉換
• 包括標注者間一致性、標籤分佈分析和置信度評分在內的品質指標
• 對數據集應用的每個操作的完整稽核追蹤的版本追蹤

關鍵差異不是能力——而是誰可以使用這個工具。無代碼界面使這些能力對組織中 95% 無法編寫 Python 的人可及。理解數據的領域專家可以直接執行決定數據品質的操作。

做出轉變

將數據準備從 Python 移至無代碼工具不需要完全放棄 Python。實際架構如下：

1. 領域專家使用無代碼工具準備數據——標注、清洗、驗證、整理
2. ML 工程師使用 Python 訓練模型——加載準備好的數據集、配置訓練、評估結果
3. 領域專家使用無代碼工具審查模型輸出——檢查錯誤、糾正標籤、精煉標準
4. ML 工程師使用 Python 迭代——在改進的數據上重新訓練、調整架構

這種分工使每個任務與正確的工具和正確的人對齊。領域專家擁有數據品質。ML 工程師擁有模型品質。兩組人都不需要學習對方的工具。

Ertas Data Suite 實現了這種架構的領域專家端。它是一個用於數據標注、清洗和整理的原生桌面應用程式——沒有 Python、沒有筆記本、沒有命令行。領域專家像安裝任何桌面應用程式一樣安裝它，通過可視化界面處理本地數據，並以 ML 工程師在其 Python 訓練管線中使用的標準格式匯出準備好的數據集。

Python 非常適合構建模型。讓它做那件事。數據準備值得為理解數據的人設計的工具。