大型模型シリーズ - RAGの解釈

RAG は、2023 年に最も人気のある LLM ベースのアプリケーションシステムアーキテクチャです。 Web 検索エンジンと LLM を組み合わせた質問応答サービスから、数千のデータチャットアプリケーションまで、ほぼ完全に RAG 上に構築された製品は数多くあります。多くの人は、RAG とエージェントを大規模モデルアプリケーションの 2 つの主流アーキテクチャと見なしていますが、RAG とは何でしょうか。 RAG には具体的にどのようなテクノロジーが含まれますか?

1. RAGとは何か

RAG (Retrieval Augmented Generation) は、特定のデータソースから取得した情報を LLM に提供し、これに基づいて生成された回答を変更します。 RAG は基本的に、大規模モデルを通じてクエリに回答し、検索アルゴリズムによって見つかった情報を大規模モデルのコンテキストとして使用できる検索 + LLM ヒントです。クエリと取得されたコンテキストの両方が、LLM に送信されるプロンプトに挿入されます。

組み込み検索エンジンは Faiss を通じて実装でき、ベクトル検索分野は RAG の推進力となっています。 pinecone のようなベクターデータベースを使用すると、オープンソースの検索インデックスの構築、入力テキスト用の追加ストレージの追加、その他のツールが可能になります。ベクターデータベースの詳細については、「ベクターデータベースの解釈」を参照してください。

RAG 指向の開発フレームワークには、LLM ベースのパイプラインとアプリケーション用の最も有名なオープンソースツールが 2 つあります。LangChain と LlamaIndex です。これらはそれぞれ 2022 年 10 月と 11 月に作成され、2023 年には ChatGPT の発生により広く採用されました。 LlamaIndex と LangChain はどちらも、非常に速いペースで開発されている素晴らしいオープンソースプロジェクトです。

写真

2. 基本的なRAG技術

RAG システムの出発点は、一般的にテキストドキュメントのコーパスです。簡単に言うと、テキストをチャンクに分割し、それらのチャンクをトランスフォーマーエンコーダーモデルを使用してベクトルに埋め込み、それらのベクトルすべてにインデックスを付け、最後に、検索ステップで見つかったコンテキストに基づいて、ユーザーのクエリに回答するようにモデルに指示する LLM プロンプトを作成します。実行時には、同じエンコーダーモデルを使用してユーザークエリをベクトル化し、このクエリベクトルに対してインデックス検索を実行して上位 k 件の結果を見つけ、データベースから対応するテキストブロックを取得して、それらをコンテキストとして LLM プロンプトに提供します。

写真

OpenAI プラットフォームでは、プロンプトワード Prompt は次のようになります。

 def question_answering(context, query): prompt = f""" my query text... """ response = get_completion(instruction, prompt, model="gpt-3.5-turbo") answer = response.choices[0].message["content"] return answer

プロンプトとプロンプトエンジニアリングの詳細については、OpenAI のプロンプトエンジニアリングマニュアルを参照してプロンプトエンジニアリングについて説明してください。

明らかに、OpenAI が LLM 市場でリードしているにもかかわらず、Anthroic の Claude や、最近人気の Mistral のような小型ながら強力なモデル、Microsoft の Phi-2、そして Llama2、OpenLLaMA、Falcon など、RAG 用の大規模モデル製品の開発に使用できる多くの代替手段があります。

3. RAGの先進技術

RAG システムのすべての高レベル技術を 1 つの図で簡単に視覚化できるわけではありませんが、コアとなる手順とアルゴリズムを説明するスキームを示すことは依然として意味があります。

写真

3.1. ブロッキングとベクトル化

まず、ドキュメントコンテンツを表すベクトルインデックスを作成し、実行時に、これらすべてのベクトルとクエリベクトル間の最小距離に対応する最も近いセマンティクスを検索します。

