ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社のコーポレートサイトはこちらです。
当ページに記載されている情報は、2023年9月30日時点の情報です。

企業情報

2022.11.21

機械学習の実装から運用まで MLOpsをスムーズに進めていくために取り組んでいること

画像

機械学習モデルの実装から運用までのライフサイクルを円滑に進めるための仕組み、MLOps(エムエルオプス:Machine Learning Operations)を担当しているエンジニアの芹沢に、DevOps(デブオプス:Development and Operations)との違い、MLOpsをスムーズに進めるために取り組んでいることなどを聞きました。

芹沢 信也(せりざわ しんや)
2019年入社。機械学習エンジニアとして、ヤフー全社で使われているレコメンドプラットフォームを担当するプロジェクトに所属。
ログ収集・学習ジョブの開発/運用やMLOpsに関連する業務を行っている。学生時代に「NHK学生ロボコン2016」国内優勝の経験も(その後世界大会の「ABUロボコン」にも出場)。

学生時代に特に力を入れて研究していたこと
大学では、人間の身体の情報を計測して、それを何らかの形で人にフィードバックして、その人の行動に変化を促すことをテーマにしていました。体に関する情報というのは、たとえば、歩いた際に筋肉に生じる電圧です。そのようにどんな筋肉でも、筋肉が収縮するときに電圧が生じるので、あらゆる筋肉の活動が情報になります。
歩いたときを例にすると、足を地面に着くときに本格的な筋肉の活動が見られます。ですが、実は着地の直前からそのために予備的な活動をしています。たとえば、着地先の段差が高いほどその予備活動が大きくなるということが知られています。
私は着地先の高さではなくて、主に(着地先の)硬さについて研究していました。具体的には、硬い材質とやわらかい材質かどうかで筋肉の活動量が変わらないか、などです。
将来的に、自分が着地先の床の硬さを誤って認識していた場合、それを事前に検知して転倒防止のためにサポートしたり、アラートを出したりするようなことができないか、と考えて研究していました。

人の何らかの行動や情報を事前に知ることで、人の行動に働きかけられないだろうか、というテーマに興味があります。ヤフーは自社で多くのサービスを持っておりデータ量も膨大です。それらのデータを生かすことで、とてもおもしろいことができるのではないかと考えて入社しました。

DevOps(デブオプス)、MLOps(エムエルオプス)とは?

まず、ソフトウエア開発の分野で「DevOps(デブオプス)」があります。

開発を進めていく際、従来のやり方では、
・開発チーム(Development)(新しい機能などをつくる)
とにかく新しいものを出して、新しい価値を提供したい、どんどん新しいものを出して反応を見たい
・運用チーム(Operations)(つくったものを継続的に運用していく)
安定して価値を提供したい、バグやトラブルなく提供したい、ちゃんと確認をしてほしい、ちゃんと自分も確認したいのですぐには出したくない

この2つに担当者やチームが分かれていることが多くなっています。

それによって、両チームのコミュニケーションに齟齬(そご)が生じたり不和が生まれたりすることもあります。その課題を解決するために、開発担当と運用担当がうまくコラボレーションできるようにしていこうという考え方がDevOpsで、ソフトウエア開発の分野で浸透している考え方です。

この発展形として、機械学習を扱うプロジェクトでこの考え方を応用しているものが「MLOps」と一般的にいわれるものです。

機械学習の場合は、
・サービス担当者(こういうことがしたいという、事業に近い人たち)
・データを分析する人
・機械学習のモデルをつくるサイエンティスト
・モデルの運用をする人
これらの人たちで進めていくことが多くなっています。

MLOps では、DevOpsと比べて、担当ごとに必要とされる知識が大きく違います。
・サービス担当者
サービスのビジネス的な知識やソフトウエア開発の知識
・データ分析をする人
データ分析の方法に関する知識やサービスのビジネス的な知識
・モデルを作るサイエンティスト
論文などから得る研究に関しての知識、データ処理・機械学習用のライブラリの知識
・モデルの開発・運用担当
基本的な機械学習の知識、機械学習パイプライン(※1)の開発・運用に使うツールの知識
※1 機械学習パイプライン:
学習データの収集 → モデルの再学習 → 再学習済みのモデルによる予測の処理を自動化し継続的に実行するシステムのこと

