高度な取得拡張生成システムの構築

前の記事では、ビジネスにおける生成 AI の主要なユース ケースの 1 つである "データを介したチャット" アプリケーションを構築するための 2 つのオプションについて説明しました。

• 大規模言語モデル (LLM) トレーニングを補足する取得拡張生成 (RAG) と、ユーザーのクエリとの類似性に基づいて取得して、完了のために LLM に渡すことができる検索可能記事のデータベース。
• 微調整。LLM のトレーニングを拡張して、問題ドメインについてさらに理解できるようにします。

前の記事では、各アプローチを使用するタイミング、各アプローチの長所と短所、その他のいくつかの考慮事項についても説明しました。

この記事では、RAG について詳しく説明します。具体的には、運用環境に対応したソリューションを作成するのに必要なすべての作業について説明します。

前の記事では、次の図を使用して RAG のステップまたはフェーズを示しました。

この表現は "単純な RAG" と呼ばれ、RAG ベースのチャット システムを実装するのに必要なメカニズム、役割、責任を最初に理解するのに役立つ方法です。

ただし、実際の実装では、記事、クエリ、および使用するための応答を準備するための、前処理と後処理の手順がこれより多くなっています。 次の図は、RAG のより現実的な表現であり、"高度な RAG" とも呼ばれます。

この記事では、次のように構成された、実際の RAG ベースのチャット システムにおける前処理と後処理の問題の種類を理解するための概念的なフレームワークを示します。

• インジェスト フェーズ
• 推論パイプライン フェーズ
• 評価フェーズ

大まかな概念として、キーワードとアイデアはコンテキストとして提供され、さらなる探索と研究の出発点となります。

データの取り込み

インジェストは主に、ユーザーの質問に答えるために簡単に取得できるよう、組織のドキュメントを格納することに関係しています。 課題は、ユーザーのクエリに最も一致するドキュメントの部分が、推論中に配置され、使用されるようにすることです。 照合は、主にベクトル化された埋め込みとコサイン類似性検索によって実現されます。 ただし、コンテンツの性質 (パターン、フォームなど) とデータ編成戦略 (ベクトル データベースに格納された場合のデータの構造) を理解することにより容易になります。

そのために、開発者は次のことを考慮する必要があります。

• コンテンツの前処理と抽出
• チャンク戦略
• チャンク編成
• 戦略を更新する

コンテンツの前処理と抽出

クリーンで正確なコンテンツは、RAG ベースのチャット システムの全体的な品質を向上させる最良の方法の 1 つです。 これを実現するには、開発者はまずインデックスを作成するドキュメントの形状と形式を分析します。 ドキュメントは、ドキュメントなどの指定されたコンテンツ パターンに準拠していますか? そうでない場合、ドキュメントはどのような種類の質問に答える可能性がありますか?

少なくとも、開発者はインジェスト パイプラインで次の手順を作成する必要があります。

• テキスト形式を標準化する
• 特殊文字を処理する
• 関連性のない古いコンテンツを削除する
• バージョン管理されたコンテンツのアカウント
• コンテンツ エクスペリエンスのアカウント (タブ、画像、テーブル)
• メタデータを抽出する

この情報の一部 (メタデータなど) は、推論パイプラインでの取得および評価プロセス中に使用するためにベクトル データベース内のドキュメントと共に保持したり、チャンクのベクトル埋め込みを誘導するためにテキスト チャンクと組み合わせたりするのに役立つ場合があります。

チャンク戦略

開発者は、長いドキュメントをより小さなチャンクに分割する方法を決める必要があります。 これにより、LLM に送信される補足コンテンツの関連性が向上し、ユーザーのクエリに正確に応答できます。 さらに、開発者は、取得時にチャンクを利用する方法を検討する必要があります。 これは、システム設計者が業界で使用されている手法に関していくつかの研究を行い、いくつかの実験を行う必要がある分野であり、組織の限られたキャパシティでテストする必要があります。

開発者は、以下の点を考慮する必要があります。

