アームチェアアーキテクト: 責任ある AI とは何ですか?

このブログでは、私たちのホストが、 デビッド・ブランク・エデルマン そして私たちのアームチェア建築家 ウリ・ホーマン そして エリック・シャラン 責任あるAIとは何かを議論する。これは前回の議論に基づいている。 アームチェアアーキテクト: アプリケーションにおける AI の倫理的かつ責任ある使用に関する考慮事項。

ここでは、「責任ある AI とは何か」の意味とそれが何を意味するのかを深く掘り下げていきます。クールなコンセプトのように聞こえますが、必ずしも十分に理解されているとは限らないため、アームチェア アーキテクトに意見を聞いてみましょう。

責任あるAIの誕生

ウリの視点から見ると、責任あるAIは、主に統計と機械学習機能に基づいて決定を下すアルゴリズムの初期の使用から生まれました。彼が提供したAIとデータを使用したクレジットカードの決定の例がありました。 アームチェアアーキテクト: AI 憲章は価値があるか? そのブログで、彼は AI の「小さな決定」が信用枠を拒否された人に影響を与える可能性があることを指摘しました。AI とデータを使用して信用決定を行う場合、データが正確であること、データに偏りがないこと、申請者を公正に評価していることを確認する必要があります。

これが責任ある AI の運動の始まりであり、その概念は透明性、公平性、そしてこれらすべての要素を混ぜ合わせたバイアスに関するものです。現在、大規模言語モデル (LLM) では、統計モデルが特定のドメインで専門家によって管理されていたのに対し、より広範囲に使用されるようになったため、さらに重要になっています。

LLM や ChatGPT や Bard などのアプリケーションは、地球上のほぼすべての人にとって AI の使用を民主化し、今では誰もが AI を使用しています。AI をプロバイダーおよびコンシューマーとして責任を持って使用するという概念は、統計モデルだけを検討していたときよりも重要になっています。

予期せぬ結果に注意
Eric は Uli の説明に 100% 同意しており、彼の観点からは、意図しない結果という観点から考えています。有害で、偏った、または妥協した LLM 実装を構築しようとする人はいません。責任のある当事者が人々に危害を加えたくないと仮定すると、Eric の主なポイントは、意味のあることを行う前に、意図しない結果を確実に認識しておくことです。

意図しない害や意図しない結果の例としては、個人のサブグループに対する偏見、ユースケースの定義に基づいてこれまで見たことのない使用パターンなどが挙げられます。実装され、稼働し、世界中で使用と人気が拡大すると、たとえば、アプリの中核にあるこの英語で訓練された LLM について考慮していなかった文化的規範や行動が存在する可能性があります。

の中に 前のブログ 説明可能なAIについて議論がありましたが、大規模な言語モデルを検討する場合、何千、何百万もの変数を持つ説明可能なAIは利用できません。しかし、説明可能性ではなく、観測可能性に進むことはできます。つまり、入力と出力が（観測可能性）であることはわかっていても、LLMが入力を処理して出力を作成する方法を完全に説明できない可能性があります。これが、生きているAIが AI憲章先ほど説明した r は貴重です。

LLMの進化に合わせて実践と手順を継続的に更新する

LLM は常に進化しており、できることに関して「ゴールポストを動かす」という表現に似ています。したがって、すべての組織とすべてのチームが実装する必要がある、一連の注意深い実践と手順とレビューが継続的に存在する必要があります。LLM が改良され、より広く利用され、より多くの場所で実装されるにつれて、ゴールポストは動き続けます。

そこに何が入っているかについて、引き続き非常に注意を払う必要があります。自分の専門知識のライブラリに何を与え、そこから何が出てくるのか、人々がそれとどのようにやり取りするかを研究し、プロンプトや応答のログを保持し、継続的かつ注意深く分析します。

Uli の視点から見ると、AI の責任あるユーザーになることは可能であるだけでなく、義務でもあります。Eric が言ったように、このモデルを世界に公開している以上、このモデルが何をするか、何をしないかの最終的な責任と説明責任はユーザーにあるため、責任を負わなければなりません。これが内部世界であるか外部世界であるかは、実際には重要ではありません。したがって、この責任ある AI 機能をどのように進めて推進するかを考えるのはユーザー次第です。

旧世界とLLMの新世界

LLM の世界では、これが少し複雑になっています。以前の世界では、モデルがどのように機能するか、モデルとは何か、モデルが動作するデータは何か、アプリケーションの使用方法など、すべてユーザーが管理していました。そのため、機能をバインドしている場合でも、これらすべての要素をユーザーが管理していました。

新しい世界では、システムがどのようなデータでトレーニングされたのか、アルゴリズムはわからない LLM を購入するかもしれません。つまり、ブラック ボックスを購入することになりますが、ブラック ボックスは非常に強力です。OpenAI、Gemini、その他のモデルは、驚くべき方法で質問に答えることができることを示しています。これらのモデルには多くの知識があり、それらを使いたいと思っても、あなたは依然として責任ある AI ユーザーです。

