DEV Community

Hanako H.
Hanako H.

Posted on

Why AI Gets Sloppy at the End of Long Documents

When you ask an AI to summarize or proofread a long document, the second half often gets noticeably worse treatment. The main causes are that a model can only take in a limited amount of text at once, and that with long inputs, its attention to the middle and later parts tends to thin out. Splitting the document and repeating your instructions with each chunk restores most of the accuracy.

Writers who use AI to clean up interview transcripts or revise long drafts run into this "sloppy second half" problem again and again. This article explains why it happens and lays out a way of feeding documents to AI that holds up in practice.

Spotting the "only the first half is careful" pattern

A typical case: you ask for a summary of a 15,000-word interview. The opening topics come back summarized in detail, down to speakers' names and figures, while the closing topics are compressed into a single line like "future plans were also discussed." Proofreading shows the same pattern. Flagged issues cluster in the first half, and obvious mistakes in the second half slip through.

It's tempting to joke that the AI got bored halfway through. But if you halve the input and the second half comes back with the same level of detail, it's clear this is a volume problem. Looking into the mechanics, the cause breaks down into a few distinct parts.

Why the second half gets less attention

There are three main reasons, and they are separate phenomena.

1. The limit on how much the model can read at once. Every AI model has a context window, a cap on how much text it can handle in a single pass. Anything beyond that cap is usually cut off or automatically compressed by the tool, and chat interfaces rarely tell you clearly when this happens. So the second half may not be handled sloppily; it may not have been read at all.*

2. "Lost in the middle," even within the limit. Research has shown that with long inputs, models are more likely to miss information in the middle than at the beginning or end. The latter third of a document often overlaps with this hard-to-reach middle zone.

3. The limit on output. Responses have a maximum length too, so the longer the input, the harder the summary has to compress. Because models write from front to back, the squeeze from a shrinking output budget tends to land on the later parts. That's where the "three paragraphs for the first half, one line for the second" imbalance comes from.

If you work in a language other than English, there's one more factor. The same content often consumes more tokens (the units AI uses to count text) in other languages than in English, so you hit the limit sooner than you'd expect. That explains why advice like "just process it all at once," written with English text in mind, doesn't always hold up.

* For a concise explanation of the concept, see the context window entry in the glossary from osFoundry, a desktop AI app.

A practical way to split documents

The basic fix is to feed the document in parts. But splitting at random won't do; a few techniques make the difference.

Split by meaning, not by length. Cut at chapters or sections. Cutting mechanically by word count can break a topic in the middle and lose context. Around 5,000 words per pass is a reasonable starting point, for example, but the right size depends on the model and the task, so find the amount at which the second half stops degrading in your own setup.

Repeat the instructions every time. If you write something like "Point out typos and questionable facts in this text. Do not change any proper nouns" only in the first message, accuracy can drop from the second chunk on. Copy the instructions and paste them into every pass. It's tedious, but it's the single most effective change.

Watch the conversation history. In a long chat, everything said earlier also counts toward what the model has to read. A chunk that would fit on its own can push you toward the limit once previous exchanges have piled up. Start a new chat for each chapter, or paste only the key points you want to carry over at the top.

Summarize in two stages. First have each chapter summarized, then line those summaries up and ask for an overall summary. It takes more effort than one big pass, but later topics no longer get lumped into "other."

Change the order when proofreading. Feeding chapters front to back means the most careful attention always lands on the beginning. Send the later chapters first, and the part most likely to be overlooked gets the most thorough check. When a deadline leaves no time to split everything, a shortcut is to pull out just the second half and show it first.

Some tasks don't work when split. Unifying inconsistent terminology or spotting contradictions between the first and second halves requires seeing the whole document. For these, separate extraction from judgment: have the AI pull candidate inconsistencies from each chapter, and let a human compare them at the end. That way the split approach still works.

Here are the fixes by symptom:

Symptom Likely cause Fix
Later topics barely appear in the summary Input exceeded the limit and was cut off Split by chapter and send separately
The overall gist is there, but the middle is thin The model missed information in the middle of a long input Split, or move the important parts to the top
Detailed first half, one-line second half Compression due to the output length limit Summarize per chapter, then combine in a second pass
Fewer issues flagged with each pass The instructions are losing their effect Paste the instructions again every time

FAQ

Can I skip splitting with the latest models that advertise long-context support?
Context limits keep growing, and more documents fit in a single pass than before. But missing information in the middle and compressing the output are tendencies that remain even as limits expand. For work where accuracy matters, splitting is still the more reliable choice for now.

Is there a way to write prompts that improves summary accuracy without splitting?
Specifying the output structure helps. State both the format and what must not be dropped, for example "about 150 words per chapter" and "keep every proper noun that appears." If the second half still loses detail, it's a volume problem, and it's time to switch to splitting.

Is there a rule of thumb for how long a document can be before splitting?
It varies with the combination of model and tool, so there's no single number. A better guide is to watch for symptoms: if later proper nouns vanish from the summary, or flagged issues cluster in the first half, resend the document in chunks half that size.

Top comments (0)