An uploaded 300 page manual: the assistant answers well about early pages but ignores later ones
A user uploads a 300 page product manual. The assistant answers accurately about content from the first dozen pages but acts as if anything in the back half of the document doesn't exist. Walk through the likely causes and how you would confirm and fix each.
Early-works-late-fails is a coverage bug: either ingestion truncated the doc so late chunks were never indexed, or retrieval can't reach them. Confirm by counting chunks per page; don't stuff the whole manual in.
Imagine you photocopy a 300-page book to make searchable index cards, but your copier jams after page 30. Now anyone searching only ever finds cards from the front of the book — the back half might as well not exist. That is one cause: the upload step quietly stopped partway, so the later pages never became searchable cards at all. The other cause is subtler: all the cards exist, but you only ever pull the five cards that look closest to the question, and the front of book cards keep winning that contest. Either way, the fix is to make sure every page becomes a findable card and that your search reaches deep enough — not to dump the entire book on the reader's desk and hope.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
This is one of the most common real bugs in production RAG, and it is a great interview scenario because the symptom is so specific it almost names the diagnosis for you. "Early pages work, later pages are invisible" is not a vague "the answers are bad" complaint — it is a positional pattern, and positional patterns come from how data flows through ingestion and retrieval, not from how the model writes sentences.
The trap the question is built to catch is the candidate who hears "300-page document" and immediately reaches for context-window size. That instinct skips the actual failure and proposes a fix that bypasses retrieval entirely.
This deep dive walks through reading the symptom correctly, the two coverage causes and how they differ, the direct way to confirm which one you have, and why the obvious "just feed it the whole manual" move is the wrong answer.
Reading the symptom: why position is the whole clue
The first job is to interpret the failure shape, because it rules out most of the search space for free.
If the assistant were hallucinating or generating poorly, the errors would scatter — wrong answers about early pages too, or confident nonsense regardless of where the content lives. Instead the failure respects page order: front reachable, back invisible. Generation does not know or care what page a chunk came from, so a generation bug cannot produce a clean positional boundary.
That leaves the data pipeline. Content reaches the model only by being chunked, embedded, indexed, and then retrieved. A positional cutoff means something in that pipeline processes the front of the document and not the back.
So before touching the prompt, the system prompt, or the model choice, you commit to a coverage hypothesis. The question becomes binary: did the late pages make it into the index at all, and if they did, can retrieval reach them? Everything downstream is diagnosis between those two branches. Stating this framing explicitly is what a strong answer does first — it shows you read symptoms structurally instead of reaching for the most familiar knob.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- A PDF parser silently returning partial text on a malformed page, so chunks for the later pages are never created or embedded.
- A RAG pipeline with top-k of 4 over thousands of chunks, where early-page chunks consistently edge out relevant deep-page ones.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you build a verification step that catches ingestion truncation automatically?
Assert expected chunk count against document length or page count after ingestion, and alert when stored chunks cover only a prefix of the page range.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Jumping to 'the model has a context limit, so let's stuff the whole 300-page manual into the prompt' — that bypasses retrieval, blows up cost, and triggers lost-in-the-middle instead of fixing the real coverage bug.
60 second bullets to scan on the way to the call.
Why a positional cutoff points at coverage rather than generation
Ingestion truncation: parser failure, character cap, token limit
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.