高度なRAGテクニック：イラスト入り概要

OpenSearchやElasticSearchといった管理されたソリューションや、Pinecone、Weaviate、またはChromaのようなデータインジェスションパイプラインを裏で処理するベクトルデータベースなどもあります。

インデックスの選択、データ、および検索のニーズに応じて、ベクトルとともにメタデータを保存し、日付やソースなどの情報を検索するためにメタデータフィルタを使用することもできます。

LlamaIndexはベクトルストアインデックスをたくさんサポートしていますが、リストインデックス、ツリーインデックス、およびキーワードテーブルインデックスなど、他のより単純なインデックスの実装もサポートされています — 後述するフュージョン検索の部分でそれについて話します。

2. 2 階層インデックス

多くのドキュメントを取得する必要がある場合、それらの中から効率的に検索し、関連情報を見つけ、ソースへの参照を含んだ1つの回答にまとめる必要があります。大規模なデータベースの場合、これを行うための効率的な方法は、サマリで構成される1つのインデックスとドキュメントチャンクで構成されるもう1つのインデックスを作成し、まずサマリで関連ドキュメントをフィルタリングし、その関連グループ内で検索することです。

2.3 仮説的な質問とHyDE

別の方法は、LLMに各チャンクごとに質問を生成し、これらの質問をベクトルに埋め込むように求めることです。ランタイムでは、この質問ベクトルのインデックスに対してクエリ検索を実行し（インデックス内のチャンクベクトルを質問ベクトルに置き換える）、回収後に元のテキストチャンクにルーティングしてLLMに回答の文脈として送信します。この方法は、実際のチャンクに比べてクエリと仮説的な質問の意味的な類似性が高いため、検索の品質が向上します。

また、逆転ロジックアプローチとしてHyDEと呼ばれるものもあります。この場合、LLMにクエリを与えて仮説的な応答を生成し、クエリベクトルとともにそのベクトルを使用して検索の品質を向上させます。

2.4 コンテキストの豊かさ

ここでのコンセプトは、より良い検索品質のためにより小さいチャンクを取得するが、LLMが推論するために周囲のコンテキストを追加するというものです。2つのオプションがあります。小さい取得チャンクの周囲の文をコンテキストに追加するか、ドキュメントを再帰的により大きな親チャンクを含むいくつかの大きな子チャンクに分割するかです。

2.4.1 文ウィンドウの取得このスキームでは、文書内の各文が個別に埋め込まれるため、クエリとコンテキストのコサイン距離検索の高い精度を提供します。最も関連性の高い単一の文が取得された後、取得した文の前後にk個の文を拡張してこの拡張されたコンテキストをLLMに送信します。

緑の部分がインデックスで検索中に見つかった文の埋め込みであり、黒色と緑色の全体の段落が提供されたクエリに関して推論を行うためにLLMに送られます。

2.4.2 オートマージングリトリーバー (または 親ドキュメントリトリーバー)

ここでのアイディアは、文ウィンドウリトリーバーと非常に似ています。より詳細な情報の一部を検索し、推論のためにその前にコンテキストウィンドウを拡張します。ドキュメントは、より大きな親チャンクを参照するより小さな子チャンクに分割されます。

検索最初により小さいチャンクを取得し、上位k個の取得チャンクの中でn個以上が同じ親ノード（より大きなチャンク）にリンクされている場合は、LLMに送信するコンテキストをこの親ノードで置き換えます。いくつかの取得チャンクをより大きな親チャンクに自動マージするような方法のため、メソッド名もそうなっています。ただし、検索は子ノードのインデックス内でのみ実行されます。詳細については、LlamaIndexチュートリアルのRecursive Retriever + Node Referencesをご確認ください。

2.5 融合リトリーバーまたはハイブリッド検索

比較的古いアイデアで、両方の世界のベストを取ることができるというものです。キーワードベースの古典的な検索（tf-idfなどの疎なリトリーバーアルゴリズムや検索業界の標準であるBM25など）と、現代の意味論的またはベクトル検索を組み合わせて1つの検索結果にすることです。唯一のトリックは、異なる類似性スコアで取得した結果を適切に組み合わせることです。この問題は通常、相互ランク融合アルゴリズムを使用して解決され、最終的な出力のために取得した結果を再順位付けします。