私のようにモデルの運用や、ログの改修を担当していると、そのために使用するツールの知識も必要になります。サービス担当者とは必要とされる知識や前提となっているところが違うため、それが原因でコミュニケーションがうまくいかないことがあります。

これを解決するために取り組んでいるのが、MLOpsです。これは先ほどお話したDevOpsと大きな目的は同じですが、システム開発以上に、各担当者のやることが異なっていることによって、コラボレーションがより難しい場合があります。

MLOpsとDevOpsの大きな違いは、MLOpsでは「モデル(※2)」を扱うことです。
このモデルの材料は、「生もの」であるデータです。トレンドや季節によってユーザーの行動は変わり、その結果データの傾向も変化していきます。
※2 モデル:
機械学習モデルとも呼ばれる。入力されたデータを解析し、評価・判定を行い、その結果を出力として返す仕組み

さらに、データは少しでもバグがあると、壊れたり不正な形になったり、今まで想定していなかった内容になったりすることがあります。そのような「生もの」の影響を直接受けてつくられるモデルも、変化し続けることになります。

そのため、データやユーザー行動が変わっていないか、学習パイプラインが問題なく回っているか、モデルの出力やAPIにトラブルが起こっていないかを継続的に監視していく必要があります。これがDevOpsとの大きな違いだと思います。
ソフトウエアはリリース後、バグがなければ問題なく運用していけますが、モデルの場合は、何もしていなくても壊れることが普通に起こる可能性があるからです。

今私が担当しているのは、データが不正な形式になるなどトラブルが起きていないかの確認、定常的に学習を行うパイプラインの開発、モデルが正常に動いているかの監視などです。
集めてきた学習データでモデルを作り、APIを提供することでサービス担当者がデータを扱える仕組みの構築にも取り組んでいます。

DevOps、MLOpsとは
DevOps:
Development(開発)チームとOperations(運用)チームが、お互い連携しながら業務を進めていくこと
MLOps:
ML(機械学習)チームとOperations(運用)チームが、お互い連携しながら業務を進めていくこと
→モデルはデータを扱うため変化し続けているので、継続的に監視していく必要がある

MLOpsをスムーズに進めていくために取り組んでいること

MLOpsをうまく進めていくためには、人と人との細かなコミュニケーションの話もありますし、担当者同士の関係も大きく影響してきます。そして、技術的な側面では、どのようなツールを導入するかも大切です。
これらの点を踏まえて、機械学習チームと運用チームがコラボレーションしやすいように考えていく必要があります。

私がこれまで取り組んできた成果として一番挙げやすいのは、モデリング業務の効率化です。
新しいモデルを本番採用するまでにはA/Bテストの準備などをする必要があり、その工数が多いこと、効率がよくないことが課題でした。そこで、検証段階からテスト実施までの実装の負担を軽減し、より早く安全にモデル改善の試行錯誤を行える仕組みを提供しました。
参考)モデリング施策を高速・安全に回せる、MLOpsの仕組みづくり

これは、実験に用いた「実験ノート」を、そのままスムーズに本番のものに移行する仕組みです。実験ノートとは、機械学習の担当者が、どのような実験を行い、どのような結果が得られたかという記録や、研究の過程での議論、データ解析結果など、実験に関わるさまざまな内容を記録しておくものです。

今までは、運用チームがこの実験ノートの記述をもう1回読み直して、開発環境に合わせた内容に清書し直す作業、つまり、ほぼやり直す作業が必要でした。このやり直しに伴う手間を減らすために、実験ノートをある程度整理すれば、そのまま本番環境でも動くようにできる仕組みを作りました。

これまで
機械学習担当:実験ノートを作成
運用担当者:実験ノートを読み直し、清書して組み込みなおす
※場合によっては機械学習担当が清書・組み直しを行うことも

MLOpsの仕組み作成後
機械学習担当:実験ノートを作成
運用担当者:実験ノートに書かれた内容をそのまま本番環境で定期実行できる

