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

Slide 1

Slide 1 text

タクシーを「希望の日時に呼ぶ」 BigQueryによるAIとAPIインフラ老木智章 & Quentin Plessis

Slide 2

Slide 2 text

2 希望の日時に呼ぶ ≠ 予約タクシーアプリ「GO」では「希望日時配車」機能が11月にリリースされました。タクシー乗務員の皆様を長時間拘束することなく、お客様を指定された時間に迎車するためのサービスです。 AIで取り組んでいる内容についてお話しします。

Slide 3

Slide 3 text

3 本日の構成 l 「希望の日時に呼ぶ」におけるAI ○ 「希望日時配車」の概要 ○ 実現のための数理モデル ○ BigQueryを用いた必要データの集計 ○ BigQuery MLを用いたリアルタイム情報の活用 ○ BigQueryの速度と価格 l AIデータを活用するAPIインフラ

Slide 4

Slide 4 text

4 自己紹介 l 老木です。 l 元画像認識エンジニア l 元強化学習の研究者 l 現BigQuery 大好き人間

Slide 5

Slide 5 text

5 一般的な予約と「希望日時配車」従来 : 車両を事前確保する。車両の拘束時間が長い。新規：希望日時直前に、車両を確保する。タクシー乗務員にとっては、通常の迎車と変わらない体験で、希望日時に対応することができる。 12:30に注文された場合、その少し前から、周辺車両を探索する

Slide 6

Slide 6 text

「希望の日時に呼ぶ」ために担当車両を事前に割り振らないため、希望日時に周辺に車両がある保証がない。車両が見つからない際のデメリットは大きい。「周辺車両が希望日時に到着する確率」を算出し、確率が十分に高い場合のみ注文を受け付ける。この確率をデータから求める！ 12:30を希望されたけど、 12:00に１台も周辺車両がない or 注文数に足りない

Slide 7

Slide 7 text

7 l 「希望日時配車」の概要 l 実現のための数理モデル l BigQueryを用いた必要データの集計 l BigQuery MLを用いたリアルタイム情報の活用 l BigQueryの速度と価格

Slide 8

Slide 8 text

配車成功確率 (実際からの省略版) 自分がその場所で待つX人目だった時、乗車にはその場所にX台の車両が必要。 10分前から車両を探す時、10分以内にX台発見できる確率を求め配車成功確率とする。右は車両がX台来るまでの時間の確率分布。次ページで右の分布の求め方を説明する。 10分以内に車両を2台発見したい。配車成功確率は青い部分の面積

Slide 9

Slide 9 text

9 車両発見時間の確率分布車両が1時間に来る平均台数がM台のとき、車両がX台来るまでの時間は、M, Xをパラメーターとしたガンマ分布に従うと期待される。この車両が来る平均台数Mをデータから求める。平均台数は、時間帯・場所に影響されると考えられるため、時間帯・場所ごとに集計する。

Slide 10

Slide 10 text

全国の平均台数の算出平均車両台数は l 1km四方で l 曜日ごとに l 30分単位で算出する。例：東京駅付近の土曜日の時間帯 12:30-13:00 では平均12.3台

Slide 11

Slide 11 text

11 注文受付成立までの流れ 1. 前もって平均車両台数Mを算出する 2. リクエストが来た際、周辺の注文数Xを算出する 3. M, Xをパラメーターとしたガンマ分布を用いて、配車成功確率Pを求める 4. Pが閾値(99%など)を超えていれば注文を受け付ける、超えていなければ注文を拒否する

Slide 12

Slide 12 text

12 l 「希望日時配車」の概要 l 実現のための数理モデル l BigQueryを用いた必要データの集計 l BigQuery MLを用いたリアルタイム情報の活用 l BigQueryの速度と価格

Slide 13

Slide 13 text

BigQuery の概略 Google Cloud Platform上で提供されるSQL実行エンジン。一つのSQL文を多数のノードで実行するため、大量のデータを高速に処理できる。また、 l 配列や構造体をエントリとして持てる l 機械学習モデルの訓練や推論を行える l SQL上でASSERTION (エラーチェック) が行えるといった特徴がある。

Slide 14

Slide 14 text

どんなデータがあるの？車載アプリを通じて l 数秒おきの車両位置情報 l メーター情報 (空車かどうか) l 送迎位置情報などを収集し、BigQuery上に蓄積している。 1日数億件オーダーの規模。

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