これはLangChainでアンサンブルリトリーバクラスで実装されています。クエリと格納されたドキュメントの間のセマンティック類似性とキーワードの一致を考慮した2つの補完的な検索アルゴリズムを組み合わせることで、再ランキングにはRRFを使用しています。

LlamaIndexでは、同様の方法で行われます。

ハイブリッドまたはフュージョン検索は、2つの補完的な検索アルゴリズムを組み合わせるため、セマンティック類似性とキーワードの一致を考慮した検索結果の質が向上します。

3. 再ランキングとフィルタリング

上記のアルゴリズムのいずれかで検索結果を取得しました。今は、フィルタリング、再ランキング、または何らかの変換を介してそれらを洗練させる時です。LlamaIndexでは、利用可能なポストプロセッサのバリエーションがあり、類似性スコア、キーワード、メタデータに基づいて結果をフィルタリングしたり、他のモデル（LLM、センテンストランスフォーマークロスエンコーダ、Cohereリランキングエンドポイントなど）によるリランキングしたり、日付の新しさなどのメタデータに基づいて処理することができます。

これは、取得したコンテキストをLLMに提供する前の最終ステップです。

今は、クエリ変換やルーティングなど、より高度なRAGテクニックに進む時です。これらは、LLMを含む複雑な論理を使用するため、媒介的な振る舞いを表現します。

4. クエリ変換

クエリ変換は、LLMを推論エンジンとして使用してユーザー入力を変更し、検索の品質を向上させるための技術の一群です。これを行うためのさまざまなオプションがあります。

クエリが複雑な場合、LLMは複数のサブクエリに分解することができます。例えば、「LangchainとLlamaIndexの中でGithubでのスターが多いフレームワークはどれですか？」と聞いた場合、コーパス内のテキストで直接的な比較を見つけることはないため、この質問をより単純で具体的な情報検索を前提とした2つのサブクエリに分解することは意味があります。「LangchainのGithubでのスターはいくつ？」と「LlamaindexのGithubでのスターはいくつ？」これらのサブクエリは並列で実行され、その後、取得されたコンテキストはLLMによって初期クエリへの最終回答を合成するために単一のプロンプトに結合されます。両方のライブラリにはこの機能が実装されています。LangchainではMulti Query Retriever、LlamaindexではSub Question Query Engineとして実装されています。

1. Step-back promptingは、LLMを使用してより一般的なクエリを生成し、取得するために使用されます。一般的なまたはハイレベルなコンテキストを取得し、元のクエリへの回答を基礎づけるために使用されます。元のクエリに対する検索も実行され、両方のコンテキストがLLMによって最終的な回答生成ステップで使用されます。ここにはLangChainの実装があります。
2. クエリの書き換えは、元のクエリを改変するためにLLMを使用します。クエリの改善のために、LangChainとLlamaIndexの両方に実装がありますが、やや異なり、LlamaIndexのソリューションの方がより強力であると考えます。

参考文献

これは検索の改善技術よりむしろ、インストゥルメントというよりも重要なものですが、番号は付けずに進めます。 回答を生成するために複数のソースを使用した場合、初期クエリの複雑さによるもの（複数のサブクエリを実行して、取得したコンテキストを1つの回答に組み合わせる必要があった）または単一のクエリに関連するコンテキストをさまざまなドキュメントで見つけた場合、ソースを正確に参照することができるかどうかが問題になります。

そのための方法はいくつかあります：

1. この引用タスクを促すためにプロンプトに挿入し、使用されたソースのIDをLLMにメンションしてもらいます。
2. 生成された応答の部分を元のテキストのチャンクと一致させる — llamaindexはこのケースに対するフジー一致に基づく効果的な解決策を提供しています。フジー一致について聞いたことがない場合、これは非常に強力な文字列一致技術です。

5. チャットエンジン

シングルクエリに対して一度以上動作できる素敵なRAGシステムを構築する際のチャットロジックで対話コンテキストを考慮することです。これはLLM以前のクラシックなチャットボットと同じく、フォローアップの質問、照応、または前の対話コンテキストに関連する任意のユーザーコマンドをサポートするために必要です。ユーザーのクエリとともにチャットコンテキストを考慮したクエリ圧縮技術で解決されます。

