【ITニュース解説】Lessons & Practices for Building and Optimizing Multi-Agent RAG Systems with DSPy and GEPA

今日のIT分野で急速に進化する大規模言語モデル（LLM）は、人間のような自然な文章生成能力を持つ。しかし、LLM単体では最新情報や特定の専門知識に弱く、誤った情報を生成する「ハルシネーション」と呼ばれる問題も抱えている。これを解決するのが「Retrieval-Augmented Generation（RAG）」という技術である。RAGは、外部の知識ベース（データベースやドキュメント）から関連情報を検索し、その情報を基にLLMが回答を生成することで、より正確で根拠のある出力を可能にする。

さらに高度なRAGシステムとして、「マルチエージェントRAGシステム」が注目されている。これは、特定の専門分野を持つ複数の「エージェント」が協力し、複雑な問題を解決するシステムである。例えば、医療分野で糖尿病とCOPD（慢性閉塞性肺疾患）の専門エージェントが連携するように、専門性を高めることで単一の汎用エージェントよりも高い精度と信頼性を実現できる。

このようなマルチエージェントRAGシステムを効率的に構築し最適化するための強力なツールが、「DSPy」と「GEPA」である。DSPyは、LLMを使ったシステムの開発を構造化するフレームワークで、従来の試行錯誤的なプロンプトエンジニアリングをモジュール化し、再利用性と保守性の高いエージェント構築を可能にする。GEPA（Genetic-Pareto Prompt Optimizer）は、DSPyに組み込まれたプロンプト自動最適化ツールだ。これは、進化的アルゴリズムと「自己反省（Reflection LM）」という仕組みを利用し、エージェントの出力や思考プロセスに対するフィードバックを基にプロンプトを自動的に改善する。これにより、手動調整よりも効率的かつ効果的にシステムの性能を高められる。

ある先駆的な研究では、DSPyとGEPAを用いて、糖尿病とCOPDの専門サブエージェントが構築された。各サブエージェントは専用の検索ツールを持ち、ReAct（Reasoning and Acting）パターンで推論と行動を繰り返す。個々のサブエージェントをGEPAで最適化した後、リードエージェントがユーザーの質問に応じて適切なサブエージェントを選択し、回答を統合する役割を担い、この構成でシステムの評価指標が大幅に向上することが示された。

筆者もこのアプローチを法律文書や規制ガイダンスという複雑なドメインに適用し、その経験から重要な学びを得た。 まず、「ドメイン特化型検索ツール」の構築が極めて重要だと分かった。法律文書のように複雑なテキストでは、汎用的な埋め込みモデル（テキストを数値ベクトルに変換するモデル）では不十分で、ドメイン特化の埋め込みモデルを用いることで、より関連性の高い文書を検索できるようになった。また、文書の作成日や管轄地域などの「メタデータ」で検索結果をフィルタリングすることで、ノイズを削減し精度を高めることができた。

次に、ReActサブエージェントへの「プロンプトと指示設計」が行動に大きな影響を与えた。「なぜこのツールを選んだのか説明せよ」といった推論ステップを組み込むことで、エージェントはより論理的にツールを選択する。少数の具体例をプロンプトに含めることは最適化を助けるが、多すぎるとプロンプトが長くなり、推論速度の低下や汎化性能（未知のデータへの適応能力）の低下を招くため、バランスが重要である。

GEPAのチューニングでは、「Reflection LM」の選択が重要だ。GEPAはReflection LMのフィードバックを基にプロンプトを改善するため、高性能なReflection LMは質の高いフィードバックを与えるがコストも高くなる。コストを抑えた小さなモデルではフィードバックが抽象的になりがちで、システムの要件とコストのバランスを見極める必要がある。

さらに、サブエージェントを個別に最適化するだけでなく、リードエージェントとサブエージェント全体を「共同で最適化」することの重要性も明らかになった。個々のサブエージェントが優れていても、リードエージェントの連携が不十分だと全体性能は上がらない。複数のドメインにまたがる曖昧な質問に対応できるよう、最適化の際に「混合クエリ」を含むデータセットを用いることが推奨される。

この分野は急速に進化しており、2025年半ばの時点で、以下のような最先端の研究トレンドが見られる。「MAO-ARAG」は、質問に応じて最適な実行エージェントを動的に選択するアダプティブなRAGシステムを提案している。「Maestro」は、プロンプト最適化だけでなく、エージェント間の接続方法（グラフ構造）や各モジュールの設定自体も自動で最適化する手法を示し、システムの構造自体を見直す重要性を指摘する。「ReSo」は、エージェントが自律的に役割を分担し、きめ細やかな報酬信号で学習する、柔軟でスケーラブルなシステムを目指す。これらの研究は、プロンプトの改善に加え、エージェントの「構造」や「ワークフローの動的な適応」、そして「効率的なフィードバック」が今後の焦点であることを示唆している。

筆者の経験と最新の研究動向を踏まえ、マルチエージェントRAGシステムを構築する際に注意すべき「落とし穴」と、推奨される「ベストプラクティス」を以下に述べる。 まず、開発や評価に使うデータセットが偏っていると、システムがそのデータセットに過学習し、実際の多様な利用シーンで機能しない「過学習」という落とし穴がある。次に、高性能なReflection LMの使用や多くの評価実行は、API利用料などの「コストとレイテンシ（応答速度の遅延）」を増大させる可能性がある。また、エージェントの思考や行動を示す詳細な「トレース」と「意味のあるフィードバック指標」が不十分だと、GEPAは本質的な問題を解決する改善を行えないことがある。さらに、エージェントの構成が固定されすぎていると、プロンプト最適化だけでは根本的な問題解決が難しい「グラフ構造の限界」に直面することもある。

これらの課題を乗り越えるため、いくつかの推奨事項がある。 システム設計では、「モジュール性から始める」ことが重要で、特定のドメインや機能ごとにサブエージェントを明確に定義し、明確なツールインターフェースを持たせるべきである。トレーニングや開発データは、「多様なデータを準備する」ことで、過学習を防ぎ、汎化性能を高める。GEPAの運用では、「能力とコストのバランスが取れたReflection LMを選択」し、最初は低コストモードから始め、必要に応じて調整する。エージェントの「構造」は固定せず、Maestroのような研究にヒントを得て、異なるワークフローやモジュール構成を試すことで、プロンプト最適化以上の性能向上を追求すべきである。評価においては、最終的な精度だけでなく、「精度以外の解釈可能なフィードバック指標」を用いることで、GEPAが具体的な改善点を見つけ出す手助けとなる。そして、開発環境での改善が実際の利用シーンでも有効であるかを定期的にテストし、「汎化性能を常に監視する」必要がある。

結論として、DSPyによる構造化されたエージェント設計とGEPAによる自動プロンプト最適化の組み合わせは、マルチエージェントRAGシステム構築において非常に強力なアプローチである。GEPAは、少ないデータで効率的に最適化を進め、堅牢なシステムを構築できる可能性を秘め、DSPyは、複雑なシステムをモジュール化された、管理しやすい形で構築するための優れた基盤を提供する。 今後、エージェントはさらに賢く、動的なワークフローを適応させ、プロンプトだけでなく構造も最適化し、人間の介入が少ないまま高性能を維持できる方向に進化していくと期待される。