1.
第42回IBISML研究会
加納龍一
タクシー運行最適化を実現する
機械学習システムの社会実装

2.
▪ 加納龍一 (かのうりゅういち)
▪ DeNAに入社→Mobility Technologiesに出向
▪ 交通移動体データの解析や、それらを活用した機械学習システムの社会実装
▪ 総合研究大学院大学の社会人学生
▪ 国立情報学研究所にお世話になっています
自己紹介
2

3.
項目
01｜導入
02｜アルゴリズム
03｜サービスの継続展開に関して
04｜まとめ
3

4.
01 導入
4

5.
▪ 2020年9月よりサービス開始
▪ 今日は、タクシードライバーに向けた機能提供の話をします
タクシー配車アプリ GO
5

6.
▪ アプリ需要よりも流し需要が多い
▪ 流し需要：乗客が手を上げてタクシーを捕まえるもの
日本のアプリ配車比率
6
https://www.slideshare.net/dena_tech/dena-techcon-2019-132196217

7.
乗務員依存の探客スキル
▪ 乗務員は歩合給であることが多いので、探客スキル向上はとても重要
7
https://www.slideshare.net/dena_tech/dena-techcon-2019-132196217

8.
▪ 乗客を効率よく発見するための経路を乗務員に提供する
▪ 道路単位での経路
▪ 地域ごとの需要ヒートマップなどではなく、行動を具体的に示す
実現したい機能
運⾏経路
位置情報
8

9.
9 (動画)

10.
02 アルゴリズム
10

11.
▪ 車両のGPS位置情報
▪ 車両の状態変化 (空車, 実車…)
▪ 道路ネットワーク
▪ など
データ
11
©ZENRIN

12.
▪ GPSの情報を道路ネットワーク(有向グラフ)にマッピング
▪ 道路ネットワーク上で全ての情報を集計
すべての情報を道路に紐づける：マップマッチ
https://github.com/amillb/pgMapMatch
とある道路での乗⾞数
このような様々な情報の系列が、全道路セグメントで得られる
12

13.
▪ 状態：どの道路にいるか
▪ 行動：どの道路からどの道路に移動するか (右左折、直進...)
▪ 報酬：売り上げなど
定式化
⾏動
状態
報酬
エージェント 環境
13

14.
▪ 任意のVからQを求め、そのQからVを求め…
▪ 収束するまで反復を繰り替えす
▪ 最終的に獲得されたQを用いて、行動方策(=行動の確率分布)を決定する
価値反復
*実際に使⽤されている式とは違います
s: state(状態: 道路)
a: action(⾏動: 右左折直進等)
pp: 乗⾞確率 (pickup-prob)
fare: 運賃の期待値
γ: 割引率
t: ⾏動に要する時間
cost: ⾏動にかかる罰則
添字t: 乗客を⽬的地まで運ぶ移動
添字n: 隣接の道路までの移動
14

15.
▪ 基本的には典型的な時系列データの教師あり学習
▪ 実車両の情報を逐次反映しながら、リアルタイムに動かす
各種特徴量の予測
ML-model
直近の乗⾞数
各種統計量
・・・
未来に発⽣する乗⾞数
15

16.
▪ 実車両の軌跡から、報酬(=行動しやすさ、しにくさ)を推定
▪ 例：とある場所へ到着した車両がどこから来たかを模倣する報酬を獲得
行動コストの推定: 逆強化学習
推定された報酬の例 (状態成分のみ)
Goal
報酬 ⾏動
逆強化学習
強化学習
16
©ZENRIN

17.
17
▪ 推定結果の例
▪ 状態成分のみ可視化
行動コストの推定: 逆強化学習
細かい道路
⾼速道路や、⼤きく曲がった道
©ZENRIN

18.
価値反復後の状態価値(V)の例
横浜スタジアム、中華街
横浜駅
商店街
18
©ZENRIN