いつものように、複数のアプローチがあります — 一般的で比較的シンプルなContextChatEngine、まずユーザーのクエリに関連するコンテキストを取得し、次にそれをLLMに送信して、次の回答を生成する際にLLMが以前のコンテキストを認識するためのメモリバッファからのチャット履歴とともに行います。

もう少し洗練されたケースはCondensePlusContextModeです — ここでは各インタラクションでチャット履歴と前回のメッセージが新しいクエリに圧縮され、このクエリがインデックスに送られ、取得したコンテキストが元のユーザーメッセージとともにLLMに渡され、回答が生成されます。

重要なことは、LlamaIndexではOpenAIエージェントベースのチャットエンジンもサポートされており、より柔軟なチャットモードを提供します。また、LangchainはOpenAIの機能APIもサポートしています。

他にもReActエージェントなど、別のチャットエンジンのタイプがありますが、セクション7へ進んでエージェント自体に進みます。

6. クエリルーティング

クエリルーティングは、ユーザーのクエリに次に何を行うかを決定するLLMの動作ステップです — 通常のオプションは要約を行ったり、データインデックスに対して検索を行ったり、さまざまな経路を試してその出力を1つの回答に合成することです。

クエリルーターはインデックスを選択するためにも使用されます — データの複数のソースを持っている場合、例えば、クラシックなベクトルストアとグラフデータベースまたは関係性データベース、またはインデックスの階層構造を持っている場合 — 複数のドキュメントのストレージの場合、例えば、要約のインデックスとドキュメントのチャンクベクトルの別のインデックスなど。

クエリルーターの定義には、それが選択できる選択肢を設定することが含まれます。ルーティングオプションの選択はLLMの呼び出しによって行われ、その結果は事前定義された形式で返され、クエリを指定されたインデックスにルーティングするために使用されます。アグナスティックな振る舞いの場合は、サブチェーンや他のエージェントに示されるマルチドキュメントエージェントスキームのように。

両方のLlamaIndexとLangChainは、クエリルータのサポートを持っています。

7. RAG内のエージェント

エージェント（LangchainおよびLlamaIndexの両方でサポートされています）は、ほぼLLM APIが最初にリリースされて以来存在していました – 理論的な思考が可能なLLMに、ツールセットと完了するためのタスクを提供するというアイデアです。ツールセットには、コード関数や外部API、他のエージェントなどの確定論的な機能が含まれる可能性があります – このLLMの連鎖の考え方がLangChainの名前の由来です。

エージェント自体は非常に大きなものであり、RAGの概要の中で十分に深く掘り下げることは不可能です。そのため、エージェントベースのマルチドキュメントの取得ケースを続け、OpenAI Assistantsステーションで短時間停止します。それは比較的新しいものであり、最近のOpenAI開発者カンファレンスでGPTとして発表されたものであり、以下で説明するRAGシステムの裏側で動作しています。

OpenAI Assistantsは、以前にオープンソースで使用していたLLMに必要な多くのツールを実装しています – チャットの履歴、ナレッジストレージ、ドキュメントのアップロードインターフェース、そしておそらく最も重要なのは、関数呼び出しAPIです。これにより、自然言語を外部ツールまたはデータベースクエリへのAPI呼び出しに変換できます。

LlamaIndexには、OpenAIAgentクラスがあり、この高度なロジックをChatEngineとQueryEngineクラスと結び付け、1つの会話ターンでの複数のOpenAI関数の呼び出しが可能です。これにより、スマートな代理行動が実現されます。

マルチドキュメントエージェントのスキームを見てみましょう – かなり洗練された設定で、エージェント（OpenAIAgent）が各ドキュメント単位で初期化され、ドキュメントの要約とクラシックなQAメカニクスを難なくこなし、トップエージェントがドキュメントエージェントへのクエリのルーティングおよび最終的な回答の合成を担当しています。

各ドキュメントエージェントには、ベクトルストアインデックスと要約インデックスの2つのツールがあり、ルーティングされたクエリに基づいてどちらを使用するかを決定します。そして、トップエージェントにとって、すべてのドキュメントエージェントはツールです。

