Apyrn Tools
All tools

RAG chunking optimizer

Chunking splits documents into smaller passages before embedding them, so a retrieval-augmented generation (RAG) system can find and send only the relevant parts to a model.

Test RAG chunk size, overlap and splitting strategy on your own text, preview the chunks, and estimate embedding and retrieval cost. Runs in your browser.

Browser-sideNo accountCopy, download, or print

Last reviewed

Your inputs are saved as a draft in this browser only. Nothing is uploaded.

Jump to result
Interactive workspace

Inputs

Result

More export options
Chunks in sample1
Total chunks10,000
Embedding cost (USD)$0.33
Retrieval tokens/query1,400
Strategy: Recursive
Sample tokens: 180
Chunks in sample: 1
Chunks across 10,000 documents: 10,000
Embedding cost: $0.33
Retrieval tokens/query: 1,400
Estimate assumes each document is similar in size to the sample text.

How to use it

  1. Paste a representative source text and pick a splitting strategy: recursive, Markdown heading aware, or fixed character window.
  2. Set the chunk size and overlap in tokens.
  3. Enter the retrieval top K, documents at scale, embedding price per million tokens, and average query tokens.
  4. Generate the simulation to review chunk counts, embedding cost, and retrieval tokens per query, then copy the result.

Questions

How is the embedding cost estimated?
The chunks produced from your sample text are scaled to the document count you enter, then multiplied by chunk size and your embedding price per million tokens. The estimate assumes each document is similar in size to the sample.
Are the token counts exact?
No. Tokens are approximated from text length at about four characters per token, which is close enough to size chunks and compare settings but is not tokenizer-exact.
Is my document text uploaded for analysis?
No. The simulation runs entirely in your browser and nothing is uploaded.
What chunk size and overlap should I start with?
There is no universal best value. A few hundred tokens with an overlap of around 10-20% is a common starting point; then test retrieval quality on real questions. Smaller chunks are more precise, larger chunks keep more context but cost more per query.