How to chunk transcripts for RAG (what the data says)
For spoken-word transcripts, chunk size matters far more than any clever retrieval technique. In a controlled test on a 264k-word transcript corpus, dropping from 800-token to ~200-token chunks took fully-correct answers from 38% to 67%. Adding contextual-retrieval prefixes on top of small chunks changed nothing measurable, and slightly hurt pure retrieval — it mainly rescued chunks that were too big in the first place.
Step by step
-
1
Start at roughly 200 tokens
Small chunks embed more 'purely' — one topic per vector. Large chunks average several topics into one embedding, which is why they lose on pointed factual questions.
-
2
Overlap, but modestly
Around 100 tokens of overlap stops an answer being cut in half at a boundary. Much more than that mostly duplicates content and inflates your index.
-
3
Split on paragraph and speaker boundaries
Accumulate whole paragraphs up to the target rather than hard-cutting at a token count. A chunk that starts mid-sentence retrieves badly no matter how well sized.
-
4
Attach metadata to every chunk
Title, date, source URL, and position. Without it you can retrieve a good passage and still be unable to tell the user where it came from — and citation is usually the point.
-
5
Measure before adding technique
Build a small set of real questions with known answers and score end-to-end answers, not just whether the right passage was retrieved. Retrieval metrics and answer quality disagree more often than you'd expect.
Doing it by hand
The whole process without any particular tool, if you'd rather build it yourself:
- Split each transcript into paragraphs.
- Accumulate paragraphs into ~200-token chunks with ~100 tokens of overlap.
- Emit one JSON object per chunk with the text plus title, date, and source.
- Embed and index as usual.
- Score a fixed question set before and after any change.
Common questions
Is contextual retrieval worth it?
It depends on what else you run. The published gains lean on a BM25 and reranking stage; with pure dense retrieval over already-small chunks, a generic per-chunk prefix mostly dilutes the embedding. Measure it on your own corpus before paying for it.
Do these numbers generalise?
Treat them as a starting point for clean spoken-word transcripts, not a universal constant. The test used one corpus, one embedding model, and 42 questions, and several of the smaller differences sat inside the noise. Code and dense technical PDFs behave differently.
Should I clean the transcript first?
Removing filler and fixing misheard names helps retrieval, because those errors land in the embedding too. Be careful with anything that rewrites meaning rather than tidying it.
The shortcut
SourceWeaver does every step above in one pass — reusing existing captions and transcripts, transcribing the rest on a GPU with optional speaker labels, and exporting in the format your destination tool actually wants. You can see real output before signing up.
Process content you own or created, content you're licensed or have permission to use, or openly-licensed and public-domain material. Whether any particular use is permitted depends on copyright law and the rights you hold — it's worth being sure before you start.