meowの覚え書き

write to think, create to understand

Laradockでの環境構築時のエラー対処メモ

f:id:meow_memow:20200908221034j:plain

Laravelの勉強を、下記の本で取り組み始めました。

環境構築は、HomesteadではなくLaradockの方を選びましたが、私もご多分に漏れず手順通りに動かしてもエラーが出てしまい、最初のララベルの画面を拝むまでに苦戦しました。
私が躓いた箇所を念の為メモしておきます。


スポンサードリンク

ERROR: for nginx Cannot start service nginx: driver failed programming external connectivity on endpoint laradock_nginx_1 (<ハッシュ値>): Error starting userland proxy: listen tcp 0.0.0.0:80: bind: address already in use

コンテナを立ち上げる時($ docker-compose up -d nginx mysql workspace phpmyadmin)に遭遇したエラーです。 メッセージの通りですが、自分のコンピュータですでにポート80番が使用されています。 laladock/.env内の下記の部分を、空いているポート(10000番など)に変えた後、解消されます。

### NGINX #################################################

NGINX_HOST_HTTP_PORT=80

UnexpectedValueException There is no existing directory at "/var/www/storage/logs" and it could not be created: Permission denied

laravelのエンドポイントにwebブラウザでアクセスしたとき、このようなメッセージとともにデバッグ画面が出ました。 原因は、立ち上げているworkspaceコンテナに対し、ルートユーザでプロジェクトを作成してしまったためでした。 一旦、プロジェクトを消した後、laradockユーザでworkspaceコンテナへアクセス($ docker-compose exec --userlaradock workspace bash )して、プロジェクトを作ると解消されます。

【Council GAN】Im2Im論文『Breaking the cycle - Colleagues are all you need』 を 顔写真 → アニメ顔変換タスクを中心に理解する

f:id:meow_memow:20200709081635j:plain:w500

2ドメイン間で画像の対応が不要(unpaired)な GAN ベースの画像変換(Image to Image translation; im2im)手法である Council GAN について見ていく。手法の試し方も一応載せておく。 なお、私の関心は顔写真 → アニメ顔変換タスク(selfie2anime)のみなので、その他のタスク(メガネ除去、男性-女性顔変換)は扱わない。


スポンサードリンク

論文に関して

CVPR2020 に採択された論文である。
2019 年 11 月にプレプリント版が上がっていたが、2020年6月ごろになってプロジェクトページおよびリポジトリ(github)が公開された1

提案手法の要旨

f:id:meow_memow:20200709082021j:plain GAN全体系のLossにCouncil lossを追加しているところが新規性のポイントである。もう少し補足すると、Cycle Consistency Loss の代わりにCouncil loss(後述)を使った所が真新しい。

ちなみに、第1項目のGAN_lossはLSGANで使われているlossである。すなわち、識別器側は本物と生成器が生成した偽物を見分けるように学習し、生成器側は識別器を本物だと騙すように学習する時のlossである2

Council Loss とは

f:id:meow_memow:20200709082220j:plain:w500

counsilというユニットを複数用意し、それぞれのユニットが相互作用を与えるようにユニット内で loss を計算する。
このcounsilは1ユニット3つの要素からなる。画像生成器  {G_i} 、画像の真贋の識別器 D_i、そして、画像(真贋問わず)が自分のcounsilから生成されたものか否かを識別する識別器 \hat{D_i}である。なお、添字の  i i番目のcounsilにおける要素であることを表している。

council lossの定義は下記。

f:id:meow_memow:20200709082911j:plain

\hat{D_i} はGAN全体系のloss  Vを 上げたいので、自分が所属する i番目のcouncilの生成器  {G_i} の出力画像に対する事後確率は0で、他のcouncilが生成した画像に対しては1に近い値を出すように学習する。すなわち、自分のcounsilが生成した画像をfake、他のconsilが生成した画像をrealと判定したい。(なんか直感と反するけど)。
一方で生成器 G_i側は\hat{D_i}を騙したい。すなわち、自分の生成した画像は同じcouncilから生成したものと見なされたいし、他のcounsilには違うと見なされたいので、他の( jと置く) counsil の生成器  G_jが持たないような特徴を生成するように学習する。
これが Counsil loss の役割のようだ。

Council loss のよい点

p.1,col.2,l.20〜にそれっぽいことが書いてある。

  • 各 council ごとの \hat{D_i}の集合的な意見を活用することで、 G_iがより安定し多様に富んだドメイン変換ができる
    • 生成される画像は、counsil 間で共通の特徴があるべき
    • \hat{D_i}によって、 G_iは他の counsil が見分けられるような特徴を生成するように収束する。これはソースとターゲットドメイン間の相互情報量の最大化をしている。
      • これにより、生成された画像がソース側の重要な特徴を維持する

事実なのか意見なのかはわからないが、このような狙いがあるらしい。

どういうことか考えてみた。例えば、council が 3 つあるとして、 \hat{D_1}を騙すために、 G_2 G_3は共通の特徴を持ちうるということ。 \hat{D_1}は髪の毛の部分を見て自分の counsil かどうかを判定しているとすれば、G_2 G_3は髪の毛の部分は似たような画像変換を獲得する、でも \hat{D_2}も騙したいのでG_2 G_3は髪の毛以外の所で差別化を図らざるを得なくなり、最終的にそれぞれの counsil は共通の特徴を持ちつつもそれぞれ異なる画像変換を獲得する的なイメージだろうか。

また、 \hat{D_i}には、ソースドメインの画像も直接入力している。この理由はソースドメインの特徴も学んでほしいと願っている(wish)からとのこと(p.4 Fig.4の説明より)。

生成器G_iの補足

生成器側は、Encoder-Decoderアーキテクチャだが、デコードフェーズ時に、ノイズ z_iを混ぜている。このことで、多様な画像を生成している(Fig.3)。

f:id:meow_memow:20200709083956j:plain:h250

先行手法Cycle Consistency Loss の欠点

これまでの、unpaired な image to image translation を GAN ベースで実現する研究は Cycle GAN で提案された Cycle Consistency Loss が使われていた。一方、Council GAN は以上のような仕組みで Cycle Consistency Loss を使わずに im2im できるようになった。論文タイトルの「Breaking the cycle」の由来である。

じゃあ何でCycle Consistency Loss がよくないとしているのか理由も調べた。

主に論文 p.2,col.2,l.26〜らへん

  • Cycle Consistency Loss は、不要な制約をかけうる。
    • cycle して元に戻そうとする余り、ターゲットの画像にソースドメイン側の特徴を残してしまう(p.1,col2,l.12)
    • 変化の量を制限してしまう(p.3,col.1,l.11)
  • 隠れた情報が残ってしまうことを回避できる
    • ある研究3によると、Cycle GANはターゲットドメインへの変換時にソースドメインの成分を高周波成分に埋め込んでいるので、Adversal Attackの脆弱性があるとのこと。これにより入力画像に細工をすることで任意の変換ができてしまうとのこと。
  • (Cycle GAN に関わらず、既存の画像変換手法は変換結果に多様性がない)