• チャンク サイズの最適化 - チャンクの理想的なサイズと、チャンクを指定する方法を決定します。 セクション単位 段落単位 文単位
• ウィンドウ チャンクの重なりとスライディング - コンテンツを個別のチャンクに分割する方法を決めます。 または、チャンクは重複しているか? または両方 (スライディング ウィンドウ)?
• Small2Big - 1 文のように細かいレベルでチャンクする場合、コンテンツは、隣接する文や段落を簡単に見つけられるように整理されますか? (「チャンク編成」を参照)。この追加情報を取得して LLM に提供すると、ユーザーのクエリに応答するとき、より多くのコンテキストが提供される可能性があります。

チャンク編成

RAG システムでは、ベクトル データベース内のデータの編成は、生成プロセスを強化する目的で関連情報を効率的に取得するために不可欠です。 開発者が考慮する可能性があるインデックス作成と取得戦略の種類を以下に示します。

• 階層インデックス - このアプローチでは、インデックスの複数のレイヤーを作成する必要があります。最上位レベルのインデックス (サマリー インデックス) を使用すると、検索領域が、関連している可能性のあるチャンクのサブセットにすばやく絞り込まれます。また、第 2 レベルのインデックス (チャンク インデックス) は、実際のデータへのより詳細なポインターを提供します。 この方法は、最初に概要インデックスをフィルター処理することにより、詳細インデックス内でスキャンするエントリの数を減らすため、取得プロセスを大幅に高速化できます。
• 特殊化インデックス - データの性質やチャンク間のリレーションシップに応じて、グラフ ベースやリレーショナル データベースなどの特殊なインデックスを使用できます。 例:
  • グラフ ベースのインデックスは、引用ネットワークやナレッジ グラフなど、取得を強化できる情報またはリレーションシップがチャンクに相互接続されている場合に役立ちます。
  • リレーショナル データベースは、チャンクが表形式で構造化されている場合に有効です。SQL クエリを使用して、特定の属性またはリレーションシップに基づいてデータをフィルター処理および取得することができます。
• ハイブリッド インデックス - ハイブリッド アプローチでは、複数のインデックス作成戦略を組み合わせて、それぞれの長所が活用されます。 たとえば、開発者は、最初のフィルター処理に階層インデックスを使用し、グラフ ベースのインデックスを使用して、取得中にチャンク間のリレーションシップを動的に調べることができます。

配置の最適化

取得したチャンクの関連性と精度を高めるため、回答する質問やクエリの種類に合わせて調整すると役立ちます。 これを実現するための 1 つの方法として、各チャンクに対して、そのチャンクがどの質問に回答するのが最適かを表す仮説的な質問を生成して挿入することができます。 これは、以下のいくつかの点で役立ちます。

• 照合の改善: 取得時、システムは受け取ったクエリをこれらの仮定の質問と比較して最適な一致を見つけ、フェッチされるチャンクの関連性を高めることができます。
• 機械学習モデルのトレーニング データ: これらの質問とチャンクの組み合わせは、RAG システムの基になる機械学習モデルを改善するためのトレーニング データとして機能し、どの種類の質問がどのチャンクで最適に回答されるかを学習するのに役立ちます。
• 直接クエリ処理: 実際のユーザー クエリが仮定の質問とかなり一致している場合、システムは対応するチャンクをすばやく取得して使用できるため、応答時間が短縮されます。

各チャンクの仮説的な質問は、取得アルゴリズムをガイドする一種の "ラベル" として機能し、より集中してコンテキストに対応します。 これは、チャンクがさまざまなトピックまたは種類の情報を対象としているシナリオで役立ちます。

更新方法

頻繁に更新されるドキュメントのインデックスを作成する必要がある場合、更新されたコーパスを維持して、レトリバー コンポーネント (ベクトル データベースに対してクエリを実行し、結果を返すシステム内のロジック) が最新の情報にアクセスできるようにすることが不可欠です。 このようなシステムでベクトル データベースを更新するための方法を以下に示します。

• 増分更新:
  • 一定の間隔: ドキュメントの変更頻度に応じて、一定の間隔 (毎日、毎週など) で更新をスケジュールします。 この方法により、データベースが定期的に更新されます。
  • トリガー ベースの更新: 更新によってインデックスの再作成がトリガーされるシステムを実装します。 たとえば、ドキュメントを変更または追加すると、影響を受けるセクションのインデックスの再作成が自動的に開始される可能性があります。
