機械学習基盤 Hekatoncheir の取り組み Shuhei Fujiwara

今日の話 DeNA が Google Cloud Platform 上に構築している 社内横断の機械学習基盤 Hekatoncheir (Hekaton) の話 ● どんな課題を解決したかったのか ● Hekaton を構成する技術要素 ● 実際の使い方の簡単な紹介 ● 活用事例

DeNA の機械学習プロジェクトと課題

DeNA の多岐に渡る事業 多くの事業で機械学習などの技術が活用されている ● ゲーム ● オートモーティブ ● スポーツ ○ 横浜 DeNA ベイスターズ ● ソーシャルライブ ○ Pococha ● 他社との協業 ○ 関西電力様との燃料運用最適化

複数プロジェクトをこなす上での課題 プロジェクト間の技術共有 ● 各プロジェクトで属人化しがち ● 類似案件でのノウハウを横展開したい プロダクション化までのハードル ● データサイエンスと MLOps の役割範囲が不明確になりがち ● プロジェクトの進め方が定型化されていない

Kaggle とは 機械学習モデルの精度を競うコンペティションのプラットフォーム ● DeNA では Kaggle 社内ランク制度が導入されている ○ 世界トップクラスの Kaggler が数多く在籍 ● Kaggle Grandmaster / Master どちらも 国内最多に！！（自社調べ） https://dena.com/jp/press/004688

Kaggler の能力を活かす 課題発見 問題設計 モデル開発 プロダクション投入 Kaggler の強み ● モデルの精度が高く開発サイクルも非常に速い ○ モデル開発後のプロダクション投入を いかに簡単にできるかが勝負 ● 機械学習の課題発見と問題設計も得意 ○ 多くのコンペを見た経験を設計に活かせる Kaggler の作ったモデルをシームレスにプロダクション投 入できるような基盤として Hekaton プロジェクトが始動

Kaggler に馴染みのあるコンペ形式 色々な機械学習プロジェクトあるあるへの回答にもなる: ● どのデータで学習してどのデータで評価すればいいんだっけ？ ○ → コンペで決められたデータでフェアにモデルを比較 ● プロダクション化のためにはどんなコードを用意すればいいんだっけ？ ○ → コンペのルールという形で従うべきフォーマットを定義 ● 自分は何をどこまで作ればいいんだっけ？ ○ → コンペ主催者と参加者で役割とゴールが明確になる

一般的なコンペと実務の違い 普通のコンペ ● 与えられたデータに対して 推論結果の CSV を提出 ● 学習と推論に使うデータは固定 実務の機械学習 ● システム内で呼び出されるコードや学 習済みモデルを提出 ● 新しいデータを使ったモデルの 継続的な改善が必要 ● 学習済みモデルの先の成果物がある ○ たとえば推論サーバー用の Docker イメージなど ※ 最近はコンペ側も多様で、この限りではない

