Scikit-learn 1.9 於2026年6月12日發布：古典機器學習工程的重大飛躍

Scikit-learn核心團隊於2026年6月12日發布了1.9.0版本，標誌著該庫近年來功能最豐富的版本之一。該更新在機器學習生態系統的關鍵時刻推出：隨著大型語言模型持續佔據新聞頭條，scikit-learn的維護者加倍投入該庫最擅長的領域——快速、可解釋、生產級別的古典機器學習——同時為下一代ML工具現代化其介面。該版本可在PyPI上獲得，相容Python 3.11至3.14。

對於在結構化表格數據上構建ML管道的工程師來說，scikit-learn 1.9提供了一系列改進：全新的實驗性回調系統用於訓練監控、通過陣列API擴展的GPU加速、通過narwhals提供的更輕量級數據框相容性層，以及顯著更豐富的HTML估算器可視化。這些變更共同解決了大規模部署sklearn模型的長期摩擦點。

該版本還在與Hugging Face的積極合作背景下推出，Hugging Face是已成為開源ML社區中心樞紐的AI平台。雖然1.9版本未隨附新的Hugging Face專用集成代碼，但兩個組織在過去四年中一直在構建共享基礎設施——最值得注意的是通過skops庫——該庫現在在Hugging Face Hub上託管近800個scikit-learn模型。1.9版本和逐漸成熟的sklearn–Hugging Face管道代表了基礎模型時代古典ML的樞紐時刻。

回調API：實時訓練監控進入Scikit-learn

1.9版本中最具影響力的單一新增功能是實驗性回調機制，這是一項長期請求的功能，為scikit-learn估算器的訓練迴圈引入了實時監控和進度可見性。直到現在，使用sklearn的ML工程師還沒有本機方式來觀察模型訓練過程——沒有進度條、沒有實時損失曲線、沒有早期停止掛鉤。這個差距迫使團隊依賴於詳細日誌標誌或外部庫等解決方案。1.9版本明確地彌補了這個差距。

回調系統開箱即用地引入了兩個具體實現：

• sklearn.callback.ProgressBar — 在fit()期間渲染實時進度條，給工程師提供訓練進度的實時視圖，無需離開筆記本或終端
• sklearn.callback.ScoringMonitor — 在優化迴圈的每個迭代中記錄評分指標，無需外部工具或自定義樣板即可啟用收斂跟蹤

在1.9版本中，回調系統由一組有針對性但有意義的估算器支持：LogisticRegression（使用lbfgs求解器）、完整的SearchCV家族（GridSearchCV、RandomizedSearchCV、HalvingGridSearchCV和HalvingRandomSearchCV）、Pipeline和StandardScaler。維護者明確指出這是一個基礎，而不是上限——發布博文將回調機制描述為"打開進度條或高級收斂監控的大門"的機制，後續版本計劃更廣泛的估算器覆蓋範圍。

該功能的重要性超越了用戶體驗。對於將scikit-learn整合到更大MLOps管道中的團隊——監控、警報和可審計性是不可協商的要求——回調API提供了可以饋送到日誌基礎設施、儀表板或MLflow和Weights & Biases等實驗跟蹤器的編程掛鉤。它表明scikit-learn團隊認真思考其庫被使用的操作環境，而不僅僅是其算法的統計正確性。

"回調機制打開了進度條或高級收斂監控的大門" — scikit-learn 1.9發布公告，2026年6月

展望未來，回調API的實驗狀態意味著在穩定之前介面可能會發生變化。在其上構建生產系統的工程師應將API表面視為在1.10和1.11版本中可能發生變化。也就是說，該設計已經足夠表達性來涵蓋最常見的監控使用案例，自6月12日發布以來的社區反應總體上是積極的，幾個MLOps工具維護者已在試驗其平台的回調適配器。

GPU加速和陣列API：Scikit-learn邁向硬體中立性

2024–2026年期間ML工程的定義敘述之一是硬體多樣性的加速：工程師不再被限制在CPU上進行古典ML。Scikit-learn對這一趨勢的回應——陣列API支持的逐步推出——在1.9版本中邁出了有意義的一步。該版本擴展了GPU相容執行到更廣泛的估算器和指標集，進一步將scikit-learn與所有計算都使用NumPy陣列在CPU上進行的假設解耦。

