機械学習関連の開発を 効率化した話

Transcript

1. 機械学習関連の開発を
   効率化した話
   エムスリー株式会社 西場正浩(@m_nishiba) MLPP #2
   会場&フードスポンサー: SmartNews
   

   View Slide

2. 自己紹介
   ● エムスリー株式
   ● AI・機械学習チーム
   ● 機械学習エンジニア
   ● SNS
   ○ https://twitter.com/m_nishiba
   ○ https://note.mu/nishiba
   ● 興味あるキーワード
   ○ 自然言語処理、推薦システム、開発効率化、チームマネジメント、 PdM
   ● 資料は公開済み。手元でも確認しながら聞いてください ~
   

   View Slide

3. 今日話すこと
   ● エムスリーの開発体制。
   ○ 1アルゴリズム、1MLエンジニア
   ○ 1MLエンジニア、複数アルゴリズム
   ● 開発で感じた難しさ。
   ○ データ取得のための SQL
   ○ クラス設計
   ○ コードレビュー
   ○ パラメータとモデル・データの紐づけ管理
   ○ 前処理後データの再利用
   ○ データのバージョニング
   ● 行った解決方法。
   ○ luigiをラップしたgokart(GitHubで公開。pip install gokart)
   ○ データ取得タスク群の m3mushroom(非公開)
   

   View Slide

4. エムスリーの機械学習チームの開発体制
   ● 状況
   ○ MLエンジニアは3人程度
   ○ 設立2年弱
   ○ プロダクト・プロジェクト数は 19程度
   ○ 自然言語処理、推薦がメイン
   ● 基本は1アルゴリズム、1MLエンジニア
   ○ 相談や議論はする
   ○ 責任を持つ人、実装する人は基本的に 1人
   ● 1MLエンジニア、複数アルゴリズム
   ○ 同時に複数のアルゴリズムの改善や開発を行うこともある。
   ○ 新規開発中に他のプロジェクトが ABテスト中&要改善
   

   View Slide

5. プロダクトの開発順序
   ● なるべく共通部分が多くなるようにプロダクトを作る。
   ○ やらない例: 機械翻訳+非テキスト系のリコメンド +画像診断
   ○ やる例: テキスト系のリコメンド、テキストの類似度、テキストのタグ付け
   

   View Slide

6. 開発で感じた難しさ
   

   View Slide

7. データ取得が大変
   ● データが色んなところにある
   ○ オラクル、Postgres、BigQuey、社内API
   ○ 2000年創業で20サービス以上あるので・・・
   ● 色々Joinやfilterしないとモデル開発上意味のあるデータにならない。
   ● サービス横断で分析するためにはフォーマットが揃っておらず色々加工する必要がある。
   ○ すごいSQLを書かないと・・・
   

   View Slide

8. ● そもそも設計難しい・・・
   ● 他のプロジェクトでも使えるようにしたい。
   ● システム開発よりMLに強みがある新卒も入社後すぐに開発する (本番で動く)
   ○ 1アルゴリズム、1MLエンジニア
   ● おれおれクラス群のコードレビュー &保守は辛い・・・
   ● ログ設計難しい、解読辛い。
   設計が難しい
   

   View Slide

9. パラメータとデータ/モデルの管理が大変
   ● pickleを作ったときのパラメータ等を一緒に管理するのが大変
   ○ e.g. 極端の話、雑なナンバリングになる
   ■ data/some_data.pkl
   ■ data/some_data_1.pkl
   ■ data/some_data_20190530.pkl
   ● (試行錯誤中)昨日、めっちゃ良いスコアが出たけど再現できない !!(パラメータが分からない )
   ● ちょっと前に他のプロジェクトで作った word2vecを使いたいけど大丈夫だよね ??
   ● 本番でエラーがでたけど再現できない ! DB変わっている??
   

   View Slide

10. 解決方法
    

    View Slide

11. パイプラインのためのパッケージ Luigi を使う
    ● バッチ処理のためのパイプラインを構築するためのパッケージ
    ○ Spotifyが作っているOSS
    ○ https://github.com/spotify/luigi
    Task
    BiqQuey
    API
    DB
    S3
    

    View Slide

12. ● Luigiを使うことのメリット
    ○ classの設計から解放される !
    ■ requires, output, runの3つの関数を書けば良い !
    ○ 設計が統一される!!
    ■ 新しいメンバーもすぐにキャッチアップできる !!
    ■ コードレビューが楽々
    ○ ログがすごく読みやすい !
    ■ どのタスクが成功したか ?失敗したかが一目瞭然
    ○ 修正後の再実行が簡単
    ■ 途中のタスクが失敗 → コードを修正 → 落ちたところから実行される。
    

    View Slide

13. さらにgokartを開発
    ● Luigiをラップしたパッケージ
    ○ エムスリーが作っている OSS
    ○ https://github.com/m3dev/gokart
    ● gokartを使うことのメリット
    ○ 更にコード量が減らせる
    ■ 保守コスト等も減少
    ■ 特にファイルの入出力周り
    ○ (中間)出力ファイルの管理が楽
    ■ タスクのパラメータによりユニークなファイル名になる
    ■ ファイルが生成されたときのパラメータが保持される
    ○ 各タスクの実行時間を確認できる。
    ○ 出力をs3にするかローカルにするかをパラメータ一つで切り替え
    ○ ジョブ終了時にslackに通知。
    

    View Slide

14. データ取得を共通タスク化
    ● gokartを使ってデータ取得を共通タスク化した。
    ○ e.g.
    DownloadNewsItems(
    from_date=date(2019, 1, 1),
    to_date=date(2019, 1, 31))
    ○ SQL等を意識する必要がない。
    ○ Pandas.DataFrameとして出力される。
    Task
    BiqQuey
    API
    DB
    

    View Slide

15. 質問どうぞ〜
    

    View Slide