RAGチェーンの品質向上

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

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

1. クエリ理解:ユーザークエリを分析および変換して、意図をより適切に表現し、フィルターやキーワードなどの関連情報を抽出して、検索プロセスを改善します。

2. 検索:検索クエリに基づいて、最も関連性の高い情報チャンクを検索します。 非構造化データの場合、これには通常、セマンティック検索またはキーワードベースの検索の 1 つまたは組み合わせが含まれます。

3. プロンプトの拡張:ユーザークエリと取得した情報および指示を組み合わせて、LLM が高品質の応答を生成できるようにガイドします。

4. LLM:アプリケーションに最も適したモデル (およびモデル パラメーター) を選択して、パフォーマンス、レイテンシ、コストを最適化/バランスします。

5. 後処理とガードレール: LLMによって生成された応答がトピックに沿っており、事実に一貫性があり、特定のガイドラインや制約に準拠していることを確認するために、追加の処理と安全対策を適用します。

「Iteratively implement & evaluate quality fixes 」では、チェーンのコンポーネントを反復処理する方法を説明しています。

クエリの理解

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

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

   例：

   • 複数ターンのチャットでの会話履歴の言い換え

   • ユーザーのクエリのスペルミスを修正する

   • ユーザー クエリ内の単語や語句を同義語に置き換えて、より広範な関連ドキュメントをキャプチャする

   重要

   照会の再書き込みは、検索コンポーネントへの変更と併せて行う必要があります

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

   例：

   • 「過去 6 か月間の記事」や「2023 年のレポート」など、クエリで言及されている特定の期間を抽出します。

   • 「 Databricks Professional サービス」や「ラップトップ」など、クエリ内の特定の製品、サービス、またはカテゴリの言及を識別します。

   • クエリから地理的エンティティ (都市名や国コードなど) を抽出する。

   注：

   フィルター抽出は、メタデータ抽出データ パイプラインとリトリーバー チェーンコンポーネントの両方の変更と組み合わせて実行する必要があります。 メタデータ抽出ステップでは、各ドキュメント/チャンクに対して関連するメタデータ フィールドが使用可能であることを確認する必要があり、抽出されたフィルターを受け入れて適用するように取得ステップを実装する必要があります。

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

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

サポートボットの複数ステップのクエリの理解

顧客サポート ボットのマルチステップ クエリ理解コンポーネントは次のようになります。

1. 意図の分類: LLM を使用して、ユーザーのクエリを「製品情報」、「トラブルシューティング」、「アカウント管理」などの定義済みカテゴリに分類します。

2. エンティティ抽出:識別された意図に基づいて、別の LLM 呼び出しを使用して、製品名、報告されたエラー、アカウント番号などの関連するエンティティをクエリから抽出します。

3. クエリの書き換え:抽出されたインテントとエンティティを使用して、元のクエリをより具体的でターゲットを絞った形式に書き換えます。たとえば、「RAG チェーンがモデルサービングにデプロイできません。次のエラーが表示されます...」などです。

検索

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

1. セマンティック検索: セマンティック検索では、埋め込みモデルを使用して、テキストの各チャンクを、そのセマンティックな意味をキャプチャするベクター表現に変換します。 セマンティック検索では、取得クエリのベクトル表現とチャンクのベクトル表現を比較することで、クエリの正確なキーワードがなくても、概念的に類似したドキュメントを取得できます。

2. キーワード検索: キーワードベースの検索では、検索クエリとインデックス付きドキュメント間で共有される単語の頻度と分布を分析することで、ドキュメントの関連性を判断します。 クエリとドキュメントの両方に同じ単語が出現する頻度が高いほど、そのドキュメントに割り当てられる関連性スコアが高くなります。

