LLM 向け PDF to Markdown: ChatGPT・Claude・RAG に文書を渡す前の準備
PDF をチャットモデルに貼り付けると、モデルが回答するという意味ではたいてい「動きます」。しかしその裏では、PDF のレイアウトノイズ——折り返された行、繰り返されるヘッダーとフッター、読み順の癖——が token となり、モデルは本文にたどり着く前にそれを見通さなければなりません。
先に Markdown に変換すれば、そのノイズの大半を発生源で取り除けます。この記事では、PDF のノイズがどこから来るのか、token でどれほどのコストになるのか、なぜ 1 行 1 段落がチャンク分割と diff に重要なのか、そしてこのサイトの LLM 最適化出力モードがまさにこのワークフローのために作られていることを説明します。
なぜ LLM は生の PDF に弱いのか
チャットツールが PDF を直接受け付ける場合、まず何かがそれをテキストに変換する必要があり、その「何か」はたいてい手早い汎用の抽出器です。出力には PDF の保存上の痕跡が残ります: 文の途中での改行、両端揃え由来のハイフネーション、毎ページ繰り返されるヘッダーとフッター、保存順に入り交じる段組みテキスト。
モデルはこれを見逃すのが得意なので、直接アップロードは一見うまくいきます。しかしモデルは、コンバーターがそのまま届けられたはずの段落を注意を割いて組み立て直しており、長い文書ではこの無駄が積み重なります。繰り返されるフッターだけでも、純粋な重複として数千 token になることがあります。
構造化テキストは、モデルの引用の拠り所にもなります。回答の根拠となった条項を引用するようモデルに求めるとき、Markdown 変換による条項番号と見出しレベルは安定した目印を与えてくれます。リフローされた PDF テキストの壁には、指し示すものが何もありません。
PDF ノイズの隠れた token コスト
トークナイザーはテキストの断片ごとに課金し、PDF ノイズは断片の塊です。ハードラップされた段落は文字数は同じでも改行が余計にかかり、40 回繰り返されるフッターは重要かどうかにかかわらず 1 ページごとの固定費です。「conver- sion」のようなハイフンで切れた行は、単語にも一致せず意味も持たない断片に分割されることがあります。
無駄は量だけではなく、位置でもあります。コンテキストウィンドウは有限で、先頭のノイズは本文を打ち切り点へと押しやります。きれいな Markdown なら十分に収まる文書が、生の PDF ダンプでは溢れてしまうことがあり、実際に何かが切り捨てられるずっと前から回答品質は低下し始めています。
こうしたことは回答の口調には表れないため、誰も気づきません。表れるのは、モデルが実際に文書のどれだけに向き合ったかという部分と、API で token 課金しているなら請求書の中です。
1 段落 1 行: なぜ折り返しが問題になるのか
従来のテキストツールは、端末や印刷ページがそう動いていたため、72 桁や 80 桁で出力をハードラップします。モデルに渡す Markdown ファイルでは、そうした折り返しの一つひとつが、改行や段落長で分割する検索パイプラインの潜在的なチャンク境界になります。
1 行の段落はチャンク分割を自明にします。段落がそのまま 1 行であり、スプリッターは空行で切れ、すべてのチャンクに完全な文が入ります。ハードラップされたテキストでは、同じパイプラインがまず折り返しを元に戻す必要があり、それをしなければチャンクは文の途中で切れ、検索品質はデバッグしにくい形で低下します。
行ベースの diff も同じ恩恵を受けます。契約書の改訂で 1 つの条項が変わったとき、1 行 1 段落のファイルは変更行をちょうど 1 行だけ示します。折り返されたファイルでは段落の残りがリフローし、本当の変更が十数個の diff ハンクに埋もれてしまいます。
コンパクトプロファイルの実際
このサイトのコンバーターには、明示的な LLM 最適化トグルがあります。有効にすると 2 つのことが起きます。PDF エンジンがコンパクト抽出プロファイルで動作し、レイアウト忠実な冗長さよりも素直で引き締まったテキストを優先すること。そして Markdown ライターがハードラップを無効にし、すべての段落を 1 行にすることです。
コンパクトプロファイルは別のトレードオフであり、全面的に優れているわけではありません。レイアウト忠実モードはページの視覚構造をより多く再現します。これは編集のために変換する人間の読者が望むものです。コンパクトモードはその装飾を削ぎ落として内容と構造だけにします。これは token ストリームが望むものです。
このトグルが影響するのは Markdown 出力だけで、それは意図的です。HTML・RST・LaTeX の出力先は、どのみち再折り返しを行うレンダラーが消費します。出力先がモデルならトグルをオンにした Markdown のままに、人間ならデフォルトのほうが読みやすいでしょう。
Markdown を RAG パイプラインに流し込む
検索拡張生成(RAG)はチャンク品質で成否が決まります。Markdown はパイプラインに、PDF には決してできないものを与えます。構造的な境界がそのまま意味的な境界であることです。見出しはトピックを示すので、スプリッターはセクションごとにチャンクを切り、見出しの経路をメタデータとして付けられます。表は完全なパイプテーブルブロックとして到着し、一つの単位として embedding を通り抜けます。
実用的なレシピはあえて退屈なものです。各 PDF を 1 行 1 段落の Markdown に変換し、サイズ上限を設けて見出しで分割し、各チャンクに見出しパスを保持させて、embedding する。整形された Markdown ファイルに対しては、どのステップも一行で書けます。生の PDF に対しては、どれも脆弱なヒューリスティックになります。
バッチ変換は、対話的な利用よりもここでこそ重要です。ナレッジベースは数十から数百の文書であり、このツールはブラウザ内で直列に変換して結果をダウンロード用にまとめます。途中にアップロードの段階がありません。文書がアップロードできない種類のものであるほど、この点の重みが増します。
なぜ変換は自分のマシンで行うべきか
人々が LLM に渡す文書は、契約書、取締役会の議事録、未公開の研究、顧客ファイルと、不釣り合いなほど機密性が高いものです。それらをクラウドコンバーターに渡すことは、保持ポリシーを自分で書いていない第三者をデータフローに加えることであり、ドラッグ&ドロップの手軽さは、これがアップロードである事実を覆い隠します。
このコンバーターは、PDF 解析エンジンを WebAssembly としてブラウザのタブ内で実行します。ファイルはブラウザのファイル API で読み込まれ、メモリ内で処理され、ローカルに書き出されます。変換経路にサーバーコンポーネントは一切ありません。ページを読み込んでからネットワークを切断しても、変換は動き続けます。
この設計上の選択は、このツールが LLM ワークフローに特に適している理由と同じものです。モデルのために文書を準備する目的は、往々にして誰がそれを見るかを自分で管理することだからです。アップロードするコンバーターは、その一歩手前で目的を裏切ることになります。
留意すべき限界
スキャン PDF にはテキストレイヤーがなく、どんな変換プロファイルもそれを変えられません。元がスキャンなら、まず OCR ソフトウェアに通し、その OCR 出力を変換してください。このコンバーターは、抽出可能なテキストのないページを、黙って空っぽの結果を返すのではなく、明示的にフラグを立てます。
複雑な表は簡略化されて到着します。GFM のパイプテーブルはセルの結合や多段ヘッダーを表現できないため、モデルが見るのは平坦化された版です。表こそが本体という表中心の資料では、下流の回答を信用する前に、何行かを原本と照合してください。
そして、このトグルは抽出そのものの品質ダイヤルではありません。コンパクトモードが変えるのはレイアウトの再現度であり、文字認識の正しさではありません。変換結果が文字化けした場合、問題はプロファイルではなく元ファイルのエンコーディングにあります。