集計結果例 kepler.glを用いて車両台数を可視化し、結果を確認している。 kepler.glはデータ量が多く (100MB〜)とも可視化できる。

Slide 17

Slide 17 text

17 l 「希望日時配車」の概要 l 実現のための数理モデル l BigQueryを用いた必要データの集計 l BigQuery MLを用いたリアルタイム情報の活用 l BigQueryの速度と価格

Slide 18

Slide 18 text

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時以降の平均車両台数を予測する

Slide 19

Slide 19 text

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 )

Slide 20

Slide 20 text

特徴量の作成 (擬似コード) 過去の履歴だけでなく、 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 ),

Slide 21

Slide 21 text

21 予測時間別モデルの運用 l 直近の予測を精度良く行うため、30分後, 60分後, 180分後... の車両台数を予測するモデルを個別に作成している。 l 乗車直前での利用が多いため、直近を精度良く予測するのは重要

Slide 22

Slide 22 text

Assertionによる異常値の防止モデルは異常値を出力する可能性があるため、ASSERT文を用いて弾いている。異常を検出すると、その時間のクエリを失敗とし、前の時間の予測結果にフォールバックする。 ASSERT ( SELECT -- 欠損値 & 範囲チェック LOGICAL_AND( cars BETWEEN 20 AND 300 ) FROM target ) AS "out of range";

Slide 23

Slide 23 text

BQMLのメリット / デメリットメリット l データがBQ上にある場合、データの取得・推論結果の格納が容易 l プロジェクトで用いるサービス数が減るデメリット l 評価関数や損失関数が選べない l 学習プロセスのカスタマイズ性が低い (e.g: イテレーション回数) l ローカルでの結果と比較した方が良い

Slide 24

Slide 24 text

24 l 「希望日時配車」の概要 l 実現のための数理モデル l BigQueryを用いた必要データの集計 l BigQuery MLを用いたリアルタイム情報の活用 l BigQueryの速度と価格

Slide 25

Slide 25 text

25 速度と価格リアルタイム情報を反映するために、数十分ごとに集計処理と機械学習モデルの推論処理を起こっている。他の処理との兼ね合いから10分程度でBQ上の処理を終える必要があり、全国の車両情報を扱うとシビアな条件となる。 BigQueryのコストを抑えつつ、この性能要件を達成したい。

Slide 26

Slide 26 text

26 料金プラン BigQueryは２つの料金プランがある。 l オンデマンド : 読み込みデータ量に対して課金される。プロジェクトあたり同時実行スロット数 2000。スロット割り当て保証なし l 定額プラン: スロット割り当てを予約する。割り当て保証があるため、クエリの実行時間が安定する定額プランを使いたいが、クエリの計算量が多いため割高になる。

Slide 27

Slide 27 text

27 オンデマンドでのサービス提供オンデマンドプランでサービスを提供するために、 l 遅延した際に、以前の予測へのフォールバック直前の予測が間に合わなかった場合は、60分前予測の結果を使うなどを行い、サービス提供を持続させている。 l クエリの高速化による制限時間内での実行成功確率の向上とはいえ、直前の予測の方が精度が良いので間に合う確率を上げている。

Slide 28

Slide 28 text

28 クエリジョブの実行時間プロット

Slide 29

Slide 29 text

クエリ高速化 bq-visualizerを用いて、クエリの最適化を行っている。クエリはステージと呼ばれる単位に分割され実行されるが、ステージごとの実行時間等がわかる。 https://github.com/GoogleCloudPlatform/professional- services/tree/master/tools/bq-visualizer

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

31 並列readによる消費スロット数最適化前最適化後 https://github.com/GoogleCloudPlatform/professional-services/tree/master/tools/bq-visualizer

Slide 32

Slide 32 text

32 「希望の日時に呼ぶ」AIのまとめ l 「希望日時に呼ぶ」を提供するために、数理モデルを作成し、そのパラメーターをデータから集計しています。 l BigQuery MLを用いて、リアルタイムデータを活用しています。 l 円滑なサービス提供のため、BigQueryで様々なエンジニアリングを行っています。まとめると、BigQueryでさまざまな機能(ML, Assertなど)を実行することで実現コストが抑えられてます！

Slide 33

Slide 33 text

「希望の日時に呼ぶ」 AIデータを活用したAPIインフラ Quentin Plessis (プレシカンタン)

Slide 34

Slide 34 text

自己紹介 Quentin Plessis (プレシカンタン) - フランス出身 (日本には7年ほど) - ソフトウェアエンジニア - 現在はMobility TechnologiesでSREやサーバ開発に従事

