Agentic RAGに進化した社内向けQAエージェント

社内向けQAエージェントをAgentic RAGへアップデートした事例を紹介します。

はじめに

Hacobuでは、MOVOサービスの仕様に関する問合せに回答するチャットボット型のRAG（Retrieval Augumented Generation）を社内向けに提供しており、以前から社内で整備していたヘルプやFAQドキュメントによりベクトルDBを構築しています。

課題感

RAGの回答内容に基本的には満足しているが、以下のような課題を抱えていました。

• テクニカルサポート側
  • FAQに情報があるにも関わらず、適切な回答が得られない場合の原因調査に手間がかかる
• IT部門側
  • そもそもベクトルDBに存在しない質問（例えば、新機能のFAQが未整備の場合など）に対して正しく回答できない
  • レスポンス時間・コストの可視化が必要
  • 現状より回答精度が悪化しないかが心配で、プロンプトを気軽に変えられない

解決策：Agentic RAG化とLangfuse v2の導入

RAGで回答できない場合に、別の方法で回答できる仕組みにするため、典型的なナイーブRAGをAgentic RAG[1]に作り替え、さらにLLMOpsを実践するため、Langfuse v2の導入を決めました。Langfuse v2を導入することで、以下のことが実現できます。

• 可観測性：エージェントの内部状態や意思決定を可視化でき、問題がより発見しやすい
• トレーサビリティ：エージェントの入出力を追跡でき、問題の原因を迅速に特定でき、再現性のあるテストが可能です
• 開発と運用の効率性：プロンプトを管理できるだけでなく、RAGAS（RAG Assessment）[2]を導入することで、RAGの回答精度も監視できます

Agentic RAGの技術スタック

技術スタックとしては、以下の通りです。RAGの技術選定に関しては、[3]に記載しています。

• チャット：Chainlit + UIカスタマイズ（React）
• LLMフレームワーク：Langchain
• ベクトルDB：FAISS
• ワークフロー：LangGraph
• データベース：PostgreSQL

Agentic RAGの構成

[4]の論文で紹介されているAgentic RAGには幾つかの種類があり、今回はHierarchical Agentic RAGを採用しました。理由は、ユーザからの質問に対して、RAGで回答できない場合に、SSE（Server-Sent Events）トランスポートのMCP（Model Context Protocol）経由でNotionに問合せをする実装にしたかったため、ワークフローにより直列的に実行できる構成を選択しました。

　　　　　　　　　　　Hierarchical Agentic RAG（画像は[4]より引用）

実際のAgentic RAGの状態遷移図は下記の通りです。WorkflowはLanggraphで実装しており、上図のMaster Agentはsupervisorとして実装し、rag_agentがRAGの処理を担い、mcp_agentがNotion API経由での検索を担っています。当然ながら、RAGの処理で回答を作成できた場合は、mcp_agentには遷移せずに終了します。

　　　　　　　　　　　　　　　　　　　状態遷移図

まとめ

社内向けのQAエージェントをAgentic RAGへアップデートした事例を紹介しました。今回はAgentic RAGの内容のみでしたが、次回は、langfuse v2を選択した理由や、RAGASによりパイプライン評価の実現について書きたいと思います。

参考文献

[1] 【論文紹介】Agentic RAGのサーベイ
[2] Ragas
[3] RAGの精度検証のすゝめ
[4] Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG