リニューアルを通じて見えてきた改善ポイント
それではリニューアルを通じて見えてきた改善ポイントについての事例紹介に進みます。改善ポイントは大きく3つに分類されます。1つ目は機械学習モデルのさらなる改善。2つ目は推定属性の安定供給とそのモニタリングのためのシステムの構築。そして3つ目はデータとモデルの再利用性のさらなる向上の3つです。以降、これらについて1つずつ紹介していきたいと思います。
まず1点目です。機械学習モデルのさらなる改善についてお話いたします。先ほど申し上げた2020年夏のリニューアルですね。その直後の属性推定システムまでは、この図に示したようなシンプルなディープニューラルネットワークをモデルとして採用していました。サービス横断で収集された先ほどの特徴量データを1つのEmbeddingレイヤーに投入して、このEmbeddingを一括して行うことで、モデルに投入するかたちになっていました。
先ほど、属性推定システムの規模のお話をした際に、特徴量データの次元数をこの右の表で紹介しましたが、ここでの次元数は、言い換えると今図に示したEmbeddingレイヤーに入力される次元数です。
さて、モデルの精度をさらに改善するべく、いろいろな試行を重ねましたが、その結果、右の図のようなモデル構造への改良が行われました。まず、これまで1つのレイヤーで一括で行っていたEmbedding処理を、特徴量データの元になったサービスの種類ごとに、別々に処理するようにEmbeddingレイヤーを分割しました。
そしてさらに、モデル本体をそれまでのシンプルなディープニューラルネットワーク、マルチレイヤーパーセプトロンの仕組みから、ResNetを用いた畳み込みニューラルネットワークに変更しました。これらの取り組みによって、このモデルの精度はさらに向上しました。そしてさらなる改善として、2021年の3月に発表されたばかりの最新手法であるMLP-mixerというモデルも導入しました。
加えて、入力する特徴量データをサービス単位で確率的にドロップアウトするというアイデア。この図で今「Service dropout」と書いていますが、こういったアイデアを取り入れました。この考え方ですが、LINEにはさまざまなサービスがありますが、「このサービスはぜんぜん利用したことがない」というユーザーも多くいると思います。
このサービス単位のドロップアウトは、こういった「このサービスはまるまる利用していません」というようなユーザーの存在をうまくシミュレーションできていると考えています。こうしたモデル改善の結果、今右の図に示したように、大半の属性セグメントの種別において、モデル精度が向上しました。
本発表の冒頭でも紹介したように、属性推定システムは非常に大規模なものなので、LINE全社的にさまざまなサービスで活用されていますし、このモデル精度の向上は、ここに示したような数パーセントの正解率の向上でも非常にインパクトがあり、重要なものです。
そしてさらに、このグラフの下のほうにもちょっと記しましたが、それぞれの属性セグメントの種別は、ものによって10から数十という多くのセグメントで構成されています。これがどのセグメントに属するかという分類問題を解いているわけですが、機械学習の分類問題としてもこのセグメントの数がとても多いので、決してこれは簡単なものではありませんでした。こうしたセグメント数でこれだけの精度改善ができたことは、このモデル改善の活動の大きな成果であると言えます。
さて、このリニューアルで見えた改善ポイントの1点目として、今モデル精度の向上についてお話をしました。続いて2点目として、推定属性の安定供給とモニタリングのためのシステムの構築の部分についてお話をいたします。
モデル出力の安定供給がなぜ重要なのか
まず、モデル出力の安定供給がなぜ重要なのか。ここが不安定になると何が問題になるのかについて最初に紹介いたします。
出力されるセグメントのボリューム、つまり属性ごとに推論されたユーザー数ですね。これの変動が大きいと、事業側に不便が生じるという課題があります。先ほど紹介しました推定属性を用いた広告や、あるいは公式アカウントのメッセージといったものが、配信を例に、この図に示しましたグラフをもとに紹介します。
この図の今緑色の点で示した日と、その翌日の今図に青色で示した日では、セグメントB、水色の折れ線で示した属性であると推定されたユーザーの人数が、1日でおよそ30パーセントもガクッと減っているということが、このグラフからわかります。さて、ここで問題になるのがたった1日の間に、広告やメッセージの配信ターゲットとなるユーザー数が30パーセントも大きく減少してしまったことです。
さらに、このセグメントBのユーザーをターゲットにする配信設定を、広告や公式アカウントのオーナーが一切変えてないとしても、1日でこれほどの配信数が減少してしまうことは、広告や公式アカウントのオーナーさんにとって非常に不利益となってしまいます。これが、推定属性の安定供給が重要になってくる理由です。
安定供給を実現するためのしくみ
さて、この問題を解決して、推定属性の安定供給を実現するために、我々はいくつかの仕組みを導入して、それらを組み合わせて適用しています。解決策の1つ目はスムージング、つまり平滑化ですね。平滑化による日々の変動の抑制です。例えば、今左側に先ほど例としてお見せした推定属性のセグメントボリュームのグラフを掲載していますが、ここにそのスムージング、平滑化を施すことで、右の図のように滑らかなボリュームの推移となって、日々の変動を抑制可能になります。
スムージングには移動平均、Moving averageをはじめとしてそれぞれのタスクに合わせていくつかの手法が選ばれて用いられています。この移動平均でスムージングする方法自体は、信号処理やそういったところで波形を処理する時に使われたりしていますが、こういった方法を機械学習の分野の出力、ポストプロセスとして応用しているかたちです。
さらにこのスムージングの処理は、モデルは毎日学習されているわけですが、日々学習されるモデルをアンサンブルするという効果もあるので、このスムージングによって推定の精度をさらに向上させる効果を狙うことすらできるという、一石二鳥の方法になっています。さらに我々は、このスムージング処理をより簡単に行えるように、Smoothing APIを開発しました。
このSmoothing APIでは、スムージングの計算の方法やスムージングを対象とするデータベースのカラムなどを指定するだけで、面倒なSQLクエリなどを一切記述することなく、このスムージング処理を行えます。これによって、スムージング処理の標準化・共通化が実現できましたし、加えて新しくシステムを実装する時に、よりシンプルにこれを素早く実装可能になりました。
この推定属性の安定供給のお話をしていますが、2つ目の改善策がセグメントボリュームのキャリブレーションです。これもちょっと仮のデータと設定に基づいて、この図で紹介いたしますと、例えばこの図に示したようなセグメントボリュームの推移があったとします。そして、仮にこれが先ほど紹介したスムージング処理を施しても、なおこういったかたちで変動が残っていると仮定します。
ここに対して、このボリュームキャリブレーション処理を施しますと、キャリブレーション後のセグメントボリュームは、今図に青色で示したような推移になります。さてどのようなキャリブレーション処理が施されたのか、次のスライドで紹介いたします。
まず、左側のこの赤い矢印で示した箇所ですが、ここでは大きすぎる変動を抑制する処理が施されています。今回の例では、1日ごとに許容されるボリューム変動が最低でも前日より±20パーセントまでと設定されていると仮定すると、それを超える変動が抑制されるように、こうして出力される推定属性が調整される処理がなされています。
次に、右側のこのオレンジ色の箇所で示した部分は、セグメントボリュームが小さくなりすぎないような処理されています。この例では、それぞれの推定属性のセグメントボリュームが、最低でも15万人は存在するように設定されていて、それを下回らないように出力が調整されています。今紹介したこのキャリブレーションの仕組みですが、特にマルチラベルのタスク、すなわち興味や関心属性のように、各ユーザーに対して複数のセグメントが付与されるようなタスクに対して、特に有効に機能しています。
このボリュームキャリブレーションの仕組みを、先ほどのスムージングと合わせて使用することで、スムージングではカバーしきれないような変動が仮に起きてしまっていても、それをこうやって抑制できますし、あとはそのボリュームが小さくなりすぎて広告や公式アカウントのメッセージ配信のターゲットがいなくなってしまうようなことを防止できます。
さて、推定属性の安定供給のための3つ目の解決策が、Gradual rolloutと我々が呼んでいる仕組みです。これは、モデルの構造そのものとかハイパーパラメータなどが刷新された新しいモデルをリリースしていく時に、これを徐々にリリースしていく仕組みです。
具体的には、今左側に例を図で示したように、その刷新後の新しいモデルで推定された属性を付与していくユーザーの割合を、日数の日の経過ごとに少しずつ徐々に増やして、時間をかけてその刷新後の新しいモデルをリリースしていく仕組みです。
これは実際にあった例ですが、このGradual rolloutの仕組みを使って、新しいモデルを実際に徐々にリリースしていった時の、ある推定属性セグメントのボリューム推移を右にグラフで示しました。この右のグラフを見るととわかるとおり、今この赤い矢印で示した部分、セグメントボリュームが徐々に変化していっている様子が見て取れると思いますが、ここがそのGradual rolloutを実施した部分です。
見てもらうとわかるとおり、一番左側が古いモデルを使っていたところ。一番右側が100パーセント新しいモデルで推論をしている箇所です。その間のところを少しずつここに推移させていっていることが、実際にこのグラフから見て取れると思います。この仕組みによって、モデルをリニューアルする際にも推定属性セグメントボリュームが、一気にガクッと新しいモデルに変化してしまうことが防げます。
今ここまで紹介してきたような施策で、実際に安定した属性推定がなされているかどうかを確認する必要があるわけですが、そのためには、出力を継続的にモニタリングすることが不可欠です。我々は、これを社内のダッシュボードツールである「OASIS」を使って実現しています。
OASISでは、SQLのクエリを記述して、それを登録することによって、今画面に示しているような可視化の処理を設定したスケジュールで自動的に実行します。例えば、これを毎日更新するといったことを自動的にしてくれる仕組みです。
さらに我々は、MLOpsの取り組みの一環として、モニタリングシステムの「Lupus」を開発しています。これによって、ダッシュボードによる可視化がより簡単にできるようになるだけでなく、出力の異常を自動的に検知可能になります。今右側にLupusの画面を出しています。この赤い丸で示したところ。明らかに出力がおかしいところを自動的に検知して、通知できるようになります。
このLupusに関しての詳細な情報ですが、今聞いています本セッションの直後に開催される「Lupus - MLOpsを加速させるためのモニタリングシステム」というセッションにて紹介をいたします。興味のあります方はぜひこの本セッション終了後、そのままLupusのセッションも見てもらえたら幸いです。
データとモデルの再利用性のさらなる向上
さて、ここまで属性推定システムのリニューアルで見えた改善ポイントの事例を2点紹介しました。最後に3点目として、データとモデルの再利用性のさらなる向上というところについて、その取り組みを紹介いたします。属性推定システムのデータ処理のパイプラインは、典型的には今図に示したようなものになっています。
つまり、まず特徴量データに前処理を施しまして、前処理後の特徴量データというものを準備します。この前処理後の特徴量データとGround truth、正解データを結合してさらにTrain、バリデーション、テストの各データセットへの分割などを経まして、モデルに投入するデータセットを作成します。そしてこの作成したデータセットを用いてモデルの学習、あるいは推論といったものが行われることになります。
LINEには、推定する属性の種別に応じて複数のタスクが存在しています。しかしこれらは開発時期が異なるなど、いろいろな経緯から今図に示したように、似たような処理であるにもかかわらず、それがバラバラに実装されていまして、メンテナンスコスト的にもあるいは計算コスト的にも無駄が多いような状態になっていました。
この課題を解決するために、我々はデータ処理パイプラインの統合を進めていきました。まず各所で個別に実施されていた特徴量データに対する前処理をここで一元化しました。次にデータセットを生成する処理をAPI化しました。これによって、それぞれのタスクはそれぞれの正解データさえ用意すれば、あとは共通の仕組みでデータセットを生成することが可能になりました。
そして、モデルの学習・推論に関する部分も、APIとして仕様を共通化して、このAPIを呼び出すだけでモデルの学習・推論を実行できるかたちに統一しました。LINEには、我々が独自に開発している機械学習モデルのライブラリがあって、これをghee-modelsと呼んでいます。ghee-modelsには、さまざまな機械学習のモデルが収められていて、各モデルの学習や推論が、APIとしてシンプルに呼び出して利用できるように、これの整備を進めています。
このghee-models APIを本格的に今回導入したことで、データとモデルの再利用性をさらに高めることが可能になりました。さらに、特徴量データに対する前処理の部分をfelibというライブラリにまとめました。このfelibライブラリにより、属性推定以外の、LINEの他の機械学習のタスクでも特徴量データの前処理を容易に行えるようになりました。
また新しい特徴量が追加されていくことがあるんですが、この特徴量の追加にも、迅速に対応できるようになりました。このfelibの開発は、現在も勢い良く進められていまして、いわゆる最近流行りのデータセントリックな機械学習のプロセスといったものも、さらに効率化されていくことが今後も期待されていきます。
以上、ここまでお話ししてきたさまざまな改善を経て、2020年夏のリニューアル後よりも洗練された属性推定システムを、今年（2021年）構築できました。
今後の展望
さて、それでは本セッションの最後になりますが、今後の展望についてお話をしたいと思います。まず新しいモデルをさらに使いやすくするための取り組みについてお話をします。先ほど紹介したghee-modelsという機械学習モデルを集めたライブラリですが、ここには有効性が確認された新しいモデルが適宜追加されていっています。
なのですが、現在このghee-modelsに新しいモデルを追加する際には、モデル自体の構造、その学習推論のコードに加えて、投入されてきたデータに対する学習前の前処理。例えばそのデータをバッチにまとめるところや、さまざまな前処理があって、そういった前処理や推論後の後処理についてのコードも、すべて記述をしてghee-modelsに追加する必要があります。
そうしますと、つまり新しいモデルを追加する際には、例えば実際にはかなり似たような処理であったとしても、これらのプリプロセス、ポストプロセスといったコードも含めて、すべて実装しなければならないということで、このモデルをライブラリに追加するためには、それなりの労力が必要になっています。
そこで今後の展望としては、このghee-modelsで共通して登場するような処理をすべてコアなコードとして統合して、新しいモデルを追加する際には、そのモデルに特有の処理だけを実装すればいいというかたちに今後していくことを計画しています。これによってghee-modelsに新しいモデルを追加していく時の労力というものを大幅に削減できて、より機動的に迅速にモデルの検証や更新が可能になると考えています。
先ほど、改善事例のところで紹介したものも含めて、本日のセッションではこの再利用性とか共通化といった考え方が繰り返し登場していますが、これらはソフトウェアエンジニアリングとしては、基本的な考え方だと思います。この属性推定システムみたいな非常に大規模なシステムであっても、あるいは最新の機械学習のシステムであっても、こういった再利用性や共通化といった考え方は重要であると考えています。
Auto-persona
さて本セッションの最後になりますが、我々がAuto-personaと呼んでいる計画について紹介いたします。Auto-personaは、LINE社員の誰であっても自分たちのサービスに特化したオリジナルな属性推定を可能にするためのプランです。この時各サービス側で必要になるのは、一部のユーザーに対して紐づけられたラベルデータ、正解データだけです。
なのでサービス側で何か特徴量データを準備するような必要は一切ありません。各サービス側で用意したラベルデータをこのAuto-persona APIに渡すと、それだけで各サービスに特化したオリジナルな属性推定をされたセグメントをラベル付けをしていないユーザーも含めて、すべてのユーザーに対して推定属性を生成できる仕組みで計画をしています。
Auto-persona APIの内部的な処理そのものは、本セッションで先ほどから紹介してきた、この属性推定システムと実はまったく同じです。LINEには、これも先ほど紹介しましたz-featuresというサービス横断型の特徴量データがすでにありますので、LINE社内のサービスであれば、このz-featuresの特徴量データを利用してモデルの学習と推論が可能になっています。
こうして得られたオリジナルな属性はLINEのユーザーさま一人ひとりにより役立つ、より有用なコンテンツを届けるために活用されていくことになります。以上で本セッションを終了します。ここまでご視聴いただきましてありがとうございました。