在1.9版本中，通過陣列API獲得GPU支持的主要估算器是：

• linear_model.LogisticRegression搭配solver="lbfgs" — 該庫中最廣泛使用的估算器之一現在本地在GPU上運行
• linear_model.PoissonRegressor搭配solver="lbfgs" — 對於計數數據和保險或精算應用至關重要
• kernel_approximation.Nystroem — GPU加速核近似解鎖大規模核SVM工作流
• pipeline.FeatureUnion — 啟用完全GPU加速的多分支功能組合管道

度量函數在1.9版本中也獲得了覆蓋範圍：d2_absolute_error_score、d2_pinball_score和average_precision_score現在接受陣列API相容輸入，意味著它們可以直接在GPU張量上運行，無需將數據複製回CPU。該版本還附帶一個新實用程序sklearn.utils._array_api.move_estimator_to，允許工程師將擬合估算器的陣列屬性移動到不同的設備或命名空間——這是混合設備ML管道的關鍵啟用器，其中預處理可能在CPU上進行，而推理在GPU上運行。

實際影響是實質性的。由:probabl. 2026年3月發布的獨立基準測試表明，在通過陣列API在GPU上運行時，複雜scikit-learn管道中可實現高達15倍的速度提升。雖然這些增益在很大程度上取決於模型類型和數據大小——較小的數據集通常由於數據傳輸開銷而看不到任何好處——但它們驗證了戰略方向：對於大型表格數據集和計算密集型管道，GPU加速的sklearn現在是一個可行的生產選項。

稀疏介面現代化

1.9版本還引入了"sparse_interface"配置鍵，允許用戶控制scikit-learn是否返回SciPy稀疏矩陣或更新的稀疏陣列介面：

import sklearn
sklearn.set_config(sparse_interface="sparray")  # opt into sparse arrays

這是與SciPy生態系統方向更廣泛一致的一部分，該方向自SciPy 1.8以來一直從舊版csr_matrix格式轉向csr_array。當前默認值保持"spmatrix"以保持向後相容性，但團隊已發出信號，在即將推出的版本中進行未來的默認更改為"sparray"。構建新管道的工程師應考慮立即選擇新介面，以避免日後發生中斷性遷移。

Narwhals集成：數據框互操作性的更輕路徑

scikit-learn 1.9中一個比較安靜但戰略性重要的變更是添加narwhals作為新庫依賴項。Narwhals是一個輕量級相容性層，允許Python代碼無縫跨多個數據框庫（主要是pandas和Polars）工作，無需庫特定的條件分支。通過採用narwhals，scikit-learn承認過去兩年從業者感受到的現實：Python數據生態系統不再與pandas同義。

這一變更的直接推動力是Polars團隊對數據框交換協議（__dataframe__）的棄用。Scikit-learn一直依賴該協議通過其在1.2版本中引入的set_output API來處理非pandas數據框。隨著Polars棄用該協議，sklearn團隊需要一個更強大的解決方案，不會在Polars API繼續發展時中斷。正如1.9版本變更日誌所解釋的那樣，narwhals提供了正是所需的：一個統一的、輕量級的介面，位於數據框層上方並將操作翻譯到底層庫。

對於ML工程師來說，這是一個重要的生活質量改進，具有真實的生產含義。Polars通過延遲評估、多線程處理和Rust後端優先考慮性能，已獲得實質性的關注作為大規模數據預處理的pandas替代品。已將其上游預處理管道遷移到Polars的團隊現在可以在scikit-learn中使用set_output(transform="polars")而不會遇到困擾交換協議方法的相容性問題。narwhals橋確保sklearn的轉換器輸出——無論來自StandardScaler、ColumnTransformer還是自定義估算器——可以本地返回為Polars數據幀，保留下游的延遲執行上下文。

選擇narwhals——一個社區驅動的項目而不是來自pandas或Polars團隊的第一方解決方案——反映了scikit-learn團隊對生態系統中立性的偏好。scikit-learn應該是社區標準的消費者，而不是專有介面的定義者。這與激發陣列API採用的哲學方法相同：在可能的情況下。

