A retrieved passage can mention the right topic and still omit the sentence needed to answer the question. If a document splitter separates a rule from its exception or a procedure from its prerequisites, the retrieval system may return incomplete context.
LLM-based chunking asks a generative model to choose boundaries based on meaning. The extra inference cost is worthwhile only if those boundaries improve retrieval. Here is how the approach works, how it differs from recursive and semantic chunking, and what to measure before using it in a RAG pipeline.
LLM-based chunking is a chunking technique that hands your document to a language model and lets it decide where to split. The model works from what the text means rather than from character counts or separator characters. The goal is to place boundaries at idea shifts.
It sits at the expensive end of what a RAG pipeline can do. It's also the only strategy where a generative model, not a rule or a distance metric, makes the call. Some LLM-assisted pipelines index propositions rather than passages, which is a different job.
LumberChunker prompts an LLM over groups of sequential passages to identify where the topic shifts and place chunk boundaries. Chonkie ships a hybrid version: recursive rules propose candidate boundaries, and the model only decides within a small window around each. Both approaches limit how much text the model processes at once.
Terminology is not standardized. Both this name and "agentic chunking" appear in 2026 research on different workflows. A May 2026 chunking evaluation compares an LLM-based method with three others. A second May 2026 paper carries "agentic chunking" in its title for work that builds fuzzy cognitive maps and reports no retrieval metric. Neither paper establishes a general retrieval advantage. This article reserves the term for generative-model boundary selection.
Three neighbors get confused with it. Semantic chunking embeds adjacent sentence groups and creates a breakpoint when their dissimilarity crosses a configured threshold, and a generative model doesn't choose that boundary. LlamaIndex ships it as SemanticSplitterNodeParser; LangChain's version never left langchain-experimental, archived read-only in May 2026. Late chunking (Günther et al.) isn't a splitting method at all; it changes when pooling happens during embedding. Dense X Retrieval rewrites text into atomic, self-contained propositions as retrieval units, changing what gets indexed rather than only where a passage ends.
Recursive chunking avoids generative-model cost and is a strong baseline. Benchmark against it, as well as against fixed-size splitting. LangChain's recursive splitter defaults to the separators ["\n\n", "\n", " ", ""], though implementations are configurable, so it already respects paragraphs and lines. In that May 2026 evaluation, recursive splitting at 300 characters beat the LLM-based method on every reported metric. The study covers 18 question-answer pairs on Khmer agricultural documents, so test retrieval quality on your own corpus.
Some teams skip the question. On long-context models, they stop chunking and pass whole documents, trading retrieval complexity for a large and repeated context bill, which we cover separately.
Use it when a wrong boundary is costly, and the corpus is small enough to afford it. Good candidates: contracts where a clause split in half changes its meaning, clinical documentation, technical references that interleave prose and code. On GutenQA, a benchmark of 3,000 needle-style QA pairs from 100 public-domain narrative books, LumberChunker's authors report DCG@20 7.37% higher than their strongest baseline. That is a relative gain against one baseline on the authors' own benchmark, not a general retrieval result.
Skip it when your corpus is large, churns often, or is cheap to be wrong about. Chunking a million support tickets with one model call each is a real bill for a gain you haven't measured. Measure whether model-guided boundaries improve retrieval on your corpus before paying for them.
LLM-driven splitters are available in specialist libraries rather than the core LlamaIndex and LangChain packages.
Chunking decides what gets retrieved, not what reuse costs. Without cross-request KV-cache reuse, a model must prefill retrieved context again on later queries. Standard prefix caching reuses matching prompt prefixes, while CacheBlend selectively recomputes boundary tokens for repeated chunks at shifted positions.
Tensormesh Platform, built on the open-source LMCache project our founders created, keeps that state across requests in your self-hosted environment. Our separate Serverless Inference service offers an OpenAI-compatible API, and prices cached tokens at $0 per million on most listed models. Better segmentation can improve retrieval on some corpora; caching cuts repeated prefill work. For more on reuse, see our case for why the KV cache is memory rather than cache.
Contact our team to discuss reusing retrieved context across requests.