Olivier Grisel談scikit-learn和機器學習技術的未來

幾周前，我們的Florian Douetteau (FD)對Olivier Grisel(OG)進行了一次訪談，正好我得到這個機會去旁聽。Olivier是scikit-learn機器學習庫的主要貢獻者，因此他們兩個詳細地 討論了Olivier的工作和其它技術的發展。這是采訪的第一部分。

Olivier Grisel 和 scikit-learn

FD：Olivier，你作為scikit-learn的主要貢獻者已經有一段時間了。你可以告訴我們一些關于你的貢獻么?

OG：大概是2010年，我就開始做scikit-learn這個項目。我是利用業余時間去做這個項目的。在2013年10月，我加入了 Inria，一所面向計算機科學和自動化研究的法國研究院。我們有個團隊，名叫Parietal，主要研究使用MRI數據對大腦進行建模。在這個項目中， 我主要負責讓scikit-learn發展地更長遠，主要是指性能和可擴展性方面。

FD：scikit-learn已經發展了這么多年，而且知道開發過程中的許多阻礙。你能告訴我們一些關于將來的事么?

OG：當然可以。在過去的幾年中，我們已經知道了一個重大的進展。現在，我們有很多新的用戶和貢獻者。根據我們的網站統計，我們每個月有 150000到160000個獨立訪客，其中有1 / 3是回訪用戶，而且我們也有越來越多的貢獻者。例如，在這些天，幾乎有300個pull請求需要我們去處理。

scikit-learn大多數的新發展都來自用戶社區自身的貢獻。他們不斷給scikit-learn庫進行修改和補充，并為scikit- learn更好的后續版本提交這些工作。然后我們會對這些修改進行測試，并將其添加到每個新的版本中。例如，在最近的一個測試版本里，我們的一個貢獻者開 發了LDA估測器。這個算法在某種程度上可以替換scikit-learn已經存在的MMF，而且LDA在可擴展性方面表現的更強。

我開發的是一個更加長期的項目，這個項目涉及了大量的問題(因此它并不屬于下一個版本的一部分)。我們正在努力使更多的scikit-learn 算法能夠以數據流模式，或核外模式，來管理數據，而不是在內存中控制整個數據集。我們希望它們逐漸地加載數據集，就像它們訓練模型那樣。

scikit-learn VS MLlib

FD：目前，在機器學習領域，我們聽到了大量關于Spark的傳聞。你有機會去嘗試一下么?如何把它與scikit-learn進行比較呢?

OG：通過制作的兩個Spark教程，我了解了一下Spark(教程1，教程2)。Spark和Python或scikit-learn之間的主 要區別是，Spark默認是一個系統，以分布式的方式管理那些其它數據處理方法無法在內存中處理的數據。這也是MLlib一開始的設計方向 (ed：Spark分布式機器學習框架)。他們選擇僅實現可擴展性的算法，這些算法可以在它們有能力處理的那些數據上和大量集群中運行。通過只選擇有這種 特性的算法，他們目前已經解決了這個雙重可擴展性問題。

scikit-learn最初的目的是處理內存中的數據，所以我們不存在偏見。我們有一些非常有效的算法，它們只在小數據集上有效。但事實上，我們有很多算法都是以批處理模式實現的。目前，我正在對它們進行重構，主要是為了讓其具有更好的可擴展性。

scikit-learn并不是創建跨集群的功能。我們不想改變所有的功能，來處理存儲在集群中的資源，但我們想把它作為一種可能性，確保 scikit-learn模型可以嵌入到一個類似Spark的框架里，這樣它們就可以分布在集群中。例如，當你在訓練一個隨機森林時，如果你認為你的數據 小到可以在整個集群中進行復制，那么你可以很容易地訓練每棵樹。對于中等規模的數據集，我們也想要加快超參數搜索和交叉驗證的速度，這自然就是并行。

在解決集群的分布式計算之前(正如Spark關注的)，我對于研究有效的核外處理方法(像Dato正在做的)也是很有興趣的。目前我還沒有真正地 研究過細節，但似乎只要你能夠更好地進行核外處理并重視算法效率，你就可以減少資源的浪費。這也可能成為scikit-learn未來發展的驅動力。

FD：以分布式方式存儲大量數據會導致性能和結果的偏差么?我正在思考使用Spark運行隨機森林的例子。

OG：MLlib隨機森林算法在選擇特征進行劃分時，它是直接在每棵樹的訓練層面進行并行的。它并沒有考慮所有可能的分裂。它建立的是一個直方 圖，并在劃分的數據集上進行并行運算。然后，使用總的信息構建劃分。這跟估計算法類似。盡管這種方法是近似估算，但在實際應用中，當你使用樣本進行建模 時，幾乎不會出現問題。因為和非估計算法的結果相比非常接近，只是實現的效率差了點。

未來的方向是特征生成?

FD：當你去查看一個數據項目，很多時間–如果不是大部分時間–是用在數據預處理和特征生成。在過去的幾個月里，scikit-learn在朝著 特征工程方向發展。這是你將繼續維持的方向嗎?你會朝一個集成的管道工作嗎?這似乎像是一條無止盡的路。有沒有一些平行的項目專攻特定的數據類型和格式， 同時又遵循scikit-learn的習慣和理念?

OG：在創建scikit-learn預測模型時，特征始終是一個關鍵點。因為pandas數據框的最新版本，我們越來越善于整合工具箱去操縱任何格式的數據，并把它轉為其它格式或是任何其他的表示。

我贊同你的觀點，特征工程對于一個具體的應用程序而言，永遠是一個特殊環節。我們希望保留一個通用庫。如果我們要專攻某個特定的領域并開發特征， 它將成為一個獨立的特定庫的一部分。例如，在天體物理學中有一個叫AstroML的專用庫。此前，我在INRIA的團隊處理的是影像數據。我們已經開發了 一個特定的庫，叫做nilearn，它是scikit-learn的一個分支項目。事實上，劃分不同項目的范圍是很有好處的。它可以圍繞社區特定的實踐活 動進行更好地交流。

FD：在特征工程這個主題上，你相信Spark和MLlib會改變數據科學家的工作方式么?

OG：最近的數據框API是Spark的一個優點。它給了數據科學家一個非常直觀，靈活，并富有表現力的工具，用于測試他們不同的數據表示。

從更高層面來講，最新版本的spark.ml包，允許在以數據組合為特征的“鏈”中創建管道和預測模型。在鏈的不同階段可以交叉驗證參數的相互作 用。也正是這類API的優點，使它更易于測試。其實在scikit-learn中也可以安裝插件，使用數據框作為輸入并且添加用戶自定義的scikit- learn轉換腳本。事實上，使這個過程變得更加簡單也正是我們應該努力的實踐方向。

搜尋這些項目

FD：非常感謝您這次精彩的談話!你覺得還有其他任何需要補充的嗎?

OG：我認為Python生態圈越來越意識到當前的技術形勢，特別是在談及到處理大量數據時。Java和Scala領先于我們，尤其是 Hadoop和Spark。開發人員對于這一點都非常清楚，他們正在尋找答案。如今有很多有趣的項目，如Blaze,Dask,或XRay。他們正在開發 相關的APIs，努力使其像Pandas一樣出色，并且能做核外計算，最終形成分布式的。Wes McKinney給Cloudera做的Ibis項目也很有趣。它使用的是Python，但用Impala作為后臺，用其替代PySpark。其實，我并 不相信在當今的生產中能夠使用它，但我相信這個主題的發展將會很有趣。

敬請期待Olivier訪談的第二部分，在那里他給數據科學的入門人士和想知道應該培養什么技術的學者提出了一些建議。