The Short Answer
The right document with the wrong passage almost always means the text was cut in the wrong place before it was indexed. Search does not read your document at query time. It compares your question against pieces that were decided once, at ingest, and a piece that spans two topics matches both weakly and neither well. Fix the cutting before you change the model.
Four causes produce this exact symptom, and they need different fixes: the pieces are too big, the answer sits across a boundary, the piece lost the context that made it meaningful, or the piece is fine and the ranking is wrong. The rest of this page is how to tell them apart in about ten minutes.
Why the right file comes back with the wrong part
Whatever you search over was cut into pieces first. Each piece became one vector, and that vector is roughly an average of everything in the piece.
Averages hide things. A page covering three subjects produces a vector that is a little bit about all three and precisely about none, so it matches a question about any of them just well enough to rank, and never well enough to be the best answer. Meanwhile a short piece that IS the answer competes against long pieces that mention the topic more times.
That is why the file is right and the passage is wrong. The file genuinely contains your answer. The piece that got returned is the one whose average happened to sit closest to your question, and that is a different thing from the piece that answers it.
Tell which of the four you have
Run these in order. Each takes a couple of minutes and rules out a cause.
| Check | What you do | What it means |
| 1. Look at the piece | Print the exact text that was returned, not the document | If it is longer than a few paragraphs, size is your problem |
| 2. Find the true answer | Locate the passage that should have won | If it straddles the end of one piece and the start of the next, boundaries are your problem |
| 3. Read the piece cold | Read only the returned text, no surrounding page | If it is unintelligible alone ("it supports this natively"), lost context is your problem |
| 4. Search the exact words | Query using the literal sentence from the true answer | If it now ranks first, cutting is fine and ranking is your problem |
The four causes and what actually fixes each
Pieces are too big. A vector averages its contents, so the more you put in, the blurrier it gets. Cutting smaller raises precision and costs recall, because now the answer might need two pieces to be complete. The usual working range is a few hundred words with some overlap between neighbours, and the honest way to pick is to try three sizes on your own questions rather than adopt a number from a blog post.
The answer straddles a boundary. A fixed-size cut lands mid-sentence, mid-table and mid-argument. Overlap between neighbouring pieces is the cheap fix, so a boundary-straddling answer appears whole in at least one of them. Cutting on structure, at headings, paragraphs or scene changes, is the better fix where the document has structure to cut on.
The piece lost its context. "It supports this natively" is meaningless alone and was clear on the page. Two techniques address this and they are different: prepending a short summary of the parent section to each piece, or embedding pieces with the whole document in the encoder's context so each vector carries where it sat. Both are covered in chunk contextualization.
The cutting is fine and the ranking is wrong. If step 4 found the passage on an exact-phrase query, the piece exists and is indexed and simply lost. That is a reranking problem, not a chunking one. A cross-encoder reads query and passage together and reorders the shortlist, which is exactly the case it exists for. See debugging retrieval results.
Why this is worse for video, audio and PDFs
Text has natural seams. Paragraphs end, headings start, and a reasonable cut is usually visible in the markup.
A video has none of that. A transcript cut every N seconds will slice a sentence, and a visual cut every N frames will slice an action. The seams that matter are scene changes and speaker turns, and they have to be detected rather than read off the file. A PDF is between the two: the seams are visual, so a naive text extraction produces pieces that cross column boundaries and merge a table with the paragraph beside it.
The general rule holds across all of them. Cut on the boundaries the content actually has, not on a fixed count of characters or seconds. Multimodal chunking strategies covers what those boundaries are per modality.
How this looks on Mixpeek
Chunking is a property of the collection, decided once at ingest rather than per file.
text_extractor@v1 exposes the controls directly:POST /v1/collections
{"collection_name":"docs",
"source":{"type":"bucket","bucket_ids":["{bucket_identifier}"]},
"feature_extractor":{"feature_extractor_name":"text_extractor","version":"v1",
"parameters":{"split_by":"sentence","chunk_size":512,"chunk_overlap":64}}}Two things worth knowing before you tune those numbers. The model behind
For video and audio the equivalent is
There is no correct number, and any page that gives you one without seeing your documents is guessing. A few hundred words with roughly ten to twenty percent overlap is a reasonable starting point for prose. The way to actually decide is to write down ten real questions with their correct answers, index at three sizes, and count how often the correct passage comes back first. That takes an afternoon and beats every rule of thumb, including this one.
Usually not, and it is the most common wasted upgrade. If the passage that answers the question was never a piece on its own, no encoder can retrieve it, because retrieval can only return units that exist in the index. Swapping models changes how well pieces are compared and does nothing about which pieces there are. Do step 1 and step 2 above first; if the answer straddles a boundary, the model was never the problem.
No, it trades precision for recall. Smaller pieces match a question more sharply and are more likely to be incomplete, so the top result becomes exactly right and missing half its context. The failure flips from "right file, wrong part" to "right part, not enough of it", which is the sign you cut too far. Overlap softens the trade; it does not remove it.
Query with the exact sentence you know is the answer. If it comes back first, the piece exists and is indexed, and the problem is that your real question ranks it below something else, which is ranking. If it still does not come back, the passage is not a retrievable unit, which is chunking. That one test separates the two causes that look identical from the outside.
Because video has no seams to read. A document tells you where paragraphs end; a video does not tell you where a scene ends, so a fixed-interval cut slices actions and sentences in half. Cutting on detected scene changes and speaker turns is the equivalent of cutting on paragraphs, and it is the difference between a result that starts mid-word and one that starts where the moment starts.
Partly. Reranking is a query-time change and needs no re-index, so if step 4 pointed at ranking you can fix it today. Anything that changes the pieces, size, overlap or boundary strategy, means re-running extraction over the corpus. That is why the four checks are ordered the way they are: they are cheapest-first, and two of the four outcomes do not require a backfill.
Debugging retrieval results for the ranking half of this problem
Chunk contextualization for pieces that lost the context around them
Multimodal chunking strategies for where the seams are in video, audio and PDFs
Text to embeddings and PDF to embeddings for the conversion itself
Best rerankers if step 4 said ranking
text_extractor@v1 is E5-large-instruct, whose usable window is 512 tokens, so a chunk_size above that is silently truncated and the tail of the piece is never indexed. And vector dimensions are fixed at namespace creation, so changing chunk size is a re-index while changing the embedding model is a migration. Get the cutting right first; it is the cheaper of the two to redo.For video and audio the equivalent is
multimodal_extractor@v1, which cuts on scene changes rather than a fixed interval, so the pieces line up with the content instead of the clock.Frequently Asked Questions
What chunk size should I use?
There is no correct number, and any page that gives you one without seeing your documents is guessing. A few hundred words with roughly ten to twenty percent overlap is a reasonable starting point for prose. The way to actually decide is to write down ten real questions with their correct answers, index at three sizes, and count how often the correct passage comes back first. That takes an afternoon and beats every rule of thumb, including this one.
Will a better embedding model fix this?
Usually not, and it is the most common wasted upgrade. If the passage that answers the question was never a piece on its own, no encoder can retrieve it, because retrieval can only return units that exist in the index. Swapping models changes how well pieces are compared and does nothing about which pieces there are. Do step 1 and step 2 above first; if the answer straddles a boundary, the model was never the problem.
Does making chunks smaller always help?
No, it trades precision for recall. Smaller pieces match a question more sharply and are more likely to be incomplete, so the top result becomes exactly right and missing half its context. The failure flips from "right file, wrong part" to "right part, not enough of it", which is the sign you cut too far. Overlap softens the trade; it does not remove it.
How do I know whether it is chunking or ranking?
Query with the exact sentence you know is the answer. If it comes back first, the piece exists and is indexed, and the problem is that your real question ranks it below something else, which is ranking. If it still does not come back, the passage is not a retrievable unit, which is chunking. That one test separates the two causes that look identical from the outside.
Why does this happen more with video than with documents?
Because video has no seams to read. A document tells you where paragraphs end; a video does not tell you where a scene ends, so a fixed-interval cut slices actions and sentences in half. Cutting on detected scene changes and speaker turns is the equivalent of cutting on paragraphs, and it is the difference between a result that starts mid-word and one that starts where the moment starts.
Can I fix this without re-indexing everything?
Partly. Reranking is a query-time change and needs no re-index, so if step 4 pointed at ranking you can fix it today. Anything that changes the pieces, size, overlap or boundary strategy, means re-running extraction over the corpus. That is why the four checks are ordered the way they are: they are cheapest-first, and two of the four outcomes do not require a backfill.