検索拡張生成（RAG）アーキテクチャは、元の検索-生成パターンからかなり拡張されています。現代のシステムでは、密集検索と語彙検索、クエリ書き換え、ランク融合、ニューラル reranking、質問分解、修正検索、反省、エージェントベースのオーケストレーションがますます組み込まれています。これらの技術は、複雑な情報探索タスクにおけるパフォーマンスを実質的に向上させることができます。

しかし、これらは基礎となる検索サブシステムが独立して評価される前に導入されることがよくあります。最近の研究では、比較的従来の検索方法が依然として非常に競争力があることが示されています：語彙検索は専門分野でうまく機能し、reranking を含むハイブリッド検索は堅実なベースラインを提供し、さらにエージェントベースのシステムでも、より強力な検索の上に構築されている場合にパフォーマンスが向上します。

検索の品質とエージェントベースの推論は、問題の異なる側面に対処します。証拠が明確に定義された検索ステップを通じて回復できる場合、主な懸念は検索の品質です。検索が反復的、マルチホップ、または中間証拠に依存する場合、エージェントベースの検索ははるかに有用になります。アーキテクチャの複雑さは、実証された障害モードに対応するべきです。

証拠が検索可能な単位に存在しているがコンテキストウィンドウに入らない場合、問題の主な原因が検索および検索サブシステムにある可能性が高くなります。システム設計の観点から、検索と生成は概念的に別々の操作であり、その障害モードは独立して評価されるべきです。

よくある質問：なぜRAGの複雑さはデフォルトとして採用されるのではなく、獲得されるべきなのか？

なぜなら、追加の推論レイヤーは、検索の根本的な失敗を修正することはできないからです。関連する証拠が候補セットの外にランク付けされている場合、クエリの書き換え、reranking、またはエージェストレーションのいかなる量でもそれを回復することはできません。複雑さは、検索が独立して評価され、特定の障害モードが特定された後にのみ導入すべきです。