Graph based ANN structures such as HNSW can also be adapted to support narrowing. One approach is to maintain multiple graphs keyed by metadata values or ranges, effectively creating per label or per bucket graphs. Another is to embed metadata into the graph topology, for example by constraining edges so that nodes with incompatible metadata are not reachable from each other within a small number of hops. In both cases, the query engine uses the filter to choose which graph or subgraph to traverse. The FANNS taxonomy distinguishes pre filtering (restricting the candidate set before ANN search), runtime filtering (applying filters during graph traversal), and post filtering (filtering after ANN search), and evaluates their impact on performance and recall. Pre filtering and partition based designs tend to benefit most from narrowed scope, because they avoid exploring irrelevant regions of the index altogether.

From a performance perspective, the gains from narrowing the search scope arise from several layers. At the algorithmic level, ANN search cost is roughly proportional to the number of candidates examined and the number of distance computations performed. If metadata filtering can reduce the candidate set from N vectors to M≪N, and the index structure can exploit this reduction by probing only the partitions or segments that contain those M vectors, then both CPU and memory traffic decrease. At the system level, fewer partitions or segments need to be loaded into memory, which reduces cache misses and disk I/O. At the optimizer level, the engine can choose cheaper plans, such as exact scans over small filtered subsets instead of approximate scans over the full table, when selectivity is high. The GLS metric proposed in the FANNS work formalizes how strongly the filter correlates with the query vector distribution, and the experiments show that high GLS (strong correlation) allows more aggressive pruning without hurting recall, while low GLS (weak correlation) requires more cautious strategies. 

To support these gains, several constructs need to be present in the storage and query stack. There must be a way to attach metadata to each vector and to index that metadata with structures that support fast filtering—B trees for ranges, inverted indexes for terms, bitmaps for categorical attributes, or specialized partition maps. There must be a physical layout that groups vectors in a way that aligns with common filters: partitions by tenant or time, shards by routing key, IVF lists by coarse centroid, segments by collection. There must be an execution engine that can push filters down to the partition or segment selection stage, rather than applying them only after ANN search. And there must be a query optimizer that can estimate filter selectivity and choose between alternative plans: pre filtering plus ANN, ANN plus post filtering, or exact scans over filtered subsets.