[脱線]そもそもCycle Consistency Loss はunpairedなim2imとどう関係があるのか

個人的な興味から論文の本筋とちょっと脱線する。そもそも、どういう理屈があってCycle Consistency Lossでunpairedなim2imが実現できるのか気になったのでCycle GAN元論文を読んで調べてみた。

p.4,"3.2. Cycle Consistency Loss"の節

Adversarial training can, in theory, learn mappings G and F that produce outputs identically distributed as target domains Y and X respectively (strictly speaking, this requires G and F to be stochastic functions) [15]. However, with large enough capacity, a network can map the same set of input images to any random permutation of images in the target domain, where any of the learned mappings can induce an output distribution that matches the target distribution. Thus, adversarial losses alone cannot guarantee that the learned function can map an individual input xi to a desired output yi . To further reduce the space of possible mapping functions, we argue that the learned mapping functions should be cycle-consistent:

読んでも私には理解できる力がなかった。特にrandom permutationのあたり。
とりあえず部分的に理解すると、「Adversarial trainingは、理論上はXとYのドメイン間の写像を学習できるが、ネットワークに変換能力が十分にある場合、adversarial lossesだけでは、変換候補先がたくさんありすぎてXからYへ移す保証ができない。そこで、写像が移しうる候補を制限するために、Cycle Consistency Lossを入れるべきだと我々は考えた」的な感じか。
大事なのは、Unpaired im2imに必ずしもCycle Consistency Loss がある必要はないということ。写像がちゃんと獲得できるならば lossは何でもいい。Council Lossはそれを実証している。

実験で手法の比較

councilの数は4。4つのcouncilの生成器から出力された結果の一例が示されている。

f:id:meow_memow:20200709084558j:plain

これに対する著者の定性的な評価(p.7,col.1,l.20〜)としては、

  • 表情や顔の構造(つまり、顎の形状)が入力画像によく似ている。これは、councilのメンバーが入力画像中の特徴の方が"同意"しやすいためだと考えられる
    • ※ "同意"の意味がわからなかったが、GAN 学習時、生成器はソースドメイン側の特徴を持っていれば識別器を騙しやすいということだろうか。そうだとすると当たり前のことを言っている気がする。
  • selfie2anime は難しいタスクである。ドメイン間のスタイルが異なるだけでなく、入力と出力で幾何学的構造も大きく異なる。例えば目のサイズ。このせいで、構造の不一致や歪み、アーティファクトを発生させることにつながる。

なお、プロジェクトページには、selfie2animeテストデータ全100件に対する各im2im手法の生成結果を載せた補足資料が公開されている。GAN論文はいい変換例だけ載せる疑惑があるので、こういうのは助かる。ただ、この資料を見るに、論文に載せている例は変換がうまくいったものを図に採用している感は否めない。

また、定量評価(FID, KID)では先行手法よりも良い結果だったとのこと。

f:id:meow_memow:20200709084736j:plain

何番目のcouncilを使ったのかは不明。 見た目的にU-GAT-ITと差がない印象であるが、定量的には差が出ている模様。

Council GAN を手元で試してみる

公式PyTorch実装がgithubで公開されているので試す。
https://github.com/Onr/Council-GAN

実行環境のセットアップ

Anacondaでの実行を想定しているらしくconda_requirements.ymlが用意されている。requirements.txtは用意されていない。なので私は何回かコードを実行して不足しているパッケージを都度入れた。

ちなみに、Dockerfileも用意されている。公式の現在(2020/07/04)のバージョンのDockerfileはビルドが通らないので、有志がプルリクしているDockerfileを使えばビルドできる

データのダウンロード

  • selfie2animeデータセットのダウンロード
    • $ bash ./scripts/download.sh U_GAT_IT_selfie2anime
      • 先行研究の UGATITで使用されていたものを落としてきている。
      • 画像の拡張子はjpgだが、実態のフォーマットはpngである。処理に問題はない。
    • datasets/selfie2animeに落とされる。
    • データサイズはソース、ターゲットドメインそれぞれ、
      • train: 3,400 枚
      • test: 100 枚
    • あと、データは全員女性4なので、このデータで学習したモデルが男性の画像で正常に変換できる保証はない。
  • 学習済みモデルのダウンロード
    • $ bash ./scripts/download.sh pretrain_selfie_to_anime
    • ./pretrain/anime/に4つのgeneratorが落とされる。

実行(コマンドライン)

  • モデル学習
    • $ python train.py --config configs/anime2face_council_folder.yaml --output_path ./outputs/council_anime2face_256_256 --resume
      • 使用GPUメモリはデフォルトで4000MBくらい
      • チェックポイントは10000stepごとに取られる。
      • チェックポイントがある状態でコマンドを実行すると、最後のチェックポイントから学習が再開する
        • ちなみに、前述の学習済みモデルには、識別器とoptimizerのチェックポイントがないので、学習済みモデルで学習を再開することはできない。
    • モデルのファイル名のフォーマットは<ドメインの方向>_<モデルの役割>_<counsilの番号>_<学習で回したステップ数>.pt
      • 例えばb2a_gen_0_01000000.ptは、ドメインBからA、Generator、0番目のcousil、1,000,000step学習したモデルということ
  • 学習済みモデルで評価
    • $ python test_on_folder.py --config pretrain/anime/256/anime2face_council_folder.yaml --output_folder outputs/council_anime2face_256_256 --checkpoint pretrain/anime/256/01000000 --input_folder ./datasets/selfie2anime/testB --a2b 0
    • outputs/test_resに画像ディレクトリができる
      • デフォルトだと10つできる。
        • 4つのcouncilのうちランダムにgeneratorを選んだ後、decodeフェーズでノイズを混ぜて画像生成している。それを10回繰り返している
        • ノイズはランダムに毎回生成しているため、画像は毎回実行結果が異なる。
    • 自分の用意した顔写真で試したい場合は、datasets/selfie2anime/testBに顔写真を入れればよい。

実行(GUI)

PyQtベースのGUIも用意されていたが、私の環境では動かなかった。 こんなエラーが出る。

$ python test_gui.py --config pretrain/anime/256/anime2face_council_folder.yaml --checkpoint pretrain/anime/256/b2a_gen_3_01000000.pt --a2b 0

test_gui.py:56: UserWarning: Filed to import face_recognition, setting use_face_locations to FALSE
warnings.warn("Filed to import face_recognition, setting use_face_locations to FALSE")
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl, xcb.