19.
▪ 生成した経路に従うとどれだけの売り上げとなるかを見積もる
▪ 交通需要や需要単価、乗客の目的地などは、実データを用いて模擬
▪ １日分のシミュレーションを並列で実施し、終了後に結果を集計
シミュレータ
19

20.
▪ 2019年12月にサービス開始
▪ お客様探索ナビ: https://dena.com/jp/press/004550
▪ 2021年現在も稼働中
▪ ナビを使った乗務員の方が、効率的に乗客を獲得できている
サービス展開
20

21.
03 サービスの継続展開に関して
21

22.
アルゴリズム概観
需要・供給予測
(典型的な教師あり学習)
行動コスト推定
(逆強化学習)
経路推薦
(強化学習)
・・・
MDP parameters
・経路推薦そのもの以外にも、大量のコンポーネントが存在
・ひとつひとつの要素がハイパーパラメータを持つ
・性能評価のために用いるシミュレータも、なかなか複雑
22

23.
▪ 世の中は変化している
▪ 商業施設の開店や閉店、季節変動、サービス展開範囲の変化など
▪ 一度デプロイしたサービスの定期的なアップデートが重要
着眼点：モデルの経年劣化
高需要道路 低需要道路
5/26 施設閉店
23

24.
▪ 調整するハイパーパラメータの数が多すぎる
▪ 各機械学習モデルのパラメータ(e.g., モデル構造, 学習率…)
▪ 価値反復の中のパラメータ(e.g., 割引き率, 正則化の重み…)
▪ 手作業での運用は大変
▪ 特に、複雑な依存関係を持ったものを扱う際のヒューマンエラーが怖い
▪ 物凄い数の並列パラメータ探索に耐えることのできるインフラが重要
課題感
今回はGCP (Google Cloud Platform)を想定
24

25.
▪ Compute EngineなどでVMインスタンスを立てまくる
しかし、よく考えてみると...
▪ インスタンスの種類を変えるときには全部立て直す？
▪ 実行した後にインスタンスを自動で落とすスクリプトを仕込む？
▪ 環境構築、やればできるがいちいち面倒では？
一番最初に思いつく方法：VMインスタンスの大量作成
管理コストが尋常じゃない
25

26.
▪ 概観
もう一歩先へ：AI Platform Trainingの使用
Local Machine
AI Platform Training
Container Registry
push
pull
command:
・マシンタイプ
・Docker image
・実行引数
job execution (CLI or python function)
所定のマシンでコンテナを動かし、
終わったらマシンを自動で消す
CLIコマンド例
＊カスタムコンテナを使うことが多いので、その場合を説明
26

27.
▪ jobを複数投入すれば、複数同時に実行することが可能
▪ 大量のインスタンスを用いた実験が簡単に！
もう一歩先へ：AI Platform Trainingの使用
とある実験のスクリーンショット
30程度のインスタンスが同時に動作
ダッシュボードをクリックすれば、
ジョブごとのログや入出力なども確認できて便利
27

28.
▪ 個人的には、シンプルなタスクに対してであれば十分だと思う
▪ “学習して予測精度を評価するだけ”の場合などは特に便利
▪ しかし、凝ったことをしようと思うと、欲が出てくる
▪ 複数のコンテナ間で依存関係を保ちながら、よしなに動いてほしい
▪ 前処理、学習、評価、解析、シミュレーション...
▪ AI Platform Trainingのジョブ投入から起動までのラグ(~5min)が気になる
▪ 複数インスタンスを用いた分散学習がしたい
⇨Dockerで管理できる内容の外側に意識が広がる
AI Platform Trainingで十分か？
28

29.
▪ Dockerコンテナの運用管理のためのオープンソースシステム
▪ Cluster, Node, Podという構成要素
▪ Cluster: インスタンスの集合
▪ Node: ひとつのインスタンス
▪ Pod: インスタンスで実行される処理単位
Kubernetes (k8s)
29

