著者 | フロリアン・ジューン 編纂者：岳陽 目次01 Adaptive-RAG: 問題の複雑さに応じてデータを分類・処理する検索強化型LLM（Adapt） 1.1 全体的なプロセス 1.2 分類器の構築 1.3 データセットの構築 1.4 トレーニングと推論 1.5 分類器のサイズの選択 02 RQ-RAG: RAGシステムにおけるクエリ最適化技術 2.1 データセットの構築 2.2 トレーニング 2.3 回答の選択 03 洞察と考察 3.1 これらの技術とSelf-RAGおよびCRAGとの比較 3.2 技術実践中に遭遇したいくつかの問題（エンジニアリング実装について） 3.3 小型モデルも活躍 04 結論 従来の RAG テクノロジーは LLM の応答におけるエラー率を効果的に低減できますが、図 1 の赤いボックスに示すように、このテクノロジーではユーザーの初期クエリを最適化することはできません。 図1：従来のRAG手法では、初期クエリ（図中の赤でマークされた部分）は改善されない。画像は原著者作成。 この方法には次のような問題が生じる可能性があります。
本稿では、クエリ分類とクエリ改良という2つの高度な戦略を考察します。どちらも小規模なモデルを学習することでシステム全体のパフォーマンスを向上させます。最後に、著者はこれら2つのアルゴリズムに関する理解と考察を共有します。 01 Adaptive-RAG: 問題の複雑さに応じてデータを分類・処理する検索強化型LLM（Adapt）1.1 全体的なプロセスAdaptive-RAGは、革新的な適応型フレームワークを提案します（訳者注：このシステムは、クエリの複雑さに基づいて、最適な情報検索・生成戦略を動的に選択できます）。図2に示すように、システムはクエリの複雑さに基づいて、最も単純なものから最も複雑なものまで複数の戦略を含む、最適なLLM利用戦略を動的に選択できます。 図2: 異なる検索強化型LLMの解法戦略の比較。出典: Adaptive-RAG[1] 図2(A)は、まず関連文書を検索し、次に回答を生成するシングルステップアプローチを示しています。ただし、このアプローチは、複数段階の推論を必要とする複雑なクエリに対しては十分な精度が得られない可能性があります。 図2(B)は、反復的な文書検索と中間応答の生成を含む複数段階のプロセスを示しています。この手法はパフォーマンスは良好ですが、大規模言語モデル（LLM）とリトリーバーを複数回呼び出す必要があるため、単純なクエリの処理にはあまり効率的ではありません。 図2(C)は適応型アプローチを示しています。慎重に設計された分類器を用いることで、最適な検索戦略（反復検索、単一検索、あるいは検索手法なし）をより正確に決定・選択することができます。 Adaptive-RAGのワークフローをより直感的に理解していただくため、この記事では具体的なコード例を用いて解説します。現在、この技術のコード実装には、公式バージョン[2]、Langchain**バージョン[3]、LlamaIndexバージョン[4]、Cohereバージョン[5]の4つのバージョンがあります。この記事では、LlamaIndexバージョンを例に挙げてこの技術を紹介します。 詳細については、こちらのドキュメント[6]を参照してください。コード量が膨大であるため、この記事ではコアとなるコードスニペットの説明に重点を置きます。 図3: Adaptive-RAGのさまざまなツール。画像は著者によるもので、LlamaIndexバージョン[4]を参考にしています。 コードの実行方法はクエリの複雑さに応じて異なり、それに応じてさまざまなツールが呼び出されます。
図2(C)に示すように、分類器を用いて適切なツールを選択できます。ただし、公式版とは異なり、ここで使用する分類器はこのアプリケーションシナリオ向けに特別に学習されたものではなく、図4に明確に示されているように、既製のLLMが直接適用されています。 図4: Adaptive-RAGのツール選択。画像は著者によるもので、LlamaIndexバージョン[4]を参考にしています。 1.2 分類器の構築LlamaIndex バージョンのコード実装には分類子の構築手順は含まれていませんが、分類子の構築プロセスを完全に理解することは、その後の開発作業にとって非常に重要です。 1.3 データセットの構築この技術を実装する上での大きな課題は、クエリと複雑度のペアを含むトレーニングデータセットが不足していることです。では、この問題にどう対処すればよいのでしょうか？Adaptive-RAGは、必要なトレーニングデータセットを自動的に作成するために2つの戦略を採用しています。 Adaptive-RAG [7]が提供するデータセットによると、分類器トレーニングセットのデータラベル付け作業は、ラベル付きの公開されている質問と回答のデータセットに基づいていることがわかります。 処理戦略は 2 つあります。 ユーザーがアップロードしたクエリの場合、最も単純な非検索ベースの方法で正しい回答が得られた場合、そのクエリには「A」というラベルが付けられます。同様に、シングルステップのアプローチで正しく回答できるクエリには「B」というラベルが付けられ、マルチステップのプロセスで正しく回答できるクエリには「C」というラベルが付けられます。ただし、より単純なモデルの方が優先度が高いことを強調しておくことが重要です。つまり、シングルステップとマルチステップの両方の方法で正しい回答が得られ、非検索ベースの方法では正しく回答が得られない場合、図5に示すように、そのクエリには「B」というラベルが付けられます。 図 5: Adaptive-RAG データセットのサンプル例、元の著者からのスクリーンショット。 上記の3つの方法のいずれも正しい回答を生成しない場合は、一部の質問がまだラベル付けおよび分類されていないことを意味します。この場合、公開データセットに基づいて直接分類します。具体的には、シングルホップデータセットのクエリは「B」、マルチホップデータセットのクエリは「C」とラベル付けされます。 1.4 トレーニングと推論トレーニング方法では、クロスエントロピー損失関数を採用し、自動的に収集されたクエリと複雑さのペアに基づいて分類器をトレーニングします。 次に、推論プロセス中にクエリを分類器に入力し、クエリの複雑度レベルを決定します。レベルラベルは「A」、「B」、「C」のいずれかになります：o = Classifier(q)。 1.5 分類器モデルのサイズの選択図6：異なるサイズの分類モデルの実験結果。出典：Adaptive-RAG[1] 図6からわかるように、分類モデルのサイズに関わらず、パフォーマンスに大きな差はありません。小さなモデルでも同じレベルのパフォーマンスを維持できるため、リソース利用効率の向上に効果的です。 次に、クエリ最適化手法である RQ-RAG を紹介します。 02 RQ-RAG: RAGシステムにおけるクエリ最適化技術前述の課題に対処するために、RQ-RAG は図 7 に示すように 3 つの最適化手法を提案しています。 図7：RQ-RAGが使用するモデルは、ニーズに応じて情報検索を実行し、必要に応じてクエリを書き換え、分解、曖昧性を解消することができます。出典：RQ-RAG[8]。
この方法により、図 7 の下部に示すように、取得された情報が包括的かつ正確であることが保証され、質問に効果的に答えることができます。 RQ-RAG は Llama2 7B モデルをエンドツーエンドでトレーニングし、書き換え、分解、および曖昧性の除去を通じてモデルがクエリ検索パフォーマンスを動的に向上できるようにします。 RQ-RAG[9]のコードは現在リファクタリング段階[10]にあるため、一部の機能はまだ完全に実装されておらず、この記事ではそれらを説明することはできません。 2.1 データセットの構築RQ-RAG システムのエンドツーエンドの性質を考えると、データセット構築プロセスに重点を置くことが重要です。 図8：データセット構築プロセス。出典：RQ-RAG[8] データセット[11]の構築は主に以下のステップで構成される。 1.まず、図9に示すように、様々な利用シナリオ（マルチターン対話、分解が必要なクエリ文、曖昧性解消が必要なクエリ文など）を網羅したコーパスを収集します。このコーパスに基づいて、タスクプールを構築します。 図9：データセットの構造。出典：RQ-RAG[8] 2.次のステップでは、タスクプール内のタスクを、マルチターン対話、クエリ分解、クエリ曖昧性解消の3つの主要なタイプに分類します。例えば、マルチターン対話データセット内の各サンプルは、マルチターン対話カテゴリに分類されます。 3. 3つ目のステップは、ChatGPT**を用いて様々なクエリを最適化することです。次に、これらの最適化されたクエリ文を用いて外部データソースから情報を取得します。一般的に、DuckDuckGoが主要な情報検索ソースであり、この検索プロセスは不透明な「ブラックボックス」と考えられています。 4. 4番目のステップでは、最適化されたクエリとそのコンテキストに基づいて、ChatGPTに修正されたモデル応答を生成するよう指示します。このプロセスを繰り返すことで、合計約40,000（40k）のインスタンスが蓄積されました。 図10、11、12は、ChatGPTとのやり取りで使用されるプロンプトテンプレートを示しています。青いテキストは、状況に応じて入力する必要がある具体的な内容を示しています。 図10：データセット構築時に使用したマルチターン対話プロンプト単語テンプレート。出典：RQ-RAG[8] 図11：データセット構築時に使用したクエリ分解プロンプトテンプレート。出典：RQ-RAG[8] 図12：データセット構築時に使用したクエリ曖昧性解消プロンプトテンプレート。出典：RQ-RAG[8] 上記の手順をすべて完了すると、図 13 の右側に示すトレーニング サンプルが取得されます。 図13: トレーニングサンプル。出典: RQ-RAG[8] 各トレーニング サンプルは、基本的に特定のトークンを含む操作シーケンスです。
2.2 トレーニング訓練データセットを取得した後、従来の自己回帰法[12]を用いて大規模言語モデル（LLM）を訓練することができる。具体的な訓練目的関数を図14に示す。 図14：RQ-RAGモデルの訓練目標。出典：RQ-RAG[8] つまり、トレーニングの核心は、モデルパラメータを微調整して、各ステップ i で、元の入力 x、最適化されたクエリ qi、および取得されたドキュメント di に直面したときに、モデル M がモデル応答 y に対して最も高い確率の予測を与えることができるようにすることにあります。 2.3 回答の選択各反復処理において、モデルはクエリの書き換え、分解、曖昧性の解消といった特定のニーズに基づいて、複数の検索クエリ文を生成します。これらのクエリは異なるコンテキストを獲得することで、モデルが複雑なタスクをより包括的かつ柔軟に処理できるようになります（これにより、拡張パスの多様化が促進されます）。 図15：異なるパスに対して、我々は3つの異なる戦略を開発しました。それは、パープレキシティ（PPL）、信頼度、そしてアンサンブル学習に基づく選択手法です。出典：RQ-RAG[8] 図15に示すように、RQ-RAGはツリーデコード戦略を開発し、3つの選択メカニズム[13]を使用しました。3つの選択メカニズムとは、パープレキシティベースの選択方法、信頼度ベースの選択方法、およびアンサンブルベースの選択方法です。 パープレキシティベースの選択手法では、モデルはすべての出力の中で最も低いパープレキシティ（PPL）を持つ回答を選択します。信頼度ベースの選択手法では、最も高い信頼度スコアを持つ結果を選択します。一方、アンサンブル学習ベースの選択手法では、累積信頼度スコアが最も高い最終結果を選択する傾向があります。 03 洞察と考察3.1 これらの技術とSelf-RAGおよびCRAGとの比較検索前に元のクエリを最適化するAdaptive-RAGやRQ-RAGとは異なり、Self-RAG[14]とCRAG[15]は、検索操作をいつ実行するかを決定することと、検索操作後の情報処理効率をどのように最適化するかに重点を置いています。特にCRAGは、Web検索に使用されるクエリ文を書き換えることで、検索結果の情報品質を向上させる点が注目に値します。 RQ-RAGとSelf-RAGはどちらも、小規模な言語モデルを学習することで、元の大規模モデル（LLM）を置き換えます。一方、Adaptive-RAGとCRAGは元のモデルを維持し、クエリを分類または評価するための2つの機能層のみを追加します。 注目の Adaptive-RAG と RQ-RAG はどちらも Self-RAG よりも優れていると主張しており、それぞれの論文には対応する実験レポートが含まれています。 生成プロセスの観点から見ると、Self-RAG、CRAG、および Adaptive-RAG は複雑なツリーデコード戦略を採用していないため、よりシンプルで高速であるように見えます。 3.2 技術実践中に遭遇したいくつかの問題（エンジニアリング実装について）クエリが複数ターンの対話に変換される場合、大規模な言語モデルを用いて長いプロンプト語データを処理すると、応答に遅延が生じる可能性があります。現在の私の理解に基づくと、この問題の効果的な解決策としては並列化が考えられます。 さらに、Adaptive-RAGとRQ-RAGはどちらもクエリを分類します。しかし、これらの分類手法は本当に最適な状態に達しているのでしょうか？特定の運用シナリオに完全に適合しているのでしょうか？他の分類戦略を使用することで、より良い結果を得ることができるのでしょうか？これらの疑問は、一連の比較実験を通じて検証する必要があります。 3.3 小型モデルも活躍RQ-RAG の実際のアプリケーションでは、データセットが適切に構築され、生成プロセスが改良されていれば、70 億のパラメータを持つモデルでも優れたパフォーマンスを実現できることが実証されています。 盲目的に大規模なモデルサイズを追求することは、必ずしも費用対効果の向上につながるわけではありません。リソースが限られているチームにとっては、データセットの最適化とアルゴリズムの改良に重点を置く方が賢明な選択となるかもしれません。 04 結論この記事では、クエリ分類とクエリ絞り込みという2つの技術的ソリューションを取り上げ、コード例を用いて解説します。また、これらの技術に対する著者の理解と考察も共有します。 検索エンジン拡張 (RAG) テクノロジーにご興味がございましたら、このシリーズの他の記事もぜひご覧ください。
読んでくれてありがとう！ このブログを楽しんで、新しいことを学んでいただければ幸いです。 フロリアン・ジューンAI研究者。LLM、RAG、エージェント、ドキュメントAI、データ構造に焦点を当てています。最新の記事はニュースレターをご覧ください。 https://florianjune.substack.com/ 終わり 参考文献 [1] https://arxiv.org/pdf/2403.14403 [2] https://github.com/starsuzi/Adaptive-RAG [3] https://github.com/langchain-ai/langgraph/blob/main/examples/rag/langgraph_adaptive_rag_cohere.ipynb [4] https://github.com/mistralai/cookbook/blob/e200507fba4e3404564f9249b345c89f83d73a10/third_party/LlamaIndex/Adaptive_RAG.ipynb [5] https://github.com/cohere-ai/notebooks/blob/main/notebooks/react_agent_adaptive_rag_cohere.ipynb [6] https://github.com/mistralai/cookbook/blob/e200507fba4e3404564f9249b345c89f83d73a10/third_party/LlamaIndex/Adaptive_RAG.ipynb [7] https://github.com/starsuzi/Adaptive-RAG/blob/0c88670af8707667eb5c1163151bb5ce61b14acb/data.tar.gz [8] https://arxiv.org/pdf/2404.00610 [9] https://github.com/chanchimin/RQ-RAG [10] https://github.com/chanchimin/RQ-RAG/tree/96b4ec981d4a4399e8402da1b75e16f7812aedfe [11] https://github.com/chanchimin/RQ-RAG/blob/96b4ec981d4a4399e8402da1b75e16f7812aedfe/data_curation/main_multiturn_answer_generate.py [12] https://github.com/chanchimin/RQ-RAG/blob/96b4ec981d4a4399e8402da1b75e16f7812aedfe/retrieval_lm/finetune.py [13] https://github.com/chanchimin/RQ-RAG/blob/96b4ec981d4a4399e8402da1b75e16f7812aedfe/retrieval_lm/output/sample_from_tree.py [14] https://medium.com/ai-advances/advanced-rag-08-self-rag-c0c5b5952e0e [15] https://ai.gopubby.com/advanced-rag-10-corrective-retrieval-augmented-generation-crag-3f5a140796f9 オリジナルリンク: https://ai.gopubby.com/advanced-rag-11-query-classification-and-refinement-2aec79f4140b |
