RAGの精度が上がらないとき、多くの現場で最初に疑われるのはモデルです。
しかし実際には、ボトルネックは「チャンク設計」にあることが少なくありません。
本記事では、chunk size・overlap・embedding次元数を数値で評価しながら改善する方法を整理します。
チャンクサイズはRecallで決める
「とりあえず512トークン」にしていないでしょうか。
この瞬間に私は少し身構えます。
主張
チャンクサイズはLLMの都合ではなく、検索Recallで決めるべきです。
根拠
RAGの第一段階は「正しい文書を上位k件に入れられるか」です。
チャンクが小さすぎると文脈が分断され、Embedding空間上で意味が弱くなります。
大きすぎるとノイズが増え、類似度が希釈されます。
具体例
同一データセットで以下を比較します。
- 256 tokens
- 512 tokens
- 1024 tokens
固定クエリセットで top5 recall を測定すると、
- 256 → 0.62
- 512 → 0.71
- 1024 → 0.66
のように山型になるケースは珍しくありません。
示唆
チャンクサイズは「モデルの最大トークン」ではなく、
Recall曲線を引いてピークで決めるのが合理的です。
Overlapは保険ではなく戦略
Overlapを増やせば安心、という設計もよく見ます。
このパターンは本当によく見ます。
主張
OverlapはRecall向上とインデックス肥大化のトレードオフです。
根拠
Overlapを増やすと境界情報の欠落を防げますが、
ベクトル数が増え、類似チャンク同士が競合します。
結果としてPrecisionが落ちる場合があります。
具体例
512 tokensで overlap 0 / 64 / 128 を比較すると、
- 0 → recall 0.68
- 64 → recall 0.72
- 128 → recall 0.73 だが precision低下
というように、一定以上は伸びが鈍化します。
示唆
Overlapは固定値にせず、
チャンクサイズとセットで最適化する対象と考えるべきです。
Embedding次元数は万能ではない
次元が高いほど賢い、という誤解も根強いです。
この誤解が設計コストを押し上げます。
主張
Embedding次元数は精度ではなく「表現密度」の問題です。
根拠
高次元は理論上情報保持力が高いですが、
データ量が少ない場合は空間が疎になり、距離が不安定になります。
いわゆる次元の呪いです。
具体例
同一データで 768次元 と 1536次元 を比較すると、
必ずしも後者が上回るとは限りません。
むしろ小規模コーパスでは差が出ないことも多いです。
示唆
Embeddingモデル選定は
「次元数」よりもドメイン適合性と評価結果で判断すべきです。
テストデータを固定しないと改善は錯覚になる
最も重要なのはここです。
評価データを都度変えている設計を見ると、私は止めに入ります。
主張
RAG改善は固定クエリセットでの継続測定が前提です。
根拠
チャンク設計を変えるたびにテストクエリが変わると、
改善なのか偶然なのか判別できません。
具体例
業務FAQや実問い合わせログから
30〜50件を抽出し、正解文書を人手で紐付けます。
これを回帰テストとして使います。
示唆
RAGはプロンプト調整ゲームではありません。
検索評価基盤を先に作ることが最短ルートです。
RAGの精度改善は、
モデル変更よりも「検索設計の数値最適化」で決まります。
次に見るべき論点は、
・再ランキングの導入
・Hybrid Searchとの比較
・評価指標（MRR / nDCG）の導入です。
構想段階で迷っている場合は、設計レビューから整理するのが早いです。