• 部分更新:
  • 選択的インデックス再作成: データベース全体のインデックスを再作成する代わりに、変更されたコーパスの部分のみ選択的に更新します。 これは、特に大規模なデータセットの場合、完全なインデックス再作成よりも効率が高くなります。
  • 差分エンコード: 既存のドキュメントとその更新されたバージョンの違いのみ格納します。 このアプローチでは、変更されていないデータを処理する必要がないようにすることで、データ処理の負荷が軽減されます。
• バージョン管理:
  • スナップショット作成: 異なる時点でドキュメント コーパスのバージョンを維持します。 これにより、システムは必要に応じて以前のバージョンを元に戻したり参照したりすることができるため、バックアップ メカニズムが提供されます。
  • ドキュメントのバージョン管理: バージョン管理システムを使用して、ドキュメントの変更を体系的に追跡します。 これは、変更の履歴を維持するのに役立ち、更新プロセスを簡略化できます。
• リアルタイムの更新:
  • ストリーム処理: ストリーム処理テクノロジを使用することにより、ドキュメントに対する変更が行われたら、ベクトル データベースをリアルタイムで更新します。 これは、情報タイムラインが最も重要な意味を持つアプリケーションにとって重要となることがあります。
  • ライブ クエリ: 事前インデックス付きベクトルのみに依存するのではなく、最新の応答に対してライブ データにクエリを実行するメカニズムを実装します。これをキャッシュされた結果と組み合わせることにより、効率が向上する可能性があります。
• 最適化手法:
  • バッチ処理: 変更を累積し、それらをバッチ処理してリソースの使用を最適化することで、頻繁な更新によって発生するオーバーヘッドを軽減します。
  • ハイブリッド アプローチ: ドキュメント コーパスの主要な更新や構造上の変更に対して、マイナーな変更に増分更新を使用したり、完全なインデックス再作成を使用したりするなど、さまざまな方法を組み合わせます。

適切な更新方法を選択するか、方法を組み合わせるかは、ドキュメント コーパスのサイズ、更新の頻度、リアルタイム データの必要性、リソースの可用性などの特定の要件によって異なります。 各アプローチには、複雑さ、コスト、更新の待機時間という点でトレードオフがあるため、アプリケーションの具体的なニーズに基づいてこれらの要因を評価することが不可欠です。

推論パイプライン

記事がチャンクされて、ベクトル化され、ベクトル データベースに格納されたので、焦点は完了時の課題に変わります。

• ユーザーのクエリは、ユーザーが探している結果をシステムから取得するよう記述されていますか?
• ユーザーのクエリはポリシーに違反していますか?
• ベクトル データベース内で最も近い一致を見つける可能性を高めるには、ユーザーのクエリをどのように書き換えればよいですか?
• クエリ結果を評価し、記事がクエリに合わせてチャンクされていることを確認するにはどうすればよいですか?
• LLM に渡す前にクエリ結果を評価および変更して、LLM の完了に最も関連性の高い詳細が確実に含まれるようにするにはどうすればよいですか?
• LLM の応答を評価して、LLM の完了がユーザーの元のクエリに確実に応答するようにするにはどうすればよいですか?
• LLM の応答がポリシーに準拠していることを確認するにはどうすればよいですか?

ご覧のように、開発者が考慮する必要がある多くのタスクは、主に以下のような形で存在しています。

• 入力を前処理して、目的の結果が得られる可能性を最適化する
• 出力を後処理して目的の結果を確実に得る

推論パイプライン全体がリアルタイムで実行されている点に注意してください。 前処理および後処理のステップを実行するロジックを設計する正しい方法は 1 つではありませんが、プログラミング ロジックと LLM への追加の呼び出しの組み合わせになる可能性が高くなります。 最も重要な考慮事項の 1 つは、可能な限り正確で準拠したパイプラインを構築することと、それを実現するために必要なコストおよび待機時間のトレードオフです。

