When the document is already a chunk
A knowledge base has four thousand help articles, each two paragraphs long and each answering one question. The ingest pipeline runs a splitter over them because the ingest pipeline runs a splitter over everything. Now half the articles are two chunks, one of which is the paragraph that does not contain the answer.
Some corpora arrive already divided into units of meaning by the people who wrote them. When that is true, splitting is not a neutral operation you can leave on by default. It is destruction of structure somebody already supplied.
Which corpora are already chunked
FAQ entries. A question and its answer. The unit is obvious, self-contained, and phrased as a question, which is exactly the shape queries arrive in.
Short help and support articles. One article, one problem, one resolution. If the median article fits well within your size limit, the article is the chunk.
Tickets, issues and support conversations. One ticket is one problem. It has a title that states it and a body that resolves it.
Product and catalogue records. One row, one product. Name, description, attributes.
Reference entries. API endpoints, error codes, CLI commands, glossary terms, configuration keys. Each entry is a complete, bounded description of one thing.
Log and event records. Bounded by construction.
The test is simple: does one document answer one realistic question, and does it fit? If yes, the splitter’s only correct behaviour is to pass it through.
The split, shown
=== SPLITTER APPLIED BLINDLY ===
--- chunk 1 ---
Why is my export empty?
An export contains only rows the requesting user has
permission to read. If your export is empty, the most common
cause is that the export was created by a service account
without read access to the relevant workspace.
--- chunk 2 ---
Grant the service account read access to the workspace and
re-run the export. Exports are not retried automatically, so
the original empty file remains until it expires.Query: “how do I fix an empty export?”
Chunk 2 has the fix and does not contain the words “export is empty,” “permission,” or “service account.” Chunk 1 has the diagnosis and no remedy. The article was one coherent answer and the splitter made two incomplete ones, each of which will sometimes be retrieved alone.
=== PASSED THROUGH AS ONE CHUNK ===
--- chunk 1 {doc_type: help_article, article_id: KB-2214} ---
[Help Centre → Exports → Why is my export empty?]
Why is my export empty?
An export contains only rows the requesting user has
permission to read. If your export is empty, the most common
cause is that the export was created by a service account
without read access to the relevant workspace.
Grant the service account read access to the workspace and
re-run the export. Exports are not retried automatically, so
the original empty file remains until it expires.One chunk, one question, one complete answer, and the title — the most matchable text in the whole document — is inside it.
What to do instead of splitting
1. Make pass-through the explicit behaviour, not an accident of size. A splitter that happens not to split a short document is doing the right thing for the wrong reason, and it will start splitting the day somebody adds a longer article. Route these document types to a no-op splitter deliberately, which is what routing is for.
2. Keep the title in the body. For question-shaped documents this is the single most important field, because the title is a question and the query is a question. Prepend it to the text you embed as well as storing it as a field.
3. Spend the effort on metadata instead. Since you are not making splitting decisions, all the available quality is in the fields you attach — product area, category, audience, status, dates. On a corpus of small records, filtering does far more than anything else you could do.
4. Set an explicit ceiling with a structural fallback. Some articles will be long. Define the size above which you do split, and split those on their own headings rather than on characters. The rule is “split the long ones structurally,” not “split everything just in case.”
5. Handle records with a serialisation, not a split. For a product row or a config entry, the decision is not where to cut but how to render the fields as text worth embedding. A sentence reads better to an embedding model than a pipe-delimited row, for the same reason it does inside a table. Keep the structured form as fields for filtering and the sentence form as the text.
6. Consider merging upward instead. The opposite problem: a corpus of one-line entries produces thousands of near-identical tiny chunks. Grouping related entries — all error codes in one family, all config keys in one section — is sometimes better than one chunk each. That is the merge decision rather than a split decision.
What this corpus shape costs you
Many small chunks, competing with each other. A thousand FAQ entries about billing are all somewhat similar. Any query about billing has a thousand plausible candidates and the differences between them are small. This is real and it is not fixed by chunking; it is fixed by the metadata filters in step 3.
Duplication across records. The same answer exists in a help article, a ticket resolution and a release note. All three are legitimately in the corpus and all three will come back. Deciding which source is authoritative is a corpus decision to make deliberately.
Records that are not self-contained after all. A ticket that says “same as the last one” or “see attached.” A product variant whose description is on the parent product. These look pre-chunked and are not.
Titles that do not describe the content. Bug, Question, Not working. Common in ticket corpora,
and it removes the advantage that made this document class easy.
Answers that span records. A resolution that requires two help articles. The unit is right for one question and wrong for a compound one, and there is nothing at the chunking layer to do about it.
How to tell whether you are splitting something you shouldn’t
One query against your index answers this: group chunks by source document and count. Sort descending, then look at the bottom — the documents that produced exactly one chunk — and at the documents that produced two.
The two-chunk documents are the interesting ones. A document that produced two chunks was just over your size limit, which means it was a single coherent unit that got cut roughly in half, and the second half is usually the part with the conclusion in it. If a large share of your corpus sits at exactly two chunks, your size limit is falling in the middle of your typical document and you are systematically halving your best material.
Then read a few of those pairs. It takes a couple of minutes, it is the same habit as reading fifty chunks, and it will tell you immediately whether the answer is a higher ceiling, a structural fallback, or no splitter at all.