CoRAG：MCTS（モンテカルロ・ツリー）を用いた動的連鎖RAGモデル

CORAGの主な貢献

CORAG（コスト制約型）検索 Optimisation for Retrieval-Augmented Generation)は、革新的なRAG(Retrieval Augmented Generation)システムです。ラグ方法論における主な課題以下はCORAGの主な貢献である：

ブロック間の関連性を総合的に考慮::
- イノベーション・ポイントCORAGはRAGタスクにブロックの組み合わせ順序の最適化を導入した最初のフレームワークである。従来のアプローチとは異なり、CORAGは各テキストブロックを独立に扱ったり、ブロックをクラスタリングレベルでしか考慮しなくなった。 モンテカルロ木探索(MCTS) を使用して、ブロックの組み合わせの最適な順序を順次検索する。このアプローチは、ブロック間の複雑な関連性を完全に捉え、冗長な情報を避け、選択されたブロックの組み合わせがユーザーのクエリに完全に答えることを保証する。
- ゆうせいこのようにして、CORAGはより正確で適切な回答を生成し、生成の質を向上させることができる。
ブロック効用非単調性問題の解決::
- イノベーション・ポイントCORAGは 予算制約 予算枯渇を終了条件として考慮するのではなく、ブロック・ポートフォリオの最適化プロセスに統合する。このアプローチでは 非単調性つまり、ブロックを増やしても最終的な結果の質が向上するとは限らない。
- ゆうせいCORAGは、最適化の過程で予算の使い方を動的に調整することで、無関係なブロックや冗長なブロックが過剰に含まれるのを防ぎ、生成される回答の精度と妥当性を向上させます。
異なる照会分野への適応::
- イノベーション・ポイントCORAGは エージェントの設定エージェントは 比較学習 MCTSのコンフィギュレーションを異なるクエリドメインに動的に適応させる。エージェントは最適な リアレンジャー・モデル 歌で応える MCTSコンフィギュレーション.
- ゆうせいこのアプローチにより、CORAGは単純なキーワードクエリから複雑な推論問題まで、様々なタイプのクエリを柔軟に処理することができ、様々なアプリケーションシナリオにおいて高品質なレスポンスを保証します。
効率的でスケーラブルな検索戦略::
- イノベーション・ポイントCORAGはノード検索にMCTSを採用している。 並列展開技術 探索プロセスを加速する。このアプローチは、指数関数的な探索空間を線形に減らし、効果的に探検歌で応える 用いる.
- ゆうせいCORAGは、効率的な検索を維持し、計算コストと検索品質のバランスを取りながら、大規模なデータセットを扱うことができます。
大幅なパフォーマンス向上::
- 実験的検証実験の結果、CORAGはいくつかのベンチマークデータセットにおいて、既存のベースライン法を上回り、ROUGEスコアを約 30%.また、CORAGは効率性にも優れており、厳しいコスト制約の中で高品質の回答を提供している。

CORAGワークフローの例

CORAGがどのように動作するかを読者がすぐに理解できるように、以下にCORAGがどのようにユーザーからの問い合わせを処理し、最終的な応答を生成するかを示す完全なワークフローの例を示します。各ステップはワークフローの前後関係を表す入力と出力を含んでいます。

ステップ1：ユーザーのクエリー入力

輸入例えば、ユーザーがCORAGシステムに自然言語による問い合わせをする：
```
「光合成のプロセスを説明し、その効率に影響する要因を挙げよ。
```
輸出クエリーは クエリ埋め込みモジュール 処理。

ステップ2：クエリー埋め込み生成