各段階を見て、特定の方法を見つけましょう。

クエリの前処理ステップ

クエリの前処理は、次の図に示すように、ユーザーがクエリを送信した直後に発生します。

これらの手順の目的は、ユーザーがシステムのスコープ内で質問していること (意図しない操作を行うためにシステムを "ジェイルブレイク" しようとしていないこと) を確認し、ユーザーのクエリを準備して、コサイン類似度/"ニアレストネイバー" 検索を使用して、可能な限り最良の記事チャンクを見つける可能性を高めることです。

ポリシー チェック - この手順には、特定のコンテンツを識別、削除、フラグ付け、または拒否するロジックが含まれる可能性があります。 たとえば、個人を特定できる情報の削除、ののしり言葉の削除、"ジェイルブレイク" 試行の特定などがあります。 ジェイルブレイクとは、モデルの組み込みの安全、倫理、または運用に関するガイドラインを回避または操作するためにユーザーが使用する可能性のある方法を指します。

クエリの書き直し - 頭字語の拡張やスラングの削除から、質問を言い直して、高度な概念と原則を抽出するためにより抽象的に質問する ("ステップバック プロンプト") など、あらゆることが考えられます。

ステップバック プロンプトのバリエーションは、LLM を使用してユーザーの質問に回答し、その応答の埋め込み (架空のドキュメント埋め込み) を作成し、その埋め込みを使用してベクトル データベースに対して検索を実行する架空のドキュメント埋め込み (HyDE) です。

サブクエリ

この処理ステップは、元のクエリに関連しています。 元のクエリが長く複雑な場合、プログラムによって複数の小さなクエリに分割し、すべての応答を結合すると便利です。

たとえば、特に物理学の分野における科学的発見に関連する質問を考えてみましょう。 ユーザーのクエリは、"現代物理学により大きな貢献をしたのは、アルバート・アインシュタインですか、それともニールス・ボーアですか?" のようになるかもしれません。

"大きな貢献" は主観的かつ多面的な場合があるため、このクエリを直接処理するのは複雑になる可能性があります。 サブクエリに分割すると、管理しやすくなります。

1. サブクエリ 1: "現代物理学に対するアルバート・アインシュタインの重要な貢献は何ですか?"
2. サブクエリ 2: "現代物理学に対するニールス・ボーアの重要な貢献は何ですか?"

これらのサブクエリの結果は、各物理学者による主な理論と発見を詳しく記述します。 次に例を示します。

• アインシュタインの場合、貢献には相対性理論、光電効果、E=mc^2 などがあります。
• ボーアの場合、貢献には、水素原子のモデル、量子力学に関する彼の研究、補完の原則が含まれる可能性があります。

これらの貢献の概要が示されたら、以下の内容を評価して判断できます。

3. サブクエリ 3: "アインシュタインの理論は現代物理学の発展にどのように影響を与えましたか?"
4. サブクエリ 4: "ボーアの理論は現代物理学の発展にどのように影響を与えましたか?"

これらのサブクエリは、アインシュタインの理論がどのように宇宙論と量子理論の進歩につながったか、ボーアの功績が原子構造と量子力学の理解にどのように貢献したかなど、各科学者の功績が分野に与えた影響を探ります。

これらのサブクエリの結果を組み合わせることで、言語モデルは、理論上の進歩の程度と影響に基づいて、現代の物理学に対してより重要な貢献をした人物に関するより包括的な応答を形成することができます。 この方法は、より具体的で回答可能なコンポーネントを処理し、それらの結果を一貫した回答に合成することにより、元の複雑なクエリを簡略化します。

クエリ ルーター

組織がコンテンツのコーパスを複数のベクトル ストアまたは取得システム全体に分割することを決定している可能性があります。 その場合、開発者はクエリ ルーターを使用できます。これは、提供されたクエリに基づいて使用するインデックスまたは取得エンジンをインテリジェントに決定するメカニズムです。 クエリ ルーターの主な機能は、特定のクエリに最適な回答を提供できる最適なデータベースまたはインデックスを選択して、情報の取得を最適化することです。

