解決方案
Ramp 的第一個信用風險模型花了將近四個月、超過 3,000 行程式碼才進入正式環境。作為一家金融服務公司,Ramp 還需要每個模型的輸出都能隨需精確重現,而客製化、一次性的部署程式碼難以保證這一點。機器學習的討論往往聚焦於模型本身,但工程時間實際上主要花在「特徵管線」(feature pipeline)上——也就是清理、轉型別、將原始資料轉換為可用輸入的程式碼——團隊估計這占了實際工作的 99%。
Ramp 的工程團隊打造了 Turbo,一套以 YAML 為基礎的設定系統,來將這件事標準化。他們找出每個 ML 工作流程共用的實體:特徵管線(Feature Pipeline,從原始資料到特徵)與模型管線(Model Pipeline,從特徵到預測)。一個「JobSpec」類別會讀取 YAML 檔案,將這些具體化為 Pydantic 物件,並提交到運算環境——一個是訓練新模型的 Train Job,另一個是從模型儲存庫載入模型的 Predict Job。由於兩種工作共用同一套 schema,部署模型幾乎就等同於複製一份設定檔並修改幾行。
回報立竿見影:今天以設定檔描述的管線,只要底層資料沒有變動,一、兩年後再執行也會產生相同的結果,直接解決了可重現性的要求。一個遷移過來的時間序列預測模型也免費獲得了全面一致的假日處理,因為每個以這套抽象建構的模型都繼承相同的特徵工程邏輯,而不必各自獨立重新實作。
達成的成果
將每個 ML 管線轉化為兩個可重複使用的部分(特徵、模型),並以單一 YAML 檔案描述
奏效的原因
將特徵管線與模型管線分離為可重複使用的實體,意味著 ML 工作中不涉及建模的那 99% 只需解決一次。
採用宣告式的 YAML schema 而非程式碼函式庫,意味著沒有 ML 背景的工程師也能部署與維護模型,而不必自己撰寫管線程式碼。
訓練與預測共用同一套 schema,意味著開發者只需學習一組概念就能完成兩者,而不必為每個階段使用各自獨立的工具。
將特徵工程標準化(例如時間序列模型中的假日處理)一次修正了一整類不一致的錯誤,而不必逐一修補每個模型。
可套用之處
當同樣的兩階段管線形態在各系統中反覆出現時,將其一次編碼為宣告式 schema——這能把一項只有專家能做、耗時數月的工作,變成任何工程師都能填寫的事。
後續發展
到 Ramp 撰寫關於 Turbo 的文章時,一個新模型已能在 5 分鐘內完成部署,平均只需約 40 行 YAML,相較之下原本需要 4 個月與 3,000 多行程式碼。當時已有將近 20 個模型在正式環境中運行,由 9 位不同的開發者建構,其中許多人早在 Turbo 出現之前從未訓練或部署過機器學習模型。
追溯依據
參考來源
- Turbo-Charging ML Development Ramp Engineering (Builders Blog) · builders.ramp.com ·