RAGは前処理で8割決まる — 文書構造に沿ったチャンク設計とデータ整備

RAGの精度の話は、つい検索やモデルに向かいます。けれど現場で最初に効くのは、もっと地味な工程です。文書をどう切り、どう整えてからインデックスに入れるか——前処理です。私たちの実感では、RAGの精度は前処理で8割が決まります。

白状すると、最初のころの私は、文書をとにかく一定の文字数で切ってインデックスに放り込んでいました。多くのツールがそれを既定にしているからです。けれど、そうして生まれるのは、見出しから切り離されて宙に浮いた段落や、途中でぶつ切りになった表でした。検索がそれを拾っても、LLMは正しく答えようがない。この記事は、文書構造に沿ったチャンク設計とデータ整備を、実装者の視点で書きます。全体像はRAG精度の診断ガイドにあり、この記事はその第1層「データ設計」を深掘りするものです。

なぜ固定長のチャンク分割は失敗するのか

実際の業務文書は、表があり、見出しの階層があり、「前項の条件に従い」のように前後の文脈に依存した記述が当たり前にあります。これを文字数で機械的に切ると、答えの半分だけが入ったチャンクや、文脈を失った断片が大量に生まれる。

たとえば、ある業界の規制法令を扱った案件では、これが致命傷になりました。条文には「第◯条の規定により」「前条の例による」といった参照が至るところにあり、固定長で切ると、その参照の係り先が別のチャンクに飛んでしまう。根拠になる条文の片側だけを渡された状態で、まともな回答は作れません（参照でつながった文書を検索でどう辿るかは、別記事法令RAGをGraph拡張で解いた事例に書きました）。

チャンクは、検索がLLMに渡す「素材」です。素材が壊れていたら、その先でどれだけ良い検索をしても、良い回答は作れません。だから切り方は、後段のどの工夫よりも手前で、精度の上限を決めてしまいます。

文書の種類ごとに、切り方を変える

対策はシンプルで、文書の「意味のまとまり」を壊さないように切ることです。1つのチャンクが1つの問いに答えられる単位になっているか——これを基準にすると、切り方は自然と決まります。

面白いのは、この基準に従うと、文書ごとに切り方がまるで変わることです。私たちが手がけた複数の実案件を並べると、それがよく分かります。

• 規格化された文書（業界の規制法令など） — 「条」を単位に切ります。規格が強い文書ほど、それ自身が持つ区切り（条・項・号）が最良のチャンク境界になる。コツは、条を途中で切らないこと、条見出し（括弧書きの見出し）をチャンクの先頭に含めること、短い条はいくつか束ねて薄すぎるチャンクを作らないことです。
• 半定型の文書（社内の週次レポートなど） — 同じ1枚の中でも、セクションごとに粒度を変えます。定型の予定表は横断で見たいので全体をまとめて1チャンクに、自由記述の報告事項は案件単位で引きたいので1件を1チャンクにする。「文書型ごと」よりさらに細かく、「セクションごと」に切り方を決めた例です。
• 非定型の文書（営業の商品資料など） — ページを単位にします。リーフレットやスライドは1ページ1トピックで作られていることが多く、ページ＝チャンクが素直に効く。

3案件に共通するのは、主軸が固定長ではないことです。固定長での分割は、構造をどうしても検出できないときの「最後の手段」か、長すぎる塊をさらに割るための補助として使うだけ。まず構造で切り、足りないところだけ固定長で補う——これが、文書型を問わず私たちが取っている順番です。

公開の比較も同じ向きです。36通りの切り方を5つの埋め込みモデルで比べた2026年3月の研究では、段落をまとめて切る方式が最も良く（nDCG@5で約0.459）、固定の文字数で切る方式は0.244未満でした（Shaukat et al., 2026）。NVIDIAの検証でも、5種の評価データの平均でページ単位の切り方が最も正確でした（NVIDIA, 2025）。一方、文の埋め込みの変わり目で切る「意味分割（セマンティックチャンキング）」は、計算の手間に見合う一貫した上積みが確認されていません（Qu et al., NAACL 2025 Findings）。

切ったチャンクの先頭には、どの文書のどの見出しの下にあったかを書き足します。文書名と見出しの経路（例:「経費規程＞第3章 旅費＞第12条（日当）」）を付けておくと、見出しから切り離された段落でも、何の話かが検索に伝わります。前後の文脈を学習した埋め込みモデルも出てきており（Voyage AI, 2025）、先頭に書き足すだけで足りなければ次の候補になります。なお、切り方や先頭に付ける情報を変えると類似度スコアの出方も変わるので、足切りの値は引き直します（ハイブリッド検索の設計）。

