Summary
この文書の要点
- チャンクサイズは文書種別と質問粒度で決める。
- 見出し、版、権限、日付などのメタデータを保存する。
- チャンクには本文だけでなく、見出し、階層、版、権限、元文書位置を持たせる。
- 分割方法を変えたら、embedding_versionを分けて検索評価をやり直す。
どこが設計の難所か
文書を固定文字数で単純分割すると、意味の途中で切れたり、見出しとの関係が失われたりします。検索結果に近い文章が出ても、回答に必要な前提が欠けることがあります。
チャンクを小さくすると検索は細かくなりますが文脈が不足します。大きくすると文脈は残りますがノイズも増えます。文書の種類、質問の粒度、モデルのコンテキスト長に応じた調整が必要です。
RAGで検索品質が悪い時、生成モデルを疑いたくなりますが、原因がチャンク分割にあることは多いです。小さすぎるチャンクは文脈を失い、大きすぎるチャンクは検索の焦点がぼやけます。
境界をどう切るか
文書構造をできるだけ保ち、見出し、章、表、箇条書きなどを意識して分割します。各チャンクには文書ID、版、見出し階層、権限、作成日、更新日を持たせ、検索時にフィルタできるようにします。
設計では、文書構造を無視して固定文字数で切るのではなく、見出し、段落、表、箇条書き、版管理を考慮します。チャンクには親見出しや文書種別を持たせ、検索後に文脈を復元できるようにします。
実装で効く細部
取り込み処理では、原文、正規化テキスト、チャンク、埋め込みを分けて保存します。文書更新時はハッシュで変更チャンクを検出し、必要な部分だけ再埋め込みします。削除や権限変更時には検索対象から外れるようにします。
PostgreSQLやベクトルDBには、chunk_text、embedding、document_id、section_path、page_number、valid_from、access_scope、embedding_versionを保存します。検索時はベクトル類似度だけでなく、文書種別や権限でフィルタし、必要ならリランキングします。
- 表や手順書は単純な文字数分割ではなく、行や手順単位を崩さないようにする。
- チャンク生成時のsplitter_versionを保存し、再分割の影響を比較できるようにする。
- 検索結果にはスコアだけでなく、元文書位置と周辺文脈を返す。
壊れ方を観測する
検証では、質問ごとに期待チャンクが上位に入るかを見ます。回答が間違った時は、生成モデルの問題なのか、検索で根拠が取れていないのかを分けて判断します。
検証では、同じ質問セットで分割サイズ、overlap、メタデータフィルタの違いを比較します。回答の正しさだけでなく、期待チャンクがtop-kに入るかを見ると、生成前の検索品質を切り分けられます。
捨てた選択肢とトレードオフ
高度な分割は実装コストが上がります。最初は見出し単位と文字数上限の組み合わせから始め、評価結果を見て調整するのが現実的です。完璧な分割を先に作ろうとすると進みません。
細かいチャンクは検索精度が上がる場合がありますが、回答生成時に文脈を集めるコストが増えます。大きいチャンクは文脈が残りますが、検索ノイズが増えます。文書種別ごとに分割戦略を変える方が、単一設定より現実的です。
現場に残す判断軸
RAGの改善では、生成モデルを変える前に検索材料を見るべきです。チャンクとメタデータを設計することで、回答の根拠を安定して取り出せるようになります。
ベクトル検索では、モデルより前に文書の切り方を設計する必要があります。チャンクとメタデータを設計資産として扱うと、RAGの改善が再現可能になります。
