RAG チェーンの品質を向上させる

この記事では、RAG チェーンのコンポーネントを使用して RAG アプリの品質を向上させる方法について説明します。

RAG チェーンは、ユーザー クエリを入力として受け取り、そのクエリに基づいて関連情報を検索し、検索したデータに基づいて適切な応答を生成します。 RAG チェーン内の正確な手順はユース ケースと要件によって大きく異なりますが、RAG チェーンを構築する際に考慮すべき重要なコンポーネントは次のとおりです。

1. クエリの理解: ユーザー クエリを分析および変換して、意図をより適切に表現し、フィルターやキーワードなどの関連情報を抽出して、検索プロセスを改善します。
2. 検索: 検索クエリを使用して、最も関連性の高い情報のチャンクを検索します。 非構造化データの場合、これは通常、セマンティックまたはキーワードベースの検索の 1 つまたは組み合わせで行われます。
3. プロンプト拡張: 検索した情報と手順とユーザー クエリを組み合わせて、高品質の応答を生成するために LLM をガイドします。
4. LLM: パフォーマンス、待機時間、コストを最適化するため、またはバランスをとるために、アプリケーションに最適なモデル (およびモデル パラメーター) を選択します。
5. 後処理とガードレール: 追加の処理手順と安全対策を適用して、LLM で生成された応答がトピックに沿っており、事実と整合性があり、特定のガイドラインまたは制約に準拠していることを確認します。

「品質修正を繰り返し実装して評価する」では、チェーンのコンポーネントを反復処理する方法を紹介します。

クエリの理解

ユーザー クエリを検索クエリとして直接使用すると、一部のクエリで機能する場合があります。 ただし、一般に、検索手順の前にクエリを再編成すると便利です。 クエリの理解は、意図をより適切に表現し、関連情報を抽出し、最終的に後続の検索プロセスを支援するために、ユーザー クエリを分析および変換するための、チェーンの最初にあるステップ (または一連のステップ) で構成されます。 検索を改善するためにユーザー クエリを変換する方法は次のとおりです。

1. クエリの書き換え: クエリの書き換えは、ユーザー クエリを元の意図をより適切に表す 1 つ以上のクエリに変換する必要があります。 目標は、検索ステップにより最も関連性の高いドキュメントを見つける可能性を高める方法で、クエリを再編成することです。 これは、検索ドキュメントで使用される用語と直接一致しない可能性がある複雑またはあいまいなクエリを処理する場合に特に便利です。

   例 :

   • マルチターンチャットで会話履歴を言い換える
   • ユーザーのクエリでスペル ミスを修正する
   • ユーザー クエリ内の単語または語句を同意語に置き換えて、より広範囲の関連ドキュメントをキャプチャする

   重要

   クエリの書き換えは、検索コンポーネントの変更と組み合わせて行う必要があります

2. フィルター抽出: 場合によっては、検索結果を絞り込むために使用できる特定のフィルターまたは条件がユーザー クエリに含まれていることがあります。 フィルター抽出では、クエリからこれらのフィルターを識別して抽出し、追加のパラメーターとして検索手順に渡します。 これにより、使用可能なデータの特定のサブセットに焦点を当てることで、検索されるドキュメントの関連性を向上させることができます。

   例 :

   • クエリに記載されている特定の期間 ("過去 6 か月の記事" や "2023 年のレポート" など) を抽出する。
   • クエリ内の特定の製品、サービス、またはカテゴリ ("Databricks Professional Services" や "ノート PC" など) のメンションを識別する。
   • 市区町村名や国コードなど、クエリから地理的エンティティを抽出する。

   Note

   フィルター抽出は、メタデータ抽出データ パイプラインおよび検索チェーンコンポーネントの両方に対する変更と組み合わせて行う必要があります。 メタデータ抽出手順では、ドキュメントまたはチャンクごとに関連するメタデータ フィールドが使用できることを確認し、抽出されたフィルターを受け入れて適用するために検索手順を実装する必要があります。

