Waze、相乗りの予測に Google Cloud の AI Platform を活用

※この投稿は米国時間 2020 年 9 月 26 日に、Google Cloud blog に投稿されたものの抄訳です。

Waze の使命は交通量を減らすことであり、当社の相乗り機能はこれを達成する礎となると考えています。当社の相乗りアプリでは、相乗りユーザー（またはドライバー）に同じ方向に通勤するユーザーのリストが表示されます（以下を参照）。相乗りユーザーまたはドライバーはそのリストから相乗りのオファーを開始し、相手側がそれを受け入れると、マッチングされて相乗りが成立します。

この投稿では、テルアビブのある場所から Google のオフィスに通勤している相乗りユーザーの例について考えてみましょう。目標は、その相乗りユーザーに同じ方向に通勤するドライバーのリストを提示し、相乗りユーザーとリスト上のドライバー間で相乗りが成立する可能性が高い順にそのリストをランク付けすることです。

関連するすべての候補者を数秒で見つけるには、エンジニアリングとアルゴリズムに関する多くの課題が伴います。そこで、優秀なエンジニアのチーム全員でそのタスクに取り組んできました。この投稿では、これらの候補者のランク付けを担うシステムの機械学習部分に焦点を当てます。

具体的には以下の点です。

• 数百人（またはそれ以上）のドライバーが（この例での）相乗りユーザーに適合する場合、どのドライバーを最初に表示するかを決定する ML モデルをどのようにして構築するか。

• 全体的なユーザー エクスペリエンスが高速で快適になるように、オンラインでの低レイテンシを確保しながら、本番環境において複雑なモデルですばやく反復処理を行えるようなシステムをどのようにして構築するか。

ドライバーと相乗りユーザーのリストをランク付けする ML モデル

この例の相乗りユーザーには、ドライバー候補のリストが表示されます。候補となるドライバーごとに、次の 2 つの質問に対する答えを見つける必要があります。

1.相乗りユーザーがこのドライバーに相乗りのリクエストを送る確率はどのくらいか。

2.ドライバーが相乗りユーザーのリクエストを実際に受け入れる確率はどのくらいか。

これを解決するには、機械学習を使用します。相乗りのリクエストを送信する相乗りユーザーと受け入れるドライバーについての集約された過去のデータを基に、この 2 つの確率を推定するモデルを構築します。モデルを使用して、相乗りが実際に発生する可能性が高い順にドライバーを並べ替えます。

Waze で使用しているモデルでは、約 90 個のシグナルを組み合わせてこの確率を推定しています。以下に、Waze のモデルで最も重要となるシグナルをいくつか示します。

ドライバー側では、出発地から目的地までのドライバーの運転距離全体に対する迂回路の距離について、同様の考慮事項が当てはまります。

モデルとサービス提供の複雑さ

このサービスの初期段階では、まず単純なロジスティック回帰モデルから始めて、ユーザーがオファーを送信、受け入れる可能性を推定しました。scikit learn を使用してオフラインでモデルをトレーニングしました。約 90 個の異なるシグナルに対して「ログと学習」アプローチ（サービス提供中にシグナルを正確に記録する）を使用してトレーニング セットを取得し、学習された重みをサービスレイヤに追加しました。

こうしてトレーニングしたモデルはかなり良好に機能していましたが、オフライン テストを通じて、ランキング タスクに勾配ブースト回帰分類などのより高度な非線形モデルを使用することで、さらに良い結果が得られる可能性があることがわかりました。

このような高度なモデルをサポートする高速なサービスレイヤをメモリ内に実装するには、かなりの労力と継続的なメンテナンス費用が必要になります。これをはるかに簡単にする方法として、サービスレイヤを外部のマネージド サービスに委任して、RESTAPI を介して呼び出せるようにするという選択肢がありました。ただし、これによってフロー全体でのレイテンシが大幅に増大することがないようにする必要があります。

意思決定を行うために、AI Platform オンライン予測サービスを使用して迅速な概念実証（POC）を行うことにしました。これがサービスレイヤでの Waze のニーズに最適であるように思われました。

迅速な（そして成功した）概念実証

scikit learn を使用して約 90 個のシグナルに対して勾配ブーストモデルをトレーニングし、そのモデルを pickle ファイルとしてシリアル化して、そのまま Google Cloud AI Platform にデプロイしました。これで完了です。REST API を介して、高度なモデルのフルマネージド サービスレイヤを取得します。そこから、Java サービスレイヤに接続するだけです（これを機能させるには重要な詳細事項が多数ありますが、純粋なモデル サービスレイヤには関係ありません）。

以下の図は、オフライン / オンラインのトレーニング / サービス提供アーキテクチャの大まかな概要を示したものです。相乗りサービスレイヤでは、さまざまなロジックを用いて関連する候補者のスコア付けの計算、取得を行いますが、ここでは ML のランキング部分だけに焦点を当てます。Google Cloud AI Platform は、そのアーキテクチャで重要な役割を果たします。これによってモデルに対する即時の堅牢なマネージド サービスレイヤを提供することで速度が大幅に向上するため、機能の向上とモデリングに集中して取り組むことができます。

速度が向上し、コアモデルのロジックに集中できるという安心感が得られたのはよかったのですが、制約としてサービスレイヤでの REST API の外部呼び出しによってレイテンシが増加しました。そこでオンライン予測 API に対して、モデルや入力サイズを変えながらさまざまなレイテンシ チェックや負荷テストを行いました。AI Platform でアプリケーションに必要な 2 桁のミリ秒という低レイテンシを達成しました。

わずか数週間で、コンポーネントを実装して接続し、AB テスト用にモデルを本番環境にデプロイすることができました。以前のモデル（一連のロジスティック回帰分類）でも良好に機能していましたが、AB テストでコア KPI の大幅な改善が見られたことには感動しました。しかし、私たちにとってさらに重要なのは、トレーニング / サービスの実装やデプロイといった面倒な問題に対処しなくても、もっと複雑なモデルでもすばやく反復処理できるプラットフォームを使用できることでした。

氷山の一角（Google Cloud AI Platform）

今後、Waze では TensorFlow を Google Cloud の Explainable AI コンポーネントとともに使用してより洗練されたモデルを追求し、実行方法についてのより詳細な分析情報を提供することで、これらの洗練されたモデルの開発を簡素化していく予定です。先日発表された AI Platform Prediction の一般提供リリースにより、GPU と複数のハイメモリで高性能計算のインスタンス タイプがサポートされるようになり、さらに洗練されたモデルを費用対効果の高い方法で簡単にデプロイできるようになります。

AI Platform Prediction サービスの初期での成功に基づいて、ハイパー パラメータ調整やパイプラインを使用したトレーニング サービスなど、GCP の AI Platformによって提供される他の魅力的なコンポーネントを積極的に活用していく予定です。実際、Waze では複数のデータ サイエンス チームやプロジェクト（広告、将来のドライブ予測、ETA モデリング）が AI Platform の他の既存の（または今後の）コンポーネントをすでに使用しているか、調査を開始しています。詳しくは今後の投稿で説明します。

-Waze シニア データ サイエンティスト Philippe Adjiman