RAGは関連性の低い情報が多いと誤った回答をする可能性が高まるという課題を抱えていますが、情報の階層構造を活用することで、より的確に答えの根拠となる情報を見つけ出せるようになります。
今回は、この階層型RAGの仕組みと、それがいかにしてデータ編集の手間を省き、精度向上を実現するのかを解説します。
背景
従来のRAGは、ユーザーの質問に対して、まずベクトル検索などを用いてナレッジベースから関連性の高い情報を探し出し、その情報を基に大規模言語モデル（LLM）が回答を生成する、という仕組みです。
RAGを構築する際に、関連性の低い細かい情報が大量にあると誤った回答をするという課題があります。
かといってベクトルDB（ナレッジベース・外部データソース）のデータを直接編集するのは時間がかかります。
そこで階層型RAGの導入によって精度向上をはかります。
階層型RAGの仕組み
階層型RAGは検索する際に、上位レベルのベクトルDBから検索して、後に限定された範囲で検索を行うという検索範囲を絞り込む仕組みをしています。
従来のRAGでは、ベクトルDBは一つにまとまっています。
なので、大量のデータがあると間違えてしまう可能性が上がります。
そこで、階層型RAGでは検索を2段階に分けて検索範囲を絞り込みます。
- 上位レベル（summary/parent）：文書全体の概要やセクションごとの要約
- 下位レベル（child/leaf）：従来のRAGに入れているような詳細なデータ
検索の仕組み
- 質問に対して、まずは上位レベルで検索し、関連するドキュメントを限定します。
- 限定されたドキュメントから直接回答の根拠になる情報を抽出します。（従来のRAGと同じ仕組み）
このようにして、限定されたドキュメントから検索することで間違える可能性を下げるという方法になっています。
検証結果
あるシステムの機能を検索するRAGを構築しました。
ベクトルDBは、次のように階層を分けました。（ベクトルDBを2個 作成しました。）
- 上位レベル：
同一機能かどうかの観点でフォルダを複数個作成。フォルダに対してベクトルDBを作成 - 下位レベル：
それぞれの機能ごとのフォルダに該当する文章を格納。各フォルダに含まれる全ファイルに対してベクトルDBを作成
今回はフォルダのベクトルDB（上位レベル）についてはフォルダ内に含まれるチャンクのベクトルの平均をとりました。
（他の方法としては機能書を概要にまとめたり・要約したりする方法が考えられます。）
これにより、次のように段階的に検索が行われ、検索範囲を限定、絞り込んだ範囲で検索が行われます。
- 機能ごとに分かれているフォルダから該当する機能のフォルダをいくつか挙げる
- 特定された機能フォルダ内の資料から、直接回答の根拠になる文章を抽出
階層型RAGによって、回答の根拠になる参照情報を検索する工程で、期待した情報がヒットする確率が上昇しました。
それによって、RAGの回答精度が上昇しました。
まとめ
階層型RAGの構築により、ベクトルDB（ナレッジベース・外部データソース）を階層ごとに分けることで検索範囲を限定、絞り込んだ範囲で検索することでRAGの回答精度が上がりました。
