MLシステムの生産準備状況と技術的負債の評価

機械学習（ML）は、ヘルスケアや金融から自動運転車、不正検出に至るまで、さまざまな産業やアプリケーションに革命をもたらしています。しかし、技術的負債や実稼働準備の不足など、さまざまな要因により、MLシステムを本番環境にデプロイすることは困難です。技術的負債はMLシステムにとって継続的な懸念事項であり、ソフトウェアをより迅速に提供するために行われた設計、実装、保守に関する決定の累積コストを指し、その負債は後で返済されるという約束を伴います。蓄積された技術的負債は、時間、費用、パフォーマンスの面で多大なコストを伴う可能性があります。MLにおける技術的負債の概念は、2014年にSculley、Holtらが発表した論文「Machine Learning: The high-interest credit card of technical debt」で初めて提唱されました。実稼働準備とは、MLシステムが信頼性、スケーラビリティ、保守性、セキュリティを確保するためのプラクティス、プロセス、テクノロジーの集合を指します。

「技術的負債はクレジットカードのようなものです。貯めるのは簡単ですが、返済するのは難しい。」 - Chris Granger.

MLシステムが本番環境で効果的かつ効率的に動作することを保証するためには、その実稼働準備状況と技術的負債を評価することが不可欠です。このブログでは、修正された MLシステム堅牢性スコア、 MLシステムの実稼働準備状況と技術的負債を評価するためのルーブリックであり、以下の論文から得られた知見に触発されています。「MLテストスコア：MLの実稼働準備と技術的負債削減のためのルーブリック」（Eric Breck他著）私たちが策定するMLシステム堅牢性スコアを構成するさまざまなパラメータ/カテゴリと、各カテゴリで実行できるテストについて探っていきます。

MLシステム堅牢性スコア

MLシステム堅牢性スコアは、MLシステムのための包括的な評価フレームワークを提供し、潜在的な技術的負債の問題を特定することを目的としています。スコアリングは、6つの主要カテゴリと22のサブカテゴリに分類されており、以下で詳しく見ていきます。

1. データ品質と準備
2. モデルのトレーニングとパフォーマンス
3. モデルの評価と解釈可能性
4. モデルのデプロイと監視
5. インフラストラクチャと運用
6. セキュリティとコンプライアンス

データ品質と準備

「私たちはより良いアルゴリズムを持っているわけではありません。ただ、より多くのデータを持っているだけです。」
- ピーター・ノーヴィグ（アメリカのコンピューター科学者）

ピーター・ノーヴィグのこの言葉は、MLモデルにおけるデータの重要性を的確に要約しています。MLモデルの訓練とテストに使用されるデータの品質は、その性能に直接的な影響を与え、データが関連性があり、正確で、問題領域を代表していることを確認することが不可欠です。以下に、評価の主要なサブカテゴリを示します。

1. データ品質と整合性：データは正確で、完全で、モデルの訓練に十分であり、一貫性があるか？
2. データプライバシーとセキュリティ：データは不正なアクセスや使用から保護されているか？
3. データバイアスと公平性：データは代表的でバイアスがなく、つまり、さまざまなシナリオやエッジケースを表現できるほど多様であるか？

モデルの訓練と性能

望ましい結果を達成する上で、モデルの訓練と性能の重要性はいくら強調してもしすぎることはありません。MLモデルの絶え間ない進化とデータセットの規模の増大は、それらを訓練するためのより強力なハードウェアへの需要を高めてきました。大規模言語モデル（LLM）の登場は、自然言語処理の分野の状況を一変させました。

モデルが引き続き良好な性能を発揮するためには、新しいデータで定期的に再訓練し、さまざまな種類のハードウェアをサポートするシステムを構築することが不可欠です。このアプローチを採用することで、開発者は、作成するMLモデルが最新で効率的であり、ますます複雑化し大規模になるデータセットを処理できることを保証できます。モデル性能の評価は、以下に示すいくつかのサブカテゴリに分類できます。

1. モデル性能指標：性能指標はビジネス要件と合致しているか？
2. モデルの選択とチューニング：適切なモデルが選択され、ファインチューニングされているか？
3. モデルの安定性と再現性：モデルは時間の経過とともに安定しており、再現可能か？

モデル評価と解釈可能性

一連の指標に基づいてMLモデルの性能を評価することは、正確な予測を保証するモデル評価の不可欠な部分です。一方、モデルの解釈可能性も同様に重要であり、開発者や利害関係者がモデルの内部動作を理解し、その出力に基づいて情報に基づいた意思決定を行うことを可能にします。解釈可能性が欠如していると、モデルが「ブラックボックス」と見なされ、その出力を信頼することが困難になる可能性があります。

モデルの性能を正確に評価するためには、組織は以下に示すいくつかのサブカテゴリを考慮する必要があります。

1. モデルの解釈可能性: モデルの出力は容易に理解・説明できるか？モデルは透明で公平か？
2. 特徴量の重要度と寄与度: モデルの特徴量を重要度と寄与度でランク付けできるか？
3. 評価環境: 評価データは本番データを代表しており、評価環境は本番環境に類似しているか？
4. 反実仮想の説明: モデルは反実仮想シナリオに対する説明を提供できるか？

モデルのデプロイと監視

効果的なモデルのデプロイと監視は、組織が最適なMLテストスコアを達成し、モデルが長期的に価値を提供し続けることを保証するのに役立ちます。以下のサブカテゴリを検討してください。

