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

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

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

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

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

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

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

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