meowの覚え書き

write to think, create to understand

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

MLOps

機械学習(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フェーズが説明の中心でしたが、プロダクトフェーズ、運用フェーズを進める上での仮説検証指針のようなものがこれからでたらいいな、と思いました。