Transformer モデルの入力シーケンスの長さは固定されているため、入力コンテキストのウィンドウが大きい場合でも、1 つまたはいくつかの文のベクトルは、複数ページのテキストの平均化されたベクトルよりも意味をより適切に表すことができるため、データチャンク化は意味のある手法です。最初のドキュメントを、意味を失わずに一定のサイズのチャンクに分割します。つまり、文を 2 つの部分に分割するのではなく、テキストを文または段落に分割します。さらに、このタスクを実行できるさまざまなテキストセグメンテーション実装がすでに存在します。たとえば、LlamaIndex では、NodeParser は、独自のテキストスプリッター、メタデータ、ノード/ブロックの関係などを定義するなど、いくつかの高度なオプションを提供します。

チャンクのサイズは考慮する必要があるパラメータであり、使用される埋め込みモデルとそのトークン容量に依存します。BERT の Sentence Transformer などの標準的なトランスフォーマーエンコーディングモデルは最大 512 トークンまでしか処理できませんが、OpenAI ada-002 は 8191 トークンなどのより長いシーケンスを処理できます。ただし、ここでのトレードオフは、LLM が推論できる十分なコンテキストと、検索を効率的に実行するための十分に具体的なテキスト埋め込みです。

次のステップは、選択したブロックの埋め込みを生成するモデルを選択することです。最適化されたモデル (bge-large または E5 シリーズ) を検索するなど、これを行うにはさまざまな方法があります。MTEB リーダーボードでは、最新のメソッド情報の一部が提供されます。ドキュメントのセグメンテーションとベクトル化の手順のエンドツーエンドの実装については、https://docs.llamaindex.ai/en/latest/moduleguides/loading/ingestionpipeline/root.html# を参照してください。

3.2. 検索インデックス

RAG の大規模モデルアプリケーションの重要な部分は、以前に取得されたベクトル化されたコンテンツを格納する、検索に使用されるインデックスです。もちろん、クエリは常に最初にベクトル化され、これは上位 k 個のパーティションにも当てはまります。最も単純な実装では、タイル化されたインデックスを使用し、クエリベクトルとすべてのタイルベクトル間の距離計算を実行し、それらを反復処理します。

10,000 以上の要素の規模で効率的に検索できるように最適化された適切な検索インデックスには、クラスタリング、ツリー、HNSW アルゴリズムなどの近似最近傍アプローチを使用して faiss、nmslib、または annoy によって実装されるベクトルインデックスが必要です。データ取り込みパイプラインを処理する ElasticSearch やベクターデータベースなどのマネージドソリューションもあります。

インデックス、データ、検索要件の選択に応じて、ベクトルとともにメタデータを保存し、メタデータフィルターを使用して特定の日付またはデータソースに関する情報を検索することもできます。 LlamaIndex は、多くのベクターストレージインデックスに加えて、リストインデックス、ツリーインデックス、キーワードテーブルインデックスなどのより単純なインデックス実装もサポートしています。

多数の文書がある場合は、それらを効率的に検索し、関連情報を見つけ、ソースの引用とともに単一の回答に集約できる必要があります。大規模なデータベースの場合、効率的なアプローチは、要約で構成されるインデックスとドキュメントチャンクで構成されるインデックスの 2 つを作成し、最初に要約によって関連するドキュメントをフィルター処理し、次に関連するグループによって検索するという 2 つの手順で検索することです。

写真

別のアプローチとしては、LLM に各チャンクの質問を生成させ、これらの質問をベクトルに埋め込み、実行時にこの質問のベクトルインデックスに対してクエリ検索を実行し (チャンクベクトルをインデックス内の質問ベクトルに置き換えます)、元のテキストチャンクにルーティングして、LLM が回答を取得するためのコンテキストとして送信するというものがあります。このアプローチでは、クエリと仮想の質問の間の意味的類似性が実際のチャンクよりも高くなるため、検索品質が向上します。 HyDE と呼ばれる逆ロジックアプローチもあります。このアプローチでは、LLM が特定のクエリに対する仮想応答を生成し、そのベクトルとクエリベクトルを使用して検索品質を向上させる必要があります。

