Mlops | Democratizing Data

機械学習工学研究会の「機械学習基盤本番適用と運用の事例・知見共有会」を開催しました

Tue, 10 Nov 2020 22:18:19 +0900

@masaru_dobashiさん共同で、機械学習工学研究会（MLSE）本番適用のためのインフラと運用WG主催の、「機械学習基盤本番適用と運用の事例・知見共有会」をオンライン開催しました。

イベントのconnpassは以下のリンクです。機械学習基盤本番適用と運用の事例・知見共有会

@wakame1367さんによるツイートのまとめはこちらです。機械学習基盤本番適用と運用の事例・知見共有会ツイートまとめ

YouTubeの動画

YouTube Liveの配信はアーカイブとして見ることができます。

当日の資料

感想

今回、僕は企画とCfP系のとりまとめ、当日は配信担当をさせていただきました。当日の司会進行は土橋さんにおまかせをしてしまったのですが、いつもながら質疑応答の仕切り力は素晴らしい限りだなと思いながら聞いていました。

今回のトピックは、機械学習チームが解散したという衝撃的な話からはじまり、NLPを中心とした機械学習基盤、リアルタイム予測基盤、モバイルやエッジ向けの機械学習など多岐にわたる発表が充実していました。個人的に特に思ったことは、一言に機械学習基盤といっても組織や規模、フェーズに応じたアーキテクチャが採用されているというように感じました。これはMobility Technologies大西さんの発表で、Kubeflow Pipelinesを選んだ理由に「ブラウザベースでパラメータを入力できること」ということがありました。

「テストごとにパラメータを入力する必要があったが、AirflowはそういうWeb UIがない。Kubeflow Pipelinesはそれができる」これは、ソフトウェアエンジニア以外の参加者がいるからですね #MLSE
— Aki Ariga (@chezou) November 6, 2020

当たり前ではありますが、システムの要件は組織の体制やビジネス要件に規定され、それが機械学習基盤でも変わらないということが改めて実感できました。

今後も、MLSE 本番適用のためのインフラと運用WGではこうした機械学習基盤のアーキテクチャやパターンを明確にするために、討論会などの活動を続けて行きたいと思います。

機械学習工学研究会（MLSE）の夏合宿 2020で本番適用のためのインフラと運用に関する討論会を開催しました

Sat, 11 Jul 2020 18:00:00 +0900

@masaru_dobashiさんとMLSEの夏合宿で、本番適用のためのインフラと運用WGの討論会を開催しました。 WGのモチベーションはMLSEのサイトをご確認ください。

MLSEの夏合宿自体の概要は、@ysk_motoさんがまとめてくださった記事がわかりやすいと思います。Discordを中心に130名を超える参加者がオンラインで様々な議論をするというスタイルでした。

機械学習工学研究会（MLSE）夏合宿　2020に参加しました

実は我々のWGの討論会自体は第一回はオフラインで開催しました。そちらのまとめはGitHubにあります。よければ御覧ください。

今回の討論会のまとめは、以下の2つのトピックについて議論をしました。

機械学習における監視・観測とアーキテクチャ例
責任分解とシステム

もう少ししたらGitHubのレポジトリにまとめを上げる予定ですが、その中から興味深かった話題を紹介したいと思います。

COVID-19の影響は予測モデルを更新し続けることである程度抑制できた

これは、PFNの丸山さんが話題に出してくれたのですが、deeplearning.aiのnewsであるThe Batchやこの記事でも言及されていた、「COVID-19によって人間の行動が変わってしまって予測に対する影響は出なかったのか？」という問いが投げかけられました。その中で、ある広告系の企業の参加者が、「入力データもモデルも毎日更新しているので、現状は対応できていると考えている。毎日モデルを更新するのが大切」という知見を共有してくれました。

もちろん、劇的に前提条件が変化をする問題ではなかなかそのままのロジックや特徴量が使えないということもありうるとは思いますが、モデルを継続的に学習しつづけることで、変化に追従するというのは長期間機械学習システムを運用していく上でなくてはならないのだと改めて思いました。

学習したモデルは、組織のありかたで渡し方はおろか渡せるものも変わる

予測モデルを誰が学習するのか、という話題のなかで、小さなチームでは学習も予測も一人でやるという状況が出たのに対して、日本の大企業では特に研究開発の会計的な事情で、研究所で学習したモデルや学習をするためのコードを渡せず仕様書のようなドキュメントで開発部門に渡すしかない、という話が出ました。言われてみればそういうケースもありうるのかと思いつつ、部門の切れ目でAPIを用意するという立て付けも取れるかもしれませんが、研究所で学習や予測APIを提供するといった体力があるところも限られてくるとは思うので、日本の会計や税務的に難しさが発生するのかと、ハッとした瞬間でした。

モデルのリネージは決めてとなるOSSがない

これは討論会で出た話では有りませんが、実験管理は徐々にOSSで出てきているが、モデルの作成に至るまでのリネージはOSSとしては決定版がないよね、という話が何度か出てきました。もうシャットダウンしてしまったDotscienceではこうしたリネージを可視化する機能を持っていましたが、まだOSSでは良いものは私の知る限りではないように思います。こうしたこともあり、サイバーエージェントではモデルのリネージを管理するためのツールを内製で開発しているそうです。OSSとしてカバーするのは難しいかもしれませんが、各社が自社のサービスの上でのソリューションを提供してくるかもしれません。