zsh: abort (core dumped) python test_gui.py --config pretrain/anime/256/anime2face_council_folder.yaml

lennaさん画像で変換を試して比較してみる

f:id:meow_memow:20200709085014j:plain

f:id:meow_memow:20200709085028j:plain

左上が元画像(ちょっとクロップしている)、上真中が私がlennaさん用にガッチガチにチューニング5したCycleGANの結果。 右上がU-GAT-IT6。形状のデフォルメはされていない。attentionをいれているので形状に注目するはずなのだが。
下がCouncil GAN 10パターン。良いものが出るまで生成ガチャを回した。かなりアニメっぽい。とくに1行5列目のlennaさんはアニメっぽくて気に入っている。

所感

いい画像が生成できるかは確率次第だったので、平均的な性能はU-GAT-ITとあまり変わらないと思う。
タイトルで"all you need" と言っているが、selfie2animeタスクに関しては必要な要素はまだまだありそう。


  1. CVPR2020の開催時期に合わせたものと思われる。

  2. LSGAN の識別器,生成器の学習のコードはこんな感じで実装する。

  3. CycleGAN, a Master of Steganography, https://arxiv.org/abs/1712.02950

  4. このご時世、見た目だけで"女性"というのはポリコレ事案な気がするが、どう言えばいいのかわからないので、とりあえず女性と言っておく。

  5. 詳しくはこちらのスライドで説明: CycleGANで顔写真をアニメ調に変換する

  6. U-GAT-ITの私の解説もよろしければご参照いただければと思います。: 【論文紹介】U-GAT-IT

"Full Stack Deep Learning - Setting up Machine Learning Projects"のメモ

f:id:meow_memow:20200621121307p:plain

What Does it Mean to Deploy a Machine Learning Model? (Deployment Series: Guide 01) - ML in Productionを読んでいたら途中で引用されていたスライド。興味があったので読んでみた。

スライドでは、機械学習プロジェクトのうち、プロジェクトの外観と、プロジェクト計画(目標設定、達成基準の決め方、ベンチマークの決め方)の説明をしている。

英語苦手なのでどのページにどういうこと書いてあったかインデックスがわりにメモっとく。理解できないところは先頭に?マークつけとく

講義の目的(p.2)

  1. MLプロジェクトを理解するためのフレームワークを紹介する
  2. ML prj.の企画と立ち上げのためのベストプラクティスを説明する

この講義で考えるケーススタディ(p.3)

  • grasp model(ロボットアームがものを掴むために)pose estimationをする
  • センサ情報からあるものがどこにあって、どの方角を向いているかを推定する

MLプロジェクトのフレームワーク(p.6)

ML prjのライフサイクル

f:id:meow_memow:20200621121601p:plain

  • ①企画と立ち上げ
    • 内容:
      • pose estimationすることを決める
      • そのための要件と目標を決める
      • リソースを割り当てる
  • ②データ収集とラベリング
    • 内容
      • 学習データを集める
      • センサ(カメラなど)のセットアップ
      • 画像をキャプチャ
      • ラベリングする
    • ②をやってみて①へ戻ることも(p.10~11)
      • 要因
        • データ取得が難しい
        • ラベル付けが難しい
  • ③ 学習とデバッグ(p.12)
    • 内容
      • OpenCVをベースラインにする
      • 既存研究のSoTAモデルの再現
      • 自分の実装したモデルのデバッグ
      • タスクのための改善活動(モデルとかデータ集めとか)
    • ③をやってみて②へ戻ることも(p.14~15)
      • 要因
        • データをさらに集める必要があった。
        • Realize data labeling is unreliable(データが信用できないことに気づく)。
    • ③をやってみて①へ戻ることも(p.16~17)
      • 要因
        • タスクが難しいと気づく。
        • 要件同士のトレードオフがあった。(一番重要な手戻りの要因)
  • ④デプロイとテスト(p.18)
    • 内容
      • 開発(実験)環境でパイロット版を立ち上げてみて、システムがどう動くか把握する
      • 回帰テストを書く
      • 本番環境へデプロイ
    • ④から③へ戻ることも(p.19)
      • 要因: 開発環境の段階で(期待した通りに)動かないので、精度改善を継続
    • ④から②へ戻ることも(p.20)
      • 要因
        • 実験時のデータと、本番データに差異があった。
      • データをもっとあつめる。
      • Mine hard cases(多分、推論が難しいデータを探す こと。)
    • ④から①へ戻ることも(p.21)
      • 要因
        • 設定したメトリクスは実際のユーザの行動に適ったものではなかった(The metric you picked doesn’t actually drive downstream user behavior. )ため、考え直す。
        • 本番環境でのモデルの性能が良くないので、要求を見直す。(例えば、より速さが必要だったり、より精度が必要だったり)

※↑は、個々のプロジェクトにおける進め方。プロジェクト横断するとなると、企画にはチーム編成や採用活動、それ以降ではインフラ構築やツールの開発を考える必要がある。(p.22~24)

  • 他に知っておく必要のあること(p.25)

    • 自分の取り組んでいるドメインにおけるSoTA技術を知ること: 何ができるのかを理解し、次に何を試すべきかを知る
  • ①~④実際にはもっと詳細なステップがある(p.27)

    • ①企画と立ち上げ
      1. プロジェクトのゴールを設定
      2. メトリクスの選択
      3. ベースラインはどれだけかを調べる
      4. set up codebase(リポジトリを作ること?)
    • ②データ収集とラベリング
      1. データの収集戦略を考える
      2. データを集める
      3. ラベル付け
    • ③学習とデバッグ
      1. 一番シンプルなモデルを選んで
      2. それを実装する→モデルをデバッグ
      3. train/val/testを実行
      4. 改善活動案の列挙と優先順位付け
    • ④デプロイとテスト
      1. ステージング?本番環境の準備(pilot)
      2. 受け入れテスト
      3. 本番環境へモデルのデプロイ
      4. 監視
  • 今回の講義では①に関して扱っていく。

    1. プロジェクトの優先順位決め、目標の選定
    2. メトリクスの選定
    3. ベースラインの選定

1. プロジェクトの優先順位決め、目標の選定

優先順位決めに大事なポイント(p.31)

f:id:meow_memow:20200621122014p:plain

  • A インパクトの大きいMLの問題
    • 低コストで予測できることが価値のある
    • 複雑なパイプライン
  • B 実現可能性(Feasibility)
    • ML pro.にかかるコストは、データがどれだけ使えるかによる。しかし、精度の要求も大きな要素である。

A. インパクトの大きいMLの問題

インパクトが大きくて、実現可能性があるところが、取り組む優先順位が高い場所である。(p.32)