より優れた検索品質を得るために、より小さなチャンクを取得するには、LLM に周囲のコンテキストを追加する必要があります。オプションには、取得した小さなチャンクの周囲の文ごとにコンテキストを拡張する文ウィンドウ取得と、ドキュメントを小さな子チャンクを含むいくつかの大きな親チャンクに再帰的に分割する親ドキュメント取得の 2 つがあります。

文ウィンドウ検索方式では、文書内の各文が個別に埋め込まれているため、コンテキストコサイン距離検索の精度が高くなります。最も関連性の高い単一の文を取得した後、見つかったコンテキストをより適切に推論するために、コンテキストウィンドウは取得された文の前後の k 個の文に拡張され、この拡張されたコンテキストが LLM に送信されます。

親ドキュメント検索は、より細かい情報を検索し、コンテキストウィンドウを拡張してから LLM に送って推論するという点で、文ウィンドウ検索と非常によく似ています。ドキュメントは、より大きな親チャンクを参照する小さなサブチャンクに分割されます。具体的には、ドキュメントはブロックの階層に分割され、最小のリーフブロックがインデックスに送信されます。検索中に、より小さなブロックがフェッチされ、検索された上位 k 個のブロックのうち n 個を超えるブロックが同じ親ノード (より大きなブロック) にリンクされている場合、LLM に提供されたコンテキストはこの親ノードに置き換えられます。検索は子ノードのインデックスでのみ実行されることに注意してください。

tf-idf や BM25 などのスパース検索アルゴリズムのような最新のセマンティック検索やベクトル検索から最良の結果を取得し、それらを 1 つの検索結果に結合するという比較的古いアイデアもあります。ここでの唯一のコツは、取得した結果を異なる類似度スコアで適切に組み合わせることです。この問題は通常、取得した結果を再ランク付けして最終出力を得る Reciprocal Rank Fusion (RRF) アルゴリズムを使用して解決されます。

写真

LangChain では、これは統合されたリトリーバークラス (Faiss ベクトルインデックスや、RRF を使用した再ランキングを備えた BM25 ベースのリトリーバーなど) で実装されています。 LlamaIndex では、これは非常によく似た方法で実行されます。

ハイブリッド検索または融合検索では通常、2 つの補完的な検索アルゴリズムを組み合わせて、クエリと保存されたドキュメント間の意味的類似性とキーワードの一致を考慮して、より優れた検索結果を提供します。

3.3. 再ランク付けとフィルタリング

検索結果を取得した後、フィルタリングによって再度並べ替える必要があります。 LlamaIndex は、類似度スコア、キーワード、メタデータに基づいて結果をフィルター処理したり、センテンストランスフォーマーに基づくクロスエンコーダー、メタデータ (日付の最新性など) に基づく凝集再ランク付けなどの他のモデルを使用して結果を再ランク付けしたりするための、さまざまな後処理手順を提供します。これは、取得したコンテキストを LLM に渡して結果の回答を得る前の最後のステップです。

クエリ変換

クエリ変換は、LLM を推論エンジンとして使用し、ユーザー入力を変更して検索品質を向上させる一連の手法です。選択できるさまざまな手法があります。

クエリが複雑な場合、LLM はそれを複数のサブクエリに分割できます。たとえば、「Github で Langchain と LlamaIndex のどちらに星が多いですか?」と質問する場合、コーパス内で直接比較が見つかる可能性は低く、より単純でより具体的な情報が取得されるのであれば、この質問を 2 つのサブクエリに分解するのが合理的です。たとえば、「Github で Langchain は星いくつですか?」「Github で Llamaindex は星いくつですか?」これらは並列に実行され、取得されたコンテキストがプロンプトに結合され、LLM が最初のクエリに対する最終的な回答を合成します。これは、Langchain ではマルチクエリリトリーバーとして、Llamaindex ではサブ質問クエリエンジンとして機能します。

写真