この仕組みをつくったときに特に意識したのは、社内で提供されているツールを使い、学習コストがあまり高くならないようにすることです。それによって属人的にならずメンテナンスがしやすいシステムを作ることができます。もちろん、モデルをつくるサイエンティストの作業がスムーズになるよう心がけました。
モデルを作成するサイエンティストに、今どのように進めているか聞いて、「少し効率が悪い」ところを洗い出して、解決できそうな仕組みを提案。その後も定期的に「こんな感じでどうですか」と、フィードバックをもらいながら調整していきました。

今回の取り組みは、同じ部の中だったので、お互いがどんな働き方をしているか、どんなモデルのつくり方をしているか知っている仲だったこともあり、かなりスムーズに進められたと思います。
反対に、スムーズに進めることが難しいかもしれないと思うのは、完全に組織としてばらばらで、お互い何をやっているかよくわからないような状態の時かもしれません。

たとえば、機械学習のことはあまり知らないサービス担当者と、サービスの事情を何も知らない私たち機械学習担当者で進める場合、まずお互いの知識を共有するところから始まります。
ヤフーの場合は社内でバックグラウンドがある程度共有されているので、きちんと話し合えばコミュニケーションが取れると感じています。これが社外となると、もしかしたらさらに難しくなるかもしれません。
ですが、どんな状況でも人同士が働く時は、その程度が異なるだけで、お互いに相手の立場になって考えられるようにコミュニケーションを行っていくのは同じだと思います。

カジュアルにコミュニケーションすることで、気づきを生む

自分がつくったものをサイエンティストの人に使ってもらうときは、どういう課題があり何に困っていて、それがどれくらい影響を与えているかを、重要度順に整理して伝えています。
それらに対して、「この方法だと、この要素はこれくらい解決できるから良さそう」ということを提案していきます。

私自身もそうなのですが、みなさんも「不便なことに慣れてしまう」ということがあるのではないでしょうか。ですが、たとえば「このツールを使う必要があるのでこういう準備が必要」など、本当は使いにくいことに疑いの目を向け続けていくことが大切だと思います。

不便に慣れてしまったことで、意外と気づいていないこともあるので、コミュニケーションをとるうちに「なんかこの辺、不便だな」と、ふと思い浮かぶことも。
私たちのチームはサイエンティストと運用メンバーが近い距離にいるのを生かして、カジュアルにコミュニケーションし合うことで気づきを生むことが大切なのではないかと考えています。

MLOpsは結局のところ、いろいろな人たちとの働き方、コミュニケーションやコラボレーションしながらスムーズに進めるための考え方だと思っています。

これまではいちメンバーとして提案してきましたが、今後はプロジェクトを主導する動きや、人を主導して巻き込んで推進していけるようになっていきたいですね。先頭に立って何かを主導するのは自分の性格的にはあまり得意なことではないのですが、今後取り組んでいきたいことのひとつです。

たとえば、小さい規模で人を主導したり教えたりする経験を積んで、その規模をだんだん大きくしていくことに、まずは取り組んでいければと思っています。
MLOpsの仕組みづくりで意識してきたように、メンバーに対しても、「外部からの目」として客観的に評価して、メンバーが活躍する場をつくっていくマネジメントスタイルであれば、自分の強みを生かしていけるかもしれません。

いろいろな生きづらさがある世の中 前向きに生きていけるものを提供したい

いろいろな生きづらさがある世の中だと思っているので、それらを緩和したり、少しでも前向きに生きていけたり、「誰かを楽にする」ためのものを何か提供したいという気持ちがあります。
また、「生きづらさ」を感じるのは気持ち的なところも大きいと思いますが、身体的な部分と精神的な部分は強く関わりがあるので、実は身体的アプローチのほうが精神的な問題にうまくアプローチできるのではないかと考えています。

最後に、サイエンスとして価値を提供するのはやはり機械学習のモデルなので、主役はサイエンティストの人たちだと思っています。その人たちが活躍しやすい場をつくれたという手応えがあったときは、うれしいですね。
今自分がやるべきことは、ユーザーに価値を提供するため、よりパフォーマンスを上げやすい環境を整えること。そして、一緒に働くサイエンティストたち、そしてユーザーに対して価値を生み出していきたいと思っています。

【関連リンク】

このページの先頭へ