RAGシステムが誤った、あるいは中途半端な答えを返すとき、その原因は大抵モデルではない。チャンキングだ。答えを含む文章が取得されたコンテキストに一度も入らなければ、どんなモデルもそこから答えることはできない。プロンプトをどれだけ調整しても変わらない。チャンキングはそもそも何を検索できるかを決める。だからこそ最初に点検すべきものであり、しかしほとんどのチームが最後にしか見ないものでもある。

Amazon Bedrock Knowledge Basesでは、データソースを作成する際にチャンキング戦略を選べる。この一つの選択が、検索品質の上限を静かに決めてしまう。ここで判断を誤ると、埋め込みモデルやリランカー、LLMを何週間も責め続けることになるが、実際の問題はドキュメントの切り方にある。

なぜチャンキングが荷重を支える決定なのか

検索はドキュメント単位ではなくチャンク単位で機能する。各チャンクはベクトルに埋め込まれ、クエリ時にはその質問に最も近い上位k個のチャンクが取得される。チャンクサイズから直接、2種類の失敗パターンが生まれる。

大きすぎるチャンクは埋め込みを希薄にする。4つのサブトピックをカバーする2000トークンのチャンクは、その4つすべての平均であるような一つのベクトルを生む。結果、あらゆるものと弱くマッチし、何とも強くマッチしない。正しいチャンクは近接するが不正確な候補の中に埋もれてしまう。逆に小さすぎるチャンクは文脈を断ち切る。例から切り離された定義や、警告から切り離された手順は、きれいに検索されるが、それを有用にしていた周囲のテキストを伴わずに届く。答えは技術的には存在するが、実用的には不完全だ。

チャンキング戦略の役割は、意味のある境界で切ることだ。各チャンクが一つのまとまった考えとなり、それだけで答えとして成立するほど自己完結していて、かつランキングできるほど具体的であるようにする。

Bedrockが提供する3つの戦略

固定長チャンキング

一定のオーバーラップを持たせながらNトークンごとに分割する。デフォルトかつ最も安価で、トピックの変化が緩やかな均一なプローズ主体のコンテンツには問題ない。しかし構造化されたドキュメントに対しては明確に悪い。トークンカウンターが着地した場所、テーブルの途中、リストの途中、見出しとそれが導入する段落の間など、お構いなしに切ってしまうからだ。オーバーラップはダメージを和らげるが取り除きはしない。コーパスが均質でベースラインが欲しいときに固定長を選ぶべきであって、単にデフォルトだからという理由で選ぶべきではない。

セマンティックチャンキング

意味で分割する。セマンティックチャンキングは隣接する文の埋め込み類似度を測定し、トピックが変化する場所で新しいチャンクを開始する。そのため境界は固定トークン数ではなく、アイデアとアイデアの間に落ちる。これはFAQ、ナレッジ記事、各回答や概念がまとまりとして保たれてほしい混在プローズなど、混合コンテンツに対する適切なデフォルトだ。チャンキングと同時に埋め込みを行うためインデックス構築のコストは高くなるが、異種混合のコーパスでの検索品質の差はそのコストを支払う価値がある。

階層型チャンキング

親チャンクと子チャンクを構築する。小さな子チャンクが埋め込まれ、精密な検索のためにマッチングされるが、モデルに返されるのはより大きな親チャンクだ。つまり具体性でランク付けし、文脈をもって答える。これはテクニカルマニュアルや法的契約書など、セクションとサブセクションを持つ本物の構造を持つドキュメントに適している。クエリは狭い条項にヒットするが、モデルはそれを正しく使うために周囲のセクションを必要とする。この戦略は最も推論が複雑であり、ドキュメントに活用できる本物の階層がある場合に最も適している。

モデルを責める前に検索を評価する

最も有用な習慣は、検索の問題を生成の問題から切り離すことだ。プロンプトをいじったりモデルを差し替えたりする前に、一つだけ確認する。実際の質問セットにおいて、答えを含むチャンクは取得されたコンテキストに現れたか。

  • 小さな評価セットを作る。実際の質問30から50個、それぞれに答えとなる出典の文章を添える。
  • 検索だけを実行する。各質問について、正解の文章が上位k件の結果に現れるかを確認する。そのヒット率があなたの検索の上限だ。
  • 正しい文章が取得されていないなら、生成の品質は無関係だ。修正すべきはチャンキング、埋め込み、top-kであり、モデルではない。
  • 検索が信頼して正しい文章を表面化するようになって初めて、モデルがそれをどう使うかに取り組む意味が出てくる。

ほとんどのチームはこれを飛ばして、いきなりプロンプトエンジニアリングに向かう。だから検索ヒット率の測定であれば午後一日で特定できたはずの問題に長く時間をかけてしまう。検索が半分の確率で答えを見逃しているなら、それはモデルの衣装を着たチャンキングの問題だ。

実践的な出発点

一般的なナレッジコンテンツにはセマンティックチャンキングから始め、ドキュメントに明確なセクション構造があり答えが周囲の文脈に依存する場合は階層型に移行し、速度とシンプルさを重視する大規模で均一なプローズにのみ固定長を残す。そして検索ヒット率を測定し、変数を一つ変え、再び測定する。チャンキングは設定して忘れるパラメータではない。RAGシステムがまともかどうかを最も左右するノブだ。

結論

RAGの品質はモデルが動く前、ドキュメントをチャンクに切る瞬間に決まっている。固定長はベースラインであり、セマンティックは混合コンテンツに対する妥当なデフォルトであり、構造が重要な場合は階層型が勝つ。まずは実際の質問セットで検索ヒット率を測定すること。答えが一度もコンテキストに入らなければ、モデルは最初から問題ではなかったのだから。

次に読む

大規模なベクトル検索を運用するストレージとインフラ側については、クラウドのフィールドノートはercan.cloudにあり、ハブはercanermis.comにある。