RAGの限界を超えるAgent Search：LangGraphで知識を運用する実践

従来のRAGシステムは単純な事実検索で高い精度を発揮しますが、複雑で曖昧なクエリに対しては限界があります。例えば「NikeとPumaの製品ポジショニングの違いが売上結果にどう影響したか」といった質問では、複数のエンティティを扱い、用語の曖昧さを解消する必要があります。従来RAGは近似するドキュメントがなければ十分な回答を返せません。この問題は実際の業務で頻出するパターンです。

📑目次

1. 従来RAGの限界と複雑クエリの問題
2. Agent Searchの3段階アプローチ（Decompose / Compose / Refine）
3. LangGraph選択の理由とアーキテクチャ設計
4. 並列処理・状態管理・ストリーミングのベストプラクティス
5. 比較表：従来RAG vs Agent Search
6. よくある質問
7. まとめと次のステップ

---

従来RAGの限界と複雑クエリの問題

従来のRAGはベクトル検索と生成を組み合わせたシンプルな仕組みです。近似するドキュメントが見つかれば事実を抽出できます。しかし、クエリに複数の企業名や曖昧な用語が含まれる場合、単一の検索で必要な文脈をすべて集められません。LangChain公式ブログのOnyx事例では、この限界を具体的に指摘しています。読者は「検索すれば答えが出る」という前提を一旦手放す必要があります。

---

Agent Searchの3段階アプローチ（Decompose / Compose / Refine）

Agent SearchはLangGraphを使って3段階のプロセスを構築します。まずDecomposeで元の質問を狭いサブクエリに分解します。次にComposeでサブクエリの回答とドキュメントから初期回答を合成します。Refine段階では、初期回答が不十分な場合に再度分解を行い、改善します。このサイクルはOnyxの実装で具体化されており、LangChain公式ブログで詳細が公開されています。読者は各段階で人間が判断を挟む余地を残せます。

---

LangGraph選択の理由とアーキテクチャ設計

LangGraphを選んだ理由はノード・エッジ・ステートの自然なマッピングと、オープンソースコミュニティの強力なサポートにあります。1週間のプロトタイプ作成後、ファンアウトやサブグラフ、ステート管理、ストリーミングなどの懸念点が解消されたため、本格採用に至りました。コード組織では1ノード1ファイルとし、サブグラフごとに専用ディレクトリを用意するなど、実務的なベストプラクティスが蓄積されています。読者はプロトタイプ段階でアーキテクチャの適合性を検証する習慣を身につけられます。

---

並列処理・状態管理・ストリーミングのベストプラクティス

並列処理ではMap-Reduce分岐を活用し、同一フローを複数ドキュメントに適用します。ステート管理にはPydanticモデルを優先し、入力キーはデフォルトなしで定義するルールを徹底します。ストリーミングはカスタムイベントを使ってサブ回答とドキュメントを同時に配信し、ユーザー体験を向上させています。Onyxの事例ではサブグラフをノードとして扱うことで不要な待ち時間を避けています。読者はこれらのパターンを自社パイプラインに適用する際の注意点を理解できます。

---

比較表：従来RAG vs Agent Search

項目	従来RAG	Agent Search
複雑クエリ対応	限定的（近似ドキュメント依存）	高い（分解・合成・洗練の3段階）
複数エンティティ	弱い	強い（並列処理・関係抽出）
実装コスト	低い	中程度（LangGraph学習必要）
ストリーミング	基本対応	高度（サブグラフ活用）
拡張性	低い	高い（HITL・ツール追加容易）

出典: LangChain公式ブログ (https://www.langchain.com/blog/beyond-rag-implementing-agent-search-with-langgraph-for-smarter-knowledge-retrieval) および Onyx GitHub (https://github.com/onyx-dot-app/onyx)（2025年2月時点）

---

関連記事:

• AgentSea / SurfKit：Kubernetes風AIエージェントオーケストレーターの概要と使い方
• Transformerの最大475倍、富士通新LLMアーキテクチャ「PHOTON」——GPU効率を劇的に向上
• 数十ページのPDFを1回で処理できるローカルOCR「Unlimited OCR」バイドゥが無料公開、商用利用も可能

よくある質問

1. Agent SearchはRAGを完全に置き換えるのか？
   いいえ。Agent SearchはRAGを補完する位置づけです。単純な事実検索は従来RAGのまま残し、複雑クエリのみをAgent Searchに振り分ける設計が現実的です。

2. LangGraphの学習コストはどの程度か？
   プロトタイプ作成で1週間程度で実用レベルに到達可能です。ノードとステートの概念を理解すれば既存LangChainコードの多くを再利用できます。

3. 並列処理でコストは増加しないか？
   サブグラフ再利用とフォーマットノードの工夫で抑制できます。不要な待ち時間を避ける設計が重要です。

4. 実際の企業事例で効果は出ているか？
   Onyxの導入で複雑クエリに対する回答品質が向上したとの報告があります。Human-in-the-Loop機能の追加も計画中です。

5. 既存RAGパイプラインへの移行方法は？
   サブグラフ単位での段階的導入が推奨されます。既存の検索部分をそのまま活かし、Agent Searchのグラフを後段に接続できます。

---

まとめと次のステップ

Agent SearchはRAGを完全に置き換えるものではなく、補完する位置づけです。既存パイプラインへの移行は、サブグラフ単位での段階的導入が推奨されます。LangGraphの学習コストはプロトタイプ作成で1週間程度で実用レベルに到達可能です。並列処理によるコスト増加は、サブグラフ再利用とフォーマットノードの工夫で抑制できます。企業事例としてOnyxの導入で、複雑クエリに対する回答品質が向上したとの報告があります。実際の運用では、Human-in-the-Loop機能の追加やツール統合を計画中です。読者は自社のクエリ特性を分析し、Agent Searchの導入範囲を判断してください。