對於在sklearn和現代數據棧工具交匯處工作的數據科學家——通過DuckDB從Parquet攝入、通過Polars預處理、通過sklearn建模的管道——narwhals關閉了之前需要手動轉換步驟或自定義包裝代碼的差距。端到端管道現在可以一直保持在Polars原生領域直到sklearn轉換階段。

Scikit-learn和Hugging Face Hub：800個模型和不斷深化的合作

Scikit-learn 1.9版本不包括新的第一方Hugging Face集成代碼，但它落在自2022年6月以來一直在悄悄成熟的生態系統內，當時Hugging Face成為scikit-learn聯盟的官方贊助商位於巴黎Fondation Inria。該合作現已進入第四個年頭，已經產生了具體的基礎設施變更，正在轉變古典ML模型的共享、部署和發現方式。

sklearn–Hugging Face集成的中心是skops，一個專門為橋接兩個生態系統而建立的Python庫。Skops提供了兩個核心功能，解決了古典ML模型分發中的真實痛點：

1. 通過skops.io進行安全序列化 — scikit-learn模型被打包為zip存檔，附帶JSON模式文件，替換了長期以來是ML模型共享中安全問題的不安全pickle格式。與pickle不同，skops格式允許模型消費者在加載前檢查完整的對象結構，對抗通過惡意模型文件進行的供應鏈攻擊提供了有意義的保護——一個隨著Hugging Face Hub規模擴大而變得越來越相關的威脅向量。
2. 通過skops.card進行Hugging Face Hub集成 — 通過skops，工程師可以直接推送訓練的sklearn模型到Hub、從估算器元數據自動生成模型卡，並通過Hugging Face Spaces提供模型用於瀏覽器內推理。模型卡生成本身消除了之前阻止從業者公開共享古典ML模型的文檔負擔。

此集成的規模反映在當前Hub統計數據中：截至2026年6月，有799個scikit-learn模型託管在Hugging Face Hub上，跨越表格分類、表格回歸和不斷增長的結構預測任務集合，包括信用評分、欺詐檢測、客戶流失預測和醫療風險分層。該數字代表四年前幾乎在Hub上完全沒有存在的庫——Hugging Face的平台主要是為NLP、視覺和音頻的深度學習模型而構建的。Hub上sklearn模型的增長表明該平台範圍的重要擴展：它正在成為完整ML堆棧的家園，而不僅僅是神經網絡。

合作背後的人力資本

合作背後的機構投資同樣值得注意。兩位經驗豐富的開發人員特別被部署在Hugging Face以推進sklearn生態系統：Adrin Jalali，一位核心scikit-learn貢獻者，在庫的治理和API設計中發揮了核心作用，以及Benjamin Bossan，廣為使用的skorch庫的作者，該庫橋接scikit-learn和PyTorch。他們在Hugging Face的存在確保了集成由理解scikit-learn內部結構到構建可靠、前向相容工具所需級別的工程師驅動。

該合作也通過Evaluate庫具有機構深度，Hugging Face的有效、標準化ML評估框架。Evaluate庫正在擴展以本地支持其API中的scikit-learn指標，這將允許工程師計算並比較sklearn指標——精確度、召回率、F1、AUC、校準——與單個評估管道內的深度學習指標。這是朝著跨古典和神經方法的統一ML評估工具邁出的重要一步，減少了目前來自為不同模型族維護單獨評估代碼的操作複雜性。

Scikit-learn 1.9版本對Hub託管模型意味著什麼

對於Hub上已託管的799個模型，scikit-learn 1.9的改進直接轉化為更好的模型質量。樹型模型中增強的樣本權重處理和嶺回歸模型中改進的數值穩定性意味著用1.9重新訓練的模型應該產生統計更正確的輸出，特別是對於在調查或行政數據上訓練的模型，其中樣本權重常見。維護Hub上sklearn模型的工程師應考慮使用1.9版本重新運行訓練並更新其模型卡——新的HTML估算器視圖使生成準確模型架構描述變得顯著更容易。

其他增強：更快的算法、更智能的可視化和關鍵棄用

