この論文は何を問題にしているか

社内の文書を検索して LLM に答えさせる仕組み、いわゆる RAG（検索拡張生成）[4]は、多くの組織で試されている。その品質を左右するのは、モデルより手前の「取り込み」の工程であることが多い。文書を読み取り、意味のまとまりごとに切り分け（チャンキング）、検索できる形で保管する工程である。

ところが社内の文書は形式がばらばらだ。PDF、Word、プレゼン資料、スキャン画像があり、中身は段組み、複雑なレイアウト、細かい表に閉じ込められている。著者らによれば、規則ベースの抽出や OCR は読む順番を壊し、表を平たく潰し、見出しの階層を失う。一方、抽出したテキストを LLM に丸ごと読ませて切り分けさせる「エージェント的チャンキング」は、トークンの費用がかさみ、原文にない内容を作ってしまう危険がある。

この論文は、形式の違いを吸収しつつ、費用と作り話の危険を抑えた取り込み方を提案している。

何を提案しているか

提案の芯は「まず全部を PDF にそろえ、切り分けでは原文を書き直さない」である。D-RAC は、著者らが以前に出した W-RAC[2]を任意の文書形式に広げたものである。

手順は三段に分かれる。第一に、どんな形式の文書もいったん PDF に変換する。著者らは、ほぼすべての形式に忠実で決定的な PDF 表示があることを利用する、と説明している。第二に、描画したページをマルチモーダル LLM に一度だけ通し、検索向けの Markdown に変換する。このとき表は、単独で意味が通る文章に書き換え、見出しの階層は保つ。第三に、切り分けは W-RAC と同じやり方で行う。Markdown を決定的に解析して ID 付きの単位に分け、LLM には本文ではなく ID の並びだけを見せて、どこで区切るかを計画させる。

切り分けの段階では原文を再生成しない。これにより、W-RAC の利点とされる費用の低さ、結果の再現性、処理の追跡しやすさを保つ、と著者らは主張している。

何を示したか

abstract に書かれている結果は次の範囲にとどまる。RAG-Multi-Corpus ベンチマークのうち、五つの業務領域にまたがる 236 文書、795 ページの PDF 部分集合で評価した。D-RAC はこの全体を 72 分で変換・分割し、エラーは出ず、検索に使えるチャンクを 1,748 個作った。

最先端の LLM によるエージェント的チャンキングと比べると、チャンキング段階の出力トークンは 95.7% 減った。チャンキングの費用は、GPT-4.1 の価格で 77.8%、Gemini 2.5 Pro の価格で 85.6% 下がり、チャンキングの時間は 75% 短くなったという。500 ページを超える文書にも、処理量に比例する形で対応できるとしている。

この論文は査読を経ていないプレプリントであり、ここに書いた結果は著者らの主張の範囲にある。

具体例で見る

ある部門が、社内の手順書や過去の報告書を検索できる仕組みを作ろうとしている。手順書は Word、報告書はスキャンした PDF、研修資料はプレゼン形式である。

抽出したテキストを LLM に切り分けさせる

形式ごとに抽出ツールを使い分け、出てきたテキストを LLM に読ませて、意味のまとまりに書き直させる。表の数値が抽出の段階で崩れたり、LLM が要約の途中で原文にない表現を足したりしても、どこで起きたかを追いにくい。文書が増えるほど費用も増える。

PDF にそろえ、ID で切り分けを計画させる

全文書を PDF にしてから、ページ単位で Markdown に変換する。切り分けでは、LLM は ID の並びを見て区切りを決めるだけで、本文は書き換えない。どのチャンクがどの ID から来たかを後から追える。ただし、表を文章に書き換える変換の段階では LLM が本文を生成している。

右側の進め方で原文の書き換えが起きないのは、切り分けの段階に限られる。変換の段階の正確さは別に確かめる必要がある。この区別を押さえておくことが、導入を判断するときの要点になる。

何が新しくないか／限界はどこか

文書を PDF にそろえる、ページ画像をマルチモーダル LLM で Markdown にする、構造を保ってから切り分ける、という要素はどれも既に実務で使われている。切り分けの方法は W-RAC そのままであり、D-RAC の追加分は前段の正規化と変換にある。著者ら自身、D-RAC を W-RAC の拡張と位置づけている。

限界として最も大きいのは、評価の中身である。abstract に示されているのは処理時間、エラーの有無、チャンク数、トークン・費用・時間の削減であり、検索の精度や最終的な回答の品質がどうなったかは示されていない。費用が下がっても検索の質が落ちていれば、実務上の意味は薄い。abstract の範囲では、この点の条件が示されていない。

次に、表を「単独で意味が通る文章」に書き換える工程は、LLM が本文を生成する工程である。数値の転記ミスや解釈の誤りが入りうるが、その正確さをどう確かめたかは abstract からは読み取れない。比較対象もエージェント的チャンキングに限られ、規則ベースの取り込み方との検索品質の比較は示されていない。評価も一つのベンチマークの部分集合で、著者らは W-RAC と同じグループである。

この主題が今なぜ話題になっているか

集計時点で、この論文は Hugging Face の Daily Papers で 35 の upvote を集めていた。GitHub の star は 0 で、公開リポジトリは確認できなかった。upvote は読む人の関心を示す話題性の指標であり、手法の正しさや有効性を示すものではない。

今回の収集では、同じ問いを扱う独立した論文の束は見つからず、束の大きさは 1 だった。主題として立ち上がったというより、一本の論文が目を引いた状態に近い。キーワードには chunking、ingestion、markdown、multimodal、enterprise が並ぶ。

それでも関心を集める理由は想像しやすい。RAG を試した組織の多くが、モデルの選定より取り込みの工程でつまずいている。表や段組みの多い業務文書をどう扱うかは、実務者に共通の悩みであり、費用の削減を具体的な割合で示した点が目を引いたと考えられる。

製薬・規制の現場から見ると何が接続するか

製薬企業の文書は、この論文が想定する「異種の業務文書」の典型である。SOP、治験実施計画書、治験薬概要書、申請資料、品質関連の記録は、形式も書式もさまざまで、表が多い。社内検索や問い合わせ対応に RAG を使う試みでは、取り込みの品質がそのまま回答の品質を決める。

この論文から持ち帰れるのは、「どの工程で原文が書き換わるか」を区別して記録するという考え方である。切り分けで原文を再生成しない設計は、回答の根拠を元の文書までたどる上で有利に働く。一方、表を文章に書き換える工程は生成であり、用量や規格値のような数値が含まれる文書では、変換結果を元の表と突き合わせる確認が欠かせない。

規制に関わる用途で使うなら、変換の正確さの検証、変換に使ったモデルの版の記録、元文書と変換結果の対応づけが必要になる。abstract はこれらに触れていないため、導入を考える側が独自に確かめることになる。

まとめ

D-RAC は、あらゆる形式の文書を PDF にそろえ、マルチモーダル LLM で Markdown に変換し、原文を書き換えずに切り分けるという取り込み手順を示したプレプリントである。著者らは、エージェント的チャンキングに比べて費用と時間を大きく減らしたと主張している。ただし検索や回答の品質は abstract に示されておらず、表を文章にする変換の正確さも確かめられていない。費用の話だけで判断せず、どこで生成が起きるかを見極めて読むのがよい。