チャンクリングが検索品質、埋め込み性能、そしてリコール拡張生成（RAG）システムの全体的な効果にどのように影響するかを学びます.

序論

リコール拡張生成（RAG)を使用してAIアプリケーションを構築する際、開発者は通常最適なLLMや埋め込みモデルを選択することに焦点を当てます。しかし、一つの基本的なステップはしばしば見過ごされます。チャンキング

チャンキング

チャンキングとは、大規模な文書をエンコーディング生成とベクトルデータベースへの保存に先立って、より管理可能な小さなパーツに分割するプロセスです

不良なチャンキングは以下の問題を引き起こすことがあります

• 関連性のない検索結果
• 幻覚的な回答
• 文脈の欠落
• 推論コストの増加

適切なチャンキングは、一方で検索精度と応答品質を劇的に向上させます。

本記事では、最も一般的なチャンキング戦略、そのトレードオフ、および各々の使用時期を探求します。

チャンキングが重要な理由

LLMsと埋め込みモデルは、無限に大きいドキュメントを効率的に処理できません。

200ページのPDFを考慮してください.

ファイル全体を一つのベクトルとして埋め込む代わりに、それを小さなチャンクに分割します.

Large Document
      ↓
 Chunking
      ↓
Embeddings
      ↓
Vector Database
      ↓
Semantic Retrieval
      ↓
LLM Response

チャンクなし

一つの巨大な埋め込み:

• 意味の粒度を失います.
• 関連のないセクションを取得します.
• トークンコストを増加します

チュンキングを使用して

関連文書セクションは検索および取得可能になります.

チュンキングのトレードオフを理解する

チュンキングサイズは検索品質に影響します.

Missing context

あまり大きい:

Noise + irrelevant information

理想的なチャンクのバランス：

• 意味合い
• 検索精度
• トークン効率

1. 固定サイズチャンキング

最もシンプルで広く使われている方法

文書は固定の文字またはトークン制限に基づいて分割されます

例：

• 500トークン
• 1000文字

どのように機能しますか

Document
──────────────────────────
Chunk 1 (500 tokens)
Chunk 2 (500 tokens)
Chunk 3 (500 tokens)

Pythonの例

LangChainを使用して：

from langchain.text_splitter import CharacterTextSplitter

splitter = CharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50
)

chunks = splitter.split_text(document)

利点

• 実装が簡単
• 処理が速い
• 予測可能なチャンクサイズ

欠点

• 文書構造を無視する
• 文を途中で切ることがある
• 意味論的な意味を減少させることがある

最適な用途

• 迅速なプロトタイピング
• 小さなデータセット
• シンプルなRAGシステム

2. 再帰的チャンキング

固定サイズのチャンキングのより賢いバージョンです

無理に分割するのではなく、構造を保つことを試みます

典型的な階層：

1. 段落
2. 文
3. 単語

より大きなセクションがサイズ制限を超える場合のみ、さらに分割します

ワークフロー

Paragraph too large?
        ↓
Split into sentences
        ↓
Sentence too large?
        ↓
Split into words

例

LangChain 再帰分割器:

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50
)

chunks = splitter.split_text(document)

利点

• 意味を保持
• より良い検索品質
• 複合文書を扱う

欠点

• 少し遅い
• ドメイン固有の構造をまだ無視できる

最適な対象

ほとんどのRAGシステム

これは通常、デフォルトの推奨事項.

3. 文節ベースのチャンキング

この戦略は、チャンクを文の境界と合わせます

ランダムなトークン数の代わりに:

Chunk = Complete Sentences

例

文書:

AI systems rely on retrieval.
Chunking improves retrieval quality.
Poor chunking hurts accuracy.

可能なチャンク:

Chunk 1:
AI systems rely on retrieval.

Chunk 2:
Chunking improves retrieval quality.

Chunk 3:
Poor chunking hurts accuracy.

Python の例

NLTK を使用して

import nltk
from nltk.tokenize import sent_tokenize

sentences = sent_tokenize(document)

利点

• 自然言語の境界
• クリーンな埋め込み
• 意味の統一性の向上

欠点

• 不均一なチャンクサイズ
• 長い文は制限を超える可能性

最適な対象

• 会話データ
• 記事
• QAシステム

4. 文節ベースのチャンキング

段落は通常、一貫した考えを持っています

これが、チャンクの境界として有用な理由です

例

Paragraph 1 → Chunk 1
Paragraph 2 → Chunk 2
Paragraph 3 → Chunk 3

利点