影響の大きいMLプロジェクトのためのメンタルモデル(p.33,34 )

  1. predictionを安価にすることがメリットがある場所はどこか
  2. 手作業でやっている複雑な作業のパイプラインのうち、どこが自動化できるか

  3. The economics of AI

    • AIは予測のコストを下げる
    • 予測は意思決定の中心的存在
    • 低コストで予測できることが意味するのは
      • どんな問題にでも予測が使える
      • それまでコストが高かった問題でさえも。(例えば、hiring a driver (?ドライバーを雇う?))
    • すなわち:予測コストを安価にできるとビジネスのインパクトがでかい場所を探そう
  4. Karpathyのツイート(p.35)
    • 「悪いね、勾配降下法は君よりいいコードを書くんだ。」
      • 訳注: 複雑なルールベースの推論ロジックを人がコーディングするよりも、MLモデルで推論をさせた方が結果がいい、みたいな意味だと思う。
  5. ソフトウェア2.0(p. 36)
    • ソフトウェア1.0は従来の、明示的にロジックをコーディングをしたプログラムのこと。
    • ソフトウェア2.0は人間がある目標を定め、(学習)アルゴリズムがその目標を満たすプログラムを探す
    • ソフトウェア2.0におけるプログラマは、データセットを用い、optimizerでコンパイルする(実行プログラムを作る)
    • Why? Works better, more general, computational advantages(? なぜ2.0がいいか。それは、より良く動作し、より一般的で、計算的なアドバンテージがあるから)

まとめ: 複雑なルールベースのソフトウェアを探し、それをMLに置き換えよう。

B. 実現可能性(Feasibility)

機械学習プロジェクトの実現可能性をコストの面で見積もる(p.38〜44)

f:id:meow_memow:20200621121351p:plain

  • プロジェクトにかかるコスト要因は3層。
    • 下がData availability
    • 真ん中がAccuracy requirement:
      • 間違った推論をするとどれだけコストがかかるか。
      • (? 何回くらいシステムを正せば使い物になるか)
    • 上がproblem difficulty
      • すでに類似の問題を解く良い方法が世に出回っているか(問題は新しいほど、リスクが高く、技術開発面で骨が折れる)
      • (? 学習は必要?)
      • (? デプロイできる?)

Accuracy requirement(p.44~p.46)

  • 要求する精度を高くするほどプロジェクトのコストが高くなる。増え方は線形では済まない(super linear)
  • Product design can reduce need for accuracy(p.47)
    • (正直、画像だけで何も書かれていないが、多分言いたいのは次のようなこと)
      • AIによる作業の完全な自動化(それ故の高い精度)を目指すのではなく、人に任せる部分も設けることで、精度の要件をへらすようにサービスをデザインする。
      • MLに何をどこまでさせるか(逆にどこからは人が)を設計すれば精度要件の負担を減らせるかを考えよう。
    • Designing Collaborative AI - Ben Reinhardt - Medium -https://medium.com/@Ben_Reinhardt/designing-collaborative-ai-5c1e8dbc8810
  • 実現可能性を見積もるにあたってのヒューリスティクス(p.48)
    • Andrew Ng「普通の人が1秒未満でできることのほとんどは今のAIで自動化できる」
      • 1秒でできる例:
        • 画像の認識
        • 音声の認識(理解)
        • 音声翻訳
        • 物体認識
      • できない例 -ユーモア、皮肉の理解
        • 手を使う作業をロボットにさせること
        • Generalize to new scenarios(Scenario Generalizationというタスクがあるらしい)

自分のpose estimationプロジェクトの見積もりをやってみる(p.49)

  • Impact
    • 目的はロボットがものをつかめるようになること
    • 従来のロボティクスパイプラインでは、ヒューリスティックとオンライン最適化を用いられていた。それ故、動作が遅く、変化にもろい。それ故、ソフトウェア2.0にすることでインパクトがある!
  • Feasibility
    • Data availability
      • データは集めやすい
      • アノテーションはchallengeな課題だけど、実験部屋にセンサーを取り付けることはできる
    • Accuracy requirement
      • ものをつかむには高いaccuracyが必要。誤差0.5cm以内。
      • だけど、失敗は低コスト。単位時間あたりのつかむ回数が大事。掴むのに成功した回数はそれほど重要ではない。
  • Problem difficulty
    • 既存研究が自分のところに流用できない

2. メトリクスの選定(p. 51)

f:id:meow_memow:20200621122343p:plain

メトリクスの選び方、組み合わせ方

  • メトリクスの選定に重要なこと
    1. 実世界は乱雑(messy)。つねに多くのメトリクスを気を払っておくこと。
    2. とはいっても、MLシステムは一つのメトリクスを最適化する時はbest
    3. 結果として、数あるメトリクスを組み合わせて一つのメトリクス(formula)をつくればいい
    4. この式は変えることができるし、変わるだろう。
  • どうメトリクスを組み合わせるか
    • 相加平均、重みつき平均、など。
    • Thresholding metrics
      • nつのメトリクスがある時に、n-1つのメトリクスはしきい値を設けて足切り用に使い、残りの1つのメトリクスの良し悪しでモデルを評価する(p.66も参照されたし)
  • Thresholding metricsで考えるべきこと(p.64)(ここ、意味がわからなくて訳が思い浮かばなかった。)
    • どのメトリクスを足切りに使うか
      • Domain judgment (e.g., which metrics can you engineer around?) (? ドメインに応じて決める、的な意味か? 工夫できるメトリクスってどういうこと?)
      • Which metrics are least sensitive to model choice? (? モデル選定にあまり影響を及ぼさない的な意味か?)
      • Which metrics are closest to desirable values? (? モデルの要件に望ましい値に最も近いものを選ぶということか? 見逃しが少ない方がいいからrecallで足切りする、的な。)
    • しきい値はどのあたりに定めるか
      • Domain judgment (e.g., what is an acceptable tolerance downstream? What performance is achievable?) (? これもドメインで決める的な意味か。モデルを後の処理で(downstream)使う時の許容範囲で決める、的な。)
      • ベースラインがそのメトリクスでどれだけの値を出すか
      • メトリクスがその時、どれくらい重要かに応じて
  • Thresholding metricsの例(p.66)
    • recallのしきい値を0.6より大きいとする。
    • そのうえで、Precisionを代表的なメトリクスとすると、model1はrecallが届いておらず足切りされる。
  • より複雑、ドメイン固有なメトリクスを作る。(p.69~74)
    • より複雑、ドメイン固有なメトリクスを作る。例えばmAP(なぜ、mAPがドメイン固有なのかは書いていなかった)

