Ramp、YAML設定システムでMLモデルのデプロイを4か月から5分に短縮

Rampの最初の信用リスクモデルを本番環境に投入するには、4か月近くとか3,000行以上のコードを要した。金融サービス企業として、Rampはすべてのモデルの出力が要求に応じていつでも正確に再現可能であることも必要としていたが、個別の使い捨てデプロイコードではそれを保証するのが難しかった。機械学習の議論はモデル自体に集中しがちだが、実際にはエンジニアリング時間の大半は「特徴量パイプライン」、つまり生データをクレンジングし、型変換し、利用可能な入力に変換するコードが占めており、チームはこれが実作業の99%だと見積もっていた。

Rampのエンジニアリングチームはこれを標準化するため、YAMLベースの設定システムであるTurboを構築した。彼らはすべてのMLワークフローに共通するエンティティを特定した。すなわち、Feature Pipeline（生データから特徴量へ）とModel Pipeline（特徴量から予測へ）である。「JobSpec」クラスはYAMLファイルを読み込み、これらをPydanticオブジェクトとして実体化し、コンピュート環境に投入する。新しいモデルを適合させるTrain Jobか、モデルストアからモデルを読み込むPredict Jobのいずれかである。両ジョブが同じスキーマを共有するため、モデルのデプロイは設定ファイルをコピーして数行を編集するのに近い。

その効果は即座に現れた。今日設定ファイルに記述されたパイプラインは、基盤となるデータが変わっていなければ、1年後や2年後に再実行しても同じ結果を生み出すため、再現性の要件を直接解決する。また、移行した時系列予測モデルは、すべてのモデルが同じ特徴量エンジニアリングのロジックを個別に再実装するのではなく継承するため、祝日の扱いが全体で一貫するようになったという利点も無償で得られた。

すべてのMLパイプラインを、1つのYAMLファイルに記述された2つの再利用可能な部品（特徴量、モデル）に変える

Feature PipelineとModel Pipelineを再利用可能なエンティティとして分離したことで、モデリング以外のML作業の99%を一度解決するだけで済むようになった。

コードライブラリではなく宣言的なYAMLスキーマにしたことで、MLのバックグラウンドを持たないエンジニアでも、パイプラインのコードを自分で書くことなくモデルをデプロイし保守できるようになった。

トレーニングと予測が1つのスキーマを共有することで、開発者は各段階ごとに別々のツールを学ぶのではなく、1組の概念を学ぶだけで両方をこなせるようになった。

特徴量エンジニアリングの標準化（例：時系列モデルにおける祝日の扱い）により、各モデルを個別に修正するのではなく、一連の不整合バグをまとめて解消できた。

同じ2段階のパイプライン構造が複数のシステムで繰り返し現れる場合、それを一度宣言的なスキーマとしてエンコードすれば、専門家だけがこなせる数か月がかりの作業を、どのエンジニアでも記入できるものに変えられる。

RampがTurboについて執筆した時点では、新しいモデルは平均約40行のYAMLで5分未満でデプロイできるようになっており、4か月と3,000行以上のコードから短縮されていた。9人の異なる開発者によって構築された約20のモデルが本番環境で稼働しており、その多くはTurboが存在する前に機械学習モデルをトレーニングしたこともデプロイしたこともなかった。