Above & Beyond

日々のアウトプット記録

Repro Tech #7 Practical AI Supported by NAVITIME

04/04(木) は「Repro Tech #7 Practical AI Supported by NAVITIME」に参加してきました。

repro-tech.connpass.com

f:id:kabukawa:20190330195042p:plain:w500

会場は NAVITIME さん。

f:id:kabukawa:20190405143120j:plain


目次


Repro Techとは

昨年開催されたAIの回の参加報告がありますので、こちらも併せてどうぞ。

kabukawa.hatenablog.jp


タイムテーブル

時間 内容
19:00 開場
19:30 はじめに
19:40 深層学習を速くするいくつかの方法 by Kota Uenishi
20:05 データサイエンスレガシーコードに立ち向かう by Sho Shimauchi
20:30 休憩 (軽食)
20:35 不確実性と上手く付き合う意思決定の手法 by Takashi Nishibayashi
21:00 REPROのAI機能を支える技術 by Takeshi Kamada
1:25 LT : Sponsor AIを選択する自由
21:30 懇親会
2:30 解散

内容

f:id:kabukawa:20190405143132j:plain


深層学習を速くするいくつかの方法

Kota Uenishi さん(Preferred Networks)

speakerdeck.com


なぜ深層学習を速くするのか?

👉 PFNは最新の研究や技術を最も早く実用化する

  • 機械学習(深層学習)の開発サイクル
    f:id:kabukawa:20190405153054p:plain:w500
    • [深層ネットワークを定義]
    • [学習実験をしてモデルを作る]
    • [テストデータで精度を確認する]
      という作業の繰り返し、つまり学習フェーズが試行錯誤のボトルネック

👉 強いモデルを作るためには

  • よいデータで学習すること
  • よいネットワークであること
  • よいレシピで学習すること
  • よいハイパーパラメータが与えられること
  • 何度も繰り返し試行錯誤すること

👉 1GPUで速くする

  • 深層学習 ≒ DNNをSGDでデータに対して最適化する
    1. データをシャッフルしてミニバッチに分割する
    2. 分割したミニバッチごとに、モデルに対してまとめ
      1. 前向き計算をして推論結果を出す
      2. 推論結果と正解データのズレ(距離)を計算
      3. ズレをもとに後ろ向き計算(backpropをする)
      4. 後ろ向き計算で得られた勾配の平均を計算
      5. 勾配をモデル䛾パラメータに反映
        この手順を好きなだけ繰り返す

👉 並列処理で速くする

  • ChainerMNによる分散学習
  • All-Reduceを速くする

👉 ハードウェアで速くする


個人メモ:

  • データやアルゴリズムの改善の繰り返しはどの会社でも行われてはいるけど、そのサイクルの速さはやっぱりPFN凄いと感じる。
  • 研究やPoCの速さというのは研究自体の力もあるけど、それを支える開発やインフラのエンジニアの力も相当必要。
  • Kubernetes(kubeflow)によって試行錯誤を速くできるように、という判断ができるのが強いなと思った。普通の会社なら構築や運用が複雑になったりすると考えるだけで尻込みしそう。
  • 自前でハードウェアを開発できるというのも強い。クラウドで大量の計算リソースが手に入るようになったとはいえ、専有できるハードウェアを作れる/持っているというのは貴重だし、最終的にはそこが地力の差になって現れてくると思っているので、これは本当に凄いこと。

データサイエンスレガシーコードに立ち向かう

Sho Shimauchi さん(Solutions Architect at Luminoso Technologies.)

speakerdeck.com


👉 今の仕事で得た知見

  • 今までの自分の認識: 機械学習をやるには大量にデータ集めて前処理して特徴エンジニアリングしてモデル作って検証して……が終わってからそのモデル使って何かをし始める
  • 今の自分の認識: 「さいきょうのモデル」がある前提でその先の仕事をする世界がある

👉 データサイエンスレガシーコード

「レガシーコードとは、単にテストのないコードです」

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

  • データサイエンスのコードはテストがないコードである(ことが多い)
  • しかしこれらのコードを別のアプリやサービスに組み込んだり、保守をしなければいけないケースは増えてくる
  • このようなコードをデータサイエンスレガシーコードと呼んでいる

「バグを見つけることは重要ですが、直近の目標は変更をより確実に行うための役立つテスト環境を作ることです」

この本では、この手法を 仕様化テスト と呼んでいる

👉 pytest

テスト駆動Python