3. ハイブリッド検索: ハイブリッド検索は、2 段階の検索プロセスを採用することで、セマンティック検索とキーワードベースの検索の両方の長所を兼ね備えています。 まず、セマンティック検索を実行して、概念的に関連する一連のドキュメントを取得します。 次に、この削減セットにキーワードベースの検索を適用し、キーワードの完全一致に基づいて結果をさらに絞り込みます。 最後に、両方のステップのスコアを組み合わせてドキュメントをランク付けします。

検索方法の比較

次の表は、これらの各取得戦略を互いに比較したものです。

	セマンティック検索	キーワード検索	ハイブリッド検索
簡単な説明	同じ 概念 がクエリと潜在的なドキュメントに表示される場合は、関連性があります。	クエリと潜在的なドキュメントに同じ 単語 が出現する場合、それらは関連しています。 ドキュメント内のクエリの 単語数が多い ほど、そのドキュメントの関連性が高くなります。	セマンティック検索とキーワード検索の両方を実行し、結果を結合します。
使用例	ユーザーの問い合わせが製品マニュアルの文言と異なる場合の顧客サポート。 例:「電話の電源を入れるにはどうすればいいですか?」、手動セクションは「電源の切り替え」と呼ばれます。	クエリに特定の非説明的な技術用語が含まれている顧客サポート。 例:「モデルHD7-8Dは何をしますか?」	顧客は、意味用語と技術用語を組み合わせたクエリをサポートします。 例: 「HD7-8D の電源を入れるにはどうすればいいですか?」
技術的なアプローチ	埋め込みを使用して連続ベクトル空間でテキストを表現し、セマンティック検索を可能にします。	キーワードのマッチングには、bag-of-words 、 TF-IDF 、 BM25などの個別のトークンベースの方法に依存します。	相互順位の融合や再ランク付けモデルなど、結果を結合するには、再ランク付けアプローチを使用します。
強み	正確な単語が使用されていない場合でも、クエリと文脈的に類似した情報を取得します。	正確なキーワード一致を必要とするシナリオ。製品名などの特定の用語に重点を置いたクエリに最適です。	両方のアプローチの長所を組み合わせます。

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

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

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

注：

クエリの拡張は、クエリ理解コンポーネント(RAGチェーン)への変更と併せて行う必要があります。 通常、このステップでは、検索クエリの複数のバリエーションが生成されます。

• 再ランク付け: チャンクの初期セットを取得した後、追加のランキング基準 (時間で並べ替えるなど) またはリランカー モデルを適用して、結果を並べ替えます。 再ランク付けは、特定の取得クエリに対して最も関連性の高いチャンクに優先順位を付けるのに役立ちます。 mxbai-rerank や ColBERTv2 などのクロスエンコーダーモデルで再ランク付けすると、検索パフォーマンスが向上する可能性があります。

• メタデータ フィルタリング:クエリ理解ステップから抽出されたメタデータ フィルターを使用して、特定の基準に基づいて検索スペースを絞り込みます。 メタデータ フィルターには、ドキュメントの種類、作成日、作成者、ドメイン固有のタグなどの属性を含めることができます。 メタデータフィルターをセマンティック検索またはキーワードベースの検索と組み合わせることで、よりターゲットを絞った効率的な検索を作成できます。

注：

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

迅速なオーグメンテーション

プロンプト拡張は、ユーザークエリをプロンプトテンプレートで取得した情報および指示と組み合わせて、言語モデルが高品質の応答を生成するように導くステップです。 このテンプレートを反復して、LLM に提供されるプロンプトを最適化すること (プロンプト エンジニアリングとも呼ばれます) は、モデルが正確で根拠のある一貫した応答を生成するようにガイドされることを保証するために必要です。

プロンプト エンジニアリングに関する完全なガイドは存在しますが、プロンプト テンプレートを反復処理するときに留意すべき点がいくつかあります。