輸入ユーザークエリテキスト。
扱う事前に訓練された モデルの埋め込み(BGE-M3など）は、クエリーテキストをベクトル表現に変換する。
輸出埋め込みベクトル（例えば1024次元のベクトル）を問い合わせる。
```
クエリ埋め込み：[0.123, -0.456, 0.789, ..., -0.012]
```

ステップ 3: エージェント予測の設定

輸入クエリ埋め込みベクトル [0.123, -0.456, 0.789, ..., -0.012].
扱う::
1. 特徴抽出埋め込みベクトルは エージェントの設定 な コーディングネットワーク 特徴抽出は
2. リアレンジャー予想最適な符号化ネットワーク出力予測 リアレンジャー・モデル例えば バージ・レランカー・ラージ.
3. MCTS構成予報同時に、符号化ネットワークは最適なMCTSを予測する。 設定パラメータ反復回数、コスト係数、探索係数などである。
輸出::
- 最適再編成モデル::バージ・レランカー・ラージ
- MCTS構成パラメータ::
  - 反復回数:: 15
  - コストファクター: 0.2
  - 探検要因: 2.5
```
最適Reranker: bge-reranker-large
MCTSの設定
- 反復: 15
- コスト係数: 0.2
- 探索係数: 2.5
```

ステップ4：潜在的なテキストブロックを取得する

輸入::
- クエリ埋め込みベクトル [0.123, -0.456, 0.789, ..., -0.012].
- ベクトルデータベース(例えば、あらかじめセグメント化されたテキストブロックとその埋め込みベクトルを含む）。

扱うの埋め込みベクトルを使用する。 類似検索ベクトル・データベースから最も関連性の高いテキスト・ブロックを検索する。以下は、最初に検索された5つのテキストブロックの例である：テキストブロック1::

光合成とは、植物や藻類、一部のバクテリアが光エネルギーを使って二酸化炭素と水をグルコースと酸素に変換するプロセスのことである。

テキスト・ブロック2::

光合成は主に植物の葉の葉緑体で起こり、光反応と炭素反応の2段階に分けられる。

テキストブロック3::

光合成の効率に影響を与える要因には、光強度、二酸化炭素濃度、温度、水の利用可能性などがある。

テキストブロック4::

光合成に対する光強度の影響は正の相関関係にあるが、光が強すぎると光阻害現象が起こり、光合成の効率が低下する。

テキストブロック5::

二酸化炭素は光合成の原料のひとつであり、その濃度は光合成の速度に直接影響する。

輸出: 潜在的なテキストブロックとその埋め込みベクトルのリスト。

チャンクの取得
- チャンク1: "光合成とは、植物、藻類、一部のバクテリアが光エネルギーを使って二酸化炭素と水をグルコースと酸素に変換するプロセスである。"
- チャンク2: "光合成は主に植物の葉の葉緑体で起こり、光反応と炭素反応の2段階に分けられる"
- チャンク3: "光合成の効率に影響を与える要因には、光強度、二酸化炭素濃度、温度、水の利用可能性などがある。"
- チャンク4: "光強度が光合成に与える影響は正の相関があるが、光が強すぎると光阻害現象が起こり、光合成の効率が低下する。"
- チャンク5："二酸化炭素は光合成の原料の一つであり、その濃度は光合成速度に直接影響する。"

ステップ5：MCTSツリーサーチ

輸入::
- テキストブロック候補のリスト::
  - チャンク1：...
  - チャンク2：...
  - チャンク3：...
  - チャンク4：...
  - チャンク5：...
- MCTS構成パラメータ::
  - 反復回数:: 15
  - コストファクター: 0.2
  - 探検要因: 2.5
- リアレンジャー・モデル::バージ・レランカー・ラージ
扱う::
1. ルートノードの初期化ルート・ノードは、テキスト・ブロックが選択されていない空の状態を表す。
2. 反復拡大::
  - オプション使用 UCBアルゴリズム 現在のユーティリティが最も高いノードを選択します。例えば、Chunk 3はクエリとの関連性が最も高いため、最初の反復に選択されます。
  - エクステンション可能なすべての子ノード（テキストチャンクの新しい組み合わせ）を生成します。例えば、チャンク3の子はチャンク1、チャンク2、チャンク4、チャンク5になるかもしれない。
  - 評価使用 リアレンジャー・モデル バージ・レランカー・ラージ すべての新しい組み合わせの効用を並行して評価する。例えば、チャンク3＋チャンク1、チャンク3＋チャンク2などの組み合わせの効用を評価する。
  - 更新ノードのユーティリティとアクセスカウントを更新し、更新を上方へ伝播する。
3. 繰り返す最大反復回数（15回）に達するまで、選択、展開、評価、更新のステップを繰り返す。
4. 終了条件最大反復回数に達した。

輸出テキストブロックの最適な結合順序

最適なチャンクの組み合わせ
- チャンク3: "光合成の効率に影響を与える要因には、光の強度、二酸化炭素濃度、温度、水の利用可能性が含まれる"
- チャンク1: "光合成とは、植物、藻類、一部のバクテリアが光エネルギーを使って二酸化炭素と水をグルコースと酸素に変換するプロセスである。"
- チャンク2: "光合成は主に植物の葉の葉緑体で起こり、光反応と炭素反応の2段階に分けられる。"

銘記するMCTSの過程で、CORAGは効用に応じて組み合わせ順序を動的に調整し、最終的に最適な組み合わせ順序を選択する。

ステップ6：最終回答の作成

輸入::
- テキストブロックの最適な組み合わせ順序::
  - チャンク3：「光合成効率に影響を与える要因には、光強度、二酸化炭素濃度、温度、水の利用可能性などがある。
  - チャンク1：「光合成とは、植物、藻類、一部のバクテリアが光エネルギーを使って二酸化炭素と水をグルコースと酸素に変換するプロセスである。
  - チャンク2："光合成は主に植物の葉の葉緑体で起こり、光反応と炭素反応の2つの段階に分けられる"
- ユーザー照会光合成のプロセスを説明し、その効率に影響を与える要因を挙げよ。

扱う::

ビルドのヒントテキストブロックとユーザークエリを最適な順序で組み合わせて構成する。 LLM 入力プロンプトの例

User Query : 光合成のプロセスを説明し、その効率に影響を与える要因を挙げてください。
関連情報
1.光合成の効率に影響を与える要因には、光の強さ、二酸化炭素濃度、温度、水の利用可能性などがある。
2.光合成は、植物、藻類、一部のバクテリアが光エネルギーを使って二酸化炭素と水をグルコースと酸素に変換するプロセスである。
3.光合成は主に植物の葉の葉緑体で起こり、光反応と炭素反応の2段階に分けられる。

レスポンスの生成使用 LLM(例：Llama3）プロンプトに対する最終回答を作成する。

輸出最終的な自然言語での返答。

最終回答
「光合成とは、植物や藻類、一部のバクテリアが光エネルギーを使って二酸化炭素と水をグルコースと酸素に変換するプロセスのことである。主に植物の葉の葉緑体で起こり、光反応と炭素反応の2段階に分けられる。光合成の効率に影響を与える要因には、光強度、二酸化炭素濃度、温度、水の利用可能性などがある。"

ステップ7：レスポンス出力

輸入最終的な自然言語での返答。
扱うユーザーに応答を提示する。
輸出ユーザー・インターフェースは応答結果を表示する。

概要

上記のワークフローの例から、CORAGの動作原理は以下のステップに要約できる：

クエリーの埋め込み生成ユーザークエリをベクトル表現に変換します。
エージェント予測の設定最適なリアレンジャーモデルとMCTSの設定パラメータを予測する。
テキストブロックの候補を取得するベクトルデータベースから最も関連性の高いテキストブロックを取得します。
MCTSツリーサーチMCTSを使って、テキストブロックの最適な結合順序を検索する。
最終回答の作成LLMを使用して、テキストブロックの最適な組み合わせに基づいて最終的な回答を生成します。
応答出力ユーザーに応答を提示する。

これらのステップは、CORAGがどのように検索、エンハンス、生成の3つのフェーズを効果的に組み合わせ、高品質の自然言語応答を提供しているかを示しています。詳細なデータ例により、読者はCORAGのデータ処理プロセスとその仕組みをより明確に理解することができる。

原文:: https://arxiv.org/pdf/2411.00744

キャプション:: CORAG: 検索強化生成のためのコスト制約付き検索最適化システム

著者Ziting Wang、Haitao Yuan、Wei Dong（南洋理工大学）、Gao Cong（南洋理工大学）、Feifei Li（アリババ・グループ）

抄録

大規模言語モデル(LLM)は、生成タスクにおいて優れた能力を発揮するが、最新の情報にアクセスすることはしばしば困難であり、幻滅を招きかねない。検索強化型生成（RAG）は、外部データベースからの知識を統合することで、この問題に対処し、より正確で関連性の高い応答を実現する。LLMのコンテキストウィンドウの制限により、外部データベースのコンテキスト全体をモデルに直接入力することは非現実的である。その代わりに、最も関連性の高い情報、すなわち「チャンク」（塊）のみが選択的に検索される。しかしながら、現在のRAG研究は3つの重要な課題に直面している。第一に、既存のソリューションは通常、各チャンクを独立して選択し、チャンク間の潜在的な関連性を無視している。第二に、実際にはチャンクの効用は「非単調」であり、チャンクを増やすと全体の効用が低下する可能性がある。従来のアプローチでは、チャンクに含まれるブロック数を最大化することに重点を置いているため、かえってパフォーマンスが低下する可能性があります。第三に、ユーザークエリの種類にはそれぞれ固有の特性があり、それに合わせた処理が必要であるが、現在のソリューションではその特性は十分に考慮されていない。

このような課題を克服するために、我々は検索強化生成のためのコスト制約付き検索最適化システムCORAGを提案する。我々は、モンテカルロ木探索（MCTS）ベースの戦略フレームワークを採用し、最適なブロックの組み合わせを順次見つけることで、ブロック間の関連を包括的に考慮する。また、予算枯渇を終了条件とする代わりに、予算制約をブロックの組み合わせの最適化プロセスに組み込むことで、ブロックの効用の非単調性の問題を効果的に解決する。さらに、コンフィギュレーションエージェントを設計することにより、本システムは各クエリタイプに対する最適なコンフィギュレーションを予測し、適応性と効率性を向上させる。実験の結果、我々のフレームワークはベースラインモデルと比較して最大30%の性能向上を示し、長いコンテキストのアプリケーションに対するフレームワークの有効性、拡張性、適用性を強調した。

PVLDB 参照形式。

CORAG: A Cost-Constrained Retrieval Optimisation System for Retrieval-Augmented Generation.pvldb, 14(1): xxx-xxx, 2020.
doi:XX.XX/XXX.XX

図1：データブロックの組み合わせ順の例。

1 はじめに

LLMは生成タスクにおいて優れた能力を発揮しているが、最新の情報を取得する際にしばしば困難にぶつかり、幻覚を引き起こすことがある [10, 38]。このような課題に対処するために、RAGが重要なソリューションとして浮上してきた。外部のデータソースをLLMに統合することで、RAGはより正確で関連性のある最新の情報を提供することができる。今日、RAGはLLMの文脈で、特に質問と回答のタスク[2, 22, 29]、医療情報検索[1, 32]、時系列分析[12, 26, 40]など、更新された外部知識を必要とするタスクで広く研究されている。外部データソースは通常非常に大きいため、LLMに直接入力するのは非現実的である。この問題を解決するため、通常、データは重複しないチャンクに分割され、ベクトルデータベースに格納される。そのため、最も関連性の高いチャンクを見つけるための効率的で正確な検索構造とアルゴリズムを設計することが重要な研究テーマとなっており、データベース[39, 48]や機械学習コミュニティ[2, 35, 43]で広く研究されている。

しかし、既存のアプローチには3つの重要な課題がある。

課題1：ブロック間の連携 現在、最も関連性の高いブロックを特定するために、主に2つのアプローチがある。最初のアプローチは、問題を近似k近傍（AKNN）タスクとして定式化し[41, 45]、各ブロックにスコアを割り当て、スコアでランク付けされた近似上位kブロックを選択する。2番目のアプローチは、ブロックをクラスタ化し、クエリに対して最も関連性の高いクラスタ内のすべてのブロックを返す[22, 29]。しかし、どちらの手法もブロック間の潜在的な関連性を無視する。最初の手法は関連性を完全に無視し、2番目の手法は各クラスタ内のすべてのブロックを等しく関連性があるものとして表面的に考慮するだけである。その結果、これらの方法では、複数のブロックが類似した情報や冗長な情報を伝えている場合、選択されたブロックにかなりの冗長性が生じる。

例えば、図1に示すように、エッフェル塔の高さと歴史を問い合わせる場合、各ブロックを独立に扱うと、貪欲法はブロックχ3とχ1を選択する。しかし、これら2つのブロックは履歴情報を提供するだけであり、クエリに完全に答えるには不十分である。一方、クラスタリング手法では、χ1、χ2、χ3、χ4のすべてを返すことになり、冗長になる。最適解はχ3とχ4を選択し、冗長性なく必要な情報を提供する。さらに、研究[11, 19, 42]は、ブロックの順序がLLMの性能に影響することを示している。例えば、エッフェル塔の場合、ブロックχ3とχ4を選択するとき、χ4を最初の位置に置くと、逆の順序に比べて高いスコアが得られる。しかし、ブロックの組み合わせの最適な順序を決定することは、どちらも利用可能なブロックの数に応じて指数関数的に増大する探索空間を必要とするため、困難な課題である。本論文では、さらにこの問題が NP-hard であることを示す（セクション 2.1 参照）。

課題2：効用の非単調性。 現在の解決策は、より多くのブロックを含めば常に最終的により良い結果が得られるという仮定に基づいている。具体的には、AKNNベースのアプローチでは、毎回正確にk個のブロックが決定論的に選択される。クラスタリングベースのアプローチでは、クラスタとクエリ間の距離の閾値が設定され、この閾値内のすべてのクラスタが返される。どちらも可能な限り多くのブロックを返す。しかし、実際にはブロックの効用は単調ではない。より具体的には、チャンクが多すぎると、エッジに関連するコンテンツが追加されることで重要な情報が希薄になり、明瞭さを低下させるノイズが発生する。さらに、ブロック間の矛盾や微妙な違いがモデルを混乱させ、レスポンスの質を低下させることもある。例えば、図1に示すように、ブロックχ1を追加すると、χ3とχ4が選択されたときの効用は減少し、効用スコアが実際には通常非単調であるという事実が浮き彫りになる。

課題3：クエリの多様性。 ユーザーのクエリには様々なタイプがあり、それぞれが固有の特徴に基づく異なるランキング戦略を必要とする[47]。現在のRAGシステムでは、ブロックのユーティリティスコアは通常、割り当てられた再ランカーモデルによって決定される。現在までに、様々なリランカーモデルが存在するが、その性能はクエリの種類によって大きく異なり、全てのクエリのバリエーションにおいて一貫して他を凌駕する単一の固定リランカーモデルは存在しない（詳細はセクション6.3.4の実験を参照）。現在のアプローチ[20, 46]は通常、ブロックランキングのために静的なリランカーモデルに依存しており、異なるクエリコンテキストに適応する柔軟性に欠けている。

問題提起である： ブロック間の関連性やユーティリティの非単調性を十分に考慮し、あらゆるタイプのクエリに対応できるRAGシステムは存在するのか？

1.1 我々の貢献

本稿では、RAGシステムにおけるブロック検索を最適化するための、MCTSに基づく新しいポリシーツリーフレームワークを提案することで、この問いに肯定的に答える。全体として、我々の貢献は以下のように要約できる：

- 我々は、RAGタスクにおけるブロックの組み合わせ順序を考慮した最初のRAGフレームワークを提示する。各ブロックを独立に、あるいはクラスタリングレベルで考慮するのではなく、MCTSを用いて最適なブロックの組み合わせ順序を順次探索する。まず、ルートノードを初期化する。次に、反復の間に、最も高い効用を持つノードを選択し、その拡張ノードの効用を計算することで、ツリーを拡張する。各拡張の後、ポリシーツリー全体の効用を更新する。このプロセスにおいて、各反復の決定は選択されたブロックに依存するため、ブロック間の関連を完全に考慮することができる。さらに、MCTSは指数関数的な探索空間を線形に減らし、並列展開技術を適用して計算効率をさらに高める。この設計により、我々はチャレンジ1に取り組む。
- 予算の枯渇を終了条件として考慮するこれまでのRAGフレームワークとは異なり、我々は、ブロックの組み合わせの最適化のプロセスに予算制約を統合し、ブロックの効用の非単調性を完全に考慮する新しい定式化を提案することで、課題2に対処する。さらに、相関性の高い低コストのブロックを優先し、トークンの長さを考慮することで、計算コストをさらに削減する。計算コストを削減する。
- 我々は、MCTSの設定をクエリに動的に適応させる比較学習ベースのエージェントを提案し、再ランカーモデルと設定を特定のクエリドメインに適応させる。このアプローチは、動的でドメイン固有のクエリに対して柔軟性と頑健性を提供し、チャレンジ3に適応する。
- さらに、我々のフレームワークといくつかの最先端手法を比較する包括的な実験を行った。その結果、我々のアプローチの有効性、効率性、スケーラビリティが検証され、ベースラインと比較して30%の性能向上が見られた。

2 予備知識

本節では、まずセクション2.1において、ブロックやブロックの組み合わせ順序など、いくつかの重要な概念の定義を紹介する。次に、ブロック順序最適化問題のNP困難性の証明を行う。最後に、セクション2.3で関連する研究について述べる。

2.1 キーコンセプト

ラグ＆チャンクス RAGは、外部コーパスから関連する文脈を取得することによって、生成モデルの性能を向上させる効率的な手法である。この手法では、コーパスはまずブロックと呼ばれる、より小さく管理しやすい単位に分割され、それらはベクトルデータベースに格納される。したがって、ブロックの正式な定義は以下のようになる：

定義2.1（ブロック）。 Cを文書のコーパスとし、ブロックχをCから抽出されたテキストの連続ブロックと定義する。形式的には、ブロックχは一連のトークン(t1, t2, ... , tn)から構成される。ここで、各tiはCのトークンであり、サイズnはユーザーによって設定される。

RAGシステムでは、各ブロックは、ブロックの意味的な意味を捉え、文脈的に類似したコンテンツの検索を可能にする埋め込みモデルを用いて、ベクトル表現に埋め込まれる。新しいクエリを受け取ると、ベクトルデータベースはクエリに最も意味的に関連するブロックを特定するために類似検索を実行する。これらの検索されたチャンクは、ジェネレーター（大規模言語モデルなど）に渡され、検索されたコンテンツに基づいて最終的なレスポンスが生成される。具体的には、ブロックに含まれるトークンの数が多いほど、ジェネレーターにかかるコストは高くなる。したがって、ブロックのコストをcost(χ) = |χ|と定義する。

ブロックの組み合わせ順。 RAGシステムでは、ベクトルデータベースの検索結果に複数のブロックが含まれることがある。しかし、生成モデルの入力制約により、これらのブロックをすべて使用することは現実的ではない。したがって、与えられたコスト予算に適合するように、ブロックの組み合わせと呼ばれる最適なブロックのサブセットを選択する必要がある。さらに、組み合わせ内のブロックの順序は、生成モデルの性能に大きな影響を与える。目標は、最適な順序を持つブロックの組み合わせの順序を特定することであり、正式には以下のように定義される：

定義2.2（最適ブロック組み合わせ順序選択）。 χ1、χ2、...、χk}を潜在的ブロックの集合とする。χk}を潜在的なブロックの集合、ȑをコスト予算、Φ = ⟨χφ1, ... , χφm⟩を潜在的なブロックの組み合わせの順序とする。χφm⟩は潜在的なブロックの組み合わせの順序を表し、各χφiはブロックであり、インデックスφiはΦにおけるその位置を表す。U(Φ)を再ランカーモデルによって割り当てられた効用スコアとする。我々の目標は、最終的な応答を生成するためにLLMに供給するコスト制約の下で、効用スコアを最大にするブロックの組み合わせの順序を見つけることである。

2.2 NP困難性の証明

ブロック組み合わせ逐次選択がNP困難であることを示すために、最大重み付きハイパーグループ問題(MWHP)を一般化する。MWHPはNP困難であるので、どのようなMWHPインスタンスも多項式時間でブロック組み合わせ最適化インスタンスに変換できることを示す。

2.2.1 MWHPの問題定義

Vは頂点の集合、Eはハイパーエッジの集合であり、各ハイパーエッジはVの部分集合を含む。w1: v → ↪Lu_2D と w2: e → ↪Lu_2D は重み関数であり、各頂点とハイパーエッジにそれぞれ重みを割り当てる。頂点の部分集合V' ⊆ Vが与えられたとき、V'がeのすべての頂点をカバーするとき、ハイパーページeはV'に属する、すなわちe∈V'と言う。目標はk個の頂点を見つけ、これらの頂点とハイパーエッジの重みの和を最大にすることである：

2.2.2 正規化プロセス

ここで、与えられたMWHPインスタンスから、ブロック組み合わせ最適化問題の対応するインスタンスを構築する。各ノードv∈Vに対して、対応するブロックXvを作成する。そのコストcost(Xv) ≡ 1を定義する。ブロック組み合わせ順序Φは、V(Φ) ⊆ Vと表記されるVの頂点の部分集合に対応する。

最後に、B = kとし、以下を目指す。

Φを使うは(4)の解を表す。)は(2)の解であり、還元はO(|V|-|E|)の時間で行うことができる。