30.
▪ できることの例
▪ ジョブを投入したら、PodをどのNodeで動かすか自動で割り当ててくれる
▪ 処理の状況に応じて、Nodeの数をオートスケールして増やす/減らす
▪ 使用量が少ないときにはコストはきちんと少なくなる
▪ 実験用途だけでなく、サービスのデプロイなどに使われることも多い
▪ リカバリなどが充実
▪ クラウドサービスとの連携は必ずしも必要ない
▪ ここには詳しく書ききれないほど多機能
Kubernetes (k8s)
30

31.
▪ コンテナ間の依存関係を解決しながらパイプラインを動かす
▪ 並列で動かせる部分は並列で
▪ 実行に失敗したものについてはリトライ
▪ 可視化との連携
▪ メトリクス
▪ 実行関係
▪ メタデータ
実験観点で実現したいこと
31

32.
▪ Kubernetes環境でパイプラインを構築し実行するツール
▪ DAGのコンポーネントがコンテナに対応
▪ 裏ではArgoが動いている
▪ DAGのデプロイが簡単
▪ Airflow(Composer)と比べると実験向き
Kubeflow Pipeline
32

33.
Kubeflow Pipeline
組込の可視化機能に加えて、
実験結果分析用のjupyter notebook実行を
DAGの一部にしておくと
自由度の高い可視化がUI上で表示できて便利
33

34.
▪ Kubeflow Pipeline + Optuna
▪ 複雑な構成をうまく管理しながらパラメータを探索し、収益向上に貢献
お客様探索ナビでの活用例
・パラメータ探索
・経路シミュレーションによる評価
・MDP parameterの抽出
・各処理の実行関係整備、並列実行
シミュレーション結果
パラメータ推薦
34
https://lab.mo-t.com/blog/optuna-kfp-hyperparameter-tuning

35.
35
▪ 探索ジョブの投入
パラメータ探索の流れ
https://lab.mo-t.com/blog/optuna-kfp-hyperparameter-tuning

36.
36
▪ 初期化
パラメータ探索の流れ
https://lab.mo-t.com/blog/optuna-kfp-hyperparameter-tuning

37.
37
▪ パイプラインの並列デプロイ
パラメータ探索の流れ
https://lab.mo-t.com/blog/optuna-kfp-hyperparameter-tuning

38.
38
▪ 各パイプラインの結果の集約
パラメータ探索の流れ
https://lab.mo-t.com/blog/optuna-kfp-hyperparameter-tuning

39.
39
▪ 結果の格納
パラメータ探索の流れ
https://lab.mo-t.com/blog/optuna-kfp-hyperparameter-tuning

40.
40
▪ ハイパーパラメータの提案
パラメータ探索の流れ
https://lab.mo-t.com/blog/optuna-kfp-hyperparameter-tuning

41.
41
▪ パイプラインの並列デプロイ
パラメータ探索の流れ
https://lab.mo-t.com/blog/optuna-kfp-hyperparameter-tuning

42.
04 まとめ
42

43.
43
▪ 「できるだけシンプルであること」の恩恵は非常に大きい
▪ 調整パラメータが増えて結果が少し良くなるくらいなら、使いたくない
▪ 「一度やったらおしまい」という作業は、ほとんどない
▪ 安定したパフォーマンスを発揮するアルゴリズムはありがたい
▪ 例えばパラメータに対して敏感なNNより、GBDTのほうが使いやすい
▪ が、E2Eも大切
▪ このあたりを売りにした研究や新規手法があったりすると嬉しい
所感

44.
▪ 「お客様探索ナビ」のアルゴリズムの概観を紹介
▪ 複雑な機能が互いに依存し合ったうえに成り立っている
▪ サービスを運用していく上で意識する点を紹介
▪ 経年劣化などをによる、サービスの定期更新の重要さ
▪ Kubeflow Pipelineなどを用いた試行錯誤の効率化
まとめ
44