メトリクス選定の例として自分のpose estimationタスクにあてはめてみる(p.75~p.81)

  • 要件
    • 最終的にはロボットが現実世界でものをつかめるようになりたい。
    • 位置の誤差は 一旦<1cmとする。このしきい値が本当に適切かはわからない。
    • 角度の誤差は5°以内。
    • 現実世界で100ms以内で動く
  • 実験:
    • いくつかモデルを学習
  • 今のパフォーマンスを要件と比べる
    • 位置エラーは0.75cm~1.25cmある(ハイパーパラメータによる)。
    • 角度誤差は60°くらいある。
    • 推論時間は最大300ms
      • → 角度誤差の対策が優先。位置エラーのしきい値は1cm。実行時間の遅さはここでは無視する。
  • 数値が改善したら、メトリクスを見直す(予定)

3. ベースラインの選定(p.82)

f:id:meow_memow:20200621122400p:plain

  • Key points for choosing baselines(p.83)
    1. ベースラインを決めることで、MLモデルに期待する性能の下限を決める事ができる
    2. 下限が厳しいほど。ベースラインとして有用
      1. 既存の研究結果
      2. 念入りにチューニングされたパイプライン
      3. human baselineなど)
  • なぜベースラインは重要か(p.85)
    • 定めるベースラインが異なれば。自分のモデルの性能とベースラインの差も異なり、その差に応じて次に打つ試作も異なるから。
  • ベースラインをどこで見つけるか(p.86)
    • External ベースライン:
      • ビジネス
      • エンジニアリングの要件
      • 既存の研究結果← フェアに比較していることを確認して!
    • Internal ベースライン:
      • スクリプトベースの方法(OpenCVとか、ルールベースとか)
      • シンプルなMLモデル(標準的な特徴量のモデル bag-of-wordsとか。)
      • 人手で特徴設計された線形分類器(基本的なDNNモデル(batch normarizationのないVGGとか))
  • human baselineをどう作るか(p.92)
    • human baselineのリスト。下に行くほどベースラインの質は高く、また、そのためのデータ入手が困難
      • 無作為に選んだ(一般の)人(例 Amazon Turk)
      • 複数人の無作為に選んだ人
      • ドメインにおけるエキスパート(例 医者)
      • より深くドメインに特化したエキスパート(例 specialists)
      • 複数人のエキスパート
    • How to create good human baselines(p.93)
      • Highest quality that allows more data to be labeled easily(? 最上級品質のベースラインはより多くのデータのアノテーションを楽にしてくれる)
      • ドメインが特化するほど、アノテーターにスキルが必要
      • モデルの性能が低下するケースを見つけ、(そのケースを解決するような)データ収集に絞る

"More on labeling in data lecture" (? より詳しくはデータ回の講義で述べる)

MLCT#12 聴講メモ(特に質疑パート)

Machine Learning Casual Talks(MLCT)は、機械学習技術をプロダクションで動かす際のプラクティスや苦労話を議論する場です。 今回はオンライン開催だったため、動画のアーカイブが残っています↓。


発表もそうなのですが、発表者へ寄せられる質問も実務課題に沿ったものが多く、自分が業務を進めていく上でもリファレンスにできそうなため、質疑のメモを重点的に残しました。

発表 ①: "Cost-efficient and scalable ML-experiments in AWS with spot-instances, Kubernetes and Horovod"の紹介と感想

発表者: 服部 圭悟((元)ABEJA)
スライド URL: https://speakerdeck.com/keigohtr/cost-efficient-and-scalable-ml-experiments-in-aws-with-spot-instances-kubernetes-and-horovod-falseshao-jie-togan-xiang

要旨

(クラウドの)ML プラットフォームを実現するにあたってソフトウェア(サービス)を組み合わせるという課題に対して、"Cost-efficient and scalable ML-experiments in AWS with spot-instances, Kubernetes and Horovod"という記事で紹介されたアーキテクチャコスパもスケーラビリティもよかったので紹介するという趣旨。記事によると、データの読み書きは EFS/EBS、ML バッチマネジャーには k8s、コンテナは AWS のスポットインスタンスを使う。(データ並列な)分散学習をする際には深層分散学習フレームワーク Horovod の API をつかって、単一ノードマルチ GPUインスタンスで学習をするという構成を提案している。

質疑

  1. Q: ML プラットフォームサービスはビジネス的に利益が出るのか。 インフラコストが高くて利益があまり期待できない印象がある。
    • A: クラウドのコストで割高になるが、ML プラットフォームを自力で組もうとすると大変なこと(エージェントの管理、クオーターの管理など)がたくさんあるのでサービスとして価値がある
  2. Q: ML に k8s を使うメリットは何か
    • A: ML エンジニアでも簡単に使えるところ。インフラ知識なくても 自分で計算クラスタを用意できる。また、MLOps 関係の文脈で k8s ベースのツール(kubeflow, horobod)がさかんに開発されており k8s 使った MLOps のエコシステムが整いつつある。その結果 k8s の上で TF、PyTorch の分散学習がしやすくなっている。
  3. Q: 服部さん(or ABEJA)では学習フェーズの厳密な再現も重要視されているか?
    • A: 学習の再現のプライオリティは比較的重要度が低い。世の中的にも重視している事例はそんなに出ていない。PoC や案件を回す方を優先している。ABEJA の顧客では、気にしている人はそこまで多くない。一方で学習の再現性が必要になる分野は人命がかかわるところ(医療、自動運転など)や金融
  4. Q:kubernetes を使った機械学習基盤のアーキテクチャで参考になる文献などありますか。
  5. Q: ABEJA では、生の k8s を使って training 環境を作っているのでしょうか。それとも kubeflow などを使っているのでしょうか。
    • A: 生の k8s の上でホストするサービスを作っている。kubeflow は試したがサービス用途で使っていくには辛いと感じた。

発表 ②: データマネジメントなき ML は、破綻する。〜こんなデータじゃ機械学習できねぇよ問題の処方箋〜

発表者: yuzutas0
スライド URL: https://speakerdeck.com/yuzutas0/20200528
参考: 『データマネジメントが 30 分でわかる本』 (amazon)
yuzutas0 さんが、DMBOK を噛み砕いて平易に解説した電子書籍。500 円という破格なので、ぜひチェックいただきたい。今回の発表もこの書籍の話を ML プロジェクトを例として説明されたものである。

要旨

機械学習ではデータの質が良いことが重要であるが、実際の業務で提供されるデータは(ML で使えるほど)品質がよくない。その理由は業務全体におけるデータマネジメントがなされていないためである。本発表では、書籍 DMBOK の 12 領域を(ML の)業務に照らし合わせて、どのようなデータをどう管理・活用すべきか考察する。
ちなみに時間の都合上発表はされなかったが、スライドの appendix に、ML 関係の業務コンサルをした時の話がある。その中には、ML 側がアプリ側にいくらデータ要件の改善を起票してもアプリ側にチケットの優先順位を下げられていつまでたってもデータの品質改善がされない場合の裏技が載っていたりする。

