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.
Free · 2 AI evals / day
The clue is in the pattern. Early pages answer fine, later pages act like they don't exist. That positional cutoff tells you the problem is in how the document was indexed or retrieved, not in how the model generates.
There are two likely causes. First, **ingestion truncation**: a parser, character cap, or token limit stopped reading partway through, so the later pages were never turned into chunks or embedded. They are simply not in the index, so retrieval can never find them.
Second, retrieval reach: the document is fully indexed, but top-k is too small for a 300-page corpus. The few slots fill with early-page chunks, and relevant late-page chunks lose the ranking.
To tell them apart, look in the index. Count the chunks stored for that document and check whether any map to the back half. Missing chunks means ingestion; present but never retrieved means retrieval. The fix you avoid is dumping the whole manual into the prompt.
A positional cutoff — front pages reachable, back pages invisible — is a coverage symptom. It is almost never a generation problem, so resist debugging the prompt.
Two causes dominate. The first is **ingestion truncation**. A PDF parser failed past a certain point, or a character/token cap stopped the pipeline partway, so chunks for the later pages were never created or embedded. That content is not in the index at all, which is exactly why no rephrasing of the query ever surfaces it.
The second is retrieval reachability. The whole document indexed cleanly, but retrieval cannot reach deep chunks. Top-k is too small relative to 300 pages, so the slots fill with early-page chunks that happen to rank slightly higher. Or a per-document cap returns only the first few hits.
Confirm by inspecting the index directly. Count the chunks for that document id and check whether any map to page ranges in the back half. Missing chunks means ingestion — repair the parser and limits, then verify full-document chunking end to end. Present-but-unretrieved means retrieval — raise top-k, add a reranker over a wider candidate set, or check the query can actually match deep content.
The wrong fix is stuffing the entire manual into the context window. That defeats retrieval, spikes cost, and hits lost-in-the-middle. The goal is to make every page reachable by retrieval, not to bypass it.
Quick reference
TL;DR
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.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Reaching for a bigger context model before confirming the late pages are even indexed If ingestion dropped the back half, no context size helps; the content has to exist in the index first.
Raising top-k as a blanket fix without inspecting whether chunks exist A larger top-k cannot retrieve chunks that were never created, so it masks an ingestion bug instead of fixing it.
Adding a reranker when the candidate pool itself never contains deep-page chunks Reranking only reorders retrieved candidates; if deep chunks never enter the pool, reranking changes nothing.
Trusting the ingestion pipeline's success status as proof of full coverage Parsers often return partial text and report success, so coverage must be verified by counting stored chunks.
Quick scan · 2–4 min
Everything important, quickly.
5 min: read the positional cutoff as a coverage symptom, separate ingestion truncation from retrieval reachability, confirm by counting indexed chunks per page, apply the matching fix, and reject the stuff the whole doc anti-pattern.
Real-world examples
Real products, models, and research that use this idea.
1A PDF parser silently returning partial text on a malformed page, so chunks for the later pages are never created or embedded.
2A RAG pipeline with top-k of 4 over thousands of chunks, where early-page chunks consistently edge out relevant deep-page ones.
3Inspecting a vector store by document id and bucketing chunks by page metadata to prove whether the back half was ever indexed.
Interviewer follow-ups
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?
Sign in or go Pro to see the approach for this follow-up.
QThe chunks exist for late pages but a query about page 250 still fails — what now?
Sign in or go Pro to see the approach for this follow-up.
QWhy is feeding the whole 300-page manual into a long-context model still the wrong call here?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
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.