「RAG を構築したが精度が出ない」 — 原因の 7 割は チャンク分割（splitter）の設計ミスです。本記事では、現場で頻発するチャンク分割の 5 つの落とし穴と、それを潰す評価方法を実装目線で解説します。

結論を先に：「とりあえず 1000 文字で分割」のような雑な設計は RAG 精度を 30-50% 引き下げる主因。チャンクサイズ・分割境界・メタデータ付与・オーバーラップ・評価セット、の 5 軸で設計を見直すことで精度が劇的に改善します。

なぜチャンク分割が RAG の精度を決めるか

RAG は「質問」と「ドキュメントチャンク」のベクトル類似度で検索します。チャンクの単位が悪いと：

  • 関係ない情報が混入 → 類似度が下がる
  • 必要な情報が複数チャンクに分断 → 1 つしかヒットしない
  • 文脈が切れる → 「これは何の話？」状態になる

LLM 自体を高性能（GPT-4o → GPT-4o）に上げても、チャンク分割が悪ければ精度向上は限定的。チャンク分割が RAG 精度の上限を決めるのです。

落とし穴 1: 固定文字数で機械的に分割する

LangChain の標準 CharacterTextSplitter で「1000 文字ごとに切る」設定をそのまま使うパターン。これは 最悪のデフォルトです。

何が問題か

  • 段落の途中、文の途中で切れる
  • 「2 章 第 3 節」のような階層情報が失われる
  • 表が真ん中で分断される

改善

RecursiveCharacterTextSplitter を使い、優先順位付きセパレータ（"\n\n" → "\n" → "。" → " "）で分割。これだけで段落の途中で切れることが激減。

落とし穴 2: 文脈境界を無視した中央切り

Recursive にしてもまだ問題が残ります。例えば「○○手順は以下の通り：①△△ ②□□ ③×× ④...」の途中で切れると、後半チャンクは「○○手順」というキーワードを失います。

改善：セマンティック分割

LangChain の SemanticChunker（Embedding ベースで類似度低下点で分割）、または LLM で意味境界を判断させるアプローチ。コストは上がるが、知識集約型ドキュメント（法律、技術仕様、研究論文）で精度向上が顕著。

落とし穴 3: メタデータを付けない

チャンクをテキストだけで保存すると、後で「どの文書のどの節」が分からなくなります。これが 出典付き回答 を成り立たせない主因。

付けるべきメタデータ

  • source：ファイル名 + パス（クリックで原典に飛べる）
  • section：「2 章 3 節 業務フロー」のような階層
  • chunk_index：同じ文書内での位置（前後参照用）
  • created_at / updated_at：古い情報を後で除外可能に
  • permission_tags：「営業部のみ」「経営層」のようなアクセス制御

pgvector なら metadata は JSONB カラムに格納し、SQL の WHERE 句で同時フィルタ可能。これが pgvector の強み。詳しくは 「ベクトル DB の選び方」 をご参照ください。

落とし穴 4: 表・図キャプションを本文と混ぜる

特に PDF を素朴に text 変換した場合、表のセル内容が本文に混ざり、意味不明なチャンクが大量生成されます。

改善

  • 構造抽出ツール：Adobe PDF Services、Unstructured.io、Azure Document Intelligence で本文・表・図を別オブジェクトとして抽出
  • 表は Markdown / CSV に変換：そのうえで埋め込み生成
  • 図キャプションは独立チャンク：「図 3-1: ○○の構造」とその説明を 1 セット

工数は増えますが、技術仕様書 / 製品マニュアル / 法律文書のような構造化された PDF を扱う案件では必須投資。

落とし穴 5: 評価セットを作らずに精度議論

「なんとなく精度悪い」「Pinecone より pgvector の方が良さそう」のような 感覚論で議論するチームが多い。これは絶対にダメ。

評価セットの作り方

  1. 社内 SME（業務専門家）にヒアリング → 「業務でよくある質問」を 50-500 件収集
  2. 各質問について「正解の出典（どの文書のどの節か）」をペア記録
  3. RAG 実行 → 検索結果 Top-K に正解出典が含まれるかを評価
  4. Recall@5、Recall@10、MRR（Mean Reciprocal Rank）などで定量化

評価セットがあって初めて、「チャンクサイズ 512 vs 1024 どっち？」「pgvector vs Pinecone どっち？」を 数字で比較できます。これが RAG プロジェクトの肝。

推奨される 3 つの分割戦略

戦略 1: シンプル（社内 FAQ など 1 万件以下）

  • RecursiveCharacterTextSplitter（chunk_size=512、overlap=50）
  • メタデータ：source、section、updated_at
  • 適用例：社内マニュアル、FAQ、議事録

戦略 2: 構造化（PDF・契約書・仕様書）

  • Unstructured.io / Azure Doc Intelligence で構造抽出
  • 本文・表・図を別チャンク
  • 階層情報（章・節・項）をメタデータに保存
  • 適用例：契約書、技術仕様書、製品カタログ

戦略 3: セマンティック（高精度要求）

  • LangChain SemanticChunker または LLM ベース境界検出
  • 埋め込み生成コストが 2-3 倍
  • 適用例：法律相談 RAG、医療診断補助、ハイステークスな業務

評価指標と PDCA の回し方

定量指標

  • Recall@K：Top-K 検索結果に正解出典が含まれる確率
  • MRR：正解出典が結果リストの何番目に来るかの平均
  • nDCG：順位を考慮した検索品質指標

定性指標

  • SME による回答品質スコア（5 段階）
  • 「役立たない」とユーザーが報告した割合

PDCA サイクル

  1. P: チャンク戦略 A を実装
  2. D: 評価セットで Recall@5 を測定
  3. C: A vs ベースラインで比較 → 改善 or 改悪 判定
  4. A: 採用 or 別戦略を試す

月 1 回の評価ミーティングで改善ループを回せば、3-6 ヶ月で「使い物になる」精度に到達します。

よくあるご質問

チャンクサイズの目安は？

512-1024 トークンが多くのケースで最適。これより小さいと文脈が切れて意味が失われ、大きいと検索精度が落ちます。RAG 評価セットで複数サイズを試し、最も精度の高いものを採用するのが現実解。

オーバーラップは何 % が良いですか？

10-20% が定番。512 トークンチャンクなら 50-100 トークンのオーバーラップ。これにより、チャンク境界に重要情報があった場合の取りこぼしを防ぎます。20% を超えるとストレージとコストが膨らむ割に精度向上は鈍化。

PDF や複雑なドキュメントはどう分割すべき？

PDF は本文・表・図キャプションを別チャンクとして分けるのが理想。表は CSV / Markdown に変換してから埋め込み生成。Adobe PDF Services、Unstructured、Azure Document Intelligence などの構造抽出ツールが必須。素朴な PDF → text 変換は精度が低くなります。

評価セットは何件用意すべきですか？

最低 50 件、理想は 200-500 件。社内 SME（Subject Matter Expert）に『この質問にはどのドキュメントの何節が答え』をペアで作ってもらいます。これがあって初めて『チャンク戦略 A vs B どっちが良い？』を数字で比較できる。