質疑

  1. Q: データマネジメントの 11 領域どれもとても大切に感じるのですが、どれもこれもできていない場合は、まずどの領域を優先してとりかかるのが良いでしょうか?(すでにある程度データが集まっていて使っている状態の場合)
    • A: 教科書的解答は 1(アーキテクチャ)と 11(ガバナンス)。理由は全体像がわかれば関係者とデータアーキテクチャレベルで会話できるし、ガバナンスルールを作れば、担当者や役割分担され責任者が決まるため。ただし、ML エンジニア的にはデータを作る側の話は見えにくいかもしれないので 8 データの品質管理をおすすめする。すなわち、自分が何が困っていて、なぜ困っているのかか言語化することで、他部門 ML チームがどういうデータ(品質、及びそのギャップ)をほしいのかを伝える際の指針となる。
  2. Q: 現場で「業務整理 → データ整理 →ML→ ビジネス価値」の優先順位について共通認識を得るためにどのような伝え方をしていますか?
    • A: 相手の経験・理解度によるので一概にいえない。素直にデータの品質が悪かったら ML タスクは取り組めないことを言った方が話が進むと思う。
    • A(司会上田さん) 関係者に「(ビジネスの成功/失敗の)再現性得たい場合は、データ整理に投資しないといけないよ、ビジネスの良し悪しのメトリクスを決めるには、まともなデータがないと評価できないよ」、と伝える。
  3. Q: 業務でトランザクションテーブル作るべきか
    • A: 打診してみてもいい。履歴がないとトラブル・法令違反につながることがある。例: EC サイトで商品をカートを入れた後に商品の値段が変わったという苦情がおきたりした時の、証拠として持っておく必要がある。
  4. Q: 成功した ML プロジェクトは 11 領域はどの程度実現できているのか
    • A: 成功という意味では、短期的には勢いでやっても金額でいうと成功する。ただし、その後のいろんな変動要因(担当者の変更)があったり、スケールしようとした瞬間に(11 領域のできていないところから)課題が噴出する。

発表 ③: 使われる機能目指して 測ったり試したり

発表者: 大嶋 悠司(メルカリ)
スライド URL: https://www.slideshare.net/Oshima0x3fd/mlct12
補足: Google Developers Japan: メルカリ : TensorFlow Lite で、気付きにくい便利機能をユーザーに提唱
今回の発表で紹介された取り組みの詳細が載っている。

要旨

メルカリではエッジ AI の適応先の 1 つとして、メルカリアプリ内のバーコード出品推薦機能(カメラで撮られた物体が本かどうか画像分類し、本だったらバーコード出品ができる旨のメッセージを出す)をリリースした。企画からリリースまでに行った取り組み(主にモデル量子化)と機能改善活動に関して述べる。

質疑

  1. Q: 実務でサーバーサイドも tflite で行こうという機運はありますか?
    • A: サーバサイドならば、TF serving で動かしたほうが TFLite よりも早い、なので使う予定はない。
  2. Q: ML を使うという施策はどのように決定されたのか。MLを使わずともUI/UXの改善でバーコード機能を使う人を増やせそうなものだが。
    • A: もちろん UI/UX のみで使う政策も並行で走らせていた。試験した結果、ML と UI/UX を組み合わせたほうが、バーコード出品の増加率がたかいので ML も組み込んだ。
  3. Q: full quantizationの大変な点を伺いたいです。
    • A: 活性化関数のマップをつくるところ。represent dataset(実データを表現するデータ)のサブセットを入れて、活性化関数の値を記録する作業がある。ちゃんとした represent dataset 作らないと精度でない。また、出品される画像のドメインが変化したときモデルのメンテコストが上がって大変になる。今回の機能は full quantization しなくても速度要件は満たしたのでその段階をスキップした。
  4. Q: uint8 に変換したモデルの場合、速度はどれくらい向上するか?
    • A: (自分の記憶でしかないが、)40%くらいは速くなる。
  5. Q: TFLiteはスマホの違いを吸収してくれるか
    • A: すべて吸収してくれるわけではない。iOS はバージョンのしきい値を決めている。android は CPU がばらついているので、CPU アーキテクチャの指定をして推薦機能をオンにするかきめている
  6. Q: TFLite のせいでアプリがおちるとかメモリリークするとかあるか
    • A: 今回の開発では、TFLite 起因のものはおきなかった。ただし、デモ開発の段階でカメラをストリーミング形式で認識しようとするとメモリリークをおこした。
  7. Q: エッジ側モデルを更新する際に気をつけるべきことはあるか
    • A: アプリにモデルを同梱して配布しているが、これは良くない。アプリインストールした後、CDN からモデルを配布したい。今後は、この端末はこのバージョンみたいにして、端末に合ったモデルの配布を考えている。
  8. Q: mixedprecision で学習試したか
    • A: やっていない。キャッチアップできてない。

所感

  • オンライン開催
    • 個人的に非常に助かった。参加抽選はないし、動画アーカイブは残るし、質疑のインタラクション手段(sli.do)も用意されており、いたれりつくせりだった。

改めて運営メンバー、発表者の方々、ありがとうございました。

【WIP】言語技術(対話、意見文、議論、論理的思考、批判的思考)に関する気付きメモ

言語技術(Language Arts)のトレーニングをして1年半が過ぎる。
レーニングには、三森ゆりか先生のご著書、『大学生・社会人のための言語技術トレーニング』の内容をベースに勉強している。

大学生・社会人のための言語技術トレーニング

大学生・社会人のための言語技術トレーニング

書籍では不明点もあったので、先生の主催する社会人向けの言語技術講座に全ての回を受講した。 それでも言語技術運用能力が身についたとは思えない。辛うじて、日常やインターネットで見聞きする議論が議論の体を成していないことがわかった程度。 言語技術を自在に操り、無意識でも情報をインプット→思考→アウトプットできるように、最低あと5年くらいは腰を据えて勉強していきたい。
このページでは、言語技術の勉強の過程で気づいたことをメモする。

  • 言語技術とは(私の見解)
    • 自分の意見を論理的に考えたり、相手の意見を論理的に正しく導けているかをジャッジする能力。
      • 私の印象では、前者を論理的思考、後者を批判的1思考と世間で呼ばれている気がする。
  • 言語技術教育
    • 言語技術を身につけさせるための教育
  • そもそもなぜ言語技術は必要か
    • 私の見解では、対話を通して他人(自分とは異なる価値観を持つ者)に自分の意見を伝わらせるため。
      • ここで「対話を通して」を強調しているのは、相手へ意見を伝わらせる手段は脅迫、金など他にもあるため。
      • また、ここで意見という言葉を強調しているのは、事実(誰でも正しいと思ってくれる情報)と区別しておきたいから。相手に事実を伝える(例えば、「今、12時です」「私の名前は山田太郎です」)ならば、相手はその情報を正しいものとして受け入れるだろう。しかし、議論の余地のある事象に対しては、相手は基本的に受け入れてくれない(例えば、「学校は私服で通学できるようにすべきだ」)。したがって、相手が納得するように、自分の意見の根拠を提示しながら、伝える必要がある。
    • 「意見を伝える必要があるのか」という議論ももちろん考えられる。私の所感では、他人との社会的なコミュニケーションが避けられないならば、自分の意見を伝える必要があると思っている。

