developersIO
BookRAG論文解説：複雑文書をTree・KG・GT-Linkで扱うRAGとは

BookRAG論文解説：複雑文書をTree・KG・GT-Linkで扱うRAGとは

RAGAIOpenAIAmazon Bedrock
2026.04.13

複雑文書を「チャンク集合」ではなく「構造 + 関係」で扱うBookRAG

はじめに

RAGの話をしていると、どうしても「文書をどうチャンク化するか」に意識が寄りがちです。
ただ、実際の業務文書はそんなに素直ではありません。章・節・表・図・脚注があり、ルールは複数箇所に散らばり、ある表の意味は本文を読まないとわからない。そんな文書に対して、普通のチャンクベースRAGだけで本当に十分なのか、という疑問がありました。

それらを問題定義し、解決を狙った BookRAG という手法を提案する論文があります。
BookRAGを一言でいうと、複雑文書を単なるチャンク集合として扱うのではなく、文書構造・概念関係・その対応関係まで含めた索引を作り、質問の種類に応じて検索手順を変えるRAGです。

この記事では、まずBookRAGの要点を整理し、次に社内規定に当てはめたイメージを見たうえで、論文の詳細、従来手法との対比、AWSで組むならどうなりそうか、という順番で整理していきます。

まず結論

先に結論だけ書くと、BookRAGのポイントは次の3つです。

  1. 文書をTree + KG + GT-LinkからなるBookIndexにする
  2. 質問をsingle-hop / multi-hop / globalに分類する
  3. 分類結果に応じてoperator planを変える

つまりBookRAGは「構造を考慮したRAG」ではありますが、もう少し踏み込んで言うと、構造そのものを検索基盤に昇格させ、その上で質問ごとに探索方法を変えるRAGです。

用語解説

いきなりTreeやKGと言われてもなので、先に用語だけ整理します。

  • BookRAGの索引を構成する要素

    • Tree: 文書の章・節・表・図などの階層構造
    • KG: 文書内に出てくる概念や用語、その関係を表したグラフ
    • GT-Link: KGの概念がTreeのどの場所に由来するかを結ぶリンク
    • BookIndex: Tree・KG・GT-Linkをまとめた索引全体

  • 検索計画に関する用語

    • Planning: 質問を分類し、その結果に応じてどのoperatorをどう組み合わせるかを決める段階
    • Operator Plan: 実際の実行計画

  • 質問タイプに関する用語

    • Single-hop: 文書中の1か所にある情報を取りにいく質問
    • Multi-hop: 複数箇所の情報をつないで答える質問
    • Global: 文書全体や広い範囲を数える・絞る質問

  • 検索対象や判断に関する用語

    • entity: 論文中では、文書から抽出される細粒度の意味単位のこと。単なる固有名詞に限らず、概念・用語・項目名・表のヘッダなども含む。KGのノードになり、Tree上のどこから来たかはGT-Linkで結ばれる。
    • section: 論文中では、文書の論理構造上の節や見出し単位のこと。単なる文字列上の区切りではなく、Treeを構成する中間ノードで、retrievalの起点や探索単位として使われる。
    • relevant: 論文中では、「質問に対して関連している」「答えに近い証拠になりそう」という意味。たとえば relevant section は、質問に答えるうえで見る価値が高い節、という意味で使われる。

BookRAGの全体フローは Planning → Retrieval → Generation の3段階です。
この中のPlanningが「質問を分類し、どのoperatorをどう組み合わせるか」を決める中核になっています。

BookRAGとは何か

既存RAGの課題

論文では、従来のRAGは一般文書に対しては機能する一方で、本・規程・手順書・マニュアルのような複雑文書では弱い場面があると述べています。

その理由として、主に次の2点が挙げられています。

  • 章・節・表・図のような文書構造と、概念間の意味関係を一体で扱えていない
  • 質問の種類が違っても検索手順がほぼ固定

たとえば、定義を聞く質問と、複数箇所の比較質問、全文書から数える質問では、本来探し方が違うはずです。

BookRAGの基本アイディア

そこでBookRAGは、文書を BookIndex = Tree + KG + GT-Link に変換します。
Treeは文書ネイティブな構造、KGは概念関係、GT-Linkはその対応です。

