AI事故を回避するための実践的なステップ

Rogue（暴走する）AI をご存知でしょうか？典型的な例として、インターネットのコメント欄を学習させたチャットボット「Tay」があります。よくよく考えてみると、Tayはコメント欄と同じような発言を繰り返したので、取った行動に驚きはありません。AIが問題行動を起こすと必ずニュースになるので、Tay以外でも事例は事欠きません。

これらの事例は恐ろしいと同時に面白いのですが、暴走するAIに注目が集まると、データからビジネス価値を生み出す責任者（ここでは便宜上「データパーソン」と呼びます）が、もっと目立たない別のリスクに目を背けている可能性があります。それは、「AI事故」です。

AI事故とはいったい何なのか？それには2つの意味があります。

1. 構築していたAIが偶然暴走してしまう場合（AIを構築している認識はあった）
2. 構築していたものが偶然AIとなり、事故につながる場合（構築時点ではAIではなくもっとリスクの低いもの、と思っていた）

これまで、AIを構築するために多種多様な作業を実施してきた人からすれば、このような事故が起こることは不思議に思えるかもしれません。プロジェクトは常に明確に定義されたビジネスニーズから始まり、データの収集と準備、モデルのトレーニングと結果を比較し、性能と公平性など他の重要な検討事項との間で適切なバランスが取られているはずです。

Dataikuのようなコラボレーションを促すプラットフォームで構築されたAIではそうかもしれませんが、世の中に存在するAIの多くが常にそのように構築されているというわけではないのです。

現代のAIは、規模と複雑さに違いはあるものの、数十年前に開発された機械学習の古典的な回帰手法などと同じ仕組みの上に開発されています。つまり、基本的な問題は変わっていません。学習範囲外への外挿ができないこと、統計的に正しいモデル適合を得るには学習データが少なすぎること、相関と因果関係の問題が解釈の可能性を阻害していること、などです。

２つの例を考えてみましょう。

1. 中欧のある銀行は、ストレステストに合格するためのリスクモデルを必要としていました。このモデルは、20年前にルールベースのシステムとしてスタートし、10年前に新たに考慮すべき変数とデータソースがモデルに追加されました。このモデルは規制当局から、設計された目的に対して「適合」と判断されました。これと並行して、こうしたストレステストの開発により、新たな予測バランスシートが作られ、それが新たなデータソースとなり、それが今度は、流動性限度を監視するためのより高度なモデルのソースとなりました。しかし、ルールベースのアプローチと先進的なモデルのデータエンジニアリングの基本的な要件は同じではありません。そして、基礎が適切でなかったため、先進的なモデルは、突然、予想外に低いパフォーマンスを発揮するようになりました。

2. ある製薬会社では、売上予測モデルの構築に苦労しています。地域によっては正確に売上を予測するものの、他の地域では常に予測が外れており、外れる理由も不明でした。これは、営業チームの目標設定に影響を与え、業績を阻害し、時には社員を退職させることさえあるのです。このモデルは一人の専門家によって作られ、その専門家のノートパソコンに保存され、実行されていました。この専門家が会社を去った後、このモデルは他の人に渡されましたが、誰もが怖くて触ることができません。このモデルは、明らかにバイアスがかかっているにもかかわらず、今でも稼働しており、販売目標の定義や営業成績のモニタリングにおいて、不明確な意思決定につながっています。

この2つの例では、経営課題に対する解決策に最初からAIを使用する予定ではないにも関わらず、ある時点でAIによる事故が発生しています。

リスクを考えてみる

意図しないモデルの振る舞いは、間違った、不正確な、あるいは危険な結果につながる可能性があり、好ましくないことは確かです。だからこそ、もう少し詳しく考える必要があるのです。これらの事故はチャットボットだけでなく、他のすべてのAI、より正確には、どのモデルにも起こり得ます。

モデル自体は間違っていることを気にしないかもしれませんが、あなたのビジネスや規制当局と顧客は気にするでしょうし、リスクやコンプライアンスの問題だけでなく、新しい市場やトレンドに対応するために競合が動き出すこともあり得ますし、収益の損失につながることもあります。では、AI事故の警告サインは何でしょうか？

