Summarisation (AI)

What is summarisation?

Summarisation is producing a shorter text that keeps what matters from a longer one. It is the AI feature people in a company use most and check least: the meeting recap in the inbox on Thursday morning, the summary at the top of a support case, the two paragraphs standing in for a forty page report nobody had time to read.

There are two ways to shorten a text, and the difference decides how much you have to verify.

Extractive summarisation picks sentences out of the source and puts them next to each other. Microsoft's Azure AI Language service works that way: every sentence gets a rank score, the highest scoring ones come back, and each one carries the character position where it stood in the original.

Abstractive summarisation writes new sentences. The same Microsoft documentation calls them concise, coherent sentences that are not verbatim extracts from the source. That is what ChatGPT, Claude and Copilot do when you ask them to summarise something.

One question separates the two: can you find that exact sentence back in the source with ctrl-F? With extraction, always. With abstraction, almost never. That is why an abstractive summary reads better, and why it can be wrong in a way extraction cannot be. A sentence that was assembled instead of copied can carry a fact that was never in the source.

Four summaries, four different jobs

People say "summarise this" as if it were one task. In a company it is at least four, and each one fails differently.

1. The meeting summary. What was decided, who does what by when, what stayed open. A decision that comes back as "the team discussed the supplier options" threw away the only thing anyone needed.

2. The thread summary for a handover. A colleague picking up a case with sixty mails in it needs the customer's question, what has been promised and where it stands, in the customer's own wording where the wording is the point.

3. The document summary with the numbers intact. A quote, a contract, an audit report. Figures, dates and conditions have to come across exactly, and whatever is left out has to be visibly left out.

4. The summary of many documents. Twenty surveys, a year of tickets, five supplier offers. This one is harder, because the model has to work out what is common, what is an outlier and what contradicts what. "Most customers mention delivery times" is a count, and a language model does not count reliably. Do the counting in a query and use the model only for the wording.

What goes wrong

Microsoft says it plainly in the responsible AI note for its own summarisation service: the model paraphrases instead of extracting, and there can be information or accuracy loss. That is the honest baseline.

Facts that were never in the source. This is hallucination in its most ordinary form, and it is measurable. Vectara, a company that builds retrieval systems, runs a public leaderboard for this: models get a text and the instruction to summarise it using only the information in the passage, and a detector counts how many summaries add something the source does not support. On the version published in November 2025, built on more than 7,700 articles from areas including law, medicine and finance, the best model came in around 3 percent and several well known models sat above 10 percent. Those are short texts with an explicit instruction, so that is the easy case.

A number that quietly moves. Rounding, a percentage turned into an amount, a decrease reported as an increase, a total that no longer matches the rows above it. Nothing looks wrong, because the sentence around the number reads fine.

The caveat dropped and the conclusion kept. The most common failure and the hardest to notice. "We can go live in April if the stock count is finished in March" becomes "go live in April". Shorter, easier to read, and a condition has become a promise.

The loudest voice wins. Whoever talked most produced most of the transcript, so they get most of the summary, and a one sentence objection at minute fifty drops out. Microsoft adds that its conversation models are trained mainly on transcripts between two participants and do less well on other genres, worth knowing before you point one at a workshop with twelve people.

The summary of a summary. A long document does not fit in one context window, so chunking splits it first, each chunk gets summarised, and the summaries get summarised again. OpenAI's own recipe for long documents works this way and warns when chunks are dropped because they overflow. Every round can cost another condition, and the final text shows no trace of what fell out two rounds earlier. The same drift appears in a weekly report built on last week's summary.

The same meeting, two summaries

Five minutes of an operations meeting, reduced to what was said:

• Bram: supplier A asks 42,000 euro for the first year, 18,000 per year after that.

• Anke: April only works if the stock count is finished in March, otherwise the next window is September.

• Chris: the budget holds under 45,000 in year one. I sign off on the pilot, not on the full rollout.

• Bram: the migration cost is not in the offer, I will ask for it in writing.

• Anke: fine, supplier A for the pilot.

A recap of the kind an assistant typically produces:

The team decided to go with supplier A. The cost is 42,000 euro for the first year and 18,000 per year after that. Go live is planned for April. Chris confirmed the budget.

Every sentence sits close to something that was said, and three things are wrong. April was conditional and the condition is gone. Chris approved the pilot, while "confirmed the budget" reads as approval of the project. The migration cost has disappeared, and that is the one figure that could push year one past 45,000.

The dropped caveat is the dangerous one. Nobody reading the recap has any reason to ask about March.

The same meeting, written for someone who has to act on it:

Decision. Supplier A, pilot only. The full rollout is not approved.
Numbers. 42,000 euro in year one, 18,000 per year after. Ceiling for year one is 45,000. The migration cost is missing from the offer, so the year one total is not known.
Planning. April only if the stock count is finished in March, otherwise September.
Action. Bram asks supplier A for the migration cost in writing.
Open. Approval for the full rollout.

The second version is longer than the first, and it is the only one somebody can act on without opening the recording. The goal is not the shortest text, it is the text that lets the reader do the next thing.

How to get a summary you can check

1. Say what it is for and who reads it. "Summarise this meeting" and "write the five lines the finance manager needs to decide whether the budget goes out" produce different texts. Only the second gives the model a criterion for what to leave out.

2. Ask for fields, not prose. Decision, conditions, numbers, actions with an owner, open points. An empty conditions field is a question you can ask. A flowing paragraph hides the same gap.

3. Make every number and name traceable. Have the model quote the source line for each figure before it writes anything. Anthropic gives this as standing advice for long documents: pull the relevant quotes first, then do the task on those quotes. That is grounding, applied to a summary. The same guidance says to put the long text above your question and instructions in the prompt, and reports that queries at the end improved answer quality by up to 30 percent in tests with complex multi-document input.

4. Keep the source next to the summary. A recap with a link to the recording gets checked now and then. A recap pasted into a mail does not, because checking it starts with a search.

5. Test on your own material. Take ten meetings or documents where you know the right answer, run them through and count what dropped out. That small eval tells you more about your own texts than any public leaderboard, and it is worth repeating when your vendor updates the model.

What to watch out for with summarisation

The business risk is not the wrong summary, it is acting on it without opening the source. A wrong summary somebody checks costs five minutes. The same text forwarded to a customer or used as the basis for an order becomes a decision nobody traced back. Every step it travels makes it less likely that anyone opens the original.

A summary is not the record. Contracts, medical notes, incident reports, anything with legal effect, anything an auditor or a regulator reads: the source document is the record and the summary is a reading aid. Once people work from the summary, a signed text has been replaced by a paraphrase.

An unreviewed summary is workslop. If the sender did not open the source, the checking moved to the receiver, who has less context and cannot see what was cut. Whoever forwards a recap owns what is in it. Microsoft puts the warning under its own output: some AI generated content might be inaccurate, incomplete, or inappropriate.