エグゼクティブサマリー
従来の検索拡張生成（RAG: Retrieval-Augmented Generation）パラダイムは、大規模言語モデル（LLM）が外部知識を活用するための基盤として広く採用されてきましたが、企業ユースケースが単純な事実確認から複雑な長文ドキュメントのQ&Aへと移行するにつれ、その構造的な限界が露呈しています。特に、RAG使用者が指摘する「回答が途中で切れてしまう」「コンテキストを理解していない」という現象は、単なる設定ミスではなく、静的なチャンキングと単一パス（Single-Pass）のベクトル類似度検索に依存する標準的RAG（Naive RAG）の根本的な欠陥に起因しています。
本報告書は、これらの課題を解決するために、受動的な検索システムから Agentic RAG（エージェント型RAG） および Deep Research（深層調査） アーキテクチャへの移行を提案し、その技術的詳細、実装戦略、およびベンチマーク結果を包括的に分析したものです。これらの次世代システムは、人間の研究者のワークフローを模倣し、複雑なクエリをサブタスクに分解し、情報の欠落を自律的に検知して再検索を行い、再帰的に情報を統合することで、完全性と文脈理解を担保します。
分析の結果、Self-RAGによる自己反省メカニズム、Corrective RAG（CRAG）による検索品質の評価、そしてLlamaIndexのTree Summarizeに代表される階層的要約手法が、長文生成におけるコンテキスト保持と回答の完結性を劇的に向上させることが確認されました。本稿では、これらの技術がどのようにして「ベクトル検索の限界」を突破し、エンタープライズグレードの信頼性を実現するかを詳述します。
1. 序論：標準的RAGにおける長文コンテキスト処理の構造的限界
現在、多くのRAGシステムが直面している「回答の切断」や「コンテキストの喪失」は、LLMの能力不足ではなく、検索と生成をつなぐパイプラインの構造的なボトルネックに由来しています。標準的なRAGは「検索して（Retrieve）、生成する（Generate）」という直線的なプロセスであり、検索結果が不完全であったり、生成に必要な情報量がコンテキストウィンドウを超過したりした場合でも、システムにはそれを修正する機会が与えられません。
1.1 「凍結されたチャンク」と意味の断片化
標準的なRAGの実装において最も一般的な手法は、ドキュメントを固定長のトークン数（例：512トークンや1024トークン）で分割（チャンキング）し、それぞれのベクトル埋め込み（Embedding）を作成することです。しかし、このアプローチは長文のQ&Aドキュメントにおいて致命的な「意味の断片化」を引き起こします。
構造化されたドキュメントにおいて、質問（Question）と回答（Answer）が物理的に離れている場合、あるいは回答が非常に長く複数のチャンクにまたがる場合、単純なベクトル検索は失敗します。質問文に類似したチャンク（質問部分）だけが検索され、肝心の回答部分が含まれる後続のチャンクが「意味的類似性が低い」と判断されて除外されるためです。その結果、LLMには質問のみが渡され、回答の核心部分が欠落した状態で生成を強いられることになります。
さらに、埋め込みモデルは本質的に短いテキストを好むバイアスを持つ傾向があります。埋め込み空間において、短いテキストは意味が凝縮されているため、クエリとの類似度が高く算出されがちです。これにより、文脈的に重要だが長いチャンクよりも、関連性が低い短い断片が優先的に検索され、結果として回答の品質が低下します。
1.2 ベクトル類似度検索の盲点と「Lost in the Middle」
ベクトル検索は「意味的な近さ」を測る優れた手法ですが、「論理的な必要性」や「情報の完結性」を判断することはできません。
| 特性 | ベクトル類似度検索の限界 | 長文Q&Aへの影響 |
|---|---|---|
| 検索基準 | クエリとの意味的類似性（Cosine Similarity） | 回答の「続き」や「前提条件」が含まれるチャンクは、クエリと直接似ていないため検索漏れする。 |
| コンテキスト範囲 | チャンク単位での局所的なマッチング | ドキュメント全体に散らばる「原因」と「結果」のような因果関係を統合できない。 |
| 透明性 | ブラックボックス（なぜ類似しているか不明） | 誤った情報が検索された際、なぜそのチャンクが選ばれたのか説明がつかず、デバッグが困難。 |
また、LLMの「Lost in the Middle（中間の消失）」現象も無視できません。検索された複数のドキュメント（Top-K）をコンテキストウィンドウに詰め込んだ際、モデルはプロンプトの最初と最後に位置する情報を重視し、中間に埋もれた情報を無視する傾向があります。長文回答を生成するために必要な情報がコンテキストの中間に配置された場合、モデルはそれを「読んでいない」かのように振る舞い、結果としてコンテキストを理解していない回答を出力します。
1.3 生成の打ち切りとコンテキストウィンドウの飽和
RAG使用者が報告している「回答が途中で切れる」現象は、物理的なトークン制限と論理的な生成能力の不一致から生じます。検索された関連ドキュメントが多すぎる、あるいはチャンクサイズが大きすぎる場合、プロンプトがLLMの入力上限（コンテキストウィンドウ）を圧迫し、回答生成に割り当てられるトークン数が不足します。標準的なRAGパイプラインは、入力トークン数と出力トークン数のバランスを動的に調整する機能を持たないため、物理的な上限に達した時点で生成が強制終了されます。
2. 理論的枠組み：Agentic RAG（エージェント型RAG）へのパラダイムシフト
上述の課題を解決するためには、静的な検索パイプラインから、自律的な意思決定を行うAgentic RAGへの移行が不可欠です。Agentic RAGは、単一のプロンプトで処理を完了させるのではなく、計画（Planning）、実行（Execution）、検証（Verification）のループを通じて、反復的にゴールを目指すシステムです。
2.1 Agentic Loop：計画・実行・検証のサイクル
従来のRAGが有向非巡回グラフ（DAG）や直線的なチェーンであるのに対し、Agentic RAGは循環グラフ（Cyclic Graph）としてモデル化されます。この循環こそが、長文Q&Aにおける「不完全さ」を修正する鍵となります。
- 計画と分解（Decomposition）：
エージェントは複雑なクエリを受け取ると、それを解決可能なサブタスクに分解します。例えば「2023年の財務報告書におけるリスク要因と対策を詳細に説明せよ」というクエリに対し、「リスク要因の特定」「各リスクに対応する対策の検索」「情報の統合と要約」というステップを計画します。 - 動的ツール選択（Tool Use）：
計画に基づき、エージェントは最適なツールを選択します。社内データベースのベクトル検索、キーワード検索、あるいはWeb検索などを使い分けます。重要なのは、一度の検索で終わらせず、必要な情報が揃うまでツールを繰り返し使用できる点です。 - 自己反省と修正（Reflection & Refinement）：
これが標準RAGとの最大の違いです。エージェントは検索結果や生成された回答を評価します。「回答が途中で切れていないか？」「情報は十分か？」を自問し、不十分であれば「次のチャンクを取得する」「検索クエリを書き換える」といった修正アクションを自律的に実行します。
2.2 Deep Research（深層調査）アプローチ
「Deep Research」はAgentic RAGの一形態であり、特に深度のある情報収集と統合に特化しています。OpenAIのDeep ResearchやGeminiのDeep Research Agentに代表されるこのアプローチは、単なるQ&Aチャットボットではなく、人間のリサーチャーのように振る舞います。
- 反復的深化（Iterative Depth）：
Deep Researchエージェントは、最初の検索結果から新たな疑問点を見つけ、派生クエリ（Follow-up Queries）を生成して深掘りします。これにより、表面的な類似性だけでは見つけられない詳細な文脈や、ドキュメントの奥深くに記述された回答を発見します。 - スクラッチパッド（Scratchpad）による記憶の蓄積：
長文回答を作成する際、エージェントは検索結果を即座に出力するのではなく、「スクラッチパッド」と呼ばれる一時記憶領域に情報を蓄積します。複数のソースから情報を集め、矛盾を解消し、構造化してから最終的な回答を生成するため、コンテキストの理解度が飛躍的に向上します。
3. 長文コンテキスト問題を解決する高度なアーキテクチャ
RAG使用者の課題である「回答の切断」と「コンテキスト理解不足」を具体的に解決するために、現在注目されている3つの主要なアーキテクチャパターンを詳説します。これらは単なる概念ではなく、実装可能な技術フレームワークです。
3.1 Self-RAG (Self-Reflective RAG)：自己反省による品質保証
Self-RAGは、LLM自身に検索と生成のプロセスを批評（Critique）させるフレームワークです。モデルは回答を生成するだけでなく、その過程で特殊な「反省トークン（Reflection Tokens）」を出力し、自らの挙動を制御します。
動作メカニズムと長文Q&Aへの適用
Self-RAGは以下のトークンを用いて制御を行います：
- Retrieve（検索判断）： 「このクエリに答えるために外部情報が必要か？」を判断します。知識が不足している場合のみ検索を行うため、不要な検索によるノイズを減らします。
- IsREL（関連性判定）： 検索されたドキュメントがクエリに関連しているかを判定します。関連性が低い（例：質問と無関係な回答部分が検索された）場合、その情報を破棄し、再検索を促すことができます。
- IsSUP（サポート判定）： 生成された回答が、検索されたドキュメントによって論理的に支持されているかを確認します。これにより、ドキュメントに書かれていない内容をでっち上げる「幻覚」を防止します。
- IsUSE（有用性判定）： 回答がRAG使用者のクエリに対して有用かを評価します。
解決策としての有効性：
回答が途中で切れてしまったり、不完全なコンテキストに基づいている場合、Self-RAGのIsUSEやIsSUPのスコアが低下します。システムはこの低スコアをトリガーとして、「情報の続きを取得する」あるいは「別のドキュメントを探す」という修正ループに入ることができます。これにより、不完全な回答がRAG使用者に提示されるのを防ぎます。
3.2 Corrective RAG (CRAG)：外部評価器による修正
CRAGは、検索結果の品質を評価する軽量な「検索評価器（Retrieval Evaluator）」をパイプラインに導入することで、RAGの堅牢性を高めます。
評価と知識の洗練（Refinement）
CRAGの評価器は、検索されたドキュメントに対して信頼度スコアを算出します。
- Correct（正確）： 検索結果が適切であれば、生成プロセスに進みます。
- Ambiguous（曖昧）： 検索結果が不完全（例：回答の一部しか含まれていない）な場合、「知識洗練（Knowledge Refinement）」ステップを実行します。これには、検索されたチャンクの周囲のテキストを取得したり、クエリを具体化して再検索したりする処理が含まれます。
- Incorrect（不正確）： 検索結果が全く的外れな場合、Web検索などの代替手段にフォールバックします。
解決策としての有効性：
RAG使用者が直面している「回答が途中で切れる」ケースは、CRAGにおいては「Ambiguous」な状態として検知されます。CRAGはこのシグナルに基づき、切断された箇所の続きを能動的に取りに行くアクションを自動化できるため、人間が手動で聞き直す必要がなくなります。
3.3 階層的要約とTree Summarize：生成の限界突破
検索の問題だけでなく、生成フェーズにおけるトークン制限（回答切れ）を解決するためには、再帰的な要約アルゴリズムが不可欠です。LlamaIndexなどが提供するTree Summarizeは、この問題に対する最も直接的な解法の一つです。
Tree Summarizeのアルゴリズム
長文の回答を生成する際、一度のLLM呼び出しですべてを処理しようとすると、コンテキストウィンドウが溢れるか、出力が途中で打ち切られます。Tree Summarizeは以下の手順でこれを回避します。
- 分割と並列処理： 検索された多数のチャンク（関連テキスト群）を、LLMのコンテキストウィンドウに収まるサイズに分割します。
- リーフノードの要約： 分割された各グループ（リーフノード）に対して、並列で要約・回答生成を行います。この段階では部分的な回答が生成されます。
- 再帰的な統合（Reduce）： 生成された部分的な回答群を新たな入力として、再度要約を行います（親ノード）。
- ルート合成： このプロセスをツリー状に繰り返し、最終的に一つの包括的な回答（ルートノード）に統合します。
解決策としての有効性：
この手法はMap-Reduceパターンの一種ですが、Q&Aのコンテキスト（質問内容）をツリーの各階層で保持し続ける点が特徴です。Refine（順次処理）方式と異なり、最初のチャンクの内容を忘れることがなく、またCompact（詰め込み）方式のように途中で切れることもありません。ドキュメントの末尾にある情報も確実に最終回答に反映されるため、「コンテキスト全体を理解した回答」が可能になります。
4. 実装戦略：Agentic Workflowの構築
理論的なアーキテクチャを実際のシステムとして実装するためには、従来の直線的なチェーン（LangChainのRetrievalQAなど）から、グラフベースのオーケストレーションフレームワーク（LangGraphやLlamaIndex Workflows）への移行が必要です。
4.1 オーケストレーションフレームワークの選定
- LangGraph:
アプリケーションを状態機械（State Machine）としてモデル化します。StateGraphと呼ばれるグラフ構造を用い、ノード（処理）とエッジ（遷移）を定義します。循環ループや条件分岐（Conditional Edges）を記述するのに適しており、Self-RAGやCRAGのような複雑なロジックの実装に最適です。 - LlamaIndex Workflows:
データ中心のイベント駆動型アーキテクチャを提供します。特にTreeSummarizeやHierarchical Indexing（階層的インデックス）などの高度なデータ処理コンポーネントが組み込まれており、長文ドキュメントの処理において強力なアドバンテージを持ちます。
4.2 推奨される実装パターン：Active Retrieval Loop
RAG使用者の課題を解決するための具体的な実装パターン（LangGraphによる概念設計）を以下に示します。
状態定義（State）：
class AgentState(TypedDict):
question: str \# ユーザーの質問
documents: List \# 検索されたドキュメント
generation: str \# 生成された回答
grade: str \# ドキュメントまたは回答の評価結果
retry\_count: int \# 再試行回数
ワークフロー（Graph Topology）：
- Retrieve Node（検索）：
RAG使用者の質問に基づき、ベクトルデータベースから初期チャンクを取得します。
重要な改善点： ここで単なるチャンクではなく、親ドキュメント検索（Parent Document Retrieval）またはウィンドウ拡張を使用します。ヒットしたチャンクの前後を含む大きなテキストブロックを取得し、文脈の断絶を防ぎます。 - Grade Node（評価 - CRAGの実装）：
検索されたテキストが質問に対する「完全な回答」を含んでいるか、LLM（軽量モデル）に判定させます。- 判定： 「不完全（回答が切れている）」 → Expand Nodeへ遷移。
- 判定： 「関連なし」 → Rewrite Nodeへ遷移。
- 判定： 「完全」 → Generate Nodeへ遷移。
-
Expand / Rewrite Node（修正）：
- Expand: 切断されたチャンクの次のチャンクIDを指定して取得し、コンテキストを結合します。
- Rewrite: 質問の意図をより明確にしたクエリを再生成し、再検索を行います。
- Generate Node（生成 - Tree Summarizeの実装）：
十分なコンテキストが確保された状態で回答を生成します。長文の場合は、Tree Summarizeロジックを用いて階層的に回答を合成します。 - Reflect Node（自己反省 - Self-RAGの実装）：
最終回答が幻覚を含んでいないか、質問に完全に答えているかを検証します。合格なら終了、不合格なら再修正ループに入ります。
5. ベンチマーク評価とトレードオフ分析
Agentic RAGへの移行は、精度と信頼性を劇的に向上させる一方で、レイテンシ（応答速度）とコストの増加というトレードオフを伴います。
5.1 精度と完全性の向上
ベンチマークテストにおいて、Deep ResearchおよびAgentic RAGアプローチは標準RAGを圧倒しています。
- DeepResearch Bench:
実際の調査タスクを用いたベンチマークにおいて、Gemini Deep Researchのようなエージェント型モデルは、レポートの品質スコアで約48.8を記録しました。これは、単なる検索機能付きLLMよりも「引用の有効性」や「調査の幅（Breadth）」において優れており、1タスクあたり100件以上の有効な引用を行う能力を示しました。 - F1スコア（CRAG）:
検索評価器と修正ループを導入したCRAGは、特定の知識抽出タスクにおいてF1スコア（適合率と再現率の調和平均）を最大で98.9%まで向上させました。これは、標準RAGがしばしば陥る「関連情報の見逃し（再現率の低さ）」と「不要情報の混入（適合率の低さ）」の両方を改善した結果です。
5.2 コストとレイテンシの壁
しかし、この知能の向上にはコストがかかります。
| 指標 | 標準RAG | Agentic RAG / Deep Research |
|---|---|---|
| LLM呼び出し回数 | 1回（生成のみ） | 5回〜数十回（計画、評価、書き換え、生成、反省） |
| レイテンシ | 200ミリ秒 〜 2秒 | 10秒 〜 数分（Deep Researchの場合） |
| トークン消費量 | 少ない | 非常に多い（中間生成物や評価のためにドキュメントを何度も読む） |
5.3 適応的ルーティング（Adaptive RAG）による最適化
すべてのクエリにAgentic RAGを適用するのはコスト効率が悪いため、Adaptive RAG（適応的RAG） の導入が推奨されます。これは「ルーター」と呼ばれる前段の分類器を用いて、クエリの複雑さに応じて処理パイプラインを切り替える手法です。
- Simple Query: 「X社の住所は？」のような単純な事実確認 → 標準RAG（高速・安価）
- Complex Query: 「X社の過去5年間の成長戦略と市場環境の変化を分析せよ」のような長文・統合クエリ → Agentic RAG（高精度・高コスト）
このルーター自体も小型のLLMや分類モデルで実装可能であり、ユーザー体験とコストのバランスを最適化する上で極めて重要です。
6. 戦略的推奨事項とロードマップ
RAG使用者が抱える「長文Q&Aでの回答切断」「コンテキスト理解不足」を解決するための、段階的な導入ロードマップを提案します。
フェーズ1：即効性のあるアーキテクチャ改善（今すぐできる対策）
- 親ドキュメント検索（Parent Document Retrieval）の導入：
ベクトル検索の単位（インデックス）は小さなチャンク（例：256トークン）のままにしつつ、LLMに渡す際はそのチャンクが属する「親ドキュメント」または「ウィンドウ（前後500-1000トークン）」を取得するように変更します。これにより、検索精度を維持したまま、文脈の断絶を即座に緩和できます。 - LlamaIndexのresponse_mode変更：
現在LlamaIndexを使用している場合、または移行可能であれば、長文Q&A用のResponse Modeをデフォルトのcompactからtree_summarizeに変更してください。これだけで、回答が途中で切れる問題の多くが解消されます。
フェーズ2：Agentic Logicの実装（中期的対策）
- 検索評価器（Retrieval Grader）の追加：
検索直後に軽量LLMを挟み、「この検索結果で回答可能か？」を判定させます。もし「情報不足（Incomplete）」と判定された場合、プログラム的に次のチャンクを取得するロジックを追加します。これは簡易版CRAGの実装となります。 - ループ構造への移行：
LangGraph等を導入し、直線的な処理からループ処理へ移行します。検索結果が不十分な場合に、ユーザーに「わかりません」と返すのではなく、自動的にクエリを修正して再検索するリトライループを実装します。
フェーズ3：Deep Researchエージェントの構築（長期的・完全な解決策）
- 完全なDeep Researchエージェントの開発：
非常に複雑な質問に対しては、一度の検索で答えようとせず、スクラッチパッドを活用して情報を蓄積するエージェントを構築します。エージェントは「調査計画」を立て、複数のソースから情報を集め、最終的にレポート形式で回答を出力します。 - Adaptive Routingの統合：
単純な質問には高速に、複雑な質問には時間をかけて深く答えるハイブリッドなシステムを構築し、UXとコストを最適化します。
結論
標準的なRAGのアプローチは、単純な情報検索には有効ですが、文脈が深く絡み合う長文Q&Aにおいては限界を迎えています。回答の切断やコンテキストの欠落は、システムが「読んで理解する」プロセスを欠いている証拠です。
Agentic RAGおよびDeep Researchアーキテクチャは、LLMに「検索結果を評価し、不足があれば自ら補う」という自律性を与えることで、これらの問題を根本から解決します。特にSelf-RAGによる自己修正とTree Summarizeによる階層的統合は、エンタープライズレベルの信頼性を担保するために不可欠な技術要素です。これらの導入により、システムは単なる検索エンジンから、真の意味での「リサーチアシスタント」へと進化するでしょう。
表1：長文Q&AにおけるRAGアーキテクチャの比較
| 機能・特性 | 標準RAG (Naive RAG) | Self-RAG / CRAG | Deep Research Agent |
|---|---|---|---|
| 処理フロー | 直線的 (Retrieve $\rightarrow$ Generate) | 条件付きループ (Evaluate $\rightarrow$ Loop) | 反復的・計画的 (Plan $\rightarrow$ Iterate $\rightarrow$ Synthesize) |
| 検索単位 | 固定チャンク | 動的 (必要に応じて拡張・再検索) | マルチステップ検索 (派生クエリによる深掘り) |
| 回答生成 | シングルパス (容量オーバーで切断) | 評価と修正 (不完全なら書き直し) | スクラッチパッドへの蓄積と統合 |
| コンテキスト理解 | 局所的 (チャンク依存) | 改善 (関連性・支持性のチェック) | 大域的 (複数ソースの統合による全体理解) |
| 主な用途 | 単純な事実質問、FAQ | 品質の高さが求められるQ&A | 複雑なレポート作成、網羅的調査 |
| コスト・速度 | 低・高速 | 中・中速 | 高・低速 |
参考文献および出典:
本報告書における記述は、提供された調査資料（1～35）および関連する技術ドキュメント（4～21）に基づいています。特に、Self-RAG8、CRAG15、Tree Summarize19、およびDeep Research5に関する記述は、それぞれの主要な技術解説を参照しています。
引用文献
- Limitations of Chunking and Retrieval in Q&A Systems : r/Rag - Reddit, 12月 18, 2025にアクセス、 https://www.reddit.com/r/Rag/comments/1jh2xgs/limitations_of_chunking_and_retrieval_in_qa/
- The Common Failure Points of LLM RAG Systems and How to Overcome Them - Medium, 12月 18, 2025にアクセス、 https://medium.com/@sahin.samia/the-common-failure-points-of-llm-rag-systems-and-how-to-overcome-them-926d9090a88f
- Long Context RAG Performance of LLMs | Databricks Blog, 12月 18, 2025にアクセス、 https://www.databricks.com/blog/long-context-rag-performance-llms
- Agentic RAG: From Overviews to Deep Research - Zeta Alpha, 12月 18, 2025にアクセス、 https://www.zeta-alpha.com/post/agentic-rag-from-overviews-to-deep-research
- Stop Using Outdated RAG: DeepSearcher's Agentic RAG Approach Changes Everything, 12月 18, 2025にアクセス、 https://milvusio.medium.com/stop-using-outdated-rag-deepsearchers-agentic-rag-approach-changes-everything-0fb81a590a76
- Summarization techniques, iterative refinement and map-reduce for document workflows | Google Cloud Blog, 12月 18, 2025にアクセス、 https://cloud.google.com/blog/products/ai-machine-learning/long-document-summarization-with-workflows-and-gemini-models
- Long-Context Isn't All You Need: How Retrieval & Chunking Impact Finance RAG, 12月 18, 2025にアクセス、 https://www.snowflake.com/en/engineering-blog/impact-retrieval-chunking-finance-rag/
- Advanced RAG Techniques - Pinecone, 12月 18, 2025にアクセス、 https://www.pinecone.io/learn/advanced-rag-techniques/
- Deep Research Agents: A Systematic Examination And Roadmap - arXiv, 12月 18, 2025にアクセス、 https://arxiv.org/html/2506.18096v2
- Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection - arXiv, 12月 18, 2025にアクセス、 https://arxiv.org/abs/2310.11511
- The Self-RAG Shortcut Every AI Expert Wishes They Knew - ProjectPro, 12月 18, 2025にアクセス、 https://www.projectpro.io/article/self-rag/1176
- Self RAG (Retrieval Augmented Generation) - GeeksforGeeks, 12月 18, 2025にアクセス、 https://www.geeksforgeeks.org/artificial-intelligence/self-rag-retrieval-augmented-generation/
- Self-RAG - GitHub Pages, 12月 18, 2025にアクセス、 https://langchain-ai.github.io/langgraph/tutorials/rag/langgraph_self_rag/
- Implementing Self-Reflective RAG using LangGraph, OpenAI and FAISS - Reddit, 12月 18, 2025にアクセス、 https://www.reddit.com/r/LangChain/comments/1iiyq21/implementing_selfreflective_rag_using_langgraph/
- Corrective RAG (CRAG): Workflow, implementation, and more - Meilisearch, 12月 18, 2025にアクセス、 https://www.meilisearch.com/blog/corrective-rag
- Implementing Corrective RAG in the Easiest Way - LanceDB, 12月 18, 2025にアクセス、 https://lancedb.com/blog/implementing-corrective-rag-in-the-easiest-way-2/
- Corrective RAG (CRAG) Implementation With LangGraph - DataCamp, 12月 18, 2025にアクセス、 https://www.datacamp.com/tutorial/corrective-rag-crag
- HuskyInSalt/CRAG: Corrective Retrieval Augmented Generation - GitHub, 12月 18, 2025にアクセス、 https://github.com/HuskyInSalt/CRAG
- Response Synthesizer | LlamaIndex Python Documentation, 12月 18, 2025にアクセス、 https://developers.llamaindex.ai/python/framework/module_guides/querying/response_synthesizers/
- LlamaIndex 0.7.0: Better Enabling Bottoms-Up LLM Application Development - Medium, 12月 18, 2025にアクセス、 https://medium.com/llamaindex-blog/llamaindex-0-7-0-better-enabling-bottoms-up-llm-application-development-959db8f75024
- Response Modes | LlamaIndex Python Documentation, 12月 18, 2025にアクセス、 https://developers.llamaindex.ai/python/framework/module_guides/deploying/query_engine/response_modes/
- Explore the Tree Summarize Function in LlamaIndex: Benefits and Practical Uses - Arsturn, 12月 18, 2025にアクセス、 https://www.arsturn.com/blog/tree-summarize-function-in-llamaindex-benefits-and-use-cases
- Llamaindex Response Modes Explained: Let's Evaluate Their Effectiveness | BlueLabel, 12月 18, 2025にアクセス、 https://www.bluelabellabs.com/blog/llamaindex-response-modes-explained/
- Build a custom RAG agent with LangGraph - Docs by LangChain, 12月 18, 2025にアクセス、 https://docs.langchain.com/oss/python/langgraph/agentic-rag
- LangGraph vs. LlamaIndex Workflows for Building Agents —The Final no BS Guide (2025), 12月 18, 2025にアクセス、 https://medium.com/@pedroazevedo6/langgraph-vs-llamaindex-workflows-for-building-agents-the-final-no-bs-guide-2025-11445ef6fadc
- Building knowledge graph agents with LlamaIndex Workflows, 12月 18, 2025にアクセス、 https://www.llamaindex.ai/blog/building-knowledge-graph-agents-with-llamaindex-workflows
- Guide to Adaptive RAG Systems with LangGraph - Analytics Vidhya, 12月 18, 2025にアクセス、 https://www.analyticsvidhya.com/blog/2025/03/adaptive-rag-systems-with-langgraph/
- Self-Rag: A Guide With LangGraph Implementation | DataCamp, 12月 18, 2025にアクセス、 https://www.datacamp.com/tutorial/self-rag
- New "DeepResearch Bench" Paper Evaluates AI Agents on PhD-Level Tasks, with Gemini 2.5 Pro Deep Research Leading in Overall Quality. : r/accelerate - Reddit, 12月 18, 2025にアクセス、 https://www.reddit.com/r/accelerate/comments/1lf20x6/new_deepresearch_bench_paper_evaluates_ai_agents/
- CRAG – Comprehensive RAG Benchmark - arXiv, 12月 18, 2025にアクセス、 https://arxiv.org/pdf/2406.04744
- Evaluating Faithfulness in Agentic RAG Systems for e-Governance Applications Using LLM-Based Judging Frameworks - MDPI, 12月 18, 2025にアクセス、 https://www.mdpi.com/2504-2289/9/12/309
- Adaptive RAG explained: What to know in 2025 - Meilisearch, 12月 18, 2025にアクセス、 https://www.meilisearch.com/blog/adaptive-rag
- RouteRAG: Adaptive Routing in RAG Systems - Emergent Mind, 12月 18, 2025にアクセス、 https://www.emergentmind.com/topics/routerag
- Q&A patterns | LlamaIndex Python Documentation, 12月 18, 2025にアクセス、 https://developers.llamaindex.ai/python/framework/understanding/putting_it_all_together/q_and_a/
- Relevance Isn't All You Need: Scaling RAG Systems With Inference-Time Compute Via Multi-Criteria Reranking - arXiv, 12月 18, 2025にアクセス、 https://arxiv.org/html/2504.07104v1