Upgrade to Pro — share decks privately, control downloads, hide ads and more …

CLISP-ML(Q)をはじめとしたMLシステムの品質確保に関する調査

 CLISP-ML(Q)をはじめとしたMLシステムの品質確保に関する調査

2022年度 人工知能学会全国大会(第36回)@京都
インダストリアルセッション1
6月14日 (火) 10:00~11:40 E会場

昨今、「機械学習モデルを内包したITシステム」(MLシステム)を構築するプロジェクトが増加にあります。
しかしながら、MLシステムの品質を保ちながらアジャイル開発を進める手法について、グローバルスタンダードな方法論が確立されていません。
そこで本発表ではMLシステムの開発時における品質確保の各種観点、要件、テストについて調査した結果を報告します。
具体的にはD. Sculleyらの「Hidden Technical Debt」論文、アンサー論文「ML Test Score」をはじめ、
Software Engineering for Machine Learning(SE4ML) 、そしてCRISP-DMを継承したCRISP-ML(Q)について紹介します。

AITC - DENTSU SOKEN

June 13, 2022
Tweet

More Decks by AITC - DENTSU SOKEN

Other Decks in Technology

Transcript

  1. CLISP-ML(Q)をはじめとしたMLシステムの品質確保に関する調査
    (※本発表スライドのフルバージョンはサイトにて掲載しています:ISID AITC で検索)
    電通国際情報サービス(ISID)
    X(クロス)イノベーション本部 AIトランスフォーメーションセンター
    製品開発Gr 小川 雄太郎、後藤勇輝
    2022年度 人工知能学会全国大会@京都 インダストリアルセッション1
    6月14日(火) 10:00~10:20

    View full-size slide

  2. 2
    本発表の概要
    昨今、「機械学習モデルを内包したITシステム」(MLシステム)を構築するプロジェクトが増加にあります。
    しかしながら、MLシステムの品質を保ちながらアジャイル開発を進める手法について、グローバルスタンダー
    ドな方法論が確立されていません。
    そこで本発表ではMLシステムの開発時における品質確保の各種観点、要件、テストについて調査した結果を
    報告します。
    具体的にはD. Sculleyらの「Hidden Technical Debt」論文、アンサー論文「ML Test Score」をは
    じめ、Software Engineering for Machine Learning(SE4ML) 、そしてCRISP-DMを継承した
    CRISP-ML(Q)について紹介します。
    【要注意】
    私たちのレビュー発表は、産総研「機械学習品質マネジメントガイドライン 第2版」を否定、上書きするもので
    はありません。上記ガイドでは引用されていないスカリーらの論文やCRISP-ML(Q)などの観点を紹介し、
    産総研「機械学習品質マネジメントガイドライン」の理解をより深めることに寄与したいという立場にあります

    View full-size slide

  3. 3
    ISID AIトランスフォーメーションセンターでは 新たな仲間を募集してます!
    AITCで働く魅力
    ・最先端の技術(AI、クラウド、DevOps)を使用し
    たシステム開発
    ・Kaggle Master、書籍執筆経験者など多様な
    人材が在籍
    ・様々な業種のAI活用に携われる
    採用ページへ
    AIトランスフォーメーションセンター(通称、AITC)の主な業務内容
    ・製造、流通、金融、ライフサイエンスなど様々な業種のAI活用のコンサルティング、データ分析
    ・最新アルゴリズム研究、さらにAIをベースとしたシステム開発

    View full-size slide

  4. 4
    MLシステムをチーム開発するにあたって
    スクラムの歴史を解説
    スクラムを構築したジェフ・サザーランドが、いかにして日本の製造業の「竹
    内・野中論文」と出会ったのか?ジェフの大学時代、戦闘機パイロット時代、
    細胞生物学の博士時代など、キャリア前半の話とともにスクラムの歴史を探
    ります(スクラム開発の解説記事シリーズより)
    Qiitaページへ
    MLシステムをチーム開発するにあたって
    書籍 「アジャイルとスクラムによる開発手法 Azure DevOpsによるプロフェショナルスクラムの実践」
    MLシステムではアジャイル開発、とくにスクラム開発が使用されるケースが多いです。6月末に発表者らより、
    スクラムの「開発者」に焦点を当てた書籍を翻訳出版します(※Azureを使用した解説がベースですが、
    Azureに限らず、種々クラウドやツールを使用したスクラムで役立つ内容が満載です)
    Amazonページへ

    View full-size slide

  5. 5
    目次
    [1] 背景:MLシステムの品質に関する先行研究
    [2] CRISP-DMからCRISP-ML(Q)へ
    [3] CRISP-ML(Q)の詳細
    [4] CRISP-ML(Q)をベースとした品質評価観点

    View full-size slide

  6. 6
    背景:MLシステムの品質に関する先行研究
    01

    View full-size slide

  7. 7
    ・GoogleのD. Sculleyらによる「MLシステム構築時に生じやすい20の技術的負債」を述べた論文
    ・MLシステムにおける「ML code」(≒MLモデル≒MLアルゴリズム)が占める領域は小さく、「ML code」
    を動かすために、「設定ファイル」、「データ取得」、「データ検証」、「特徴量抽出」、「パイプラインプロセスマネジ
    メント」、「リソースマネジメント」、「モデルサービングインフラ」、「実環境モニタリング」、「各種結果解析ツー
    ル」などの周辺コンポーネントが必要
    ・この複雑性からMLシステムの構築時には、技術的負債(Technical Debt)が、隠れて蓄積しやすい
    (※技術的負債とは後々、システムの保守・改善が困難になる要因を意味する)
    ・そこで、上記論文ではMLシステムの技術的負債につながる20の特徴を整理し提起した
    Sculley, David, et al. "Hidden technical debt in machine learning systems." Advances in neural information processing systems 28 (2015): 2503-2511. [link]
    D. Sculleyらの論文を契機に、MLシステムの品質に関する議論が本格化しました

    View full-size slide

  8. 8
    ・スカリーらの論文は、「MLシステムのうち、MLアルゴリズムはほんの一部です」と、図を引用して使用される場面
    が多いですが、この論文内で提起した「20個の技術的負債(Technical Debt)」の具体的内容が重要
    ・負債(Debt)は日本語では正確には、「有利子負債」。 有利子なのがポイント。
    放っておくと、時間の経過とともに利子で借金がどんどん増加(= システムの保守・改善の困難度が増加)
    ・MLシステムでは通常のITシステムにはない種類の技術的負債があり、かつ発見しづらい(Hidden)。
    その結果、MLシステムの構築・維持・運用は難しいものである
    ・次ページでは、論文内で提起された、MLシステムにおける発見しづらい技術的負債20個を解説

    View full-size slide

  9. 9
    MLシステムの技術的負債につながる20の特徴(No. 1~10) (※発表では詳細説明は省略します)
    Sculley, David, et al. "Hidden technical debt in machine learning systems." Advances in neural information processing systems 28 (2015): 2503-2511. [link]
    D. Sculleyらが提唱した Hidden Technical Debt その1
    No. 負債名 発表者ら日本語訳
    1 Entanglement データとシステム挙動のもつれ(データとの分離不可性)
    2 Correction Cascades 直列モデル間での分離不可性
    3 Undeclared Consumers 未把握のモデルユーザーの存在
    4 Unstable Data Dependencies 訓練データ依存による不安定さ
    5 Underutilized Data Dependencies 活用されていないデータの存在
    6 Static Analysis of Data Dependencies データ間依存関係の静的解析の困難さ
    7 Direct Feedback Loops 将来の訓練データに影響を与える直接フィードバックループ
    8 Hidden Feedback Loops 異なるシステムとの間接フィードバックループの存在
    9 Glue Code グルーコード パターン
    10 Pipeline Jungles パイプラインジャングル パターン

    View full-size slide

  10. 10
    MLシステムの技術的負債につながる20の特徴(No. 11~20) (※発表では詳細説明は省略します)
    Sculley, David, et al. "Hidden technical debt in machine learning systems." Advances in neural information processing systems 28 (2015): 2503-2511. [link]
    D. Sculleyらが提唱した Hidden Technical Debt その2
    No. 負債名 発表者ら日本語訳
    11 Dead Experimental Codepaths 試作や実験的コードが残っているパターン
    12 Abstraction Debt 抽象化の欠如パターン
    13 Common Smells MLシステムに多い、良くない実装パターン
    14 Configuration Debt 設定ファイルの不備
    15 Fixed Thresholds in Dynamic Systems MLモデルのしきい値など指定値の問題
    16 Monitoring and Testing 実環境での挙動等をモニタリング&テストしていない
    17 Data Testing Debt 入力データの健全性確認不足
    18 Reproducibility Debt 再現性の未確保
    19 Process Management Debt 複数のMLモデルの実行プロセス管理手法の欠如
    20 Cultural Debt 研究者とエンジニアの間の文化に起因

    View full-size slide

  11. 11
    MLシステムの技術的負債につながる20の特徴
    No. 負債名 説明
    1
    Entanglement
    データとシステム挙動のもつれ
    (データとの分離不可性)
    MLモデルはCACE(Changing Anything Changes Everything)であり、訓
    練に使用するデータや特徴量設計が変わると、MLシステムの挙動ごと変化する
    2
    Correction Cascades
    直列モデル間での分離不可性
    MLモデルを直列にスタッキングした場合には、上流のモデルの変更が下流のモデル
    の性能に影響する。そのため独立にモデルの性能を向上させてもMLシステムとして
    性能が向上するかは不明となる
    3
    Undeclared Consumers
    未把握のモデルユーザーの存在
    MLモデルの出力を、他のどのシステムが使用しているのか未把握である場合、当該
    モデルの変更による影響を見積もれない。また未把握モデルが当該モデルとフィー
    ドバックループを作っているとさらに面倒な問題を生む
    4
    Unstable Data
    Dependencies
    訓練データ依存による不安定さ
    訓練データと本番データの性質が異なったり、訓練データに依存して特徴量やルック
    アップテーブルが作られるアルゴリズムだったりすると、MLシステムの挙動は思い
    通りでなくなる可能性がある
    5
    Underutilized Data
    Dependencies
    活用されていないデータの存在
    MLシステムで活用されていないデータを入れたままにしていても、モデルは動作す
    るが、後々そのデータに起因した修正の面倒さやバグが発生する可能性がある
    Sculley, David, et al. "Hidden technical debt in machine learning systems." Advances in neural information processing
    systems 28 (2015): 2503-2511. [link]
    D. Sculleyらが提唱した Hidden Technical Debt 詳細説明

    View full-size slide

  12. 12
    MLシステムの技術的負債につながる20の特徴
    No. 負債名 説明
    6
    Static Analysis of Data
    Dependencies データ間依
    存関係の静的解析の困難さ
    プログラムの場合はクラス間などの依存関係を簡単に静的解析で追えるが、MLシス
    テムでは、使用している種々データ間の依存関係を静的に明確化することが難しく、
    後々に依存関係の未把握が問題原因になる可能性がある
    7
    Direct Feedback Loops
    将来の訓練データに影響を与え
    る直接フィードバックループ
    MLシステムの推論結果によって、システム運用時に測定される将来の訓練データが
    影響を受ける場合、MLシステムそのものが不安定になる可能性がある
    8
    Hidden Feedback Loops
    異なるシステムとの間接フィー
    ドバックループの存在
    異なるMLシステムを介して互いに推論結果が影響し合っていると、直接フィード
    バックループ同様にMLシステムそのものが不安定になる可能性がある
    9
    Glue Code
    グルーコード パターン
    MLモデル(MLアルゴリズム)が、Fig. 1で示したようにMLシステム内で他のモ
    ジュールと連動して使用できるように追加した「接合用コード」が、utils.pyに大量に
    含まれていて保守性が悪いパターン
    10
    Pipeline Jungles
    パイプラインジャングル パター

    データの「前処理パイプライン」などに、データの新規追加・増築を繰り返していくう
    ちに、各種パイプラインが保守性・可読性の悪い、ぐちゃぐちゃ状態になるパターン
    Sculley, David, et al. "Hidden technical debt in machine learning systems." Advances in neural information processing
    systems 28 (2015): 2503-2511. [link]
    D. Sculleyらが提唱した Hidden Technical Debt 詳細説明

    View full-size slide

  13. 13
    MLシステムの技術的負債につながる20の特徴
    No. 負債名 説明
    11
    Dead Experimental
    Codepaths 試作や実験的
    コードが残っているパターン
    試作段階のコードや実験的に追加したコードたち(既に実質的には未使用)が、製品
    コードに残っていて動作に関わっているパターン
    12
    Abstraction Debt
    抽象化の欠如パターン
    MLシステムの各種コードを抽象的に記述せず、個別具体的に記述・実装することに
    よって、保守性が悪くなるパターン
    13
    Common Smells
    MLシステムに多い、良くない実
    装パターン
    MLモデルにPythonの生のデータ型が入力されていたり、複数の言語でMLモデル
    が構築されていたり、試作コードのままの状態で製品レベルにリファクタリングされ
    ていない、などのパターン
    14
    Configuration Debt
    設定ファイルの不備
    設定ファイル(config)を整備せず、コードにパラメータ値やパイプラインのプロセス
    などを直書きしてしまっていることで、変更容易性、可読性が悪い状態
    15
    Fixed Thresholds in
    Dynamic Systems
    MLモデルの指定値の問題
    実環境では入力データの特徴が経時変化するのに対して、MLモデルの推論のしき
    い値などを固定値に指定したままにしているせいで、システムの性能が悪化した状態
    Sculley, David, et al. "Hidden technical debt in machine learning systems." Advances in neural information processing
    systems 28 (2015): 2503-2511. [link]
    D. Sculleyらが提唱した Hidden Technical Debt 詳細説明

    View full-size slide

  14. 14
    MLシステムの技術的負債につながる20の特徴
    No. 負債名 説明
    16
    Monitoring and Testing
    実環境での挙動等をモニタリン
    グ&テストしていない
    実環境での現時点での最新データの特徴や、MLモデルの推論値の分布などをモニ
    タリングして対処しないことで、MLシステムの性能が悪化する問題
    17
    Data Testing Debt
    入力データの健全性確認不足
    入力データをサニティチェック(健全性確認)したり、その分布を確認したりしないこ
    とに起因して発生する問題
    18
    Reproducibility Debt
    再現性の未確保
    乱数シードなどを固定しておらず、MLモデルの訓練結果を再現できず、再現性のな
    いMLシステムになっている状態
    19
    Process Management
    Debt
    複数のMLモデルの実行プロセ
    ス管理手法の欠如
    複数のMLモデルが動作するシステムの場合、モデルの更新や障害復旧プロセスなど
    が管理されていないと、システムを安定動作させづらい問題
    20
    Cultural Debt
    研究者とエンジニアの間の文化
    に起因
    研究者とエンジニアの文化の違いに起因するチーミング問題
    Sculley, David, et al. "Hidden technical debt in machine learning systems." Advances in neural information processing
    systems 28 (2015): 2503-2511. [link]
    D. Sculleyらが提唱した Hidden Technical Debt 詳細説明

    View full-size slide

  15. 15
    ・スカリーらの論文では、「20個の技術的負債(Technical Debt)」の具体的内容だけでなく、MLシステムの技術
    的負債を測定する5つの方法も提唱しています(定性的ですが・・・)

    View full-size slide

  16. 16
    Sculley, David, et al. "Hidden technical debt in machine learning systems." Advances in neural information processing
    systems 28 (2015): 2503-2511. [link]
    論文内で提唱された、MLシステムの技術的負債を測定する5つの方法
    No. 測定手法
    1 新しいアルゴリズムのMLモデルに置き換えるのにどの程度苦労するか
    2 各データ間の依存関係は容易に把握可能か
    3 MLシステムの変更を加えた際、システムの出力結果の変化を正確に測定できるか
    4 1つのMLモデルの改善が他のモデルの性能劣化を起こさないか
    5 新メンバがどれくらい早くMLシステムの内容を理解し、業務に携われるか
    D. Sculleyらが提唱した Hidden Technical Debt その3

    View full-size slide

  17. 17
    ・その後、スカリーらは、MLシステムの「技術的負債(Technical Debt)」を“定量的に”把握するための、アンサー
    論文を発表します

    View full-size slide

  18. 18
    Breck, Eric, et al. "The ML test score: A rubric for ML production readiness and technical debt reduction."2017 IEEE International Conference on Big Data (Big Data). IEEE, 2017. [link]
    その後、D. Sculleyらは自らアンサー論文を発表 「ML Test Score」
    ・D. Sculleyらによる、「MLシステムの技術的負債論文」へのアンサー論文
    ※Rubric(ルーブリック)とは、到達度を示す評価基準を、観点と尺度からなる表として整理した表です
    ・「特徴量とデータ」、「モデル構築・訓練」、「実装コードおよびインフラ」、「モニタリング」の4つの分野について、
    7個ずつ、合計28個のテスト手法を提案
    ・NIPS 16の発表 Breck, Eric, et al. “What’s your ML Test Score? A rubric for ML production systems.” (2016). [link]
    が、この論文のベースになっています

    View full-size slide

  19. 19
    ML Test Score 「特徴量とデータ」(※発表では詳細説明は省略します)
    Breck, Eric, et al. "The ML test score: A rubric for ML production readiness and technical debt reduction."2017 IEEE International Conference on Big Data (Big Data). IEEE, 2017. [link]
    D. Sculleyらが提唱した ML Test Score その1
    No. テスト内容 発表者ら日本語訳
    1 Feature expectations are captured in a
    schema
    特徴量がスキーマに適合しているかをチェック
    2 All features are beneficial 全ての特徴量がモデルに寄与しているかをチェック
    3 No feature’s cost is too much 使用する際にデメリットが大きい特徴量が含まれていないかをチェック
    4 Features adhere to meta-level requirements
    MLシステムとして使用に適さない特徴量が含まれていないかをチェック
    5 The data pipeline has appropriate privacy
    controls
    データの処理パイプラインでもセキュリティ対策がなされているかをチェッ

    6 New features can be added quickly 新たな特徴量を迅速に追加できる設計になっているかをチェック
    7 All input feature code is tested 特徴量の生成コードが十分にテストされているかをチェック

    View full-size slide

  20. 20
    ML Test Score 「モデル構築・訓練」(※発表では詳細説明は省略します)
    D. Sculleyらが提唱した ML Test Score その2
    No. テスト内容 発表者ら日本語訳
    1 Every model specification undergoes a code
    review and is checked in to a repository
    MLモデル部分がコードレビューされているかチェック
    2 Offline proxy metrics correlate with actual
    online impact metrics
    MLモデルの性能が、ユーザーに貢献しているかをチェック
    3 All hyperparameters have been tuned MLモデルの全ハイパーパラメータはチューニングされているかをチェック
    4 The impact of model staleness is known MLモデルの経年劣化の影響を把握しているかをチェック
    5 A simpler model is not better
    簡便なアルゴリズムのMLモデルより価値があるMLモデルになっている
    かをチェック
    6 Model quality is sufficient on all important
    data slices
    検証データで、とある集団を抜き出して性能を評価して問題がない状態か
    をチェック
    7 The model has been tested for
    considerations of inclusion
    MLモデルが公平性を保持しているかをチェック
    Breck, Eric, et al. "The ML test score: A rubric for ML production readiness and technical debt reduction."2017 IEEE International Conference on Big Data (Big Data). IEEE, 2017. [link]

    View full-size slide

  21. 21
    ML Test Score 「実装コードおよびインフラ」(※発表では詳細説明は省略します)
    D. Sculleyらが提唱した ML Test Score その3
    No. テスト内容 発表者ら日本語訳
    1 Training is reproducible モデル訓練の結果が再現可能かをチェック
    2 Model specification code is unit tested
    モデル訓練のコードに問題がないかを確認するテストコードが用意されて
    いるかをチェック
    3 The full ML pipeline is integration tested
    生データから推論結果返却まで一気通貫なテストが実施されているかを
    チェック
    4 Model quality is validated before attempting
    to serve it
    MLモデルを再学習後、本番デプロイ前に性能検証を実施しているかを
    チェック
    5
    The model allows debugging by observing
    the step-by-step computation of training or
    inference on a single example
    モデル訓練や推論の内部処理を少量のデータを投入しデバック可能か
    チェック
    6
    Models are tested via a canary process
    before they enter production serving
    environments
    カナリアリリースを用いて新モデルがデプロイされているかをチェック
    7 Models can be quickly and safely rolled back
    to a previous serving version
    本番環境でMLモデルをロールバックし旧バージョンに迅速に戻せるかを
    チェック
    Breck, Eric, et al. "The ML test score: A rubric for ML production readiness and technical debt reduction."2017 IEEE International Conference on Big Data (Big Data). IEEE, 2017. [link]

    View full-size slide

  22. 22
    ML Test Score 「モニタリング」(※発表では詳細説明は省略します)
    D. Sculleyらが提唱した ML Test Score その4
    No. テスト内容 発表者ら日本語訳
    1 Dependency changes result in notification
    MLシステムが使用している上流データの変更について情報が通知される
    体制であるかをチェック
    2
    Data invariants hold in training and serving
    inputs
    本番環境のデータ特性の訓練データからの乖離をモニタリングしているか
    チェック
    3 Training and serving features compute the
    same values
    特徴量エンジニアリングの結果が訓練時と本番環境で一致しているかを
    チェック
    4 Models are not too stale 本番環境のモデルが古くなっていないかチェック
    5 The model is numerically stable MLモデル内でNanやInf、その他例外値をアラートしているかチェック
    6
    The model has not experienced a dramatic or
    slow-leak regressions in training speed,
    serving latency, throughput, or RAM usage
    訓練時間、デプロイにかかる時間、推論時間、メモリ使用量をモニタリング
    しているかチェック
    7 The model has not experienced a regression
    in prediction quality on served data
    本番環境のデータが経時変化していないかをチェック
    Breck, Eric, et al. "The ML test score: A rubric for ML production readiness and technical debt reduction."2017 IEEE International Conference on Big Data (Big Data). IEEE, 2017. [link]

    View full-size slide

  23. 23
    「MLシステム」 (右)は従来のシステム(左)に比較して、事前にその挙動を推定しづらいという特徴がある。
    これは、MLシステムがデータに依存している点や種々のMLモデルの設定に依存しているためである。そこ
    で新たに4分野のテストを追加
    Breck, Eric, et al. "The ML test score: A rubric for ML production readiness and technical debt reduction." 2017 IEEE
    International Conference on Big Data (Big Data). IEEE, 2017.[link]
    D. Sculleyらが提唱した ML Test Score 詳細説明
    (1)特徴量とデータ
    (2)モデル
    構築・訓練
    (3)実装コード
    およびインフラ
    (4)モニタリング
    (1)特徴量
    とデータ
    (4)モニタリング

    View full-size slide

  24. 24
    [1] 特徴量とデータに関するテスト
    Breck, Eric, et al. "The ML test score: A rubric for ML production readiness and technical debt reduction." 2017 IEEE
    International Conference on Big Data (Big Data). IEEE, 2017.[link]
    No. テスト内容 実行方法
    1
    Feature expectations are captured in a
    schema
    特徴量がスキーマに適合しているかをチェック
    各特徴量をドメイン駆動型開発のValue Objectとして扱い、分布や取りうる
    値の範囲などについて、validationをかける
    2
    All features are beneficial
    全ての特徴量がモデルに寄与しているかをチェック
    特徴量間での相関を確認し、相関が強すぎるものは片方を削除。さらにLeave
    one outで各特徴量がモデルの性能に寄与していること確認するための、
    validationをかける
    3
    No feature’s cost is too much
    使用する際にデメリットが大きい特徴量が含まれてい
    ないかをチェック
    その特徴量を追加することで、推論時間の増加、メモリ使用量の増加、はどの
    程度かを確認する。また特徴量は、依存するデータの生成過程で経時変化しや
    すくないかなど、不安定性をはらんでいないか検討する
    4
    Features adhere to meta-level
    requirements
    MLシステムとして使用に適さない特徴量が含まれて
    いないかをチェック
    データとしては取得できていたとしても、その特徴量を使用することがMLシス
    テムとして適切でないもの(例えば年齢など、倫理的観点)は、本番モデルから
    は削除されているかを確認する
    5
    The data pipeline has appropriate
    privacy controls
    データの処理パイプラインでもセキュリティ対策がな
    されているかをチェック
    データの処理パイプラインにアクセスできると、機密性の高い生データを取得
    できたり、類推できる可能性がある。生データそのもののアクセス権限だけで
    なく、パイプラインへのアクセス権限も適切になされているかを確認する
    D. Sculleyらが提唱した ML Test Score 詳細説明

    View full-size slide

  25. 25
    [1] 特徴量とデータに関するテスト
    Breck, Eric, et al. "The ML test score: A rubric for ML production readiness and technical debt reduction." 2017 IEEE
    International Conference on Big Data (Big Data). IEEE, 2017.[link]
    No. テスト内容 実行方法
    6
    New features can be added quickly
    新たな特徴量を迅速に追加できる設計になっている
    かをチェック
    特徴量の追加を容易に試行錯誤できると良いモデルを持つMLシステムを構築
    しやすい。こうした特徴量の追加が容易で、迅速に実施できる設計になってい
    るかを確認する
    7
    All input feature code is tested
    特徴量の生成コードが十分にテストされているかを
    チェック
    特徴量間エンジニアリングのコード部分が、要件を満たしていることを確認す
    るために、十分にテストされているかチェックする。さらに訓練データとテスト
    データのそれぞれを入力してみて、機能するかを確認する
    D. Sculleyらが提唱した ML Test Score 詳細説明

    View full-size slide

  26. 26
    [2] モデル構築・訓練に関するテスト
    Breck, Eric, et al. "The ML test score: A rubric for ML production readiness and technical debt reduction." 2017 IEEE
    International Conference on Big Data (Big Data). IEEE, 2017.[link]
    No. テスト内容 実行方法
    1
    Every model specification undergoes a
    code review and is checked in to a
    repository
    MLモデル部分がコードレビューされているかチェック
    MLモデルの詳細内容を誰か一人しか把握していない状況を避ける必要がある。
    これは保守面でも重要である。そのためにMLモデル部分のコードが他者に
    コードレビューされているかを確認する。またモデルのバージョン管理がされ
    ているかも確認する
    2
    Offline proxy metrics correlate with
    actual online impact metrics
    MLモデルの性能が、ユーザーに貢献しているかを
    チェック
    MLモデルの性能が最終的にどの程度ユーザーに貢献し、MLシステムとしての
    ビジネス価値に寄与しているかを明らかにしておくことが重要である。例えば、
    性能を少し悪くしたモデルとA/Bテストして、MLモデルの性能がどのような関
    係性で最終的な価値へ貢献しているかを確認する
    3
    All hyperparameters have been tuned
    MLモデルの全ハイパーパラメータはチューニングさ
    れているかをチェック
    MLモデルで使用されている、または訓練時に使用されている各種ハイパーパ
    ラメータが、全てグリッドサーチなどを用いて調整されていて、最大パフォーマ
    ンスになるように設定されているのかを確認する
    4
    The impact of model staleness is known
    MLモデルの経年劣化の影響を把握しているかを
    チェック
    本番環境のデータの性質が経時変化するため、モデルの再学習は重要である。
    そのため、実際にどの程度の頻度で再学習するべきかを把握しているか確認
    する。例えば昨日までのデータでのモデル、先週までモデル、昨年モデルをデプ
    ロイし、A/Bテストで比較する
    D. Sculleyらが提唱した ML Test Score 詳細説明

    View full-size slide

  27. 27
    [2] モデル構築・訓練に関するテスト
    Breck, Eric, et al. "The ML test score: A rubric for ML production readiness and technical debt reduction." 2017 IEEE
    International Conference on Big Data (Big Data). IEEE, 2017.[link]
    No. テスト内容 実行方法
    5
    A simpler model is not better
    簡便なアルゴリズムのMLモデルより価値があるML
    モデルになっているかをチェック
    複雑な特徴量エンジニアリングやモデル構築過程を有するMLモデルを使用す
    る前に、線形モデルなどの簡便で保守容易なMLモデルでの性能を確認してお
    く。そして、複雑なモデルを使用するだけのメリットがあるかを確認する
    6
    Model quality is sufficient on all
    important data slices
    検証データで、とある集団を抜き出して性能を評価し
    て問題がない状態かをチェック
    検証データのとある集団、例えば映画データを扱う場合は特定ジャンルの映画
    のみなど、目的変数の特定の値の集団のみを取り出して性能を確認し、グロー
    バルな性能と著しく変化しないかを確認する。目的変数の場合はラベルごとの
    性能など。著しい変化がある場合はその集団の訓練データが不足していると考
    えられる
    7
    The model has been tested for
    considerations of inclusion
    MLモデルが公平性を保持しているかをチェック
    MLモデルが公平性を保持しており、inclusionなものかを確認する。これは公
    平性を担保するだけでなく、モデルのロバスト性(堅牢性)にも関わる問題であ
    る。特徴量の内容を精査し公平性に関わるものについて、例えばスライスして
    抜き出し(性別や居住地域など)、グローバルなデータでの性能と著しい変化が
    ないかを確認する
    D. Sculleyらが提唱した ML Test Score 詳細説明

    View full-size slide

  28. 28
    [3] 実装コードおよびインフラに関するテスト
    Breck, Eric, et al. "The ML test score: A rubric for ML production readiness and technical debt reduction." 2017 IEEE
    International Conference on Big Data (Big Data). IEEE, 2017.[link]
    No. テスト内容 実行方法
    1
    Training is reproducible
    モデル訓練の結果が再現可能かをチェック
    MLモデルの訓練にランダム性がなく、訓練結果の再現性がある場合にはMLシ
    ステムの保守性も向上する。またハイパラチューニングなどでも重要である。そ
    のため、乱数のシード固定などがなされ、モデル訓練の結果が再現可能かを確
    認する
    2
    Model specification code is unit tested
    モデル訓練のコードに問題がないかを確認するテスト
    コードが用意されているかをチェック
    MLモデルの訓練パイプラインの設定ファイルへの単体テストの実施、MLモデ
    ルの訓練で損失が低下しているかの単体テストの実施など、モデル訓練のコー
    ド自体が単体テストされているかを確認する。
    また、モデル訓練がチェックポイントから再開できるように実装されていると便
    利である
    3
    The full ML pipeline is integration tested
    生データから推論結果返却まで一気通貫なテストが実
    施されているかをチェック
    MLシステムでは、特徴量エンジニアリングやMLモデル構築やデプロイなど
    様々なステージが存在し、実装者が異なることも多い。そのため、一気通貫に生
    データから推論結果返却までをテストしているかを確認する。
    とくに新しいMLモデルやパイプラインをデプロイした際にはデプロイ後テスト
    を実施しておくと良い
    4
    Model quality is validated before
    attempting to serve it
    MLモデルを再学習後、本番デプロイ前に性能検証を
    実施しているかをチェック
    MLモデルを再学習した後、すぐに本番環境にデプロイせず、性能検証をしてい
    るかを確認する。例えば、検証データでの性能確認や前バージョンのモデルと
    の性能比較などを実施する
    D. Sculleyらが提唱した ML Test Score 詳細説明

    View full-size slide

  29. 29
    [3] 実装コードおよびインフラに関するテスト
    Breck, Eric, et al. "The ML test score: A rubric for ML production readiness and technical debt reduction." 2017 IEEE
    International Conference on Big Data (Big Data). IEEE, 2017.[link]
    No. テスト内容 実行方法
    5
    The model allows debugging by
    observing the step-by-step computation
    of training or inference on a single
    example
    モデル訓練や推論の内部処理を少量のデータを投入
    しデバック可能かチェック
    何らか問題が発生した際の原因究明、解決に向けて、MLモデルの実装が保守
    容易であることが望ましい。少量のデータを投入し、MLモデルの訓練や推論の
    内部処理をデバックすることが可能かを確認する
    6
    Models are tested via a canary process
    before they enter production serving
    environments
    カナリアリリースで新モデルがデプロイされているか
    をチェック
    新モデルを現行モデルと一気に入れ替えると障害発生や性能劣化が発生した
    際の影響範囲が膨大となる。そのため、新モデルをリリースするさいにはカナ
    リアリリースを適用しているかを確認する
    7
    Models can be quickly and safely rolled
    back to a previous serving version
    本番環境でMLモデルをロールバックし旧バージョン
    に迅速に戻せるかをチェック
    新モデルをデプロイした際に障害が発生した場合、初期対応としてモデルの
    バージョンをロールバックできることが望ましい。このロールバックが迅速に実
    行できる設計・運用となっているかを確認する
    D. Sculleyらが提唱した ML Test Score 詳細説明

    View full-size slide

  30. 30
    [4] モニタリングに関するテスト
    Breck, Eric, et al. "The ML test score: A rubric for ML production readiness and technical debt reduction." 2017 IEEE
    International Conference on Big Data (Big Data). IEEE, 2017.[link]
    No. テスト内容 実行方法
    1
    Dependency changes result in
    notification
    MLシステムが使用している上流データの変更につい
    て情報が通知される体制であるかをチェック
    MLシステムが利用している上流データでスキーマの変更や取得条件の変更な
    どがあると、システムやMLモデルに大きな影響がある。上流データを管理して
    いる部門から、こうした変更時にはきちんと情報が通知される体制であるかを
    確認する
    2
    Data invariants hold in training and
    serving inputs
    本番環境のデータ特性の訓練データからの乖離をモ
    ニタリングしているかチェック
    本番環境でのデータ特性が訓練データと乖離するとMLシステムの性能が劣化
    する。本番環境での入力データでスキーマ不一致が増えていないかや分布形状
    が変化していないかをモニタリング&アラートするようになっているかを確認
    する
    3
    Training and serving features compute
    the same values
    特徴量エンジニアリングの結果が訓練時と本番環境で
    一致しているかをチェック
    特徴量エンジニアリングのパイプラインがモデル訓練時と本番環境で異なる場
    合が存在する(本番環境はより処理速度を速めるように変更されているなど)。
    これは「training/serving skew」と呼ばれる。本番環境と訓練コードに同じ
    データを投入し、出力された特徴量の値が一致するかをテストするように整備
    されているか確認する
    4
    Models are not too stale
    本番環境のモデルが古くなっていないかチェック
    MLモデルをデプロイしてからの経過時間をモニタリングするとともに、あらか
    じめ定めた再学習タイミングでアラートを出すようにして、古くなったモデルを
    運用しない体制が整備されているかを確認する
    D. Sculleyらが提唱した ML Test Score 詳細説明

    View full-size slide

  31. 31
    [4] モニタリングに関するテスト
    Breck, Eric, et al. "The ML test score: A rubric for ML production readiness and technical debt reduction." 2017 IEEE
    International Conference on Big Data (Big Data). IEEE, 2017.[link]
    No. テスト内容 実行方法
    5
    The model is numerically stable
    MLモデル内でNanやInf、その他例外値をアラートし
    ているかチェック
    MLモデルの訓練や推論時に途中でNanやInfやスキーマ不一致の例外値が生
    じているとモデルの不安定性につながる。NanやInfが発生していることをき
    ちんとアラートするようにしているかを確認する
    6
    The model has not experienced a
    dramatic or slow-leak regressions in
    training speed, serving latency,
    throughput, or RAM usage
    訓練時間、デプロイにかかる時間、推論時間、メモリ使
    用量をモニタリングしているかチェック
    使用するデータやモデルのアルゴリズム、特徴量が変わると、訓練時間、デプロ
    イにかかる時間、推論時間、メモリ使用量が変化する。きちんとこれらをモニタ
    リングし、急激な変化にはアラートをあげるようにしているかを確認する
    7
    The model has not experienced a
    regression in prediction quality on
    served data
    本番環境のデータが経時変化していないかをチェック
    MLモデルの訓練と検証は過去のデータを使用して実施されているため、本番
    環境できちんと性能を発揮している保証はない。そこで本番環境で推論結果が
    正しいかを検証する運用体制になっているかを確認する
    D. Sculleyらが提唱した ML Test Score 詳細説明

    View full-size slide

  32. 32
    「MLテストスコア」は各テスト項目について、「手動で実施しドキュメントに記載されている」であれば0.5点、
    「自動で実施され記録される」であれば1点とする。
    4つの分野で各最大で7点であり、最終的なMLシステムのMLテストスコアとしては4つの分野の最低点
    とする。以下はGoogleでの当時の36システムの平均点。この図から、どの項目が簡単でどこが難しい or
    見逃しやすいかが分かる
    Breck, Eric, et al. "The ML test score: A rubric for ML production readiness and technical debt reduction." 2017 IEEE
    International Conference on Big Data (Big Data). IEEE, 2017.[link]
    D. Sculleyらが提唱した ML Test Score 詳細説明

    View full-size slide

  33. 33
    ・スカリーらはML Test Scoreを構築する際、4つの分野にMLシステム構築内容を分解しました
    (1)特徴量とデータ、(2)モデル構築・訓練、(3)実装コードおよびインフラ、(4)モニタリング
    ・しかし発表者らは、「4つの分野への分解」は以下のような若干の扱いづらさを感じています
    [1] 4つでは分解レベルとして大きすぎる点。他にも切り方があるであろう・・・
    [2] MLシステム構築のプロセス(時間軸)を意識していないため、構築の時系列順に扱いづらい点
    [3] システム開発の標準である、要求→要件→テストの3段階プロセスでなく、唐突にテストが提示される点
    (要求と要件の話がない・・・)
    ・そこでまずは、その他の文献でのMLシステム構築時の品質の「切り口」を調査しました
    ・その後、MLシステムの品質調査ベースとする、「MLシステム構築プロセス」のグローバルな標準手法を探索

    View full-size slide

  34. 34
    [1] Key perspectives in quality management of AI projects での切り口
    (Quality Management of Machine Learning Systems, 2020.)
    様々な「MLシステム構築」の切り口 その1
    Santhanam, P. "Quality Management of Machine Learning Systems."International Workshop on Engineering Dependable and Secure Machine Learning Systems. Springer, Cham, 2020. [link] [linkarxiv]
    3.3 AI Trust Assessment
    -
    Explainability
    -
    Bias/Fairness
    -
    Robustness
    -
    Transparency
    3.4 Quality Metrics
    -
    Defect management
    -
    Model evaluation
    -
    Model Uncertainty

    View full-size slide

  35. 35
    様々な「MLシステム構築」の切り口 その2
    Serban, Alex, et al. “Adoption and effects of software engineering best practices in machine learning.” Proceedings of the 14th ACM/IEEE International Symposium on Empirical
    Software Engineering and Measurement (ESEM). 2020. [link] ※論文よりもサイトの方が情報が更新されています SE4MLのサイト https://se-ml.github.io/
    [2] Software Engineering for Machine Learning(SE4ML) での切り口
    「データ」、「訓練」、「実装コード」、「デプロイ」、「チーム」、「ガバナンス」の6つの切り口で整理

    View full-size slide

  36. 36
    様々な「MLシステム構築」の切り口 その2
    Serban, Alex, et al. “Adoption and effects of software engineering best practices in machine learning.” Proceedings of the 14th ACM/IEEE International Symposium on Empirical
    Software Engineering and Measurement (ESEM). 2020. [link] ※論文よりもサイトの方が情報が更新されています SE4MLのサイト https://se-ml.github.io/
    [2] Software Engineering for Machine Learning(SE4ML) での切り口
    (別途、4つの観点から、MLシステムの構築にとくに重要だったプラクティス上位3つを整理)

    View full-size slide

  37. 37
    様々な「MLシステム構築」の切り口 その2
    Serban, Alex, et al. “Adoption and effects of software engineering best practices in machine learning.” Proceedings of the 14th ACM/IEEE International Symposium on Empirical
    Software Engineering and Measurement (ESEM). 2020. [link] ※論文よりもサイトの方が情報が更新されています SE4MLのサイト https://se-ml.github.io/
    [2] Software Engineering for Machine Learning(SE4ML) での切り口
    No. 領域(切り口) 教訓 難易度
    1 データ Use Sanity Checks for All External Data Sources Medium
    2 データ Check that Input Data is Complete, Balanced and Well Distributed Advanced
    3 データ Test for Social Bias in Training Data Not ranked
    4 データ Write Reusable Scripts for Data Cleaning and Merging Basic
    5 データ Ensure Data Labelling is Performed in a Strictly Controlled Process Basic
    6 データ Prevent Discriminatory Data Attributes Used As Model Features Not ranked
    7 データ Use Privacy-Preserving Machine Learning Techniques Not ranked
    8 データ Make Data Sets Available on Shared Infrastructure (private or public) Medium

    View full-size slide

  38. 38
    様々な「MLシステム構築」の切り口 その2
    Serban, Alex, et al. “Adoption and effects of software engineering best practices in machine learning.” Proceedings of the 14th ACM/IEEE International Symposium on Empirical
    Software Engineering and Measurement (ESEM). 2020. [link] ※論文よりもサイトの方が情報が更新されています SE4MLのサイト https://se-ml.github.io/
    [2] Software Engineering for Machine Learning(SE4ML) での切り口
    No. 領域(切り口) 教訓 難易度
    9 訓練 Share a Clearly Defined Training Objective within the Team Basic
    10 訓練 Capture the Training Objective in a Metric that is Easy to Measure and Understand Basic
    11 訓練 Test all Feature Extraction Code Advanced
    12 訓練 Assign an Owner to Each Feature and Document its Rationale Advanced
    13 訓練 Actively Remove or Archive Features That are Not Used Advanced
    14 訓練 Employ Interpretable Models When Possible Not ranked
    15 訓練 Peer Review Training Scripts Medium
    16 訓練 Enable Parallel Training Experiments Basic
    17 訓練 Automate Feature Generation and Selection Not ranked
    18 訓練 Automate Hyper-Parameter Optimisation Advanced
    19 訓練 Automate Configuration of Algorithms or Model Structure Not ranked

    View full-size slide

  39. 39
    様々な「MLシステム構築」の切り口 その2
    Serban, Alex, et al. “Adoption and effects of software engineering best practices in machine learning.” Proceedings of the 14th ACM/IEEE International Symposium on Empirical
    Software Engineering and Measurement (ESEM). 2020. [link] ※論文よりもサイトの方が情報が更新されています SE4MLのサイト https://se-ml.github.io/
    [2] Software Engineering for Machine Learning(SE4ML) での切り口
    No. 領域(切り口) 教訓 難易度
    20 訓練 Continuously Measure Model Quality and Performance Basic
    21 訓練 Assess and Manage Subgroup Bias Not ranked
    22 訓練 Use Versioning for Data, Model, Configurations and Training Scripts Basic
    23 訓練 Share Status and Outcomes of Experiments Within the Team Basic

    View full-size slide

  40. 40
    様々な「MLシステム構築」の切り口 その2
    Serban, Alex, et al. “Adoption and effects of software engineering best practices in machine learning.” Proceedings of the 14th ACM/IEEE International Symposium on Empirical
    Software Engineering and Measurement (ESEM). 2020. [link] ※論文よりもサイトの方が情報が更新されています SE4MLのサイト https://se-ml.github.io/
    [2] Software Engineering for Machine Learning(SE4ML) での切り口
    No. 領域(切り口) 教訓 難易度
    24 実装コード Run Automated Regression Tests Advanced
    25 実装コード Use Continuous Integration Medium
    26 実装コード Use Static Analysis to Check Code Quality Advanced
    27 実装コード Assure Application Security Not ranked
    28 デプロイ Automate Model Deployment Medium
    29 デプロイ Enable Shadow Deployment Medium
    30 デプロイ Continuously Monitor the Behaviour of Deployed Models Medium
    31 デプロイ Perform Checks to Detect Skew between Models Advanced
    32 デプロイ Enable Automatic Roll Backs for Production Models Medium
    33 デプロイ Log Production Predictions with the Model's Version and Input Data Advanced
    34 デプロイ Provide Audit Trails Not ranked

    View full-size slide

  41. 41
    様々な「MLシステム構築」の切り口 その2
    Serban, Alex, et al. “Adoption and effects of software engineering best practices in machine learning.” Proceedings of the 14th ACM/IEEE International Symposium on Empirical
    Software Engineering and Measurement (ESEM). 2020. [link] ※論文よりもサイトの方が情報が更新されています SE4MLのサイト https://se-ml.github.io/
    [2] Software Engineering for Machine Learning(SE4ML) での切り口
    No. 領域(切り口) 教訓 難易度
    35 チーム Use A Collaborative Development Platform Basic
    36 チーム Work Against a Shared Backlog Medium
    37 チーム Communicate, Align, and Collaborate With Others Basic
    38 チーム Decide Trade-Offs through Defined Team Process Not ranked
    39 ガバナンス Establish Responsible AI Values Not ranked
    40 ガバナンス Perform Risk Assessments Not ranked
    41 ガバナンス Enforce Fairness and Privacy Advanced
    42 ガバナンス Inform Users on Machine Learning Usage Not ranked
    43 ガバナンス Explain Results and Decisions to Users Not ranked
    44 ガバナンス Provide Safe Channels to Raise Concerns Not ranked
    45 ガバナンス Have Your Application Audited Not ranked

    View full-size slide

  42. 42
    Kästner, Christian, and Eunsuk Kang. "Teaching Software Engineering for Al-Enabled Systems." 2020 IEEE/ACM 42nd International Conference on Software Engineering:
    Software Engineering Education and Training (ICSE-SEET). IEEE, 2020.[link] [linkarxiv][github]
    の提唱と、そのカバー領域
    様々な「MLシステム構築」の切り口 その3
    [3] Software Engineering for AI-Enabled Systems(SE4AI) での切り口

    View full-size slide

  43. 43
    続いて、「時間軸に沿った」MLシステム構築プロセスという観点で切り口を調査しました

    View full-size slide

  44. 44
    [1] 混合型機械学習ライフサイクルプロセス(産総研:機械学習品質マネジメントガイドライン 第2版)
    日本国内で最も定番のMLシステム開発のガイドラインだと思います
    様々な「MLシステム構築の時系列プロセス」 その1
    産総研:機械学習品質マネジメントガイドライン 第2版, 2021. [link]

    View full-size slide

  45. 45
    [2] The nine stages of the machine learning workflow
    (Software Engineering for Machine Learning:A Case Study) Microsoft, 2019.
    様々な「MLシステム構築の時系列プロセス」 その2
    Amershi, Saleema, et al. "Software engineering for machine learning: A case study." 2019 IEEE/ACM 41st International Conference on Software Engineering: Software
    Engineering in Practice (ICSE-SEIP). IEEE, 2019. [link]

    View full-size slide

  46. 46
    [3] Quality Management of Machine Learning Systems, 2020. での、MLシステム構築図
    様々な「MLシステム構築の時系列プロセス」 その3
    Santhanam, P. "Quality Management of Machine Learning Systems."International Workshop on Engineering Dependable and Secure Machine Learning Systems. Springer, Cham, 2020. [link] [linkarxiv]

    View full-size slide

  47. 47
    ・MLシステムの品質に関しては、種々の切り口、種々のテスト観点、そして様々な構築プロセスの記述が乱
    立しており、「これだ!」というベストプラクティスは“グローバルには確立していない”(と私たちは感じる)
    ・とはいえ、なんらかの「MLシステム構築プロセス」を土台に、要求・要件・テスト観点・テストケースを整理し、
    品質の高い、MLシステムを構築するスキームが必要とされる
    ・次章では、「まずはベストプラクティスを押さえ、それを発展させる」、という視点で、
    データサイエンス分析のベストプラクティス的な存在である、「CRISP-DM」をベースに、これをMLシステ
    ムに発展させた内容を検証する
    まとめ 背景:MLシステムの品質に関する先行研究

    View full-size slide

  48. 48
    CRISP-DMからCRISP-ML(Q)へ
    02

    View full-size slide

  49. 49
    ・データサイエンス分析の分野ではこれまで、CRISP-DM(Cross-Industry Standard Process for
    Data Mining)がスタンダードなプラクティスとして存在感を示していた
    CRISP-DMの発展 その1
    オラクル社 https://www.slideshare.net/oracle4engineer/20151209-ddd

    View full-size slide

  50. 50
    ・しかし、データサイエンス分析と機械学習は特性が異なり、CRISP-DMから種々亜種が誕生
    (CRISP-DMは20年以上前に提案されたスキームであり・・・)
    CRISP-DMの発展 その2
    Martínez-Plumed, Fernando, et al. "CRISP-DM twenty years later: From data mining processes to data science trajectories."IEEE Transactions on Knowledge and Data Engineering(2019). [link]

    View full-size slide

  51. 51
    [発展パターン例1] TDSP(Team Data Science Process) by Microsoft
    CRISP-DMの発展例 その1
    https://docs.microsoft.com/ja-jp/azure/architecture/data-science-process/overview

    View full-size slide

  52. 52
    [発展パターン例1] TDSP(Team Data Science Process)
    (※発表者らによる、日本語翻訳と成果物の一例)
    CRISP-DMの発展例 その1
    フェイズ 内容 成果物
    プロジェクトの開始見
    極め
    ・Issue度、ROI、技術的難易度、
    データの質、の4観点からのプロジェ
    クトの査定
    ・「プロジェクトの開始見極め」報告レポート
    ・分析に使用したプログラムファイル
    ・データの取得と前処理に使用したコード
    ビジネスの把握
    ・チームとメンバの定義
    ・目標を定義
    ・機械学習の種類と性能を定義
    ・リポジトリとVMの用意
    ・データを整理
    ・チャータードキュメント(プロジェクト憲章)
    ・リポジトリ
    ・計算用のVM(Virtual Machine)
    ・生データの取得解説書
    ・データ辞書
    データの取得と理解
    ・データ前処理のプログラムを作成
    ・探索的データ解析(EDA:
    Exploratory Data Analysis)
    ・前処理コード
    ・前処理パイプライン解説書
    ・データ品質レポート
    ・データ定義書
    モデリング
    ・小規模サンプルデータの用意
    ・特徴量エンジニアリング
    ・モデルの訓練
    ・小規模なサンプルデータセット
    ・データ定義書の [特徴セット] 部分
    ・モデルの訓練を実施するコード
    ・各モデルレポート
    機械学習の性能確認 ・ROIを基準とした性能確認 ・最終モデルレポート
    デプロイ
    ・MLシステムのアーキテクチャ図作

    ・推論部分のコードを実装
    ・デプロイのパイプラインを構築
    ・MLシステムのアーキテクチャ図
    ・機械学習の推論コード
    ・AzureDevOpsとMLサービスで使用するコード
    類一式
    顧客受入
    ・システムの検証
    ・プロジェクトのハンドオフ
    ・顧客向けプロジェクトの終了レポート
    開始
    終了

    View full-size slide

  53. 53
    [発展パターン例2] DST(Data Science Trajectories model)
    (データサイエンスプロジェクトの目的の多様化に合わせ、CRISP-DMを内包し、拡張可能なスキームを提案)
    CRISP-DMの発展例 その2
    Martínez-Plumed, Fernando, et al. "CRISP-DM twenty years later: From data mining processes to data science trajectories."IEEE Transactions on Knowledge and Data Engineering(2019). [link]

    View full-size slide

  54. 54
    [発展パターン例3] CRISP-ML(Q)
    ・CRISP-DMをベースとしつつも、「機械学習プロジェクト」に適用するための、CRISP-ML(Q)を提唱
    ・20年以上前のCRISP-DMでは出発点が「Data Mining(やデータ分析)」であった点、そして、データマ
    イニングやデータ分析と、機械学習・ディープラーニングは性質が極度に異なる点を明示的に示し、その前提
    で、スキームを構築・提唱
    CRISP-DMの発展例 その3
    Studer, Stefan, et al. "Towards CRISP-ML (Q): a machine learning process model with quality assurance methodology."Machine Learning and Knowledge Extraction3.2 (2021): 392-413. [link]

    View full-size slide

  55. 55
    [発展パターン例3] CRISP-ML(Q)
    CRISP-DMの「ビジネス理解」と「データ理解」が合体し、さらに、「Monitoring and Maintenance」(監
    視・保守)を追加。そしてQuality面も強化(詳細は次章にて解説) ※論文に全体像の図がなく、以下図は発表者ら記す
    CRISP-DMの発展例 その3
    Studer, Stefan, et al. "Towards CRISP-ML (Q): a machine learning process model with quality assurance methodology."Machine Learning and Knowledge Extraction3.2 (2021): 392-413. [link]
    Martínez-Plumed, Fernando, et al. "CRISP-DM twenty years later: From data mining processes to data science trajectories."IEEE Transactions on Knowledge and Data Engineering(2019). [link]
    CRISP-DM CRISP-ML(Q)

    View full-size slide

  56. 56
    [発展パターン例4] CRISP-ML
    要注意。前出のCRISP-ML(Q)とは異なるフレームワークとして、その後、「CRISP-ML」も提唱されている
    なお、「CRISP-ML(Q)」と「CRISP-ML」は名前が似ていますが別物であり、著者らも別Grである
    CRISP-DMの発展例 その4
    Kolyshkina, Inna, and Simeon Simoff. "Interpretability of Machine Learning Solutions in Public Healthcare: The CRISP-ML Approach." Frontiers in big Data 4 (2021): 18. [link]

    View full-size slide

  57. 57
    ・データサイエンス分析のベストプラクティス的な存在である、「CRISP-DM」をベースに、これをMLシステ
    ムに発展させた内容を検証し、「CRISP-ML(Q)」を「MLシステム構築プロセス」を土台に据えて、この後、
    要求・要件→テスト観点→テストケースと落とし込んで整理していくのが、グローバルには受け入れられ、動
    きやすいだろうと判断
    【CRISP-ML(Q)を選定した理由】
    - CRISP-DMを自然に拡張していて扱いやすい
    - ml-ops.org [link] サイトで、ML-OPSのスキームとして選定されていて、グローバル認知度が高そう
    まとめ CRISP-DMからCRISP-ML(Q)へ

    View full-size slide

  58. 58
    CRISP-ML(Q)の詳細
    03

    View full-size slide

  59. 59
    (1)CRISP-DMをベースとしつつも、MLに適用するための、CRISP-ML(Q)を提唱
    前提として、Data MiningとMachine Learningはプロセスが異なる
    ・20年以上前のCRISP-DMでは出発点が「Data Mining(やデータ分析)」であった点、そして、データ
    マイニングやデータ分析と、機械学習・ディープラーニングは性質が極度に異なる点を明示的にす
    Studer, Stefan, et al. "Towards CRISP-ML (Q): a machine learning process model with quality assurance methodology."Machine Learning and Knowledge Extraction3.2 (2021): 392-413. [link]
    CRISP-ML(Q)の詳細 その1

    View full-size slide

  60. 60
    (2)CRISP-ML(Q)では、「Monitoring & Maintenance」が追加。さらにQuality(品質)を担保す
    るために、各フェイズにQuality Assurance(品質保証ステップ)を追加
    CRISP-ML(Q)の詳細 その2
    Studer, Stefan, et al. "Towards CRISP-ML (Q): a machine learning process model with quality assurance methodology."Machine Learning and Knowledge Extraction3.2 (2021): 392-413. [link]

    View full-size slide

  61. 61
    CRISP-DMの「ビジネス理解」と「データ理解」が合体し、さらに、「Monitoring and Maintenance」(監
    視・保守)を追加。そしてQuality面も強化(詳細は次章にて解説) ※論文に全体像の図がなく、以下図は発表者ら記す
    CRISP-DM と CRISP-ML(Q)の比較 その1
    Studer, Stefan, et al. "Towards CRISP-ML (Q): a machine learning process model with quality assurance methodology."Machine Learning and Knowledge Extraction3.2 (2021): 392-413. [link]
    Martínez-Plumed, Fernando, et al. "CRISP-DM twenty years later: From data mining processes to data science trajectories."IEEE Transactions on Knowledge and Data Engineering(2019). [link]
    CRISP-DM CRISP-ML(Q)

    View full-size slide

  62. 62
    CRISP-DM(Cross-Industry Standard Process for Data Mining)
    https://www.slideshare.net/oracle4engineer/20151209-ddd
    CRISP-DM と CRISP-ML(Q)の比較 その2

    View full-size slide

  63. 63
    CRISP-ML(Q) ※以下の図は発表者ら記す。6フェイズ、29項目から構成される
    CRISP-DM と CRISP-ML(Q)の比較 その3

    View full-size slide

  64. 64
    [1] Business and Data Understanding(ビジネスとデータ理解)
    No. 内容 実行方法
    1
    Define the Scope of the ML Application
    MLシステムのスコープを決定する
    MLシステムが満たすべきスコープ(ビジネス面、ML面)を定める。その際、ビジ
    ネスの人間、研究者、データエンジニアが揃った状態で進め、十分な量のデータ
    が存在するかなどにも注意する
    2
    Success Criteria
    MLシステムの成功基準を定める
    3段階に分割し、MLシステムの定量的な成功基準を定める。ビジネス目標、ML
    モデル目標、経済的な目標(金銭換算できる目標)を定める
    3
    Feasibility
    実現可能性を検討する
    4つの側面から実現可能性を検討する。データは十分に存在するか、他の事例
    などでPoCは成功しているか(Applicability of ML technology)、法律
    的観点で制限はないか(規制や公平性、倫理面)、定量的成功基準は満たせそう
    か、の4つを検討する
    4
    Data Collection
    データを収集する
    MLモデル構築に必要なデータを収集する。データ収集は継続的なプロセスな
    ので、データセットのバージョン管理や収集手法に関するドキュメンテーション
    をきちんと行う必要がある
    CRISP-ML(Q)の各要素内容 その1
    Studer, Stefan, et al. "Towards CRISP-ML (Q): a machine learning process model with quality assurance methodology."Machine Learning and Knowledge Extraction3.2 (2021): 392-413. [link]

    View full-size slide

  65. 65
    [1] Business and Data Understanding(ビジネスとデータ理解)
    No. 内容 実行方法
    5
    Data Quality Verification
    データの品質を検証する
    ドメイン知識などを含めたデータに関する記述(description)を整備し、デー
    タの要件(スキーマ、範囲、分布)を定義し、使用する訓練データを検証する
    6
    Review of Output Documents
    成果物ドキュメントをレビューする
    「Business & Data Understanding」では、開発のスコープ、成功基準、
    データの品質検証を実施した。これらの結果を成果物ドキュメントにまとめ、
    MLシステムのFeasibility(実現可能性)が十分にあるのかをレビューする
    Studer, Stefan, et al. "Towards CRISP-ML (Q): a machine learning process model with quality assurance methodology."Machine Learning and Knowledge Extraction3.2 (2021): 392-413. [link]
    CRISP-ML(Q)の各要素内容 その2

    View full-size slide

  66. 66
    [2] Data Preparation(データ準備)
    No. 内容 実行方法
    1
    Select Data
    データを選択する
    必要最低限で十分な特徴量となるように、データを選択する。不要な特徴量を
    MLシステムに入れることは、不安定さを生み出す原因となるため避ける。また
    データスキーマやデスクリプションに適合しないデータを取り除く。データ分布
    に偏りがある場合はサンプリング手法の検討も行う(アップサンプリングなど)
    2
    Clean Data
    データを前処理して整える
    ノイズのフィルタリングや欠損値の補完など、データをきれいにする
    3
    Construct Data
    データを構築する
    特徴量エンジニアリングや次元削減などを実施し、特徴量を作成する。さらに
    データオーギュメンテーションを必要に応じて実施する
    4
    Standardize Data
    データを標準化する
    正規化などの標準化を実施する。この際、標準化パイプラインは訓練データで
    作成されたものを、推論時にも使用するように注意する
    Studer, Stefan, et al. "Towards CRISP-ML (Q): a machine learning process model with quality assurance methodology."Machine Learning and Knowledge Extraction3.2 (2021): 392-413. [link]
    CRISP-ML(Q)の各要素内容 その3

    View full-size slide

  67. 67
    [3] Modeling(MLモデル構築)
    Studer, Stefan, et al. "Towards CRISP-ML (Q): a machine learning process model with quality assurance
    methodology." Machine Learning and Knowledge Extraction 3.2 (2021): 392-413. [link]
    No. 内容 実行方法
    1
    Define quality measures of the model
    モデルの品質評価手法を決定する
    Performance、Robustness、Scalability、Explainability、Model
    Complexity、Resource Demandの観点からモデルの品質評価手法を決
    定する
    2
    Model Selection
    モデリング手法を選択する
    先行事例などを参考にモデリング手法を選択する。モデルにはドメイン知識を
    含めるのが良いが、適切であることに注意する。
    3
    Model training
    モデルを訓練する
    モデルを訓練する。この際、クロスバリデーションなどを用いて過学習を避ける
    ようにする。また訓練後、必要に応じてモデルサイズの圧縮なども行う
    4
    Assure reproducibility
    訓練済みモデルの再現性を確認する
    特徴量エンジニアリングや次元削減などを実施し、特徴量を作成する。さらに
    データオーギュメンテーションを必要に応じて実施する
    5
    Experimental Documentation
    モデリング過程をドキュメントに残す
    モデリングの試行錯誤の過程や最終状態をきちんとドキュメントに残す
    CRISP-ML(Q)の各要素内容 その4

    View full-size slide

  68. 68
    [4] Evaluation(評価)
    No. 内容 実行方法
    1
    Validate performance
    モデルの性能を検証する
    検証データセットでモデルの性能を確認する
    2
    Determine robustness
    モデルのロバスト性を確認する
    モデルのロバスト性について確認する
    3
    Increase explainability for ML
    practitioner & end user
    モデルに説明性を追加する
    モデルのローカルとグローバルな説明性・解釈性について確認できるようにす

    4
    Compare results with defined success
    criteria
    成功基準とモデルの結果を比較する
    はじめに定めたモデルの成功基準と実際の性能結果を比較する
    5
    Experimental Documentation
    モデルの評価結果をドキュメントに残す
    モデリングの試行錯誤の過程や最終状態をきちんとドキュメントに残す
    Studer, Stefan, et al. "Towards CRISP-ML (Q): a machine learning process model with quality assurance methodology."Machine Learning and Knowledge Extraction3.2 (2021): 392-413. [link]
    CRISP-ML(Q)の各要素内容 その5

    View full-size slide

  69. 69
    [5] Deployment(展開)
    No. 内容 実行方法
    1
    Define inference hardware
    推論インフラの環境を計画する
    推論を実行するインフラ環境、ハードウェア環境を決定する。また監視・運用の
    設計や体制についても決定する
    2
    Model evaluation under production
    condition
    実環境でモデルを検証する
    モデルの性能が訓練時に検証した通りか、実環境での性能を確認する。成功基
    準のMLモデルの成功基準だけでなく、ビジネス目標の成功基準も満たすかを
    実環境で確認する
    3
    Assure user acceptance and usability
    UXが想定通りか検証する
    MLシステムのUXが想定した通りになっているか、ユーザー相手に検証する
    4
    Minimize the risks of unforeseen errors
    想定外のエラーに対する対応手順を用意する
    想定外の未知のエラーに遭遇した際の対処方法として、例えばモデルやシステ
    ムのロールバックを可能にしておく、MLモデルの代替となるモジュールを用意
    するなどして、システムのダウンタイムが最低限になるように準備しておく
    5
    Deployment strategy
    安全性の高いデプロイ戦略を遂行する
    MLシステムのMLモデルを一気に新しく置き換えるのではなく、カナリアリリー
    スなどの安全性の高いデプロイ戦略で、本番環境へのデプロイを実行する
    Studer, Stefan, et al. "Towards CRISP-ML (Q): a machine learning process model with quality assurance methodology."Machine Learning and Knowledge Extraction3.2 (2021): 392-413. [link]
    CRISP-ML(Q)の各要素内容 その6

    View full-size slide

  70. 70
    [6] Monitoring and Maintenance(監視と保守)
    No. 内容 実行方法
    1
    Monitor
    本番環境のデータ特性の変化を監視する
    本番環境のデータ特性(範囲、分布)などが訓練データから乖離しはじめていな
    いかを監視する
    2
    Update
    MLモデルを再学習する
    MLモデルを再学習したり、新たなデータでファインチューニングしたりする。再
    学習後には前のモデルと性能を比較するようにする。モデルの再学習において
    は、MLシステムがフィードバックループを形成していないかに注意する。モデ
    ルの推論結果が、新たな訓練データに影響を及ぼしている場合にはMLシステ
    ムが不安定になる可能性がある点に注意する
    3
    Maintenance
    本番環境の保守を実施する
    例えば、本番環境で使用しているハードウェア、センサなどの劣化がないかを
    確認し、必要に応じて保守する
    Studer, Stefan, et al. "Towards CRISP-ML (Q): a machine learning process model with quality assurance methodology."Machine Learning and Knowledge Extraction3.2 (2021): 392-413. [link]
    CRISP-ML(Q)の各要素内容 その7

    View full-size slide

  71. 71
    CRISP-ML(Q)をベースとした品質評価観点
    04

    View full-size slide

  72. 72
    ※以下の図は発表者ら記す
    CRISP-ML(Q)をベースとした品質評価観点
    [1] Business and Data Understanding(ビジネスとデータ理解)
    CRISP-ML(Q)

    View full-size slide

  73. 73
    No. 要求・要件(機能要件、非機能要件) テスト観点 テスト内容 出典
    1.1.1
    AIの必要性の検討
    AIを活用することが、ビジネスゴール達成
    に本当に必要で最適か検討する
    要求管理
    Requirement
    Management
    AI活用時のビジネスインパクト(利益増減額、節約
    可能時間)をMLモデルの性能に応じて、数式で表
    す。とくにMLモデルが完璧だった場合のインパクト
    をまず計算すること
    Quality
    Management of
    Machine
    Learning
    Systems, 2020.
    1.5.1
    準備済みデータの検討1
    プロトタイプモデルを構築するだけの量と質
    の両面を満たすデータが存在しているか
    データ
    >品質
    >>均質性
    モデル構築時の検証にクロスバリデーション
    (k=5)を使用し、性能評価指標に大きなばらつき
    が存在しないかを確認する
    Quality
    Management of
    Machine
    Learning
    Systems, 2020.
    1.5.2
    準備済みデータの検討2
    プロトタイプモデルを構築するだけの量と質
    の両面を満たすデータが存在しているか
    データ
    >品質
    >>均質性
    検証データのとある集団、例えば映画データを扱う
    場合は特定ジャンルの映画のみなど、目的変数の
    特定の値の集団のみを取り出して性能を確認し、グ
    ローバルな性能と著しく変化しないかを確認する
    The ML Score,
    2017
    CRISP-ML(Q)をベースとした品質評価観点
    [1] Business and Data Understanding(ビジネスとデータ理解)
    No. 内容 実行方法
    1.1
    Define the Scope of the ML Application
    MLシステムのスコープを決定する
    MLシステムが満たすべきスコープ(ビジネス面、ML面)を定める。その際、ビジ
    ネスの人間、研究者、データエンジニアが揃った状態で進め、十分な量のデータ
    が存在するかなどにも注意する
    ・・・
    今回の発表は以上となります。今後の機会にて。6フェイズ、29項目を「要求・要件」→「テスト観点」→「テスト内容」

    View full-size slide

  74. 74
    ご清聴いただき、ありがとうございました

    View full-size slide

  75. CONFIDENTIAL

    View full-size slide