機械学習工学研究会 現場を交えた勉強会 #1 勉強会メモ

実施概要

詳細はこちら

実例をベースに、皆で機械学習システムのあれやこれやを議論します。

近年、機械学習・深層学習の発展によって、機械学習を利用するシステムが急速に社会に広がってきていますが、開発・テスト・運用の方法論は未だ確立できていません。そこで、従来の「ソフトウェア工学」に対応するような「機械学習工学」が必要であると考えていますが、活きた工学にするには、現場との密な交流が不可欠です!

本イベントでは、機械学習システムの現場のエンジニアの方に登壇いただき、みんなで議論することで、学術領域と現場との交流を促進できたらと考えています。

各発表

事業会社における機械学習システム開発・運用の課題と展望

田中さん（株式会社リブセンス)より

資料はこちら

発表を受けて

話を聞いていて、私自身も機械学習を取り扱う際に、「あるある」な課題にとても共感した。

特に意識しておくべき・していきたいと思った点は以下のもの。
(勉強会のラストの討議でも話題に挙がった)

• 機械学習を扱うコードのテストや検証の大変さ

• モデルが与えるビジネス収益寄与の不透明性

SIer出身のエンジニアが機械学習を取り入れたASPサービス開発で学んだこと

柳原さん （株式会社ブレインパッド）

発表を受けて

ご自身の経験から、業務システムと機械学習システムの違いを定性的にまとめられていた。
例えば、システム化の目的の違いについては、以下のようにまとめられていた。

• 業務システム
• 業務の効率化が目的
• 機械学習システム
• サービスに対して付加価値を提供することが目的

ビジネス上の収益のために、サービスへの付加価値の在り方が不明瞭で、仕様定義が難しいのは確かになぁという感じ。

後は、ブレインパッドで開発しているレコメンドエンジンのRtoasterでは、
外販先のサービスごとに連携方法を変える必要があるため、
コアとなるレコメンドエンジン部分と連携方法のコンポーネントを分離しているらしい。
自社サービスへの利用ではなく外販が目的の開発ならではの工夫も感じられた。

データサイエンティストとエンジニア 両者が幸せになれる機械学習基盤を求めて

田村さん（株式会社リクルートライフスタイル）

発表資料はこちら

発表を受けて

機械学習システムの開発には、ビジネス・データサイエンス・エンジニアリングの幅広いスキルが必要になり、それぞれの専門家が専念しやすいような共通基盤を用意するという話。

API運用の仕組みを共通基盤化することで、データサイエンティストが簡単に機械学習プログラムを運用することができるようになった反面、属人化や野良APIの蔓延が起きたそう。

整備した分析基盤を用意することによって、データサイエンティストは、開発したモデルを運用するための手直しなどの手間がなくなり、自身が専念すべき分析やモデリングに注力することができる。
しかし自由度や透明性を追求する反面、運用する立場のエンジニアは、セキュリティやパフォーマンスをトレードオフにしているので、双方の間でコミュニケーションをとって落としどころをうまく見つけようというまとめ。

討議

3者の発表を受けて、質問をベースに討議を行った。
それぞれの質問の中で上がった話を抜粋。

モデル開発者の属人化を防ぐための取り組みについて

• dockerで環境を構築しており、開発者自身がそれを用意している。
• デプロイ前にレビューを行ったり、知見の共有を行う。また、環境は基本的にGCPで統一されているため、属人化は起こりにくい。

モデルの精度が低くて実運用が厳しかった話について

• レコメンドの際に、モデル精度は高いが、各ユーザで似通った結果が出てしまった。ビジネス的な効果は見込めない。

• Rtoasterでは、モデルが生成したレコメンドリストをビジネスルールで調整する仕組みを導入している。

• モデルの精度が高いが、ビジネス上の価値に繋がらなかったケースがある。

• モデル自体の精度より、ABテストなど実運用のテストの結果を重視している。

機械学習周りのコードの品質の低さにより発生した障害の事例について

• 想定していないデータが入ってきたために、モデルの学習が終わらなかったこと。

• サービス開発との認識合わせがうまくいってなかったことで、モデル学習時にシステム終了するリスク発生。

• データサイエンティストとエンジニア、それぞれ立場の違いから、認識を合わせることが難しい。

• データサイエンティストが作成した大量データを入力する検証用のコードが、実運用のエンジンにデプロイされており、高い負荷がかかった。

単体テストのテスト評価基準の決め方

• 学習プログラムは、IFの確認を行う程度で、あまりできていない。

• 前処理のコンポーネントなど、共通化されているライブラリは、単体テストを実装している。後続の処理は、型の確認に留まっている。

• クラスタリングやランキングなどの結果は、入力データから正しそうな結果が出ることを確認している。

学習用コードのテストしているのか

• PoC段階ではテストコードは実装せず、開発が始まった段階で、テストを実装し始める。

• 定期運用が入るコードはテストを実装するが、アドホックに使うコードはコストに見合わないので実装しない。

モデルの仕様を追加、変更はどのようにしているか

• モデルに導入する特徴量をパッケージ上で取捨選択できるようにしている。

• 基本的に、モデルはABテスト後にデプロイをするため、作りこみの過程で特徴を変えることを多く行う。

データに対する仕様変更の対応はどのように行っているか

• モデルの学習時にエラーが起きることによって気づくことがある。

• データ基盤を運用しているので、データがかわることによるエラーはあまり起きない。