ノーコードのDifyで作っている場合、画面の区切り記号の設定では、条文単位のような構造に沿った分割は作れません。どこまでDifyのチャンク設定で直り、どこから外で切って入れるかはDifyでRAGの精度が出ないときに書きました。

メタデータを付ける

チャンクには、本文だけでなくメタデータを添えます。いつの文書か、どの部署のものか、最新版か。メタデータがあると、検索を「最新版だけ」「この部署だけ」と絞り込めるようになり、新旧の取り違えや部署違いの混入を防げます。本文の意味だけで探すベクトル検索の弱点を、メタデータでの絞り込みが補います。あわせて、営業資料のように「このページは導入事例か・見積か・解説か」という"役割"をメタデータに持たせておくと、「導入事例だけ見せて」といった絞り込みにも応えられるようになります。

取り込みの段で持たせておきたいのは、ページとページ内の位置、版、有効期間（いつからいつまで有効か）、書き手です。ページと位置があれば回答の根拠を該当箇所まで示せ、有効期間があれば改定前の版を検索から外せます。書き手は安全にも効きます。数百万件の知識ベースでも、狙った質問1問につき細工した文書を5件混ぜるだけで、攻撃の成功率が90%に達したという報告があります（Zou et al., USENIX Security 2025）。公式の文書と利用者の投稿は、インデックスを分けて持つのが安全です。

表は、「2つの表現」で持たせる

前処理でいちばん厄介なのが、表です。ベクトル検索は、行と列で意味が決まる表が苦手で、そのまま埋め込むと精度が出ません。かといって表を捨てれば、肝心の情報が抜ける。

そこで私たちがよく採るのが、1つのチャンクに2つの表現を持たせる方法です。検索に使う版は、表のセルを「いつ・どこで・何を」という自然な文に開いて埋め込む。人が読む版は、元の表（Markdown）をそのまま添えて表示に使う。埋め込みに最適な形と、人が読んで分かる形は違う——だったら両方持てばいい、という割り切りです。

PDF・スキャンの読み取りを、別の工程として測る

切る前に、文書を正しく読めているかという工程があります。テキストを持つPDFなら文字を取り出せますが、スキャンした資料や表・図の多い資料では、読み取りの誤りがそのまま検索と回答の誤りに連鎖します。読み取りの誤りがRAGに与える影響を測ったICCV 2025の研究は、評価したどの読み取り手法も、RAGの知識ベースを作るには十分でなかったと結論しています（Zhang et al., ICCV 2025）。

読み取りの道具も変わりました。レイアウト検出・文字認識・表の認識を別々の部品でつなぐ方式から、文書の読み取りに特化した10億パラメータ前後の小型モデルがページを読む方式が主役になりつつあります（MinerU2.5・PaddleOCR-VLなど）。商用でも、ブロックごとの位置と、ページ・語ごとの確信度を返すものがあります（Mistral OCR 4）。確信度の低い箇所だけを人が確かめる、という品質チェックの工程を組めます。

道具を選ぶときは、公開ベンチマークの順位より、自社の文書30〜50ページでの答え合わせを優先します。表のセルの値・読む順番・数値が合っているかを1ページずつ確かめる、地味なテストです。評価セットでも、スキャンや表から作った質問は分けて集計しておくと、外れたときに原因が検索ではなく読み取りにあると切り分けられます（評価セットの作り方）。日本語の読み取りモデルには非商用ライセンスのものもあるので、業務で使う前にライセンスを確かめます。

データの衛生 — 古い版・廃止規程を片づける

前処理には、切る作業だけでなく、整える作業も含まれます。内容の重複した古い版を整理し、すでに廃止された規程が混ざっていれば取り除く。表記の揺れや記号を正規化する。たとえば「第三条の二」のような番号を機械が扱える形に揃えたり、PDFで字下げでしか表現されていない階層を復元したり——といった、地味だが効く整えです。

こうした「答えが一意に決まる」整えは、まずルールで解けないかを考えます。正規化や重複除去は、LLMを使わずルールで書けば、ブレず・安く・繰り返し同じ結果になる（この考え方はハイブリッド検索の設計でも通底しています）。ゴミが入っていれば、検索も評価も、その分だけ濁ります。土台のデータをきれいに保つことは、上のすべての層に効きます。社内の検索窓が「使われない」原因をたどると、このデータ衛生に行き着くことが多い——という話はエンタープライズサーチとはにも書きました。