1. ある目的のために構築されたモデルが、それの背景・暗黙的な前提が文書化されているか否かに関わらず、他の目的に使用され、アウトプットを生成してしまう。単純なルールベースのモデルでさえ、このように他の目的の使用が連鎖すると、より洗練されたシステムにのみ期待される創発的な振る舞いを示し始めるかもしれません（上記の銀行の例）。効率的に運用するために資産化と再利用は当たり前のことですが、事故なく使用するためには、監視システムが必須です。

2. ビジネス上重要な課題を解決するために個人が善意で作ったモデルが不可解であるため、あるいは、過去には機能していたため誰も手を加えることができず、改修するのがタブー化されるような存在になっている。ここで大事なのは、これが利用されているということではありません。トレードオフを認識して対処することもなく、モデルの結果を監視することもせずに、どの程度不可解で自動化されたシステムに重要な意思決定を委ねているか、ということを意識する必要があります。

3. 特定の目的のためにサードパーティーから購入、あるいはライセンス供与された、独自のブラックボックスモデル。もしかしたら、単に履歴書をスクリーニングするためのツールを購入したと思っているかもしれませんが、多くの規制当局の観点からすると、実際には目的も正体も不明なAIの使用を始めたことになります。このブラックボックスの正確な前提条件、トレーニング内容、バイアスが不明なため、それを正しく使っているかどうかを確認する機会はほとんどないのです。言い換えれば つまり、意図的であれ無意識であれ、開発された範囲外でモデルをすでに使っている可能性があるのです。

では、チームはどのようにしてAI事故のリスクを軽減すればよいのでしょうか。その答えは、明確なガバナンスとMLOpsプロセスにあります。

AI事故を抑制するためのベストプラクティス

「AIシステムは完全な最適化装置ではないため、また、どのような仕様であっても意図しない結果が生じる可能性があるため、結果が理想や設計意図と大きく乖離することがあります。」 -Pedro Ortegaら、DeepMind安全チーム

AIの事故リスクを効果的に管理するためには、明確な目標とモデルのスコープを特定し、それを実際の動作と比較するのがベストです。
具体的には：

• アルゴリズムが行うべき理想のゴール（理想仕様）は何か
• それをどのように分解して実装するか（設計仕様）
• 実際に実装されたもので、意図したとおりに動作するか否かの確認（実際の動作）

つまり、入力と出力の両方について、想定される範囲を明文化しておくということです。そして、それができたら、次のステップを取り入れます。

1. スケーラブルな監視方法の確立
1つのモデルであれば監査コミティーが議論し、リリースを承認することも可能です。しかし、数百、数千のモデルがある場合、それは不可能になります。そこで、このような状況では、複数のタイプのAIを議論させることで、人の承認プロセスをサポートすることができるのです。例えば、Dataiku 10では、ビジュアルモデル比較により、データサイエンティストやMLオペレータは、パフォーマンスメトリクス、フィーチャーハンドリング、トレーニング情報を並べて見ることができ、モデル開発とMLOpsワークフローの両方を支援することができます。さらに、モデルを本番環境に導入する前に、ユーザーによる承認を必須とし、また、カスタマイズすることで複数のレビュアーと承認者を含めることができます。

さらに、過去の行動から人間の好みを推測することで、目的（設計仕様）を指定し、過去の数百の決定を取り込んで、機械が人間の行動を模倣する最適なモデルを目指すことができ、承認を支援することもできます。適切な監視なしにAIプロジェクトやモデルを開発・展開すると、パフォーマンスが低下し、顧客や組織に意図しない影響を与えることになります。DataikuにあるエンタープライズグレードのガバナンスとAIポートフォリオの監視により、チームは標準化されたプロジェクト計画、リスクと価値の評価、中央モデルレジストリ、レビューとサインオフのためのワークフロー管理を実装することができます。

