A new study on search-engine speedups tested a popular trick across three different retrieval systems - and found it only works in some of them.
Researchers ran 1,140 experiments across a bare-bones exhaustive C++ search pipeline and two production-style engines, BMP and SEISMIC, using two benchmarks (MS MARCO and Natural Questions) and two very different query styles: SPLADE, which averages 44 query terms, and V3-GTE, which averages 7. They tested "static pruning," the practice of trimming an index or a query ahead of time to make search faster. Cutting documents and posting lists from the index worked everywhere, cutting latency by 1.2x to 6.6x and shrinking index size by 18-82%, because sparse retrieval is bottlenecked by memory access rather than raw compute. Trimming query terms, by contrast, only helped the bare-bones pipeline, a 4-11x speedup, because BMP and SEISMIC already do that job internally, so the extra step added nothing.
That distinction matters because most pruning research gets validated on a single custom pipeline and then gets cited as if it generalizes. This paper shows one popular technique, query pruning, doesn't survive contact with real production engines, while a less glamorous one, index pruning, does, and even stacks on top of the dynamic pruning those engines already run. It also offers a practical stopping rule: push pruning until Recall@10 drops to around 85-95%, since ranking quality, measured by NDCG@10, holds steady well past that point.
It's a useful corrective for an infrastructure research area that too often optimizes for one pipeline and calls the result universal.