通常、クエリ ルーターは、クエリがユーザーによって作成された後、取得システムに送信される前の時点で機能します。 簡略化されたワークフローを以下に示します。

1. クエリ分析: LLM または別のコンポーネントが、受け取ったクエリを分析して、その内容、コンテキスト、必要な情報の種類を把握します。
2. インデックスの選択: クエリ ルーターが、分析に基づいて、使用可能な複数のインデックスから 1 つ以上を選択します。 各インデックスは、さまざまな種類のデータやクエリに最適化される可能性があります。たとえば、ファクト クエリに適している場合もあれば、意見や主観的なコンテンツを提供するのに優れている場合もあります。
3. クエリのディスパッチ: 選択したインデックスにクエリがディスパッチされます。
4. 結果の集計: 選択したインデックスからの応答が取得され、場合によっては集計または処理されて、包括的な回答が形成されます。
5. 回答の生成: 最後の手順では、取得した情報に基づいてコヒーレント応答が生成され、場合によっては複数のソースからコンテンツが統合または合成されます。

組織では、以下のユース ケースに対して複数の取得エンジンまたはインデックスを使用する場合があります。

• データの種類の特殊化: 一部のインデックスは、ニュース記事、学術論文、さらに一般的な Web コンテンツや特定のデータベース (医療情報や法的情報など) に特化している場合があります。
• クエリの種類の最適化: 事実の迅速な検索 (日付、イベントなど) に最適化されているインデックスもあれば、複雑な推論タスクや深いドメイン知識を必要とするクエリに適しているインデックスもあります。
• アルゴリズムの違い: ベクトルベースの類似性検索、従来のキーワードベースの検索、より高度なセマンティック理解モデルなど、さまざまな検索アルゴリズムが異なるエンジンで使用される場合があります。

医療アドバイザリ コンテキストで使用される RAG ベースのシステムを想像してみてください。 システムは複数のインデックスにアクセスできます。

• 詳細かつ技術的な説明のために最適化された医学研究論文のインデックス。
• 症状と治療の実際の例を提供する臨床ケース スタディ インデックス。
• 基本的なクエリと公衆衛生情報の一般的な正常性情報インデックス。

ユーザーが新薬の生化学効果に関する技術的な質問をした場合、クエリ ルーターは、その深さと技術的な焦点に基づいて、医学研究論文インデックスを優先する可能性があります。 しかし、一般的な病気の典型的な症状に関する質問の場合、内容が幅広く理解しやすいため、一般的な健康指標が選択される場合があります。

取得後の処理ステップ

取得後の処理は、次の図に示すように、取得元コンポーネントがベクトル データベースから関連するコンテンツ チャンクを取得した後に発生します。

候補のコンテンツ チャンクを取得したら、次のステップとして、記事のチャンクが LLM プロンプトを拡張するときに役立つことを検証し、LLM に表示されるプロンプトの準備を開始します。

開発者は、プロンプトのいくつかの側面を考慮する必要があります。 補足情報が多すぎるプロンプトでは、一部 (おそらく最も重要な情報) が無視される可能性があります。 同様に、無関係な情報を含むプロンプトは、回答に過度の影響を与える可能性があります。

もう 1 つの考慮事項は、干し草の山の中の針問題です。これは、プロンプトの最初と最後のコンテンツが、中間のコンテンツよりも LLM にとって大きな重みを持つという、一部の LLM の既知の癖を指す用語です。

最後に、LLM のコンテキスト ウィンドウの最大長と、非常に長いプロンプトを完了するのに必要なトークンの数 (特に大規模なクエリを処理する場合) を考慮する必要があります。

これらの問題に対処するため、取得後処理パイプラインには以下のステップが含まれる場合があります。

• 結果のフィルター処理 - このステップでは、開発者はベクトル データベースによって返される記事チャンクがクエリに関連していることを確認します。 そうでない場合、LLM のプロンプトを作成するときに結果は無視されます。
• 再ランク付け - ベクトル ストアから取得した記事チャンクをランク付けして、プロンプトの端 (開始と終了) の近くに関連する詳細が確実に表示されるようにします。
• プロンプト圧縮 - LLM に送信する前に、複数の記事チャンクを組み合わせて 1 つの圧縮プロンプトにまとめるために設計された、小規模で安価なモデルを使用します。

