Upgrade to Pro — share decks privately, control downloads, hide ads and more …

機械学習基盤 Hekatoncheir の取り組み【DeNA TechCon 2021】/techcon2021-12

機械学習基盤 Hekatoncheir の取り組み【DeNA TechCon 2021】/techcon2021-12

DeNA には優秀な Kaggler が多く在籍しており、機械学習の課題発見や高精度なモデリングに大きな強みを持っています。一方で機械学習モデルのプロダクション化は Kaggler の開発サイクルと比べて時間がかかりがちです。

そこで、DeNA では Kaggler が自身の得意分野に注力しつつ自然と production ready なものが出来上がるように「Hekatoncheir」という機械学習基盤を作成しました。Hekatoncheir は Google Cloud Platform の AI Platform など既存のツールを組合せて、コンペティションという Kaggle like な形式で事業課題を解決する仕組として開発・運用されています。

コンペティションという形で、コンペ参加者が担う純粋な機械学習アルゴリズムの実装とコンペ主催者が担う周辺タスクの境界を明確にしつつ、両者のコミュニケーションコストを削減します。結果として開発サイクルが早まり、実サービスへより気軽に機械学習を導入できるようになりました。

本発表では、Hekatoncheir が作られた背景や技術選定・アーキテクチャについて解説します。また、活用例として Pococha などの実サービスで、プロダクト投入までのリードタイムを短縮しつつ高頻度でのモデルの更新を実現している事例についても紹介します。

8a84268593355816432ceaf78777d585?s=128

DeNA_Tech

March 03, 2021
Tweet

