安全に関する要件は、安全関連の要件に AI を使用するシステムを好まないようです (特に、破壊/死亡の大きな潜在的リスクが関係する場合)。誰でも理由を提案できますか? ロジックを適切にプログラムすれば、アルゴリズムにインテリジェンスを追加すればするほど、このアルゴリズムが危険な状況を回避できる可能性が高くなる、と私は常々思っていました。実際には違いがありますか?
10 に答える
ほとんどの AI アルゴリズムはファジーです。通常、進行するにつれて学習します。安全性が非常に重要なアイテムの場合、何が必要かは決定論的です。これらのアルゴリズムは、正しいことを簡単に証明できます。これは、多くの安全性が重要なアプリケーションにとって不可欠です。
その理由は二つあると思います。
まず、AI が予測不可能な決定を下す可能性があります。確かに、それらは有益な場合がありますが、安全上の懸念について話すとき、特に人々の命が危険にさらされている場合、そのようなリスクを冒すことはできません.
2 つ目は、決定の背後にある「推論」を常に追跡できるとは限らず (AI で結果を生成するためにランダムな要素が使用される場合があります)、何か問題が発生した場合に、「理由」を判断する能力がないことです (非常に正確な方法)は責任になります。
最終的には、説明責任と信頼性に帰着します。
安全性の観点から、多くの場合、動作の予測可能性/決定性の保証と迅速な応答時間に関心があります。AI スタイルのプログラミング手法を使用していずれかまたは両方を行うことは可能ですが、システムの制御ロジックが複雑になるにつれて、システムがどのように動作するかについて説得力のある議論を提供することは難しくなります (監査人を満足させるのに十分説得力があります)。
システムが複雑になるほど、テストが難しくなります。システムが重要であるほど、100% 包括的なテストを実施することが重要になります。
したがって、重要なシステムでは、人々はテスト可能な次善の機能を持ち、複雑な意思決定のために人間の相互作用に依存することを好みます。
一般的に、AI システムはより複雑であると考えられていると思います。複雑さは通常悪いことです。特に、一部の人々が AI システムを認識する方法である「魔法」に関連する場合は特にそうです。
これは、代替案が必ずしもより単純である (またはより優れている) と言っているわけではありません。
制御システムのコーディングが完了したら、すべてのコード パスと入力の順列のトレース テーブルを表示する必要がありました。これは、機器を危険な状態 (従業員またはインフラストラクチャにとって) にしないことを保証し、プログラムが本来の機能を実行したことを「証明」するために必要でした。
@tvanfossonが示したように、プログラムがファジーで非決定論的である場合、それを行うのは非常に難しいでしょう。その答えを受け入れるべきだと思います。
重要なステートメントは、「ロジックを適切にプログラムしている場合」です。では、それをどのように「提供」するのでしょうか。経験上、ほとんどのプログラムにはバグがぎっしり詰まっています。
バグがないことを保証する唯一の方法は正式な検証ですが、それは最も原始的に単純なシステム以外では実際には実行不可能であり、(さらに悪いことに) 通常はコードではなく仕様で行われるため、まだわかりません。仕様が完璧であることを証明した後、コードは仕様を正しく実装します。
受け入れられている AI の定義がないため、質問はより具体的にする必要があります。
私の答えは、出力情報の安全性を向上させるために、パラメーター推定 (一種の学習) を使用するだけの適応アルゴリズムに関するものです。提案されたアルゴリズムの動作は決定論的 (すべてのコンピューター プログラム) であるだけでなく、簡単に決定できるように見えるかもしれませんが、これも機能安全では歓迎されません。
入力データと故障モードのすべての組み合わせをカバーするテスト レポートの提示を求める評価者に備えてください。アルゴリズムが適応的であるということは、現在の入力値だけでなく、以前の値の多くまたはすべてに依存することを意味します。宇宙の時代に完全なテストをカバーすることは不可能であることをご存知でしょう。
スコアを付ける方法の 1 つは、以前に受け入れられた単純なアルゴリズム (最新技術) が安全ではないことを示すことです。問題空間を知っていれば、これは簡単です (そうでない場合は、AI から遠ざけてください)。
問題には別の可能性があります。パラメーターが正確に推定されているかどうかを示す説得力のある監視機能です。
それはAIが非常にわかりにくく、維持できなくなるからだと思います。
AI プログラムがファジーであると見なされたり、リリースされた瞬間に「学習」したりしたとしても、すべての既知のケース (および AI プログラムから既に学習済み) については、完成前に非常によくテストされています。ほとんどの場合、この「学習」はプログラムの「しきい値」または重みを変更し、その後、そのコードを実際に理解して維持することは、作成者であっても非常に困難です。
これは、数学者にとって理解しやすい言語を作成し、テストを容易にし、問題を回避する新しい疑似コードを提供することで、過去 30 年間で変化してきました (mat lab AI ツールボックスなど)。
通常のアルゴリズムが設計とテストが粗雑に行われた場合、人を殺してしまう可能性は十分にあります。まだ読んでいない場合は、Therac 25のケースを調べてください。これは、動作が完全に決定論的であるはずのシステムでしたが、それでも事態は恐ろしく、恐ろしく間違っていました。それも「知的に」推論しようとしていたと想像してみてください。
複雑な問題空間の「通常のアルゴリズム」は、難解になりがちです。一方、一部の「インテリジェント」アルゴリズムは単純な構造を持っています。これは、ベイジアン推論のアプリケーションに特に当てはまります。データの尤度関数を知る必要があるだけです (データが統計的に独立したサブセットに分かれている場合は、複数が適用されます)。
尤度関数をテストできます。テストが必要な信頼レベルに達するのに十分な範囲で裾をカバーできない場合は、別のセンサーからのデータなどを追加してください。アルゴリズムの構造は変わりません。
欠点は、ベイジアン推論に必要な CPU パフォーマンスです。
その上、Therac 25 について言及することは役に立ちません。なぜなら、アルゴリズムはまったく関与しておらず、スパゲッティ コードをマルチタスクするだけだからです。著者らの言葉を引用すると、「[the] 事故は、ソフトウェアのコーディング エラーが関係しているという点でかなり独特でした。ほとんどのコンピュータ関連の事故は、コーディング エラーではなく、省略や環境条件やシステム状態の処理ミスなど、ソフトウェア要件のエラーが関係していました。」