責任ある AI ユーザーになるにはどうすればよいのでしょうか?

責任ある AI ユーザーになるには、何をコントロールできるでしょうか? たとえば、太陽が昇ったり沈んだりすると腹が立つという人がいます。残念ながら、太陽が昇ったり沈んだりすることをコントロールすることはできません。ただし、どのモデルを使用するかはコントロールできます。

ブラック ボックス モデルを選択したので、モデルをトレーニングしたデータ セットやアルゴリズムのトレーニング方法を制御できないと仮定しましょう。これは、太陽が昇ったり沈んだりするのと同じように、制御できません。制御できるのは、モデルに質問すること、つまりプロンプトです。制御できるプロンプトを設計します。プロンプトは構造化されているため、制御できると言えます。プロンプトを使用する人間が送信するテキストは制御できませんが、それが有効な言語か不適切な言語かなどを理解するという点で、特定の操作を行うことができます。つまり、これらすべてを行うことができます。

これで、私が設計したプロンプトが責任あるガイドラインに従っていることをユーザーに対して証明できると言えます。これは証明できるものであり、その後、プロンプトはブラック ボックスに入り、処理され、戻りパスで応答を構造化できます。一方、LLM は、プロンプトが送信され、テキストが出力されていることを通知します。

プロンプトエンジニアリングの使い方

プロンプト エンジニアリングを使用する方法は多数あります。たとえば、モデルが JSON で応答するように強制できます。つまり、JSON スキーマを取得し、スキーマに適合しないものはすべて自動的に拒否され、その JSON スキーマを問題として推論して、返されたコンテンツが正しいものであり、偏りがないことを確認できます。その後、それをアプリケーションにフィードできます。

説明可能なAIから観察可能なAIへ
つまり、これは責任ある AI についての異なる考え方であり、説明可能な AI (透明なアルゴリズム、透明なデータセット) から、機械を理解するのではなく入力と出力を観察する観察可能な AI へと移行します。

責任あるAIに対する建築家の影響

Uli の考え方は、Azure OpenAI やその他のモデルを備えた Microsoft などの責任ある AI プロバイダーを選択し、選択したら次の操作に進むというものです。

特定の言葉や暴力などのプロンプトをフィルタリングしたり、応答コンテンツの安全性を確認したりするなどのテクニックやテクノロジーを使用します。最後に、次のようなオープンソーステクノロジーがあります。 タイプチャット、 どれが 2023年7月に導入 これは、JSON を使用して構造化された方法でプロンプトと応答を構築するのに役立ちます。これは、応答タイプの早期バインディングであるスキーマ化された応答で、アプリケーションが簡単に使用でき、簡単に検証できることを意味します。一部の LLM は同じルートを採用し始めており、プロンプト内で、LLM にインライン要求を実行して、たとえば JSON で応答することができます。

つまり、Uli は適切なモデルとパートナーを選び、コンテンツの安全性について考え、TypeChat などの機能を通じてアプリケーション層について考えることを推奨しています。他にも方法はありますが、これは非常に具体的な方法です。

事前フィルタリングとモデレーション

Eric は、Uli が概説した実装手順は素晴らしいと考えており、彼の見解をいくつか付け加えたいと考えています。彼にとって、大きな問題は事前フィルタリングとモデレーションに関するものです。プロバイダーに組み込まれているコンテンツ モデレーション ツールがある場合はそれを活用し、ホストされている基盤モデル プロバイダーが潜在的に有害または無効な出力をフィルタリングしてフラグ付けするために必要なものとともに、独自のコンテンツ モデレーション ツールを構築する必要があるかどうかを決定します。

2 つ目は、API のアクセスと制御です。アーキテクチャの観点からは、知らないうちに誰かが舞台裏でモデルとやりとりすることは望ましくありません。そのため、特定の制約とパラメータをプログラムで定義するようにしてください。

彼は、現在多くのモデルが実際にリターンペイモードになっているか、応答に関連付けられた信頼区間を指定しており、それが可能な場合はコード内でエラー追跡を開始できると述べました。

たとえば、応答が返ってきて、それが 30% で、モデルでさえも「あまり良くない」と言っているような場合、実装の観点から例外を追跡し、微調整とカスタマイズを行うことができます。データ セットに基づいてモデルを微調整する方法を探ります。

ライブラリの観点から、モデルに提供しているデータは何ですか。モデルがそのデータを参照するときに、偏った情報やトークン化された情報、トークン化されていない情報、または PII などにアクセスしているかどうかを確認します。

リソース

以下のエピソードを視聴するか、 アームチェアアーキテクツシリーズの他のエピソードを見る。