Machine Learning Casual Talks #7に参加してきました #MLCT

データ分析

#レポート

#機械学習

じょんすみす

2018.11.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、小澤です。 2018/11/20に開催されたMachine Learning Casual Talks(MLCT) #7に参加してきましたので、その報告を書かせていただきます。

Machine Learning Casual Talks #7 - connpass

タイムテーブルと発表資料

発表はセッション2つとLT3つの構成となっており、その後セッション発表者でのパネルディスカッションが開催されました。なお、発表資料はconnpassにも記載されていますが、発表資料は基本的に公開予定となっております。資料が追加され次第、適宜本記事にもリンクを追加していく予定です。

セッション

タイトル	発表者
The Road to Machine Learning Engineer from Data Scientist	@_stakaya さん
ABEJA InsightにおけるML活用サービスのデリバリー	@xecus さん

LT

タイトル	発表者
Jupyter だけで機械学習を実サービス展開できる基盤 ~ サイエンティストとエンジニアの共生へ ~	@techeten さん
機械学習基盤を一人で構築するということ	@yukiyan_w さん
JapanTaxiにおける機械学習活用事例	KiichiUeta さん

MLCTとは

最初にMLCTの創始者である @chezou さんより、MLCTをはじめた理由に関しての説明がありました。

この中で「カジュアルトークとは」と「MLCTは何を扱う会なのか」は毎度おなじみの重要な話ですが、以下のようになっています。

今でこそ、実システムでの運用を含めた機械学習システム全体をどのように設計・構築していくかという話を様々な場面で聞くようになりましたが、第1回開催時には、まだまだそのレベルまで到達している例が少ないこともあり、あまりそういった話が世の中に出てこないという時代でした。実際第1回はMLCTは有名な論文であるMachine Learning: The High-Interest Credit Card of Technical DebtをGoogleが出しすよりも前でした。

セッション内容

The Road to Machine Learning Engineer from Data Scientist

最初のセッションは「The Road to Machine Learning Engineer from Data Scientist」となります。

内容としては「おセンチなポエム」と本人は言っておりましたが、データサイエンティストや機械学習エンジニアが今後のキャリアを考えるうえで参考になる内容となっていました。この業界では比較的よくある話として転職によるキャリアップや年収云々といった話が、ありますが実体験に基づく内容となっており、まだまだ定義のなかなか定まらない"データサイエンティスト"が今後の人生を考えるきっかけにもなる内容であったと思われます。

お題として、以下のような内容を挙げていました。

「俺に勝手にラベルを貼るんじゃねぇ」ということで、"ラベルを貼ることで、それに応じた価値が決まる"という話をしていたのが印象的でした。例えば、データサイエンティストという肩書であればそれに応じた給料レンジが決まるなど、"その人"ではなく"その肩書"が価値を決める基準になってしまうとのことでした。

本人の経歴としては以下のように、もともとソフトフェアエンジニアからこの業界に入ったようです。

これまでの経歴と転職のタイミングということで、転職しやすいタイミングというは景気で変わるということです。

転職したタイミングとしては、上記のグラフで矢印が付いたタイミングとなっており、いずれも景気によって有効求人倍率が高い状態とのことでした。

クオンツとして働いていた期間に関してですが、新卒後転職したのちはリーマンショックの影響もあり中途採用市場が凍結されてていた時代ということです。

この間主にやっていた仕事内容としては、Excelを使った分析やそのためのAdd-in作りがメインということで、あまり楽しい内容でなかったものの、給料が年次で決まるため不景気下でも上がり続けるし転職市場は凍結されている状態のため、逃げ道はないという状態だったとのことです。

この時代に学んだこととして、いくつか挙げているものがありました。

中でもいくつか印象深かったものを挙げると、まず景気が(我々庶民の)命であるという点です。

また、ビジネスとは"法律(ルール)に違反しないようにお金をたくさん稼ぐゲーム"である、という考え方は、ビジネスに鈍感になりがちなエンジニアは頭の片隅に常に意識しておいてもいいことだと思います。

その後、景気の回復とともに「楽しいことをしたい」ということでエンジニアへの転職をしたとこのことです。

ここで、"高給=麻薬"と話しているのは印象的ですね。

機械学習エンジニアとして学んだことにあげている内容は、機械学習エンジニア以外でも意識したほうがいい内容といえるでしょう。

最後に機械学習っぽいことということで現在どのようなことを行っているかについて簡単に解説していました。こちらはMLCT開催日(2018/11/20)の翌日、より詳細に話すとこのとですが、この発表時にはすでに受付が終了していたようですｗ

詳しく知りたい方は、そちらに参加した人に聞いたりしてみてください。

ABEJA InsightにおけるML活用サービスのデリバリー

2つ目のセッションは「ABEJA InsightにおけるML活用サービスのデリバリー」となります。

発表内容としては、Abejaさんでの取り組みとそれを実現するうえで課題やその解決方法となっています。

AbejaさんはIoTと画像解析を使った仕組みを実店舗に対して導入している企業となるため、そこでのテクニックがふんだんにちりばめられた話となっていました。

Abejaで実際に行っている業務内容して、いくつかの事例が挙げられてました。

こちらは工場で作られた製品の不良チェックを自動で行う仕組みになっています。工場ではどんどん機械化・無人化が進んでいますが、それでも最後の品質チェックにはどうしても人間が確認する必要があるという状況があるそうです。そのため、メインとなる生産ラインを自動化しても最後には人手が必要になるためなかなかコストが抑えられない、という課題を解決することが可能になる技術とのことでした。