このスキームは、複数の関与するエージェントによる多機能のRAGアーキテクチャを示しています。また、クラシックな単一ドキュメントの要約およびQAメカニクスと共に、異なるドキュメントおよびその要約で説明されるさまざまなソリューションやエンティティを比較する能力も備えています。これは、代表的なチャットとドキュメントの収集の使用ケースをカバーしています。

このような複雑なスキームの欠点は、画像から推測できます – エージェント内のLLMとの複数のやり取りにより、少し遅くなる可能性があります。万一の場合、LLMの呼び出しは常にRAGパイプラインで最も長い操作です – 検索は設計上、速度に最適化されています。そのため、大規模な複数のドキュメントのストレージの場合、スケーラブルにするためにこのスキームを簡略化することをお勧めします。

8. レスポンス合成器

これはRAGパイプラインの最終ステップであり、慎重に取得したすべてのコンテキストと初期のユーザークエリに基づいて回答を生成するものです。最も単純なアプローチは、一度にすべての取得したコンテキスト（一定の関連性の閾値を超えるもの）とクエリを連結してLLMに入力することです。しかし、いつものように、取得したコンテキストを洗練させてより良い回答を生成するために、複数のLLM呼び出しを行う他のより洗練されたオプションもあります。

レスポンス合成の主なアプローチは次のとおりです：1. 取得したコンテキストをLLMにチャンクごとに送信して回答を繰り返し洗練する方法、2. 取得したコンテキストを要約してプロンプトに合わせる方法、3. 異なるコンテキストチャンクに基づいて複数の回答を生成し、それらを連結または要約する方法。詳細については、レスポンス合成モジュールのドキュメントをご覧ください。

エンコーダーとLLMの微調整

このアプローチでは、RAGパイプラインに関与する2つのDLモデルのうちのいずれか、つまりTransformerエンコーダー（埋め込みの品質としたコンテキストの取得品質に責任を持つ）またはLLM（提供されたコンテキストを最適に利用してユーザークエリに回答する責任を持つ）のいずれかを微調整します。幸運なことに、後者はフューショット学習器です。

現在は高品質な合成データセットを生成するための高性能なLLM（例えばGPT-4）が利用可能となりました。しかし、常に気を付けておく必要があります。プロの研究チームが注意深く収集し、クリーニングし、検証された大規模なデータセットでトレーニングされたオープンソースのモデルを小規模な合成データセットを用いて素早く調整することは、モデルの一般的な機能を制限する可能性があります。

エンコーダーの微調整

私もエンコーダーの微調整アプローチには少し懐疑的でした。検索に最適化された最新のTransformerエンコーダーは非常に効率的です。そのため、bge-large-en-v1.5（この記事執筆時のMTEBリーダーボードの上位4位）のパフォーマンス向上をテストしました。その結果、LlamaIndexノートブックの設定で、再現性の品質が2%向上しました。劇的な変化はありませんが、狭いドメインのデータセットでRAGを構築している場合には、このオプションを知っておくと良いでしょう。

ランカーの微調整

他のオプションとして、取得した結果を再ランキングするためのクロスエンコーダーを使用することもあります。これは次のような方法で機能します。クエリとトップkの取得したテキストチャンクをSEPトークンで区切って、クロスエンコーダーに渡し、関連するチャンクに対して1、非関連のチャンクに対して0を出力するように微調整します。この微調整プロセスの良い例はこちらで見つけることができます。その結果、クロスエンコーダーの微調整により、ペアワイズスコアが4%向上しました。

LLMの微調整

最近、OpenAIはLLMの微調整APIの提供を開始しました。また、LlamaIndexではチュートリアルを通じて、RAG設定でGPT-3.5-turboを微調整する方法を紹介しています。ここでのアイデアは、ドキュメントを取得し、GPT-3.5-turboを使用して複数の質問を生成し、その質問に基づいてGPT-4で回答を生成し（GPT4を使用したRAGパイプラインを構築する）、その質問-回答のペアのデータセットを使用してGPT-3.5-turboを微調整することです。RAGパイプラインの評価に使用されるragasフレームワークは、忠実度のメトリクスで5%の向上を示し、微調整されたGPT 3.5-turboモデルが提供されたコンテキストをより良く活用して回答を生成することができることを示しています。

