Chunking vs Semantic Chunking、RAG文書をどのように分けるべきでしょうか？
Chunkingは、長い文書を検索・埋め込み・モデル文脈に適した小さな単位に分割する一般的なプロセスです。Semantic Chunkingは、段落、見出し、意味的類似度、または文書構造を利用して、トピックが切り替わる境界を中心に分割する方法です。
3行要約
Chunkingは文書を固定サイズ・文字・トークン・ルールで分割する全体的なプロセスであり、Semantic Chunkingは見出し・段落・レイアウト・意味の変化を境界として用いる下位のアプローチです。
Semantic Chunkingが常に優れているわけではなく、文書解析・埋め込み・変化検出のコストと可変なチャンクサイズにより、フィルタ・保存・評価の複雑さが高くなることがあります。
まずは構造を保った固定・ルールベースを基準線として作り、正解根拠 Recall・Citation Correctness・遅延・コストが実際に改善される場合にのみ、より複雑な分割を選ぶべきです。
Semantic Chunkingは一般的なChunkingとは異なる段階でしょうか？
完全に別の段階というより、分割境界を決める方法の一つです。すべてのRAGパイプラインは、文書を保存・検索・モデル入力に適した単位へ分割する必要があります。固定の500トークンで分けることも、見出しと段落に沿って分けることも、文の埋め込み間の類似度が大きく下がる地点を境界とすることも、すべてChunkingです。
Semantic Chunkingという言葉は、意味的一貫性を保とうとする複数の方法を広く指します。Azure AI Searchの文書レイアウトベースの方法は、見出し・段落・表などの構造を読み取り、意味的につながった本文をまとめます。別の実装では、隣接する文ベクトルの距離から話題転換を推定します。同じ名前でもアルゴリズムは異なり得ます。
区分 | 固定・ルールベースChunking | Semantic Chunking |
|---|---|---|
境界 | 文字・トークン数、区切り文字、段落 | 見出し・レイアウト・話題転換・意味類似度 |
チャンクサイズ | 比較的一定 | 文書構造に応じて可変的 |
実装コスト | 低く、再現しやすい | レイアウト分析・埋め込み・モデルコストがよりかかる可能性がある |
主な利点 | 大規模処理・デバッグ・バージョン管理が簡単 | 見出しと根拠を同じ単位に残せる可能性 |
主なリスク | 主張・例外・表が境界で切れることがある | あまりに大きすぎる・小さすぎる可変チャンク、アルゴリズム・モデル変更に伴う再生成 |
チャンクサイズはどのように決めるべきでしょうか？
平均的な数値1つですべての文書を処理することはしません。埋め込みモデルの入力上限、生成モデルに渡す全体コンテキスト、検索器が返す候補数、文書の表・リスト・見出し構造をあわせて見ます。チャンクが大きすぎると1つのベクトルに複数のトピックが混ざり、小さすぎると定義・条件・例外が互いに分離されてしまうことがあります。
一般的なチャンクでは、まず段落の境界を優先し、見出しとソースURLをメタデータとして保持します。そのうえで、最大トークン数を超えた場合のみ追加分割します。この基準線はコストが低く、どこで切られたかを再現しやすいです。
Semantic Chunkingのほうがよいのは、どのような場合でしょうか？
表の行とヘッダー、法令・ポリシーの条項と例外、技術文書の手順と注意事項のように、構造が正解の意味に直接影響する文書では有利なことがあります。固定サイズが重要な条件を繰り返し分断し、正解段落が上位候補から継続的に漏れる場合は、評価する理由があります。
一方で、短いFAQ、構造が一定の製品紹介、1段落に1つの定義しかないデータでは、複雑なSemantic Chunkingによる追加の利益は小さいかもしれません。チャンク数が増えれば埋め込み・保存・取得コストも増え、フィルタと権限メタデータの管理も複雑になります。複雑な方式を使うという理由だけで品質が上がるわけではありません。
取得品質の比較基準
質問ごとに、正解を支える元の段落と文書IDをまず指定します。正解チャンクが上位k件の候補に入ったか、必須条件と例外が同じチャンクに残っているか、ソースURLと見出しが保持されたかを確認します。最終回答では、主張と引用されたチャンクが一致しているかを別途確認します。
評価段階 | 指標 | 失敗の解釈 |
|---|---|---|
分割 | 正解根拠・条件・例外が同一チャンクに保持されているか | 構造を無視した境界で情報が切断される |
埋め込み | 質問セットごとの正解チャンク Recall@k | 適切なチャンクがあっても、ベクトル表現で取得されない |
フィルタ・保存 | 権限・バージョン・日付メタデータの保持 | 正解がないのではなく、フィルタで除外されている |
再ランキング | 正解チャンクの上位順位とノイズ比率 | 取得はされたが生成コンテキストから漏れている |
生成・引用 | 主張-根拠一致・Citation Correctness | チャンクがあってもモデルが誇張・誤解する |
品質だけでなく、前処理時間、埋め込み呼び出し回数、インデックスサイズ、検索遅延、文書更新時の再処理コストもあわせて残します。平均精度が少し上がっても、重要なポリシー質問の例外が切り捨てられるなら、運用基準は通過できません。
文書タイプごとにどう分けますか？
WebページはH1・H2・H3と段落を優先し、URL・タイトル・canonicalはメタデータとして保持します。PDFはページ・タイトル・表・脚注・読み順を先に復元する必要があります。スキャン文書はOCRエラーが構造エラーにつながる可能性があるため、数値・表ヘッダー・署名欄を別途確認します。
説明書は手順と注意事項を一緒に配置し、ポリシー文書は施行日・対象・例外を同じチャンクに残します。製品カタログは項目別スキーマで保存する方が、テキストチャンクより適している場合があります。文書タイプを無視した1つの分割器では、すべてのコンテンツをうまく処理できません。
既存サイトへの適用範囲
SEO記録にはChunkingとSemantic Chunkingの構造保持が、露出・クリックに与えた影響を残します。GEO記録には、チャンクサイズがAI回答の言及・引用と噛み合った場面を別途残し、2つの結果を無理にまとめません。
RAGリポジトリのためにWebサイトのコンテンツを別途移すより、既存ページのHTML構造を整えることを先に行います。タイトル・小見出し・表ヘッダー・出典・日付がレンダリングされた本文にあれば、どのChunkingを適用しても原文と正答根拠を結びつけやすくなります。
この運用方式では、既存のWebサイトを維持したまま導入し、公開原文の構造・レンダリング・メタデータとAI回答の引用を結びつけて確認できます。質問ごとに、欠落が原文・分割・検索・生成のどの段階で始まったのかを切り分け、Semantic Chunkingの追加コストを支払う理由があるかどうかを判断できます。
ChunkingとSemantic Chunkingの並行運用における実際の判断
ChunkingとSemantic Chunkingのどちらかを先に選ぶのではなく、分割基準、構造保持、計算コスト項目の基準値を作ります。この値がなければ、修正前後を比較できず、担当者が変わるたびに同じ診断を繰り返します。影響の大きいURLと質問を少数選定し、誰がどの値をいつ修正したかを残します。
ChunkingとSemantic Chunkingのチャンクサイズ項目も、全体平均だけは見ません。新しく修正したページ、そのままのページ、季節性の影響を受けるページを分けることで、差が見えてきます。結果が予想と異なる場合は、新しいページを増やす前に、原文不足、技術的ブロック、外部情報と測定の空白を確認します。
参考資料
検索・RAG構造を続けて見る
ChunkingとSemantic Chunking比較後のSearch OS運用
現在のサイトにSearch OSを連携すると、ChunkingとSemantic Chunking比較において、構造保持、計算コストの項目を同じ質問グループとして追跡できます。全面移行なしに公開URLと原文を照合し、影響の大きい修正から適用します。
Search OSが内部実績を集計した結果、導入企業のSEOとAI検索露出は平均88%以上増加しました。成果が出た後も、ChunkingとSemantic Chunkingに関連する検索露出、AI回答の正確性と引用を継続的に確認します。既存資産を守りながら、変更が必要な部分のみを補完し、現在の環境で可能な最良の露出状態を維持します。