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

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

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）などの観点を紹介し、産総研「機械学習品質マネジメントガイドライン」の理解をより深めることに寄与したいという立場にあります

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

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

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

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

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システムの品質に関する議論が本格化しました

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

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 パイプラインジャングルパターン

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 研究者とエンジニアの間の文化に起因

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 詳細説明

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 詳細説明

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 詳細説明

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 詳細説明

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

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

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

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] が、この論文のベースになっています

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 特徴量の生成コードが十分にテストされているかをチェック

20 ML Test Score 「モデル構築・訓練」（※発表では詳細説明は省略します） D. Sculleyらが提唱した ML Test Score
その２ 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]

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]

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]

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）モニタリング

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 詳細説明

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 詳細説明

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 詳細説明

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 詳細説明

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 詳細説明

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 詳細説明

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 詳細説明

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 詳細説明

32 「MLテストスコア」は各テスト項目について、「手動で実施しドキュメントに記載されている」であれば0.5点、「自動で実施され記録される」であれば1点とする。 4つの分野で各最大で7点であり、最終的なＭＬシステムのＭＬテストスコアとしては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 詳細説明

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

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

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つの切り口で整理

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つを整理）

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

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

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

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

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

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）での切り口

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

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

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]

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]

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

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

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

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]

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

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サービスで使用するコード類一式顧客受入・システムの検証・プロジェクトのハンドオフ・顧客向けプロジェクトの終了レポート開始終了

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]

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]

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）

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]

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

58 CRISP-ML(Q)の詳細 03

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

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]

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）

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

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

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]

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

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

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

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

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

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

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

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

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項目を「要求・要件」→「テスト観点」→「テスト内容」

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

CONFIDENTIAL

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

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

More Decks by AITC - DENTSU SOKEN

Other Decks in Technology

Featured

Transcript