LLMと検索パイプラインのためのPDF準備
最終確認
PDFを言語モデルに与えること — 検索拡張生成のため、要約のため、あるいは長いコンテキストウィンドウに貼り付けるだけのため — は、いまや文書を変換する最も一般的な理由の一つです。
同時に、変換品質が最も効き、最も気づかれにくい用途でもあります。検索パイプラインは静かに失敗するからです。変換が悪い文書はエラーを出しません。ただ誤った箇所を返す、あるいは表が壊れた箇所を返すだけで、モデルはそこから自信を持って答えます。
読了 8 分
生テキストの抽出では足りない理由
どのPDFライブラリも数行のコードで文書のテキストを返します。一段組みの社内文書ならそれで十分です。それ以外では足りません。理由は3つあり、いずれも検索精度を損ないます。
第一に読み順です。生の抽出は字形が描かれた順にテキストを返すため、二段組みのページでは段が交互に混ざります。チャンクの半分が無関係な段落を行き来する文の断片となり、ベクトル空間の何にも対応しない点に埋め込まれます。
第二に境界です。見出しがなければ文字数以外に分割の手掛かりがなく、チャンクは文の途中でも表の途中でも切れます。説明の途中から始まるチャンクは単独では理解できません。検索で取り出されるチャンクに求められるのは、まさにその単独での理解可能性です。
第三に表です。生テキストとして抽出された表は、どの列から来たのかを示すものが何もない数値の羅列になります。それを読んだモデルはそれでも質問に答えます。ただし、その答えが誤っているというだけです。
Markdownがパイプラインにもたらすもの
ここでMarkdownが優れた中間形式であるのは、見た目が整っているからではありません。
- 見出しが意味的なチャンク境界を与えるので、チャンクは1000文字の窓ではなく1つの節になります。
- 見出しのパスが各チャンクに文脈を与えます。埋め込み前に「第3章 › レート制限 › バースト時の挙動」を前置きでき、同じ語が節ごとに違う意味を持つ文書で検索精度が測定可能なほど改善します。
- パイプ表は行と列の対応を保つので、取り出された表を読むモデルはどの数値がどの見出しに属するかを判別できます。
- 簡潔です。Markdownは要素あたり数文字の費用で構造を運びますが、HTMLやJSONのレイアウト形式は、モデルに何も伝えないマークアップにトークンを費やします。
- 現行のどのモデルも訓練で膨大な量を見ている形式なので、プロンプトでの説明を必要としません。
チャンク分割の具体
変換済み文書でうまくいくのは、まず見出しで分割し、大きすぎる節の内部でのみサイズ上限に頼る方法です。
大半の文書種別で通用する、おおよその指針は次のとおりです。
| 第一の分割点 | H2。長い節ではH3にフォールバック |
|---|---|
| 目標チャンクサイズ | 500〜1,000トークン |
| 上限 | コンテキストに複数チャンクが収まる範囲 |
| 重複 | 1〜2文。見出し区切りなら不要 |
| チャンク接頭辞 | 文書タイトルと見出しパス全体 |
| 表 | 分割しない。サイズを超えても丸ごと保つ |
表は絶対に分割しない
大半のパイプラインが破る規則です。素朴な分割器は、自分が表の中にいることを知りません。
GFMの表を途中で割ると2つのチャンクができ、どちらも有効な表ではありません。前半はヘッダーと数行を持ち、後半はヘッダーのない行だけを持ちます。後半は無用どころか有害です。数値にラベルがなく、モデルが推測でラベルを付けるからです。
分割前に表ブロックを検出し、目標サイズを超えても各表を丸ごと保ってください。1つのチャンクに収まらないほど大きい表なら、各断片にヘッダー行を繰り返してください。
スキャン文書の位置づけ
スキャンにはテキストがないため、分割すべきものがありません。先に文字認識が必要であり、その出力にはパイプライン側で織り込むべき性質があります。認識は転記ではなく推定だからです。
とくに2点。信頼度はページごとに変動するため、40ページはほぼ完璧で3ページだけ当てにならない、という文書があり得ます。認識工程がページ単位の信頼度を返すなら、それをチャンクのメタデータへ引き継ぎ、確度の低い回答に印を付けられるようにしてください。もう1点、読めなかった語は印を付けられずに脱落します。つまりテキストは流暢で完全に見えながら、エンジンが最も苦戦したもの — 多くは氏名、整理番号、数値 — が欠けています。
誤りに実害が伴う用途では、認識されたテキストは原本と突き合わせるべき手掛かりとして扱い、記録の出典としては扱わないでください。
コーパスをインデックスする前に確認すること
インデックス作成は高価で遅く、やり直しの利かない工程です。先にサンプルへ20分を割く値打ちがあります。互いに性質の異なる5つの文書を変換し、Markdownを読んでください。
- 見出しは筋の通った階層になっていますか。平坦なら分割器に手掛かりがなく、コーパス全体で固定長の窓に逆戻りします。
- 表は生き延びましたか。2つ3つについて、列数を原本と突き合わせてください。
- 多段組みのページで読み順は正しいですか。段の混在は、見れば明らかで、インデックスしたあとでは見えなくなります。
- 空、あるいはほぼ空の変換結果はありませんか。それはスキャンであり、別の経路が要ります。
- 同じ定型文がどの文書にも繰り返されていませんか。繰り返されるヘッダーとフッターはほぼ同一のチャンクとなり、検索結果から実質的な内容を押しのけます。
付随的ではないプライバシーの問題
RAGのコーパスは、組織が第三者に渡したがらない文書からこそ作られます。契約書、社内報告書、顧客記録、未公開の研究などです。
パイプラインのどの工程がそれらの文書をどこかへ送るのか、意識的に決める値打ちがあります。変換工程はその一つである必要はありません。ブラウザ内で動く変換器は、ファイルがすでに存在する端末上で処理するため、変換の段階で関係者が増えることはありません。後続の工程がどうかは別の判断ですが、切り離して判断できる事柄です。