Chunking

100ページの社内マニュアルをRAGシステムに取り込むとき、そのまま丸ごとLLMに渡すことはできません。コンテキストウィンドウの制限もありますが、それ以上に検索精度が下がるからです。チャンク分割（Chunking）とは、文書を適切なサイズの断片（チャンク）に分割し、検索と生成の両方で最適な粒度にする前処理技術です。

なぜ分割が必要なのか

RAGの検索ステップでは、ユーザーの質問に意味的に近い文書を見つけます。しかし文書全体を1つのベクトルにすると、個々のトピックの特徴が薄まり、検索精度が大幅に低下します。たとえば「有給休暇の申請方法」を知りたいのに、就業規則全体が1つのチャンクだと、給与計算や勤怠管理の情報も混ざった曖昧なベクトルになってしまいます。適切に分割することで、質問に本当に関連する部分だけを正確に取得できるようになります。

固定長チャンキングとセマンティックチャンキング

最もシンプルな方法は固定長チャンキングで、文字数やトークン数で機械的に分割します。500〜1000トークン程度が一般的な目安です。実装が簡単で処理速度も速いですが、文の途中で切れたり、意味のまとまりが壊れるリスクがあります。

これに対し、セマンティックチャンキングは文章の意味的なまとまりを考慮して分割します。段落や見出しの区切り、話題の変わり目を検出して自然な単位に分けるため、検索精度が向上します。LangChainのRecursiveCharacterTextSplitterは、見出し→段落→文→文字の順に階層的に分割を試みる実用的な手法です。

オーバーラップの重要性

チャンク間にオーバーラップ（重複部分）を設けることも重要な戦略です。たとえば500トークンのチャンクに50〜100トークンのオーバーラップを持たせると、分割境界付近の文脈が保持されます。「前のチャンクの末尾」と「次のチャンクの先頭」が重なるため、境界をまたぐ情報の欠落を防ぐことができます。

チャンクサイズのトレードオフ

チャンクサイズの選択にはトレードオフがあります。小さいチャンク（200〜300トークン）は検索精度が高まりますが、必要な文脈が不足しがちです。大きいチャンク（1000〜2000トークン）は文脈を豊富に含みますが、無関係な情報も混入し、トークンコストも増えます。最適なサイズはデータの性質やユースケースによって異なるため、実際のクエリでテストしながら調整するのが現実的なアプローチです。FAQ形式なら小さめ、技術文書なら大きめ、というように使い分けるのが効果的です。