I tested 7 chunking strategies on production RAG.

Here's what failed and what actually won:

→ Fixed-size: Fast but dumb. Splits sentences in half. Prototype only.

→ Recursive: The safe default. 80% of RAG apps use this. Works fine, rarely optimal. Might fail if your semantic endings are non-uniform

→ Semantic: Sounds smart. Costs 2x compute. Causes non-uniform splits and fails badly on uniform content (code, specs).

→ Parent-child (small-to-big): Retrieves small, returns big for context. Works if child chunks are highly targeted factoids. Has trouble scaling on docs with unclear boundaries

→ AST code-aware (adapted to use case often paired with Hybrid routing): Respects function and class boundaries. Winner for technical docs. +4.3% recall (if adapted for your use case right).

The truth?

There's no universal winner.

What works for legal docs fails for codebases.

What works for FAQs fails for research papers.

You have to test on YOUR data.

That's why in the Engineer's RAG Accelerator, we implement 7 different strategies and evaluate them head-to-head with a real evaluation framework.

(We build the eval layer from scratch to A/B test all decisions reliably)

That's week 2 of the cohort.

40 Engineers (from organisations like Microsoft, Revolut, Visa, Autodesk and more) have already enrolled

Last 10 spots, filling fast

♻️ Restack to share these insights with everyone