完了後の処理ステップ

完了後の処理は、以下の図に示すように、ユーザーのクエリとすべてのコンテンツ チャンクが LLM に送信された後に発生します。

LLM によってプロンプトが完了したら、応答が正確であることを確認するために、完了を検証します。 完了後の処理パイプラインには、以下のステップが含まれる場合があります。

• ファクト チェック - これは多くの形式を取る可能性がありますが、その目的は、事実として提示された記事で行われた特定のクレームを特定し、その事実を正確にチェックすることです。 ファクト チェック ステップが失敗した場合、より適切な回答を得るために LLM に再度クエリを実行するか、ユーザーにエラー メッセージを返すことが適切である可能性があります。
• ポリシー チェック - これは、ユーザーと組織のどちらに対しても、回答に有害なコンテンツが含まれていないことを確認するための最後の防御線です。

評価

非決定論的システムの結果を評価することは、多くの開発者が使用している単体テストや統合テストほど簡単ではありません。 考慮すべきいくつかの要因があります。

• ユーザーは取得している結果に満足していますか?
• ユーザーは質問に対して正確な回答を得ていますか?
• ユーザー フィードバックをキャプチャするにはどうすればよいですか? ユーザー データに関して収集できるデータを制限するポリシーはありますか?
• 不十分な回答に関する診断のため、質問に答えるすべての作業を可視化していますか? 根本原因分析を実行できるよう、入力と出力の推論パイプラインに各ステージのログを保持しますか?
• 結果の回帰や劣化を起こさずにシステムを変更するにはどうすればよいですか?

ユーザーからのフィードバックのキャプチャと操作

前述のように、開発者は、場合によっては組織のプライバシー チームと連携して、特定のクエリ セッションでフォレンジクスと根本原因分析を可能にするため、フィードバック キャプチャ メカニズムや、テレメトリ、ログなどを設計する必要があります。

次のステップでは、評価パイプラインを開発します。 評価パイプラインの必要性は、AI システムによって提供される応答の逐語的なフィードバックと根本原因を分析する際の、複雑さと時間を要する性質から生じます。 この分析は、AI クエリがどのように結果を生成したかを理解するためにすべての応答を調べ、ドキュメントから使用されるコンテンツ チャンクの妥当性をチェックし、これらのドキュメントを分割するために採用された戦略を確認するため、非常に重要です。

さらに、結果を向上させる可能性のある追加の前処理または後処理ステップを検討します。 この詳細な調査では、多くの場合、特にユーザーのクエリに応じて適切なドキュメントが存在しない場合、コンテンツのギャップが明らかになります。

そのため、評価パイプラインを構築することは、これらのタスクの規模を効果的に管理するため不可欠になります。 効率的なパイプラインでは、カスタム ツールを使用して、AI によって提供される回答の品質を概算するメトリックを評価します。 このシステムは、ユーザーの質問に対して特定の回答が与えられた理由、その回答の生成に使用されたドキュメント、およびクエリを処理する推論パイプラインの有効性を判断するプロセスを合理化します。

ゴールデン データセット

RAG チャット システムのような非決定論的システムの結果を評価する方法の 1 つとして、"ゴールデン データセット" を実装できます。 ゴールデン データセットは、承認された回答、メタデータ (トピックや質問の種類など)、回答の基礎となる真理として役立つソース ドキュメントへの参照、さらにはバリエーション (ユーザーが同じ質問をする可能性のある多様性を捉えるために、異なる言い回しを使用する) を含む、キュレーションされた一連の質問です。

"ゴールデン データセット" は "最適なシナリオ" を表しており、開発者がシステムを評価してパフォーマンスを確認し、新しい機能や更新プログラムを実装するときに回帰テストを実行可能にします。

損害の評価

損害モデリングは、潜在的な損害を予測して、個人にリスクをもたらす可能性のある製品の欠陥を発見し、そのようなリスクを軽減するための積極的な戦略を策定することを目的とした手法です。