超越頭條功能，scikit-learn 1.9附帶了一個密集的算法改進、可視化升級和錯誤修復包，這些受益於日常ML工程工作。其中幾個值得那些可能在發布說明中忽視它們的從業者注意。

算法性能提升

帶有通縮算法的FastICA在1.9版本中速度提升約10倍，對於在音頻處理、神經科學（EEG/fMRI）或金融時間序列分解中使用獨立成分分析進行信號分離的團隊來說是一個顯著改進。RidgeCV和RidgeClassifierCV——生產古典ML中最常見部署的模型——現在都更快且數值上更穩定，解決了在病態設計矩陣上可能產生不可靠alpha選擇的邊緣情況。SpectralEmbedding中使用的ARPACK特徵求解器已被優化，受益於依賴大型稀疏矩陣特徵分解的基於圖的流形學習工作流。

新的metric_at_thresholds()函數

新的metrics.metric_at_thresholds()函數通過模型預測的單一通過計算所有可能分類閾值上的度量值。在此附加之前，計算二元分類器的閾值敏感性曲線——醫療診斷、欺詐檢測和操作點可調任何應用中的常規任務——需要自定義循環代碼或precision_recall_curve()和roc_curve()輸出的後處理。新函數標準化了此工作流並與sklearn指標API的其餘部分幹淨地集成。

更豐富的HTML估算器可視化

Jupyter筆記本中擬合估算器的HTML表示已被顯著增強。擬合屬性（以_結尾的屬性，例如coef_、feature_importances_和n_iter_）現在在HTML視圖中的結構化表格中顯示，允許工程師一目了然地檢查學習參數，無需調用print(model.coef_)。ColumnTransformer現在在可視化中顯示輸出特徵名稱和複製粘貼按鈕，使追蹤輸入特徵如何通過複雜預處理管道映射變得非常容易。對於在Jupyter中使用進行探索性模型開發和利益相關者溝通的團隊，這些可視化改進有意義地減少了模型檢查的摩擦。

樹和線性模型改進

RandomForestRegressor現在在使用absolute_error準則時支持本地缺失值處理——關閉了一個差距，迫使從業者在醫療記錄或傳感器數據等上下文中在擬合集成模型前進行數據歸因，其中缺失性帶有信息並不應被歸因掉。該版本還改進了HistGradientBoosting、RandomForest和ExtraTree中樣本權重處理的統計正確性，解決了可能影響在不平衡數據集或具有概率權重的調查數據上訓練的模型的細微偏差。此外，多任務線性模型現在支持稀疏輸入矩陣X和樣本權重——對於使用稀疏文檔特徵矩陣進行多輸出回歸的NLP從業者來說是一個重要功能。

需要注意的棄用

1.9版本引入了幾個棄用，團隊應在1.11和1.12版本中計劃遷移以進行計劃的突破性變更：

• 樹型模型中的criterion="friedman_mse"已棄用；標準"squared_error"準則是推薦的替代品
• SVC.probability參數已棄用；推薦的替代品是CalibratedClassifierCV包裝基礎SVC(probability=False)
• lasso_path()和enet_path()中的n_alphas參數已棄用
• LogisticRegressionCV中的默認評分將在1.11版本中從精確度更改為"neg_log_loss" — 一個統計動機的變更，可能會令依賴當前默認行為進行閾值基模型選擇的團隊感到驚訝

這些棄用遵循scikit-learn的在突破性變更落地前警告兩個主要版本的慣例，給團隊充分的跑道更新代碼而無需緊急重構。

來源

• Scikit-learn發布1.9：更好的數值學、新核心功能（scikit-learn博客）
• 版本1.9 — scikit-learn 1.9.0發布說明（scikit-learn.org）
• scikit-learn和Hugging Face攜手並進（scikit-learn博客）
• 與scikit-learn庫相容的模型（Hugging Face Hub）
• skops — 用於安全scikit-learn模型共享的Python庫（GitHub）
• 使用GPU加速scikit-learn：通過陣列API實現15倍速度提升（:probabl.博客）
• PyPI上的scikit-learn 1.9.0
• scikit-learn中陣列API採用的更新（Quansight實驗室）