Hekatoncheir の名前の由来 Hekatoncheir は無数の腕を持つギリシャ神話の神 そのため、ヘカトンケイルたちは、ティーターンと戦い、無数の剛腕で1度に300の大岩を敵に投げ付け てゼウスたちを支援した。この大岩はひとつひとつが山の如き巨大さを誇り、着弾の衝撃で大地が揺れ 動くほどであった。 (Wikipedia: https://ja.wikipedia.org/wiki/ヘカトンケイル) ● 多くの Kaggler とその試行を事業課題の解決という 1 つの目標に向ける という意味合いで命名された

Hekaton のアーキテクチャ

Hekaton Hekaton の全体像 Training Evaluation Artifact submit update dataset Data Pipeline ● Hekaton のパイプラインは学習・評価・成果物生成の 3 つのステップで構成 ○ 成果物はたとえば API サーバー用の Docker イメージなど ● パイプラインが実行されるトリガーは次の 2 つ: ○ コンペ参加者のコード submit ○ データセットの更新

Hekaton を構成する技術要素 (1/2) Google Cloud Platform の full managed なサービスを繋ぐ形 処理の繋ぎ方: Event Full managed なサービスに 処理を委ねる Cloud Pub/Sub ● 非同期メッセージングサービス Cloud Functions ● Pub/Sub などをトリガーに関数を実行するサービス

Hekaton を構成する技術要素 (2/2) 具体的な処理を行う主要なサービス群: Cloud Build ● 学習・評価で利用する Docker イメージのビルド AI Platform ● Docker コンテナを使った学習・評価・成果物生成処理の実行

学習処理の構成 submit Upload code Update dataset Training Docker image Download Use Docker image competitor Cloud Storage AI Platform Cloud Build Save model Evaluation Container Registry competition host Upload competition code Pub/Sub + Cloud Functions Pub/Sub + Cloud Functions Pub/Sub + Cloud Functions

既存のワークフローエンジンとの関係は？ Airflow や Kubeflow Pipeline などを利用していないが競合させる意図はない ● Hekaton の pipeline 中では分岐や待ち合わせがほとんど存在しない ○ 依存関係が煩雑になりやすい data pipeline はスコープの外 ○ ここでの併用などは十分にあり得る ● 足りるのであれば full managed に寄せた方が運用コストは低い Hekaton Training Evaluation Artifact submit update dataset Data Pipeline

モデルやデータのバージョン管理は？ 学習コード ● Submit 時に Docker イメージが残る データセット ● 各サービスで作成したデータセットの名前とバージョンを Hekaton の DB に 登録できる 学習済みモデル ● どの学習コード (Docker イメージ) とどのデータセットで作られた モデルか後で追うことができる 成果物 ● 学習済みモデルとコンペのバージョンからどう作られたか追える

Hekaton を使った開発の流れ

利用方法 社内ユーザーには CLI として提供 $ hekaton --version Hekaton CLI 0.1.9 ● Kaggle CLI に近い感じ

コンペ参加者の作業 (1/2) 予め用意された competition name を指定してプロジェクトを作成 $ hekaton init --competition-name sample-competition コードを書いたらバージョン管理のタグを付けて submit ● 普通のコンペと違って CSV ではなく、コードと Dockerfile を submit する $ hekaton submit --tag v1

コンペ参加者の作業 (2/2) ルールに従って学習や推論のコードを書く ● コンペごとにルールが実装されている ● たとえば「Trainer クラスと Predictor クラスを実装してください」など class Predictor: def __init__(self, model_dir: str): # Load trained model # ... def predict(x: Dict): # ... class Trainer: def __init__(self, model_dir: str): # Load trained model # ... def train(x: Dict): # ...

コンペ主催者の作業 (1/3) competition name を決めてプロジェクトを作成 $ hekaton competition init --competition-name sample-competition コンペ用のコードとデータセットが準備できたら publish $ hekaton competition publish --tag v1

コンペ主催者の作業 (2/3) 学習・評価・成果物生成の 3 つの処理を用意 import hekaton # 参加者の Trainer class を利用 from submission import Trainer # 細かい処理は Hekaton SDK で # サポート @hekaton.hekaton_training def main(): # 学習に使って欲しいデータを用意 dataset = ... # Trainer にデータを渡す trainer = Trainer() trainer.train(dataset) Hekaton ではエントリポイントと呼ぶ ● 参加者の学習モジュールに学習用データを渡す ● 保存したモデルと参加者の推論モジュールに評価用 データを渡す ● 保存したモデルと参加者の推論モジュールから成果 物を生成する ○ バッチ推論の結果や API サーバー用 Docker イ メージなど 学習処理の例 (train.py)

コンペ主催者の作業 (3/3) データセットを用意して Hekaton に登録する ● Hekaton の DB にデータセットの name とバージョン管理の tag を登録 Hekaton Training Evaluation Artifact Data Pipeline データセット作成処 理を日時で実行 Hekaton の Pub/Sub に新しいデー タセットの情報を publish

Hekaton を通じた役割分担 コンペ参加者視点 ● 緩いルールの範囲内で自由にコードを書いて精度向上に注力できる ● 書いたコードをほぼ手直しゼロでプロダクションに持っていける コンペ主催者視点 ● 全ての参加者がルールに従ってコードを書くので同じ手順で実行できる ○ このコードどうやって実行するの？が発生しない ● 定期的な再学習など機械学習プロジェクト共通のところは Hekaton が面倒を見てくれる ● 他のコンペの設計を参考にして知見を横展開しやすい

Hekaton の活用事例

Pococha での活用事例 DeNA が運営する LIVE コミュニケーションアプリ ● ライバーとリスナーの距離の近さが良いところ ● 推しのライバーを見つけられるかで 定着率に大きな差が出る！ ○ おすすめのライバーを表示する タイムライン改善が非常に重要 実際に Hekaton を使って開発・リリースまでを行った https://www.pococha.com/overview/how-to

Pococha での活用事例 開発体制 ● データサイエンティスト 2 人 (コンペ主催者 + 参加者) ● ML エンジニア 1 人 (コンペ主催者のサポート) 開発期間と運用 ● モデル開発開始から 1st リリースまで 2 ヶ月程度 ○ Hekaton 本体の大規模アップデートと並行して行ったので少し長め ● 週 2 日程度のペースで継続的にモデルを更新 ○ 推論サーバー用の Docker イメージは毎日新しいデータで自動生成 ○ 評価値などを確認して問題なければデプロイしている

まとめ

開発時に気をつけたこと ● Kaggler の良さを活かす ○ 十分な自由度を確保して限界まで精度向上ができるように ● 役割の切り分けを明確に ○ データサイエンティストがモデリングに集中できるように ● データサイエンティストと ML エンジニアのコミュニケーションを スムーズに ○ プロダクション投入のためのコード修正が一番大変 ○ これをコンペのルールという形で吸収

Hekaton が目指すところ ● 将来的には 1 ヶ月程度のスパンで新しい機械学習の挑戦ができるような 世界を目指したい ○ 試行錯誤の回数はとても大事！ ● データサイエンティストがモデリングに注力しているだけで自然と production ready なものができるように ○ Kaggler が一番得意な分野で実力を発揮できる！

自己紹介 藤原 秀平 (FUJIWARA Shuhei) ● AI システム部 ML エンジニアリンググループ ○ Hekaton プロジェクト Tech Lead ● Google Developers Expert