RAGデータ設計
RAGは前処理で8割決まる — 文書構造に沿ったチャンク設計とデータ整備
RAGの精度の話は、つい検索やモデルに向かいます。けれど現場で最初に効くのは、もっと地味な工程です。文書をどう切り、どう整えてからインデックスに入れるか——前処理です。私たちの実感では、RAGの精度は前処理で8割が決まります。
白状すると、最初のころの私は、文書をとにかく一定の文字数で切ってインデックスに放り込んでいました。多くのツールがそれを既定にしているからです。けれど、そうして生まれるのは、見出しから切り離されて宙に浮いた段落や、途中でぶつ切りになった表でした。検索がそれを拾っても、LLMは正しく答えようがない。この記事は、文書構造に沿ったチャンク設計とデータ整備を、実装者の視点で書きます。全体像はRAG精度の診断ガイドにあり、この記事はその第1層「データ設計」を深掘りするものです。
なぜ固定長のチャンク分割は失敗するのか
実際の業務文書は、表があり、見出しの階層があり、「前項の条件に従い」のように前後の文脈に依存した記述が当たり前にあります。これを文字数で機械的に切ると、答えの半分だけが入ったチャンクや、文脈を失った断片が大量に生まれる。
たとえば、ある業界の規制法令を扱った案件では、これが致命傷になりました。条文には「第◯条の規定により」「前条の例による」といった参照が至るところにあり、固定長で切ると、その参照の係り先が別のチャンクに飛んでしまう。根拠になる条文の片側だけを渡された状態で、まともな回答は作れません（参照でつながった文書を検索でどう辿るかは、別記事法令RAGをGraph拡張で解いた事例に書きました）。
チャンクは、検索がLLMに渡す「素材」です。素材が壊れていたら、その先でどれだけ良い検索をしても、良い回答は作れません。だから切り方は、後段のどの工夫よりも手前で、精度の上限を決めてしまいます。
文書の種類ごとに、切り方を変える
対策はシンプルで、文書の「意味のまとまり」を壊さないように切ることです。1つのチャンクが1つの問いに答えられる単位になっているか——これを基準にすると、切り方は自然と決まります。
面白いのは、この基準に従うと、文書ごとに切り方がまるで変わることです。私たちが手がけた複数の実案件を並べると、それがよく分かります。
- 規格化された文書（業界の規制法令など） — 「条」を単位に切ります。規格が強い文書ほど、それ自身が持つ区切り（条・項・号）が最良のチャンク境界になる。コツは、条を途中で切らないこと、条見出し（括弧書きの見出し）をチャンクの先頭に含めること、短い条はいくつか束ねて薄すぎるチャンクを作らないことです。
- 半定型の文書（社内の週次レポートなど） — 同じ1枚の中でも、セクションごとに粒度を変えます。定型の予定表は横断で見たいので全体をまとめて1チャンクに、自由記述の報告事項は案件単位で引きたいので1件を1チャンクにする。「文書型ごと」よりさらに細かく、「セクションごと」に切り方を決めた例です。
- 非定型の文書（営業の商品資料など） — ページを単位にします。リーフレットやスライドは1ページ1トピックで作られていることが多く、ページ＝チャンクが素直に効く。
3案件に共通するのは、主軸が固定長ではないことです。固定長での分割は、構造をどうしても検出できないときの「最後の手段」か、長すぎる塊をさらに割るための補助として使うだけ。まず構造で切り、足りないところだけ固定長で補う——これが、文書型を問わず私たちが取っている順番です。
メタデータを付ける
チャンクには、本文だけでなくメタデータを添えます。いつの文書か、どの部署のものか、最新版か。メタデータがあると、検索を「最新版だけ」「この部署だけ」と絞り込めるようになり、新旧の取り違えや部署違いの混入を防げます。本文の意味だけで探すベクトル検索の弱点を、メタデータでの絞り込みが補います。あわせて、営業資料のように「このページは導入事例か・見積か・解説か」という"役割"をメタデータに持たせておくと、「導入事例だけ見せて」といった絞り込みにも応えられるようになります。
表は、「2つの表現」で持たせる
前処理でいちばん厄介なのが、表です。ベクトル検索は、行と列で意味が決まる表が苦手で、そのまま埋め込むと精度が出ません。かといって表を捨てれば、肝心の情報が抜ける。
そこで私たちがよく採るのが、1つのチャンクに2つの表現を持たせる方法です。検索に使う版は、表のセルを「いつ・どこで・何を」という自然な文に開いて埋め込む。人が読む版は、元の表（Markdown）をそのまま添えて表示に使う。埋め込みに最適な形と、人が読んで分かる形は違う——だったら両方持てばいい、という割り切りです。
データの衛生 — 古い版・廃止規程を片づける
前処理には、切る作業だけでなく、整える作業も含まれます。内容の重複した古い版を整理し、すでに廃止された規程が混ざっていれば取り除く。表記の揺れや記号を正規化する。たとえば「第三条の二」のような番号を機械が扱える形に揃えたり、PDFで字下げでしか表現されていない階層を復元したり——といった、地味だが効く整えです。
こうした「答えが一意に決まる」整えは、まずルールで解けないかを考えます。正規化や重複除去は、LLMを使わずルールで書けば、ブレず・安く・繰り返し同じ結果になる（この考え方はハイブリッド検索の設計でも通底しています）。ゴミが入っていれば、検索も評価も、その分だけ濁ります。土台のデータをきれいに保つことは、上のすべての層に効きます。
前処理は地味だが、上の層では取り返せない
ここが、この記事でいちばん言いたいことです。精度はモデルより前処理で決まる。前処理は、動いているデモを派手にはしません。だから社内で票が入りにくい。それでも、後段のすべてはこの土台の上に載っています。
けれど、土台が雑だと、検索を工夫しても評価を回しても取り返せません。逆に、土台が整っているほど、上の層の工夫が素直に効く。私たちが要件定義からデータの前処理まで自分たちで手を入れるのは、ここを外注や自動任せにすると、後段のすべてが濁ることを現場で何度も見てきたからです。
データ設計のセルフチェック
- 文字数で機械的に切っていないか。文書構造（条文・見出し・表）に沿って切っているか。
- 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