これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
前回に続いて、2017年に公開された論文「Quick Access: Building a Smart Experience for Google Drive」を元にして、Googleドライブの「クイックアクセス」機能を支える機械学習システムについて解説します。今回は、このシステムを実環境に適用した際に直面した課題、そして、実環境における性能評価の結果を紹介します。
第91回の記事で説明したように、このシステムでは「Activity Service」を用いて学習データを生成しています。これは、Bigtableに保存されたさまざまなログを集約してレポートするシステムですが、この機械学習プロジェクトのために用意されたものではなく、以前から存在していたものです。さらに、このシステムでは、複数のチームが管理するログを集約しているため、ログデータの品質にばらつきがありました。フィールドとしては存在するものの実際のデータは存在していなかったり、大元のログの仕様変更によりデータの値が突然変化するなどの問題に直面したそうです。すでに稼働しているシステムに後から機械学習を適用する場合、「機械学習に使用することを前提とせずに収集されるデータ」を用いる必要があるため、このようなデータの品質に関わる問題は必ず発生します。この問題に対応するために、クイックアクセスの開発チームでは、Activity Serviceから得られるデータの統計値（平均や分散など）を自動計算して、モニタリングするシステムを開発しました。あきらかに不自然な統計値を持つフィールドや、統計値が大きく変化するなどの事象をトラッキングすることで、問題のあるデータを発見したそうです。
機械学習モデルを実環境に適用した際に起きる問題の典型例に「Training-Serving Skew」があります。これは、学習に用いるデータと実環境で予測に用いるデータに違いが生じると言うものです。前述のActivity Serviceは、Bigtableに保存された過去データを集約する機能に加えて、現在のアクティビティを元にしたリアルタイムデータを提供する機能があります。実環境ではリアルタイムデータを用いた予測を行いますが、この際、過去データとリアルタイムデータでフィールドの内容が異なるという問題が発生したのです。たとえば、「comment」と「comment-reply」という2つのフィールドについて、過去データでは異なる意味を持つフィールドであるにもかかわらず、リアルタイムデータを呼び出した場合は、なぜか同一のデータが返却されるという事があったそうです。さきほどのデータ品質の問題と同様に、リアルタイムデータの仕組みについても、元々は、他のチームが利用するために作られたことから、このような不整合が発生したものと考えられます。
それでは、クイックアクセスの開発チームは、この問題をどのようにして発見したのでしょうか？ 彼らは、学習済みの機械学習モデルを実環境に適用する際に、「Dark experiment」を実施しました。これは、機械学習モデルによる予測は行うものの、実際の結果はユーザーには見せないという手法です。それぞれのユーザーが実際に開いたファイルが予測結果と一致しているかだけを調べる事で、エンドユーザーに影響を与える事なく、実環境における予測精度を調べることができます。その結果、過去データを用いたテストに比べて、リアルタイムデータを用いた予測は、予測精度が大きく下がることが発見されました。その原因を追求する中で、この「Training-Serving Skew」の問題に気がついたという事です。
その後、学習データについても、実環境に合わせて、リアルタイムデータ用のAPIから取得したデータを利用するように学習処理のパイプラインを再構成することでこの問題を回避しましたが、それでもまた、学習データと予測用データの差異は完全にはなくなりませんでした。予測時は、その時点での最新のリアルタイムデータを使用するという想定ですが、実際には、最新のデータがActivity Serviceを通じて取得可能になるまでには、わずかなタイムラグが存在します。つまり、リアルタイムデータ取得のAPIからは、最新よりも少し古いデータが得られるのです。したがって、学習処理においても「最新より少し前のデータを用いた際に予測精度が最も高くなる」という基準でチューニングを行う必要があることになります。冒頭の論文には、（この論文の執筆時点において）学習用データと予測用データが完全に一致するように、システム設計のさらなる見直しを行っているとの記述があります。
機械学習モデルを実環境に適用する際は、モデルの予測結果をどのようにユーザーに見せるかと言うインターフェースについても考える必要があります。クイックアクセスの開発チームが最初に考えたのは、検索機能との統合です。Googleドライブのホーム画面には検索ボックスが用意されていますが、検索ボックスにカーソルをあわせると、予測に基づいたドキュメントが検索候補として現れるというものです。しかしながら、この方法の場合、もともと検索機能を利用する習慣がないユーザーは、この機能に気づかない可能性があるということで採用されませんでした。
次のアイデアは、ユーザーが開くであろうと予測されたドキュメントの候補をポップアップ表示するというものです。特に、一定値以上の予測値（たとえば、開く確率が80%以上など）を持つドキュメントがある場合にかぎって表示するようにすれば、精度の悪い結果をユーザーに見せずに済みます。しかしながら、この方法にも問題があるために不採用となりました。社内ユーザーにテストしてもらった所、ポップアップが表示される場合と表示されない場合があるとサービスの動作に一貫性が感じられず、特にポップアップが表示されなかった場合に、「システムが正しく動作していないのでは」と感じてしまったと言うのです。これらの結果を踏まえて、最終的には、ホーム画面上部の固定領域に候補を表示するという現在のデザインに落ち着いたということです。
最後に、実環境における性能評価を示すデータを紹介しておきます。一般に機械学習モデルの性能を評価する際は、シンプルなロジックに基づいた「ベースモデル」を用意しておき、このベースモデルに対して、どの程度の性能向上が得られるかを調べます。冒頭の論文では、「最近開いたドキュメントを候補として表示する」という単純な仕組みをベースモデルとして、これに対して「トップ3の候補に対する正解率」がどれだけ向上したかが示されており、結果は図1のようになります。
図1 ベースモデルに対する正解率の向上（論文より抜粋）
ここでは、Googleドライブを利用する頻度によってユーザーをグループ分けしており、利用頻度が高いユーザーほど、より大きな性能向上が得られていることがわかります。そして、クイックアクセスを提供するそもそもの目的は、ユーザーが目的のドキュメントを発見して開くまでの時間を短縮することでした。実際にその目的を達成できているかを示したものが、図2のデータになります。
図2 ドキュメントを開くまでの平均時間（論文より抜粋）
クイックアクセスの予測が正しかった場合、つまり、表示された候補をユーザーが選択した場合、ドキュメントを開くまでの平均時間は9.3秒です。一方、ユーザーが自分でドキュメントを探し出した場合は、18.4秒となっており、クイックアクセスによる時間短縮の効果が確かに現れています。
今回は、2017年に公開された論文「Quick Access: Building a Smart Experience for Google Drive」を元にして、Googleドライブの「クイックアクセス」機能に用いられる機械学習モデルについて解説しました。論文の中では、予測処理のレイテンシーによる結果の違いを示すデータなども紹介されていますので、興味のある方は、ぜひ論文の方も参照してください。
次回は、ペタバイト規模のデータをSQLで分析可能にした「Dremel（BigQueryの元になったGoogle社内のデータ分析ツール）」に関する論文を紹介したいと思います。
Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
