Chunking slide decks

Somebody adds the company’s presentation archive to the corpus. Retrieval quality drops for everyone, because the index now contains several thousand chunks that read like Q3 Priorities and Faster. Cheaper. Simpler. and match almost any query weakly.

Slides are the worst-behaved document type most corpora contain. They are short, elliptical, visually encoded, and the actual content was spoken by a person who is not in the file.

Why a slide resists chunking

The text is a prompt, not a statement. A bullet reading “3 regions by EOY” is a reminder to the presenter. It is not a sentence, it does not name its subject, and it will never be a good retrieval target.

The meaning is in the layout. An arrow between two boxes, a chart, a two-column comparison, a before/after diagram. Extracted to text, those become a list of labels in whatever order the extractor found them, with the relationship gone.

Slides are tiny and there are lots of them. One slide is far below any sensible chunk size, so you either get thousands of near-empty chunks or you group slides and hope the grouping is meaningful.

Titles repeat. Agenda, Background, Next steps, Thank you, Appendix. Across a corpus of decks, these produce hundreds of chunks with near-identical text from unrelated documents.

There is often a much better source. The deck was made from a document, or summarised into one. Indexing the document instead is frequently the correct engineering answer, and it is worth asking before building anything.

The split, shown

A short deck, chunked per slide and then chunked as a labelled section with notes.

=== ONE CHUNK PER SLIDE ===
--- chunk 1 ---
Platform Roadmap
--- chunk 2 ---
Where we are
• Single region
• Manual failover
• 4 h RTO
--- chunk 3 ---
Where we're going
• 3 regions by EOY
• Automatic
• Under 15 min
--- chunk 4 ---
Questions?

Chunk 3 is four fragments. Three regions of what, automatic what, under fifteen minutes of what. It matches a query about disaster recovery weakly and by accident, because it never uses any word a person would search for. Chunk 4 is noise that will be indexed with the same weight as everything else.

=== SLIDE GROUP + SPEAKER NOTES + DECK CONTEXT ===
--- chunk 2 ---
[Platform Roadmap — internal deck — 2026-05 — slides 2–3]
[section: Current state and target state]

Slide 2 — Where we are
• Single region
• Manual failover
• 4 h RTO
Notes: Today the platform runs in one region. Failover is a
manual runbook and our recovery time objective is four
hours, which we have never actually tested end to end.

Slide 3 — Where we're going
• 3 regions by EOY
• Automatic
• Under 15 min
Notes: By end of year we want three active regions with
automatic failover and an RTO under fifteen minutes.

The second version is retrievable for regions, failover, recovery time objective and RTO, none of which appear on the slides. Almost all of that came from the speaker notes, and the rest came from a header naming the deck.

The strategy

1. Extract the speaker notes and treat them as the primary text. This is the single highest-value step and it is often skipped because the notes are not what you see when you open the file. Notes are written in sentences, they name their subjects, and they are the closest thing in the deck to what the presenter actually said. Where notes exist, index them as the body and the slide text as a title.

2. Group consecutive slides into sections. Use the deck’s own section markers if it has them, or the title-slide pattern, or a fixed run of slides as a fallback. One slide is too small a unit and a whole deck is usually too large. A section of three to six slides on one topic is the unit that behaves most like a chunk.

3. Put the deck’s identity on every chunk. Deck title, date, audience, author, slide numbers. A slide chunk carries so little text of its own that the metadata is more than half of it — and the date matters more here than in most document types, because decks are snapshots of a plan that changed.

4. Keep the slide title with the body. Same principle as keeping a table’s header: the title is the only line on a slide that states the subject.

5. Extract table and chart content deliberately. A table on a slide is a table and should be handled as one. A chart is an image; what you can index is its title, axis labels and any data labels, and you should expect that to be thin. Chart-heavy decks are where this document type stops repaying effort.

6. Drop the structural slides. Title cards, agendas, section dividers, “Questions?”, thank-you slides, and slides whose entire text is a company logo. Filter them by length threshold and a small list of known titles. They are the boilerplate of the format and indexing them costs you precision across the whole corpus.

7. Consider generating a description per section. A model reading the slide text plus notes can write two sentences of prose that are far more matchable than the bullets. This is rewriting a chunk so it can stand alone applied to a format that needs it more than most — and it carries the same hazard, that a generated description of an ambiguous slide is confidently invented. Keep the original text and cite that.

What still breaks

Decks with no speaker notes, which is most decks. You are left with fragments, and the honest answer is that they will retrieve poorly no matter how you cut them.

Diagram-only slides. An architecture diagram is the most information-dense slide in a deck and it extracts as a dozen nouns in arbitrary order. No chunking strategy recovers the arrows.

Decks whose narrative spans the whole file. A deck that builds one argument across thirty slides has no sectional structure to group on, and each group is a piece of a case rather than a claim.

Duplicate decks. The same presentation exists in four versions with different dates, and all four are in the corpus. That is a corpus-management problem, not a chunking one, but it shows up as slides matching everything.

How to tell if it worked

Ask whether the deck belongs in the index at all. For each deck class, check whether a document covering the same material already exists — a design doc, a report, a wiki page. Where it does, indexing the deck adds noise and duplicates a better source. A corpus is allowed to exclude a document type.

For the decks that stay, take the sections you produced and read them without the file open. If a section tells you what was being claimed, the notes were there and the grouping worked. If it reads as a list of labels, you have confirmed the ceiling for this document type, and the useful next move is a length-distribution check to see how many near-empty chunks the deck corpus is contributing to your index overall.