この帰納法は、ブロックの組み合わせ最適化問題において、再ランカーが任意であることを前提としていることに注意。再ランカーについてある仮定を置くと、最適なブロックの組み合わせ順序を求める複雑さを大幅に減らすことができる。例えば、リランカーが関連を考慮せず、各ブロックの効用スコアを線形に合計するだけであれば、各ブロックを独立に評価することができる。しかし、本稿では最も一般的なケースを扱い、再ランカーモデルに関する仮定は設けない。

2.3 関連作品

2.3.1 エンハンスメントの生成

RAG[14、20]は知識集約的な自然言語処理タスクの処理に広く使われている。典型的なRAGプロセスでは、密な埋め込みに基づく検索器が外部データベースから関連情報を検索し、生成プロセスでLLMがそれを利用する。このプロセスを改善するために、いくつかの研究[5, 18, 22, 35]が、LLMの生成ニーズにより適した検索器の適合、多段階検索法の開発、および無関係な情報のフィルタリングに焦点を当てている。最先端の検索器は数多く存在するが[8, 9, 15, 16, 27, 34]、検索器とLLMをエンド・ツー・エンドのプロセスで最適化すること[25, 31]がより有望である。例えば、研究[30]では、リトリーバとLLMを同時に、あるいは段階的に共同学習させることに焦点を当てている。しかし、これでは最適化のためのエージェントロスが必要となり、学習プロセスが複雑になる。特に、埋め込みデータベースのインデックスを頻繁に再作成する必要がある場合には、高い計算コストが発生する。そのため、[5]のようなアプローチは、複雑なマルチステップクエリをより小さなサブインデックスに分解し、頻繁にインデックスを再作成することなく、応答の包括性を向上させる。しかし、これらのアプローチは通常、LLMの全体的な応答品質に大きく影響するブロックの組み合わせ順序の重要な役割を無視している。我々の知る限り、この論文はRAGタスクにおけるブロック結合順序を考慮した最初のアプローチである。