文書が更新されたときは、正規化したテキストのハッシュ値を比べて変わった文書だけを見つけ、その文書だけを読み直して埋め込み直します。古い版は消さずに有効期間を閉じて残しておくと、「いつの時点の規程で答えたか」を後から辿れます。

前処理は地味だが、上の層では取り返せない

ここが、この記事でいちばん言いたいことです。精度はモデルより前処理で決まる。前処理は、動いているデモを派手にはしません。だから社内で票が入りにくい。それでも、後段のすべてはこの土台の上に載っています。

けれど、土台が雑だと、検索を工夫しても評価を回しても取り返せません。逆に、土台が整っているほど、上の層の工夫が素直に効く。私たちが要件定義からデータの前処理まで自分たちで手を入れるのは、ここを外注や自動任せにすると、後段のすべてが濁ることを現場で何度も見てきたからです。この前処理が構築全体のどこに位置するか——手順0〜5の設計図はRAG構築の手順にまとめています。

よくある質問

チャンクは何文字で切ればよいですか。

文字数から決めない、というのがこの記事の答えです。条・見出し・段落・ページといった文書の区切りで切り、長すぎる塊だけを固定長で割ります。公開の比較でも、段落をまとめて切る方式やページ単位の切り方が、固定の文字数で切る方式を上回っています。文字数で決めるのは、構造を検出できない文書に対する最後の手段です。

セマンティックチャンキング（意味分割）は使うべきですか。

優先度は低いと考えています。文の埋め込みの変わり目で切る意味分割は、計算の手間に見合う一貫した上積みが確認されていません（NAACL 2025 Findings）。同じ手間は、見出し・段落で切ることと、文書名と見出しの経路をチャンクの先頭に付けることに回すほうが効きます。

スキャンしたPDFや表の多い資料は、どう取り込めばよいですか。

読み取りを独立した工程として扱い、自社の文書30〜50ページで表のセルの値・読む順番・数値を答え合わせしてから道具を決めます。表はセルを文に開いた版と元の表の2つを持たせ、読み取りの確信度が低い箇所は人が確かめます。表や図が主役の資料では、ページを画像のまま引く検索を補助の経路として足す方法もありますが、日本語の公開ベンチマークは乏しく、自社の文書での評価が要ります。

データ設計のセルフチェック

• 文字数で機械的に切っていないか。文書構造（条文・見出し・表）に沿って切っているか。
• 1つのチャンクが、1つの問いに答えられる単位になっているか。
• 文書名・見出しの経路をチャンクの先頭に付けているか。
• スキャンや表の読み取りを、自社の文書で答え合わせしたか。
• ページ・位置・版・有効期間・書き手をメタデータに持っているか。
• 古い版・廃止規程・重複を整理しているか。
• 正規化や重複除去を、LLMではなくルールで固めているか。

データの土台から、見直しませんか

「答えの半分しか入っていない」「表がバラバラになる」「古い規程で誤答する」という症状が出ているなら、原因は前処理にあるかもしれません。いまの文書の種類と構成を聞かせていただければ、どう切り、どう整えると効くか、当たりをつけてお伝えします。前処理を含む全体像はRAG精度の診断ガイド、データ整備から積み上げた事例は商社の文書検索事例で読めます。

参考文献

• Gao et al. (2023) Retrieval-Augmented Generation for Large Language Models: A Survey — arXiv:2312.10997
• Lewis et al. (2020) Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS — arXiv:2005.11401
• Shaukat et al. (2026) A Systematic Investigation of Document Chunking Strategies and Embedding Sensitivity（査読前） — arXiv:2603.06976
• NVIDIA (2025) Finding the Best Chunking Strategy for Accurate AI Responses — developer.nvidia.com
• Qu, Tu & Bao (2025) Is Semantic Chunking Worth the Computational Cost?, Findings of NAACL 2025 — ACL Anthology
• Zhang et al. (2024) OCR Hinders RAG: Evaluating the Cascading Impact of OCR on Retrieval-Augmented Generation, ICCV 2025 — arXiv:2412.02592
• Zou et al. (2024) PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language Models, USENIX Security 2025 — arXiv:2402.07867
• Voyage AI (2025) voyage-context-3 — blog.voyageai.com
• Mistral AI (2026) Mistral OCR 4 — mistral.ai