recursive-char （デフォルト）。最初に段落で分割、次に改行、文境界（ . ）、空白で分割を試みます。各ピースをチャンクサイズの予算まで貪欲にパック。どうしても入らない場合のみ、文字単位のハード分割にフォールバック。LangChain・LlamaIndex・ほぼすべての本番 RAG スタックのデフォルトで、散文コーパスにおいて妥当な出発点です。 sentence 。文境界で分割し、文の途中では決して切りません。文が予算より短くても、まるごと残します。チャンクが根拠として引用されるユースケース（QA・引用）では recursive-char より良く、文の途中で終わるチャンクが出ません。文の長さがばらつくため、チャンクサイズもばらつきます。 paragraph 。各段落を 1 単位として扱います。隣接する短い段落をパックできますが、長い段落は決して分割しません。各段落が一貫した思考になっているドキュメント・KB 記事・整った長文に有用。 semantic 。paragraph に見出し検出を加えたもの。 # 、 ## などで始まる行や短い大文字行を新セクションの境界として扱います。視覚的な段落間隔よりセクション境界が重要なテクニカルドキュメントに有用。

ヒューリスティックです。英語的なテキストには「文字数 / 3.8」、CJK には「1 文字あたり 1 トークン」を使います。散文で ±5〜10%、コード重めや構造化テキストではそれより精度が落ちます。なぜ本物のトークナイザを使わないか。 tiktoken は ~1 MB の WASM で、チャンクのサイジングだけのために載せるには重すぎます。下流モデルがチャンクに対して厳密なトークン上限を持つ場合（例：cohere/embed-v3 は 512 上限）、安全マージンを取って構築するか、パイプラインで本物のトークナイザを通してください。サイジングにはこれで十分。各チャンクの正確なトークン数は RAG 品質にはほとんど影響しません — 埋め込みモデルはどうせ超過分を切り捨てます。重要なのは一貫性で、チャンキングと下流プロンプトの予算配分に同じヒューリスティックを使うことです。

RAG テキストチャンカー

RAG・埋め込み準備のためにテキストをトークンサイズのチャンクに分割。複数戦略：再帰文字、文単位、意味境界。重複量を設定可能。すべてブラウザで完結。

Paste your document

RAG (Retrieval-Augmented Generation) is a technique that pairs an LLM with an external knowledge base. Instead of relying only on the model's parametric memory, the system retrieves relevant passages at query time and concatenates them into the prompt.

The retrieval step depends on a vector store. Documents are split into chunks, each chunk gets an embedding vector, and those vectors are stored in a database that supports approximate nearest-neighbour search.

# Chunk size matters

Chunks that are too small lose context — a single sentence might not contain enough information to answer the question. Chunks that are too large dilute relevance — the embedding becomes an average of many unrelated topics, and retrieval gets noisy.

A common starting point is 500 tokens per chunk with 50 tokens of overlap. Overlap lets a chunk see a bit of context from its neighbours, which helps when a relevant span happens to fall across a chunk boundary.

# Strategy choice

Recursive character splitting is the most general: it tries paragraph breaks first, then line breaks, then sentence boundaries, then spaces. This is the default in most frameworks and works well for prose.

Sentence-aware splitting respects sentence boundaries and never breaks mid-sentence. It produces cleaner chunks for QA over articles and books, at the cost of more variable chunk sizes.

Paragraph chunking treats each paragraph as its own chunk (subject to the size limit). This is useful for structured documents like documentation or knowledge-base articles where each section is already a coherent unit.

Semantic chunking goes one step further: it tries to keep semantically related content together by respecting headings and topic boundaries, even when those don't align with paragraph breaks.

Chunk size (tokens): 500

Overlap (tokens): 50

Strategy

これは何のため？

