2.2. Retrieval, augmentation, and generation (aka RAG Chain) — Databricks Generative AI Cookbook [2024/6/21時点]の翻訳です。
本書は著者が手動で翻訳したものであり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
Databricks生成AIクックブックのコンテンツです。
2.2. 収集、拡張、生成(RAGチェーン)
データパイプラインによってデータが処理されたら、RAGアプリケーションで使用できるようになります。このセクションでは、オンライン環境のRAGアプリケーションにユーザーがリクエストを送信した際に生じるプロセスを説明します。推論時に起動されるこのステップのシリーズ、あるいはチェーンは通常RAGチェーンと呼ばれます。
- ユーザークエリーの前処理(オプション): あるケースでは、ベクターデータベースのクエリーにより適するようにユーザーのクエリーが前処理されます。これには、テンプレート内でのフォーマッティング、リクエストを書き換えるための他のモデルの利用、収集を支援するためのキーワードの抽出などが含まれます。このステップのアウトプットは、以降の収集ステップで使用される収集クエリーとなります。
- 収集: ベクターデータベースからサポート情報を収集するために、収集クエリーはデータ準備の過程でドキュメントのチャンクのエンべディングを作成する際に用いられたのと同じエンべディングモデルを用いてエンべディングに変換されます。これらのエンべディングによって、コサイン類似どのような手法を用いて収集クエリーと非構造化テキストのチャンクの間の意味論的な類似度を比較することができます。次に、ベクトルデータベースからチャンクが収集され、エンべディング化されたリクエストにどれだけ類似しているのかに基づきランキングされます。トップの結果(最も類似した結果)が返却されます。
- プロンプト拡張: LLMに送信されるプロンプトは、それぞれのコンポーネントをどのように活用するのかの指示、多くの場合、レスポンスのフォーマットを制御する追加の指示を含むテンプレートの中で、収集されたコンテキストを用いてユーザーのクエリーを拡張することで形成されます。適切なプロンプトテンプレートに対する試行錯誤のプロセスは、プロンプトエンジニアリングと呼ばれます。
- LLM生成: LLMは入力としてユーザーのクエリーと収集されたサポートデータを含む拡張されたプロンプトを受け取り、追加のコンテキストをベースとしたレスポンスを生成します。
- 後処理(オプション): 追加のビジネスロジックの適用、引用の追加、あるいは事前定義のルールや制約に基づいて生成テキストを洗練するために、LLMのレスポンスをさらに処理する場合があります。
RAGアプリケーションのデータパイプラインのように、RAGチェーンの品質に影響を与える数多くの重要なエンジニアリングの意思決定が存在します。例えば、ステップ(2)でどれだけのチャンクを収集するのかの決定、ステップ(3)でどのようにサポートデータとユーザーのクエリーを組み合わせるのかは、モデルが高品質なレスポンスを生成する能力に大きなインパクトを与えます。
チェーンを通じて、企業ポリシーとコンプライアンスを確実にするために様々なガードレイルが適用されるかもしれません。これには、適切なリクエストのフィルタリング、データソースにアクセスする前のユーザー権限のチェック、生成されたレスポンスへのコンテンツモデレーションテクニックの適用などが含まれます。
- 目次
- 前のセクション: 2.1. データパイプライン
- 次のセクション: 2.3. 評価とモニタリング