技術サマリー：エージェント型 RAG における発見可能な継続的修正のための反復的ナゲット最適化

1. 問題定義

複雑な B2B（企業間取引）環境において、エージェント型検索拡張生成（RAG）システムは頻繁に自由形式のユーザーフィードバックを受信します。多くのフィードバックシグナルは曖昧（例：「役に立たない」）または主観的（例：トーン）ですが、重要なサブセットには実行可能な事実修正が含まれます。これらの修正は、将来のユーザーが利用すべき特定の製品動作、役割制限、名称の明確化、またはポリシーの詳細に関するものです。

核心的な課題は、これらの修正を事実ナゲット（短く、独立した知識ベースのエントリ）に変換することです。その要件は以下の通りです：

1. 保守的であること：新たな誤りを導入することなく、修正された事実をエンコードすること。
2. 自立していること：元の会話に依存せず、再利用に十分な文脈を含めること。
3. 発見可能であること：元のフィードバックと語彙的重なりがほとんどない将来のクエリと一致すること。
4. 精密であること：無関係なトラフィックに対する検索につながる過度な広範さを避けること。

フィードバックを単に要約するか、元の相互作用の文言を継承する標準的なアプローチは、将来のユーザーが異なる役割から問いかけ、異なる問題に言及するか、あるいは異なる語彙を使用するため、しばしば失敗します。さらに、既存の顧客ドキュメントを直接編集することは、検証の難しさと多段階手順を混乱させるリスクにより、しばしば実行不可能です。

2. 手法：反復的ナゲット最適化（INO）

本論文は、反復的ナゲット最適化（INO）を提案します。これは、ナゲットの構築を測定可能な問題として扱い、生産環境のエージェント型 RAG システム自体をテストハarnessとして利用して解決する、インデックス作成時の最適化手法です。

INO ループ

1. 抽出：LLM ベースのフィルタが、ユーザーフィードバックストリームから実行可能な事実修正を識別します。
2. 初期化：候補ナゲットを作成します（通常、修正内容と元のクエリの言い換えを含みます）。
3. プローブ：候補ナゲットを顧客コーパスの凍結コピーに挿入します。その後、元のクエリ（$q_0$）と、評価用に特別に生成された 3〜5 のホールドアウト言い換えからなる「プローブセット」を実行します。
4. 反映と修正：ナゲットがプローブクエリのいずれに対しても検索されたり引用されたりしなかった場合、LLM リフレクタが失敗トレースを分析します。以下を検査します：
   • 失敗したクエリ。
   • 検索された競合ドキュメント。
   • 生成された回答。
   • 現在のナゲット表現。
     リフレクタは、新たな主張を追加することなく事実修正を厳密に保持しつつ、ナゲットのタイトル、本文の文言、検索アンカーを修正して発見可能性を向上させます。
5. 反復：ナゲットが正常に検索され引用されるまで、このプロセスを最大 $T=3$ 回繰り返します。

主要な相違点

多くのタスクにわたって変更を均すためにシステム指示を調整するプロンプト最適化手法とは異なり、INO は1 つの特定の事実修正に関する将来のクエリにわたって作業を均し、検索可能なアーティファクト自体を最適化します。これにより、生産エージェントの設定は固定されたままとなり、最適化は局所的、監査可能、かつ可逆的になります。

3. 実験設定

著者は、複数の企業にまたがる 2 つの異なる B2B エージェントからの実生産データを用いて INO を評価しました：

1. チャットエージェント：顧客固有の知識ベース（KB）を介して自由形式のサポート質問に回答します。
2. サポートチケットエージェント：サポートチケットの転写文を読み、回答を提案します。

評価指標：

• 検索：ナゲットが再ランクファを通過し、ジェネレータに到達するかどうか。
• 引用：ナゲットが最終回答のソースで引用されるかどうか。
• 回答準拠：人間の注釈者に対して較正された LLM ジャッジが、生成された回答が元の修正に対応し、ナゲットの事実を遵守し、後退を避け、かつ根拠性を維持しているかを確認します。

ベースライン：
本研究は、INO を他の 4 つの戦略と比較しました：

• 標準：ナゲットをそのままインデックス化。
• トリガークエリアンカー：元のクエリの言い換えを付加。
• 合成アンカー：LLM 生成の将来ユーザークエリを付加。
• 組み合わせ：トリガーと合成の両方のアンカーを付加。

4. 主要な結果

INO は、両方のエージェントおよび評価タイプにおいて、すべてのベースラインを一貫して上回りました。

• 発見可能性：チャットエージェントのホールドアウトクエリにおいて、INO は標準ナゲットベースライン（52.3%）に対して検索率を 25〜29 パーセントポイント改善しました（77.3%）。
• 使用率：引用率も大幅に向上し、INO は**68.1%に達し、ベースラインの41.3%**と比較されました。
• 一般化：性能の差は「実在する」歴史的クエリ（合成 LLM 言い換えよりも困難）において広がり、INO は単に元のクエリを記憶するのではなく、未見の表現にもよく一般化することを示しています。
• サポートチケット：サポートチケットエージェント（入力がノイズの多い転写文である場合）では、改善がさらに顕著でした。INO は検索を43.1 ポイント（35.1% 対 78.2%）、引用をベースラインに対して40.7 ポイント改善しました。
• 回答品質：回答レベルの評価において、INO は要求された修正に対応した回答の割合を**52.2% から 73.4%**に増加させました。また、重大な後退エラーと幻覚的な根拠ラベルを削減しました。
• 精度：1,400 のランダムクエリに対するネガティブコントロールテストでは、低い偽陽性率（検索率 1.4%）を示し、手動検査によりこれらはノイズではなく意味的に等価な言い換えであることが確認されました。

5. 意義と主張

本論文は、INO が生産環境の RAG システムにおける継続的修正のための実用的でスケーラブルな解決策を提供すると主張しています。その意義は以下の点にあります：

• 運用上の実現可能性：最適化はオフラインで行われ、ナゲットあたり約0.31 ドルのコストと 2 分未満の時間を要し、インデックス作成後のエンドユーザーにはゼロの追加遅延をもたらします。
• 生産環境への展開：このシステムは現在稼働しており、顧客展開において週に数百の検索ナゲットを生成しています。
• 局所最適化：エージェントのグローバル設定ではなくアーティファクトを最適化することで、修正が原子性を持ち、無関係なタスクのパフォーマンスを誤って低下させることがないことを保証します。

著者は限界について謙虚に述べており、結果は現在英語のみに限定され、使用されている特定のハイブリッドエージェント型 RAG アーキテクチャに依存していることを指摘しています。彼らは、異なる検索アーキテクチャ（純粋な密または純粋な疎）が提案された最適化に対して異なる反応する可能性があることを認めています。