# RAG chunk overlap: measure lost boundaries and duplicated evidence

Increasing chunk overlap changes both boundary coverage and repeated evidence in a RAG index.

Author: Retrivium team
Updated: 2026-11-03
Canonical URL: https://retrivium.ai/journal/rag-chunk-overlap-duplicate-evidence/
Language: en

Increasing chunk overlap changes both boundary coverage and repeated evidence in a RAG index. Evaluate those effects separately, because a pipeline returning more near-duplicate passages is not necessarily supplying more useful source information.

## Establish the overlap unit

The [recursive splitter guide](https://docs.langchain.com/oss/python/integrations/splitters/recursive_text_splitter) exposes chunk size and overlap together with a length function. Preserve the unit actually used: characters and model tokens are not equivalent budgets. A setting copied from a character-count example cannot be interpreted as a token count without changing its measurement rule. Record separator behavior as well, since requested overlap and actual text boundaries need not describe identical strings across document types.

## Preserve what crosses the boundary

Use a source passage where a definition and its qualification straddle a prospective split. An overlap can retain that relationship, but it can also repeat material already available in neighboring chunks. The [Docling chunking concepts](https://docling-project.github.io/docling/concepts/chunking/) provide a structural alternative worth keeping as a separate control. Do not change overlap, structural policy and embedding model together; each affects which evidence is encoded and retrieved.

## Compare source coverage, not only hits

Prepare an illustrative query requiring evidence from two source documents. Several overlapping chunks from the first source may occupy the entire result budget while the second is missing. Count unique relevant source IDs alongside relevant chunks. Neither count replaces the other: one diagnoses passage retrieval, the other explains whether the returned evidence covers the question's distinct requirements.

| Observation | Failure it can reveal |
|---|---|
| Boundary coverage | A qualification was split away |
| Unique source coverage | Repeated chunks displaced another source |
| Returned text budget | Apparent gains came from more evidence text |

## Keep the comparison budget visible

A fixed hit limit does not produce equal evidence size when chunk lengths change. Preserve both the number of results and the text actually supplied downstream. Avoid declaring a strategy better merely because it returns a longer combined passage. Also inspect duplication inside the final serialized context, since deduplication may happen after retrieval and change what the answer model actually receives.

## Interpret evaluation metrics carefully

The [Ragas metrics reference](https://docs.ragas.io/en/latest/concepts/metrics/available_metrics/) separates context-related evaluation from answer faithfulness. A relevant repeated chunk can still be redundant for the question, and a faithful answer can omit evidence that was never retrieved. Keep source-level judgments with any automated scores. Do not assume that one context metric automatically penalizes every duplication pattern or validates the completeness of an answer requiring several documents.

## Save an overlap decision table

For each tested policy, retain splitter units, separators, actual chunk spans, source IDs and the same held-out questions. Include a boundary-sensitive case and a duplication-heavy case. The useful decision identifies which relationships overlap preserved and what it displaced under the chosen result budget. It should not prescribe one percentage for every corpus or equate a larger index with better retrieval.

Related reading: [Batch text embeddings on your own GPU](/journal/text-embeddings-batch/); [A local RAG server: placing components around the GPU](/journal/rag-server-local-architecture/).