クエリの書き換えとフィルター抽出に加えて、クエリの理解におけるもう 1 つの重要な考慮事項は、1 つの LLM 呼び出しを使用するか、複数の呼び出しを使用するかです。 慎重に作成されたプロンプトで 1 回の呼び出しを使用すると効率的ですが、クエリ理解プロセスを複数の LLM 呼び出しに分割すると、結果が改善される場合があります。 ところで、これは、多くの複雑なロジックステップを単一のプロンプトに実装しようとしている場合に、一般的に適用できる経験則です。

たとえば、1 つの LLM 呼び出しを使用してクエリの意図を分類し、2 つ目は関連エンティティを抽出し、3 つ目は抽出された情報に基づいてクエリを書き換えます。 この方法ではプロセス全体の待機時間が長くなる可能性がありますが、よりきめ細かな制御が可能になり、検索したドキュメントの品質が向上する可能性があります。

サポート ボットのマルチステップ クエリの理解

複数ステップのクエリ理解コンポーネントによりカスタマー サポート ボットが検索される方法を次に示します。

1. 意図の分類: LLM を使用して、ユーザーのクエリを定義済みのカテゴリ ("製品情報"、"トラブルシューティング"、"アカウント管理" など) に分類します。
2. エンティティ抽出: 識別された意図に基づいて、別の LLM 呼び出しを使用して、製品名、報告されたエラー、アカウント番号などの関連エンティティをクエリから抽出します。
3. クエリの書き換え: 抽出された意図とエンティティを使用して、元のクエリをより具体的で対象指定された形式に書き換えます。例: "RAG チェーンがモデル提供でデプロイに失敗しています。次のエラーが表示...."。

取得

RAG チェーンの検索コンポーネントは、検索クエリで最も関連性の高い情報のチャンクを検索する役割を担います。 非構造化データのコンテキストでは、通常、検索にはセマンティック検索、キーワードベースの検索、メタデータ フィルターのうち 1 つまたはこれらの組み合わせが含まれます。 検索戦略の選択は、アプリケーションの特定の要件、データの性質、処理が想定されるクエリの種類によって異なります。 次のオプションを比較してみましょう。

1. セマンティック検索: セマンティック検索では、埋め込みモデルを使用して、テキストの各チャンクをセマンティックの意味をキャプチャするベクトル表現に変換します。 検索クエリのベクトル表現とチャンクのベクトル表現を比較することで、セマンティック検索では、クエリの正確なキーワードが含まれていない場合でも、概念的に似たドキュメントを検索できます。
2. キーワードベースの検索: キーワードベースの検索では、検索クエリとインデックス付きドキュメント間の共有単語の頻度と分布を分析して、ドキュメントの関連性が決定されます。 クエリとドキュメントの両方に同じ単語が出現する頻度が高いほど、そのドキュメントに割り当てられる関連性スコアが高くなります。
3. ハイブリッド検索: ハイブリッド検索では、2 段階認証プロセスを採用して、セマンティックおよびキーワードベース検索の両方の長所を組み合わせます。 まず、セマンティック検索を実行して、概念的に関連するドキュメントのセットを検索します。 次に、この縮小されたセットにキーワードベースの検索を適用して、正確なキーワードの一致に基づいて結果をさらに絞り込みます。 最後に、両方の手順のスコアを組み合わせてドキュメントをランク付けします。

検索戦略を比較する

次の表は、これらの各検索方法を相互に比較したものです。

	セマンティック検索	キーワード検索	ハイブリッド検索
