タクシーを「希望の日時に呼ぶ」 BigQueryによるAIとAPIインフラ

タクシー配車アプリGOでは、担当車両を事前に割り振らないまま希望日時に車両を呼ぶ「希望日時配車」の機能を提供しています。日本全国のタクシー情報、BigQuery、MLを用いてどのようにこの機能を実現しているかご紹介します。

Transcript

1. タクシーを「希望の日時に呼ぶ」 BigQueryによるAIとAPIインフラ 老木 智章 & Quentin Plessis
2. 2 希望の日時に呼ぶ ≠ 予約 タクシーアプリ「GO」では「希望日時配車」機能 が11月にリリースされました。 タクシー乗務員の皆様を長時間拘束することなく、 お客様を指定された時間に迎車するためのサービス です。 AIで取り組んでいる内容についてお話しします。
3. 3 本日の構成 l 「希望の日時に呼ぶ」におけるAI ◦ 「希望日時配車」の概要 ◦ 実現のための数理モデル ◦ BigQueryを用いた必要データの集計 ◦ BigQuery MLを用いたリアルタイム情報の活用 ◦ BigQueryの速度と価格 l AIデータを活用するAPIインフラ
4. 4 自己紹介 l 老木です。 l 元画像認識エンジニア l 元強化学習の研究者 l 現BigQuery 大好き人間
5. 5 一般的な予約と「希望日時配車」 従来 : 車両を事前確保する。車両の拘束時間が長い。 新規：希望日時直前に、車両を確保する。 タクシー乗務員にとっては、 通常の迎車と変わらない体験で、 希望日時に対応することができる。 12:30に注文された場合、 その少し前から、周辺車両を探索する
6. 「希望の日時に呼ぶ」ために 担当車両を事前に割り振らないため、希望日時 に周辺に車両がある保証がない。 車両が見つからない際のデメリットは大きい。 「周辺車両が希望日時に到着する確率」 を算出し、確率が十分に高い場合のみ注文を受 け付ける。この確率をデータから求める！ 12:30を希望されたけど、 12:00に１台も周辺車両がない or 注文数に足りない
7. 7 l 「希望日時配車」の概要 l 実現のための数理モデル l BigQueryを用いた必要データの集計 l BigQuery MLを用いたリアルタイム情報の活用 l BigQueryの速度と価格
8. 配車成功確率 (実際からの省略版) 自分がその場所で待つX人目だった時、乗車には その場所にX台の車両が必要。 10分前から車両を探す時、10分以内にX台発見 できる確率を求め配車成功確率とする。 右は車両がX台来るまでの時間の確率分布。 次ページで右の分布の求め方を説明する。 10分以内に車両を2台発見したい。 配車成功確率は青い部分の面積
9. 9 車両発見時間の確率分布 車両が1時間に来る平均台数がM台のとき、車両 がX台来るまでの時間は、M, Xをパラメーターと したガンマ分布に従うと期待される。 この車両が来る平均台数Mをデータから求める。 平均台数は、時間帯・場所に影響されると考え られるため、時間帯・場所ごとに集計する。
10. 全国の平均台数の算出 平均車両台数は l 1km四方で l 曜日ごとに l 30分単位で 算出する。 例：東京駅付近の土曜日の時間帯 12:30-13:00 では平均12.3台
11. 11 注文受付成立までの流れ 1. 前もって平均車両台数Mを算出する 2. リクエストが来た際、周辺の注文数Xを算出する 3. M, Xをパラメーターとしたガンマ分布を用いて、配車成功確率Pを 求める 4. Pが閾値(99%など)を超えていれば注文を受け付ける、超えていなけ れば注文を拒否する
12. 12 l 「希望日時配車」の概要 l 実現のための数理モデル l BigQueryを用いた必要データの集計 l BigQuery MLを用いたリアルタイム情報の活用 l BigQueryの速度と価格
13. BigQuery の概略 Google Cloud Platform上で提供されるSQL実行エンジン。 一つのSQL文を多数のノードで実行するため、大量のデータを高速に処 理できる。また、 l 配列や構造体をエントリとして持てる l 機械学習モデルの訓練や推論を行える l SQL上でASSERTION (エラーチェック) が行える といった特徴がある。
14. どんなデータがあるの？ 車載アプリを通じて l 数秒おきの車両位置情報 l メーター情報 (空車かどうか) l 送迎位置情報 などを収集し、BigQuery上に蓄 積している。 1日数億件オーダーの規模。
15. 15 平均車両台数の集計 BigQueryでは地理データを直接扱え るため、各地点での平均車両台数は SQL上で求めている。 右は位置・曜日・時間ごとに車両台数 をカウントしている例。 SELECT youbi, jikan, m.mesh_code, COUNT(*) FROM mesh_points AS m JOIN cars USING (youbi, jikan) WHERE ST_DISTANCE(m.point, cars.point) <= MAX_DISPATCH_LIMIT GROUP BY youbi, jikan, mesh_code
16. 集計結果例 kepler.glを用いて車両台数 を可視化し、結果を確認し ている。 kepler.glはデータ量が多く (100MB〜)とも可視化でき る。
17. 17 l 「希望日時配車」の概要 l 実現のための数理モデル l BigQueryを用いた必要データの集計 l BigQuery MLを用いたリアルタイム情報の活用 l BigQueryの速度と価格
18. AIの予測値を平均車両台数とする 過去の平均値から配車成功確率を求め る場合、直近のトレンド (例：雨で車 両が少ない) に対応できない。 BQMLを用いてリアルタイムに、それ 以降の車両台数を予測し、それをガン マ分布のパラメーターとする。 0 5 10 15 20 25 0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 平均⾞両台数 台数 予測台数 7時までのデータを使って、7時以降の 平均車両台数を予測する
19. BigQuery ML (BQML) SQL上でMLモデルを作成する。 BQのデータを用いた学習や、推論 結果のBQへの書き出しが容易。 線形回帰モデルやXGBoostが利用 可能。 CREATE OR REPLACE MODEL car_model OPTIONS( MODEL_TYPE="LINEAR_REG" ) AS ( SELECT num_cars as label, before15min_cars, before30min_cars, before45min_cars, FROM TRAIN_DATA )
20. 特徴量の作成 (擬似コード) 過去の履歴だけでなく、 SQL上でさまざまな特徴量を作 り精度を向上させている。 l 祝日かどうか l 東京からの距離 など。 SELECT num_cars AS label, -- feature SIN(youbi / 7 * 2 * ACOS(-1)) AS sin_youbi, COS(youbi / 7 * 2 * ACOS(-1)) AS cos_youbi, latitude, longitude, dist_tokyo, is_weekend, is_holiday, avg_cars, LAG (cars, 1) OVER (ORDER BY ts_bin ), LAG (cars, 2) OVER (ORDER BY ts_bin ),
21. 21 予測時間別モデルの運用 l 直近の予測を精度良く行うため、30分後, 60分後, 180分後... の車両 台数を予測するモデルを個別に作成している。 l 乗車直前での利用が多いため、直近を精度良く予測するのは重要
22. Assertionによる異常値の防止 モデルは異常値を出力する可能性 があるため、ASSERT文を用いて 弾いている。 異常を検出すると、その時間のク エリを失敗とし、前の時間の予測 結果にフォールバックする。 ASSERT ( SELECT -- 欠損値 & 範囲チェック LOGICAL_AND( cars BETWEEN 20 AND 300 ) FROM target ) AS "out of range";
23. BQMLのメリット / デメリット メリット l データがBQ上にある場合、データの取得・推論結果の格納が容易 l プロジェクトで用いるサービス数が減る デメリット l 評価関数や損失関数が選べない l 学習プロセスのカスタマイズ性が低い (e.g: イテレーション回数) l ローカルでの結果と比較した方が良い
24. 24 l 「希望日時配車」の概要 l 実現のための数理モデル l BigQueryを用いた必要データの集計 l BigQuery MLを用いたリアルタイム情報の活用 l BigQueryの速度と価格
25. 25 速度と価格 リアルタイム情報を反映するために、数十分ごとに集計処理と機械学習 モデルの推論処理を起こっている。 他の処理との兼ね合いから10分程度でBQ上の処理を終える必要があり、 全国の車両情報を扱うとシビアな条件となる。 BigQueryのコストを抑えつつ、この性能要件を達成したい。
26. 26 料金プラン BigQueryは２つの料金プランがある。 l オンデマンド : 読み込みデータ量に対して課金される。プロジェク トあたり同時実行スロット数 2000。スロット割り当て保証なし l 定額プラン: スロット割り当てを予約する。割り当て保証があるため、 クエリの実行時間が安定する 定額プランを使いたいが、クエリの計算量が多いため割高になる。
27. 27 オンデマンドでのサービス提供 オンデマンドプランでサービスを提供するために、 l 遅延した際に、以前の予測へのフォールバック 直前の予測が間に合わなかった場合は、60分前予測の結果を使うなどを 行い、サービス提供を持続させている。 l クエリの高速化による制限時間内での実行成功確率の向上 とはいえ、直前の予測の方が精度が良いので間に合う確率を上げている。
28. 28 クエリジョブの実行時間プロット
29. クエリ高速化 bq-visualizerを用いて、 クエリの最適化を行っている。 クエリはステージと呼ばれる 単位に分割され実行されるが、 ステージごとの実行時間等が わかる。 https://github.com/GoogleCloudPlatform/professional- services/tree/master/tools/bq-visualizer
30. 30 クエリ高速化 テクニック例 BQ独自の高速化がいくつもある。 右はクエリ料金と引き換えに、 処理を高速化する並列readの例 WITH ... ), MULTIPLE_READ AS ( SELECT * FROM USER_POINTS WHERE MOD(user_id,3)=0 UNION ALL SELECT * FROM USER_POINTS WHERE MOD(user_id,3)=1 UNION ALL SELECT * FROM USER_POINTS WHERE MOD(user_id,3)=2 ) SELECT 重い処理 FROM MULTIPLE_READ
31. 31 並列readによる消費スロット数 最適化前 最適化後 https://github.com/GoogleCloudPlatform/professional-services/tree/master/tools/bq-visualizer
32. 32 「希望の日時に呼ぶ」AIのまとめ l 「希望日時に呼ぶ」を提供するために、数理モデルを作成し、そのパ ラメーターをデータから集計しています。 l BigQuery MLを用いて、リアルタイムデータを活用しています。 l 円滑なサービス提供のため、BigQueryで様々なエンジニアリングを行 っています。 まとめると、BigQueryでさまざまな機能(ML, Assertなど)を実行するこ とで実現コストが抑えられてます！
33. 「希望の日時に呼ぶ」 AIデータを活用したAPIインフラ Quentin Plessis (プレシ カンタン)
34. 自己紹介 Quentin Plessis (プレシ カンタン) - フランス出身 (日本には7年ほど) - ソフトウェアエンジニア - 現在はMobility TechnologiesでSREやサーバ開発に従事
35. 全体像 - AIデータ活用 講演の前半 データ格納 集計、学習、推論 Cloud Storage BigQuery 格納 App Engine GOサーバ GOアプリ GKE 予測サービス Cloud Storageに保存されているAIデータを活用し、 配車成功率の予測などを行う予測サービス
36. 「希望の日時に呼ぶ」機能の流れ 希望日時選択 App Engine GOサーバ GKE 予測サービス 乗車可能な日時 手配料金 Cloud Storage 配車成功率予測 手配料金計算
37. 「希望の日時に呼ぶ」機能の流れ 希望日時設定 App Engine GOサーバ GKE 予測サービス 確定 Cloud Storage 配車成功率予測 探車開始時間予測 配車範囲予測
38. 「希望の日時に呼ぶ」機能の流れ 通知 App Engine GOサーバ 探車開始時間になったら、 空車を探す 探車 車両確定
39. 探車ロジック (実際とは異なる) 希望日時設定済みの方 通常配車 通常配車 通常配車対象外車両 (探車範囲内のN台に限定)
40. 予測サービス – 概要 提供する機能（API） - 配車成功率予測 (場所と希望日時と他のユーザの希望によって) - 手配料金計算 - 配車パラメータ確定（探車開始時間、配車範囲など) 処理の流れ - 必要なデータを取得する - 講演前半のアルゴリズムに従って予測する GKE 予測サービス Cloud Storage (GCS) GOサーバ App Engine
41. 予測サービス – 課題 処理の流れ - 必要なデータを取得する - 講演前半のアルゴリズムに従って予測する 課題 - 場所や日時によって、使うべきGCSデータが異なる - GCSからデータを取得するには時間がかかる - GCSデータが継続的に更新されていく（15分に一回) - データ量が多い（1kmメッシュ数 x 時間bin数) (レコード数2億以上) GKE 予測サービス Cloud Storage (GCS) GOサーバ App Engine
42. 予測サービス – アーキテクチャ 予測サービス Cloud Storage (GCS) Redis (Memory Store) Cloud Function gRPC サーバ App Engine GOサーバ データ更新ジョブ GCS新規ファイル 作成トリガー 低頻度更新データの更新 高頻度更新データの更新トリガー APIリクエスト データ取得 データ更新 データ更新 GKE
43. 予測サービス – データ GCSデータ（イメージ） - 日時bin毎に、このようなJSONデータが 用意されている Redisデータ（イメージ） - キー： <prefix>:<timestamp>:<meshcode> - 値：MessagePackでエンコードされた構造体
44. 予測サービス – Redisメモリ最適化 データを単純に保存してしまうと使用メモリが増大 対策 - データフォーマットを変更することでデータ量を減らす - キーを省略してなるべく短くする - 値のエンコーディングをJSONからMessagePackに切り替える - 元々バラバラになっていたデータを同じ構造体に合体させる - キーのハッシュ化
45. 予測サービス – Redisメモリ最適化 キーのハッシュ化 - 普通の文字列キーを「subkey」と「field」に分ける - 文字列キーからハッシュキーに切り替える （SET key value から HSET subkey field value に切り替える) 説明：キーと値以外、キーのメタデータが保存される。ハッシュに変更することで、キー のメタデータが共有されてオーバヘッドが減る。「field」の数が少ない場合、Redisが内部 的にデータをHashTableからArrayとして持つためメモリ使用が更に減る 変更後 HSET <prefix>:523953 56 value HGET <prefix>:523953 56 元々 SET <prefix>:52395356 value GET <prefix>:52395356
46. 予測サービス – パフォーマンス検証 対策毎の効果（メモリ使用削減) 予測サービスレスポンスタイム（ms) 平均 3〜4ms
47. パフォーマンスと安定性を保証するために… - GCSデータをRedisに同期 - gRPCサーバで高速な予測APIを提供 大量データに対応するために… - データの持ち方調整 - Redisのメモリ最適化 まとめ - AIデータを活用したインフラ 講演の前半 データ格納 集計、学習、推論 Cloud Storage BigQuery 格納 App Engine GOサーバ GOアプリ GKE 予測サービス Redis (Memory Store)
48. ご清聴ありがとうございました