Retrieval-Augmented Generation（RAG）と埋め込みベース検索のどちらも、コーパスを チャンク に分割することに依存します。それぞれのチャンクが個別に埋め込まれ、ベクトル DB に格納されます。分割は AI 機構が動く前に行われますが、検索品質はそこに静かに、ほとんどの人が思うより強く依存します。チャンクが小さすぎると文脈を失い、大きすぎると関連性が薄まり、文の途中で切れたチャンクは埋め込みが妙な意味的位置に落ちて検索品質が下がります。このツールはブラウザ完結の素早いプレイグラウンドで、チャンクサイズ・オーバーラップ・戦略を試してから、パイプラインに組み込めます。

4 つの戦略

recursive-char（デフォルト）。最初に段落で分割、次に改行、文境界（. ）、空白で分割を試みます。各ピースをチャンクサイズの予算まで貪欲にパック。どうしても入らない場合のみ、文字単位のハード分割にフォールバック。LangChain・LlamaIndex・ほぼすべての本番 RAG スタックのデフォルトで、散文コーパスにおいて妥当な出発点です。
sentence。文境界で分割し、文の途中では決して切りません。文が予算より短くても、まるごと残します。チャンクが根拠として引用されるユースケース（QA・引用）では recursive-char より良く、文の途中で終わるチャンクが出ません。文の長さがばらつくため、チャンクサイズもばらつきます。
paragraph。各段落を 1 単位として扱います。隣接する短い段落をパックできますが、長い段落は決して分割しません。各段落が一貫した思考になっているドキュメント・KB 記事・整った長文に有用。
semantic。paragraph に見出し検出を加えたもの。#、## などで始まる行や短い大文字行を新セクションの境界として扱います。視覚的な段落間隔よりセクション境界が重要なテクニカルドキュメントに有用。

オーバーラップ — 理由と量

理由。 関連スパンがちょうど 2 つのチャンクの境界に落ちると、両方とも半分しか持たないため検索品質が下がります。オーバーラップは、前のチャンクの末尾 N トークンを次のチャンクの先頭にコピーし、両方にスパン捕捉の機会を与えます。
量。チャンクサイズの 10〜20% が経験則。500 トークンチャンクなら 50〜100 トークン。ここのデフォルトは 50 で、実用上うまく動きます。
トレードオフ。 オーバーラップが多い = 総埋め込み数増（ストレージ・コスト・インデックス構築時間・検索候補が増える）。具体的な理由がない限り 30% を超えないこと。検索品質はほとんど上がらず、コストだけ増えます。

トークン推定

ヒューリスティックです。 英語的なテキストには「文字数 / 3.8」、CJK には「1 文字あたり 1 トークン」を使います。散文で ±5〜10%、コード重めや構造化テキストではそれより精度が落ちます。
なぜ本物のトークナイザを使わないか。 tiktoken は ~1 MB の WASM で、チャンクのサイジングだけのために載せるには重すぎます。下流モデルがチャンクに対して厳密なトークン上限を持つ場合（例：cohere/embed-v3 は 512 上限）、安全マージンを取って構築するか、パイプラインで本物のトークナイザを通してください。
サイジングにはこれで十分。 各チャンクの正確なトークン数は RAG 品質にはほとんど影響しません — 埋め込みモデルはどうせ超過分を切り捨てます。重要なのは一貫性で、チャンキングと下流プロンプトの予算配分に同じヒューリスティックを使うことです。

よくある落とし穴

JSON や CSV のような構造化データをテキストチャンカーでチャンクしない。 チャンク境界がレコードの途中に落ち、埋め込みは意味を失います。先にレコード境界で分割するか、ツール固有の RAG 手法を使ってください。
コードを散文チャンカーでチャンクしない。 コード検索では関数境界が重要であり、文字数ではありません。tree-sitter ベースのチャンカーがあります。
空白と BOM。 貼り付けたテキストには隠れた空白が含まれ、トークン推定が狂うことがあります。気になるなら貼り付け前にトリム・正規化してください。
プライバシー。 すべてブラウザ内で動きます。貼り付けた文書はページを出ません — ローカルスクリプトと同じ感覚で、機密情報や PII を含む素材にも使えます。