Full-text-first answering
Full-text-first answering is an approach in which a document that fits within a stated attention budget is placed into the model’s context in its entirety — nothing chunked, nothing ranked, nothing left out — while anything larger is navigated by its own structure and read section by section on demand, rather than cut into fragments and retrieved by similarity.
- Reading budget
- Roughly 25,000 English words
- Above it
- Chapter map, then whole sections
- Index to build
- None
The failure retrieval hides
The standard pipeline cuts a document into fragments, embeds them, retrieves the few that look most similar to your question, and answers from those. When it works, it works well. When it fails, it fails invisibly: the answer is fluent, sourced, and missing the paragraph that would have changed it — because that paragraph never scored highly enough to be retrieved.
You cannot detect this from the answer. There is no signal that says “three relevant passages were not shown to the model.” A good retrieval and a bad one look the same.
That matters most for exactly the questions worth asking:
- Where does the author change position? — the evidence is spread across chapters, and no single fragment contains it.
- What does this paper not claim? — absence has no embedding.
- Where do these two sources disagree? — requires both, and retrieval optimises for similarity to the question, not for coverage of the dispute.
A twenty-page paper fits in a modern context window several times over. Chunking it is solving a problem you do not have. So the first question is not “which fragments are relevant” but “does this fit”. If it does, the model reads what you would read, and the whole class of retrieval-miss failures does not arise.
Looking for one exact sentence — a clause number, a name, a quoted phrase — is a lookup, so it is done as one: keyword search that returns the section to open.
The route depends on the size of the material, decided per document rather than once for the whole architecture.
“Does this fit” is a budget, not the size of the window
This is the part worth being precise about, because “we put your whole document in” is exactly the kind of sentence that should make you suspicious about your bill.
The threshold is roughly 40,000 characters of Chinese, or around 25,000 words of English
— which covers most papers, reports and long chapters. Under it, the text goes in whole. Over it, it does not.
This budget is far smaller than what current models will technically accept. That is deliberate, and it is the actual design claim on this page: the limit that matters is not what fits, it is what a model can still pay attention to. Past a certain volume, the middle of a long context gets recalled unreliably — so pushing more in stops helping and starts hurting, while costing you more. A stated budget with a structured path above it beats a bigger window used carelessly.
Two consequences follow, both about cost:
- The document block is stable, so it is cached. It is assembled the same way every turn and placed ahead of everything that changes, which lets providers reuse it. Asking a second and third question about the same paper does not re-pay full price for the paper each time.
- Nothing is indexed to make this work. No embedding pass, no vector store, no wait while your folder is processed before you can ask anything. Under the budget there is no pipeline at all — the document is simply read.
A document you add to the conversation is read first; the rest of your folder is searched only when the question needs it.
What happens when it does not fit
Books do not fit, and pretending otherwise is the other failure mode. Nor does the answer become “push in more and hope”. It becomes the thing a person does with a book they have not read: look at the structure, then read the parts that bear on the question.
- Structure first. A chapter-level map is built and navigated. Structure is the thing chunking destroys, and it is what questions about a whole book depend on.
- Then whole sections, read on demand. Having decided a chapter matters, the model reads that section in full — not a sliver of it, and not a similarity-ranked fragment. Meaning is not cut off at an arbitrary boundary.
- Search as location, not as recall. Looking for one specific sentence is a lookup, so it is done as one — keyword search that returns a section to open, rather than a guess about which fragment was closest in meaning. Exact terms — a citation, a statute number, a variable name — are precisely what similarity blurs.
The same mechanism scales past a single book. Add several documents to a question and the budget is handed out across them smallest first, so a three-page brief added next to a four-hundred-page book still gets read in full rather than being crowded out. Point a question at a whole folder and nothing is force-fed at all — otherwise the smallest files, relevant or not, would eat the budget. Each document gets a one-line gist, the ones the question needs are picked by what they are about, and they are reached the same way the book is: structure first, sections on demand.
How this differs from “long context solves RAG”
It is not the claim that context windows have made retrieval obsolete. Large corpora still need retrieval, and always will.
The claim is narrower: the decision should be made per document, not per architecture. Most tools chunk everything because chunking everything is simpler to build. That simplicity is paid for by the user, in misses they cannot see.
Where you meet it
- Questions across a folder — the behaviour this page describes
- PDF reader — a paper answered from its whole text
- EPUB reader — what happens when a book does not fit
From the blog: How to ask AI about a whole book · Why there is no vector database in it
Common questions
Does MindMax read the whole PDF, or only parts of it?
A document under the reading budget — roughly 25,000 English words, which covers most papers and reports — is read whole. A longer one, such as a book, is navigated by its chapter map and the sections that matter are read in full, rather than sampled as fragments.
Why not put the whole book into a long context window?
Because what a model can technically accept is more than it can reliably attend to: the middle of a very long context is recalled unevenly, and you pay for every token of it. A stated budget with a structured path above it gives better answers for less.
Is full-text-first an alternative to RAG?
For a single document or a handful, yes: when the text fits, nothing needs to be retrieved. For a large folder, search is still needed — the difference is that it locates documents and sections to read in full, rather than handing the model a few fragments as the answer’s only evidence.
Does reading the whole document cost more?
The first question about a document pays for reading it. Because the document block is assembled identically each turn, providers can cache it, so follow-up questions about the same paper do not pay full price for it again.