信頼できるAIシステムを作る３つの指針（OpenAI論文）
アイイン より 210331 中村 隼太
⚫︎今、開発者の責任を問う
近年のAIの進歩は目覚ましく、さまざまな領域で活用されています。しかしその技術の進歩の速さに対して、技術の安全性や信頼性には不透明な部分が多く存在しています。実際に、世界の大企業はシステムの不透明性に対して市民から説明を求められたり、システムの変更を求められたりすることがしばしばあります。
開発者がユーザーや顧客、社会全体に対して責任を持ってAIを構築しているという信頼を得るためには、その責任を示す行動を実証するメカニズムに焦点を当てる必要があります。
AIや政策などの学術的研究者、産業界の研究者、政策立案者など、AIの開発に関わるさまざまな機関の専門家によってAIシステムの検証可能性の論文が発表されました。
⚫︎「検証可能性」を高める必要がある
著者らは、AIシステムの安全性、セキュリティ、公正性、プライバシー保護に関して開発者の主張を検証するための様々な手段について提言を行っています。例えば開発者が直面しうる、次のような疑問に答えられるようなものです。
機密文書の機械翻訳に用いるAIシステムが保証するプライバシー保護のレベルについて、開発者の主張を検証できるか？
規制当局は、自動運転が起こした事故の原因を追跡することができるか？自動車メーカーの安全性の主張は、どのような基準で比較されるべきか？
産業界ほどのコンピューティングリソースを持たない学者は、大規模なAIシステムにが及ぼす影響について公平な研究を行うことができるか？
AI開発者は、特定の分野において競合他社が優位に立つために手抜きすることはなく、最善の方法でシステム構築を行っていると確認できるか？
本論文での提言は、2つの効果を期待できます。
⚫︎AIシステムの特性に関する主張を照明するために、AI開発者自身が利用できる選択肢を増やすこと。
ユーザー、政策立案者、市民など、他の利害関係者がAI開発者に求める要求の具体性と多様性を高める。
本報告書では、AIのシステムや開発プロセスを構成する3つの要素である「制度」「ソフトウェア」「ハードウェア」の観点からメカニズムを整理しています。
下記に、それぞれのメカニズムに関連する提言をまとめたリスト示します。
⚫︎制度的メカニズム
①利害関係者の連合体は、AIシステムの第三者監査の実施と資金調達のオプションを研究するタスクフォースを創設すべきである。
②AIを開発している組織は、開発したシステムに関連するリスクを探るためにレッドチーミング演習を実施し、そのためのベストプラクティスやツールを共有すべきである。
③AI開発者は、AIシステムのバイアス・バウンティとセーフティ・バウンティを試験的に実施し、AIシステムを広く精査するためのインセンティブとプロセスを強化すべきである。
④AI開発者は、AIのインシデントに関するより多くの情報を、共同チャンネルを含めて共有すべきである。
⚫︎ソフトウェアメカニズム
⑤基準設定機関は、学界や産業界と協力して、AIシステムのセーフティクリティカルなアプリケーションに対する監査証跡要件を策定すべきである。
⑥AIを開発している団体や資金提供団体は、リスク評価や監査のサポートに重点を置いた、AIシステムの解釈可能性に関する研究を支援すべきである。
⑦AI開発者は、共通の基準に照らした性能評価を含む、プライバシー保護を目的とした機械学習のためのツール群を開発し、共有し、使用すべきである。
⚫︎ハードウェアメカニズム
⑧産業界と学術界が協力して、AIアクセラレータのハードウェア・セキュリティ機能を開発するか、あるいは機械学習の文脈で安全なハードウェア（コモディティ・ハードウェア上のセキュア・エンクレーブを含む）を使用するためのベストプラクティスを確立するべきである。
⑨1つまたは複数のAIラボは、1つのプロジェクトに関わる計算能力を詳細に推定し（高精度計算測定）、そのような方法をより広く採用する可能性について報告すべきである。
⑩政府の資金提供団体は、産業界の主張を検証する研究者の能力を向上させるために、学術界の研究者のためのコンピューティングパワーリソースへの資金提供を大幅に増やすべきである。
■それぞれのメカニズムについて、詳しく説明していきます。
1. 制度的メカニズム
制度的メカニズムは、AIシステムの安全性、セキュリティ、公正性、およびプライバシー保護を確保するための開発者の行動に可視性を与えます。制度的メカニズムは、AI開発に関する検証可能な主張において基礎的な役割を果たします。
以下では、AI開発における主張の検証可能性を向上させる可能性のあるメカニズムとして、第三者監査、レッドチーム演習、バイアス・安全性改善への報奨金、AIインシデントの共有を紹介します。それぞれにおいて、そのメカニズムを検討する動機となった課題を示し、そのメカニズムを改善または適用するための提言が示されます。
1.1 第三者監査
<課題>
AIの開発プロセスは、外部からは不透明であることが多く、開発者の主張を第三者が検証することは様々な障壁がある。その結果、システムの属性に関する主張を容易に検証できない場合がある。
<提言①>ステークホルダーは、AIシステムの第三者監査を実施し、資金を提供するための選択肢を研究するタスクフォースを創設すべきである。
第三者監査は外部の独立した監査人により行われる監査で、組織の現在や過去の行動が、原則や規範に一致しているかを評価するものです。
第三者監査の対象となりうるAIシステムには、プライバシー保護のレベル、セキュリティ、倫理的な問題などがあります。例えば、自動運転車や医療用AIシステムなどの安全性や、検索エンジンがその検索結果にバイアスを持っていないかを監査します。
第三者監査に関連する問題に焦点を当てたタスクフォースは、監査に適した初期の仕組みを構築し、機密性の高い知的財産を取り扱うためのアプローチを考案する必要があります。この分野の共同研究は、同じ監査プロセスを研究室や国を超えて使用することができるため、特に有望であると思考えられます。これらの分野の研究が発展するにつれ、監査プロセスも発展すると考えられます。
第三者による監査が政府の政策と結びつき、資金を調達する方法のひとつとして、「規制市場」があります。AIの規制市場では、政府はAIの規制によって達成すべき高い成果を設定し、その成果を達成するために必要な監査を実施する民間企業やその他の組織を支援する仕組みが考えられます。
1.2 レッドチーム演習
<問題点>AI開発者にとって、誰かに悪用されるリスクなど、AIシステムに関連する「未知の不安」に対処することは困難です。さらに、既存のレッドチームアプローチは、AIの領域でこのような懸念に対処するには不十分です。
<提言②>AIを開発している組織は、開発したシステムに関連するリスクを探るためにレッドチーム演習を行うべきであり、そのためのベストプラクティスやツールを共有すべきである。
レッドチーム演習とは、技術システムの欠陥・脆弱性を発見するための組織的な取り組みです。コンピュータセキュリティなどの分野では、レッドチームは、このような発見をするために、システムを巡回する任務を日常的に行っています。レッドチームが欠陥を発見することで、セキュリティとシステムの完全性を向上させることができます。
AIシステムの開発者が開発した技術システムの潜在的リスクを予期していないために、事故やトラブルが起こることがしばしばあります。レッドチーム演習の取り組みのベストプラクティスは一般的にまだ初期段階にありますが、専門のレッドチームを設置する業界の研究所は増えてきています。また、レッドチームを組織内で構成するのではなく、専門家集団として企業などを超えて形成することも有益です。
このようなコミュニティを形成することで、
構成員が幅広い知識をつけることができ、社会全体に提言を行ことができる。
AIインシデントの情報共有が多くの組織で行うことができる。
リソースの少ない小規模な組織も恩恵を受け取ることができる。
などのメリットがあります。
1.3 バイアス・安全性の改善への報奨金
<問題点>特定のAI開発者と関係のない個人が、AIのバイアスや安全性に関する問題を探し出して報告することに対するインセンティブがあまりにも低く、また正式なプロセスもありません。その結果、これらの特性を持つAIシステムを広く精査することは比較的稀になっています。
<提言③>
AI開発者は、AIシステムにおけるバイアスと安全性の問題発見にかける懸賞金を試験的に導入し、AIシステムを広く精査するためのインセンティブとプロセスを強化すべきである。
バグバウンティは、脆弱性に関連するバグを発見して報告する個人に報酬を与える方法として、情報セキュリティ業界で普及しています。バグバウンティは、バグを公に公開したり、他者に販売したりするのではなく、システムの開発者や発注者に直接バグを報告するための方法です。一般的に、バグバウンティでは、適切な報酬を決定するために、バグの規模や深刻度を明確にする必要があります。
バイアスバウンティとセーフティバウンティは、バグバウンティのコンセプトをAIに拡張するものです。ここでは、まずAIシステムの偏りと安全性の問題を発見するための報奨金に焦点を当てていますが、他の特性（セキュリティ、プライバシー保護、解釈可能性など）に対する報奨金も検討可能です。
※このようなバウンティプログラムを設定する際に対処すべき課題は以下の通りです。
*発見された問題の規模/重大さに応じた報酬額の設定。
応募を募り、評価するプロセスを決定すること。
そのような報奨金によって発見された問題をタイムリーに開示するためのプロセスを開発すること。
展開されたAIシステムの中で、バイアスや安全性の問題を報告するための適切なインターフェースの設計。
報告されたバグを処理し、修正プログラムを利用可能するためのプロセスを定義する。
不正なインセンティブの発生を回避する。
従来のコンピュータセキュリティの問題を発見して対処することと、AIシステムの問題を特定して対処することとの間には、完璧な類似性があるとは言えません。したがって、バグバウンティのコンセプトをAI開発の文脈に適応させるためには、上記の要素について検討が必要です。
1.4 AIインシデントの共有
<問題点>AIシステムは、その潜在的なリスクに関する共通の知識があれば、より効果的に精査することができます。しかし、AIシステムが望ましくない、あるいは予期しない振る舞いをした場合は、コストがかかるため、あまり共有されません。
<提言④>AI開発者は、AIインシデントに関するより多くの情報を共有すべきである。
組織は、AIシステムが望ましくない、あるいは予期しない行動をとって被害を引き起こしたり引き起こす可能性のあるケースを、他の人が学べるようなケーススタディとして共有することができます。その際には、自分や他人の経験に基づいて、将来のインシデントを防ぐためにどのように取り組んできたかという情報を添付することができます。
しかし通常、AIを開発している組織はポジティブな結果を主に報告します。その結果、一般市民、規制当局、ユーザーは、AIシステムの潜在的なリスクについて、偏ったイメージを持つことになります。
AIのインシデントを共有することで、他者が考慮しなかったリスクを発見でき、AI開発における主張の検証可能性を向上させることができます。また、これらのリスクに関する知識は、開発者への質問に役立つため、外部からの監視効果を高めることができます。
AI開発者がインシデントを報告する能力とインセンティブを向上させるには、サイバーセキュリティなど他の領域でインシデントを報告するために存在するインフラと同様に、新たなインフラを構築する必要があります。インシデントの共有をサポートするインフラには、以下のようなものが必要になります。
⚫︎インシデントが公開されることによって生じる過度の風評被害から組織を保護するための仕組み。
秘密保持契約に基づいて各組織と協力し、個人情報の収集と匿名化を行う、信頼できる中立的な第三者。
ユーザーがインシデントデータベースに容易にアクセスできるプラットフォームを維持・管理する組織。
データベースへの貢献とデータベースから得られた知識の積極的な利用を促進するために、このデータベースの存在を公表するためのリソースとチャネル。
パターンを分析したり共有可能な教訓を特定したりするために、データベース内のインシデントを監視する専任の研究者。
将来的には、インシデント共有のための段階的に強固なプラットフォームの導入や、そのようなプラットフォームへの貢献に加えて、AIと他の領域との関連性をより詳細に調査し、インシデント共有がより成熟している他の領域（原子力産業やサイバーセキュリティ産業など）からの重要な教訓を特定することも可能です。
長期的には、実験と研究から得られた教訓が、成熟した知識体系として結晶化する可能性があります。また、政府が特定のインシデント報告を義務化したり、インセンティブを与えたりする際にも、このような知識が役立つと考えられます。
2. ソフトウェアメカニズム
ソフトウェアメカニズムは、システムの特性をより理解することで新しい主張の検証をサポートしたり、既存の主張をより高い信頼性で検証したりすることができます。ここではまず、ソフトウェアメカニズムの概要を説明し、次に、いくつかの重要な問題、および関連する提言を紹介します。
多くのソフトウェアメカニズムに関する専門知識は広く普及しておらず、そのようなメカニズムを通じて信頼を築くには課題があります。例えば、AI開発者が「ユーザーデータは秘密にされている」という主張の根拠を示すことは、研究所がプライバシーに関する正式なコミュニティに準拠しているという信頼を築くのに役立ちます。一方で専門家ではない人は、プライバシーの定義は人により異なっているため、得られる信頼は限定的かもしれません。
したがって、理論的に既存のメカニズムでどのような主張が実証できるか、だけでなく、実際にこれらのメカニズムを精査できる立場にあるのは誰かを考慮することが重要です。
ソフトウェアメカニズムは、制度的メカニズムやハードウェアメカニズムを補完する様々な方法で、AI開発に関連する主張を実証することで、研究者や監査役などがシステムの内部構造を理解するのに役立ちます。
AIシステムの結果の再現性は、システムの特性に関する主張の検証を可能にする重要な手段です。結果、モデル、コードを公開することで、外部の人間（特に技術専門家）がAIシステムについての主張を検証することができます。また、慎重な実験設計や、標準的なソフトウェアライブラリの使用は、結果の再現性を向上させます。
形式的検証とは、数学の形式的な手法を用いて、あるシステムが要求事項を満たしているかどうかを確認するものです。形式的検証は、システムの機能的な動作を保証するために、セーフティクリティカルな領域で導入されることが多い技術です。
これまで、AIシステムは、そのような厳密な検証を受けることはありませんでしたが、自動運転やロボットなどのセーフティクリティカルな領域で機械学習が利用されるようになると、機械学習モデルとそれに付随する非機械学習コンポーネントを対象とした新しい形式解析技術が必要になります。機械学習モデルの形式的検証技術はまだ発展途上であり、多くの課題を抱えています。
形式的な検証に代わるものとして、経験的な検証と妥当性の確認が提案されています。注意しなければいけないのは、形式的検証よりも実用的な手法となり得るが、経験的に動作するため、その主張を完全に保証することはできないという点です。
以下では、重要であると考えられるソフトウェアメカニズムについて説明します。特に、監査証跡、解釈可能性、プライバシー保護のための機械学習について取り上げます。
2.1 監査証跡
<問題点>AIシステムには、問題の定義、設計、開発、運用の各段階における追跡可能なログが存在しないため、システムの特性や影響に関する後の主張に対して説明責任を果たすことは困難です。
<提言⑤>
基準設定団体は、学界や産業界と協力して、AIシステムの安全性の高いアプリケーションのための監査証跡要件を策定すべきである。
監査証跡とは、システム運用時の処理内容やプロセスを、追跡可能な形で記録したものです。監査証跡は、AIがより安全性を重視するタスクに適用されるにつれて、重要性を増していくと考えられます。
監査証跡については、多くの業界の特に安全性が重視されるシステムにおいて、すでに標準化しています。例えば、民間航空機には、毎秒複数のデータを記録・取得するフライトデータレコーダが搭載されています。
監査証跡は、第三者監査人、政府の規制機関、企業による安全関連情報の自主的な開示など、多くの制度的な信頼構築を支える重要な役割を果たすことになると考えられます。
2.2 解釈可能性
<問題点>ブラックボックス化されたAIシステムは、その内部構造の説明や可視性なしに予測を行うため、その主張を検証することは困難です。この問題は、解釈可能性の意味についての共通認識が得られていないことにより、さらに悪化しています。
<提言⑥>
AIを開発している組織や資金提供団体は、リスク評価や監査を支援することに重点を置いて、AIシステムの解釈可能性に関する研究を支援すべきである。
AIシステムは、さまざまな問題で優れた性能を発揮しているにもかかわらず、その動作を理解したり予測したりすることが難しいため、しばしば「ブラックボックス」と呼ばれています。このようなシステムの内部プロセスがどのように機能するかをより理解することは、障害を積極的に予測し、モデルの動作を監査し、新しいシステムを構築するためのアプローチを検討するのに役立ちます。
モデルの解釈可能性に関する研究は、特定のモデルがどのようにして機能するのかを理解することを目的としています。しかし、解釈可能性を技術的に定義することは困難であり、その定義は研究者により異なります。また、モデルの開発者や規制当局は、入力データ全てにおけるモデルの挙動を理解することに関心があるかもしれませんが、一般市民は、個々のケースについてモデルが特定の予測を行った理由を理解したいかもしれません。
つまり重要なのは、「解釈可能」なモデルがすべての状況で必要とは限らないということです。モデルが解釈可能であることをどの程度重視するかは、例えば、いくつかの異なる要因によって決まります。
・センシティブな領域（例：自動運転やヘルスケアなど、誤った予測が人間の福祉に悪影響を及ぼす場合）や、ユーザーが実行可能な手段を持つことが重要な場合（例：銀行ローン）には、より重視する。・過去のパフォーマンスデータがある時は重視しない。（例えば、解釈可能でなくても、十分な過去のパフォーマンスを持つモデルは使用されうる）
・解釈可能性を向上させることで他のコストが発生する場合（例：プライバシーの侵害）は重視しない。
長期的には、人権や福祉が害される可能性のある敏感な領域では、解釈可能性がAIシステム監査の重要な要素となり、モデルの動作について監査人に適切な直観を提供できるかどうかで、AIの特定の用途が制限されるようになると予想しています。これは、金融などの規制された領域ではすでに取り組まれています。
2.3 プライバシー保護のための機械学習
<問題点>AI開発に関わるデータやモデルを検証可能な形で保護するために、様々な手法が潜在的に使用されています。一方で、新しいプライバシー保護のための機械学習技術を評価するための基準は不足しており、それらを実装する能力は、現状では一般的なAI開発者のスキルセットの範囲外となっています。
<提言⑦>
AI 開発者は、共通の基準による性能測定を行えるような、プライバシー保護のための機械学習のためのツール群を開発、共有、使用すべきである。
AIの学習データには、人に関する機密情報が含まれていることが多く、個人のプライバシーが侵害されるリスクがあります。
個人が機械学習システムの主張を十分に信頼してそのトレーニングに参加するためには、データへのアクセス、データの使用、およびデータの保護に関する証拠が必要です。AI開発コミュニティやその他の関連コミュニティは、「プライバシー保護機械学習」として、これらの懸念に対処するための様々な手法やメカニズムを開発してきました。
プライバシー保護機械学習は、暗号やプライバシーのコミュニティの研究に大きく関連しており、それぞれが独自の制限やコストを持つ技術の組み合わせを用いて実行されます。これらの技術は、重要な情報のプライバシーを保証することで、データ所有者とデータ利用者との間の信頼を支える強力なツールです。
しかし、これらの技術は、(1)プライバシー情報の有用性、(2)モデルの品質、(3)AI開発者の経験と生産性、(4)計算、通信、エネルギー消費などのコスト間のトレードオフを十分に理解した上で、慎重に使用する必要があります。また、これらの技術は、すべての状況で有効なわけではありません。したがって、データやモデルを、十分なリソースを持つ悪意のある第三者の行動から保護するために、複数の技術を組み合わせる必要がある場合もあります。
共通の性能評価基準を持つオープンソースのプライバシー保護機械学習フレームワークを使用することで、AI開発における主張の検証可能性に大きな影響を与えられると考えられます。第一に、堅牢なオープンソースフレームワークは、プライバシー保護機械学習技術を実装するためのスキル要件を軽減するために必要です。
第二に、新しいプライバシー保護機械学習技術を評価するための共通基準があれば、新しい結果の比較可能性が高まり、技術の進歩が加速する可能性があります。
最後に、標準化によって、ユーザー、監査人、政策立案者を含む外部の関係者が プライバシー保護機械学習の性能に関する主張を検証する能力を向上させることができます。
3. ハードウェアメカニズム
コンピューティングハードウェアは、AIシステムのトレーニング、テストでの使用を可能にします。AIの開発に関連するハードウェアは、センサー、ネットワーク、メモリから、最も重要な処理能力まで多岐にわたります。
AIシステムの能力や影響が増大していることや、この分野に特化したハードウェアの需要があることから、AI開発に使用されるハードウェアに関する主張の検証可能性を保証するための新しいアプローチが必要とされています。
ハードウェアは、様々な方法で検証可能な主張をサポートすることができます。プライバシーやセキュリティの保証を精査可能にしたり、ソフトウェアメカニズムと合わせて活用したりすることで、安全な機械学習を行うハードウェアが実現できます。また、ハードウェアメカニズムは、組織がそのコンピューティング能力をどのように利用しているかを示すためにも利用できます。
3.1 機械学習用の安全なハードウェア
<問題点>ハードウェアのセキュリティ機能は、データやモデルの盗難に対して効果を発揮しますが、コモディティハードウェアのみしか信頼できる実行環境とは言えません。機械学習のタスクは、専用のハードウェアで実行されることが多くなっています。このような場合、信用できる実行環境の開発には多額の初期費用がかかり、ハードウェアにおける解決策としては最適ではないかもしれません。
<提言⑧>
産業界と学術界が協力して、AI開発用のハードウェアセキュリティ機能を開発したり、機械学習の文脈で安全なハードウェア（コモディティハードウェア上の信頼できる実行環境を含む）を使用するためのベストプラクティスを確立したりすべきである。
AIシステムには必ず物理的なインフラが存在します。そのためシステムが安全でプライバシーに配慮されたものであるかどうかは、そのインフラのセキュリティが大きく関与します。
例えば、画面ロック解除のための顔認証機能を備えたiPhoneは、プライバシー保護のために、顔に関連するデータをコンピュータの物理的に異なる部分に保存しています。次に説明するように、AIに信頼できる環境を適用できる範囲を広げることで、より高度なセキュリティとプライバシー保護を実証し、要求することが可能になります。
このようにデータ保存のために物理的に安全な場所を作ることで、悪意のあるハッカーなどがシステムにアクセスできたとしても、機密データにアクセスしたり、プログラムを妨害したりすることを困難にします。
ほとんどの機械学習アプリケーションでは、機械学習に特化していないハードウェアを使用する方がコストは低いです。しかし、最先端の機械学習モデルでは、大きな計算量が必要となることが多く、より特化したハードウェアの使用が推進されています。特殊なAIハードウェアを使用する場合、信用できる環境を構築するには、新しい設計ごとに新たな投資が必要になります。
また、特殊なAIハードウェアでは、全く新しいセキュリティ機能が必要になる場合があり、さらなるコストがかかることがあります。
ハードウェアセキュリティ機能を機械学習に特化したハードウェアに統合するための集中的かつ継続的な取り組みは、セクターを超えた協力を必要としますが、価値を高めることができるでしょう。
3.2 高精度な計算機使用量の測定
<問題点>計算機資源の使用状況を測定する基準がないため、自主的な報告の価値が下がり、AI開発プロセスで使用されている資源に関する主張を検証することが難しくなっています。
<提言⑨>
AIの研究を行う機関は、1つのプロジェクトに関わるコンピューティングパワーを詳細に推定し、そのような方法をより広く採用する可能性について報告すべきである。
設置されたハードウェアの使用状況を内部で監視するためのツールやシステムはすでに多く存在します。現在、AI開発者が計算機の使用状況を報告している例として、論文などに訓練の詳細や,モデルの訓練や実行に使用された計算機の量が記載することがよくあります。
これらは他の研究との比較や研究の再現のために行われますが、計算使用量を測定して報告する標準的な方法がないため、直接比較するためには余分な作業が必要になることがよくあります。このような曖昧さは、信頼できるAI開発を行う上で課題となっています。というのも、ハードウェアの使用状況について検証可能な主張を行いたいAI開発者であっても、組織や文脈を超えて比較可能な標準的な形式でそのような情報を提供することができないからです。
計算機使用量の報告精度向上と標準化を行うことで、組織間での研究結果の比較が容易になります。例えば、監査人は、ある組織が監査対象のプロジェクトで報告された使用量よりも多くのコンピューティングパワーを利用していることに気付き、そのプロジェクトに関連する報告されていない活動を明らかにすることができます。
3.3 学界への計算機の援助
<問題点>産業界と学界の間のコンピューティングリソースの格差によって、AI開発者の技術的主張、特に計算機集約型システムに関する主張を産業界以外の人々が精査することが制限されています。
<提言⑩>
政府の資金提供団体は、産業界の主張を検証する研究者の能力を向上させるために、学界の研究者に対するコンピューティングリソースの資金提供を大幅に増やすべきである。
近年、多くの学界のAI研究者が産業界のAIラボに移行しています。この移行の理由の一つは、学界に比べて産業界ではコンピューティングリソースをより多く利用できることです。この人材の移動は、有用なソフトウェアフレームワークやアルゴリズムの開発に繋がった一方で、学界と産業界で利用可能な計算資源の格差が拡大しているという懸念も生じています。
ここでは、政府がコンピューティングパワーを公平にするために行動することの具体的なメリットに焦点を当てています。つまり、学界のような経済的に利害関係のない研究者が、産業界のAI開発者が主張する内容を検証する能力を向上させることです。例は以下の通りです。
・商用モデルの精査の強化：「制度的メカニズム」の項で説明したように、独立した第三者が他者の開発したモデルをストレステストすることには大きな価値があります。計算量の多いAIシステムのテストには、追加のコンピューティングリソースが必要になる場合があります。
・AIのテストにAIを活用する：AIシステムがより複雑になるにつれ、潜在的な故障傾向や隠れたバイアスを探るために、自動テストを導入することが有用になる可能性があります。そのようなテストはますます計算集約的になるかもしれません。
・計算機要件に関する主張の検証：上述したように、モデル学習の計算機入力を考慮することは、現在、AI開発における未解決の課題となっています。計算機の説明性の標準化と並行して産業界以外の研究開発者への計算機支援を行うことで、AI開発者が開発するシステムのリソース要件に関する主張を検証することが可能になります。
⚫︎結論
人工知能は社会を有益にも有害にも変化させる可能性があります。AI開発者が社会やお互いの信頼を得ることができれば、有益なアプリケーションが実現し、リスクが回避される可能性が高まります。
そのような信頼を得るための一つの方法として、AI開発に関する主張をさまざまな手法で検証可能にするメカニズムを提言しました。
これらのメカニズムがAIコミュニティに刺激を与え、組織を超えた検証可能性の探究が行われることが期待されます。
検証可能な主張は、より信頼性の高いAI開発の第一歩となります。AI開発者と他のステークホルダーが協力して主張の検証可能性を向上させなければ、AI開発に対する社会の懸念はますます大きくなるでしょう。
AIの応用範囲は拡大に伴って様々なリスクが発生しています。AIの開発について検証可能な主張を可能にする取り組みにより、AIの影響をポジティブに形成し、広く社会的利益をもたらす可能性を高めることができます。
研究紹介は以上です。
技術の進歩に追いついていなかった周辺の環境が整備されようとしています。私たちも安心して利用できるような技術が、今後のスタンダードになっていくことを期待したいですね。
関連記事
DeepMindの新しいAI『MuZero』は、ルールをゼロから学んで極める。/研究者公認の解説記事【AI×エンタメ】（論文）
最新のAI関連特許を100本近くチェックした筆者がおすすめの出願・取得事例5選
AIがニュースをつくる時代、著作権の行方はどこに？
この記事で取り扱った論文：Miles Brundage, Shahar Avin, Jasmine Wang, Haydn Belfield, Gretchen Krueger, Gillian Hadfield, Heidy Khlaaf, Jingying Yang, Helen Toner, Ruth Fong, Tegan Maharaj, Pang Wei Koh, Sara Hooker, Jade Leung, Andrew Trask, Emma Bluemke, Jonathan Lebensold, Cullen O’Keefe, Mark Koren, Théo Ryffel, JB Rubinovitz, Tamay Besiroglu, Federica Carugati, Jack Clark, Peter Eckersley, Sarah de Haas, Maritza Johnson, Ben Laurie, Alex Ingerman, Igor Krawczuk, Amanda Askell, Rosario Cammarota, Andrew Lohn, David Krueger, Charlotte Stix, Peter Henderson, Logan Graham, Carina Prunkl, Bianca Martin, Elizabeth Seger, Noa Zilberman, Seán Ó hÉigeartaigh, Frens Kroeger, Girish Sastry, Rebecca Kagan, Adrian Weller, Brian Tse, Elizabeth Barnes, Allan Dafoe, Paul Scharre, Ariel Herbert-Voss, Martijn Rasser, Shagun Sodhani, Carrick Flynn, Thomas Krendl Gilbert, Lisa Dyer, Saif Khan, Yoshua Bengio, Markus Anderljung, “Toward Trustworthy AI Development: Mechanisms for Supporting Verifiable Claims”, arXiv – DOI
The post 信頼できるAIシステムを作る３つの指針（OpenAI論文） first appeared on アイブン.
