How to Analyze a Long Document With AI (2026)

You are reading Chapter 18 of 36 in the AI Bootcamp, AI Central's free course for professionals who want to use AI in their own work. The chapters build on each other, so if this is your first one, Chapter 1 is the place to start. All of them sit on the AI Bootcamp page, and three more arrive every week.

To analyze a long document with AI, stop asking it to summarise and start putting questions to it: what the document is, what it claims, what it supports, what it leaves out, and what it wants you to do next. Six questions, sent one at a time, get you further than any summary will.

This guide shows you where a long document actually fails an assistant, gives you the 6 questions to run in place of a summary request, and ends with a check that takes seconds.

We publish AI systems like this for 300,000+ senior professionals at AI Central, and more of them live in the AI Central Library.

Ask for a summary of a 90-page document and you get back something fluent, confident and well organised, which has quietly left out the one paragraph that would have changed your decision.

You cannot tell which paragraph, because the summary is now the only version of that document you have read. Nobody has ever been caught by a bad summary. People get caught by a good one.

A summary is judged on how it reads. It is never judged on what it left out, because you cannot see that.

This chapter assumes you have a prompt library started, even if it holds only two templates. Chapter 17 sets one up. Bring one long document from your own work: a contract, a board pack, a policy, a research report, something you would rather not read twice.

Every one of these tools will accept a document far longer than you would ever read yourself. None of them promises even attention across all of it.

Capacity is the number the vendor publishes. Claude takes up to 500MB per file and 20 files per chat, PDFs to 1,000 pages, though past 100 pages it stops reading the charts and images and reads only the text. ChatGPT has a hard 512MB per file plus a separate cap of roughly 2 million tokens of text, so a small file can still be too long. Gemini takes 10 files per prompt at 100MB each, and Google describes its 1 million token window as around 1,500 pages of text. Copilot in Word summarises documents up to roughly 80,000 words, and Microsoft states that it does not always cite the later parts of one.

Getting the file in is the easy half, and it was Chapter 7's job. Formats, attaching versus pasting, and telling what the assistant did not read all live there. This chapter starts once the document is already in the chat.

Recall is the other quantity, and it behaves differently. Accuracy is highest for material at the very start of a long input and at the very end, and lowest through the middle. That has been documented since 2023 and has survived every generation of model since. One 2026 evaluation ran 17 long-context models and found every one of them losing accuracy as the input grew. Larger context windows did not remove the effect. They gave you more middle.

A 2026 study isolated length itself. Even when the surrounding filler was stripped down to blank space, so there was nothing to distract or confuse, performance still fell as the input got longer. A document of 200 pages is harder for the tool to work with than the same content in 20, quite apart from what is in it.

The assistants are not identical here. Gemini now handles single-fact retrieval from very long inputs well wherever the fact sits, and every model on the market is better at this than its predecessor. What no production model has done is remove position effects, and the gap between finding one fact and reasoning over several scattered ones is where the remaining failures are.

The habit worth building is small. Before you ask anything, know roughly where in the document the thing you care about sits. If it sits in the middle of a long file, that is the part you check first, not last.

Summarise this is the first thing almost everyone types and close to the last thing an analyst would. It is also the only request whose output you have no way of checking.

There are four attitudes you can take to a document, and only the bottom three produce something you can go and verify. Summarise compresses it and leaves you nothing to check the result against. Extract gives you named things, each with where it sits. Interrogate answers your own questions out of the text. Challenge tells you what is missing, unsupported, or being sold to you.

A summary fails silently. One that dropped the indemnity clause, the covenant, the single dissenting paragraph in the appendix reads exactly like one that kept them, and you will never know which you are holding. You asked it to throw most of the document away, and it did, using its judgement about what mattered rather than yours.

It is also the request that plays worst to the tool. Research found that faithfulness in long generated summaries falls off toward the end of the output, so the later paragraphs of a long summary are the least trustworthy part of it, which is not where anyone expects the weak spot to be. Omission has also been studied far less than invention, though at work it is the more expensive failure. An invented fact can be spotted. An absent one cannot.

Extraction is a better question because it produces something falsifiable. Every obligation with a date attached. Every named party. Every commitment the document makes that has a number or a deadline in it. Ask for those as a list with locations and you have output that can be wrong in a way you can detect, which is the only kind of output worth having.

Interrogation is better still, and it is what separates an analyst from a reader. An analyst does not compress a document. They arrive with a question, put it to the document, and use the document to answer it. The 90 pages are not the deliverable. Whatever you needed to know is.

Challenge is the level almost nobody reaches. What is this document not telling me. Which of these claims does it support and which does it simply assert. What would somebody who disagreed with this say. You can ask an assistant all three, and it will answer them.

Not a summary request. A reading pass you run in the same order every time, on every document, which makes it exactly the sort of thing worth saving as a template.

