質問

安全に関する要件は、安全関連の要件にAIを使用するシステムを好まないようです(特に、破壊/死亡の大きな潜在的リスクが関与する場合)。誰でもなぜを提案できますか?ロジックを適切にプログラムすれば、アルゴリズムにインテリジェンスを追加すればするほど、このアルゴリズムは危険な状況を防止できる可能性が高くなると常に考えていました。実際には事情は異なりますか?

役に立ちましたか?

解決

ほとんどのAIアルゴリズムはファジィです。通常、学習しながら学習します。重要な安全性が重要なアイテムの場合、必要なのは確定的です。これらのアルゴリズムは、多くの安全性が重要なアプリケーションに不可欠であるため、正しいことを証明するのが簡単です。

他のヒント

理由は2つあると思います。

まず、AIが予測不可能な決定を下す可能性があります。確かに、それらは有益である可能性がありますが、安全性の懸念について話すとき、特に人々の生活が順調である場合、そのようなリスクを取ることはできません。

2番目は、「推論」が決定の背後にあるものを常に追跡できるとは限らず(AIで結果を生成するために使用されるランダムな要素がある場合もあります)、何かがうまくいかない場合は、「なぜ」を決定することができません。 (非常に正確な方法で)責任となります。

最終的には、説明責任と信頼性に帰着します。

システムが複雑になるほど、テストが難しくなります。 そして、システムがより重要であるほど、100%包括的なテストを行うことがより重要になります。

したがって、重要なシステムでは、テストできる最適でない機能を使用し、複雑な意思決定を人間の操作に依存することを好みます。

安全性の観点から、多くの場合、動作の予測可能性/決定性の保証と迅速な応答時間に関心があります。 AIスタイルのプログラミング手法でどちらかまたは両方を実行することは可能ですが、システムの制御ロジックが複雑になると、システムの動作に関する説得力のある議論を提供するのが難しくなります(監査員を満足させるほど説得力があります)。

AIシステムは一般により複雑であると考えられます。特に「魔法」に関連する場合、複雑さは通常悪いことです。これが一部の人々がAIシステムを認識する方法です。

それは、代替案が必ずしも単純である(または優れている)と言うことではありません。

制御システムのコーディングが完了したら、すべてのコードパスのトレーステーブルと入力の順列を表示する必要がありました。これは、(従業員またはインフラストラクチャのために)機器を危険な状態にしないことを保証し、「証明」するために必要でした。プログラムが本来行うべきことを実行したこと。

@tvanfossonが示したように、プログラムがファジーで非決定的である場合、それは非常にトリッキーです。その答えを受け入れるべきだと思います。

重要なステートメントは、「ロジックを適切にプログラムする場合」です。さて、どのようにあなたは「提供」しますか?それ?経験によれば、ほとんどのプログラムにはバグがたくさんあります。

バグがないことを保証する唯一の方法は正式な検証ですが、それは最も原始的に単純なシステムを除くほとんどすべてにとって実質的に実行不可能であり、(より悪い)は通常コードではなく仕様で行われるので、まだありません仕様が完璧であることを証明した後、コードが仕様を正しく実装していることを知っている。

それは、AIを理解するのが非常に難しく、維持することが不可能になるためだと思います。

AIプログラムがファジーと見なされる場合、または「学習する」場合でもリリースされた瞬間には、すべての既知のケース(および既に学習済み)に対して非常によくテストされてから終了します。ほとんどの場合、この「学習」は一部の「しきい値」を変更しますまたはプログラムの重みとその後、作成者にとってもそのコードを本当に理解して維持することは非常に困難です。

これは、数学者が理解しやすい言語を作成し、テストを容易にし、問題に関する新しい擬似コード(mat lab AIツールボックスなど)を提供することにより、過去30年間で変化しました

通常のアルゴリズムは、見掛け倒しに設計およびテストされたときに、人々を殺すことができる十分な方法があります。まだ読んでいない場合は、 Therac 25 。これは、振る舞いが完全に決定論的であるはずのシステムでしたが、それでも事態は恐ろしく、恐ろしく間違っていました。 「理性的に」推論しようとしていると想像してください。

AIの受け入れられた定義はないので、質問はより具体的です。

答えは、出力情報の安全性を向上させるために、パラメータ推定(一種の学習)を単に採用する適応アルゴリズムについてです。提案されたアルゴリズムの振る舞いは決定論的である(すべてのコンピュータープログラムがそうである)だけでなく、決定するのも簡単であるように見えるかもしれませんが、これは機能安全において歓迎されません。

入力データと障害モードのすべての組み合わせをカバーするテストレポートのデモンストレーションを依頼する評価者に準備してください。適応アルゴリズムは、現在の入力値だけでなく、以前の値の多くまたはすべてに依存することを意味します。宇宙の時代では完全なテストカバレッジが不可能であることを知っています。

スコアリングの1つの方法は、以前に受け入れられたより単純なアルゴリズム(最新技術)が安全でないことを示すことです。問題のある領域がわかっている場合、これは簡単です(もしわからない場合は、AIに近づかないでください)。

問題には別の可能性があります。パラメータが正確に推定されているかどうかを示す説得力のある監視機能です。

"通常のアルゴリズム"複雑な問題の場合、空間は厄介になる傾向があります。一方、一部の「インテリジェント」なアルゴリズムの構造は単純です。これは、ベイジアン推論のアプリケーションに特に当てはまります。データの尤度関数を知っている必要があります(データが統計的に独立したサブセットに分かれている場合は複数適用されます)。

尤度関数をテストできます。テストが必要な信頼レベルに達するほどテールをカバーできない場合は、たとえば別のセンサーからのデータを追加するだけです。アルゴリズムの構造は変わりません。

欠点は、ベイジアン推論に必要なCPUパフォーマンスです。

その上、Therac 25に言及することは役に立ちません。なぜなら、アルゴリズムはまったく関係していなかったから、マルチタスクスパゲッティコードだけだったからです。著者を引用して、「[[]]事故はソフトウェアコーディングエラーを伴うという点でかなりユニークでした。ほとんどのコンピューター関連の事故はコーディングエラーではなく、省略や誤った環境条件やシステム状態などのソフトウェア要件のエラーです」 ;

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top