ステップバックプロンプトは、LLM を使用してより一般的なクエリを生成し、検索のより一般的な、またはより高レベルのコンテキストを取得するため、元のクエリに対する回答はこのコンテキストに基づくことができます。さらに、元のクエリの取得が実行され、最終的な回答生成ステップで両方のコンテキストが LLM に提供されます。 LangChain にはリファレンス実装 https://github.com/langchain-ai/langchain/blob/master/cookbook/stepback-qa.ipynb があります。クエリ書き換えでは、LLM を使用して初期クエリを再定式化し、検索効率を向上させます。 LangChain と LlamaIndex の両方に実装がありますが、LlamaIndex リファレンス実装の方が強力です (https://llamahub.ai/l/llamapacks-fusionretriever-query_rewrite)。

複数のソースを使用して 1 つの回答を生成する場合は、最初のクエリが複雑なため、複数のサブクエリを実行してから取得したコンテキストを 1 つの回答にマージする必要があるか、または 1 つのクエリに関連するコンテキストが、正確にバック参照できる複数のドキュメントで見つかったためです。この引用タスクをプロンプトに挿入し、LLM に使用されたソースの ID を提供するように要求し、生成された応答部分をインデックス内の元のテキストブロックと一致させることができます。Llamaindex は、この状況に対して効率的なファジーマッチングベースのソリューションを提供します。

3.5. チャットエンジン

単一のクエリで複数回実行できる RAG システムを構築するための重要な機能は、LLM 時代以前の従来のチャットボットと同様に、会話のコンテキストを考慮したチャットロジックです。これは、フォローアップの質問、繰り返しの参照、またはユーザーコマンドに関連する以前の会話コンテキストをサポートするために必要です。クエリ圧縮技術では、チャットのコンテキストとユーザークエリの両方を考慮できます。コンテキスト圧縮を実装する方法はいくつかあります。一般的で比較的シンプルな方法は ContextChatEngine です。これは、まずユーザークエリに関連するコンテキストを取得し、次にそれをキャッシュのチャット履歴とともに LLM に送信します。これにより、LLM は次の回答を生成するときに前のコンテキストを認識できるようになります。

写真

より複雑な実装は CondensePlusContextMode です。このモードでは、各インタラクションでチャット履歴と最後のメッセージが新しいクエリに凝縮され、その後インデックスが作成され、取得されたコンテキストが元のユーザーメッセージとともに LLM に渡されて回答が生成されます。

3.6. クエリルーティング

クエリルーティングは、ユーザークエリに基づいて次に何を実行するかを決定する、LLM によって実行される決定ステップです。これらのオプションは通常、要約、何らかのデータインデックスに対する検索の実行、またはさまざまなルートを試してからその出力を 1 つの回答に統合することです。

クエリルーティングは、インデックス、またはより広義には、従来のベクターストアやグラフデータベース、リレーショナルデータベースなど、ユーザークエリを送信するデータストアを選択するためにも使用できます。マルチドキュメントストレージの非常に典型的な例は、サマリーインデックスとドキュメントチャンクベクトルの別のインデックスです。

クエリルートを定義するには、実行できる選択肢を設定する必要があります。ルーティングは LLM 呼び出しを通じて実行され、クエリを特定のインデックスにルーティングするための結果が定義済みの形式で返されます。プロキシアプローチが採用されている場合、クエリは、以下のマルチドキュメントプロキシスキームに示すように、サブチェーンまたは他のプロキシにルーティングされます。 LlamaIndex と LangChain はどちらもクエリルーティングをサポートしています。

3.7. RAG のエージェント

エージェントは、最初の LLM API がリリースされて以来、ほぼ存在しており、その目的は、推論が可能で、達成する必要のあるタスクを実行できる LLM 用のツールセットを提供することです。これらのツールには、任意のコード関数や外部 API、さらには他のエージェントなどの決定論的な関数が含まれる場合があります。この LLM リンクのアイデアが LangChain の源です。

エージェントはそれ自体が大きなトピックであり、OpenAI Assistant は基本的に LLM に必要な多くのツールを実装しており、おそらく最も重要なのは関数呼び出し API です。後者は、自然言語を外部ツールまたはデータベースクエリへの API 呼び出しに変換する機能を提供します。 LlamaIndex には、この高レベルロジックを ChatEngine および QueryEngine と組み合わせて、知識ベースおよびコンテキスト認識のチャット機能を提供する OpenAIAgent クラスがあり、複数の OpenAI 関数を一度に呼び出す機能も提供しているため、インテリジェントエージェントの使用が最前線にまで達します。