2.3.2 RAGの再ランク付け

RAGプロセスにおいて検索性能を向上させるためには、再ランク付け手法が不可欠である[43, 44, 51]。

図2：CORAGシステム・アーキテクチャの概要

従来の再ランク付け手法[33, 50]は、通常、検索されたコンテキストをランク付けするために、BERTやT5などの中規模の言語モデルに依存している。しかし、これらのモデルは通常、クエリとコンテキストの間の意味的関係を捉えるのに苦労する。そのため、最近の研究[43]では、ノイズの多い情報や無関係な情報が存在する場合でも、コンテキストの再ランク付けを改善するコマンド調整LLMの可能性が強調されている。このような進歩にもかかわらず、RAGシステムにおけるLLMの再順位付け能力はまだ十分に活用されていない。特に、ブロックの順位付けがLLMの性能に影響することが示されており[19]、RAGタスクにおいてブロックの組み合わせの順序を考慮する必要性が強調されている。しかし、既存のモデルは、孤立したブロックではなく、特定の順序やブロックの組み合わせが最適な検索に必要とされる状況には適していない。したがって、今後の研究では、RAGフレームワーク内のクエリに応答して、より効率的にブロックをシーケンスするために、LLMをより良く利用する必要がある。

2.3.3 大規模言語モデルのための強化学習

近年、強化学習（RL）は、様々なデータ管理やRAGタスクに使用されるようになってきている。RL技術は、検索エンジンなどの外部の知識ソースを利用することで、大規模な言語モデルの生成能力を向上させることができる[13, 23]。特に、人間のフィードバック[4, 36, 37]は、RLフレームワークを通じて、モデルがより正確で文脈に関連した応答を生成するのを助けるために統合することができる。さらに、多くのクエリ最適化アプローチ[17, 21, 49]は、モデルの性能がクエリチューニングを通知し、最終的に下流のタスクの結果を改善することで、検索プロセスをさらに改善する。本研究では、RAGシステムにおけるブロックの組み合わせ逐次検索プロセスを最適化するために、軽量RL手法であるMCTSを適用する。また、MCTS検索プロセスをガイドするための設定エージェントを導入する。我々の知る限り、これはこの特殊な問題に対する最初のアプローチである。

3 システム概要

前述したように、既存のRAGフレームワークは3つの重要な課題に直面している：ブロック間の関連性とブロックの組み合わせの連続的な有用性の非単調性を適切に考慮する方法、そして異なるクエリドメインに適応する方法である。これらの課題は出力の関連性を低下させる。これらの問題に対処するために、我々は、クエリドメインとユーザ予算の両方を考慮して、最適なブロックの組み合わせを検索するように設計されたシステムであるCORAGを紹介する。本システムの最も重要な要素として、最適ブロック組み合わせ検索モデルを紹介する。このモデルは、ブロックの組み合わせ順序の逐次検索にMCTSベースのポリシーツリーを採用しており、ブロック間の関連性（課題1）とブロックの組み合わせ順序の実用性の非単調性（課題2）を十分に考慮することができる。また、様々なクエリドメインに対して最適なMCTS構成と再ランカーを推奨する構成推論モジュールを提案し、課題3に取り組む。以下、これら2つのモジュールについて簡単に説明する。

最適ブロック組み合わせ探索 ブロックの関連性を考慮する簡単なアプローチは、（ステップ1に示すように）ベクトル・データベースからブロックの候補を検索し、可能なすべてのブロックの組み合わせを網羅的に探索することからなる。しかし、このアプローチは大きな待ち時間と計算コストをもたらす。これを軽減するために、最適ブロック組み合わせ探索をツリー内ノード探索問題として再構成する戦略ツリー（ステップ2に示す）を構築する。具体的には、戦略ツリーのルート・ノードは空の初期状態を表し、各子ノードは特定のブロックの組み合わせに対応する。例えば、ルートノードがブロックχ1を表す子ノードを持つ場合、その子ノードの1つはχ1+χ2の組み合わせを表し、別のノードはχ1+χ3

我々はこの問題を解決するためにMCTSベースの探索アルゴリズムを設計する。従来のMCTSとは異なり、我々のアプローチでは、可能性のある全ての子ノードを評価しながら、各反復において最も実用性の高いノードを展開する。さらに、戦略ツリー探索中にコストと予算の制約を考慮する。ノード効用は探索とコスト制御のバランスをとることにより計算され、効率と精度を最適化する。

構成の推論： コンフィギュレーション・チューニングの単純な解決策は、可能なコンフィギュレーションや再ランカーをすべて列挙し、その結果を並列に計算し、最適なコンフィギュレーションを選択することだろう。しかし、これはRAGシステムの非現実的なコストにつながる。ポリシーツリー探索プロセスのための構成（すなわち、反復回数、コスト係数、探索係数）を最適化するために、クエリドメインに基づいて動的に構成を生成する構成エージェントを導入する。このモデルの有効性を保証するために、正と負のラベルペアを用いた比較学習アプローチを採用する。正ラベルは同じベストリランカーからのクエリ埋め込みに対応し、負ラベルは異なるベストリランカーからのものである。この結合損失関数は、回帰（パラメータチューニングのため）と対比学習（ラベル識別を強化するため）を同時に最適化するために用いられる。