テクノロジ (特に AI システム) の影響を評価することが目的のツールには、提供されたリソースに記載されている損害モデリングの原則に基づいて、いくつかの重要なコンポーネントが用意されています。

損害評価ツールの主な機能は、以下のとおりです。

1. 利害関係者の識別: このツールは、直接的なユーザー、間接的に影響を受ける当事者、将来の世代や環境問題などの非人間的要因など、テクノロジの影響を受けるさまざまな利害関係者をユーザーが特定し、分類するのに役立ちます。

2. 損害カテゴリと説明: プライバシーの喪失、感情的な苦悩、経済的搾取など、潜在的な損害の包括的な一覧が含まれます。 このツールは、テクノロジがこれらの損害を引き起こす可能性がある方法を示すさまざまなシナリオをユーザーにガイドし、意図した結果と意図しない結果の両方を評価するのに役立ちます。

3. 重大度と確率の評価: このツールを使用すると、ユーザーは特定された各損害の重大度と確率を評価し、最初に対処する問題に優先順位を付けられます。 これには定性的評価が含まれる可能性があり、利用可能な場合はデータによってサポートされる可能性があります。

4. 軽減戦略: 損害を特定して評価すると、このツールにより、潜在的な軽減戦略が提案されます。 これには、システム設計の変更、より多くのセーフガード、または特定されたリスクを最小限に抑える代替テクノロジ ソリューションが含まれる場合があります。

5. フィードバック メカニズム: このツールには、利害関係者からのフィードバックを収集するメカニズムを組み込む必要があり、これにより、危害評価プロセスが動的になり、新しい情報や視点に応答できるようになります。

6. ドキュメントとレポート: このツールは、透明性と説明責任を高めるため、危害評価プロセス、調査結果、および潜在的なリスクの軽減のために講じられたアクションを文書化した詳細なレポートの作成を容易にします。

これらの機能は、リスクの特定と軽減に役立つだけでなく、最初から広範な影響を考慮することで、より倫理的かつ責任ある AI システムの設計にも役立ちます。

詳細については、以下を参照してください:

• 損害の評価の基礎
• 損害の種類

セーフガードのテストと検証

この記事では、RAG ベースのチャット システムが悪用または侵害される可能性を低減することを目的としたいくつかのプロセスについて説明しました。 レッド チーミングは、軽減策が効果的であることを保証する上で重要な役割を果たします。 レッド チーミングでは、潜在的な弱点や脆弱性を明らかにするため、アプリケーションを目的とした敵対者のアクションをシミュレートします。 このアプローチは、ジェイルブレイクの重大なリスクに対処する上で特に重要です。

RAG ベースのチャット システムのセーフガードを効果的にテストして検証するには、開発者は、これらのガイドラインをテストできるさまざまなシナリオで、これらのシステムを厳密に評価する必要があります。 これにより、堅牢性が保証されるだけでなく、定義された倫理基準と運用手順に厳密に準拠するようシステムの応答を微調整するのにも役立ちます。

アプリケーション設計の決定に影響を与える可能性がある最終的な考慮事項

アプリケーションの設計上の決定に影響を与える、この記事で考慮すべき事項とその他のポイントの簡単な一覧を以下に示します。

• 設計における生成 AI の非決定的な性質を確認して、出力の変動性を計画し、応答の一貫性と関連性を確保するためのメカニズムを設定します。
• 待ち時間とコストの増加の可能性に対するユーザー プロンプトの前処理の利点を評価します。 送信前にプロンプトを簡略化または変更すると、応答の品質が向上する可能性がありますが、応答サイクルの複雑さと時間が増加する可能性があります。
• LLM 要求を並列化してパフォーマンスを高める戦略を調査します。 この方法では待ち時間が短縮される可能性がありますが、複雑さとコストへの影響が生じる可能性を回避するため、慎重に管理する必要があります。

生成型 AI ソリューションの構築の実験をすぐに開始する場合は、「Python 用の独自のデータ サンプルを使用してチャットを開始する」を参照することをお勧めします。 このチュートリアルには、.NET、Java、JavaScript でも使用できるバージョンがあります。