この論文は、企業のあらゆる文書形式(PDF、Word、プレゼンテーション、スキャン)をRAG(検索拡張生成)システムに投入するための新しい前処理手法D-RACを提案している。核心は、すべての文書をまずPDFに標準化し、マルチモーダルLLMの一度の処理で「検索に最適化されたマークダウン」に変換したうえで、テキストを再生成せずに識別子(ID)ベースでチャンキングする点だ。その結果、アブストラクトによればチャンキング段階の出力トークンを95.7%削減し、コストを77.8〜85.6%削減した。
企業が社内ナレッジをチャットボットや検索システムに載せるには、まず文書を細かく分割(チャンキング)して検索可能な断片にする必要がある。ところが現実の企業文書は形式がバラバラだ。PDF、Word、PowerPoint、そして紙をスキャンしたものまで混在している。しかも、その中の情報は複雑なビジュアルレイアウト、複数の段(カラム)に分かれたページ、びっしり詰まった表の中に閉じ込められている。
問題は、こうした文書を機械が「読む順序どおりに」ほどいていくのが非常に難しいという点だ。論文は既存手法の二つの系統いずれにも限界があると指摘する。
一つ目は、ルールベースの抽出やOCR(光学文字認識)。この方式は、まるで新聞紙面を上から下へやみくもになぞるようなもので、読む順序(reading order)を壊し、表を平坦に潰し(flatten)、見出しの階層構造(heading hierarchy)を失ってしまう。2段組みのページを左上から右下へと一直線に読んでしまうと文脈が絡まる、と考えればわかりやすい。
二つ目は、抽出したテキストの上でLLMがすべてよしなに処理する「完全エージェント型チャンキング(agentic chunking)」。品質は上がり得るが、LLMがテキストを書き直していく必要があるため、トークンコストがかさみ、存在しない内容をでっち上げるハルシネーション(hallucination)のリスクも生じる。
まとめると、精度を守ろうとするとコストとハルシネーションが膨らみ、安価なルールベースに寄せると文書構造が崩れる。D-RACはこのジレンマを狙い撃ちにする。
D-RACは、著者らが以前発表したウェブ文書向けフレームワークW-RAC(Web Retrieval-Aware Chunking)を、任意の文書形式へ拡張したものだ。名前のとおり「検索を念頭に置いた(Retrieval-Aware)チャンキング」である。動作を身近なたとえで説明すると、こうなる。
ステップ1、すべての文書をPDFに標準化する。WordだろうとPPTだろうとスキャンだろうと、事実上すべての形式は「忠実で決定論的な(deterministic、つまり毎回同じ結果になる)PDF印刷版」を持つ、という点を活用する。プリンターで出力すればどんなファイルも同じ紙の見た目になるのと同じだ。入力の多様性を、PDFという一つの関門へ集約するのである。
ステップ2、マルチモーダルLLM(文字だけでなく画像・レイアウトも一緒に見るモデル)がレンダリングされたページを一度さらって「検索最適化マークダウン」に変換する。ここでは二つが肝になる。表は前後の文脈がなくてもそれ自体で理解できる「自己完結した文章(self-contained prose)」に書き直す。たとえば「四半期 / 売上」の表の1マスを「2026年第3四半期の売上は…である」のような完結した文にほどいて、のちに断片として切り出されても意味が生き残るようにする。同時に、見出しの階層構造はそのまま保存する。
ステップ3、こうして作ったマークダウンをW-RAC方式そのままでチャンキングする。まず決定論的にパースして「IDで指定可能な単位(ID-addressable units)」に分割する。文書の断片ごとに番号札を貼るようなものだ。次に軽量なLLMが、各断片の短いテキストプレビュー(おおよそ200〜400字)と見出し階層情報を合わせて見て、どの断片をどうまとめるかを計画(chunk planning)する。このとき元のテキストを書き直すのではなく、計画の「出力」を断片の識別子(番号)だけで表現するのが核心だ。図書館の司書が本の中身を丸ごと書き写す代わりに、表紙の要約と分類情報には目を通しつつ、最終的な分類表には請求記号だけを書き込むのと同じである。
この設計の決定的な利点は、「チャンキング中は元のテキストを絶対に再生成しない」という点だ。LLMはプレビューと階層情報を参照しつつも、出力としては番号だけを出すので内容をでっち上げる余地がなく(観測可能性・observabilityを維持)、出力トークンが極めて少ない(低コスト)。ただし、ここで決定論的なのは、マークダウンを断片に分割するパースと、与えられたID計画に従ってテキストを再び繋ぎ合わせる再構成の段階である。どの断片をどうまとめるかを決める計画そのものは依然としてLLMが生成しており(論文の実験もtemperature 0.1を用いる)、IDだけを出力するからといって毎回の実行でチャンク構成が必ず同じになると保証されるわけではない。それでも、W-RACがウェブで享受していた観測可能性と低コストという利点をそのまま保ちながら、「レンダリング可能なあらゆる形式」を一級の入力として受け入れられるようになったのである。
論文はRAG-Multi-CorpusベンチマークのPDFサブセットでD-RACを評価した。このサブセットは五つの企業ドメインにまたがる236文書、795ページ規模だ。アブストラクトが示す数値は次のとおり。
| 項目 | 結果(アブストラクト基準) |
|---|---|
| コーパス全体の変換・チャンキング時間 | 72分、エラー0件 |
| 生成された検索用チャンク | 1,748個 |
| チャンキング段階の出力トークン | 95.7%削減 |
| チャンキングコスト削減 | 77.8%(GPT-4.1価格)〜85.6%(Gemini 2.5 Pro価格) |
| チャンキング時間 | 75%短縮 |
| スケーラビリティ | 500ページ超の文書でも線形(linear)にスケール |
ここでの比較対象は「フロンティアLLMを使ったエージェント型チャンキング」だ。つまり最新の大型モデルでよしなにチャンキングする方式と比べたとき、D-RACは出力トークンを20分の1程度まで削りながら、795ページのコーパスをエラーなしで処理した、というのが核心的な成果である。コストがGPT-4.1基準で約5分の1、Gemini 2.5 Pro基準で約7分の1まで下がったという点は、大規模な文書を扱う企業にとってすぐに体感できる削減だ。
「線形にスケール」という表現も重要だ。文書が500ページを超えても処理時間がページ数に比例して増えるだけで、急激に爆発しないという意味である。数千ページにおよぶマニュアル・契約書・規程集がありふれた企業環境において、予測可能なコスト構造を提供する。
アブストラクトだけで判断するなら、いくつかは正直に指摘しておくべきだ。
ONTLEは「AIプロジェクトマネージャー派遣型SaaS」として、小規模企業や個人起業家の反復業務を肩代わりすることを目指している。そうしたプロダクトにおいて社内文書を扱うRAGは、すなわち「AIが会社の資料を正確に読んで答える」ための土台だ。D-RACのアプローチは、まさにこの点で実用的な示唆を与えてくれる。
第一に、入力形式の多様性を「PDF標準化」という一つの関門で吸収する発想は、顧客企業ごとにWord・Excel・PPT・スキャンが入り混じる現実によく合う。形式ごとに別々のパーサーを作って保守する負担を減らせる。
第二に、「チャンキング中はテキストを再生成しない」という原則は、コストと信頼性の両方に意味がある。AI PMのように反復的に大量の文書を処理しなければならないプロダクトでは、出力トークンを減らせば運用費が下がり、まとめた結果が新しく書いた文章ではなく断片番号として残れば「なぜこの断片がこうまとめられたのか」を追跡しやすくなる(観測可能性)。顧客に根拠を説明しなければならない業務ツールであればあるほど、この観測可能性は品質と同じくらい重要だ。
第三に、表を自己完結した文章にほどいておく戦略は、検索品質に直結する。実際の業務文書の核心的な情報は表に集中していることが多いが、断片に切られても意味が生き残る形で保存しておけば、回答の根拠引用が安定する。
ただしONTLEの視点から見ても、先の限界はそのまま有効だ。最終的な検索・回答品質の指標は本文で別途確認する必要があり、マークダウン変換段階の精度は導入前に自社の文書で小規模な検証(パイロット)をしてみるのが安全だ。コスト削減の数値は印象的だが、自分たちのデータでの再現は別問題だ、という姿勢が正しい。
Word・PPT・スキャンなど形式がバラバラでも、ほぼすべての形式は「忠実で毎回同じ結果になるPDF印刷版」を作れるからです。入力の多様性をPDFという一つの関門に集めれば、形式ごとに別々の処理ロジックを作る必要なく、以降の段階を統一できます。
アブストラクト基準で、フロンティアLLMを使ったエージェント型チャンキングと比べてチャンキング段階の出力トークンを95.7%削減し、チャンキングコストをGPT-4.1価格基準で77.8%、Gemini 2.5 Pro価格基準で85.6%削減し、チャンキング時間は75%短縮しました。
D-RACはチャンキング段階で元のテキストを再生成しません。LLMは各断片の短いテキストプレビュー(おおよそ200〜400字)と見出し階層情報を参照しますが、計画の出力は断片に付いた識別子(番号)だけで表現するため、内容を新たに書き下ろしながらハルシネーションを起こす余地が減ります。ただし、どの断片をどうまとめるかを決める計画そのものはLLMが生成するので(実験もtemperature 0.1を使用)、毎回の実行でチャンク構成が完全に同一だと保証されるわけではありません。また、その手前のマークダウン変換段階は依然としてマルチモーダルモデルの理解に依存します。
アブストラクトが提示した数値は主にチャンキング段階のコスト・速度・処理の安定性です。表を自己完結した文章にほどき、見出し階層を保存する設計は検索に有利になるよう意図されていますが、最終的な検索・回答品質についての具体的な数値はアブストラクトに明記されていないため、本文の詳細な評価を確認する必要があります。