Skip to content

Latest commit

 

History

History
49 lines (33 loc) · 1.74 KB

File metadata and controls

49 lines (33 loc) · 1.74 KB

Fixed-Size Token Chunking

Split the document into chunks of exactly N tokens with M tokens of overlap between consecutive chunks. No awareness of sentences, paragraphs, or meaning — just raw token counts.

It's dumb, but it's fast and deterministic. Most RAG systems start here.

How it works

  1. Document tokenized using the model's tokenizer
  2. Tokens sliced into chunks of chunk_size (500 by default)
  3. Each chunk overlaps with the next by chunk_overlap (50) tokens to avoid cutting off context
  4. Each chunk embedded and stored independently

When to use

  • You want a fast, predictable baseline before trying smarter strategies
  • Documents have uniform density (no headers, no tables)
  • You don't want to pay for embedding calls to a semantic splitter
  • Token budget is tight and you need exact control over chunk size

When NOT to use

  • Documents have clear sections or paragraphs — fixed splitting cuts across them
  • Sentences matter — a 500-token cut can slice mid-sentence
  • You're working with code, tables, or structured content

Trade-offs

Speed Very fast — no LLM or embedding needed
Accuracy Medium — no semantic awareness, can cut mid-sentence
Cost Zero — pure text processing
Predictability High — exact chunk sizes every time

Overlap explained

Overlap exists because the cut point might split a thought across two chunks. With 50 token overlap, the end of chunk 1 repeats at the start of chunk 2 — so neither chunk loses critical context.

Too much overlap = redundant context. Too little = broken thoughts at boundaries.

Run it

# No API key needed
python fixed_size_chunking.py

Adjust CHUNK_SIZE and CHUNK_OVERLAP at the top of the script to experiment.