言語技術教育で習うスキル

他人との議論・コミュニケーション

  • 質問応答

情報のインプット(聞く、読む、観察する)

  • 事実 or 意見 を分類する癖
    • 自分の意見を支えるために根拠を用意するが、その根拠には客観的に正しくないと説得力に欠ける。なので、根拠となる情報を集める際には、それが事実といえるか、他人の1意見なのかは分類しておく必要がある。
    • また
    • なお、三森先生曰く、事実も意見の一種という立場を取る人もいるので、先生の言語技術講座では、事実は10人中8,9人が正しいと認識している事象に対してのことを指すとしていた。
      • 例.「日本は細長い国である」は事実。

情報に対する思考

  • 空間配列(Spatial Order)
    • 事象を構成する要素を「全体→細部」という順番で整理すること。

その他

  • 日本と国外の言語技術教育の学習開始タイミングに関して
    • 日本では、大学の研究室配属後や社会人になってようやく研修などで論理的思考・批判的思考を習い始める気がする。
    • 一方で、それ以外の国では、母国語の授業で、小学1年生からカリキュラムとして扱っていると本に書いてある。
    • 日本語の言語技術を身につけるタイミングが遅いことに対して、三森先生が講座で「言語技術は算数のようなもの。日本ではいきなり、論理的思考を学ばせるが、これは算数も知らない学生に微分方程式を学ばせるようなもの」というようなことを仰っていた記憶がある。

  1. よく言われることだが、批判は、他人を言葉で人格攻撃する意味ではない。相手の意見の不足している点を指摘することで、相手の説を補強するという寧ろ建設的な役割を果たす。

【WIP】機械学習システム開発プロジェクトで直面する課題の列挙

機械学習を搭載したシステム(MLシステム)やプロダクトの開発は、保守・運用フェーズが(PoCや開発フェーズに比べて)辛いです。その辛さを軽減しよう、すなわち、保守・運用をしやすいようにMLシステム開発をしようとする試みは、MLOpsと呼ばれています。
現行(2019年)で、MLOpsにベストプラクティスは存在していません。そのため、MLシステム開発に携わるエンジニアは日々同業者と勉強会で、自分がMLシステムを開発するにあたって、どういう課題があって、どう解決しようとしてるかを議論し、ナレッジを貯めています。
私もご多分に漏れず、MLシステムの保守・運用に苦しんでいるうちの一人です。 ただ、今一度我が身を振り返ってみると、何が苦しいのかを言語化していませんでした。そこで、この記事では、課題を文字に起こすことで思考を整理したいと思います1

現時点での課題リスト

  1. ML部隊とOps部隊の役割分担がアンバランス
    • ML部隊がPoCをやって、いい精度が出るモデルができ次第、Ops側にモデルやコードを渡してスキルトランスファーが完了ということがあります。渡されたコードに説明はなく、readmeにモデル学習のさせ方だけが書いてあったりします。
    • そうなると、MLシステムのMLモデル周りでなにか不具合が見つかった時、コードのデバッグをするのは運用側になります。
      • 保守対象のMLのコードというのは、アカデミアのリポジトリを引っ張ってきていることが多いため、コード品質はお世辞にも良いとは言えないことが多いです2。そのため、保守が大変になりがちです。
      • すると、ML側よりも、そのコードを理解する必要がでてきます。そうなると、MLモデルの選定はML側なのに、面倒を見るのはOps側というアンバランスさが発生します。
  2. 「MLシステムの運用・保守は辛い」という認識がされていない。
    1. 良い精度 ≠ 良いシステム
      • 上のこととも関連しますが、モデルの精度を高めることで、保守性が悪化することもあります。手法をSotAなMLモデルに差し替えれば精度はあがるものの保守にコストが取られて旨味がないこともありえます。
      • 研究(PoC)のコードを、製品ver.に流用しようとするのはくれぐれもやめた方がいいと思います。
    2. 人事評価でOpsが不当に低い
      • ML側とOps側で、どう評価を換算するかが整備されていないことが根本的な要因だと思います。
  3. MLモデルの推論結果の(主に顧客への)説明責任が難しい。
    1. 信頼度(事後確率)が正解・不正解と相関がない
      • 信頼度が低くても推論結果があっていることもあれば、信頼度が99%でも推論結果が間違っていることがあります。
    2. 「説明可能なAI」自体がおかしな可視化結果を出す
      • DNNは基本的にブラックボックスですが、CAMやattentionなどの構造を取ると、推論の判断理由(どのような特徴を以て、答えを導いたか)を可視化することができます。
      • しかし、これも完全に使えるわけではなく、人間の直感に反するような結果がでることもあります。
      • そうすると、エンドユーザにそのような結果になった理由を聞かれた時に困ってしまいます。

まだまだ出てきそうなので、随時更新したいと思います。


  1. そしてあわよくば、実務でMLエンジニアをされている人達が集う勉強会の懇親会で、議題にあげることも考えています。

  2. そもそも、研究者は自分のコードが他人のプロダクションに載せられることを想定してはいないと思うので、それが普通だと思います。

【論文メモ】PoCキャンバスを用いた仮説検証プロセスの管理手法

機械学習(ML)モデルは確率的に振る舞う以上、MLシステム開発は不確実性が伴います。
そのため、MLシステム開発においては、不確実性を減らすためにソフトウェア開発に着手する前にPoCを行います。すなわち、不確実性に対して、こうなるだろうという仮説を予め立てた上で、それが合っているかを実験します。 この論文では、機械学習のPoCを行う上での道具(シート)を提案しています。

論文の基本情報

機械学習システム開発の不確実性

MLシステムと従来のソフトウェア開発の違う点は、PoCが求められること。それは、不確実性が伴うため。次のような不確実性が存在する。

MLシステムprjの不確実性、ソフトウェアの構造の不確実性