最近の論文RA-DIT: 検索強化デュアルインストラクションチューニング（Meta AI Researchによる）では、クエリ、コンテキスト、回答の三つ組を使用してLLMとRetrieverをチューニングする技術を提案しています（元の論文ではデュアルエンコーダと呼ばれています）。実装の詳細については、ガイドを参照してください。この技術は、Fine-tuning APIを使用してOpenAI LLMを微調整し、元の論文ではLlama2オープンソースモデルを微調整するために使用されました。結果として、知識集約タスクのメトリックスでLlama2 65B with RAGと比較しておよそ5％の向上があり、常識的な推論タスクでも数パーセントの向上がありました。

もしRAGのLLM fine-tuningについてより良い手法をご存知の場合、特に小規模なオープンソースのLLMに応用されたものであれば、ぜひコメントセクションでご専門知識を共有してください。

評価

RAGシステムのパフォーマンス評価のためのいくつかのフレームワークが存在します。これらは、回答の関連性、回答の根拠、忠実度、および取得されたコンテキストの関連性など、いくつかの独立したメトリックスを持つというアイデアを共有しています。

前のセクションで言及されたRagasは、生成された回答の品質メトリックスとして忠実度と回答の関連性を使用し、RAGのリトリーバ部分にはクラシックなコンテキストの精度と再現率が使用されます。

最近公開された素晴らしいショートコースBuilding and Evaluating Advanced RAG（Andrew NG講師）で、LlamaIndexと評価フレームワークTruelensが提案されており、RAG triad（クエリに対する取得されたコンテキストの関連性、根拠（LLMの回答が提供されたコンテキストにどれだけ支持されているか）、およびクエリに対する回答の関連性）を提案しています。

キーともっとも制御可能なメトリックスは、取得されたコンテキストの関連性です。基本的には、上記で説明した高度なRAGパイプラインの1〜7部まで、エンコーダとランカーの微調整セクションはこのメトリックスを向上させることを目的としています。一方、8部とLLMの微調整は回答の関連性と根拠に焦点を当てています。

比較的シンプルなリトリーバ評価パイプラインの良い例はこちらで見つけることができます。

また、OpenAIのcookbookでは、ヒット率だけでなく一般的な検索エンジンの評価メトリックである平均相互順位と、忠実度や関連性といった生成された回答のメトリックスも考慮した少し高度な手法が示されています。

LangChainには、カスタムの評価ツールが実装されており、RAGパイプライン内で実行されるトレースを監視することで、システムをより透明にするLangSmithという高度な評価フレームワークがあります。

LlamaIndexを使用している場合、rag_evaluator llama packを使用することで、パブリックデータセットを使用してパイプラインを迅速に評価することができます。

結論

私はRAGへのアルゴリズム的アプローチの中核を概説し、いくつかのアプローチを示すことで、あなたのRAGパイプラインで試してみる新しいアイデアを引き起こすか、今年発明された多様な技術にいくらかのシステムをもたらすことを期待しています – 私にとって、2023年はこれまでで最も刺激的なMLの年でした。

その他にも多くの考慮事項があります。 ウェブ検索ベースのRAG（RAGs by LlamaIndex、webLangChainなど）やエージェント型アーキテクチャ（そしてこのゲームにおける最近のOpenAIのステーク）、そしてLLMsの長期記憶に関するいくつかのアイデアもあります。

回答の関連性と忠実さに加えて、RAGシステムの主な制作上の課題は速度です、特により柔軟なエージェントベースのスキームに取り組んでいる場合ですが、それは別の投稿の話です。このストリーミング機能を使用しているChatGPTとほとんどの他のアシスタントが使用しているのは、単に知覚された回答の生成時間を短縮するためです。そのため、私はより小さなLLMsや最近のMixtralとPhi-2のリリースが私たちをこの方向に導いている非常に明るい未来を見ています。

この長い投稿を読んでいただき、ありがとうございました！

主な参考文献は私の知識ベースに収集されており、このドキュメントセットとチャットするための共同パイロットがあります：https://app.iki.ai/playlist/236。

LinkedInで私に会ってください：https://www.linkedin.com/in/ivan-ilin-またはTwitterで：https://twitter.com/ivanilin9