airagllmindexing
RAGのチャンク分割とインデックス設計チェックリスト｜検索精度を上げる実務（2026）
|
5 min read
RAGの品質はchunkingとindexingで決まる。構造ベース分割、chunkサイズ/overlap、メタデータとフィルタ、重複除去、再インデックス方針まで、取り回せるチェックリストに落とし込む。
目次
- 結論（Conclusion）
- 背景（Explanation）
- 実務手順（Practical Guide）
- 手順1：retrievalの“単位”を決める（5分）
- 手順2：構造ベースで分割する（15分）
- 手順3：chunkサイズとoverlapを意図して決める（10分）
- 手順4：フィルタに効くメタデータを付ける（10分）
- 手順5：重複除去と正規化（10分）
- 手順6：再インデックス方針を決める（10分）
- 手順7：retrieval品質を測る（10分）
- 落とし穴（Pitfalls）
- チェックリスト（Checklist）
- FAQ
- 1) chunkサイズは結局どれが正解？
- 2) overlapは多いほど良い？
- 3) ぐちゃぐちゃなretrievalの最速改善は？
- 内部リンク（Internal links）
- 免責
RAGのretrievalを良くするchunking/indexingの決め方（embedding以前の話）
結論（Conclusion）
RAGの品質問題の多くは retrieval の問題。 chunking と indexing は「検索が何を見える状態にするか」を決める。
実務で外しにくいデフォルト：
- 文字数より 構造（見出し/セクション） で分割
- chunkは自己完結（定義が欠けない）
- 強いメタデータ（doc_id/section/updated_at/tenant）
- フィルタを強く（tenant、権限、プロダクト領域）
- 再インデックスはポリシー化（気分でやらない）
やらないと「間違ったchunkが勝つ」が起きる。
背景（Explanation）
chunkingは「500 tokens」にする作業ではない。 ユーザーの質問とチャンクの単位を揃える作業。
悪い設計で起きること：
- 関係ないchunkが上に来る
- 文脈が分断（定義が別chunkにある）
- 重複テキストがretrievalを支配
- 古いポリシーが新しいdocに勝つ
- tenant分離がメタデータで担保できず事故る
目的は：
- recall（正しいdocを拾う）
- precision（ノイズを拾わない）
実務手順（Practical Guide）
手順1：retrievalの“単位”を決める（5分）
まず1つだけ答える。
- 取りたいのは「段落」か「セクション」か「全文書」か
ルール：
- 引用して見せたい単位にchunkを合わせる
手順2：構造ベースで分割する（15分）
優先：
- Markdown見出し
- HTMLセクション
- PDFページブロック（タイトル付き）
構造がない場合のみ固定サイズへ。
おすすめ：
- セクション分割
- ただし最大token上限あり
- continuity用に小さなoverlap
手順3：chunkサイズとoverlapを意図して決める（10分）
目安：
- 知識docなら 300〜800 tokens/chunk
- overlap 30〜100 tokens
ルール：
- 小さすぎる → 文脈不足
- 大きすぎる → ノイズ混入
手順4：フィルタに効くメタデータを付ける（10分）
最低限：
- doc_id（安定）
- chunk_id
- source_type（wiki/ticket/upload）
- updated_at
- tenant_id / org_id
- access labels（role/team）
- product_area / tags
ルール：
- メタは保存するだけでなく、retrievalで強制する
手順5：重複除去と正規化（10分）
よくある問題：ボイラープレートが多い。
- nav/footerノイズ除去
- 繰り返し免責文の集約
- 近似重複の検出（canonicalを1つ残す）
手順6：再インデックス方針を決める（10分）
明文化する：
- いつ再embeddingするか（更新時/夜間バッチ）
- 削除がどう反映されるか
- 古いchunkが残る最大期間
最小：
- trustedは更新時に即re-index
- untrustedは隔離 + 遅延index
手順7：retrieval品質を測る（10分）
計測：
- 小さなevalセットでtop-k hit rate
- 低スコアクエリの割合
- top-k内の重複chunk比率
ログ：
- retrieved_doc_ids + chunk_ids
- scores
- 適用したfilters
測れないものは改善できない。
落とし穴（Pitfalls）
- 構造があるdocを固定サイズで切る（セクションが壊れる）
- tenant/権限フィルタが弱い（セキュリティ事故）
- 重複除去なし（ボイラープレートが勝つ）
- 削除反映なし（古い答えが残る）
- embedding調整に逃げて、フィルタ/重複が放置される
チェックリスト（Checklist）
- [ ] retrieval単位（段落/セクション/文書）を定義した
- [ ] chunkingは構造優先（見出し/セクション）
- [ ] chunkサイズとoverlapが文書化されている
- [ ] 全chunkに doc_id + chunk_id がある
- [ ] メタに tenant_id と権限ラベルがある
- [ ] retrievalでメタフィルタを強制している
- [ ] 重複/ボイラープレートを減らしている
- [ ] 再インデックス方針（更新/削除）が明文化されている
- [ ] untrustedは隔離/遅延index
- [ ] retrievalログにdoc_id/chunk_idとscoreが残る
- [ ] evalセットでtop-k hit rateを追っている
FAQ
1) chunkサイズは結局どれが正解？
構造ベースが正解。数値が必要なら500 tokens付近から始め、hit rateと引用UXで調整。
2) overlapは多いほど良い？
NO。多すぎるとtop-kが重複で埋まる。小さくして測る。
3) ぐちゃぐちゃなretrievalの最速改善は？
tenant/権限/プロダクト領域の強いフィルタ + 重複除去。embedding調整より効くことが多い。
内部リンク（Internal links）
免責
一般的なエンジニアリングガイドです。