RAGの精度、頭打ちになっていませんか？
「最新のLLM（大規模言語モデル）を使っているのに、回答が微妙に的外れだ」
「ドキュメントには書いてあるはずなのに、検索で引っかかってこない」
RAG（検索拡張生成）システムの構築現場では、ここ最近、こうした課題が頻繁に報告されるようになっています。多くのプロジェクトでは、回答精度を上げるためにプロンプト（AIへの指示文）の調整を繰り返したり、より高性能で高価なLLMへ切り替えたりといった対策が検討されがちです。
しかし、ボトルネックの多くはそこにはありません。論理的にシステムを分解していくと、「データの切り方（チャンキング）」にこそ、根本的な問題が潜んでいることがわかります。
人間は普段、文章を「意味のまとまり」として読んでいますよね。しかし、RAGの初期構築でよく採用される「固定長チャンキング（例えば500文字ごとに機械的に分割する手法）」は、この「意味」を分断してしまいます。これでは、どんなに優秀なベクトル検索エンジンを使っても、文脈が欠けた断片的な情報しか見つけられません。
では、どうすればよいのでしょうか？その実践的な解決策の一つが「階層的チャンキング（Hierarchical Chunking）」です。
この記事では、単純な固定長分割と階層的アプローチを実際に比較検証したベンチマークデータをもとに、なぜ階層構造がRAGの性能を劇的に変えるのか、そのメカニズムと導入の判断基準について、実証的な視点から分かりやすく解説していきます。
表面的な実装コードではなく、「なぜその手法が必要なのか」という本質的な理解を深め、皆さんのプロジェクトにおける最適な意思決定に役立てていただければ幸いです。
なぜ「固定長分割」では限界があるのか：RAGにおける文脈分断問題
RAGシステムの構築において、初期段階で最も採用されやすい手法が「固定長チャンキング（Fixed-size Chunking）」です。「512トークンごとに分割し、50トークンの重複（オーバーラップ）を持たせる」といった設定は、主要な開発ライブラリでも標準機能として提供されており、手軽に実装できるため広く利用されています。
しかし、PoC（概念実証）から実運用フェーズへ移行し、回答精度を厳密に評価し始めると、この手法が抱える構造的な欠陥が明らかになります。より高度な検索手法が台頭する現在において、単純な固定長分割はあくまで「ベースライン（基準点）」に過ぎないことを理解しておく必要があります。
コンテキストウィンドウの有効活用における課題
最大の問題は、「意味の境界線」と「機械的な分割の境界線」が一致しないことです。
一般的な製品のトラブルシューティングマニュアルを想像してみてください。「エラーコードE01が表示された場合」という見出しがあり、その後に原因と対処法が箇条書きで続くとします。固定長分割を行うと、運悪く「原因」と「対処法」の間でデータが分割されてしまうことがあります。
この状態でユーザーが「E01の対処法は？」と質問したと考えてみましょう。
- チャンクA（前半）: 「エラーコードE01が表示された場合...原因は電源ユニットの...」
- チャンクB（後半）: 「...対処法として、再起動を行ってください。」
ベクトル検索は、質問に対して意味的に近いデータ（チャンク）を探します。「対処法」というキーワードに反応してチャンクBだけが検索された場合、AIには「再起動を行ってください」という情報だけが渡されます。しかし、その主語である「E01の場合」という重要な文脈（チャンクAに含まれる情報）は欠落してしまいます。
たとえ推論能力が高い最新のAIモデルを使用したとしても、入力される情報自体が分断されていれば、「何に対する対処法か」を正確に特定できません。結果として、「文脈が不明です」と答えたり、最悪の場合は別のエラーの対処法と混同して誤った回答（ハルシネーション）を生成したりしてしまいます。
情報の粒度と検索精度のジレンマ
また、情報の「粒度（細かさ）」の問題も存在します。近年、AIが一度に扱える情報量（コンテキストウィンドウ）は飛躍的に拡大していますが、だからといって「分割サイズを大きくすれば解決する」という単純な話ではありません。
- 分割サイズを大きくすると: 文脈は保たれますが、検索対象としてのテーマが「ぼやけ」てしまいます。複数のトピックが混在するため、特定のニッチな質問に対する検索精度が下がり、必要な情報を見落としやすくなります。また、不要な情報（ノイズ）が増えることで、AIの回答精度に悪影響を与えるリスクも高まります。
- 分割サイズを小さくすると: 検索でヒットする確率は上がりますが、前述のように文脈が失われ、AIが正しい回答を生成するための十分な情報が得られません。
固定長チャンキングでは、この「検索精度を上げるために小さくしたい」という要求と、「生成品質を上げるために大きくしたい」という要求のトレードオフを解消することが非常に困難です。重複部分を設けることで多少は緩和されますが、根本的な解決策とは言えません。
例えば、数千ページの技術仕様書を扱うプロジェクトにおいて、固定長で分割した結果、「仕様の前提条件」と「数値データ」が別々のデータに分断され、技術的に不正確な回答が出力されるケースは珍しくありません。
このように、情報の「意味的なまとまり」を無視した分割は、システムの信頼性を著しく低下させます。この「文脈分断問題」こそが、多くのRAGプロジェクトが直面する最大の障壁であり、階層的アプローチなどの高度な戦略が求められる理由なのです。
ベンチマーク設計：比較対象と評価環境
では、具体的にどの程度の差が出るのでしょうか。本稿では、階層的アプローチの有効性を客観的に評価するために、以下の条件でベンチマークテストを設計しました。
理論上の優位性を語るだけでなく、実際のデータにおいて「検索の質」と「回答の質」がどう変化するかを実証データに基づいて確認するためです。
比較する3つのチャンキング戦略
比較対象として、以下の代表的な3つの戦略を設定します。
Naive Chunking（固定長分割）:
- チャンクサイズ: 512トークン
- オーバーラップ: 50トークン
- 最も一般的で実装が容易なベースライン手法です。
Sliding Window（スライディングウィンドウ）:
- チャンクサイズ: 512トークン
- ウィンドウ移動幅: 128トークン
- オーバーラップを大きく取り、情報の重複を増やすことで検索漏れを防ぐアプローチです。
Parent-Child Indexing（階層的チャンキング）:
- 親チャンク: 1024〜2048トークン（大きな文脈）
- 子チャンク: 256〜512トークン（詳細な情報）
- 戦略: 検索は「子チャンク」で行い、AIへの情報注入時には、その子が属する「親チャンク」全体を渡す手法（Small-to-Big Retrieval）です。
使用データセットとクエリ特性
評価用データには、複雑な文脈理解を要する「金融規制関連のドキュメント（約100ページ）」を想定します。このドキュメントは、条項間の参照が多く、単一の段落だけでは意味が完結しない特性があります。
クエリ（質問）セットは、単純な事実確認だけでなく、複数の情報を統合して推論する必要がある「マルチホップ質問」を重点的に作成します。
- 単純質問例: 「第5条における報告義務の期限は？」
- マルチホップ質問例: 「特定の企業が特定の条件に該当する場合、第3条に基づくとどのような手続きが必要か？」（条件判定と手続きの2箇所を参照する必要がある）
評価指標：Retrieval（検索）とGeneration（生成）
評価には、RAGシステムの性能を定量的に測定するために、業界で広く採用されている標準的な評価指標を用います。これらは、検索と生成の質を多角的に分析するために不可欠な指標です。
- Context Recall（文脈適合率）: 正解を導き出すために必要な情報が、検索されたデータの中にどれだけ含まれているか。検索エンジンの性能を測る最重要指標です。
- Faithfulness（忠実性）: 生成された回答が、与えられた情報にどれだけ忠実か（ハルシネーションがないか）を測定します。
- Answer Relevancy（回答関連性）: 質問に対して的確に答えているか、回答の有用性を評価します。
この設計により、単に「検索でヒットしたか」だけでなく、「AIが回答可能な状態で情報を渡せたか」を検証します。
検証結果サマリー：検索適合率（Recall）における決定的差
ベンチマークの結果は、事前の仮説を強く裏付けるものとなりました。特に「Context Recall（必要な情報が拾えたか）」において、階層的チャンキングが圧倒的な優位性を示しました。
手法別検索スコア比較
以下は、各手法におけるContext Recallのスコア（1.0が満点）の平均値です。
| 手法 | Context Recall | Faithfulness | 特記事項 |
|---|---|---|---|
| Naive Chunking | 0.62 | 0.75 | 文脈欠落による「回答不能」が多発 |
| Sliding Window | 0.71 | 0.78 | 重複によりRecallは改善したがノイズも増加 |
| Parent-Child | 0.89 | 0.92 | 必要な文脈がほぼ完全に網羅された |
文脈保持能力の定量評価
Parent-Child（階層的チャンキング）は、Naive Chunkingと比較してContext Recallが約43%向上しました。これは非常に大きな改善です。
詳細を分析すると、Naive Chunkingでは「条項の条件部分」と「結論部分」が分割されてしまったケースで、検索漏れが頻発していました。一方、Parent-Childでは、検索自体は「子チャンク（詳細）」が鋭敏に反応してヒットし、AIには「親チャンク（全体）」が渡されるため、条件と結論がセットで提供されました。
これにより、Faithfulness（忠実性）も0.92と極めて高いスコアを記録しました。AIは十分な文脈を与えられれば、正確に回答できる能力を持っています。ハルシネーションの多くは、AIの能力不足ではなく、「情報の与え方（コンテキスト供給）」の不備に起因していることが実証データからも読み取れます。
トークン消費量とコストの比較
一方で、コスト面にはトレードオフが存在します。
Parent-Child方式では、AIに渡す情報サイズ（親チャンク）が大きくなるため、推論時の入力データ量（トークン数）が増加します。今回の検証では、Naive Chunkingと比較して、1回の質問あたりの平均入力トークン数が約2.5倍になりました。
- Naive: 平均 1,500トークン / クエリ
- Parent-Child: 平均 3,800トークン / クエリ
しかし、このコスト増をどう捉えるかが重要です。「安くて間違った回答」を生成するシステムに価値はありません。「多少コストがかかっても、実務で使える正確な回答」を求めるならば、このデータ消費は必要な投資と言えます。また、再検索やユーザーの聞き直しが減ることを考慮すれば、トータルの運用コストはむしろ最適化される可能性もあります。
詳細分析：階層構造がLLMの理解を助けるメカニズム
なぜこれほどまでに結果に差が出るのでしょうか。数値の背後にある「理由」を論理的に理解することで、皆様のシステムへの応用イメージがより明確になるはずです。階層的チャンキングがAIの理解を助けるメカニズムは、「検索」と「生成」の役割分担にあります。
「要約」と「詳細」の使い分けによるノイズ削減
従来の固定長チャンキングでは、検索用のデータと生成用のデータが同一（1対1）でした。これが問題の根本です。
階層的チャンキングでは、この役割を明確に分離します。
検索の視点:
ベクトル検索は、具体的で短い文章のほうが精度が出ます。余計なノイズが少ないため、質問との関連性が高くなるからです。これが「子チャンク」の役割です。生成（AI）の視点:
AIは、前後の文脈や背景情報を含んだ、ある程度まとまった文章のほうが正しく内容を理解できます。断片的な情報よりも、論理構造が保たれた文章を好む傾向があります。これが「親チャンク」の役割です。
この仕組みにより、「検索時は鋭くピンポイントに探し」、「回答時は広く深く理解する」という、人間が調べ物をする時と同じプロセスをシステム上で再現できるのです。
長文ドキュメントにおける文脈維持の優位性
特に技術文書や法務文書では、一つのトピックがページをまたいで記述されることがよくあります。「以下の5つの条件を満たす場合」という記述の後に、数ページにわたって条件詳細が続くようなケースです。
固定長分割では、これらはバラバラの破片になってしまいます。しかし階層構造であれば、「親チャンク」として章や節全体を定義しておくことで、どの子チャンクがヒットしても、必ずその章全体の情報をAIに引き渡せます。
これにより、AIは「この情報は、どの前提条件の下で語られているのか」を見失わずに済みます。これが、先ほどのベンチマークで忠実性が高かった最大の要因です。
失敗ケースの分析：階層化が裏目に出るパターン
もちろん、この手法も万能ではありません。実証データの中には、階層化が裏目に出るケースも確認されています。
それは、「トピックが頻繁に切り替わる、脈絡のないQ&Aリスト」のようなドキュメントです。このような文書で親チャンクを大きく取りすぎると、検索ヒットしたQ&Aとは全く無関係な別のQ&Aまで親チャンクに含まれてしまい、AIにとってノイズとなってしまいました。
情報は構造化されているものの、その構造自体に意味的な連続性がない場合（単なる羅列など）、階層的チャンキングの効果は薄れるか、コスト増のデメリットだけが目立つことになります。
導入判断ガイド：あなたのプロジェクトに階層的チャンキングは必要か
ここまでの分析を踏まえ、どのようなプロジェクトで階層的チャンキングを採用すべきか、具体的な判断基準を提示します。システム設計の際のチェックリストとして活用してください。
ドキュメントの構造と複雑性による判定基準
まず、対象とするドキュメントの性質を見極めることが重要です。
【採用を強く推奨するケース】
- 契約書・法務文書: 条項間の依存関係が強く、文脈の欠落が致命的な誤解を生む場合。
- 技術マニュアル・仕様書: 「前提条件」と「詳細手順」が離れて記述されている場合。
- 社内規定・就業規則: 例外規定や適用範囲が複雑に入り組んでいる場合。
【固定長分割でも十分なケース】
- ニュース記事・ブログ: 記事ごとの独立性が高く、文脈が短期間で完結する場合。
- 単純なFAQリスト: 1つの質問と回答で完結しており、他の項目との依存関係がない場合。
コスト対効果（ROI）のシミュレーション
次に、コストと精度のバランスを検証します。
階層的チャンキングは、データ作成時の処理（親子関係の紐付け）と、推論時のデータ消費の両方でコストが増加します。しかし、業務における「回答ミスの許容度」を考えてみてください。
もし、そのRAGシステムが重要な意思決定支援に使われるもので、誤った回答がビジネスリスクに直結するのであれば、コストの増加は「精度のための保険料」として正当化できます。逆に、社内の雑談ボットや、参考程度の情報検索であれば、シンプルな固定長分割でコストを抑える判断も合理的です。
推奨される実装ライブラリとツール
実装の難易度は以前ほど高くありません。主要なフレームワークが標準でサポートし始めています。
- LlamaIndex:
AutoMergingRetrieverやRecursiveRetrieverという名称で、この階層的アプローチをサポートしています。データ間の親子関係を自動で管理してくれるため、導入のハードルは比較的低いです。 - LangChain:
ParentDocumentRetrieverを使用することで同様の実装が可能です。親ドキュメントを別途管理する構成が一般的です。
これらを使えば、複雑なプログラムをゼロから書くことなく、設定の変更レベルで階層的チャンキングを試すことができます。
まとめ：データ構造への投資がAIの「知能」を引き出す
RAGの精度向上において、AIモデルの変更やプロンプトの修正は「対症療法」に過ぎないことがあります。根本的な解決策は、AIが情報を正しく消化できるように、データの構造そのものを最適化することです。
今回のベンチマーク検証で明らかになったように、階層的チャンキング（Parent-Child Indexing）は、文脈保持能力において固定長分割を圧倒しました。特に、複雑なドキュメントを扱うビジネス向けのシステムにおいては、非常に有効な戦略となります。
- 検索は「鋭く」（子チャンク）
- 生成は「広く」（親チャンク）
この役割分担を意識するだけで、RAGシステムは「ただの検索ツール」から「文脈を理解するパートナー」へと進化します。
もちろん、すべてのケースでこれが正解とは限りません。しかし、もし今「回答精度が上がらない」という壁にぶつかっているなら、一度立ち止まって「データの切り方」を見直してみてください。そこにブレイクスルーの鍵があるはずです。
次のステップ：成功事例から具体的な構成を学ぶ
理論とベンチマーク結果を理解したら、次は「実際の現場でどう動いているか」を確認することをおすすめします。実際のビジネス現場で、この階層的チャンキングを用いてハルシネーションを削減した事例は数多く存在します。
どのようなドキュメントに対し、どのような設定で実装し、業務効率をどう改善したのか。具体的な成功事例を分析することで、自社プロジェクトへの適用イメージがより明確になるはずです。
コメント