• 高い意味的整合性
• 人間可読なチャンク
• ブログやドキュメントに適している

欠点

• 段落の長さが異なる
• 長い段落はオーバーフローする

最適な用途

• ブログ
• ドキュメント
• 研究論文

5. 重複チャンキング

チャンキングの主要な問題点:

境界でのコンテキスト喪失

例：

チャンク1：

The API authentication uses JWT...

チャンク2：

...tokens for secure communication.

重要な意味は両チャンクにまたがっている

重複がこれを解決する

重複の仕組み

Chunk 1
──────────────
AAAA BBBB CCCC

Chunk 2
          CCCC DDDD EEEE

注意：

CCCC

は両方のチャンクに表示されます.

コード例

splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=100
)

利点

• より良い検索連続性
• 境界問題を減少
• より高い回答精度

欠点

• より多くの埋め込み
• より大きなベクトルストレージ
• 検索コストの増加

最適な対象

ほぼすべての本番環境RAGシステム

典型的な重複率：

• 10–20%

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

セマンティックチャンキングは、意味ではなくサイズを利用します。

文書はトピックが変わる場所で分割されています。

これは大幅に賢くなっています。

コンセプト

代わりに：

Every 500 tokens

を分割します：

Meaning shift

例

文書:

Section A → Databases
Section B → Kubernetes
Section C → Security

セマンティックチャンキングは以下のものを作成します:

Chunk 1 → Database topic
Chunk 2 → Kubernetes topic
Chunk 3 → Security topic

高レベルパイプライン

Text
 ↓
Sentence embeddings
 ↓
Similarity comparison
 ↓
Topic boundary detection
 ↓
Chunks

Pythonの例（概念的な）

from sentence_transformers import SentenceTransformer
from sklearn.metrics.pairwise import cosine_similarity

文の類似度が分割箇所を決定します

利点

• 優れた検索品質
• トピックに対応
• 強い文脈的相关性

欠点

• 計算コストが高い
• 実装に手間がかかります

最適な用途

• 企業向け検索
• 法務文書
• 知識ベース

7. 構造認識型チャンキング

一部の文書にはすでに構造が含まれています.

例:

• HTML見出し
• Markdownセクション
• タイトル付きPDF
• コードファイル

このを無視する代わりに、私たちはそれを使います。

例

マークダウン:

# Authentication
JWT details...

# Rate Limiting
API throttling...

チャンク:

Authentication section
Rate Limiting section

コード例

Markdownヘッダースプリッター:

from langchain.text_splitter import MarkdownHeaderTextSplitter

headers = [
    ("#", "Header1"),
    ("##", "Header2")
]

利点

• 高い意味の整合性
• 作成者の意図を使用
• ドキュメントに最適

欠点

• クリーンなフォーマットに依存
• 生テキストでは効果が低い

最適な対象

• 開発者ドキュメント
• ウィキ
• 技術文書

8. コードチャンキング

ソースコードは特別な扱いが必要です.

500文字ごとに分割するとロジックが壊れる可能性があります.

代わりに:

分割方法:

• 関数
• クラス
• モジュール
• ASTノード

不良チャンク

def login():
    ...

半分でカット

より良いチャンク

Entire login() function

Tree-sitterを使用した例

import tree_sitter

ASTベースのパースは構文を保持します

利点

• 論理的な構造を維持
• コードの検索が容易
• AIコーディングアシスタントに強い

欠点

• 言語特有のツールing

最適な対象

• code copilots
• リポジトリの検索
• ソフトウェアドキュメント

チャンキング戦略の比較

実践的なチャンキング戦略

多くの成功したRAGシステムはハイブリッドアプローチを使用しています.

例：

Structure-aware
        +
Recursive splitting
        +
10–20% overlap

パイプライン：

Document
   ↓
Heading Split
   ↓
Recursive Chunking
   ↓
Overlap
   ↓
Embeddings
   ↓
Vector DB

これは通常、以下の間の最良のバランスを提供します：

• 関連性
• コスト
• シンプルさ

最終的な考え

チャンキングは単なる前処理ではありません。

は直接影響を与えます：

• 検索精度
• 埋め込み品質
• 妄想率
• ユーザーエクスペリエンス

普遍的な最良の戦略はありません。

良いルール：

• 再帰的 + 重複から始めます
• 意味論的または構造認識型のチャンキングへ移行します が複雑さが増すと
• コード認識チャンキング をエンジニアリングシステムに使用します

多くの場合、チャンキングを改善することは、より大きなLLMに切り替えるよりも大きな利益をもたらします