夏合宿全体を通じた感想

Discordを通じた議論や発表はとても体験としてよかったと思います。特に、人工知能学会のポスターで苦痛だったExcelで書かれPDFで出力されたパスワード付きZoomのリンクをクリックして移動するという地獄の体験をしたあとでは、Go Liveでどういう発表をしているのかもプレビューで覗けますし、軽量な音声だけで議論も進むので活発な議論ができていたのではないかと思います。

ただ、会社のポリシーでP2Pのプロトコルを使っているDiscordのアプリは使えず、会社のMBPでは非力だったためか画面共有の表示が安定してされなかったのは難しいところではありました。GPUマシンでは安定しているので、MBPでは少し厳しいですね。

我々の討論会ではZoomを使って議論をしたのですが、Muralと呼ばれるMiroのようなオンラインホワイトボードも使っていたので、複数のグループに分かれて付箋を貼っていくスタイルでも良かったかもしれません。

ただ、ご多分に漏れずDiscordの参加人数が10人を超えてくると、議論が一本にしかならない関係もあり並列して話をするのは難しい印象でした。

最後に

9月頃にWGとして、各社で携わった機械学習基盤の知見共有をするためのオンラインカンファレンスを実施予定です。もう少ししたら、公募を開始しようと思いますので、機械学習システムを構築している話や、構築しようとしたけどうまく行かないといった話をシングルトラックのセッションとして発表していただければと思います。

IBIS 2019の機械学習工学企画セッションに登壇しました

Thu, 05 Dec 2019 00:24:00 +0900

この記事は、機械学習工学アドベントカレンダー2019の5日目です。

こんにちは、chezouです。先日、PFNの比戸さんにお声がけいただきIBIS 2019という日本で最大の理論系機械学習のワークショップで、3日目の「機械学習工学」の企画セッションに「継続的改善をし続けるための機械学習基盤の課題」というタイトルで発表しました。理論系のワークショップというのは知っておりアウェイ感半端なく、数式もないという煽りも受けましたが、なんとか実務者の皆様に届いてくれたのではないかと思っています。

Challenges for Machine Learning Systems toward Continuous Improvement

Machine Learning in productionに対する9つの課題は、世の中にまだまだ整理されているものではなく難産だったので色々と議論ができればと思っています。9つの課題とdotscienceのLuke Marsden氏によるReproducible, Accountable, Collaborative, Continuousという4つのマニフェストの話を元に整理してみたのですが、どのような課題と抽象化を行っているのか、そしてそれがどういう嬉しさがあるのかへの理解の一助となればと思います。

Concept drift?

「学習時と予測時の分布の違いを検出するデータバリデーションが大事」という話をしました。で、この「学習時と予測時の分布の違い」というのを"Concept drift"という表現を使って説明をしたのですが、 shima__shima先生からもご指摘をいただき、どうも違うのではないかということで色々と調べたり議論をしていました。Concept driftは英語圏では雑にこのニュアンスを表現するのに使われており、特に産業界ではそれでいいかなという表現であるという認識です。ただ、もともとはストリームデータに対するdriftという定義があるようです。

人によっては"Covariate shift"(共変量シフト)や"Domain shift"という表現をするということから、Covariate Shiftがいいのかなと思っていましたが、“Delayed effect"という表現が時間的な変化に対する表現としてよいようです。ただ、個人的にはスライドでも書いたように光の変化は時間変化というよりは仮定する前提条件が覆された例だと思っているため、Delayed effectも少し狭いかなと思っていました。

なお、GoogleはTensorFlow Extendedの論文中で"training-serving skew"という表現を使っています。

以下、shima__shima先生の説明が参考になるかと思います。

共変量シフトは統計系の文脈ででてきて抽象的に分布が違うといった意味合いで最初に出てきました．
転移学習は機械学習分野で類似したデータという感じででてきました．2000年中頃はいろいろ呼び名がありましたが今では転移学習に落ち着いていると思います． https://t.co/4n1NXdWPAE
— しましま (@shima__shima) December 3, 2019

同じころ，コーパスの分野の違いというあたりから，Hal Daumé さんあたりがNLP分野でドメイン適応という言葉を使い始められました．
時間による変化で起きるならdelayed effect という言葉もあります．https://t.co/qVmBdO2fz3
— しましま (@shima__shima) December 3, 2019

機械学習工学セッションの他の発表

他の発表は、NIIの石川先生による機械学習工学とテストの話 (スライド)、STORIA法律事務所の柿沼先生の機械学習と知財の話(スライド)でした。

石川先生の機械学習を工学として捉え直したときの説明や、adversarial testなどテストの最近の状況は自分自身追いかけられていなかったのでとても良かったです。

柿沼先生はAI模擬裁判などでご存知の方も多いと思いますが、先生の知財の話は学習済みモデル含めたシステムの権利は受託したベンダーか発注者のどちらにあるのか、という話も面白く、実践的で知見に富んだ話でした。ぜひML関係者はスライドを読むと良いと思います。また、柿沼先生への比戸さんの質疑から派生した議論をメールでさせていただいたのですが、機会があったら公開したいと思っています。