サンプルの説明	クエリと潜在的なドキュメントに同じ概念があれば、それらには関連性があります。	同じ単語がクエリと潜在的なドキュメントに表示される場合は、それらは関連します。 ドキュメント内に、クエリからの単語が多いほど、そのドキュメントの関連性が高くなります。	セマンティック検索とキーワード検索を両方とも実行し、結果を結合します。
ユース ケースの例	ユーザー クエリが製品マニュアルの単語と異なる場合のカスタマー サポート。 例: "電話をオンにする方法は?" に対して、 マニュアルのセクションに "電源を切り替える" と書かれている場合。	クエリに特定の説明的ではない技術用語が含まれている場合のカスタマー サポート。 例: "モデル HD7-8D は何をしますか?"	セマンティックおよび技術用語の両方を組み合わせたカスタマー サポート クエリ。 例: "HD7-8D の電源をオンにする方法を教えて"
技術的なアプローチ	埋め込みを使用して連続ベクトル空間内のテキストを表し、セマンティック検索を有効にします。	キーワードの照合は、bag-of-words、TF-IDF、BM25 などの個別のトークンベースのメソッドに依存します。	相互ランクの融合や再ランク付けモデルなどの再ランク付けアプローチを使用して結果を結合します。
長所	正確な単語が使用されていない場合でも、コンテキスト的にクエリに似た情報を検索します。	キーワードの正確な一致を必要とするシナリオ。製品名などの特定の用語に焦点を当てたクエリに最適です。	両方のアプローチの長所を兼ね備えています。

検索プロセスを強化する方法

これらのコア検索戦略に加えて、検索プロセスをさらに強化するために適用できるいくつかの手法があります。

• クエリの拡張: クエリの拡張は、検索クエリの複数のバリエーションを使用して、より広範な関連ドキュメントをキャプチャするのに役立ちます。 これは、展開された各クエリに対して個別の検索を実行するか、単一の検索クエリですべての展開された検索クエリを連結すると実現できます。

Note

クエリの展開は、クエリ理解コンポーネント (RAG チェーン) の変更と組み合わせて行う必要があります。 通常、この手順では、検索クエリの複数のバリエーションが生成されます。

• 再ランク付け: チャンクの初期セットを検索した後、追加のランク付け基準 (たとえば、時間で並べ替え) またはリランカー モデルを適用して結果を並べ替えます。 再ランク付けは、特定の検索クエリを使用して、最も関連性の高いチャンクの優先順位を付けるのに役立ちます。 mxbai-rerank や ColBERTv2 などのクロスエンコーダー モデルを使用して再ランク付けすると、検索パフォーマンスが向上する可能性があります。
• メタデータ フィルタリング: クエリ理解ステップから抽出されたメタデータ フィルターを使用して、特定の条件に基づいて検索領域を絞り込みます。 メタデータ フィルターには、ドキュメントの種類、作成日、作成者、ドメイン固有のタグなどの属性を含めることができます。 メタデータ フィルターとセマンティックまたはキーワードベースの検索を組み合わせることで、より対象を絞った効率的な検索を作成できます。

Note

メタデータ フィルター処理は、クエリ理解 (RAG チェーン) コンポーネントとメタデータ抽出 (データ パイプライン) コンポーネントの変更と組み合わせて行う必要があります。

プロンプト拡張

プロンプト拡張は、ユーザー クエリをプロンプト テンプレートで検索した情報と指示と組み合わせて、高品質の応答の生成に向けて言語モデルをガイドする手順です。 このテンプレートを反復的に最適化して LLM (別名 "プロンプト エンジニアリング") が正確で根拠のある一貫した応答を生成するように誘導する必要があります。

完全なプロンプト エンジニアリングのガイドがありますが、ここではプロンプト テンプレートを反復するときに留意すべき考慮事項を次に示します。

1. 例を提供する
   • 適切な形式のクエリの例とそれに対応する理想的な応答をプロンプト テンプレート自体に含めます (フューショット学習)。 これは、モデルが応答の望ましい形式、スタイル、コンテンツを理解するのに役立ちます。
   • 良い例を考え出す便利な方法の 1 つは、チェーンが苦労するクエリの種類を特定することです。 これらのクエリに対してゴールド スタンダードの応答を作成し、プロンプトに例として含めます。
   • 提供する例が、推論時に予測されるユーザー クエリを代表するものであることを確認します。 モデルの一般化を改善するために、さまざまな範囲の予想されるクエリをカバーすることを目的とします。
