Choose document boundaries before chunking a RAG corpus

Chunking a handbook starts with deciding what one source means. If a parser joins unrelated sections before splitting them into fixed-size pieces, a retrieved passage can mix an instruction with an exception that belongs to another topic.

Consider an authored operations handbook containing "Password reset", "Account deletion" and "Billing contacts". Give the handbook a source ID, then preserve each heading as a section with its own stable identifier. Record the extracted text offsets before creating smaller passages.

A useful chunk record might carry these fields:

source_id: handbook
source_revision: revision-7
section_id: account-deletion
heading: Account deletion
start_offset: 1840
end_offset: 2460
text: ...

These are synthetic fields for an application design. Define whether offsets count Unicode code points, bytes or another unit. A citation renderer and an ingestion pipeline must use the same convention.

The Sentence Transformers semantic-search guide describes embedding corpus entries and queries into a comparable vector space. The document and passage boundaries you feed into that process remain a corpus-design decision.

Document headings becoming chunks with provenance tags.

Inspect what can stand alone

Read each proposed chunk without its neighboring text. A passage beginning "This exception applies only here" has lost the subject that explains it. Preserve the parent heading and enough adjacent context to resolve that reference, or keep the relevant paragraph together.

A heading is a useful clue, but it is not always a complete boundary. A long section may need several chunks. A short warning may need to stay attached to the procedure it limits. Tables can require a repeated header so the rows retain their meaning.

Keep structural metadata separate from text that will be embedded. Prepending a heading can help a passage make sense, but repeating the entire document outline on every chunk can overwhelm the content being searched. Test with queries aimed at the actual tasks readers perform.

Build a boundary fixture

Write one question whose answer sits entirely inside a section and another whose answer needs a procedure plus its exception. Label the expected source spans before running retrieval. Then inspect whether the returned text contains the complete support needed for each answer.

Include two sections that use similar vocabulary for different actions. If a password-reset question retrieves account-deletion instructions, review both the chunk contents and the query's intent before changing the embedding model.

Good boundaries make results easier to inspect and cite. They cannot guarantee retrieval recall or a faithful generated answer. Preserve the original source revision so a reviewer can distinguish a bad answer from a later document edit.