はじめに

m3とFringeが主催したMLOps勉強会に参加した。
MLOpsの勉強会というよりは、gokart(ml pipline tool)の宣伝だった笑
- とはいえ、titleがgokart meet up的なのだったら参加しなかったと思う。
「Web engineer自身がMLOpsになることだ」のキャッチコピーはいずこへ？

結論

六本木のビルがすごくて妬ましかった。
マイセンのカツサンドを二つくれた。
内容はかなり有益だったので良かった。
懇親会でM3の偉い人と話せたのは特に良かった。
- その人に限らず、m3やFringeの人は海上の雰囲気を良くしようと心掛けてるのを感じた。
最近piplineをちょこちょこ作ってたので、gokartを使ってもみたい。
もう少し規模の大きいpiplineツールを作ってみたいなという気にもなった。

以下、内容

詳しい内容はtwitterとかで、スライドが上がっているのでそっちを参考にしてね。

gokartを作った話

経緯

アルゴリズムの開発でPDCAを高速に回したい
- 前処理の変更や追加
- データパイプラインの変更
パラメータが変わったら、そこだけ再計算したい
luigi（既存のpipline tool）をラップしてgokart を作った

効果

もともとの課題
- mlはできるけど、設計が苦手な人が多かった（大きいクラスを作っちゃうとか）
- 設計レビューは難しい
gokartにより以下ができるようになる
- 書き方を統一
- タスクの使いまわし
- 単一責任の原則の強制
- gokartのパイプライン上で一部pandasのテストをしてくれる（型チェック）。
上記による効果
- 複数のプロジェクトを同時に開発したいときなど、モデルの共通化をしたい場合がある。
  - モデルをidで管理してくれる
- キャッチアップのコストを下げることができる。
  - cookiecutterで構成を作れる。
- 本番落ちた時に対応できる。
  - 中間生成物をS3に保存している。
- 色々、共通化したい。

今後

単体テストを楽にしたい
documentを作る

その他

sterほしい

機械学習を無理なく広告システムに導入する

前提

広告配信のシステムに、機械学習を乗せた話
ユーザー状況をもとに興味がありそうな広告を配信する。
click率を上げることが効果的
- 統計的にもできるけど、機械学習をつかうと、精度以外でも使いたいパラメータを柔軟に使えたりする。
広告配信はビジネス上の制約もある（応答時間: 20ms）。
- モデルを軽量化する必要がある。

開発時に気を付けたこと

ML専門じゃない人とシステム開発を一緒にやる必要がある。
- ＊この辺の話を懇親会で聞けばよかった...。
- 定量的に話すことで、認識の違いをなるべく減らした。
  - 特に、数字だけ言うと人によって単位を違ってイメージしていたりする。
- 配信側が対応するのか、ML側が対応するのか
ログ出力が可能かどうかを最初に考える必要がある。
- システム側で必須か、ＭＬ側のために取る必要があるか。
- ＊この辺も最近気になっていて、システム開発してからＭＬやりたいっていう要望への対応を考えると、あらかじめ必要そうなものは取っておくべきなのか、どこまで考慮すべきなのかってのが気になっている。
トラブってもなんとかなる設計を心掛けた。
- ストレージを一枚はさみ、ML側のサーバがとらぶっても、配信側のサーバが生きていれば動くようにした。
モデルの特徴量を減らした。
- l1正則化とかって手もある
修正のたびにデプロイしたくない。
- 大量のログを効率よく学習する
- 並列実行できるおうに、モデルを複数つくって平均するようにする
  - 特徴量ごとにcsvファイルがあって、それをzipにまとめて学習してる
  - 最新のフォルダと古いフォルダが別のストレージにある。
AWS Step Function（＊よくわからなかったけどメモ）

gokartを利用したワークフローの運用と課題について

機械学習ワークフローがサポートすべきところ

データ、特徴量加工の冪等性（べきとうせい）
モデル感の依存性
スケールするか
保守性
説明可能性
gokartは以下をサポート
- 特徴量加工
- モデルの保守性
  - cookiecutterでフォルダ構成を共通化できる。
  - thunderbokt（ハッシュで登録したモデルや特徴量を管理できるって感じかな）
  - redshells（なんぞ？）

gokartがサポートしてない

複数のモデルを組み合わせたい
- １プロジェクト１モジュール
hadoop, sparkの分散学習サポートは強くない
guiはなし

唯一の欠点

github ster数が少ない

使い方とか

cukkiecutterで保存先はS3とか手元とかに決めれる
task管理例
- taskA: データをロード
- taskB: データを学習
- taskC: taskAとtaskBをdump
thunderbolt でpandasでロードできる
luigiとの比較：
- パラメータ管理を自分で記述する必要がある。

前提と課題

１人１プロジェクト
バッチ推論がメイン
クラウドサービスは多くない
- ターゲットユーザが絞られている場合がいいのでは？
タスクＡとタスクＢでメモリが違うときとか、本来わけるべき
- 可視化がない（feature inportanceとかは？っておもったけど、難しいのかな）
中間ファイル、キャシュの取扱いが難しい
- 中間ファイルの一部が破損していてもそれが気付きにくい。

その他

Ｍ３テックブック２、piplineのまとめを技術書展で出すらしい。
starがほしい

gokart導入のきっかけと、運用の現状

きっかけ

mlppで知った
- Airflowは重そう。
- luigiで特徴量の管理はできた。
uniposの機能のα版に使う
- 分析するときに同じような処理をしている。
csvが増えていく。（＊めっちゃわかる）

gokartできること（luigiでも可:L, gokartで可）

Ｌ：taskuごとにコードが分離されている。後からの修正が容易。
- コードをきれいにするのは後回しにできる。
- 各タスクが何を受け取って、何を吐き出すかが明瞭
Ｇ:outputを書かなくてもpickeに吐き出される。
Ｇ:parameterは記述の必要があるため、意識するようになる。
- しらなくてもいいパラメータをバケツリレーしなくなる（＊たまにやってしまう）
- パラメータによって、ファイル名にハッシュ値がつく
  - thunderboltで管理できる。
  - sphonxを使ってdocstringからhtmlを自動生成してくれて、html管理できる。

その他

star ほしい、contributeしたい
＊懇親会で話すネタを提供してくれたのが結構良いと思った。

懇親会

OSS開発を推進しているとのことだけど、どういう経緯でそうなったの？
- Ｍ３はもともとエンジニアがいなくて、やりたいことがあるんだからエンジニアは外注すればよいという考えで始めた。
  - が、開発をしてみると大失敗した。
    - 顧客が本当にほしかったもののブランコ状態
- そこで、やっぱり社内でエンジニアが必要だねとなった。
  - それで採用したエンジニアが、ＯＳＳの権威みたいな人だった。
    - 我々もＯＳＳ使って開発しているのだから、他のＯＳＳに貢献するのは当たり前だよねという考え。
- 現在、ＯＳＳ開発を促進しているというよりは、ＯＳＳ開発してもいいよというスタンスが近い。
  - githubで役員がスポンサーになってる
- 顧客のプロダクトの場合、難しいかもしれないけど、うまく切り分けてあげるのがいいのでは。
AUCが何％ですとか、特徴量のマトリックスが必要で人がわからなくても済む場合にも、効果をわかりやすくするために、あえて人がわかる形にしてあげることで、説明しやすさを増して、顧客にアプローチしやすい工夫をする。

参考

pythonのpipline比較（qiita）