つまり、「どこを見に行くか」と「何を手がかりに辿るか」を両方持つ設計にします。

そのうえで、オンライン検索では質問を分類し、質問タイプごとにoperator planを変えるようにします。
これがBookRAGの特徴です。単に「構造化した文書をLLMに読ませる」のではなく、構造化した索引を前提に、検索手順そのものを動的に組むわけです。

社内規定にBookRAGを当てはめる

ここからは、社内規定を例にしてBookRAGをイメージしやすくします。
論文の詳細に入る前に、この例を頭に入れておくと後半がかなり読みやすくなります。

Treeは何に当たるか

Treeは、規程の章立てを骨格にしつつ、その配下に本文・表・画像なども含めて持つ階層構造です。

  • 第1章 総則
  • 第2章 経費精算
  • 2.1 対象経費
  • 2.2 承認フロー
  • 表: 金額帯ごとの承認者
  • 付録: 例外申請 など

つまり、従来RAGのchunkを、章・節・表の所属関係つきで持っているものと考えると近いです。

KGは何に当たるか

KGは、規程の中に出てくる概念関係です。

  • 経費精算
  • 出張申請
  • 上長
  • 部門長
  • 10万円超
  • 領収書
  • 3営業日以内
  • 例外申請

そして関係は例えばこうです。

  • RequiresApprovalBy(10万円超の申請, 部門長)
  • RequiresDocument(経費精算, 領収書)
  • DeadlineIs(領収書提出, 3営業日以内)

つまり、社内規定におけるentityは、役職・制度・条件・期限・証憑・システム名などだと思うとわかりやすいです。

GT-Linkは何に当たるか

GT-Linkは、「その概念がどこに書いてあるか」の対応です。

  • "10万円超" → 2.2 承認フロー の表
  • "部門長" → 同じ表
  • "領収書" → 2.1 対象経費 の本文
  • "例外申請" → 付録ノード

つまり、KGの概念辞書から、規程本文の該当箇所にジャンプするためのリンクです。

質問タイプも社内規定だとわかりやすい

  • Single-hop
    「領収書はいつまでに提出すればよい？」
    → 1か所を見れば答えやすい。

  • Multi-hop
    「10万円超の備品購入と海外出張では、承認者はどう違う？」
    → 複数箇所を見て比較する必要がある。

  • Global
    「この規程集の中で、部門長承認が必要なケースはいくつある？」
    → 全体から条件を満たすものを数える。

論文解説

1. BookIndexの各要素

BookIndexは3つの要素で構成されています。

  • Tree
    章・節・本文・表・画像などを、文書の論理階層に沿って並べたもの。
    普通のchunkingよりも、「この表はどの節に属しているか」のような位置関係を残しやすいのがポイントです。

  • KG
    文書内の細粒度なエンティティと、その関係を表した知識グラフ。
    テキストだけでなく、表や画像も必要に応じてグラフ化します。
    表については、表そのものや行ヘッダ・列ヘッダもentityとして扱います。

  • GT-Link
    KGのentityが、Tree上のどのノードから来たかを結ぶリンク。
    これによって、概念から本文へ飛ぶ、逆に本文から関連概念へ戻る、という往復ができます。

2. どう作るのか

BookIndexの構築は、大きく Tree Construction と Graph Construction に分かれます。
Tree側ではレイアウト解析とsection filteringを使い、Graph側ではentity / relation抽出とGradient-based Entity Resolutionを行います。後者は、略称や表記揺れでentityが分裂しないように統合する仕組みです。

3. 質問を3種類に分ける

BookRAGでは、質問を次の3種類に分類します。

  • Single-hop: 1つの情報ターゲットを取りに行く質問
    • 例: 「Information Scent の定義は？」
  • Multi-hop: 複数箇所の情報を集めて比較・統合する質問
    • 例: 「Transformer は RNN と何が違う？」
  • Global Aggregation: 全文書や範囲内で数える・集計する質問
    • 例: 「Section4にIFT関連の図はいくつある？」