テスト駆動Python

  • Pythonのテストフレームワーク
    $ pip install pytest pytest-cov pytest-randomly pytest-mock でインストール
    • テストカバレッジを計測する
      pytest-cov · PyPI
      $ pytest --cov=source_dir --cov-report=html で実行
    • モックオブジェクト(あるオブジェクトを擬装するオブジェクト)を使うためのツール
      pytest-mock · PyPI
    • テスト実行時にランダムな順序で実施する暗黙的にテストの実行順序を仮定したテストが混じってないかを確認可能
      pytest-randomly · PyPI
      $ pytest --randomly-seed=1234 で実行(1234はシード値)

👉 scripttest

コマンド実行をそのままテストに落とし込むための、機能テストツール
scripttest · PyPI
$ pip install scripttest でインストール

👉 flake8

  • コードフォーマッター兼静的解析ツール
    flake8 · PyPI
    $ pip install flake8 でインストール
    $ flake8 target.py で実行

👉 プロファイリング


個人メモ:

  • AI/機械学習のプロジェクトをプロダクション環境で運用し始めれば、レガシーコードとの闘いは必ずある、というのはよく分かる。
  • そういうコードにはテストがないことが多い、というのもありがち。
  • 時間/リソースを割けるかとか顧客が金を出すかはなかなか難しいということはあるものの、そうなる前にここに挙げられたツール類を入れてレガシーコードを改善するというのは禿同。
  • ところで、プロダクション向けコード書くのに、みんな何使っているの?PyCharm?まさかJupyter notebookで書いたコードをそのまま?まさか、いや、それもあり得る気がしてきた。。。

不確実性と上手く付き合う意思決定の手法

Takashi Nishibayashi さん(Software Engineer at VOYAGE GRUOP)

speakerdeck.com


機械学習で得た予測値をどのようにして使うか、予測の次の意思決定のフェーズに注目

  • 予測システムと意思決定
  • ビジネスにおける最適化
  • ラベル無しデータの探査
  • 予測モデルの不確かさを行動に反映する
  • オンライン最適化

👉 予測システムと意思決定

f:id:kabukawa:20190406122948p:plain:w500

  • できれば自動で決めたい、ではどうすれば?
  • むしろアプリケーションエンジニアの仕事は自動化がメイン

数理最適化

  • ある制約の元で目的関数を最大(最小)化するパラメータを求める
  • 不確実性の無い問題とは?

例:生産計画

  • 予測を利用した最適化
  • 予測を利用している時点で、何らかの不確実性を内包している

紹介する主な方策

  • 以下の繰り返し
    1. 予測
    2. 意思決定・行動
    3. 結果の観測
    4. 予測器の更新

余談: 最適とは何か?

f:id:kabukawa:20190406123915p:plain:w500

能動学習(Active Learning)

f:id:kabukawa:20190407002806p:plain:w500

貪欲法(Greedy Algorithm)

f:id:kabukawa:20190407002826p:plain:w500

補足: さらなる困難

f:id:kabukawa:20190406124149p:plain:w500

note.mu

  • 最適とは一体何なのか

👉 まとめ

f:id:kabukawa:20190407003439p:plain


参考文献:

  1. [1806.10692] ActiveRemediation: The Search for Lead Pipes in Flint, Michigan
  2. [1209.3353] Further Optimal Regret Bounds for Thompson Sampling
  3. バンディット問題の理論とアルゴリズム (機械学習プロフェッショナルシリーズ)
  4. [1209.3352] Thompson Sampling for Contextual Bandits with Linear Payoffs
  5. Incrementality Bidding & Attribution by Randall A. Lewis, Jeffrey Wong :: SSRN
  6. パターン認識と機械学習 下 (ベイズ理論による統計的予測)
  7. 情報理論の基礎―情報と学習の直観的理解のために (SGC Books)
  8. "Introduction to online convex optimization."
  9. [1708.03741] Online Convex Optimization with Stochastic Constraints

個人メモ:

  • 話されている内容が具体的な手法についてという事もあり、基礎的なところを理解できていないことを痛感した。
  • 参考文献が示されているので、これらを読んで勉強をしていきたい。
  • 水道管のプロジェクトの結末についてのnoteの記事は読んでいたけど、使われていた手法と併せて話を聞くと更に興味が湧いたのでありがたかった。

REPROのAI機能を支える技術

Takeshi Kamada さん(Repro)

speakerdeck.com


👉 話すこと

👉 Repro AI Labs.

  • データ分析
  • PoC
  • ML Ops
  • Repro本体への機能追加

