Character-Threaded Summarization for Long Documents

Once I got over the initial shock that GPT-3 could write surprisingly good summaries aimed at different targets—summaries for a fifth grader, or genuinely coherent TL;DRs that weren’t just the single “most important sentence” pulled out of a document—summarization became one of the most interesting areas to explore.

It also took me a little while to appreciate why summarization is such a slippery problem: people disagree, often strongly, about what counts as a “good” summary.

Some of the early “summarization” demos that impressed audiences were basically doing extraction—selecting a handful of key sentences and stitching them into a paragraph. I remember seeing people rave about a summarization model from another company, and when I looked closely, that was all it was doing. At the same time, I saw other demos that were genuinely good. The bar kept shifting as people calibrated what these systems could actually do.

But the hardest part of summarization—the thing we’ve only relatively recently started to wrap our heads around and improve substantially—is that it gets dramatically more difficult as documents get longer.

On one level, you can always produce a simple “here’s what happened” summary. The problem is that, in long-form text (especially narrative), “what happened” isn’t always stable. It depends on time, perspective, and later revelations that reverse earlier claims. If you compress aggressively, the first thing you tend to lose is the distinction between:

• what a character believed at the time,
• what the text implied temporarily,
• and what ultimately turned out to be true.

Before getting into my preferred approach, there’s a practical setup step that’s easy to forget but makes everything that follows work better—especially for long fiction and complicated nonfiction:

A first pass is to ask the model to identify all of the characters (or entities) in the story.

A second pass is to ask it for all of the locations and then the key events.

Even just that—characters, locations, key events—creates a scaffold. It gives you an inventory of “what exists” in the document, which you can then use to drive more reliable summaries instead of hoping a one-shot prompt will notice everything important.

Why long documents break summaries

Fiction makes the core failure mode obvious. If you’re summarizing something like the plot of Harry Potter, it sounds straightforward until you remember how stories work: red herrings, reversals, and characters being told things that later turn out to be false. A model trying to compress a long story might grab a statement that’s only true from a character’s limited point of view and present it as fact in the final summary.

A concrete example: Harry is told early on that his parents died in a car accident. A naive long-document summary might repeat that as a factual plot point—“his parents died in a car accident”—even though we, as readers, eventually learn this was a lie meant to cover up their murder by Voldemort.

When I looked at early attempts to summarize long texts, this kind of error showed up again and again. It wasn’t that the model couldn’t paraphrase. It’s that long narratives contain counterfactuals, reversals, and perspective-dependent claims—and those are exactly the things that get mangled when you compress aggressively.

Once you notice that, you start to see the same pattern outside fiction too. Nonfiction has fewer deliberately misleading statements than novels, but reversals still happen all the time:

• Someone gets married and changes their name.
• Someone’s education level changes over time.
• Someone gets convicted and later exonerated.
• An early description is updated by later information.

The structure is different, but the problem rhymes: long documents often contain “facts” that are only locally true.

A different approach: summarize the world-lines, not just the document

That’s the point where I started thinking about summarization differently. Instead of treating it as “summarize the entire body of text in one shot,” I began thinking of it as:

Summarize the world-lines of the entities inside it.

By “world-lines,” I mean the storyline of each major character (in fiction) or each important entity (in nonfiction): what happens to them, in what order, and how later events correct or reinterpret earlier ones.

This is less like writing a single abstract, and more like building a structured intermediate representation first—then summarizing from that representation.

A workflow that scales better on long text

Here’s what that looks like in practice. If I wanted to summarize a story like Dracula, I wouldn’t start by asking for a single global summary. I’d do it in stages.

Stage 1: Build the inventory

1. Identify all characters.
2. Identify locations.
3. Identify key events.

This is the “map” of the document. It helps ensure you don’t forget important threads, and it gives you handles for the next step.

Stage 2: Create world-lines (entity-by-entity timelines) Then I’d break the narrative down by character and ask for something like:

• Tell me everything that happens to Jonathan Harker. Go through the text, extract his journey, build a timeline, and summarize it.
• Do the same for Mina—what happens to her, in order, and what it amounts to.
• Do the same for Professor Van Helsing and any other major characters, each on their own.
• And of course: Dracula himself. What happens to Count Dracula over the course of the story? How does his arc evolve?

The key move here is that you’re not asking for “a summary” yet. You’re asking for coherent, time-ordered accounts for each major thread.

Stage 3: Combine the threads into a unified summary Once you have the individual timelines and character-level summaries, then you combine them into a unified summary of the whole work.

At that point, the “global summary” is no longer trying to do everything at once. It’s integrating already-summarized strands.

Why this works better

This approach does a few useful things.

First, it makes it more likely you’ll include important details from each major thread, rather than letting one character dominate the summary simply because they have more “summary-friendly” sentences.

Second, it forces the model (or the process) to deal with time and change—so reversals are harder to miss. If a character believes something early on and learns the truth later, a timeline has to reconcile that. A one-shot summary often doesn’t; it collapses “belief at time t” into “fact overall.”

Third, it matches how many long documents are actually structured. A lot of texts aren’t a single narrative. They’re multiple intertwined narratives—multiple entities evolving over time. When you summarize per entity first, you’re respecting that structure instead of fighting it.

The broader principle

For me, the larger principle is this: when the source material is complex, don’t try to compress everything at once.

Summarize the threads first, then summarize them together.

You tend to get stronger, more faithful results—especially as documents get longer, the number of entities increases, and the number of “locally true, globally false” statements rises.