Slide 35

Slide 35 text

全体像 - AIデータ活用講演の前半データ格納集計、学習、推論 Cloud Storage BigQuery 格納 App Engine GOサーバ GOアプリ GKE 予測サービス Cloud Storageに保存されているAIデータを活用し、配車成功率の予測などを行う予測サービス

Slide 36

Slide 36 text

「希望の日時に呼ぶ」機能の流れ希望日時選択 App Engine GOサーバ GKE 予測サービス乗車可能な日時手配料金 Cloud Storage 配車成功率予測手配料金計算

Slide 37

Slide 37 text

「希望の日時に呼ぶ」機能の流れ希望日時設定 App Engine GOサーバ GKE 予測サービス確定 Cloud Storage 配車成功率予測探車開始時間予測配車範囲予測

Slide 38

Slide 38 text

「希望の日時に呼ぶ」機能の流れ通知 App Engine GOサーバ探車開始時間になったら、空車を探す探車車両確定

Slide 39

Slide 39 text

探車ロジック (実際とは異なる) 希望日時設定済みの方通常配車通常配車通常配車対象外車両 (探車範囲内のN台に限定)

Slide 40

Slide 40 text

予測サービス – 概要提供する機能（API） - 配車成功率予測 (場所と希望日時と他のユーザの希望によって) - 手配料金計算 - 配車パラメータ確定（探車開始時間、配車範囲など) 処理の流れ - 必要なデータを取得する - 講演前半のアルゴリズムに従って予測する GKE 予測サービス Cloud Storage (GCS) GOサーバ App Engine

Slide 41

Slide 41 text

予測サービス – 課題処理の流れ - 必要なデータを取得する - 講演前半のアルゴリズムに従って予測する課題 - 場所や日時によって、使うべきGCSデータが異なる - GCSからデータを取得するには時間がかかる - GCSデータが継続的に更新されていく（15分に一回) - データ量が多い（1kmメッシュ数 x 時間bin数) (レコード数2億以上) GKE 予測サービス Cloud Storage (GCS) GOサーバ App Engine

Slide 42

Slide 42 text

予測サービス – アーキテクチャ予測サービス Cloud Storage (GCS) Redis (Memory Store) Cloud Function gRPC サーバ App Engine GOサーバデータ更新ジョブ GCS新規ファイル作成トリガー低頻度更新データの更新高頻度更新データの更新トリガー APIリクエストデータ取得データ更新データ更新 GKE

Slide 43

Slide 43 text

予測サービス – データ GCSデータ（イメージ） - 日時bin毎に、このようなJSONデータが用意されている Redisデータ（イメージ） - キー： :: - 値：MessagePackでエンコードされた構造体

Slide 44

Slide 44 text

予測サービス – Redisメモリ最適化データを単純に保存してしまうと使用メモリが増大対策 - データフォーマットを変更することでデータ量を減らす - キーを省略してなるべく短くする - 値のエンコーディングをJSONからMessagePackに切り替える - 元々バラバラになっていたデータを同じ構造体に合体させる - キーのハッシュ化

Slide 45

Slide 45 text

予測サービス – Redisメモリ最適化キーのハッシュ化 - 普通の文字列キーを「subkey」と「field」に分ける - 文字列キーからハッシュキーに切り替える（SET key value から HSET subkey field value に切り替える) 説明：キーと値以外、キーのメタデータが保存される。ハッシュに変更することで、キーのメタデータが共有されてオーバヘッドが減る。「field」の数が少ない場合、Redisが内部的にデータをHashTableからArrayとして持つためメモリ使用が更に減る変更後 HSET :523953 56 value HGET :523953 56 元々 SET :52395356 value GET :52395356

Slide 46

Slide 46 text

予測サービス – パフォーマンス検証対策毎の効果（メモリ使用削減) 予測サービスレスポンスタイム（ms) 平均 3〜4ms

Slide 47

Slide 47 text

パフォーマンスと安定性を保証するために… - GCSデータをRedisに同期 - gRPCサーバで高速な予測APIを提供大量データに対応するために… - データの持ち方調整 - Redisのメモリ最適化まとめ - AIデータを活用したインフラ講演の前半データ格納集計、学習、推論 Cloud Storage BigQuery 格納 App Engine GOサーバ GOアプリ GKE 予測サービス Redis (Memory Store)

Slide 48

Slide 48 text

ご清聴ありがとうございました