写真

マルチドキュメントエージェントを例にとると、エージェント (OpenAIAgent) は各ドキュメントで初期化され、ドキュメントの要約と従来の QA メカニズムを実行できるほか、クエリをドキュメントエージェントにルーティングして最終的な回答を合成するトップレベルの汎用エージェントも実行されます。各ドキュメントプロキシには、ベクターストレージインデックスとサマリーインデックスという 2 つのツールがあり、ルーティングクエリに基づいて使用するツールを決定します。このアーキテクチャでは、関係する各エージェントによって多数のルーティング決定が行われます。このアプローチの利点は、異なるドキュメントとその要約に記載されているさまざまなソリューションやエンティティを比較できることと、従来の単一ドキュメントの要約と QA メカニズムを比較できることです。これは基本的に、ドキュメントセットとのチャットの最も一般的なユースケースをカバーします。

このソリューションは、LLM を内部的に使用して複数の反復を前後に実行するため、少し遅くなります。念のため、LLM 呼び出しは、RAG パイプラインの最長検索操作によって速度が最適化されます。したがって、大規模なマルチドキュメントストアの場合、スケーラブルにするためにスキームをある程度簡素化できます。

3.8. レスポンスの統合

応答合成は、RAG パイプラインの最終ステップであり、取得されたすべてのコンテキストと最初のユーザークエリに基づいて回答を生成します。最も単純なアプローチは、取得したすべてのコンテキスト（何らかの関連性しきい値を超えるもの）をクエリとともに連結し、それを LLM に渡すことです。ただし、取得したコンテキストを絞り込み、より適切な回答を生成するために、複数の LLM 呼び出しを伴う、より複雑なオプションも存在します。応答合成の主な方法は次のとおりです。

取得したコンテキストをブロックごとに LLM に送信することで、回答を反復的に改良します。
取得したコンテキストをプロンプトに合わせて要約します。
さまざまなコンテキストのチャンクに基づいて複数の回答を生成し、それらを接続または要約します。

レスポンス合成の詳細については、ドキュメント https://docs.llamaindex.ai/en/stable/moduleguides/querying/responsesynthesizers/root.html の例を参照してください。

4. RAGのエンコーダと大規模モデルの微調整

RAG パイプラインに含まれるディープラーニングモデルに対して微調整が行われます。1 つは、埋め込み品質を担い、コンテキスト検索の品質を向上させる Transformer Encoder であり、もう 1 つは、提供されたコンテキストを活用してユーザークエリに回答する LLM です。 GPT-4 などのハイエンド LLM を使用して、高品質の合成データセットを生成できます。ただし、大規模なデータセットでトレーニングされたオープンソースモデルを取得し、小さな合成データセットを使用してすばやく微調整すると、モデルの全体的な機能が低下する可能性があることに常に注意する必要があります。

トランスフォーマーエンコーダーの最適化された検索の新しいバージョンは非常に効果的であり、bge-large-en-v1.5 はラップトップ環境でも大幅な検索品質の向上を実現できます。

4.1. エンコーダの微調整

古くからある良い選択肢は、クロスエンコーダを使用することです。ベースエンコーダーが完全に信頼されていない場合、クロスエンコーダーは取得した結果を再ランク付けできます。これは、クエリと、トークンで区切られた上位 k 個の取得されたテキストチャンクをクロスエンコーダーに渡し、関連するチャンクには 1 を、無関係なチャンクには 0 を出力するように微調整することで機能します。この調整プロセスについては、https://docs.llamaindex.ai/en/latest/examples/finetuning/crossencoderfinetuning/crossencoderfinetuning.html# を参照してください。

4.2. 大規模モデルの微調整

