社内文書を読み込ませた RAG を作ったのに、肝心の答えがどうも噛み合わない。
そんなとき、疑う先はモデルよりも先に「文書の切り方」だったりします。
検索でヒットしているのに答えがずれるなら、ヒットした断片そのものが的を外している可能性が高いからです。
この断片を作る工程がチャンキング（chunking）と呼ばれるもの。
地味な前処理に見えて、RAG の当たり外れをかなりの部分で握っています。
チャンキングは検索の単位を決める作業
チャンキングとは、長い文書を検索しやすい大きさの断片（チャンク）へ分割する処理のこと。
なぜ文書を丸ごと渡さないのか
理由の一つは、コンテキストウィンドウという物理的な上限です。
100ページのマニュアルをそのまま押し込もうとしても、そもそも入りきりません。
ただ、仮に全部入ったとしても丸ごと渡すのは得策ではないのです。
関係のない記述が大量に混ざると、肝心の1行が薄まって読み落とされるという問題が残ります。
LangChain の公式ドキュメントでも、ページ単位では検索に対して粗すぎるため、関連部分が周囲の文章に薄められないよう、さらに細かく分割すると説明されているのです。
この点は LangChain の Knowledge base ガイドでも説明されているところ。
検索の解像度はチャンクで決まる
RAG の検索は、チャンク単位でベクトル化されて行われます。
つまりチャンクより細かい粒度で「ここだけ欲しい」と指定する手段は無いわけです。
チャンクの切り方を決めるという行為は、そのまま検索の解像度を決める行為。
ここを雑にしたまま埋め込みモデルやプロンプトを差し替えても、効果が頭打ちになりがちです。
大きすぎても小さすぎても外れる
チャンクサイズには、大きすぎず小さすぎずという山があるのです。
大きいチャンクはノイズを連れてくる
1つのチャンクに複数の話題が同居していると、検索でヒットしたときに無関係な記述までモデルへ渡ることになります。
引用の根拠が曖昧になり、要約の途中で話が別のトピックへ滑る原因にもなるのです。
トークン消費が増えるぶん、応答も遅くなりがち。
小さいチャンクは文脈を落とす
逆に細かく刻みすぎると、今度は主語や前提が別のチャンクへ行ってしまいます。
「この機能は管理者のみ利用できます」という一文だけが切り出されても、どの機能の話なのか分からなくなる。
チャンクは、それ単体で読んでも意味が通る単位に切るのが基本です。
この観点を持つだけで、切り方の判断はぐっと楽になります。
オーバーラップで境界の断絶を防ぐ
分割の境目をまたいだ情報を救うため、隣り合うチャンクをわざと少し重ねておく手もあるのです。
これがチャンクオーバーラップと呼ばれる設定です。
重なりがないと境界が切れる
説明の前半と後半がちょうど境目で分断されると、どちらのチャンクも中途半端になります。
「まず A を設定します」でチャンクが終わり、「次に B を有効にします」から次のチャンクが始まる。
こうなると、手順の連続性が検索側から見えません。
先頭の数行を前のチャンクと共有させておけば、どちらがヒットしても前後の流れをたどれる状態になるのです。
設定値は本文の性質に合わせる
LangChain のドキュメントに載っている例では、チャンクサイズ 1000 文字に対してオーバーラップ 200 文字という組み合わせが使われています。
ここで大事なのは、この数字が万能の正解ではないという点です。
規約や仕様書のように1文が独立している文書なら、重なりは薄くても足ります。
一方、話が数段落にわたって続く解説文では、重なりを厚めに取らないと文脈が切れやすくなるのです。
重ねるほどインデックスの容量と検索コストが増えるので、そこはトレードオフ。
区切り方には段階がある
どこで切るかという判断にも、いくつかのやり方が存在します。
固定長で切る
決めた文字数やトークン数で機械的に切る、いちばん単純な方法です。
実装が楽で速度も出る反面、文の途中で切れてしまう場面が避けられません。
区切り文字をたどって切る
段落、改行、句点といった自然な区切りを優先しながら、目標サイズに収まるまで再帰的に分割していく方法。
LangChain のRecursiveCharacterTextSplitterがこの考え方で、一般的なテキストにはこれが推奨されています。
文の途中で切れる事故を減らしつつ、サイズもある程度そろえられるため、まずはここから試すのが無難です。
構造や意味のまとまりで切る
Markdown の見出し階層や HTML のセクションのように、文書側が持っている構造を使って切る手もあります。
意味の近さで境界を判断する方法も研究・実装が進んでいるものの、その分だけ処理コストは上がるのです。
最後に
チャンキングは、RAG の中でいちばん地味で、いちばん効く工程でした。
検索の解像度は、埋め込みモデルではなくチャンクの切り方が決めているという理解が出発点になります。
まずは区切り文字ベースの分割を既定値で動かし、実際の質問で外した事例を眺めながらサイズと重なりを調整する。
その地道な往復がいちばん確実な精度改善の道だと感じています。
モデルを差し替える前に、一度チャンクの中身を目で読んでみる。
そのスタンスでやっていきたいところ。
以上です。
コメントを残す