機械学習システムが満たすべき要件について

はじめに

機械学習システムを開発する際に、機械学習モデルを中心に考慮すべき要件を自分用にまとめました。

機械学習(ML)システムのライフライクル

機械学習モデルの開発、デプロイ、運用は、以下の手順で進めます。

• 検証用モデルの開発
• オフライン評価とチューニング
  • 検証用モデルが十分な性能を満たしているか確認
    • 後述のデータサイエンス観点
  • 特徴量設計やハイパーパラメータチューニングを行う
• 商用モデルの開発
  • 各要件を満たすよう、商用環境にデプロイする用にモデルコードを書き換える
• テスト
  • 各要件を満たしているかどうか検証する
• デプロイ
• 運用
  • 実際にシステムを稼働させ、期待された性能が出ているかを監視
    • オンライン評価
  • システムに影響を与えうる項目を監視
    • 特徴量の分布や予測値の分布を確認
    • 学習や推論の時間
  • 改善点があれば、検証用モデルで改善し再検証を行う

この中で、主に評価とテストに関連する項目が次に続きます。

エンジニアリング観点の要件

主に非機能要件について記載します。

性能・効率性

事前にシステムが満たすべきサービス水準を満たしているかどうか、検証する必要があります。
MLシステムにおいては、扱えるデータ量や学習・推論に伴う時間を検討します。
特にオンラインで推論する場合、推論時間がクリティカルになるため、ストレステスト等行う必要があります。

手っ取り早く性能を上げる手段として、クラウドコンピューティングを使っている場合は、スケーリングする手段もありますが、当然コストがかかります。効率性を上げるコードレベルでの改善も必要です。例えば、学習方法を見直す、モデル圧縮を行うなどの対応が考えられます。

信頼性・可用性

障害なくシステムを稼働できるかという話ですが、MLシステムでは、主にモデルの学習や推論時にデータに異常があった場合にどうするかという話になるかと思います。

仕様に合わない異常データは、上流のデータフローで排除できますし、システム的にも対処可能です。ただし、仕様に沿ったデータを扱ってもエラーとなる場合もあります。
このような原因を事前に想定し対処することは困難です。

1レコードずつ扱うオンラインの学習であればエラー発生時に除外、オンラインの推論であればデフォルト値を定義して返したり類似属性の結果を返したりなどで対応可能です。しかし、扱うデータ量が多いと影響範囲が大きく、対応方法も慎重に検討すべきです。

アラートを出し、早期に対処できるようにすることが無難です。そして、既知の課題は、システム内で対応できると良いでしょう。

異常データが与えるモデル精度への影響は後述のロバスト性で触れます。

修正可能性

MLシステムは、モデルを定期的に改善することが前提のシステムなので、コードの修正コストは長期的に積み重なっていきます。また、新技術もどんどん取り入れられていくため、フレームワークを置き換えることもあります。

特徴量作成部分とモデル学習部分を分けたり、メンテナンス性の高いワークフローを整備することが必要です。

修正可能性を意識した設計にすることで、移植性や再利用性も挙がっていきます、

検証可能性

システムが扱うデータやモデルが出力した予測結果が機能要件を充足しているかを検証します。よいシステム設計であれば、テストコードによる検証が可能となっているはずです。

モデルの予測結果の検証については、データサイエンス観点の項で触れますが、モデルの予測結果に満たすべきサービス水準が具体的に定まっている場合は、テストケースとして追加するのが無難です。

データサイエンス観点の要件

主にオフライン評価で見る点を述べますが、運用の中で各指標をモニタリングできるようにしておくと、早期の異常検知や原因の解明に役立ちます。

精度

システムに組み込むモデルが満たすべき精度指標を目的に応じて最適なものを選択します。システムが満たすべき精度指標を設定することで、デプロイ時に十分な精度を担保し、継続的に改善していくことが可能となります。

最終的な目標は、稼働時のモデルの振る舞いをオンライン評価で監視する必要がありますが、デプロイ前は利用可能なデータを使ったオフライン評価を行います。

オフライン評価の指標としては、回帰問題ではRMSEやRMSLE、分類問題ではAccuracy、Precision、Recall、AUCなどです。

ただし、オフライン評価ではMLシステムが外部に与える効果を正しく評価できない場合もあり、オンライン評価まで行う必要があります。

汎化性能

学習・テストデータに関わらず安定した精度を出せるかを検証します。代表的な方法はクロスバリデーションです。

利用可能なデータの範囲で精度を保証することも必要ですが、トレンドによってデータの傾向が変わるのであれば、精度が落ちる前提の基、どのくらいの周期で見直しが必要なのかを検証することも重要です。

ロバスト性

MLシステムへの入力となるデータが何らかの影響によって変動した際にも、安定した精度を出すことが出来るかを検証する必要があります。

データ仕様に合わない異常であれば上流のデータフローで対処可能ですが、そうでない場合意図せずデータの分布が変化していることとなります。

意図的に以下のようなデータを作成し、安定した精度が出るのかを検証します。

• 数値へノイズを入れたり外れ値を追加する
• カテゴリ値に進出の値を追加する
• 一部のデータをオーバーサンプリング、アンダーサンプリングする

公平性

公平性は、一般的に性別や人種などによる社会的弱者への考慮の文脈として使われることが多いですが、ここではより広い意味合いとして、学習データによって生じるバイアスの解消を指すこととします。

データによるバイアスが影響を受ける可能性があり、かつそれがシステムによって悪影響を及ぼしうる属性を把握することが必要となります。

評価の際に、属性値に応じたセグメント別に、予測値の分布や評価値に問題がないことを確認することが対処法の1つです。

属性によって大きくデータの分布が異なるのであれば、属性値別にモデルを複数運用するのも1つの手段です。勿論、その分学習などに伴うコストやシステムとしての複雑性も増加するため、それらと兼ね合いで判断する必要があります。

解釈可能性

どのようにモデルが特徴量を判断し、予測結果を出力したのかを解釈できるかです。

解釈性があることで、分析者はモデルの改善の手掛かりを得ることができます。また、事業者目線からでも、モデルが及ぼしうる社会的影響やモデルの判断結果に対する社会的責任を果たすことに繋がります。

予測精度を上げるために、アルゴリズムを複雑にすればするほど、予測に伴うプロセスを人が把握することが難しくなるため、基本的には精度とトレードオフにある観点です。

参考

• Monitoring Machine Learning Models in Production
• 機械学習アプリケーションにおけるテストについて
• プロジェクトの成否を決める非機能要件を定義するには