BETA

英語記事のサマリ - UberのAIラボが #Pyro という深層学習+ベイズのライブラリを発表(2017)

投稿日:2019-02-04
最終更新:2019-02-04

UberのAIラボがPyroという深層学習+ベイズのPythonライブラリを発表したブログ記事をサマリ翻訳してみた.

2017年11月の記事で若干古いが, 他にPyMC4やTFP(Tensorflow Probability)などのライブラリがある現状, Pyroがどのようなポジショニングをしているか確認する目的.

注)正確な翻訳ではなくあくまでも記事の翻訳サマリなので, 個人的に重要でないと判断した部分は省略したり, 原文がわかりづらい部分は意図的に言葉を付け加えたり補足したりしてます(`・ω・´)(ぺこり)

TL;DR

  • UberのAIラボが Pyroという深層学習+ベイズのPythonライブラリを発表した
  • 確率モデリングによりデータの不確実性を推論し, 専門家の知識をAIシステムに活用することができる
  • 4つのコンセプトがある
    • 汎用性
    • 拡張性
    • 最小限
    • 柔軟性
  • 既存の確率プログラミング言語の枠組みに加え, guide という概念を取り入れている

内容

はじめに

Uberのやりたいことはユーザに信頼性のある移動手段を提供することで, そのためには毎回の予測と最適化を容易に行う必要がある.

用途としては主に以下の通り.

  • 乗り手とドライバーとのマッチングをする
  • 最適なルートのレコメンドする
  • 賢いライドシェアの組合せを見つける
  • 次世代の自動運転車を開発する

これらの課題を解決していく試みの中で, UberのAIラボがOSSとして Pyro を発表した. Pyroはモダンな深層学習とベイズ統計モデリングの手法を統合したツール.

なぜPyro?

  • なぜ確率モデリングが必要?
    • 教師なし学習および半教師つき学習のモデルと予測の不確実性を正しく捉え, 専門家の前提知識をAIシステムに組み込むため.
  • なぜ確率プログラムが必要?
    • 複雑なモデルを構築するための明確で高レベルかつ完全なツールが必要なため.
  • なぜ深層確率モデルが必要?
    • データから生成過程を学び, どのように推論するか知識を具体化するため.
  • なぜ最適化による推論が必要?
    • 大量データにもスケールして対応できるよう, モダンな最適化と変分推論を活用するため.

以下は詳細.

確率やそれを用いたモデルによって不確実性を推論し, それによりデータから「何がどれだけわかっているか?」「何がどれだけわからないか?」を理解することができる. 加えて, その業界の専門家の前提知識をそのAIシステムに組み込むことができる.

確率モデルの実装はめんどうでバグりやすいので, 「確率プログラミング言語(Probability Programming Language)」というものが必要になる. これを用いることで確率モデルの実装に伴う決定論的な計算(例: 1+1=2 など)と乱数生成(例: 正規分布から値をサンプリングする)を自然に組み合わせることができる.

Pyroはそれらを可能にし, かつ既存の確率プログラミング言語の問題点であるスケーラビリティの低さを解消しつつ, 深層学習の手法も取り入れている. 重要な概念としては 第二のモデル(guide) を導入しており, これは Helmholtz machine のアイディアである. 通常の確率モデル(第一のモデル)はデータの生成過程表し, guide(第二のモデル)はデータを潜在変数への変換の生成過程を表している.

注) ↑ このあたりは説明不足っぽいので, 別の資料を参考にしたい(`・ω・´)

もちろん正確なguideを実装するのは不可能なので, そのかわりに 変分 の手法を用いて最適化問題を解くことでguideをモデルの事後分布に近づけるようにする. この最適化は 自動微分 で行われるため, 勾配計算などを自動で効率的に計算してくれる. このあたりは PyTorch というPyroのバックエンドのライブラリによって行われる.

Pyroのデザインコンセプト

  • 汎用性: 汎用的なPythonコードでループや再帰, および乱数生成や推論ができること
  • 拡張性: 少しのオーバーヘッドで大量データにスケーラブルに対応できる(最適化やミニバッチ, 近似推論などを用いて)
  • 最小限: 内部的に, 組合せ可能な抽象的なコードで実装されている(Pytorchや他ライブラリに処理を委譲している)
  • 柔軟性: 高レベルな抽象的なAPIを提供しつつ, より複雑な推論やモデルが必要であればカスタムすることもできる

これらのコンセプトを実現しようとすると, 実際には相反している項目があるため実現が難しい. 例えば汎用性を上げるとスケーラビリティを担保するのが難しくなり, 最小の抽象化を実現しようとすると応用的なカスタマイズが難しくなり拡張性が下がる.

これらの問題を解決するためにWebPPLやEdwardなどの他の確率プログラミング言語のさまざまなテクニックを拝借してきた.

  • 組み合わせ可能なハンドラーによるコントロールフローと計算処理の分離:
    • Poutine(Pyro Coroutine)
    • Trace
    • Replay
    • Condition

今後の課題

  • 抽象化の改善によるモデリングプロセスの高速化(例: 自動デフォルトguideなど)
  • マルコフ連鎖モンテカルロ法(MCMC)やSMC, HMCによる推論エンジンの追加
  • ガウス過程やベイズ最適化などの追求

参考資料

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

@yukinagaeの技術ブログ

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう