RAGパイプラインの品質は、検索アルゴリズムよりも前段のPDF読み取りで決まります。読み取り順序を誤ったパーサーは、表を壊し、見出しを取りこぼし、誤ったテキストをそのまま索引化します。エラーは出ないまま静かに劣化するため、後工程のどんな工夫も手遅れになります。
今日は、複数の技術記事が示すPDFパーサー比較の実測値と、その手前にある「なぜ抽出が壊れるのか」という問題を掘り下げます。
Nutrientの実測が示す読み取り順序と処理速度の差
Nutrient Blogは、オープンソースのPDFパーサーとホスト型解析APIを、opendataloader-benchという公開ベンチマークで比較しています。200件の実際のPDFに人手で正解のMarkdownを付けたコーパスを使い、Apple M3 Ultra(ディスクリートGPUなし)で、固定バージョンを指定した対象パーサーを走らせた結果です。ただしOpenDataLoader hybridの数値はこの固定バージョン実行では計測されておらず、上流の公開リーダーボードに掲載された値を参照しています。スコアは0から1で、高いほど良いとされています。処理時間はページあたりの秒数で、低いほど良いという指標です。
この実測で明確な差が出たのが、読み取り順序を測るNIDというスコアと、処理速度です。かみ砕いて言えば、NIDは「本来の文章の並び順をどれだけ正しく復元できたか」を測る指標で、これが低いパーサーは段組みや表を読んだときに文章がバラバラの順番で出力されてしまいます。標準版のNutrient CLI(バージョン1.3.0)はNID 0.93というスコアで、この実測の中では最も高い値でした。速度面では、同じCLIが1ページあたり0.004秒で処理できています。対して、同じ実測の中で最も遅かったDocling(バージョン2.110.0)は1ページあたり0.549秒でした。
この処理速度の差を物差しにすると、単純計算でNutrient CLIはDoclingの約137倍の速さでページを処理していることになります。出典記事はこの差について、大量の文書を再インデックスする際に「一晩で終わるか、週末をまるごと使うか」を分けると説明しています。つまり日常的な処理時間の違いというより、チャンク化戦略を変えるたびに全件を再処理する場面で、この速度差が響いてくるという話です。
ただし出典記事は、速度だけを追う判断を明確に否定しています。読み取り順序を落とすパーサーは、遅くても順序を保つパーサーより劣るという評価軸を示し、両方を同じコーパスで測ってから、実際に再処理する文書量に対してインジェストの設計をすべきだと述べています。速さと正確さは別軸で、どちらかだけを見て選ぶものではないということです。
もう一つ実測が明らかにしているのは、パーサーの適用範囲の線引きです。標準版のCLIはOCRを実行しない設計で、テキストがすでに埋め込まれている「born-digital」なPDFにしか向いていません。スキャン文書や画像を含むPDFには、別のNutrient Data Extraction APIが用意されており、こちらはOCRを実行し、表・キーバリュー領域・境界・信頼度・ページ文脈を含む空間的なJSONを返す仕組みです。出典記事は、この信頼度スコアについて「未検証の信号として、レビューへ回すページの振り分けに使う」ものだと位置づけています。つまり信頼度が高いからといって、その抽出結果を無条件に正解として扱ってよいわけではないという留保です。
パーサー選びを分ける3つの条件と、精度が壊れる手前の工程
Nutrientの実測記事は、パーサーを選ぶ基準について「ブランドの好みではなく、3つの問いで決まる」と述べています。文書にすでにテキストレイヤーがあるか、チャンカーがMarkdownを求めているか構造化されたJSONを求めているか、そしてファイルをどこで処理してよいか、という3点です。この整理は、テキストPDFと画像PDFを最初に振り分ける発想と重なります。
builderai.toolsが伝えているのは、オープンソースのパーサー(MinerU、Docling、Marker 2など)における層構造の変化です。パーサーは元々、埋め込みテキストの抽出、レイアウト検出、OCRや表構造の認識という3つの層で構成されていましたが、この記事によれば2026年にはレイアウト検出とOCR層が一つの視覚言語モデルへ統合される動きが進んでいます。Marker 2は650Mパラメータの視覚言語モデルSurya 2を使い、レイアウト・OCR・数式をまとめて処理する設計です。同記事はまた、Doclingが公開ベンチマークのolmOCR-Benchで50.3というスコアである一方、born-digitalなPDFに限定すると64.0まで上がる(Marker 2は83.5、MinerUのパイプラインは83.3)という数値を示し、Doclingが「OCRベンチマークで勝つ設計ではない」と説明しています。
parseur.comは視点を変え、ユースケース別の選び方を整理しています。ノーコードでのビジネス自動化、AWSなど既存のクラウド基盤への統合、そしてRAGパイプラインを組む開発者向け、という3分類です。同記事はAdobe AcrobatのAIについても触れ、要約や質問応答はできても、構造化フィールドの抽出やビジネスツールへの自動連携はできないと明確に線引きしています。
llamaindex.aiは、出力形式そのものが精度に影響すると指摘しています。RAGや検索の文脈ではMarkdownが読みやすさとチャンク化のしやすさを両立させ、アプリケーションのロジックにはJSONが向いているという整理です。同記事は「パース後のクリーンアップ作業が多いほど、パイプラインの他の部分に脆いロジックを持ち込みやすくなる」と述べています。
さらに手前の問題として、beekle.jpはGraphRAGの精度が検索アルゴリズムよりも取り込み(抽出)工程で決まると説明しています。同記事が挙げる数値として、ニュース記事から企業間の関係をLLMで自動抽出する取り組みでは、抽出精度は約73%と報告されているとのことです(出典はNTTデータ DATA INSIGHTとされています)。実用に足る水準としつつも、3割近くは誤りうるという読み方であり、どの結果が誤りかは事前に判別できないため、LLMによる抽出は検証を組み込んで初めて使えるという主張です。この記事は、抽出結果を元文書と突き合わせる検証工程と、スキーマ設計や用語辞書のように人が決めるべき部分を省略しないことを、繰り返し強調しています。
用語補足：NID・TEDSスコア
出典記事のNutrient Blogが使うNIDは、PDFから抽出したテキストが本来の読み取り順序をどれだけ保てているかを測る指標です。これは0から1のスケールで、高いほど良いという意味です。ただしこれらは同じコーパス、同じハードウェア条件での比較値であり、別の文書セットや環境で同じ数値が出る保証はありません。出典記事自身も、コーパス・正解データ・評価ハーネスを公開しており、どのチームもそれらを使って評価を再実行できると述べています。つまりこの数値は、鵜呑みにするための結論ではなく、自分たちの文書で再検証するための出発点として読むべき数字です。
編集後記：速度と正確さを同じ土俵で測る発想
今回の実測記事で印象に残るのは、137倍という処理速度の差そのものより、それを「正確さが保たれている前提でのみ意味を持つ差」として扱っている点です。読み取り順序を落とすパーサーが速くても、それは劣るという評価軸を先に固定し、その上で速度の話をしています。RAGパイプラインの導入検討では、まず速度やコストの比較に目が行きがちですが、この記事の構成は逆に、精度の物差しを先に決めてから速度を見るという順番を示しています。自社の文書で再現実験をするなら、この順番自体が参考になりそうです。