2. 定期的に、さまざまな視点から、広範囲にテスト、検証、妥当性確認を行い継続的に結果を監視し評価する
チームは、プロセス（例：CRISP-DMなど）を繰り返し、多様な経歴、スキルセット、技術やドメインの専門知識を持つ人々を巻き込むことで、逸脱に対処することができます。年次トレンドレポートでお伝えしたように、2021年は、多くの組織が、テクノロジーを構築しそこから利益を得るためAIをスケールさせるには、多種多様なメンバーを参加が不可欠であること、AIをスケールさせることはできないことと、MLOpsは強固なAI戦略にとって重要な部分であることを認識した年でした。DataikuのAIガバナンスは、AIプログラムやプロジェクトのリード、リスクマネージャー、主要なステークホルダーがプロジェクトやモデルを体系的に管理し、AIポートフォリオ全体の進捗を監視できる専用監視ツールを提供します。

3. 失敗を想定し設計する
モデルを構築する際には、ベストなパフォーマンスを発揮できるようベンチマークし、出力を分析します。失敗した場合は、AIを限界の状況で明示的にテストし、その判断がビジネスプロセスにどのような影響を及ぼすかを確認するのです。これは一種のリスク評価です。モデル自体のパフォーマンスをチェックするだけでなく、モデルの影響範囲と、それが意思決定にどのような影響を与えるかをチェックするのです。特に重要なビジネス・アプリケーションにおけるAIについては、その周りにセーフガードを構築することをお勧めします。このトピックについてはこちらより、O’Reilyの「Machine Learning for High-Risk Applications: Techniques for Responsible AI」を参照ください。

4. 再現性のある方法でバイアスを体系的にチェックしながらAIをトレーニングしている。無意識のバイアスも存在する可能性があることを意識する
偏ったデータで作られたモデルは、偏った予測をする可能性が高いです。モデルは気にしませんが、顧客（そしてビジネス！）は気にする可能性が高いです。適切なツールとプロセスにより、データサイエンティストと構築者は、より責任ある公正な結果をもたらすモデルを作成することができます。例えば、Dataikuは、格差影響分析を提供し、敏感なグループが有利なグループに近い割合で肯定的な結果を受け取ったかどうかを測定し、サブ集団分析は、ユーザーがグループごとに結果を確認できるようにします。どちらの分析も、モデルによって不公平または異なる扱いを受けている可能性のある人々のグループを見つけるのに役立ちます。

5. 事故について話し始める意識を高める
AI事故について、最初のステップは経営陣だけでなくAIプロジェクトに関わる全員が一般的な認識を高め、教育し、次のステップではオープンに話し合うことです。科学の世界では、「負の結果」は一般的に公表されませんが、この慣習は、他の多くの人々が同じ間違った道を歩むことにつながります。チームは、AIの事故やニアミスに関する情報共有を促進すべきです。AIを仕組み化する技術の利用はまだ新しい分野なので、すべてが最初の試みでうまくいくわけではありませんが、目標はあらゆる間違いや予期せぬ結果から学ぶことであるべきなのです。さらに、チームは、AI安全研究開発、AI標準開発およびテスト能力に投資する必要があります。

今後について

AIは、他のアルゴリズムと同様に、明確なガバナンス戦略とそれをサポートするビジネスプロセスが必要です。どのタイプのモデルを使っても、モデル自体は自分が間違っていても気にしないので、モデルを検証し妥当性を確認することが必要です。エンドツーエンドのライフサイクル管理を通じてモデルのパフォーマンスを監視する責任は、あなた自身にあります。今後は：

• AIの事故について認識すること。透明性、信頼性、効率性の高いMLOpsプロセスを構築する。
• リスクを管理しながらビジネスへの影響を広げるため、ビジネスエキスパートとアナリストをプロセスの一部にすること。
• データ、アクセス、モデルに関する明確なガバナンスを確立する。

また、ベストプラクティスの適用を新規構築したAIだけに限定せず、データに基づく重要な意思決定を自動化する他のあらゆる種類のモデルにも同じ厳密さを適用することをお勧めします。「新しい」モデリングアプローチと「古い」モデリングアプローチを分ける人工的な線は、後者の大きな潜在リスクを軽視することになります。こうすることで、リスクを管理しながら、真のAI拡張を可能にすることができるのです。

原文：Practical Steps to Avoid AI Accidents