【論文メモ】Challenges in Deploying Machine Learning
(Zennのタイトル文字数制限にひっかかってしまったのでタイトルを一部省略)
公開されている情報を基に機械学習をデプロイする上での課題をまとめたサーベイ論文。
うまく要約したかったのですが、トピックが多岐にわたり、圧縮率は低めです。
論文では機械学習における各ステップの課題を下図のようにまとめている。
Data management
機械学習ソリューションの有効性はアルゴリズムと同様にデータに依存する。
このセクションではデータ管理における問題を取り扱っている。
Data collection
データ収集とは、どのようなデータがあるのか、また、どのように便利なストレージを構築していくのかを模索し、理解するための活動。
特に大規模なプロダクション環境では、どのようなデータがどこにあるのかを発見すること自体が困難な場合がある。
データソースを見つけ、その構造を理解することは大きな課題であり、これが解決されないとデータサイエンティストは実際のアプリケーション開発に着手することすらできない。
Twitterでは、複数のサービスが互いに呼び出し合い、同一エンティティ（例：Twitterユーザー）を処理しているため、このような状況がしばしば発生している。
このアプローチはスケーラビリティや変更の面で非常に柔軟なアーキテクチャであるが、裏返しとして、大規模な場合、エンティティに関連するどのデータがどのサービスによってどのような形で保存されているかを把握することが不可能になる。また、データの中にはログという形でしか存在しないものもあり、その性質上、解析やクエリが容易ではない。さらに悪いのは、データがどこにも保存されておらず、データセットを構築するためには、サービスのAPIコールが必要になる場合。このようなデータの分散・散乱は、データサイエンティストにとって大きなハードルとなる。
Data preprocessing
通常、前処理段階では、欠損値の入力、データの順序付けと簡略化、生データからより便利なフォーマットへのマッピングなど、さまざまなデータクリーニング作業を行う。
あまり知られていない問題として、前処理の対象となる重要な問題にデータの分散・散乱がある。
複数の関連する個別のデータソースが存在することがよくある。これらのデータソースは、異なるスキーマ、異なる規約、データの保存、アクセス方法を持っている可能性がある。
これらの情報を機械学習に適した1つのデータセットに結合することは、それ自体が複雑な作業になる。
この例として、Firebirdの開発者が直面した問題がある。Firebirdは、アトランタ消防局の諮問システムで、火災検査の優先対象を特定するのに役立つシステムである。Firebird開発の第一歩として、火災事故の履歴、ビジネスライセンス、世帯など12のデータセットからデータを収集した。これらのデータセットを結合して、消防局が監視している各物件に関連するすべての側面をカバーする単一のデータセットを作成した。
下記の論文の著者は、データの結合が難しい問題であったことを特に強調しており、建物の位置がその建物を特定するための最良の方法であるという事実を踏まえ、各データセットには建物の住所を示す空間データを含ませた。空間情報は異なるフォーマットで表示されることがあり、綴りの違いなど細かい違いがあることもある。そのため、これらのデータを整理・修正する必要があり、これには膨大な時間がかかったとしている。
Data augmentation
データを増強する必要がある理由はいくつかあるが、実際に最も問題となっているのはラベルデータが少ないことである。
実世界のデータはラベルが付いていないことが多く、ラベル付けはそれ自体が課題となっている。
ここでは、ラベル付きデータが少ない要因として、「専門家へのアクセスが限られている」、「高分散データが存在しない」、「データ量が膨大」の3つを挙げている。
高品質のラベルを収集するためには、専門家へのアクセスがボトルネックになるケースもある。
これは、医療画像解析のように、ラベリング・プロセスに専門知識が必要になる分野で特に顕著である。
通常、複数の専門家に画像のラベル付けを依頼し、そのラベルを集約して品質を確保する。しかし、大規模なデータセットでは専門家の数が限られているため、この方法はほとんど実行されない。
ノイズの多いラベルは最終的なモデルの精度に影響することが考えられるが、このような損失は、わずかなエラーでも致命的な結果を招く可能性があるヘルスケア業界では受け入れられにくい（これは「The Final Percent Challenge」として知られている）。
高分散データへアクセスができないことは、機械学習ソリューションを研究室環境から実世界にデプロイする際に直面する主な課題の1つ。
強化学習などでめったに発生しないデータを利用できない（低分散データ）ことで、実運用が難しくなるケースがある（例：安全でない状況で正しい判断ができるよう訓練されていない自動運転車など）。
ネットワークトラフィック分析のように、ダウンサンプリングしてもデータ量が膨大で、ラベル付けのためにサンプリングされた各パケットを追跡する必要がある場合、ラベル付けは現実的ではなくなる。
Data analysis
データに潜在する偏りや予想外の分布を明らかにするためには、データを分析する必要がある。
あらゆる種類のデータ分析を行うためには、高品質なツールの利用が不可欠。
この点で実務家が特に困難を感じている分野の一つが、データプロファイリングであり、欠損値、データタイプの不整合、仮定の検証など、データ品質のトラブルシューティングに関連するすべての活動を指す。
データサイエンティストがデータの問題が作業全体の品質に影響する主な理由としていることを考えると、このようなツールの必要性は明らかである。
Model learning
モデルの学習は、機械学習のデプロイワークフローの中でも、もっとも注目されているステップであるが、まだまだ現実的には検討すべきことがたくさんある。
このセクションではモデルの学習における問題を取り扱っている。
Model selection
多くの実用的なケースでは、モデルの選択は、モデルの1つの重要な特性である「複雑さ」によって決定されることが多い。
深層学習や強化学習のような分野が研究コミュニティで人気を博しているにもかかわらず、実際にはより単純なモデルが選択されることが多い。
シンプルなモデルでは、機械学習ソリューションの導入までの時間が短縮され、重要なフィードバックを収集することができ、また、複雑すぎる設計を避けることができる。
Airbnbの検索サービスでは、機械学習を適用する過程でチームは複雑な深層学習モデルから始めた。チームはすぐにその複雑さに圧倒され、結局、開発サイクルを消費してしまった。
何度かデプロイに失敗した後、ニューラルネットワークのアーキテクチャは大幅に簡素化され、単一隠れ層のニューラルネットワークとなった。
このようなシンプルなモデルであっても、本番環境にMLモデルをデプロイするためのパイプライン全体を構築することができ、かつ適度なパフォーマンスを発揮するという点で価値があった。
時が経つにつれ、モデルは2つ目の隠れ層を追加して進化していったが、それでも当初意図したレベルの複雑さには至らず、かなりシンプルなままであった。
複雑でないモデルのもう一つの利点は、必要なハードウェアが比較的少なく済むことである。
リソースに制約のある環境では、この点が重要な判断材料となる。
Europa Clipper宇宙船に搭載された様々な科学機器へのMLモデルのデプロイに向けたプロジェクトでは、宇宙船の総重量、堅牢性、搭載される科学機器の数の間で常にトレードオフの関係があった。
そのため、計算機資源は限られており、その使用量はできる限り少なくしなければならない。
このような要求に応えるには、当然ながら計算負荷の軽いモデルが好まれる。
Europa Clipperのチームは、3つの異常検知タスクに機械学習を使用した。あるモデルは時系列データを入力とし、あるモデルは画像を入力としたが、3つのケースではいずれも単純な閾値またはPCAベースの技術が実装された。
これらの手法が選ばれた理由は、そのロバストなパフォーマンスと計算能力への要求が低いことにあった。
リソースに制約のある環境の例としては、無線セルラーネットワークもある。ここでは、エネルギー、メモリ消費、およびデータ転送が非常に制限される。
深層学習などの高度な技術は、高次元のモバイルネットワークデータを扱うことができるにもかかわらず、実用的なデプロイについてはまだ検討されていない。
モデルの出力を理解可能なビジネス・ドメイン用語に解釈できるかどうかは、モデルの選択において重要な役割を果たしており、性能面での検討を上回ることもある。
そのため、基本的なMLアルゴリズムと考えられる決定木は、実際に広く使用されている。
しかし、深層学習（DL）は、過去に取得した大量のデータを分析する必要がある実用的なバックグラウンドタスクによく使用されている。
この概念は、無人航空機（UAV）の分野で例示されている。
イメージ・センサは、低コスト、軽量、低消費電力であるため、UAVでは一般的であり、センサーから取得した画像を処理することは、DLが提供する生データの処理に関する優れた能力を活用する主な方法である。
しかし、UAVにDLを搭載してオンライン処理を行うためには、計算機資源の確保が大きな課題となる。
Training
モデルの学習に関する最大の懸念事項の一つは、目的を達成するために必要な経済的コストである。
これは自然言語処理（NLP）の分野では特に当てはまる。
下記の論文は、個々の浮動小数点演算のコストは低下しているものの、NLPの学習にかかる全体的なコストは増加する一方であると述べている。
著者らは、この分野の最先端モデルの1つであるBERTを取り上げ、選択したモデルのサイズに応じて、完全なトレーニングプロセスに5万ドルから160万ドルのコストがかかることを発見した。
彼らは、トレーニングデータセットのサイズ、モデルパラメータの数、トレーニングプロセスで使用される演算の数、これらすべてが全体のコストに貢献していると述べている。
ここで特に重要なのは、モデルパラメータの数の要因である。新しいNLPモデルは、すでに何十億ものパラメータを使用しており、この数は近い将来さらに増加すると予想されている。
これに関連して、下記の論文ではMLモデルのトレーニングが環境に与える影響を懸念している。
MLモデルのトレーニングは、より多くの計算資源を消費することで、エネルギー消費量と温室効果ガス排出量を増加させている。
この論文での試算によると、NASを利用した1回の学習サイクルは、平均的な自動車4台が生涯に排出する量に匹敵するCO2を排出するとしている。
著者らは、研究者がこのようなモデルトレーニングの影響を認識することがいかに重要であるかを強調し、コミュニティは計算効率の高いハードウェアやアルゴリズムをより優先的に採用すべきであると主張している。
Hyper-parameter selection
多くのMLモデルでは、学習プロセスで獲得されるパラメータに加えて、いくつかのハイパーパラメータを定義する必要がある。
ハイパーパラメータ最適化（HPO）は、ハイパーパラメータの最適な組み合わせを選択するプロセスであり、ほとんどのHPO技術は、MLモデルの複数のトレーニングサイクルを必要とする。
また、HPOタスクのサイズは、新しいハイパーパラメータを追加するごとに指数関数的に増大する。
これらの考慮事項により、HPO技術は、特に深層学習のアプリケーションにおいて、実際には非常に高価でリソースが重たいものとなっている。Hyperbandやベイジアン最適化のように、必要な学習サイクル数を最小化するために特別に設計されたアプローチであっても、モデルの複雑さやデータセットの大きさのために、問題に対処することはできていない。
また、HPOでは、モデルが実行される環境によって課される特定の要件を考慮する必要がある場合もある。
このことは、下記論文が例示しており、モデルを組み込みデバイスやモバイル機器にデプロイするためには、そのような機器に課せられるエネルギーやメモリの制約を十分に考慮する必要がある。このため、モデルの精度とハードウェアの効率性を両立させ、カスタマイズされたハードウェアを考慮した最適化技術が必要となる。
Model verification
機械学習モデルは合理的な処理や堅牢性などを満たす必要があり、モデル検証の目標は多面的であると述べている。
Requirement encoding
機械学習モデルの要件を定義することは、テスト活動の重要な前提条件である。
Booking.comが150のモデルを本番環境に導入した後に発見したように、モデルのパフォーマンスの向上がビジネス価値の向上につながらないことがよくある。そのため、KPIやその他のビジネス上の指標など、より具体的な測定基準を定義して測定する必要がある。
Booking.comの場合、そのような測定基準には、コンバージョン、カスタマーサービスチケット、キャンセルなどが含まれていた。このようなメトリクスを定義するためには、モデリング、エンジニアリング、ビジネスの観点からの理解が必要となるため、学際的な取り組みが必要となる。一度定義された指標は、本番環境のモニタリングや、モデル更新の品質管理に利用される。
また、単にMLモデルの精度を測定するだけでは、そのパフォーマンスを理解するには不十分で本来、パフォーマンス指標は、それを視聴する人たちの優先順位を反映したものでなければならない。
Formal Verification
形式的な検証ステップでは、モデルの機能がプロジェクトの範囲内で定義された要件に従っているかどうかを検証する。
このような検証では、数学的な正しさの証明や、出力誤差範囲の数値的な推定などが含まれるが、実際にはほとんど行われていない。多くの場合、品質基準は広範な規制の枠組みを介して形式的に設定されている。
MLソリューションが規制に従わなければならない例として、銀行業界が挙げられる。
この要件は、世界的な金融危機の後に策定されたもので、業界は機械学習モデルに対する精査の必要性を認識していた。
その結果、モデルの構築、承認、維持を定義するプロセスに、より高度な規制が適用されるようになった。例えば、英国のPudential Regulation AuthorityとEuropean Central Bankが公式なガイドラインを発表している。これらのガイドラインでは、すべてのビジネス意思決定ソリューションにモデルリスクフレームワークを導入することが求められており、このようなフレームワークを実装するためには、開発者はMLモデルの動作を理解するために大規模なテストを行う必要がある。
この文脈での正式な検証ステップは、モデルが対応する規制で設定されたすべての基準を満たしていることを確認することを意味する。
Test-based Verification
テストベースの検証は、モデルが以前に見たことのないデータに対してうまく一般化できるかどうかを確認することを目的としている。
検証データセットの収集は、トレーニングデータセットを分割して得られるため、通常は問題ないが、本番環境への導入には十分でない場合がある。
理想的なシナリオでは、テストはビジネスに直結した指標が観察できる実環境で行われる。しかし、実環境での本格的なテストは、安全性、セキュリティ、規模など様々な理由から困難であり、多くの場合、シミュレーションによるテストで代用されている。
自律走行車を制御するモデルの場合、シミュレーションはコストが安く、実行速度が速く、実世界ではほとんど遭遇しない状況を作り出す柔軟性を備えている。このような利点があるため、この分野ではシミュレーションが普及している。しかし、シミュレーションに基づくテストは、シミュレーション開発者の仮定に依存しているため、実世界のテストを完全に代替するものではないことを覚えておく必要がある。シミュレーションと実世界との間のわずかな違いでも、システムの動作に大きな影響を与える可能性があるため、シミュレーション環境の検証だけでは不十分である。
この点は、エージェントのトレーニングにシミュレーションを使用することがデファクトスタンダードとなっている強化学習の分野での経験でも強調されている。
さらに、データセット自体も、データのエラーがパイプラインに入り込まないように、また全体の品質に影響を与えないように、常に検証する必要がある。
下記論文は、データの問題が気づかれない最も一般的なシナリオの1つは、データ生成がMLパイプラインから切り離されている状況であると主張している。このような問題が発生する原因には、コードのバグ、フィードバックループ、データの依存関係の変化などがある。データエラーは、パイプラインの様々な段階で伝播し、顕在化する可能性があるため、MLパイプラインにデータ検証ルーチンを組み込むことで、早期に問題を発見することが重要になる。
Model deployment
本番環境で稼働する機械学習システムは、長期間にわたって保守しなければならない複雑なソフトウェアシステムである。そのため、開発者には、通常のソフトウェアサービスの運用と共通するものや機械学習に特有のものなどさまざまな課題があると述べている。
Integration
モデル統合のステップは、モデルを実行するためのインフラ構築と、モデル自体を消費・サポート可能な形で実装することの2つの主要な活動で構成されている。
ソフトウェア工学で日常的に使われている多くの概念が、MLの文脈で再構築されており、ソフトウェア工学で一般的なトピック（コード再利用など）をMLに取り入れることはメリットがある。
Pinterestでは、画像の埋め込み表現を学習する際に類似した埋め込みを使用するモデルが3つあり、当初はモデルを個別に繰り返すことができるように、完全に別々に管理していた。
しかし、この方法では、これらの埋め込みを扱うための労力を3倍にしなければならず、エンジニアリング上の課題があった。そこでチームは普遍的な埋め込みを学習できるかどうかを検討した。結果的に、この再利用は個々のタスクのパフォーマンスを向上させるだけでなく、デプロイパイプラインを簡素化することにもつながった。
下記論文では、機械学習の実践者が現在直面している工学的問題が幅広く示されている。
それらのほとんどは、エンジニアリングではアンチパターンと考えられているが、現在、機械学習ソフトウェアでは広まっているものである。これらの問題の中には、abstraction boundaries erosionやcorrection cascadesのように、ソフトウェアが外部データに明示的に依存しなければならない場合にMLが使用されていることに起因するものがある。
また、グルーコードやパイプラインジャングルのような問題は、汎用的なソフトウェアパッケージを開発するこの分野の一般的な傾向に起因するものである。これは、通常のソフトウェアシステムが必要とするすべての設定に加えて、かなりの数のML固有の設定が追加され、それらを維持しなければならないことに起因している。
研究者とソフトウェアエンジニアは、機械学習を用いてビジネス目標を達成することを目的とした同じプロジェクトで一緒に働くことがよくある。研究者はモデルを作成し、エンジニアはそれを実行するためのインフラを構築するというように、表面的には明確な責任分担がなされているように見えるが、実際には、開発プロセス、モデルの入出力、性能評価基準などを考慮すると両者の関心事はしばしば重なり合っている。
両方の役割を担うコントリビュータは、同じコードを扱うことが多い。そのため、研究者を全ての開発工程に参加させ、エンジニアと一緒に製品のコードベースを所有し、同じバージョンコントロールを使用し、コードレビューに参加させることが有益である。明らかにオンボーディングやスロースタートの課題があるにもかかわらず、このアプローチは、製品提供のスピードと品質の面で長期的な利益をもたらすと見られている。
Monitoring
モニタリングは、機械学習システムのメンテナンスに関連する問題の1つである。コミュニティは、モニタリングすべきデータやモデルの主要な指標は何か、またそれらをどのように警告するかを理解する初期段階にある。進化する入力データ、予測の偏り、MLモデルの全体的なパフォーマンスの監視は、未解決の問題である。
データ駆動型の意思決定に特有のもう一つのメンテナンス問題は、フィードバックループである。
運用中のMLモデルは、定期的な再トレーニングによって、時間の経過とともに自らの挙動に影響を及ぼすことがある。モデルを最新の状態に保つ一方で、モデルの動作に影響を与えるためにモデルへの入力が調整されるというフィードバックループを作ることが可能である。これは、意図的に行われることもあれば、不意に起こることもあり、MLシステムを運用する際の固有な課題となっている。
下記論文は、本番環境で使用できないモデル予測にフラグを立てるための重要な手段として、異常値検出の重要性を指摘している。
著者らは、このような予測が発生する理由として、モデルが学習データセット以外の場所で一般化できないことと、キャリブレーションが不十分なために分布外のインスタンスを過信して予測してしまうことの2つを挙げている。異常値検出器の導入は、ラベル付き外れ値データが不足しているため、それ自体が課題となる。異常値検出器の学習は、半教師付き、あるいは教師なしの問題となることが多いと述べている。
MLシステムのモニタリングについては、下記論文に詳しい情報がある。
この論文では、米国の2つの警察署における早期介入システム（EIS）について述べている。表面的には、彼らの監視目的は完全に標準的なものに見え、データの整合性チェック、異常検知、パフォーマンス測定などある。
これらのタスクには、すぐに使えるツールあると期待されていたが、著者らは、モデルのパフォーマンスを良好に保つために、これらのチェックをすべてゼロから構築しなければならなかったと説明している。
例えば、データの整合性チェックでは、特定の入力テーブルの更新と過去の記録のチェックサムを検証し、パフォーマンス指標は上位k個の出力の変化数で定義し、異常は時系列の相関関係で追跡した。これらの監視ツールはすべて、かなりの調査と実装が必要であった。
この経験談は、現在入手可能なエンド・ツー・エンドのMLプラットフォームに共通する問題点を浮き彫りにしている。つまり、MLソリューションは、問題の特殊性に非常に敏感であるため、すぐに使えるツールはそのニーズにうまく適合しないのである。
Updating
モデルの初期デプロイが完了しても、データや環境の最新の傾向を常に反映させるために、後からモデルを更新することが必要になることがある。モデルを新しいデータに適応させるには、定期的な再トレーニングや継続的な学習など、複数の手法がある。
しかし、本番環境でのモデルの更新は、実用上の問題にも影響される。モデル更新手順の質と頻度に直接影響する特に重要な問題はコンセプトドリフトである。MLにおけるコンセプトドリフトとは、Xをモデル入力、yをモデル出力としたときの同時分布p(X, y)に見られる変化と理解される。
この現象が検出されないと、モデルの性能に大きな悪影響を及ぼす可能性がある。
コンセプトドリフトは様々な理由で発生する。例えば、2008年の金融危機の際、金融業界は激動の変化に直面したが、もし高度な検出技術が採用されていれば、進行中の危機に対する追加的な洞察が得られたかもしれない。
コンセプトドリフトは何十年も前から知られていたが、今日のMLのアプリケーションにとって依然として重要な問題である。
モデルを最新の状態に保つためにいつ再学習するかという問題に加えて、モデルの成果物をどのように本番環境に提供するかというインフラ上の問題もある。ソフトウェアエンジニアリングでは、このようなタスクは継続的デリバリー（CD）で解決するのが一般的である。CDは、ソフトウェアの変更をビルド、テスト、デプロイするための自動化されたパイプラインを構築することで、開発サイクルを加速するためのアプローチである。
しかし、機械学習ソリューションのCDは複雑である。なぜなら、コードにのみ変更が生じる通常のソフトウェアプロダクトとは異なり、MLソリューションでは、コード、モデル、データの3つの軸に沿って変更が生じるためである。ML用のCDを構築する試みとしては以下の論文がある。
Cross-cutting aspects
このセクションの内容はデプロイパイプラインの全てのステップに影響を与える可能性があるトピックである。
Ethics
倫理的配慮は、常にデータ収集活動に反映されるべきである。
Alan Turing Instituteが作成した倫理的なAIに関する報告書で述べられているように、「AIプロジェクトのワークフロー全体において、人間の責任の継続的な連鎖を確立することが不可欠である」。研究者や開発者がこの推奨に従わない場合、政府の規制違反、正当化できない結果、既存の問題の悪化など、さまざまな理由で複雑な事態が発生する可能性がある。
様々な国で、個人情報を保護するための規制が作られており、個人から収集した情報の機密性が高ければ高いほど、その使用に関する規制は厳しくなる。
そして、最もセンシティブな情報を扱う業界は医療である。
下記論文では、多くの国では、患者のデータを保護するための厳しい法律が制定されており、医療分野でのMLの導入を特に困難にしていると述べている。
そのような規制の例としては、欧州連合の一般データ保護規則や、アジアの様々な国の倫理的スクリーニング法などがある。これらの規則は、人々が安心して自分のデータが使用されるようにするために絶対に必要であることは間違いない。一方で、レビュー、ソフトウェアの更新、データ収集・アノテーションのサイクルが必要となるため、MLの技術的進歩に追従することは非常に困難となっている。
DeepMindとRoyal Free NHS Foundation Trustが、重篤な疾患の検査結果を自動的にレビューするアプリケーションであるStreamsの開発に取り組んでいるときに発見したように、企業はソリューションの技術的側面だけに焦点を当てるべきではない。最初の共同研究では、患者データの使用や患者の関与全般に関して十分な具体性がなかったため、データ保護規則の遵守に関する調査が行われた。改訂された共同研究契約では、データが倫理的に使用されていることを確認するために、患者と一般市民の関与を含む、はるかに包括的な内容になっている。
犯罪者の「リスクスコア」を算出するモデルは、人間のバイアスを取り除く方法として販売されていることがある。
しかし、これらのモデルには、一見すると中立的な人口統計情報を使用されており、それが代理として機能してしまい、特定の人種や収入の人に不利益が発生することがある。
同様に、下記論文では災害リスク管理（DRM）分野にMLを適用する際の主な懸念事項の1つとして、偏った訓練データセットの使用による社会的不平等の悪化を挙げている。さらに、MLは以前は別々だったデータセットを組み合わせることで、プライバシーやセキュリティの問題を引き起こす可能性があると主張している。
これらの問題のいくつかは、Fairness in MLとして知られる機械学習の分野で研究されている。
下記論文が議論しているように、創造的な芸術の分野でのMLの使用には、興味深い倫理的側面がある。学習されたモデルが視覚的な芸術作品の作成に使用された場合、その作品の著作権がどこにあるのかは完全には明らかになっていない。したがって、オリジナリティの問題には特別な注意が必要である。
この問題と密接な関係があるのは、MLで生成された偽のコンテンツが誤った目的で容易に使用されることへの懸念の高まりである。
機械学習が遭遇する倫理的問題のもう一つの側面は、データに基づく意思決定である。
機械学習ツールが重要な意思決定プロセスに利用されるようになると、その利用に関する倫理的懸念が高まる。下記論文のEMBERSと呼ばれる市民の不安を予測するシステムは、予測とコミュニケーションのツールとして使用するように設計されているが、著者は、社会におけるその役割を誤解したり、または意図的に政府が誤用する可能性もあると指摘している。
End users’ trust
MLは、エンドユーザから慎重な反応を示されることが多い。
モデル自体は最小限の説明しかしないので、エンドユーザにその有用性を説得することは困難となっている。エンドユーザにMLベースのソリューションを信頼してもらうためには時間を費やす必要がある。
あるアプリケーションに明確に定義された利用者がいる場合、これらの人々をプロジェクトの初期段階で参加させることは、最終製品に対する彼らの信頼を高めるための効率的な方法である。
このようなアプローチは、医療分野では一般的である。
その一例として、「Sepsis Watch」というプロジェクトがある。
このプロジェクトは、患者の敗血症発症リスクを推定するモデルを構築することが目的で、初めての試みではなく、以前に失敗したとみなされていたため、医療従事者はSepsis Watchの成功に懐疑的であった。この疑念を払拭するために、チームは次の方法で信頼関係を築くことを優先した。
- 強力なコミュニケーションチャネルを構築する。
- 技術的な進歩を示すのではなく、目標達成に向けた進捗状況をステークホルダーと共有する。
- 公的機関や外部への説明責任を果たすためのメカニズムを確立する。
- プロジェクトの初期段階で、第一線の臨床医と経営層レベルの意思決定者の両方を関与させる。
この研究の重要なメッセージの一つは、モデルの解釈可能性は信頼構築ツールとしては限界があり、エンドユーザーから高い信頼を得るためには他の方法を検討すべきであるということである。
議論の余地があるように聞こえるかもしれないが、実際には「Project explAIn」によってなされた結論と一致している。AIの意思決定に関する説明能力の相対的な重要性は、文脈によって異なることがわかっている。
Security
MLに特化した敵対的な攻撃は、モデル自体、学習に使用されるデータ、さらには結果として得られる予測に対して発生する可能性がある。敵対的機械学習の分野では、MLモデルに対するこのような攻撃の影響と、それに対する防衛方法が研究されている。
下記論文によると、産業界の実務者は、MLシステムに対する攻撃を保護、検出、対応する能力を備えていないことが分かっている。
実際に使用されているMLモデルに影響を与える最も一般的な攻撃には、データポイズニング、Model Stealing、Model Inversionの3つがある。
データポイズニングにおける攻撃の目的は、生成された結果を操作するために、学習段階でモデルの整合性を意図的に破壊することである。データポイズニングは、MLモデルが新しい学習データで継続的に更新される場合に特に有効である。
下記論文では、線形モデルを使用した医療現場で、ポイズニング率8%の特定の悪意のあるサンプルを学習データに導入したところ、患者の半数で誤った投与量になったことを報告している。
データポイズニングは、Microsoftのボット「Tay」で起こったように、フィードバックループを利用した協調的な集団活動の結果としても起こり得る。Tayは、時間の経過とともに言語の理解度が向上するように設計されており、すぐに大量の意図的に悪意のあるツイートが殺到した。公開から16時間以内に、Tayのメッセージのうち、罵倒や攻撃的なメッセージの割合が増え、ボットは削除されてしまった。
もう1つのタイプの敵対的攻撃は、（公開されている予測APIなどを介して）デプロイされたモデルの入力をクエリし、出力をモニタリングすることによるリバースエンジニアリングである。
敵対的なクエリは、代替モデルを訓練するために、モデルに関する情報を最大限に抽出するように作られる。このような攻撃は「Model Stealing」と呼ばれている。一言で言えば、この攻撃は、防御側にとって重要なビジネス上の利点である知的財産の損失につながる。
下記論文では、Google、Amazon、Microsoftが提供するMLサービス（ロジスティック回帰、決定木、SVM、ニューラルネットワークなど、さまざまなMLアルゴリズム）の実運用モデルを複製できることを示している。この研究では、同等のモデルを抽出するためのクエリ数が650～4013、時間が70～2088秒であったと報告している。
これに関連する攻撃として、「Model Inversion」がある。この攻撃の目的は、プライベートなトレーニングデータセットの一部を復元して、その機密性を破ることである。
下記論文は、予測に伴って信頼度を報告するモデルを利用することで、学習データを復元できることを示している。
下記論文では、GDPRのようなデータ保護法に準拠するための重要なステップとして、Model Inversion攻撃から保護することの重要性を強調している。
最後に
著者らは、これらのMLデプロイの課題に対処するオープンソース、商用のツール、サービスはいろいろとあるものの、何かを追加すれば新たな依存関係が追加されること、適切なツール選択における学習コストがかかることを課題として挙げている。
全体論的なアプローチとして、MLのデプロイではある程度のソフトウェア開発が必要になるが、MLプロジェクトは従来のソフトウェアプロジェクトと根本的に異なることを意識することが必要としている。主な違いは、データの発見、データセットの準備、モデルの学習、デプロイ成功の測定など独自の活動から生じる。
現代のシステムはデータ駆動型であることが多いため、アーキテクチャの原則においてデータに優先順位を付ける必要があるとし、MLプロジェクトは通常、スクラムやウォーターフォールなどの一般的に使用される管理プロセスにうまく適合しないため、ML用に特別に調整されたプロセスを検討することは理にかなっていると述べている。
そのような取り組みのひとつにTechnology Readiness Levels for ML (TRL4ML)フレームワークが挙げられている。TRL4MLは、MLと従来のソフトウェアエンジニアリングの主な違いを考慮に入れた、堅牢なMLシステムを作成するプロセスについて説明している。
ソフトウェアエンジニアリングで非常に広く行われていることは、開発者が開発プロセスのさまざまな段階で意思決定を行うのに役立つ一連のガイドラインとベストプラクティスを定義することである。これらのガイドラインは、変数名から実行環境のセットアップまで、幅広い質問に対応できる。
同様に、Googleで利用されている機械学習のベストプラクティス集では、社内のエンジニアや研究者の実際の経験から導き出されるさまざまな重要な側面について実践的なアドバイスを提供している。
全体的なアプローチはMLアプリケーションを念頭に置いて作成されているため、MLの導入が非常に簡単になる可能性がある。ただし、このようなアプローチはすべて、プロジェクトの管理と開発における現在の基準に大きな変化をもたらすため、多大な時間の投資を想定していることに注意する必要がある。
したがって、採用する前にリスクとベネフィットを注意深く評価する必要がある。
Discussion