プロジェクト上での3つの不確実性 1. PoCの実現性に関する不確実性 - PoCですら事前に予測不可能なことが多い(工数やリソース)。そのため、Pre-PoCを行うこともある。 2. ソフトウェアにおけるモデルの不確実性 - 確率的な振る舞いをするモデルがどのようにユーザに価値を提供するかがわからない。同じ精度90%という値でも、迷惑メールの分類性能と自動運転の性能では精度の持つ価値が違う。 3. 運用における学習の不確実性 - 運用中に妥当な学習をし続けられるかわからない。

ソフトウェアの構造とその不確実性 1. モジュールがモデルの不確実性を扱うことが可能か - モデルの不安定な挙動を、モジュール内でリカバリすることができるか。 2. ソフトウェアがモデルの不確実性を吸収することが可能か - モデルの不安定な挙動に対し、サービスという観点でリカバリすることができるか。例えば、MLで天気を予測するサービスがあったとして、推論器が異常値を出した場合は、別の天気予報の情報を提供するモードに切り替える、ようなことを考えているかなど。 3. ユーザや環境からの情報をデータとして追加による不確実性を扱うことが可能か

機械学習システム開発における開発プロセスが満たすべき要件

前段で上げた不確実性がある中で、各粒度においてどういう要件を満たす必要があるか。

MLシステムprjの3つの不確実性に関する要件 1. PoCの実現性に関する不確実性 - 精度向上により顧客価値を提供できるか - PoCの成功/失敗条件の規定 - 非ML手法との比較 1. ソフトウェアにおけるモデルの不確実性 - ソフトウェアにおいて、どのような不確実性が許容できるのかを把握する - ユーザにどのような価値を届けるのかを見据え、その価値を提供するために欠けている情報を機械学習で補えるという仮説を立て、その仮説をPoCとして検証する 1. 運用における学習の不確実性 - 新しく学習したモデルが、そのソフトウェアにとって最低限の水準を満たしていることを保証する仕組み - 製品自身に新しい学習モデルを評価する仕組み - ユーザ自身に判断を仰ぐといった設計が適している場合もある

ソフトウェアの構造とその不確実性に関する要件 1. モジュールがモデルの不確実性を扱うことが可能 - 自動テストが有効であること。モデルが想定外の結果を導き出した場合でも、モジュールとしては、想定された挙動を保証することができる。 1. ソフトウェアがモデルの不確実性を吸収することが可能 1. モジュールレベルで不確実性が考慮されていれば、そのモジュールの振る舞いをソフトウェアレベルでどうすればよいか決めればよい。 2. ユーザや環境からの情報をデータとして追加による不確実性を扱うことが可能 1. PoCフェーズであればエンジニアがデータ処理をすることができるが、運用に入って取得したデータにおいては、恣意的に欠損値を埋めたりすることができないため、そのようなデータの加工についても十分に検証する必要がある。

仮説指向ソフトウェア開発プロセス(HOP)

筆者は、ソフトウェア開発プロセスとして、仮説指向ソフトウェア開発プロセスを提唱している。HOPは3つのフェーズから成る。

f:id:meow_memow:20190929224014p:plain

  1. PoCフェーズ。
    1. 2種類のPoCを反復的に実施。
      1. モデル仮説の検証PoC: データがあった時、期待するMLモデルを構築することができるという仮説を検証する。いわゆる機械学習のPoC。
      2. 価値仮説の検証PoC: MLモデルがユーザに価値を提供でき、ユーザもその価値を認めてくれるという仮説を検証
    2. 手順(上図)としては、価値仮説の上にモデル仮説が複数載っている状態)
      1. 価値仮説を策定
      2. 価値仮説の前提となるモデル仮説を策定
      3. 価値仮説を検証
      4. モデル仮説を検証
      5. 手順4の結果をもとに振り返り。4つの選択肢。
        1. 新しいモデル仮説を策定し、手順4へ
        2. 新しい価値仮説を策定し、手順2へ
        3. PoCフェーズの終了
        4. プロジェクトの終了
  2. プロダクトフェーズ
    1. モデル構築とプロダクト開発をスクラムで進める
    2. 以下のことに考慮
      1. ユーザにとって価値のないモデル構築のための要件も、ユーザストーリーとして扱う
      2. 運用フェーズのための、モデルの妥当性の検証手法を確立する
      3. MLモデルの性質に応じた自動テストを記述する
      4. "done"の定義に、モデルの異常系のテストケースを追加する
  3. 運用フェーズ
    1. プロダクトを横断できるような画一的な手順はない
    2. 考慮すべき点を列挙すると、
      1. 運用で取得したデータで学習するかを決める
        1. 学習する場合は、その妥当性をどう検証するか確定し、妥当でない場合のアクションも決めておく
      2. 運用中のソフトウェアのアップデートの介入方法について決めておく。

PoCキャンバス

f:id:meow_memow:20190929224050p:plain

HOPにおける最初のPoCフェーズの要素を整理する手法(上図)を提案。

10つの領域がある。この数字の順に埋めていくのが簡単とのこと。モデル仮説として、Difficulty(PoCにおいて何が難しいか)をもとに、Performance(MLのスコープ)を決めて、MLに必要なDataとAlgorithmを決める。その一方で、価値仮説として、想定するCustomerと、その人がかかえているProblemを明確にして、達成したときのValueは何かを考える。モデル仮説と価値仮説がきめられたならば、その2つをつなぐ、Accountability、Maintainability、Costを整理し、prjとして成立しうるかを検証する。

  1. Difficulty
    • 顧客価値の実現を機械学習によって達成しようとする上で困難になる要因。
  2. Performance
    • MLモデルが満たすべき予測精度、計算時間。ここに載せた値が実現できない場合は、3.Data,4.Algorithm、1.Difficultyの変更が検討される。達成が前提なのでSLAとみなせばよさそう。また、MLモデルが満たさなくてよい要件なども補記する。
  3. Data
    • MLモデルの構築、評価データの取得経路、データクレンジング、特徴量選択手法
  4. Algorithm
  5. Customer
    • 価値を提供する想定対象。
  6. Problem
    • 5のCustomerが抱えているであろう課題。
  7. Value
    • 価値仮設の概要
  8. Accountability
    • MLモデルの説明可能性
  9. Maintainability
    • MLモデルの保守性
  10. Cost
    • 価値仮設として、prjの期間、費用

すべてを最初に埋めることはできないかもしれないが、その場合は将来的に仮説がこける可能性があることを認識しておく。

なお、提案されたことに対する評価実験は論文にない。

所感

PoCの段階で9.Maintainabilityが考えられていることはいいことだと思いました。保守性を考えずにPoCを行うと、製品化した際に保守性が壊滅的になっていると考えるからです。
PoCフェーズが説明の中心でしたが、プロダクトフェーズ、運用フェーズを進める上での仮説検証指針のようなものがこれからでたらいいな、と思いました。