導入：ここまでの連載の整理
これまで本連載では、テキストchunkingの限界について触れてきました。
PDFというファイルはテキストファイルではなく、段組み・表・図版・ページ跨ぎといった構造を持つため、単純なテキスト分割では意味単位が壊れやすいという背景があります。
そこで、LlamaParseを用いて「復元」ではなく「整形」を前提としたパースを行い、構造を保持したまま扱う方針について整理してきました。
さらに、構造化RAG（Structure-Aware RAG）という考え方を軸に、
- PDF取得
- 構造を壊さないパース
- 構造前提のchunk設計
という流れで、PDFを前提としたRAGの設計を段階的に整理してきました。
しかしここまでの整理で、まだ一つ空白が残っています。
LlamaParseによってMarkdown化された構造はあくまで「整形された状態」であり、
- どこが一つの意味単位なのか
- ページを跨ぐ表はどう扱うのか
- 図と本文の関係はどう保持するのか
といった、構造の最終確定までは行われていません。
本記事では、この空白を埋めるために、「構造を壊さず確定する工程」をどのように設計するかを整理します。
その中で、補助的なアプローチとしてVision-Guided Chunking（VGC）をどの位置で使うべきかを 構造化RAGの文脈から接続していきます。
それでも壊れる構造
ここまでの連載では、LlamaParseによってMarkdown構造を整形し、その構造を前提としたchunk設計を行う方針について整理してきました。
しかし実務上、Markdownまで整形してもなお、構造が成立しないケースが存在します。
例えば次のようなものです。
- 表がページを跨いでいる
- 続き文が次ページにある
- 2段組レイアウト
- 図中に埋め込まれたテキスト
- 図と本文の参照関係
- 手順書の途中分断
これらは、Markdownとして整形されていても意味単位として確定できない構造です。
つまり「Markdown整形 = 構造確定」ではないという問題が残ります。
補助アプローチとしてのVision-Guided Chunking
こうした構造崩壊を扱うためのアプローチとして、Vision-Guided Chunking（VGC）という手法が提案されています（arXiv:2506.16035）。
VGCは、従来のテキストchunkでは取りこぼされやすいレイアウトや視覚要素を含む構造情報を保持しながら、意味的に一貫したチャンクへ再構成するために、マルチモーダルLLM（LMM）でPDFをバッチ処理するアプローチです。
ただし、本連載では全文をVGCで処理する前提には立ちません。
基本はMarkdown構造を前提とし、「構造が成立しない箇所のみ補助的にVGCを適用する」という立ち位置で扱います。
VGCの処理の考え方（概念）
VGCでは、文書を複数ページ単位のグループとして扱い、LMMにまとめて読み込ませます。
代表的な流れは以下のようなものです。
- （論文では例として）一般に4ページ程度のバッチでグルーピング
- 前グループとのcontext継承
- continuation flagによる接続判定
これはテキストchunkにおける「overlap + 継続判定」に近い役割を持ちます。
ただし、LMMに自由に分割させるのではなく、chunk生成エンジンとしてプロンプト設計を行う点が重要です。
VGCのプロンプト設計の要素
VGCでは以下のようなルールを組み合わせてchunk生成を行います。
- 抽出ルール
- 構造ルール
- 特例ルール（表・手順）
- 継続判定ルール
- 出力フォーマット
これらを制御することで、ページ跨ぎや視覚構造を含めた意味単位の再構成を行います。
論文では、この設計により従来のテキストchunkingと比較して精度が大きく改善したと報告されています。
構造確定という工程
ここまでで見てきた通り、Markdownまで整形された文書であっても、意味単位として確定できない構造が残るケースが存在します。
そのため、RAG前処理には「どこまでを一つのchunkとして扱うかを確定する工程」が必要になります。
本連載では、この工程を構造確定工程として位置付けます。
VGCの役割の位置付け
VGCは、視覚構造やページ跨ぎの関係性を扱うことができる強力なチャンク生成アプローチです。
ただし、本連載の設計では、全文をVGCで処理する前提には立ちません。
構造化RAGは論理構造（見出し・段落・意味単位）を主導とし、
VGCは視覚構造（配置・図表・ページ跨ぎ）を補助する役割として扱います。
つまりVGCは、文書全体のチャンク生成手法というより、構造が確定しない箇所を再接続するためのモジュールとして位置付けます。
VGCを常用しない設計という選択
Vision-Guided Chunkingは、LMMを用いて文書を解析し、構造を保持したままチャンク生成を行う強力なアプローチです。
一方で、その構成上、LMM推論を前提とするため、文書量が増えるほど前処理コストが増加します。
特にPDFなどの長文ドキュメントを大量に扱う場合、全文をVGCで処理する構成では、チャンク生成段階のコストが無視できない水準になる可能性があります。
構造化RAGでは、LlamaParseによる整形にも一定のコストは発生しますが、
- Markdown主体の分割
- 必要箇所のみVGC
という設計を取ることで、LMM推論回数を抑えつつ、構造保持とコストのバランスを取ることができます。
本連載では、この観点から、「VGCを常用するのではなく、構造が成立しない箇所に限定して適用する」という設計を採用しています。
これはVGCの有効性を否定するものではなく、どこに適用するかを設計するという観点からの判断です。
本記事で採用する接続案（設計方針）
ここまでの整理を踏まえると、全文をVGCで処理するのではなく、まずはMarkdownベースで構造を確定できる範囲を最大化し、成立しない箇所のみをVGCで補助する構成が現実的です。
本記事では、この考え方を次のようなパイプラインとして整理します（以降、この流れを前提に議論します）。
※これはあくまで「設計方針」であり、文書タイプや要件（コスト/精度/レイテンシ）により最適解は変わります。
構造検査の設計
構造確定工程では、LlamaParseで生成されたMarkdownをそのままchunk化するのではなく、「意味単位として成立しているか」を検査する必要があります。
本記事では、構造検査を以下のような軽量なルールベースで設計します。
完全な自動判定を目指すのではなく、「壊れている可能性が高い箇所を検知する」というスタンスを取ります。
- 見出し境界ルール
基本単位は、見出しブロックとします。
H2 / H3
├ 見出し
├ 本文
├ 表
└ リスト
これらを1ブロックとして扱い、見出し単位で意味が閉じているかを確認します。
検査条件例
- 見出し直後に本文が存在するか
- 見出しだけで終わっていないか
- 見出し下の要素が別ページで分断されていないか
- 見出し配下の表・手順が途中で切れていないか
- 箇条書き・手順の途中切れ検知
箇条書きや手順は、途中でchunkが切れると意味が崩壊しやすい要素です。
検査条件例
-
- や「-」が連続している途中で終了
- 「次ページへ続く」系
- 最後が読点・接続詞で終わる
- 番号が途中で終わる
- Markdown table崩れ検知
Markdown化された表でも構造が壊れているケースは非常に多いです。
検査条件例
- ヘッダ行のみ存在
- 行数が極端に少ない
- 列数が途中で変わる
- 次ページに続いている可能性
- 軽量検査という設計思想
構造検査は完璧に判断するための工程ではありません。
目的は「VGCが必要そうな箇所を検知すること」です。
そのため本記事では
- 100%正確な検査は目指さない
- ルールベース
- 低コスト
という設計を採用します。
- VGC発動対象の考え方
上記の検査で、
- 見出し配下の構造が閉じない
- 手順が途中で切れる
- 表がページ跨ぎ
- 図参照が分断
といったケースが検出された場合、そのブロックをVGCによる再接続対象とします。
本記事では、全文をVGCで処理するのではなく、構造が成立しない箇所のみ適用するという設計を前提とします。
まとめ
本記事では、Markdown整形後に残る「構造未確定領域」をどのように扱うかを整理しました。
構造化RAGでは、まず論理構造ベースで意味単位を確定し、成立しない箇所のみを視覚構造補助（VGC）で再接続するという設計を採用します。
全文をVGCで処理するのではなく、必要箇所に限定して適用することで、
- 構造保持
- コスト
- 運用性
のバランスを取ることが可能になります。
参考文献
本記事で補助的に扱った「Vision-Guided Chunking」に関する論文はこちらです。
本記事は論文の再現を目的としたものではなく、構造化RAGの設計文脈の中で「どの位置で使うべきか」を整理することを目的としています。
Discussion