こちらは小売店に設置されたカメラの画像解析で、音連れたお客さんの性別や年齢を推定することが可能になるという仕組みです。こちらの小売店の画像解析の仕組みを使って、リアル店舗でもECサイトと同じくらいのデータが得られ、この後の分析に使えるダッシュボードも用意されています。

こちらの仕組みは、さらに新機能としてリピータ分析や同線分析といったことも可能になっているようです。

そんなAbejaの利用規模ですが、動画のトラフィックは1日10TB, 動いているコンテナ数は7000以上になるとのことです。

ここからは、実際にサービスとして提供するに際にして気にかけなけなければならない点についての話となります。実運用しているからこそ見えてくるさまざまな課題や顧慮しなければならない点といった知見が惜しみになく紹介されました。

まず、設計の重要ポイントの1つ目としてデータデリバリーの観点です。

ここで挙げられている点はとしては、

安定的かつ安全なデータ転送の仕組み
多様化するデバイス・アルゴリズム・モデルに柔軟に対応する仕組み作り

という2点となっています。

いずれも実店舗での運用がなされているからそこ初めて見える課題であると感じました。

実際に起こった問題として、

店舗契約のネットワーク環境が障害を起こしたことによる影響
既存ネットワークや導入ソフトウェア、セキュリティポリシーとの干渉
導入店舗増加によるデバイスの多様化

などがあげられていました。

続いては運用の観点での話となります。

こちらは

デバイス・AIの品質見える化 + 異常値検知
デバイス管理・設定管理機能の提供
AI関連設定の管理機能提供

となっています。

実際に発生しうる問題としては

デバイスの故障
- 環境依存の群発故障の原因特定は困難
オクルージョンや逆光による映像品質低下
デバイス増加による設定の管理コスト増加

特に実店舗での運用では電源やネットワーク機器の人為的な断線(コンセント抜かれちゃった)とかも多いようです。

オクルージョンや逆光は時間帯や商品の配置換えなどで起こるようです。特に注意が必要なのは七夕の笹や短冊による影響とのことでした。

続いて、システムがどのように構成されているか、という話となります。システム全体像としては、以下のようになっているようです。

この中で映像録画システムは以下の3つに分かれており、データのフローを監視しながら、それぞれがコンテナとして動いているとのことでした。

暗号化接続終端コンテナ
録画コンテナ
動画変換コンテナ

映像解析システムも同様にデータフロー監視とともに精度監視も行っているようです。そのなかで、顔画像・特徴量抽出とそこから先の年齢・性別・リピータ判定の処理に分かれています。

Abejaの特徴として、なんと自身でISPバックボーンを持っているとのことでした。映像解析には多大なトラフィックを使うとこともあり、これによって既存のISPの影響を受けることなく安定した回線の提供を行っているようです。

最後にバックエンドの特徴としていくつもの要素を挙げていました。

デバイス・アルゴリズムに応じて柔軟にカスタマイズ可能なサービス基盤
導入・運用を円滑にするために、社内サポートメンバ用のシステムがある
機材用に独立したLAN環境
Design for failureを前提とした仕組み
- 機器の故障はどんなに頑張ってもゼロにはできない

LT

LTは3本立てとなっており、いずれもLTで話すのはもったいなく通常のセッションでもいいレベルの内容でした。

Jupyter だけで機械学習を実サービス展開できる基盤 ~ サイエンティストとエンジニアの共生へ ~

最初は「Jupyter だけで機械学習を実サービス展開できる基盤 ~ サイエンティストとエンジニアの共生へ ~」というタイトルでの発表となります。

ご存知の方も多いかもしれませんが、あのアレです。

Jupyter だけで機械学習を実サービス展開できる基盤 - Tech Blog - Recruit Lifestyle Engineer

さまざま施策を素早いサイクルで回していきたいというのは多いことでしょう。そんなサイクルを素早く回すために、なんどもA/Bテストを繰り返すわけですが、機械学習システムとなるとかかわる人のロール的に難しいことも多くあります。

データサイエンティストやプランナーは企画やモデリング・A/Bてすとの分析に専念すべきで、エンジニアリングにそれほどパワーを咲くべきではない
エンジニアは企画ごとにカスタムでシステムを作ると負担増で運用ができなくなる

これを実現するために、データサイエンティストは自走で、エンジニアの手作業が不要環境が欲しかったというのがモチベーションとなっているようです。

システムの詳細は上記の記事に書かれているので詳細は割愛しますが、今回の仕組みは既存のシステムに乗せるのではなく、ビジネス要件を満たす仕組みを構築しつつ、将来いいものが出てきたときに備える仕組みとのことでした。

機械学習基盤を一人で構築するということ

LT2つ目は「機械学習基盤を一人で構築するということ」というタイトルでの発表となります。

タイトルからして苦労してそうな内容ですね... こちらの発表者はTimeTreeというサービスを開発しているとのことで、予定を適切にカテゴリ分けしたいというのが動機となっているようです。

関係者に機械学習のことを知っている人がいない中で、機械学習の勉強から始めて、タスクの洗い出しや見積もり、教師データあつめ、モデリング、インフラ構築とリリースまでを3か月でおこなったとのことでした。

実際に作成した基盤は以下のような仕組みになっていたとこです。

さらにすごいのは、発表者はリリースしただけで終わらない仕組みまで考えてやっていました。

やったことない技術をプロジェクトかしてもPoCの延長的に場当たり的になるのを防ぐため
- 見積もりとタスク洗い出しに時間をかける
- それによってリリース後のロードマップもぼんやり浮かぶ
一人プロジェクトなので技術的負債を残さないように工夫する
- やったことを記録に残す
- 関係者がいないので、誰も読んでくれない -> 口頭での共有も行う

全く知らない状態からここまでできるのは本当にすごいことですね。