開発解説
表が多いPDFをRAGで扱う前に何を確認する?行列の崩れを先に見る

目次
PDFをRAGへ追加できたのに、表について質問すると答えが崩れることがある。
そのとき、最初から生成モデルの性能だけを疑うのは早い。表が検索用データへ変換される途中で、行と列の対応が崩れていないかを先に確認する。
図: 処理や設定の流れを1枚に整理。実際の操作条件は本文で確認する。
まず代表的な表を3つ選ぶ
文書内のすべての表を一度に調べる必要はない。壊れ方が異なりそうな表を3つほど選ぶ。
たとえば、
- 列数が少ない単純な表
- 見出しが複数行にまたがる表
- 結合セル、注記、単位などを含む表
を選ぶと確認しやすい。
原PDFと抽出後の文字を並べ、次を見る。
- 列見出しと値の対応が残っているか
- 行の途中に別の列の値が混ざっていないか
- 単位や注記が対象の値から切り離されていないか
- 元のページ番号や表名へ戻れるか
文字を抽出できたことと、表の意味が残ったことは別
PDFから文字列を取り出せても、表としての意味まで残るとは限らない。
たとえば抽出結果が、
2025
10
20
30
のように数字だけ並んでいた場合、元の列見出しとの関係が失われていれば、後段のモデルだけで正しく復元するのは難しい。
必要ならMarkdown、CSV、構造化JSONなど、行と列の関係を残しやすい形式を比較する。
ただし、「CSVだから必ず正しい」「JSONなら最適」と形式名だけで決めず、実際の代表表を変換して確認する。
文書を分割するときも表をばらばらにしない
表の見出しと値が別々の文書片へ分かれると、検索時に片方しか取れないことがある。
表全体、または意味が保てる行のまとまりを一つの単位として扱えるか確認する。
さらに、後から原表へ戻れるよう次のような情報を残す。
元ファイル:
ページ番号:
表名:
章・節:
検索結果だけを見ても、どの表のどの位置から来た情報か分からない状態は避ける。
代表表ごとに質問を作る
選んだ3表について、答えが原表で分かっている質問を作る。
たとえば、
- この行のこの列の値は何か
- 最大値はどれか
- 注記まで含めると条件は何か
といった質問だ。
回答文だけを見て採点せず、
- どの文書片が検索されたか
- その文書片に必要な行・列が残っているか
- 元PDFの表では何と書かれているか
まで戻って確認する。
大量に索引化する前に抽出方法を決める
代表的な3表の時点で行列関係が崩れているなら、大量のPDFを索引化してからモデルや検索設定を調整しても原因を追いにくい。
先に抽出形式や分割方法を直し、表の意味が検索用データへ残っていることを確認してから文書全体へ広げる方がよい。
画像だけのスキャンPDFで文字そのものを抽出できていない場合は、スキャンPDFをローカルRAGで使う前のOCR手順から確認できる。
まとめ
- PDFから文字を抽出できても、表の行と列の関係まで正しく残るとは限らない
- 簡単な表・複数行の見出しがある表・結合セルや注記がある表などを原PDFと見比べる
- 検索用に分割するときも、ページ番号や表名など原表へ戻るための情報を残す
- 回答だけを採点せず、検索された文書片と原表まで戻って確認する
公式サイトで次に進む
この記事で明示的に扱うソフトだけを表示します。配布・手順は各公式ページで確認してください。
Ollama
local-gen.jpがファイルを配布するものではなく、互換性を保証するものでもありません。
この記事で扱ったデータ
モデル・GPU・実行ソフトの確認済みデータを、記事とは別に確かめられます。