2. プロンプト テンプレートをパラメーター化する
   • 検索したデータやユーザー クエリ以外の追加情報を組み込むようにパラメーター化して、プロンプト テンプレートが柔軟性を持つように設計します。 これは、現在の日付、ユーザーのコンテキスト、または他の関連するメタデータなどの変数である可能性があります。
   • 推論時にこれらの変数をプロンプトに挿入すると、よりパーソナライズされた応答やコンテキストに対応した応答が可能になります。
3. Chain-of-Thought プロンプトを検討する
   • 直接の回答がすぐに見つからない複雑なクエリの場合は、Chain-of-Thought (CoT) プロンプトを検討してください。 このプロンプト エンジニアリング戦略では、複雑な質問をより単純で連続した手順に分解し、論理的な推論プロセスを通じて LLM を誘導します。
   • モデルに "問題を段階的に考える" ように導くことで、より詳細で適切な理由を持つ応答を提供するように促すことができます。これは、マルチステップまたはオープンエンドのクエリの処理に特に効果的です。
4. プロンプトがモデル間で転送されない場合がある
   • プロンプトは、多くの場合、異なる言語モデル間ではシームレスに転送されないことを認識します。 各モデルには独自の特性があり、あるモデルに対して適切に動作するプロンプトが別のモデルに対しては、それほど効果的ではない場合があります。
   • さまざまなプロンプトの形式と長さを試して、オンライン ガイド ( OpenAI Cookbook、Anthropic cookbook など) を参照し、モデルを切り替えるときにプロンプトを適用および調整する準備をします。

LLM

RAG チェーンの生成コンポーネントは、前の手順から拡張プロンプト テンプレートを受け取り、LLM に渡します。 RAG チェーンの生成コンポーネントに対して LLM を選択して最適化する場合は、LLM 呼び出しを含む他の手順にも同様に適用できる次の要因を考慮してください。

1. さまざまな既製モデルを試す。
   • 各モデルには、独自のプロパティ、長所、弱点があります。 一部のモデルでは、特定のドメインの理解が深まったり、特定のタスクに対する高いパフォーマンスが発揮されたりする場合があります。
   • 前述したように、同じプロンプトでもモデルによって応答が異なるため、モデルの選択もプロンプト エンジニアリング プロセスに影響を与える可能性があることを覚えておいてください。
   • クエリ理解の呼び出しなど、生成手順の他にも LLM を必要とする複数のステップがチェーン内にある場合は、異なる手順に異なるモデルを使用することを検討してください。 コストの高い汎用モデルは、ユーザー クエリの意図の特定などのタスクには過剰な場合があります。
2. 小規模から始めて、必要に応じてスケールアップします。
   • 最も強力で能力の高い使用可能なモデル (GPT-4、Claude など) にすぐに手を伸ばしたくなるかもしれませんが、より小さな軽量モデルから始める方が効率的なことがよくあります。
   • 多くの場合、Llama 3 や DBRX などの小規模なオープンソースの代替手段を使用すると、より低コストで推論時間を短縮した満足のいく結果を得ることができます。 これらのモデルは、非常に複雑な推論や広範な世界の知識を必要としないタスクに特に効果的です。
   • RAG チェーンを開発および調整するときは、選択したモデルのパフォーマンスと制限を継続的に評価します。 モデルが特定の種類のクエリで苦戦している場合や、十分に詳細または正確な応答を提供できない場合は、より能力の高いモデルにスケールアップすることを検討してください。
   • モデルの変更が応答品質、待機時間、コストなどの主要なメトリックに与える影響を監視して、特定のユース ケースの要件に対して適切なバランスを取っていることを確認します。
