RAGの「集計」機能を向上させるエージェントを用いた解決方法

生成AIを業務の大きなデータを扱う場合に、RAG（Retrieval-Augmented Generation）を取り入れることは有効な手法となります。分量の多い社内ドキュメントやマニュアルをAIに読み込ませ、精度の高い回答を得るシステムを設計している方は多いでしょう。

しかし、PoC（概念実証）を進める中で、「RAGはデータの集計や網羅的な条件抽出」が苦手という問題をクリアしなければいけない場合があります。

本記事では、この問題がなぜ起きるのかというRAGの構造的な原因と、それを解決するための「LLMエージェント」を用いたシステムアーキテクチャについてまとめます。

なぜ、RAG（いきなりベクトル検索）では集計ができないのか？

一般的なRAGのシステムフローは以下のようになっています。

1. ユーザーが質問を入力する
2. 質問をベクトル化し、ベクトルデータベースから関連度合いの高いチャンク（文章の断片）を上位N件（例：5件）抽出する
3. 抽出した5件のテキストをプロンプトに埋め込み、LLMに回答を生成させる

このフローのまま、得意先情報が格納されたデータベースに対して「大阪にある会社をすべて探して」「今月の売上総額を集計して」といった質問を投げると。。。

システムは「大阪の会社」に意味的（ベクトル的）に近いデータを上位5件だけ抽出し、LLMに渡します。LLMは与えられた「5件」という極めて狭い情報だけを受け取るため、データベース全体に大阪の会社が100件あったとしても、「大阪の会社は5件です」という誤った回答をする可能性があります。つまりLLMに与える情報数によって、母数の情報が制限されてしまうのです。

ベクトル検索（類似度検索）は、「意味的に近い文章」を探すことを目的とするため、「条件に完全一致するものを数え上げる」「全体をソートする」といった処理は苦手です。

エージェントによる解決フロー

では、「意味的に近い文章」と「集計・ソート等」の両方に回答精度を上げるためには「LLMエージェント」を活用した動的な検索手法の処理分岐です。

エージェントアーキテクチャの処理ステップ

1. 質問内容を分類する処理
   質問を受け取ったLLMは、まず「これは意味検索が必要か、それともデータベースの集計・条件検索が必要か」を判断します。
2. 検索ツールの取捨選択と実行
   LLMが判断した意図に基づき、裏側で用意されたツール（API）を呼び出します。
   • ルートA： ベクトルDBに対して類似度検索を実行（従来のRAG）
   • ルートB： Text-to-SQL（自然言語からSQLを生成）を用いてRDBに対してクエリを実行等
3. 回答生成
   実行したツールの結果（抽出されたテキスト、またはSQLの集計結果）を受け取り、ユーザーに向けて自然な言語で回答を生成します。

この構成をとることで、「マニュアルの検索」から「精緻なデータ集計」までを一つのインターフェイスファンクションでシームレスに行うことが可能になります。