概要我々のフレームワークの流れを図2に示す。まず入力されたクエリに対して埋め込みを生成し、それを用いてベクトルデータベースから潜在的なブロックを検索する。これらのクエリ埋め込みは、クエリフィールドに基づいて最適なMCTSコンフィギュレーションを動的に生成するコンフィギュレーションエージェントにも供給される。この最適なコンフィギュレーションを用いて、検索された潜在的なブロックから最適なブロックの組み合わせと順序を決定するためにポリシーツリーを検索することができる。最後に、この最適なブロックの組み合わせを使って、LLMの最終的なヒントを構成する。

4 ブロック組み合わせ検索

先に述べたように、ブロックの組み合わせの順序は、LLMのヒント構築の効率に大きな影響を与える。潜在的な組み合わせの数は膨大であるため、特に多数のブロックが関係する場合、全ての可能なブロックの組み合わせ順序を列挙することは実行不可能である。本節では、最適なブロックの組み合わせ順序を探索する問題において、効率と精度の良いバランスを実現する新しいアプローチを提案する。セクション4.1では，この問題をポリシーツリーにおける最適ノードの探索としてモデル化する（セクション4.1）．そして，このノード探索問題を解くMCTSベースのアルゴリズムを提案する(セクション4.2)．

4.1 ストラテジー・ツリー・サーチ・モデリング

最適な組み合わせ順序を見つけるために、最初のステップは、すべての可能な組み合わせ順序を効率的に列挙できるデータ構造を見つけることである。自然な選択肢は木であり、根から葉のノードにトラバースすることで、すべての潜在的な答えを探索することができる。

ストラテジー・ツリー 図3に示すように、ベクトルデータベースから抽出されたすべての可能なブロックの組み合わせの順序を表す戦略ツリーを構築する。具体的には、ルートノードはブロックのない初期状態を象徴し、それに続く各ノードは潜在的なブロックから選択されたブロックを表す。したがって、子ノードは、潜在的なブロックのキューから次に利用可能なブロックを選択し、祖先ノードによって確立されたシーケンスにマージすることによって、親ノードから生成される。例えば、あるノードがブロックの組み合わせシーケンス{χ1}を表す場合、子ノードは{χ1, χ2}、{χ1, χ3}、{χ1, χ4}のような後続の組み合わせシーケンスを含むことができる。したがって、戦略ツリーを以下のように正式に定義する：

定義4.1（戦略ツリー）。 クエリqと潜在的なブロックの集合{χ1, χ2, ... , χn}が与えられたとき、ポリシーツリーTを構築する。Tのルート・ノードは、ブロックのない初期状態を表す。後続の非ルート・ノードは、残りの潜在的ブロックから新たに選択されたブロックをその親ノードのシーケンスにマージすることによって、ブロックのセットを含む。このプロセスにより、各非ルート・ノードにブロックの順序付けられた組み合わせが順次構築され、最も高いユーティリティ・スコアを持つノードを見つけることを目指す。

戦略ツリーにおいて、我々の目標は、最小のコストで最大の利益をもたらす順序付けられたブロックを含むノードを選択することである。これを達成するために、便益とコストのトレードオフを評価する効用計算関数を設計する必要がある。この関数は、後述するように「ノード効用」と定義するものによって定量化される。

結節ユーティリティ。 実用性の指標は、ブロックの組み合わせを選択することで得られる利益と、LLMのプロンプトとしてブロックを使用するコストという2つの要素から構成される。具体的には、利点はLLMによって定量化される。LLMは選択されたブロックとクエリとの類似度を測定する。次に、ノード値V(vi)と検索回数N(vi)の利用（ノード値V(vi)）と探索（検索回数N(vi)）のバランスをとるために、さらにUpper Confidence Bound (UCB)[3]アルゴリズムを使用する。与えられたノードviについて、コストに関しては、セクション2で定義され、割り当てられた総予算Bに対する現在のブロックの組み合わせのコストの比率によって測定されるラベリングコストを考慮する。したがって、ノードの効用は以下のように定義される：

定義4.2（ノード効用）。 戦略ツリーとコスト予算Bが与えられたとき、非ルートノードの効用は次のように定義される：

ここで、V(vi)は学習モデルによって決定されたノードviにおけるブロックの組み合わせの推定利益値であり、N(vi)はノードviへの訪問回数であり、これは訪問回数の少ないノードの探索を促進し、Nは探索と搾取のバランスを確保するためのポリシーツリー内の全ノードへの訪問回数の合計である。さらに、cost(vi)はノードviのラベリングコストを表し、Bはラベリング予算の合計であり、cは探索と搾取のトレードオフを制御し、λはコスト効率を改善するためのコストペナルティ係数である。

最適ノード選択モデリング。 定義されたノード効用に基づいて，セクション2で説明したように，最適なブロックの組み合わせ順序を選択するタスクは，政策ツリーTの最適なノードを選択するように再定式化される．与えられた予算制約Bの下で，viに関連する総コストがBを超えないようにしながら効用U(vi)を最大化するノードvi⊆Tを特定することが目標である．

ここで、V(vi)はノードviにおけるブロックの組み合わせの推定利益であり、cost(vi)はその関連コストを表す。この式により、与えられた予算内で効用を最大化するブロックを選択することが可能になる。

図3：MCTSベースのブロック最適化ワークフロー

アルゴリズム1 MCTSに基づく戦略ツリー探索

4.2 MCTSに基づくポリシーツリー探索

モチベーションだ。 ポリシー・ツリーのすべてのノードを列挙すると最適なノードが見つかるが、計算コストが高くなる。この問題を解決するには、ルート・ノードから出発してツリーを反復的にナビゲートする貪欲な戦略を適用するのが簡単なアプローチである。各反復で、最も利益の大きい子ノードを選択し、予算が尽きるまで続ける。しかし、この方法では最適な結果が得られない可能性が高い。例えば、χ1はχ2よりわずかに利益が高いかもしれないが、χ2 + χ3はχ1 + χ3よりかなり利益が高いかもしれない。この場合、貪欲なアプローチは最適な結果をもたらさない可能性がある。したがって、効率の高い親ノードを再検討する必要がある。同時に、低利益ノードの探索を減らす必要がある。

この目標を達成するために、我々はブロックの組み合わせを効率的に選択し、ランク付けするように設計されたMCTSベースの戦略ツリー探索法を提案する。この手法は、ブロック配列の可能性のある空間を繰り返し探索し、指定された予算制約の中で与えられたクエリを最適化する。

概要 MCTSに基づくポリシーの概要はアルゴリズム1に示されている。まず，入力クエリーを用いてポリシー・ツリーのルート・ノードを初期化する．計算予算が尽きない場合、ノード選択とユーティリティの更新という2つの重要なステップを繰り返し実行する。反復の限界または予算に達したら、処理を停止し、最も高い効用を持つノードを見つけるためにツリーを再帰的に探索する。通常ルートノードにのみ注目する従来のMCTS戦略とは異なり、我々のアプローチはブロックの組み合わせ効用を最大化するために有望な中間レベルノードも考慮する。

主要機能の詳細説明。 この2つの重要な機能について、さらに以下のように説明する：

ノード選択（アルゴリズム2）。 最適なブロックの組み合わせを導く可能性が最も高い、最も高い効用値を持つノードを再帰的に選択する。具体的には

アルゴリズム2 NodeSelection

アルゴリズム3 UtilityUpdate

選択する。 最大効用値を持つノードを特定する。𝑣がまだ拡張されていない場合、可能性のあるすべての子孫ノードを生成し、戦略ツリーに含めます。もし ↪L_1D463↩ が拡張されていれば、最も高い効用を持つ子孫ノードを選択し、さらに探索する。
エクステンション。 最もユーティリティの高いノードを選択した後、潜在的な子ノードをすべて生成してノードを拡張する。各子ノードは、可能なブロックの組み合わせの新しい順序を表す。我々のアプローチは、複数のサブノードを同時に計算・評価する並列拡張を用いる。この並列性は、バリューネットワークが単一のノードと同程度の計算コストで複数の組合せを扱えることを利用し、探索の効率を高める。
計算された効用。 各新規子ノードの効用値を効用式を用いて計算する。リ・ランカー・モデルRは複数のブロックの組み合わせを並列に処理して生成する。

5 エージェントの設定

ユーザーの予算内でブロックの関連付けを処理する効率性に取り組んだ後、残るタスクは、各クエリのドメインに適合するシステムを設計することである。MCTSプロセスには、再ランカーの選択、反復回数、探索係数、コスト係数など、いくつかの重要な構成が含まれる。異なるクエリタイプ間でこれらの設定を最適化することは特に困難である。この問題に対処するために、各クエリに対して最適な再ランカーと構成を予測する構成エージェントのフレームワークを提案する。本節では、まずセクション5.1でエージェントフレームワークを紹介し、セクション5.2でモデル学習プロセスを概説する。

5.1 モデリングの枠組み

モチベーションだ。 各クエリのドメインに適応し、最適なコンフィギュレーションを推奨する必要があるチャレンジ3に対処するためには、各クエリを最適なリランカーに割り当てるMLP分類器を使用するのが簡単な解決策である。しかし、最初の実験では、MLP分類の性能は低いことが示された。さらに分析を進めると、類似したタイプのクエリは、同じ最適な再ランカーと構成を共有する傾向があることがわかる。従って、同じカテゴリのクエリ同士を近づける一方で、異なるカテゴリのクエリ同士を引き離すために、コントラスト学習を用いたシャムネットワークを使用することは、より実現可能なアプローチである。

図4は、入力を特徴グラフに変換する2つの主要なモジュールから構成されるエージェントの概要である。まず、入力埋め込みモジュールは、入力クエリの埋め込みを生成する。その後、符号化ネットワークがこれらの埋め込みを処理して特徴マップを生成し、それを用いてMCTS設定の様々な構成を導出する。

以下のセクションでは、各コンポーネントの詳細を説明し、その設計根拠を説明する。

(1) 埋め込みクエリーを入力する。 明示的事実、暗黙的事実、解釈可能合理性、隠れた合理性[47]などのクエリの多様性を考慮し、様々なクエリの要因を効率的に捉えるために、BGE-M3[6]埋め込みモデルを用いて、各クエリの埋め込みを生成する。これらの埋め込みは、同じようなタイプのクエリを同じリランカーカテゴリにマッピングすることで、学習フレームワークを強化する。1024次元の空間で表現される埋め込みは、基本的な意味的特徴を捉え、コーディングネットワークが効率的にクエリを比較、分類することを可能にする。このステップにより、異なるタイプのクエリの検索関連性を向上させることができる。さらに、同じ埋め込みモデルを使用することで、独自の特徴や関連するメタデータを含む、最適な再ランカー注釈付き埋め込みも生成され、最適な再ランカーにクエリを整合させることができる。

(2) コード化されたネットワークを使った特徴マップの生成：その 再ランカー選択タスクを最適化し、異なるクエリタイプに対して各クエリに最適な再ランカーを推薦するために、分類と構成予測の両方に有用な表現を効率的に学習するコーディングネットワークを使用する。このタスクには3つの完全連結層からなるシャムネットワークを用いる。これはd=1024次元の入力クエリの埋め込みを処理し、分類出力とMCTSの構成予測（すなわち、反復回数とλ）を学習する。符号化ネットワークの各枝は重みを共有し、各枝は線形変換の後にRELU活性化を適用する。順次、最初の隠れ層は次元を512に減らし、2番目は256に減らし、3番目は128に減らす。最後の出力層は、検索プロセスを導くために最も効率的なMCTS構成を予測するために使用される回帰出力と同様に、各クエリに最適な再ランカーを特定する分類予測を提供する。分類出力は各クエリに最適な再ランカーを特定し、回帰出力は最適なMCTSコンフィギュレーション設定を決定する。

5.2 共同トレーニング

本節では、コンフィギュレーション・エージェントを開発するための訓練プロセスについて概説する。図4に示すように、我々はモデルの学習効率を向上させるために、3つの共同学習タスクを実装した。最初の2つのタスクは、それぞれ最適な再ランカーを選択するための分類と、MCTSハイパーパラメータの最適値を予測するための回帰である。さらに、学習プロセスをさらに改善するために、比較学習アプローチを取り入れる。

5.2.1 分類と回帰損失。

予測された再ランクラベルY(pred)とそれに対応する実際の最適再ランクラベルY(true)が与えられると、分類損失L(cla)は以下のように計算される。

ここで、F(cla)は予測されたリランカーラベルと実際のリランカーラベルの間のクロスエントロピー損失を表す。この損失関数は、各クエリに対して最適な再ランカーを正確に分類するのに役立つ。同様に、回帰損失L(reg)は次のように定義される。

ここで、↪Lu_1D439 は予測されたMCTSパラメータ↪Ll45D↩と実際のMCTSパラメータ↪Ll45D↩の平均二乗誤差(MSE)である。この指標は反復回数と↪L_1706↩の観点からMCTSコンフィギュレーションの正確な予測を保証する。

図4：コンフィギュレーション・エージェントの概要

5.2.2 対照学習。

異なるクエリドメインを効率的に区別し、それぞれのクエリに最適な設定を推奨するために、異なるリランカークラスの埋め込みを押し出しながら、同じドメインのクエリを近づける比較学習を用いる。

比較の準備。トレーニングデータセットを準備するためには、各クエリに最適なリランカーと設定を決定しなければならない。本研究では、様々な設定による広範な実験を通して、各クエリに対する最適なリランカーと対応する設定を決定した。その後、これらの最適なリランカーの注釈に基づいてクエリのペアが生成される。正のペアは同じ最適な再ランカーを共有するクエリで構成され、特徴空間への埋め込みを最小化することを容易にする。逆に負のペアは、異なるリランカーを持つクエリで構成され、それらの間の埋め込み距離を最大化することを目的とする。いくつかのリランカーは特定のクエリに対して同様の性能を発揮するため、ROUGE-Lが10%以上異なるケースのみを選択し、トレーニングデータセットとする。

コントラスト損失。図4に示すように、ある正対（𝑥𝑖, 𝑥+）に対して𝑖）と負のペア（𝑥, ↪Ll_1D457-𝑥𝑗）、まず符号化モデルを用いて対応する特徴マップを生成する。これらの特徴マップは、コントラスト損失ᵃconを計算するために使用されます。具体的には、このプロセスは以下のように表すことができます：

そのうちのひとつだ。𝑓(𝑥) は埋め込み関数を表す。コンは2つのタイプのペア：正のペア（類似した再検索元）と負のペア（異なる再検索元）に適用される類似度関数です。この損失関数は、同じ再検索元を持つクエリは埋め込み空間内でより近く、異なる再検索元を持つクエリはより遠くなるように設計されています。

5.2.3 トレーニングの全過程。

最後に、全損失関数L(total)は、次のように比較損失、分類損失、回帰損失の合計である。

特に、コントラスト損失Lcon(θ)は、同じ最適再ランカーを持つクエリの埋め込みを近づけ、異なる再ランカーを持つクエリの埋め込みを遠ざける。分類損失Lcla(θ)は、モデルがクロスエントロピーを用いて再ランカーを正しく識別することを助け、回帰損失Lreg(θ)は最適なMCTS構成を予測する際の誤差を最小化する。

備考全損失Ltotalが計算されると、学習率ηで勾配降下法を用いてネットワークパラメータθが更新される。この最適化プロセスは、複数のサイクルEとバッチにわたって繰り返され、分類器とパラメータ予測の両方が時間とともに改善されることを保証します。

6 実験

この実験的研究の目的は、以下の質問に答えることである。
- RQ1 コスト制約のあるRAGパイプラインにおいて、我々のCORAGは他の手法と比較してどうか？
- RQ2 CORAGのブロックサイズを変えた場合の効率は？
- RQ3 RAGにおける現在のボトルネックは何か？
- RAGのボトルネックは？
- RQ4 異なるデータセットサイズに対するCORAGのスケーラビリティは？
- RQ5 CORAGにおける各デザインの効果は？

6.1 実験セットアップ