Transcript

  1. Shuhei Fujiwara

  2. DeNA が Google Cloud Platform 上に構築している 社内横断の機械学習基盤 Hekatoncheir (Hekaton) の話

    • どんな課題を解決したかったのか • Hekaton を構成する技術要素 • 実際の使い方の簡単な紹介 • 活用事例
  3. None
  4. • ゲーム • オートモーティブ • スポーツ ◦ 横浜 DeNA ベイスターズ

    • ソーシャルライブ ◦ Pococha • 他社との協業 ◦ 関西電力様との燃料運用最適化
  5. • 各プロジェクトで属人化しがち • 類似案件でのノウハウを横展開したい • データサイエンスと MLOps の役割範囲が不明確になりがち • プロジェクトの進め方が定型化されていない

  6. 機械学習モデルの精度を競うコンペティションのプラットフォーム • DeNA では Kaggle 社内ランク制度が導入されている ◦ 世界トップクラスの Kaggler が数多く在籍

    • Kaggle Grandmaster / Master どちらも 国内最多に!!(自社調べ) https://dena.com/jp/press/004688
  7. 課題発見 問題設計 モデル開発 プロダクション投入 • モデルの精度が高く開発サイクルも非常に速い ◦ モデル開発後のプロダクション投入を いかに簡単にできるかが勝負 •

    機械学習の課題発見と問題設計も得意 ◦ 多くのコンペを見た経験を設計に活かせる Kaggler の作ったモデルをシームレスにプロダクション投 入できるような基盤として Hekaton プロジェクトが始動
  8. • どのデータで学習してどのデータで評価すればいいんだっけ? ◦ → コンペで決められたデータでフェアにモデルを比較 • プロダクション化のためにはどんなコードを用意すればいいんだっけ? ◦ → コンペのルールという形で従うべきフォーマットを定義

    • 自分は何をどこまで作ればいいんだっけ? ◦ → コンペ主催者と参加者で役割とゴールが明確になる
  9. 普通のコンペ • 与えられたデータに対して 推論結果の CSV を提出 • 学習と推論に使うデータは固定 実務の機械学習 •

    システム内で呼び出されるコードや学 習済みモデルを提出 • 新しいデータを使ったモデルの 継続的な改善が必要 • 学習済みモデルの先の成果物がある ◦ たとえば推論サーバー用の Docker イメージなど ※ 最近はコンペ側も多様で、この限りではない
  10. Hekatoncheir は無数の腕を持つギリシャ神話の神 そのため、ヘカトンケイルたちは、ティーターンと戦い、無数の剛腕で1度に300の大岩を敵に投げ付け てゼウスたちを支援した。この大岩はひとつひとつが山の如き巨大さを誇り、着弾の衝撃で大地が揺れ 動くほどであった。 (Wikipedia: https://ja.wikipedia.org/wiki/ヘカトンケイル) • 多くの Kaggler

    とその試行を事業課題の解決という 1 つの目標に向ける という意味合いで命名された
  11. None
  12. • Hekaton のパイプラインは学習・評価・成果物生成の 3 つのステップで構成 ◦ 成果物はたとえば API サーバー用の Docker

    イメージなど • パイプラインが実行されるトリガーは次の 2 つ: ◦ コンペ参加者のコード submit ◦ データセットの更新
  13. Google Cloud Platform の full managed なサービスを繋ぐ形 なサービスに 処理を委ねる •

    非同期メッセージングサービス • Pub/Sub などをトリガーに関数を実行するサービス
  14. • 学習・評価で利用する Docker イメージのビルド • Docker コンテナを使った学習・評価・成果物生成処理の実行

  15. None
  16. • Hekaton の pipeline 中では分岐や待ち合わせがほとんど存在しない ◦ 依存関係が煩雑になりやすい data pipeline はスコープの外

    ◦ ここでの併用などは十分にあり得る • 足りるのであれば full managed に寄せた方が運用コストは低い
  17. • Submit 時に Docker イメージが残る • 各サービスで作成したデータセットの名前とバージョンを Hekaton の DB

    に 登録できる • どの学習コード (Docker イメージ) とどのデータセットで作られた モデルか後で追うことができる • 学習済みモデルとコンペのバージョンからどう作られたか追える
  18. None
  19. 社内ユーザーには CLI として提供 $ hekaton --version Hekaton CLI 0.1.9 •

    Kaggle CLI に近い感じ
  20. 予め用意された competition name を指定してプロジェクトを作成 $ hekaton init --competition-name sample-competition コードを書いたらバージョン管理のタグを付けて

    submit • 普通のコンペと違って CSV ではなく、コードと Dockerfile を submit する $ hekaton submit --tag v1
  21. • コンペごとにルールが実装されている • たとえば「Trainer クラスと Predictor クラスを実装してください」など

  22. competition name を決めてプロジェクトを作成 コンペ用のコードとデータセットが準備できたら publish

  23. 学習・評価・成果物生成の 3 つの処理を用意 参加者の を利用 細かい処理は で サポート 学習に使って欲しいデータを用意 にデータを渡す

    Hekaton ではエントリポイントと呼ぶ • 参加者の学習モジュールに学習用データを渡す • 保存したモデルと参加者の推論モジュールに評価用 データを渡す • 保存したモデルと参加者の推論モジュールから成果 物を生成する ◦ バッチ推論の結果や API サーバー用 Docker イ メージなど 学習処理の例
  24. • Hekaton の DB にデータセットの name とバージョン管理の tag を登録 データセット作成処

    理を日時で実行 Hekaton の Pub/Sub に新しいデー タセットの情報を publish
  25. • 緩いルールの範囲内で自由にコードを書いて精度向上に注力できる • 書いたコードをほぼ手直しゼロでプロダクションに持っていける • 全ての参加者がルールに従ってコードを書くので同じ手順で実行できる ◦ このコードどうやって実行するの?が発生しない • 定期的な再学習など機械学習プロジェクト共通のところは

    Hekaton が面倒を見てくれる • 他のコンペの設計を参考にして知見を横展開しやすい
  26. None
  27. • ライバーとリスナーの距離の近さが良いところ • 推しのライバーを見つけられるかで 定着率に大きな差が出る! ◦ おすすめのライバーを表示する タイムライン改善が非常に重要 実際に Hekaton

    を使って開発・リリースまでを行った https://www.pococha.com/overview/how-to
  28. • データサイエンティスト 2 人 (コンペ主催者 + 参加者) • ML エンジニア

    1 人 (コンペ主催者のサポート) • モデル開発開始から 1st リリースまで 2 ヶ月程度 ◦ Hekaton 本体の大規模アップデートと並行して行ったので少し長め • 週 2 日程度のペースで継続的にモデルを更新 ◦ 推論サーバー用の Docker イメージは毎日新しいデータで自動生成 ◦ 評価値などを確認して問題なければデプロイしている
  29. None
  30. • Kaggler の良さを活かす ◦ 十分な自由度を確保して限界まで精度向上ができるように • 役割の切り分けを明確に ◦ データサイエンティストがモデリングに集中できるように •

    データサイエンティストと ML エンジニアのコミュニケーションを スムーズに ◦ プロダクション投入のためのコード修正が一番大変 ◦ これをコンペのルールという形で吸収
  31. • 将来的には 1 ヶ月程度のスパンで新しい機械学習の挑戦ができるような 世界を目指したい ◦ 試行錯誤の回数はとても大事! • データサイエンティストがモデリングに注力しているだけで自然と production

    ready なものができるように ◦ Kaggler が一番得意な分野で実力を発揮できる!
  32. 藤原 秀平 (FUJIWARA Shuhei) • AI システム部 ML エンジニアリンググループ ◦

    Hekaton プロジェクト Tech Lead • Google Developers Expert