AI tool for summarising text: from executive briefings to transcripts

Why a custom summarisation tool rather than copy-pasting into ChatGPT

General chat tools work well for a single page of text and public information. For board papers, legal case files, client contracts and compliance reports, you run into three hard limits: token limits, missing source attribution, and data your organisation cannot allow to leave its environment.

A board pack is typically one hundred and fifty to three hundred pages. A commercial LLM's context window may cover that in one go, but even then, without structure, the model reads an arbitrary selection and returns a smooth yet unverifiable summary. A board secretariat needs to know which conclusion comes from which paragraph, otherwise the summary is unusable for decision-making. The same applies to legal work: a solicitor summarising a judgment without paragraph references cannot cite that material in a memo.

A custom summarisation tool turns these requirements into a pipeline: documents are ingested in a structured way, chunked at semantic boundaries, summarised through a hierarchical map-reduce, and every output sentence is linked to its source page. The tool runs in your own environment — Azure West Europe, AWS Frankfurt, or on-premises with Llama 3 or Mistral — so your documents never leave your data boundaries. The difference from copy-paste AI lies in reproducibility, control and compliance.

The architecture: extractive, abstractive, map-reduce and RAG

A summarisation tool of any real depth is not just a prompt sent to a chat API. It is a pipeline of four components working together, each with its own design choices depending on the document type, the desired length and the citation requirements.

Extractive versus abstractive summarisation. Extractive techniques pick literal sentences from the source text and stitch them together: simple, quotable and free of hallucinations, but sometimes choppy. Abstractive summarisation rephrases in its own words and produces more fluent text, but requires active hallucination prevention. For legal rulings we often choose a hybrid: abstractive for the summary, extractive for quotations. For board documents and RFPs it is almost always abstractive with grounding citations.

Map-reduce for long documents. Documents above the token budget are chunked semantically, not at arbitrary byte boundaries, often along chapters, sections or paragraphs. Each chunk receives a local summary (the "map" step), after which a second pass consolidates those partial summaries (the "reduce" step). For very long documents we move to hierarchical summarisation in three or four layers, preserving page references at each level.

RAG for cross-document queries. When a question must be answered across multiple documents, such as "what are all the liability clauses in our top twenty supplier contracts?", we add Retrieval-Augmented Generation. Documents are embedded in a vector database, searched semantically, and the top-N results are summarised. Read more about document classification and RAG pipelines.

Fact-checking and hallucination prevention. Every output sentence is grounded in a specific source text fragment through citation-grounded generation. A second LLM pass verifies that each claim actually follows from the cited source (factuality scoring). Our evaluation pipeline uses BLEU and ROUGE metrics on curated test sets, plus human-in-the-loop evaluation for each document type.

Four scenarios we are already building today

These are realistic projects for which we are regularly approached. Not a vision of the future, but projects that could be in production within eight to sixteen weeks.