この分類は学術的に唯一絶対の分類というより、探索戦略を切り替えるためのroutingと理解するとわかりやすいです。

4. Planningとは何か

ここでいうPlanningは、質問を分類した後、どのoperatorをどの順で実行するかを決めることです。
具体的にはクエリ分類を行い、その結果に応じて実行可能なoperator列を生成します。

つまり、

  • 単純な質問ならentity起点で狭く取りに行く
  • 複雑な質問なら分解してからそれぞれを取りに行く
  • 全体集計系ならfilterを順に当てる

という感じで、質問ごとに探し方そのものを変えるのがPlanningです。

Operator Library解説

論文に出てくるOperator Libraryは、最初に読むと少し抽象的です。
そのため、この節では各operatorが「何をするものなのか」を一言ずつ整理します。
読み飛ばしても大丈夫ですが、後続の説明で単語の意味がわからなくなったときの辞書代わりに使えるようにしています。

まずオペレータは Formulator / Selector / Reasoner / Synthesizer の4グループに分かれています。
さらに、それぞれのグループには次の役割があります。

  • Formulator: 質問をどう扱うか整理するグループ
  • Selector: どこを見に行くか絞り込むグループ
  • Reasoner: 取ってきた候補を評価・順位付けするグループ
  • Synthesizer: 最後に回答へまとめるグループ

Formulator

質問を分解したり、質問の中から手がかりを取り出したりするグループです。
「まず何を探すべきか」を整える役割に近いです。

  • Decompose
    複雑な質問を、取りに行ける小さな質問に分解するoperator

  • Extract
    質問文から重要なentityを抜き出し、KG側のentityと結びつけるoperator

Selector

文書全体からいきなり探すのではなく、見るべき候補を先に絞るグループです。
BookRAGの「広い探索空間を狭めてから考える」流れの入り口です。

  • Filter_Modal
    Table / Figureなど、モダリティで候補を絞るoperator

  • Filter_Range
    ページ範囲やsection範囲で候補を絞るoperator

  • Select_by_Entity
    あるentityに関連するsection配下のTreeノード群を取るoperator

  • Select_by_Section
    relevantなsectionを選び、そのsection配下のTreeノード群を取るoperator

Reasoner

絞り込んだ候補の中で、どれがより重要か・関連が強いかを評価するグループです。
TreeとKGの両方を使って、複数の観点から候補を再評価します。

  • Graph_Reasoning
    KG上で重要なentityを辿り、GT-Link経由でTreeノードの重要度に落とし込むoperator

  • Text_Reasoning
    取得したTreeノードを、質問との意味的な近さで再評価するoperator

  • Skyline_Ranker
    複数の評価軸で候補を絞るoperator。単純な1軸順位付けではないのがポイントです。

Synthesizer

最後に、取得した証拠をもとに回答へまとめるグループです。
部分回答を作ってから統合する、という流れを担います。

  • Map
    取得した一部の情報から、部分回答を作るoperator

  • Reduce
    部分回答や複数証拠をまとめて、最終回答にするoperator

プログラムとプロンプトそれぞれの役割

BookRAGは、プロンプトで方針を決める部分と、プログラムでBookIndexを操作する部分とで分かれています。

プロンプトの役割

  • 質問をsingle-hop / multi-hop / globalに分類する
  • 複雑な質問をsub-questionに分解する
  • 質問文からentityを抽出する
  • relevant sectionを選ぶ補助をする
  • partial answer / final answerを生成する

要するに、何をするべきかを判断・生成する部分がLLM側です。
その判断を引き出すための入力がプロンプトです。

プログラムの役割

主にBookIndexを実際に操作する部分です。

  • Tree / KG / GT-Linkを構築する
  • operator planに沿って処理を順に実行する
  • entityに紐づくsubtreeを取り出す
  • page / section / modalでフィルタする
  • KG上でreasoningし、その結果をGT-Link経由でTreeに反映する
  • 複数スコアを使って候補を絞る

要するに、論文内で定義されている方針を実際に実行するエンジンがプログラム側です。

何が効いているのか

論文中のベンチマーク結果を見ると、Planningが最も重要だそうです。w/o Planning、つまり質問分類とoperator plan生成をやめて、全クエリに静的ワークフローを当てる比較版では性能が大きく落ちています。

