RAGを社内展開したあと、精度の頭打ちを最初に招くのはチャンキング(文書分割)とリランキング(再スコアリング)の設計です。ここを詰めずに埋め込みモデルだけを差し替えても、検索の当たり外れは大きく変わりません。
一方で、チャンク幅の最適値やリランカーの必要性は業務データによって振れます。この記事では、方式比較・運用指標・撤退条件までを、検索精度を上げるための判断軸として整理します。
RAGのチャンキングとリランキング設計｜検索精度チューニングの判断軸(2026年下期版)
画像: Generated by OpenAI via Codex
この記事でわかること
- チャンキングとリランキングが検索精度のどこに効くか
- 固定長・意味単位・階層型など主要チャンキング方式の使い分け
- クロスエンコーダ型と大規模モデル型リランカーの判断軸と限界
- 導入前チェックリストと運用開始後に見る指標
- 採用しないほうがよい条件と、Blackfordの実務視点
結論サマリー｜まず見る指標と次の行動
| 読者の課題 | 最初に見る指標 | 確認すること | 次の行動 |
|---|---|---|---|
| 検索で拾えない文書が多い | Recall@k、無回答率 | 文書分割の粒度と重複が適切か | チャンク幅と重複幅を再設計する |
| 上位候補に業務外の文書が混ざる | Precision@k、上位一致率 | 語彙検索と埋め込み検索を併用しているか | ハイブリッド検索とリランカーを検討する |
| 回答が事実からずれる | 幻覚率、根拠一致率 | 上位nの中に正解が含まれているか | リランカーで上位を再スコアリングする |
| 費用と遅延が想定より重い | 1問合せ単価、p95遅延 | 常時リランキングが必要な用途か | 軽量リランカー併用か対象絞り込みへ切替 |
※LLM関連サービスの料金、データ保持条件、提供機能は変更される場合があります。導入前に公式情報で最新条件を確認してください。
基本説明｜用語と対象範囲
| 用語 | 意味 |
|---|---|
| チャンキング | 文書を検索単位に分割する処理。粒度・重複幅・境界の設計を含む |
| 埋め込みモデル | 文書と質問をベクトルに変換するモデル |
| リランキング | 埋め込み検索の上位候補を、質問との関連度で再スコアリングする処理 |
| ハイブリッド検索 | 語彙検索(BM25等)と埋め込み検索を組み合わせる方式 |
| Recall@k / Precision@k | 上位k件に正解が含まれる割合と、上位k件の的中率 |
対象は、社内文書検索・ナレッジQ&A・業務RAGアシスタントなど、継続的にコーパスと質問が増える用途です。単発のデモや小規模PoCは対象外とします。
なぜ今このチューニングが重要か
RAGの本番展開が広がった2026年、社内コーパスは増え続け、初期の分割設計のままでは精度が落ちる例が増えています。
- 契約書や規程は長文で構造が深く、単純な固定長分割で文脈が切れる
- 議事録やチャット履歴は短文が多く、逆に細かすぎて意味が薄まる
- 上位候補が業務外文書に埋もれ、生成LLMの選択が甘くなる
主要ベクトルDBはフィルタとハイブリッド検索を強化し、埋め込みモデル側もリランカーとの分業を前提にしたモデル群を出しています。
ここで「モデルを新しくすれば精度が上がる」という前提は成立しにくくなっています。分割とリランキングの設計を運用で回すことが、精度と費用の両立に効きます。
チャンキング方式の判断軸
概要比較(方式ごとの向き不向き)
| 方式 | 一言でいうと | 向くケース | 注意点 |
|---|---|---|---|
| 固定長分割 | 文字数/トークン数で機械的に切る | 短文の議事録、チャット、単純FAQ | 長文の文脈が切れやすい |
| 意味単位分割 | 段落・見出し・文の境界で切る | 規程、契約、マニュアル | 見出し欠落文書で粒度が揺れる |
| 階層型分割 | 見出しと本文を親子で保持する | 手順書、社内Wiki、複数階層文書 | 実装が重く、DBスキーマ設計が必要 |
| 質問単位分割 | 予想質問ごとに要約を作る | FAQ整備が進んだ用途 | 作成コストが高く、更新運用が必要 |
実務判断向けの比較
| 比較軸 | 確認すること | 実務上の意味 |
|---|---|---|
| チャンク幅 | 単位(文字/トークン)と中央値、上位分布 | 幅が広いと文脈は残るが埋め込みが薄まる |
| 重複幅 | 前後何%(または何トークン)を重ねているか | 少ないと境界情報が落ち、多いと索引が膨らむ |
| メタデータ | 出典、部署、公開範囲、更新日を保持しているか | 権限フィルタと最新性判定に直結する |
| 前処理 | 目次・ヘッダ・フッタ・改ページを除去しているか | ノイズが埋め込み類似度を歪める |
粒度の設計は、質問長と回答長の分布を先に確認してから決めます。1問合せの平均長が短ければ細かめ、長文の要約用途なら広めに寄せます。
リランキング方式の判断軸
概要比較
| 方式 | 一言でいうと | 向くケース | 注意点 |
|---|---|---|---|
| クロスエンコーダ型 | 質問と候補文をペアで採点する専用モデル | 上位候補の絞り込み、費用と遅延の抑制 | 対応言語と最大入力長を確認する |
| 大規模LLM型 | 生成モデルに関連度を判定させる | 業務用語が特殊、判定基準が複雑 | 呼び出し費用と遅延が大きい |
| ルールベース | 更新日・部署・タグで再ソートする | 権限・鮮度・優先度が明確な用途 | 意味的な近さは補正できない |
| ハイブリッド併用 | BM25と埋め込みのスコアを結合する | 固有名詞・型番・略語の照合が多い用途 | 重み調整と評価データの整備が必要 |
実務判断向けの比較
| 比較軸 | 確認すること | 実務上の意味 |
|---|---|---|
| 上位k | 生成に渡す前に何件まで残すか | 大きすぎると幻覚要因、小さすぎると欠落 |
| 遅延 | 追加遅延(ms/秒)と全体p95 | 対話用途では体感品質を左右する |
| 費用 | 1問合せあたりのリランカー費用 | 常時実行か対象限定かの判断根拠になる |
| 言語対応 | 日本語・英語・混在文書での精度 | 業務コーパスに合うかを試験で確認する |
リランカーは万能ではありません。分割設計が不十分な状態で上位を並べ替えても、そもそも候補集合に正解が入っていなければ効きません。
実装・運用で確認すべき項目
導入前チェックリスト
- 質問と回答のサンプルが50〜200問揃っているか
- 出典・部署・公開範囲・更新日のメタデータを保持できているか
- 語彙検索と埋め込み検索のスコアをログに残せているか
- 権限フィルタが検索段階で効くか(生成段階だけに寄せない)
- 上位k件と生成前の入力長制限が仕様として決まっているか
運用開始後に見る指標
| 指標 | 意味 | 使い方 |
|---|---|---|
| Recall@k | 上位k件に正解が含まれる割合 | 分割・埋め込み・ハイブリッド設定の善し悪しを判定 |
| Precision@k | 上位k件の的中率 | リランカー導入の効果測定 |
| 無回答率 | 「わからない」で返した割合 | 検索側の欠落と生成側の抑制を切り分け |
| p95遅延 | 応答遅延の95パーセンタイル | 常時リランキングの必要性を判断 |
| 1問合せ単価 | 埋め込み・リランカー・生成の合計 | 対象絞り込みと軽量モデル併用の判断 |
採用しないほうがよい条件
- コーパスが数百件で、質問も限定的な用途
- 業務ルール検索など、決定的な条件抽出のほうが適する用途
- 更新頻度が低く、静的FAQで足りる用途
- 評価データが用意できず、効果測定が担保できない状態
リスクと限界
- 分割設計のミスは、埋め込みやリランカーの上位改善では取り戻しにくい
- リランカー導入で費用と遅延が上がるため、対象を絞る運用設計が要る
- 大規模LLM型リランカーは、判定理由がブラックボックス化しやすい
- 語彙検索側の辞書やシノニム整備が不十分だと、固有名詞に弱くなる
- 権限・鮮度・機密区分のメタデータが欠落すると、業務用途では致命的
指標や運用設計を伴わないチャンク幅の一律変更は、精度の再現性を損ないます。A/B比較の前後で評価データを固定し、変更の影響を可視化することが前提です。
Blackfordの見解
RAGの検索精度は、モデル選定ではなく文書設計と運用ループで決まります。分割とリランキングは、後戻りが最も面倒な工程です。
設計段階から、次の5点を分けて考えることを推奨します。
- 文書ライフサイクル: 作成、更新、廃止、権限、鮮度をメタデータで管理する
- 検索経路: 埋め込み、語彙、リランキング、権限フィルタの順序を明文化する
- 評価データ: 業務ユーザーが継続的に追加できる仕組みを先に作る
- 費用配分: 常時リランキングにするか、対象を絞るかを月次で見直す
- 運用責任: 検索側と生成側の担当を分け、指標を共通に持つ
RAG基盤の構築と運用ループ整備は、Blackfordのデータ基盤・MLOps支援で相談できます。
社内データの棚卸しから設計に踏み込む場合はDataRoid、既存クラウドやオートスケール設計を含む継続運用はDataRoid Cloudで確認できます。
関連コラムでは、ベクトルデータベース選定ガイド、埋め込みモデル比較、RAG精度評価と運用を参照できます。
よくある質問
Q. チャンク幅は何トークンにすべきですか？
A. 目安として、対話用途で400〜800トークン、長文要約用途で1000〜1500トークンから始める例が多いです。重複幅は10〜20%程度が起点です。ただし、質問長と回答長の分布で最適値は動くため、評価データで比較してから決めます。
Q. リランカーは全質問に必要ですか？
A. いいえ。上位候補にばらつきが大きい用途や、業務用語が特殊な用途に絞ると費用対効果が上がります。定型FAQや権限で切り分け可能な検索では、リランカーなしで十分な場合があります。
Q. ハイブリッド検索は必ず併用すべきですか？
A. 固有名詞や型番、略語が多いコーパスでは効きやすい傾向があります。逆に、意味的な言い換えが中心のコーパスでは、単独の埋め込みで足りることもあります。評価データでの比較を推奨します。
Q. 中小企業でもリランカー導入は現実的ですか？
A. 対象を絞れば現実的です。全質問に大規模LLM型を常用するのではなく、上位候補が近接した場合や、業務クリティカルな問合せに限定する運用が実務的です。
Q. 更新頻度が高い文書はどう扱いますか？
A. 分割時のメタデータに更新日と有効期間を持たせ、リランキング段階で鮮度を加味します。旧版と新版の同時ヒットを避けるため、廃止フラグを検索側で除外することが重要です。
まとめ
RAGの精度は、モデルの新しさよりも分割・検索・再スコアリングを運用で回せているかで決まります。まず質問と回答の分布を確認し、分割方式・重複幅・メタデータを整えた上で、リランカーの導入判断に進むと再現性が上がります。
導入判断や運用ループの整備に迷う場合は、業務データの状態と評価指標を先に整理してから、必要な範囲で外部リソースを組み合わせるのが安全です。
＼社内RAGの精度チューニングを相談できます／
Blackfordに相談する
