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

前の記事では、ビジネスにおけるジェネレーティブ 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 の応答がポリシーに準拠していることを確認するにはどうすればよいですか?

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

• 必要な結果を得る可能性を最適化するための入力の前処理
• 出力を後処理して目的の結果を確実に得る

推論パイプライン全体がリアルタイムで実行されています。 前処理と後処理の手順の設計には適切な方法はありませんが、プログラミング ロジックと他の 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 でも使用できるバージョンがあります。