1. 例を挙げる

   • 適切な形式のクエリの例とそれに対応する理想的な応答をプロンプト テンプレート自体に含めます (few-shot learning)。これは、モデルが応答の目的の形式、スタイル、および内容を理解するのに役立ちます。

   • 良い例を思いつくための有用な方法の1つは、チェーンが苦労しているクエリの種類を特定することです。 これらのクエリに対するゴールドスタンダードの応答を作成し、プロンプトに例として含めます。

   • 提供する例は、推論時に予想されるユーザークエリを代表するものであることを確認してください。 モデルをより適切に一般化するために、予想されるさまざまなクエリをカバーすることを目指します。

2. プロンプトテンプレートのパラメータ化

   • 取得したデータやユーザー クエリ以外の追加情報を組み込むようにパラメーター化することで、プロンプト テンプレートを柔軟に設計します。 これは、現在の日付、ユーザー コンテキスト、その他の関連するメタデータなどの変数である可能性があります。

   • 推論時にこれらの変数をプロンプトに挿入すると、よりパーソナライズされた応答やコンテキスト認識応答が可能になります。

3. 思考の連鎖のプロンプトを検討する

   • 直接的な答えがすぐにはわからない複雑なクエリの場合は、 思考の連鎖 (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 チェーンを使用して個々のタスクに特化したモデルをトレーニングすることで、すべてのタスクに単一の大規模モデルを使用する場合と比較して、全体的なパフォーマンスの向上、レイテンシの削減、推論コストの削減が期待できます。

5. 継続的な事前学習

   • RAG アプリケーションが特殊なドメインを扱う場合、または事前トレーニング済みの LLM で十分に表現されていない知識を必要とする場合は、ドメイン固有のデータに対して継続的な事前トレーニング (CPT) を実行することを検討してください。

   • 事前トレーニングを継続することで、ドメイン固有の特定の用語や概念に対するモデルの理解が向上します。 その結果、大規模なプロンプトエンジニアリングや少数のショットの例の必要性が軽減されます。

後処理とガードレール

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

1. 出力形式の強制

   • ユースケースによっては、生成された応答が構造化テンプレートや特定のファイルタイプ (JSON、HTML、Markdown など) などの特定の形式に準拠することが必要になる場合があります。

   • 構造化された出力が必要な場合は、 InstructorやOutlinesなどのライブラリが、この種の検証ステップを実装するための良い出発点となります。

   • 開発時には、必要な形式を維持しながら、生成された応答のバリエーションを処理できるほど後処理ステップが柔軟であることを確認してください。

2. スタイルの一貫性の維持

   • RAG アプリケーションに特定のスタイル ガイドラインまたはトーン要件 (フォーマル vs. カジュアル、簡潔 vs. 詳細など) がある場合、後処理ステップでは、生成された応答全体でこれらのスタイル属性をチェックして適用できます。

3. コンテンツフィルタと安全ガードレール

   • RAG アプリケーションの性質と、生成されたコンテンツに関連する潜在的なリスクに応じて、不適切、不快、または有害な情報の出力を防ぐために、 コンテンツ フィルターまたは安全ガードレールを実装することが重要になる場合があります。

   • 安全ガードレールを実装するには、 LlamaGuard APIsなどのモデルや、 OpenAI のモデレーション など、コンテンツのモデレーションと安全性のために特別に設計された の使用を検討してください。API

4. 幻覚への対処

   • 幻覚に対する防御も後処理ステップとして実装できます。 これには、生成された出力と取得されたドキュメントを相互参照したり、追加のLLMを使用して応答の事実の正確性を検証したりすることが含まれる場合があります。

   • 生成された応答が事実の正確性の要件を満たさない場合 (代替応答の生成やユーザーへの免責事項の提供など) を処理するためのフォールバック メカニズムを開発します。

5. エラー処理

   • 後処理ステップでは、ステップで問題が発生した場合や満足のいく応答を生成できなかった場合に適切に対処するためのメカニズムを実装します。 これには、デフォルトの応答を生成したり、問題を人間のオペレーターにエスカレーションして手動で確認したりすることが含まれる場合があります。