環境我々のシステムは、一般的なRAGフレームワークであるLlamaIndexと統合した。実験は、Intel Core i7-13700K CPU（12コア、24スレッド、5.3GHz）、64GBのRAM、1TiB NVMe SSDを搭載したLinuxサーバー上で実行した。Configuration Agentモジュールは、PyTorch 2.0を使用して、24GBのVRAMを搭載したNVIDIA RTX 4090 GPUに実装した。

表1：実験に使用した統計データ。

データセット	1TP5トレイン	#dev	1TP5テスト	#p
MSMARCO	502,939	6,980	6,837	8,841,823
ウィキ	3,332	417	416	244,136

データセット1）WikiPassageQA[7]は4,165の質問と100,000以上のテキストチャンクを含むQ&Aベンチマークであり、段落レベルの検索を評価することを目的としている。(2) MARCO [24]は、Q&Aと情報検索に重点を置いた自然言語処理タスクに特化した包括的なデータセットである。表1に示すように、WikiPassageQAとMARCOはともに高品質な質問と段落注釈を提供しており、検索効果の評価に適している。実験では、LLMに各データセットのグランドトゥルース回答を生成させる。例えば、CORAGのパフォーマンスを評価するためにLlama3を使用する場合、LLMの特性との公平性と整合性を維持するために、同じ実験セットアップでLlama3も使用してグランドトゥルースを生成する。

ベースライン。CORAGの性能を2つの典型的なRAGベースラインと比較する：

- RAPTOR [29]: RAPTORは、テキストのブロックを再帰的に埋め込み、クラスタリングし、要約することで、階層的な文書要約ツリーを構築し、複数レベルの抽象化を実現する。このアプローチはセクション1で説明したクラスタリングベースのアプローチと一致している。おおよその予算制約の中でツリー構築を完了する。
- NaiveRAG：関連ブロックを検索するための基本的な手法である。まず、ベクトル類似度検索に基づいてベクトルデータベースから候補ブロックを検索し、リランカーモデルを用いてランク付けを行う。この方法はセクション1で述べたAKNN法である。コスト制約を満たすために、貪欲な予算配分戦略を用いて、予算が完全に尽きるまでブロックを検索する。

さらに、CORAGの性能への影響を評価するために、ベースラインとして我々のアプローチからコンフィギュレーション・エージェントを削除し、このバージョンをCORAG w/o Agentと呼ぶ。最後に、CORAG Upperと呼ばれるアプローチを実装する。これは、可能なブロックの組み合わせをすべて探索し、最適な順序を選択することで上限を確立する。潜在的な組み合わせの数が多いため、CORAG Upperの場合、探索を6ブロック以下の組み合わせに限定する。

備考GraphRAG[22]のような他のアプローチは、ブロックを要約しインデックスを構築するためにLLMへの頻繁な呼び出しに大きく依存しており、我々の厳しいコスト制約を超える膨大なコスト（例えば、数十億トークン）が発生する。したがって、これらのアプローチは我々の問題を解決するためには実行不可能である。公平な比較のために、これらのタイプのRAGアプローチは実験から除外した。

ハイパーパラメータの設定：CORAGのハイパーパラメータは設定エージェントによって自動的に決定されるが、NaiveRAGはハイパーパラメータを必要としない。他のベースライン手法については、公平な比較のために同じハイパーパラメータを使用することで一貫性を確保する。具体的には、探索係数を2.4、反復回数を10、コスト係数λを0.1に設定する。予備実験では、この設定によりベースラインの性能が最適化されることが示された。また、これらの設定を検証するために、さらに切除研究を行う予定である。

学習パラメータの設定。我々のアプローチでは、コンフィギュレーション・エージェントはコントラスト学習を用いて学習される。このプロセスで使用されるハイパーパラメータには、コントラスト損失（margin=1.0）、学習率（lr=0.001）、バッチサイズ（32）、サイクル数（num_epochs=60）、埋め込みモデル（すなわち、BAAI/bge-m3 [6]）が含まれる。

評価指標Rouge-1、Rouge-2、Rouge-Lを評価指標として使用し、Ground-Truthの回答と生成された回答のRougeスコアを比較することで有効性を評価します。効率性を評価するために、異なる方法でクエリに回答するのに必要な待ち時間を測定します。

図5：効率の比較

6.2 パフォーマンスの比較

6.2.1 RQ1：ルージュの比較。

図2に示すように、主にWikiPassageQAとMARCOを使用して、CORAGの性能をいくつかのベースラインと比較した。当然のことながら、CORAGは、すべての可能な組み合わせ順序を網羅的に列挙する極端なケースを表す上限値を超えないが、これは明らかに非効率的で非現実的である。結論として、CORAGはベースラインを上回り、検索空間を効果的に刈り込みながら検索の関連性を高める。

6.2.2 RQ2：効率性評価。

図5に示すように、CORAGは木探索アルゴリズムに基づいているため、エージェントは与えられたクエリに対して最適な再ランカーとパラメータを予測するのに役立つ。したがって、異なるブロックサイズとデータセットが検索最適化タスクの効率に与える影響を評価することは極めて重要である。異なるデータセットとブロックサイズを用いて効率をテストした結果、伝統的な検索手法を用いたNaiveRAGは、検索時間は短いがRougeのスコアは低いことが確認された。同様に、RAPTORは要約のために外部のLLMを利用するが、効率が悪い。対照的に、我々のCORAGアプローチは効率と検索関連性の効果的なトレードオフを達成している。

6.2.3 RQ3：パフォーマンス分解。

現在のRAGシステムのボトルネックを強調するために、ベースラインNaiveRAGの性能分解を示す。ブロックの組み合わせの最適な順序を検索するという課題に対処するために、NaiveRAGを用いてそれを実装するには、以下のステップが必要である：a) クエリー埋め込みを取得する、b) ブロックの組み合わせ候補を検索する、c) ブロックの組み合わせ候補を再順位付けする、d) キューの絞り込み。図6に各ステップの平均待ち時間を示す。

表 2: WikiPassage QA と MARCO データセットにおける Rouge の比較

6.2.4 RQ4：スケーラビリティの評価

WikiPassageQAやMARCOのような大量のパラグラフを含む大規模なデータセットを扱う場合、CORAGは優れたスケーラビリティを発揮します。各段落を256のラベル付きチャンクに分割することで、チャンクの数を100k以上に簡単に拡張することができる。データ量が大幅に増加したにもかかわらず、我々の検索時間は従来のアプローチと比較して10%しか増加せず、大規模な検索タスクを管理する上で我々のシステムが効率的であることを示している。特筆すべきは、我々のシステムはCORAG Upper法を凌駕し、検索に要する時間はわずか10分の1でありながら、競争力のあるROUGEスコアを提供していることである。この性能と計算オーバヘッドの効果的なバランスは、検索空間を効率的に刈り込み、巨大なデータセットにおいても高速な検索を保証するシステムの能力を浮き彫りにしている。このように、我々のアプローチは、大規模なデータ処理と高い検索精度を必要とするシナリオに適している。

図6：パフォーマンス分解

表3：異なる予算下での性能比較

6.3 RQ5：アブレーション研究

6.3.1 予算の異なるアブレーション研究

表3に示すように、CORAGをコスト制約のあるシステムとして評価し、異なる予算が全体的な性能に与える影響を調べた。MARCO データセットを使用し、予算制限を 1024、2048、8192 トークンに設定し、ROUGE を使用して結果を評価した。注目すべきは、CORAGの平均タグ付けコストが各予算制限を下回っていることで、チャレンジ2で強調したように、ブロックの効用は単調ではないことが示唆される。予算が増加するにつれて、CORAGは探索空間の拡大から恩恵を受け、単にブロック数を増やすのではなく、より多くの関連情報を含めることができる。

6.3.2 探索係数の異なるアブレーション研究

図7に示すように、探索係数の違いによるシステム性能への影響を評価するため、特にCの値を0、1、2、3としてアブレーション試験を実施した。その結果、探索係数を約2に設定することで、探索過程における探索と探索の最適なバランスが達成され、最高の性能が得られることがわかった。このバランスにより、システムはポテンシャルの高いブロックに焦点を当てながら、関連する情報を効率的に発見することができ、最終的にRAGレスポンスの向上につながる。対照的に、探索係数が低いと探索不足により最適な結果が得られず、探索係数が高いと焦点の過度の分散により最適な結果が得られなかった。これらの結果は、CORAG探索プロセスのパフォーマンスにおける探索係数の重要な役割を強調し、慎重なパラメータチューニングの重要性を浮き彫りにした。

