RAG（Retrieval Augmented Generation）を日本語で実運用しようとしたとき、多くの方が悩むのが 「チャンクサイズ（chunk size）」と「オーバーラップ（overlap）」の最適設定 です。
チャンクサイズとオーバーラップは、RAGシステムの 効率・精度・コスト に直結する重要なパラメータです。特に日本語では言語特性上の考慮点も多く、英語でのベストプラクティスをそのまま適用してもうまくいかない場合があります。
本記事では、日本語RAGシステムにおけるチャンクサイズとオーバーラップのベストプラクティスを整理し、実践的な指針を解説します。
1. チャンクサイズのベストプラクティス
(1) LLMのコンテキストウィンドウとコスト
-
LLMは一度に処理できるテキスト量（コンテキストウィンドウ）が決まっています。
- 例: Gemini 1.5 Pro / GPT-4.1 Mini → 100万トークン
GPT-4 → 40万トークン
Claude 4 → 20万トークン など
- 例: Gemini 1.5 Pro / GPT-4.1 Mini → 100万トークン
-
入力が増えるほどコストが上がり、応答速度も遅くなります。
➡️ 無駄のないサイズ設定がコスト最適化のカギです。
(2) 情報の粒度と理解度
- 小さすぎるチャンク: 文脈が欠落し、断片的な情報しか得られない。
-
大きすぎるチャンク: 不要な情報やノイズが混入し、回答の精度が下がる。
➡️ モデルが理解しやすい粒度を意識する必要があります。
(3) 推奨されるチャンクサイズ
- 実験例（LlamaIndexなど）では 1024トークン が品質と効率のバランスに優れるとされています。
- 一般的には 256〜1024トークン の範囲で調整するのが現実的です。
(4) 日本語特有の考慮点
- 「1トークン ≒ 0.75単語 または 1.5漢字」 と換算できます。
- 例えば 1024トークン ≒ 約680漢字 に相当。
➡️ 日本語では「トークン」ベースで設計しつつ、実際の文量は漢字換算も意識しましょう。
2. オーバーラップのベストプラクティス
(1) 文脈の連続性を確保
チャンク化すると文脈が途切れるリスクがあります。
そのため、チャンク間で一部を重複させるオーバーラップ が有効です。
(2) 日本語での重要性
- 日本語は単語間にスペースがなく、機械的に分割すると文脈を壊しやすい。
- 文や段落の境界で区切りつつ、末尾をオーバーラップ させると、意味の連続性を維持できます。
(3) オーバーラップ量の目安
-
明確な公式値はありませんが、一般的には
チャンクサイズの10〜20%程度 が推奨されます。- 例: 1024トークンのチャンクなら 100〜200トークンをオーバーラップ
3. 高度なチャンク分割戦略（Advanced RAG）
-
段落・章単位の分割: 意味的なまとまりを重視して分割する。
-
ノイズ除去: PDFのヘッダー・フッター・ページ番号などを削除して検索効率を上げる。
-
Small-to-Big Retrieval:
- まず小さなチャンクで検索 → その前後の大きなチャンクを追加で参照
- Amazon Bedrock Knowledge Basesなどが対応済み
4. 最適設定を見つけるには？
- 評価軸: 忠実性（Faithfulness）、関連性（Relevancy）、応答時間、コスト
-
評価ツール: LlamaIndex Response Evaluation、RAGAS、RAGChecker などを活用
➡️ 一度決め打ちせず、必ず実験的に調整・評価することが重要 です。
まとめ
日本語RAGシステムのチャンクサイズとオーバーラップのベストプラクティスは以下の通りです。
- チャンクサイズ: 256〜1024トークンを目安（日本語では約170〜680漢字）。
- オーバーラップ: チャンクサイズの10〜20%を推奨。
- 分割戦略: 文や段落の境界を意識、ノイズ除去を徹底。
- Advanced RAG: Small-to-Big Retrievalなどを必要に応じて導入。
- 評価と改善: 忠実性・関連性・速度・コストを指標に、実験を繰り返して最適化。
日本語は文の区切りが曖昧なため、英語以上にチャンクサイズとオーバーラップの設計が重要です。
最終的には ユースケースに合わせた実験と調整 が最適解となります。