アーキテクチャ(Repro)

f:id:kabukawa:20190407010613p:plain:w500

最近のCTOの発表


👉 ML基盤

f:id:kabukawa:20190407010719p:plain:w500

👉 最速リリースのポイント

  • 構築が楽なサービスを使った
  • Repro本体の既存の仕組みに乗れた

👉 最速でリリースしたツケ

  • 前処理・学習・予測全て1スクリプト1タスクで実行
    • 途中でコケた時に全て再実行…
  • 処理時間が線形に増加してスケールできない
    • 一時期は7時間かかっていた…
  • 捕捉できてないエラーがあった
    • コケていたことに気付かずインシデントに…

👉 Dataprocアンチパターン

  • Jupyter notebookもscikit-learnもインストールできる
  • やろうと思えはMLバッチ処理に使える?!
  • でもやらないほうがよい
    • Python側でマシンリソース使いすぎた時にSparkのJobが落ちる

👉 改善できた理由

  • 今後のAI機能開発を見据えたチーム増員
  • AIエンジニアに不足しがちな視点を補完(きっとアルゴリズムや予測精度で頭いっぱいですよね)

まなび

  • 推測するな 計測せよ
    • 適切にログを追加
    • 通信に無駄に時間がかかっていたのがわかって改善につながった
  • 技術スタックの理解を深める
    • 知らないと使えない
    • 知ることで監視設定など追加できた
  • 雰囲気で運用をやらない
    • チームでSLO設定
    • Redashのダッシュボード作成
  • リファクタリング
    • 前処理・学習・予測を分割した
    • 再実行しやすくなった
    • SocketTimeoutException がでなくなった

f:id:kabukawa:20190407013539p:plain:w500


個人メモ:

  • こういう実務での改善や運用周りの話は、聞いていて学びが多いので聞くことができて良かった。
  • マルチクラウドを使う時のポイント/注意点は色々あると思うので、その辺りが聞いてみたいと思った。

AIを選択する自由

大川舞子 さん(NAVITIME)

www.slideshare.net


結論

  1. どうしてAIを使うのか?
  2. AIの方が楽だからと言える時だけ AIを選択しよう

NAVITIME社のレコメンデーションの歴史

  • 機械学習黎明期に0から機械 学習モデルを実装。
    • → 改善しても精度が良くな らない。メンテ辛い
    • → 費用対効果が伴わない ため一度機能をクローズ

なぜ今 AIでレコメンデーションを 作っているのか?

  • 外部サービスが提供されつつある
  • 学習データがシンプルで既存資産が利用できる
  • 機は熟した

検討した方法

  • 自分で機械学習モデルを作る
  • OSSを利用する
  • 外部サービスを利用する Amazon Personalize (beta)

Microsoft / Product Recommendations Solution

  • Microsoft の AI レコメンド サービス がOSS
  • eコマースレコメンドに最適化したモデル/パラメータが 利用可
  • REST API / テストツール/ Swaggerも同時提供

github.com

学習データについて

モデル生成(日次)の処理の流れ

f:id:kabukawa:20190407015405p:plain:w500

推論(ユーザーリクエスト)

f:id:kabukawa:20190407015427p:plain:w500

将来的にはサービス本体もオンプレからクラウド

f:id:kabukawa:20190407015506p:plain:w500

まとめ

費用対効果があると 判断した時だけ AIを選択することで 世界平和を実現しよう


個人メモ:

  • 確かにML系のクラウドサービスは充実してきているし、OSSも増えているので機は熟したというのは分かる。
  • 自前で作るだけでなく、適切な(要件にFitする)サービス/OSSを探して適用するというところも技術者としては必要になってくるのではないか?
  • 当たり前ではあるけど、AIありきではない、なぜ必要なのか?それに対する必要な資金は用意されているのか、というところがこれからますます大事になってくるんだろうな、ということを思った。

懇親会

f:id:kabukawa:20190405143143j:plain

楽しくお話をさせていただいた皆様、ありがとうございました!


まとめ

今回もとても充実した内容で、あっという間の2時間でした。 知らないことも多く、まだまだ勉強が足りないと思ったので、今回の内容に対して自分でも知識を深めていきたいなと思いました。 3回目の参加になったのですが、開催されるたびに内容も運営も充実してきていて、とても良い勉強会だと思っています。 また次回開催されるときには是非参加したいです。

登壇者、スタッフ、参加者の皆様、ありがとうございました!