雷鋒網 (公眾號：雷鋒網) AI 科技評論按：實際上，號稱「美版知乎」的?Quora 也已經大量引入了機器學習技術，而 Quora 的工程師們則喜歡把自己研究機器學習、產出技術方案的過程戲稱為「煉丹」，如今他們也想對外分享他們的經驗和成果，開始做一系列「機器學習煉丹之旅」的技術博客。日前，他們發出了該系列博客的第一篇—— 《使用 Alchemy 做特征工程》（「Feature Engineering at Quora with Alchemy」），作者為? Quora 的兩位工程師? Kornél Csernai? 和? Naran Bayanbat 。雷鋒網 AI 科技評論編譯如下。

概述

一直以來，Quora 都致力于拉近人們和有益知識的距離。這意味著，我們需要不斷增加知識的采集，并對知識進行評估，還要知道怎樣高效地對它們進行排序和分類。現在，Quora 的重點便是通過問答來實現這些目標：讀者在網站上尋找相關的內容，提問者尋找有用的答案，而我們就是從他們的提問中提取出正確問題的答復者。其次，我們也需要考慮檢測并刪掉違規的內容，以及識別出重復的問題。而為了實現這些目標，我們重點倚靠機器學習技術。

首先讓我們來看一個典型的案例：Quora 的 Home Feed 功能。在這個最簡單的功能中，系統會根據我們認為特定用戶可能重視的上下文中的一系列特征，對候選 post? 進行排序。之后，這些計算了得分的輸入就會形成一個基本的漏斗（funnel）。

一個強大的特征能夠明顯提升產品的質量，因此快速迭代模型特征非常重要。隨著 Quora 網站上機器學習工程師數量日益增多，用來支持產品中各類應用程序的獨一無二的特征工程框架的數量也在增多。這種增長自然也帶來了一些挑戰：

• 一如既往地，更多的框架意味著更多碎片（fragmentation）、更多冗余（redundancy），以及給我們的工程團隊帶來更重的維護負擔。各個團隊的開發人員正在創建不同的系統來應對同一個技術挑戰，并且無法跨多個應用程序重復利用特征。

• 對于一個典型的機器學習應用程序來說，針對每個問題都有成百上千篇候選 post，而每篇候選 post 中又可以提取出數百個特征。同一時間，多個產品服務又必須要實時響應，且響應的時間不能超過幾百毫秒。這就意味著，特征提取受限于時間很緊的速度、計算以及記憶局限。我們其中的一些框架難以應對這些局限，也無法成功從日復一日的特征開發中將系統所面臨的挑戰抽象化。
  

高水平的設計

為了應對上述所有的挑戰，我們為特征提取開發了一個高性能、規模化、無國界的服務——Alchemy，它可以泛化到 Quora 上所有的機器學習相關應用程序。

在這 Feed 功能的案例以及相似的應用程序中，這就意味著將特征提取這一步驟單獨分離出來作為該網站的一項服務。

之前：

之后：

Alchemy 使用應用程序類型（如 Feed 功能）和目標列表（如候選 post），就能為它們各自返回一個數值化的、經過分類的特征向量。假設將特征組織成邏輯組（每個邏輯組表示為一個類別）的形式，這種形式具有數據依賴關系（data dependencies），例如一個問題所對應的答案數量。之后，應用程序就會確定應該提取哪個特征組、

來自應用程序的請求會實時排列，并且在某些情況下，源于不同期工作的請求也會進行排隊。每個請求包含了需要評估特征的請求類型以及候選列表（同時，相應的應用程序會定義每個特征列表）。之后，Alchemy 檢索并組織任一必要的數據，并最終平行計算出每個目標的特征。

數據存儲

Alchemy 使用 HBase 作為它的存儲層，不過它也可以輕易地進行擴展來支持其他的存儲庫。為了讓查詢更加高效，我們采用了多個緩沖層（HBase 頂部的 Memcache 以及 Memcache 頂部的一個內存 LRU cache）。我們的數據由 Thrift 目標組成，它們可以直接存儲于內存 cache，以及以二進制形式（binary serialized format）存儲于 HBase 和 Memcache。

由于高速緩沖器存儲的值會變得陳舊，我們就需要讓 Alchemy 知道何時需要從?ground truth?中舍棄掉一些值。這項操作可以通過這種方式實現：從應用程序端寫入 Kafka 隊列并從 Alchemy 端上的這一隊列中讀取值。 該隊列包含 table、 key 以及值信息，因此 Alchem 可以在內存緩沖器中用新的值來取代舊的值。

性能

實現 Alchemy 的第一個版本后，我們投入了大量精力來提高該服務的性能。為了讓 Alchemy 變得更加快速，我們采用 C++語言將其寫成了一個單獨的服務，這與將特征提取器嵌入 web 應用程序的代碼中的做法相反。這樣做的原因在于：

• C++ 是一個低水平的編程語言，它通常可以比用 Python 寫的應用程序運行得更快。

• 針對每個問題，我們都會發送成百上千篇候選 post 進行評估，代碼在候選級別上就能輕松實現并行。而在 Python 中，代碼很難在一個過程內實現并行。

• 將 Alchemy 寫成一個單獨的服務，我們就能夠在存儲器中存儲大量反序列化的目標，從而巨大地減少數據檢索的延遲（latency），然而這些在 web 應用程序代碼中通常是無法實現的。

除了決定采用這些設計，我們還 profile 了代碼以找到并消除熱點。此外，我們還不斷審查了大量的度量標準，以了解當這些熱點出現時的速度回歸（speed regression）源。

（是的，當為單個特征提取編寫代碼時，選擇采用 C++ 可能會降低開發速度。然而，我們認為 C++ 所帶來的優勢要遠大于這一損失，因為機器學習工程師在使用 Alchemy 時不再需要擔心性能優化問題。）

遷移和未來工作規劃

到目前為止，我們對 Alchemy 所做的所有遷移（?migration）都帶來了積極的結果。對于我們的在線預測系統，請求延遲得到改善之后，我們就有了更多的空間去嘗試那些比較花時間、計算成本比較高的特征。此外，我們可以對更多候選 post 進行排序，從而提供更好的用戶體驗。使用 Alchemy 還讓我們能夠繼續維護以前耗費過多時間去維護的離線系統（其中的一些離線系統已經被我們在線遷移了）。總的來說，我們已經能夠看到，工程師可以更頻繁地啟動特征并迭代他們的模型。

這些遷移還帶來了許多觀點、反饋和特征請求，它們都將以實質性的方式積極為我們的路線圖提供信息。舉一個小例子，我們開始對目標 ID 的請求進行分區以實現更好的緩存利用率。

至于未來的工作規劃，我們可能會增加 Python 的綁定，以便工程師和數據科學家可以更廣泛地使用該系統。我們還會識別特征之間的依賴關系，構建特征圖并異步計算出特征和數據的依賴關系。一個靈活的異步數據檢索抽象，會讓訪問多個數據的存儲變得更加容易。所有這些改進都可以將機器學習工程師的負擔轉移出去，從而使他們可以更專注于開發出色的機器學習模型。

結論

一旦 Alchemy 能夠結合大量的應用程序，它的投資回報率是非常高的。系統特征提取做得更好，也意味著它的排序也做得更好。

所有人都說，增長是一個伴隨著挑戰的好事。弄清楚如何明智地控制這種增長以減少低效率和冗余，是值得從多個維度深入思考的事情，并且這種增長可能會帶來很大的收益。

via： https://engineering.quora.com/Feature-Engineering-at-Quora-with-Alchemy ?雷鋒網 AI 科技評論編譯

。