1. デプロイインフラストラクチャ: デプロイインフラストラクチャはスケーラブルで信頼性があるか？
2. A/Bテストと実験: モデルは制御された実験でテストおよび検証されているか？ダウンタイムがないことを保証するために、モデルのロールアウトプロセスはスムーズか？
3. 監視とアラート: ロギングインフラストラクチャは整備されているか？モデルのパフォーマンスを監視し、問題発生時にアラートを発する仕組みはあるか？
4. モデルの更新: 新しいデータや特徴量が利用可能になった際に、システムはモデルを自動的に更新するか？

インフラストラクチャと運用

トレーニングとパフォーマンスのカテゴリでインフラストラクチャについて触れましたが、インフラストラクチャはMLモデルが効率的かつ正確にトレーニングされることを保証するだけでなく、運用においても重要な役割を果たします。考慮すべきサブカテゴリは以下の通りです。

1. リソースの割り当てと最適化: リソースは効率を最大化し、コストを最小限に抑えるように割り当てられ、最適化されていますか？
2. コンテナ化とオーケストレーション: コンテナとサービスは、スケーラブルかつ効率的な方法で管理されていますか？
3. 継続的インテグレーションとデプロイメント: コードベースへの変更は、自動的にテスト、ビルド、デプロイされていますか？
4. ROI測定: MLモデルが本番環境で稼働した後、そのビジネスへの影響を測定できますか？

セキュリティ、障害対応、コンプライアンス

これは最後の、そして最も重要なカテゴリの一つであり、以下のサブカテゴリに分かれています。  

1. アクセス制御と認可: 不正アクセスから保護するために、アクセス制御と認可ポリシーが導入されていますか？
2. コンプライアンスと規制要件: システムは関連する規制や要件に準拠していますか？
3. エラー処理と復旧: MLシステムは、障害から適切に復旧し、システムのドリフトによるエラーを処理できますか？
4. データ保護と暗号化: 機密データは、転送中および保存時に保護され、暗号化されていますか？

MLシステム堅牢性スコアの算出

最終的なスコアリングには、企業は0〜4の尺度に基づいたスコアリングフレームワークを使用できます。このスコアリングフレームワークは以下の表の通りです。

1. 25未満のスコアは、MLシステムがまだ準備ができていない可能性が高く、多くの課題に対処する必要があることを意味します。
2. 25～40の範囲のスコアは、現在のシステムは適切であるものの、規模を拡大するにつれて障害点が生じ始める可能性があることを示唆しています。
3. 40以上のスコアは、堅牢で、システムが規模を拡大しても機能するソリューションであることを示します。
4. 60を超えるものは、貴社にとってクラス最高のソリューションとなるでしょう。

これらの質問に答え、テストを実施することで、MLシステムの運用準備状況を包括的に評価できるだけでなく、MLシステムの開発および展開中に発生する可能性のある潜在的な技術的負債の問題を特定できます。これらの問題を早期に特定することで、それらを軽減または排除するための措置を講じることができ、システム全体の技術的負債を削減できます。

ソフトウェアシステムと同様の技術的負債の評価

上記のスコアリングフレームワークの基礎としてMLテストルーブリックを使用していますが、MLシステムの準備状況を評価するための他のフレームワークも存在します。

1. 古いフレームワークの1つは、機械学習アプリケーションのソフトウェアテストへのアプローチで、 2007年のC・マーフィーによって提唱されました。 これは、ソフトウェアシステムと同様に、MLシステムの開発および展開全体におけるテストと検証の重要性を強調しています。このアプローチは、単体テストや統合テストなどの従来のソフトウェアテスト手法と、モデル検証やデータ検証などの専門的なMLテスト手法を組み合わせています。
2. もう1つの最近のフレームワークは、機械学習システムのための技術成熟度レベル（TRL）で、 2022年10月のA・ラビンとリーによって提案されました。TRLは、概念段階から運用段階まで、MLシステムの成熟度と準備状況を評価するための体系的かつ詳細な方法を提供します。

結論

結論として、MLシステムの運用準備状況と技術的負債を評価することは、展開と保守を成功させる上で不可欠です。MLテストスコアは、データ品質、モデル性能、評価方法、運用、監視などの側面を網羅し、これらの要素を評価するための包括的なルーブリックを提供します。機械学習システムのためのTRLやその他のフレームワークも、システムの成熟度と準備状況を補完的に評価できます。継続的な監視と保守、および徹底的なテストと検証は、技術的負債を最小限に抑え、MLシステムが運用可能な状態を維持するために不可欠です。

👉

追伸：MLシステムの無料診断をご利用ください！
MLインフラストラクチャ全体の診断にご興味がございましたら、までご連絡ください founders@truefoundry.com, 事前アンケートをお送りし、システムを理解するため、いくつか質問にお答えいただく30分間の時間を設けます。

その後、お客様と協力し、1週間以内にお客様のMLシステムの無料診断とベンチマークを提供いたします。

参考文献

1. C. マーフィー、G. E. カイザー、M. アリアス、「機械学習アプリケーションのソフトウェアテストへのアプローチ」。SEKEにて。Citeseer、2007年
2. D. スカリー、G. ホルト、D. ゴロビン、E. ダビドフ、T. フィリップス、D. エブナー、V. チャウダリー、M. ヤング、「機械学習：技術的負債の高金利クレジットカード」、SE4ML: Software Engineering for Machine Learning (NIPS 2014 ワークショップ)にて、2014年
3. A. ラビン、C. リー他、「機械学習システムの技術成熟度レベル」、2022年10月
4. エリック・ブレック、シャンチン・カイ、エリック・ニールセン、マイケル・サリブ、D. スカリー Google, Inc.、「MLテストスコア：MLの生産準備と技術的負債削減のための評価基準」、2017年