図7：Cの値の違いによるROUGEの比較

6.3.3 費用係数の異なるアブレーション研究

その結果、ユーティリティにコスト係数を導入すると、ROUGEスコアがわずかに低下することがわかった。この減少は、コスト制約がない場合、CORAGはコスト効率を犠牲にしてでも、より長いアウトプットを生産する傾向があるという事実によるものである。しかし、ROUGEスコアのわずかな減少にもかかわらず、減少は5%以内にとどまっており、これは許容範囲内である。これらの結果は、出力の豊かさとコスト制約のバランスをとるためにコスト係数を効率的に調整することの重要性を強調し、CORAGの性能を最適化するための効率的な設定チューニングを可能にする我々の設定エージェントの役割をさらに強調しています。

図8：ラムダの値を変えた場合のROUGEの比較

6.3.4 異なるリアレンジャーを用いたアブレーション研究

検索性能に対する様々なリアランカーの影響を評価するため、広く認知されている6つのリアランカーモデル、jina-reranker-v1-turbo-en、jina-reranker-v2-base-multilingual、bge-reranker-v2-m3、bge-reranker-large、bge-reranker-base、gte-multilingual-reranker-baseを用いてアブレーション研究を行った。これらのリアランカは、固定コスト係数0.1、探索係数2.4、予算制約1024で設定されたllama3-8Bモデルを使用して、MARCOデータセット上で評価された。

表4：異なるリフォーマーによる性能比較

表4の結果は、異なる再整理器間で性能に差があることを示しており、特定の運用制約の下でRAGシステムの性能を最適化するために再整理器を注意深く選択することの重要性を強調している。再整理器の中でも、gte-multilingual-reranker-baseとbge-reranker-largeはQAタスクにおいて一貫して高い性能を示し、これらの再整理モデルが様々なQAクエリに関連する情報を捕捉する上で非常に効率的であることを示唆している。アブレーション研究においてブロックサイズが大きくなるにつれて、異なるクエリに対して推奨される再ランカーにおいて、個々の再ランカーがエージェントの性能を下回ることが観測された。このことは、検索結果を改善するために構成を動的に調整することで、構成エージェントが効果的に再配置器の多様性を利用していることを示唆している。より良い再配置の選択とパラメータ構成を推奨する構成エージェントの能力は、特に予算が限られているような制約の下で、RAGシステムの性能を最大化する役割を強調する。

6.4 ケーススタディ

図9はCORAGと従来のNaiveRAGアプローチの検索品質を比較した3つの例を示しており、我々のアプローチがベースラインアプローチを上回る理由を強調している。NaiveRAGは単純なトップk検索と並べ替えを行うため、クエリとの関連性よりもキーワードのマッチングに基づいてチャンクを検索するため、クエリの意図に関連する重要な情報を見逃すことが多い。例えば、"葉っぱの花は低木か？"というクエリに対して、NaiveRAGはコンテンツを検索する。というクエリに対して、NaiveRAGはマッチするキーワードを含むコンテンツを検索するが、葉の花の実際の分類を提供できない。対照的に、CORAGのブロック組み合わせ戦略は、葉の花のカテゴリを含むコンテキストを検索し、LLMがより正確な応答を返すことを可能にする。別のケースでは、NaiveRAGは "oxyfluorfen "を含む用語と法律条文を検索したが、クエリの意図を理解していなかった。一方CORAGは、oxyfluorfenと綿花のユースケースを結びつけるコンテンツを提供した。ベクトル類似性検索ではブロック間の論理的関係を捉えることができなかった。最後に、"バクテリアはどこから来るのか？"というクエリについて。NaiveRAGは "バクテリア "というキーワードを含むチャンクを検索するが、その起源には触れていないのに対し、CORAGはバクテリアの起源や繁殖条件を含む、より完全な回答を提供する。これらのケースは、CORAGが論理的につながった情報の検索に優れており、単純なキーワードマッチング以上のものを必要とするクエリにはNaiveRAGよりも適していることを示している。

図9：CORAGのケーススタディ

7 RAGと将来の設計オプションに関する洞察

7.1 現行のRAGの欠点

現在のRAGシステムの分析を行い、検索（S1）、強化（S2）、生成（S3）の各段階で直面するパフォーマンス上の課題を明らかにする。

S1: 検索オーバーヘッド 現在のRAGシステムは一般的に、要約と索引付けの構造にLLMを利用し、外部LLMに関連する計算コストを無視しているため、計算オーバーヘッドが増加している。モデルベースの並べ替えは、検索時の関連性を向上させる一方で、大きな待ち時間をもたらし、待ち時間を考慮した文脈効率の妨げとなる可能性がある。効率と性能のバランスをとるためには、費用対効果の高いインデックスの構築と並べ替えの最適化が不可欠である。

S2：オーバーヘッドの強化 最適化されたブロックの組み合わせ順序のような検索後のテクニックは、文脈の関連性を高めるが、追加の計算を必要とする。検索空間を最小化し、組み合わせ順序を最適化するプルーニング戦略は、計算コストのバランスをとり、文脈関連性を高めるために不可欠である。順序と一貫性に重点を置いた効率的なブロック結合の最適化は、コスト削減と検索性能の向上に不可欠である。

S3：ジェネレーション・オーバーヘッド 最適なブロックの組み合わせのための効率的なヒントエンジニアリングには、膨大な計算リソースが必要である。入力の関連性と簡潔性を維持しながらオーバーヘッドを削減するためには、クエリに特化したヒントの洗練と圧縮が不可欠である。異なるクエリタイプやドメイン固有の要件を扱うための適応的な戦略は、出力品質を損なうことなくプロンプトの効率性を確保する。

7.2 設計オプション

上記の課題に対処するため、RAGシステムの性能を最適化するために、以下のような設計上の選択を行う：

P1: 検索と並べ替えプロセスの共同設計 CORAGでは、ツリー検索における並列拡張がクエリ処理を高速化し、検索と並列並べ替えを可能にすることで待ち時間を大幅に短縮する。将来的な最適化により、ステージ固有の遅延をなくし、ランキング効率をさらに向上させることで、ボトルネックに対処することができる。この共同設計アプローチは、ランキング処理と関連するスコアリングを改善するために、ブロックの組み合わせ順序を効率的に管理する。

P2: ツリー構造と探索反復の最適化 その結果、戦略ツリーの高さを短くすることで、計算オーバヘッドを削減し、検索効率が向上することが示された。ツリーベースの探索においてツリーの高さを最小化することで、文脈に関連するブロックの探索速度が向上し、待ち時間と計算コストが大幅に削減される。この最適化アプローチは、大規模データセットにおけるRAGシステムの性能を向上させる。

P3: ダイナミック・チップ・プロジェクト クエリのタイプに基づいてリアレンジャーを選択し、適応的なヒントテンプレートを使用することで、LLMの検索関連性を向上させることができる。クエリの意図とドメイン固有のコンテキストに沿った動的なキュー構造は、リソースの制約の中で出力品質を維持することができる。この適応的キューエンジニアリングアプローチは、RAGシステムにおけるクエリの動的な性質に対応し、効率と検索品質の効果的なバランスを達成する。

8 結論

ブロックの有用性の非単調性、ブロック間の相関性、異なるクエリドメインの多様性を考慮し、学習ベースの検索最適化システムCORAGを提案する。最初に、ブロックの組み合わせの順序をポリシーのツリーとしてモデル化し、MCTSを用いてこのツリーを探索し、ブロックの組み合わせの最適な順序を見つけることを目指す。与えられたクエリに対して最適な構成と再配置を正確に予測する構成エージェントを導入する。さらに、各反復で複数のノードを展開する並列クエリ展開戦略を考案する。実験の結果、我々のアプローチはコスト制約の範囲内で最先端のアプローチを大幅に上回り、効率性の面でも優れていることが示された。