また、w/o gradient ERでも性能が落ちているため、KGの品質も効いています。
さらに w/o Graph_Reasoning、w/o Text_Reasoningでも低下しており、構造だけ、意味だけ、どちらか片方だけではなく、複数のスコア軸を使うretrievalが効いていることが示唆されます。

要はBookRAGはTreeだけ持てばよいわけでも、KGだけ持てばよいわけでもありません。
Planning / Tree / KG / GT-Link / Reasoning の組み合わせが大事、ということです。

従来手法との対比

ここからは論文の説明を少し砕いて、従来RAGと対応づけます。完全に対応しているわけではなく、理解しやすくするために大雑把に対応付けしているので、その点はご注意ください。

対応表

観点 従来のRAG BookRAG
主な検索単位 chunk Tree node / subtree
検索の手がかり embedding類似度中心 entity + section + filter + graph reasoning
構造情報 メタデータ寄り 検索の土台そのもの
グラフ ない or 補助 KGが主役の1つ
出典対応 弱い GT-Linkで明示的に保持
ワークフロー 固定 query typeごとに動的

共通点

もちろんBookRAGもRAGなので、以下の点は共通です。

  • オフラインで索引を作る
  • オンラインでrelevantな証拠を取得する
  • 最後にLLMが回答を生成する

つまり大枠は通常のRAGと同じですが、索引の作り方と検索の組み方が大きく違います。

実際にAWSで動かすならどうなりそうか

ここからはBookRAGをAWS上に実装するなら、というイメージです。実際に組んで検証までは行っていません。あくまで経験上こうなるだろう、という整理です。

まず役割分担

BookRAGをAWSに実装するなら、役割分担は以下のようになるでしょう。今回は ECS on Fargate を採用した場合のケースです。コンテナ内部で各処理を行うプログラムが入っている想定です。

Bedrock

  • query classification
  • decomposition
  • entity extraction
  • section selectionの補助
  • final answer generation
  • embedding
  • rerank

ECS on Fargate

  • Tree / KG / GT-Linkの構築
  • operator planの解釈と実行制御
  • subtree取得
  • filter実行
  • graph traversal
  • graph reasoning
  • candidate merge / entity resolution

各要素の構成

BookRAGの構成をAWSに当てはめると、たとえば以下のように整理できるでしょう。

オフラインindexing

  • PDF / 規程ファイルをS3に置く
  • ECS/Fargate上のバッチでレイアウト解析
  • Tree構築
  • Bedrockでentity / relation抽出
  • KG / GT-Link構築
  • BookIndexを保存

オンラインQA

  • APIで質問を受ける
  • オーケストレータがBedrockで分類・分解
  • プログラムがBookIndexを探索
  • 必要に応じてrerank
  • Bedrockで最終回答生成

まとめ

BookRAGは「チャンクをどう切るか」の改善というより、複雑文書に対する検索基盤そのものを作り直した手法です。
特に、社内規定や業務マニュアルのように章立て・条件・表・例外ルールが重要な文書群と相性が良いように感じました。

個人的には、BookRAGの面白さはTreeやKG以上に、Planningを前提にしていることだと思います。
構造化しただけで終わらず、質問のタイプに応じてTree / KG / GT-Linkをどう使うか、この設計が論文の性能差につながっていそうです。

また、論文内ではプログラム部分はPythonで実装されていました。実際のプログラムは論文を読むか、参考リンクにあるものを参照いただければと思います。

参考

この記事をシェアする

関連記事

【生成AIプロンプト入門】 RAGをシンプルに理解する
戸田駿太
2025.06.11
【登壇レポート】　「Amazon Bedrockで始めるRAG入門」というテーマで登壇しました
神野 雄大
2026.03.21
AIエージェント開発を体系的に学ぶには最適の入門書「LangChainとLangGraphによるRAG・AIエージェント［実践］入門」
つくぼし
2025.01.13
Bedrock EvaluationsでKnowledge Bases RAGの検索精度を定量評価する - LLM as a Judgeな評価駆動開発
quiver
2025.09.02