Brave Search API

More Search API pages

API glossary

Chunking

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Chunking is the process of splitting a large document or body of text into smaller, self-contained segments (called “chunks”) so they can be embedded, indexed, and retrieved individually. In retrieval-augmented generation (RAG) and semantic search, chunking determines the unit of text a system stores and later pulls back as context. This, in turn, directly shapes how relevant and complete the retrieved results are.

In short: chunking decides how a long document is cut into retrievable pieces, and getting the cut right is what makes retrieval both accurate and concise (i.e. able to refer to subsets of the “right” document for its needs).

How chunking works

Chunking exists because of two limits: embedding models and LLM context windows can only handle so much text at once, and retrieval is most accurate when each stored unit is topically focused. The process typically runs as follows:

  1. Parsing: Clean text is extracted from the source (HTML, PDF, and so on), ideally preserving structure such as headings, paragraphs, and lists.
  2. Segmentation: The text is split into chunks using a chosen strategy (see below).
  3. Overlap: A small amount of text is often repeated between adjacent chunks so meaning isn’t lost at the boundaries.
  4. Enrichment: Each chunk can be tagged with metadata or surrounding context (such as source, section title, and short summary) to make it more self-explanatory on its own.
  5. Embedding and indexing: Each chunk is converted into a vector embedding and stored in a vector database, keyed for fast lookup.
  6. Retrieval: At query time, the system finds the chunks whose embeddings are most similar to the query and passes them to the model as context.

The defining tension is size: chunks that are too large dilute relevance and waste context, while chunks that are too small lose the surrounding meaning. Good chunking is the art of balancing the two for a given type of content.

Chunking vs. tokenization and embedding

  • Tokenization splits text into tokens (sub-word units) so a model can process it; chunking splits documents into passages so a system can store and retrieve them. Different granularity, different purpose.
  • Embedding turns a chunk into a numeric vector; chunking is the prior step that decides what each unit of text actually is. Chunk first, then embed.
  • Fixed-size chunking cuts text by a set length (e.g. a number of tokens or characters); semantic chunking cuts at meaning boundaries so each chunk stays topically coherent. The first is simpler and faster; the second tends to retrieve more cleanly.

Where chunking is used

  • Retrieval-augmented generation (RAG) pipelines: Chunking prepares source documents so the most relevant passages can be retrieved and fed to the model at the time of answer.
  • Semantic and vector search: Searching over chunks rather than whole documents returns focused, on-topic passages instead of sprawling pages.
  • Document chatbots and knowledge bases: Question-answering over manuals, wikis, and support docs depends on well-formed chunks to surface the right answer.
  • Long-document summarization and analysis: A model can only take in so much text at once (this is known as the model’s context window), so a long book or report won’t fit in a single pass. Chunking lets the model work through the book or report one piece at a time and then merge those partial results into a single overview.

Chunking strategy is usually tuned to the content type (for example, dense prose, code, tables, and transcripts each chunk differently) and it matters most whenever content is too long to feed in whole. In this case, retrieval quality depends on returning focused, self-contained passages.

Retrieval-augmented generation (RAG), semantic search, embeddings, vector database, tokenization, context window, chunk overlap, reranking, indexing.