最近、OpenAI は LLM 微調整 API の提供を開始し、LlamaIndex には RAG 設定で GPT-3.5-turbo を微調整して GPT-4 の知識の一部を「抽出」するチュートリアルがあります。基本的な考え方は、ドキュメントを取得し、GPT-3.5-turbo を使用して一連の質問を生成し、次に GPT-4 を使用してドキュメントの内容に基づいてこれらの質問に対する回答を生成することです。つまり、GPT4 に基づいて RAG パイプラインを構築し、質問と回答のペアのデータセットで GPT-3.5-turbo を微調整します。 RAG パイプラインの評価を通じて、微調整された GPT 3.5 ターボモデルは、元のモデルよりも提供されたコンテキストをより有効に活用して回答を生成できることが予備的に判断できます。

より洗練されたアプローチは、Meta AI Research の論文「RA-DIT: Retrieval-Enhanced Dual Instruction Optimization」で紹介されており、クエリ、コンテキスト、回答の 3 つに対して LLM とリトリーバー (元の論文ではデュアルエンコーダー) を同時に最適化する手法を提案しています。この手法は、微調整 API と Llama2 オープンソースモデルを介して OpenAI LLM (元の論文) を微調整するために使用され、知識集約型タスクでは約 5% の向上 (RAG を使用した Llama265B と比較して)、常識的推論タスクでは数パーセントの向上が実現しました。実装の詳細については、https://docs.llamaindex.ai/en/stable/examples/finetuning/knowledge/finetuneretrievalaug.html#fine-tuning-with-retrieval-augmentation を参照してください。

5. RAG指向のパフォーマンス評価

RAG システムのパフォーマンスを評価するために、全体的な回答の関連性、回答の追跡可能性、信頼性、取得されたコンテキストの関連性などの指標を使用して、いくつかのフレームワークを適用できます。

Ragas フレームワークは、RAG 検索部分と従来のコンテキスト精度リコールで生成された回答の品質指標として、信頼性と回答の関連性を使用します。評価フレームワーク Truelens では、RAG システムのパフォーマンス評価の 3 つとして、検索とクエリのコンテキスト関連性、回答の追跡可能性、および回答とクエリの関連性を使用することを推奨しています。その中で、最も重要かつ制御可能な指標は、取得されたコンテキストの関連性であり、次に回答の関連性と追跡可能性が続きます。

LangChain には非常に高度な評価フレームワークである LangSmith があり、カスタム評価を実装し、RAG パイプラインの実行ステータスを追跡して、システムの透明性を高めることができます。 LlamaIndex には、公開データセットを使用して RAG システムを評価するための簡単なツールを提供する rag_evaluator パッケージがあります。

6. まとめ

RAG システムの主な課題は、回答の関連性と信頼性に加えて、速度です。ただし、ネットワーク検索に基づく RAG、エージェントアーキテクチャとの緊密な統合、LLM 長期記憶に関するいくつかの方法とアプローチなど、考慮すべきことは他にも多数あります。それでも、RAG の応用範囲はまだまだ広いです。RAG を実際の用途に使う際には、この記事で紹介した技術が皆様のお役に立てれば幸いです。

写真

【参考文献】

https://docs.llamaindex.ai/en/stable/apireference/servicecontext/nodeparser.html
https://huggingface.co/spaces/mteb/leaderboard
https://huggingface.co/BAAI/bge-large-en-v1.5
https://huggingface.co/intfloat/multilingual-e5-large
翻訳: 原文
https://plg.uwaterloo.ca/~gvcormac/cormacksigir09-rrf.pdf
https://python.langchain.com/docs/modules/dataconnection/retrievers/MultiQueryRetriever
https://docs.llamaindex.ai/en/stable/examples/queryengine/subquestionqueryengine.html
https://github.com/langchain-ai/langchain/blob/master/cookbook/stepback-qa.ipynb
https://docs.ragas.io/en/latest/index.html
出典：http://arxiv.org/pdf/2310.01352.pdf
https://github.com/truera/trulens/tree/main
参考文献
https://github.com/run-llama/llama-
ハブ/ツリー/dac193254456df699b4c73dd98cdbab3d1dc89b0/ラマハブ/ラマパック/rag_evaluator