3. モデル パラメーターを最適化する
   • さまざまなパラメーター設定を試して、応答の品質、多様性、一貫性の最適なバランスを見つけます。 たとえば、温度を調整すると、生成されるテキストのランダム性を制御できますが、max_tokens は応答の長さを制限できます。
   • 最適なパラメーター設定は、特定のタスク、プロンプト、望ましい出力スタイルによって異なる場合があることに注意してください。 生成された応答の評価に基づいて、これらの設定を繰り返しテストおよび調整します。
4. タスク固有の微調整
   • パフォーマンスを調整するときは、クエリの理解など、RAG チェーン内の特定のサブタスクに対して小さなモデルを微調整することを検討してください。
   • RAG チェーンを使用して個々のタスクに特化したモデルをトレーニングすることで、すべてのタスクに対して 1 つの大規模なモデルを使用する場合と比べると、全体的なパフォーマンスを向上させ、待機時間を短縮し、推論コストを削減できる可能性があります。
5. 継続的な事前トレーニング
   • RAG アプリケーションが特殊なドメインを扱う場合、または事前トレーニング済みの LLM で十分に表現されていない知識が必要な場合は、ドメイン固有のデータに対して継続的な事前トレーニング (CPT) を実行することを検討します。
   • 継続的な事前トレーニングにより、ドメイン固有の特定の用語や概念に対するモデルの理解を向上させることができます。 これにより、広範なプロンプト エンジニアリングやフューショットの例の必要性を減らすことができます。

後処理とガードレール

LLM が応答を生成した後、多くの場合、出力が望ましい形式、スタイル、コンテンツの要件を満たしていることを確認するために、後処理手法またはガードレールを適用する必要があります。 チェーン内のこの最後の手順 (または複数のステップ) は、生成された応答全体の一貫性と品質を維持するのに役立ちます。 後処理とガードレールを実装する場合は、次の点を考慮してください。

1. 出力形式の強制
   • ユース ケースによっては、生成された応答が、構造化されたテンプレートや特定のファイルの種類 (JSON、HTML、Markdown など) などの特定の形式に準拠するように要求される場合があります。
   • 構造化された出力が必要な場合は、 Instructor や Outlines などのライブラリが、この種の検証手順を実装するために適した開始点になります。
   • 開発時には、必要な形式を維持しながら、生成された回答のバリエーションに対応できるように、後処理手順の柔軟性を確保するのに十分な時間をかけましょう。
2. スタイルの一貫性の維持
   • RAG アプリケーションに特定のスタイル ガイドラインまたはトーン要件 (丁寧またはカジュアル、簡潔、詳細など) がある場合、後処理手順では、生成された応答全体でこれらのスタイル属性を確認して適用できます。
3. コンテンツ フィルターと安全ガードレール
   • RAG アプリケーションの性質と、生成されたコンテンツに関連する潜在的なリスクによっては、不適切、攻撃的、または有害な情報の出力を防ぐためにコンテンツ フィルターまたは安全ガードレールを実装することが重要な場合があります。
   • Llama Guard などのモデルや、コンテンツ モデレーションと安全性のために特別に設計された API (OpenAI のモデレーション APIなど) を使用して、安全ガードレールを実装することを検討してください。
4. ハルシネーションの処理
   • ハルシネーションに対する防御は、後処理手順として実装することもできます。 これには、検索したドキュメントで生成された出力を相互参照したり、追加の LLM を使用して応答の実際の正確性を検証したりする必要があります。
   • 生成された応答が事実の正確性要件を満たしていなかった場合に対応する、代替応答の生成やユーザーへの免責事項の提供などのフォールバック メカニズムを開発します。
5. エラー処理
   • すべての後処理手順では、その手順で問題が発生した場合、または満足のいく応答が生成されない場合に適切に対処するメカニズムを実装します。 これには、既定の応答を生成したり、手動レビューのために人間のオペレーターに問題をエスカレーションしたりすることが含まれます。