What is this document, who produced it, and what does it want its reader to do. Ask this first even when you think you know. The answer frames every other answer, and an assistant will often name an audience or a purpose you had not considered.

What are the claims this document most wants me to accept. Quote each one exactly and tell me where in the document it sits. Everything after this question depends on it, and it is the one people skip. You are asking for words that exist rather than words about words.

Which of those claims does the document support with evidence inside itself, and which does it simply assert. This one line does most of the analytical work. Documents that are trying to persuade you tend to be evidence-heavy exactly where it does not matter and assertion-only exactly where it does.

What would a document of this kind normally contain that this one does not. What a document leaves out is very often the entire point of the document, and this is one of two questions a summary is structurally incapable of answering.

Where does it contradict itself, or quietly change what a term means partway through. That is the other one, and both are about what is not on the page.

If I act on only one thing in here, what should it be, and what would have to be true for that to be the wrong call. It gives you the decision and its own failure condition in one answer, which is a more useful pair than a conclusion on its own.

Send these as 6 messages in one thread, not one message with 6 parts. Six questions in one prompt buys you six shallow answers. And on anything genuinely long, run the pass over the document in sections rather than in one go: a 200-page document is the clearest case there is for splitting a big job into steps.

Almost nothing over 10 pages is neutral. Something in there is arguing for something, which is why questions 4, 5 and 6 are worth the extra messages.

The rule is one line long: every claim arrives with the words it came from and where they sit, in the same message. Put it in the instruction itself. If a claim cannot be supported by a passage from the document, say so instead of stating it.

Then read down this list until a line is true. It quoted, and you found those words: use it. It quoted, and you cannot find them: drop the claim. It gave a location but no words: go and read that part. It gave neither: you have a summary.

This works for a reason worth knowing. Evaluation work found that finding real material and refusing to invent material are separate abilities in these models, not one ability. Two models scored within a point of each other on locating facts that genuinely were in a source, and differed by more than 40 points in how often they stated facts that were not. You cannot infer one from the other, and a fluent answer tells you nothing.

What you can do is check, and it costs seconds. Copy 6 or 7 words out of a quote it gave you and search the original document for that string. Extracting text verbatim is one of the things these tools do most reliably, with error rates in published tests running in the low single digits, which is what makes a failed search meaningful. If the words are not there, the claim resting on them goes. No argument, no second opinion.

That catches invention. The opposite failure, the thing it never mentioned at all, needs a different check. Ask for every instance of something as a numbered list with locations. Then ask the same question again over the first half of the document only, then over the second half only. If the two halves add up to more than the single pass found, the single pass missed something, and you already know where to expect it to have gone missing.

Both checks together cost two extra messages and a search box. You are not going to do this for every document you read, and you are not meant to. Do it for the ones you are going to act on, sign, forward to a board, or repeat out loud in a room where somebody knows the document better than you do.

The chapter closes with 3 exercises that take about 20 minutes. Take the document you brought, run question 2 on it, and check one of the quotes. That single check will tell you more about how far to trust this tool than any amount of reading about it.

Before: you hand over a 90-page document, get back four confident paragraphs, and have no idea which parts of those 90 pages the assistant actually looked at.

After: you put 6 questions to it instead, you get claims with the words they came from and where they sit, and you can prove in seconds whether an answer came out of the document or out of the model.

Two things carry into Chapter 19: the document you interrogated, and one quote you checked against the original. Chapter 19 keeps that same document open and turns to the figures inside it, where an assistant is reliable with numbers and where it produces arithmetic that looks right and is not.

If you want help phrasing the questions themselves, the 26 principles of prompt engineering covers how to write an instruction that does what you asked. For a one-page reference to keep beside you while you work, start with our free AI cheat sheets, and the rest of the syllabus lives in the AI Central Library.

It will accept one. Claude takes PDFs up to 1,000 pages, Google describes Gemini's 1 million token window as around 1,500 pages of text, and ChatGPT caps a file at 512MB plus roughly 2 million tokens. Accepting a document and reading all of it evenly are different claims: accuracy is highest at the start and the end of a long input and lowest through the middle.

Because you have no way of checking the result. A summary that dropped the clause you needed reads exactly like one that kept it, and it is now the only version of the document you have read. Extraction, interrogation and challenge all produce output you can go and verify against the file. A summary does not.

Six questions, one per message: what the document is and who made it, its main claims quoted with locations, which claims it supports and which it asserts, what a document like this usually contains that this one does not, where it contradicts itself, and the one thing to act on plus what would make that the wrong call.

Copy 6 or 7 words out of the quote and search the original document for that string. Verbatim extraction is one of the most reliable things these tools do, with error rates in published tests in the low single digits, so a failed search is meaningful. If the words are not there, drop the claim.

Ask for every instance of the thing as a numbered list with locations, then ask the same question again over the first half of the document only, then the second half only. If the two halves add up to more than the single pass found, the single pass missed something.