Continued from previous two posts:

Traditional storage products already embody many of these ideas, even if they were not originally designed for vector search. Relational databases use table partitioning, index organized tables, and partial indexes to restrict scans to relevant partitions. Search engines like Elasticsearch and OpenSearch use index level routing, shards, and filtered queries to narrow the set of documents before applying scoring. When these systems added k NN or vector search capabilities, they naturally reused the existing partitioning and filtering machinery: k NN queries can be combined with term filters, range filters, and routing keys, and the engine can limit ANN search to shards that satisfy the filters. This reuse is one reason why hybrid search (metadata plus vectors) in such systems can be efficient without re indexing all vectors for each new filter.

Contemporary vector databases and cloud services extend these constructs with more built-in support for dynamic narrowing. Milvus exposes collections and partitions, supports hybrid search with scalar filters, and uses adaptive execution strategies to balance recall and latency under filtered workloads. pgvector integrates with PostgreSQL’s planner and allows filtered vector queries to benefit from relational indexes and partitioning. Commercial services such as Pinecone, Weaviate, and others expose namespaces, metadata filters, and per collection indexes, encouraging users to design schemas where common filters align with collection boundaries. Some services also support “metadata aware” routing, where vectors are placed into pods or shards based on attributes, so that queries with those attributes automatically narrow the search to a subset of pods.

These product features still suggest plausible directions for further work. One direction is to make partitioning and metadata aware routing more adaptive: instead of static partitions, the system could monitor query patterns and GLS like metrics, and reorganize partitions to maximize the overlap between common filters and vector clusters. Another direction is to integrate learned indexes or neural partitioners that map metadata and vectors jointly into buckets, so that both semantic similarity and filter constraints are captured in the same coarse index. A third direction is to expose more control to the optimizer, allowing users to specify policies such as “prefer exact scans when filter selectivity exceeds a threshold” or “limit ANN search to partitions with high GLS for this filter,” which would make the narrowing behavior more predictable in production.

Overall, narrowing the scope of vector search via metadata without re indexing the entire corpus is already a recognized problem, and both research and products are converging on a set of constructs—partitioned indexes, hybrid metadata/vector indexing, segment level pruning, and cost based optimization—that make this narrowing effective. The efficiency gains come from reducing the number of candidates and the amount of data touched, while keeping retrieval semantics intact by ensuring that all vectors satisfying the filter within the chosen partitions are considered. The interesting space lies in formalizing the interaction between filters and vector distributions, designing index structures that exploit that interaction, and building optimizers that can dynamically choose the right narrowing strategy for each query workload.

Query planning and reranking are becoming first class features in cloud services. Question decomposition for RAG based pipeline now consist of three steps: decomposition into sub-queries, retrieval per sub-query, and re-ranking against the original question. For example, Azure AI search’s retrieval activity shows a similar multi-stage process: a ModelQueryPlanning step, multiple AzureSearchQuery calls, and an AzureSearchSemanticRanker stage. Azure AI Search supports continuous indexing of documents, enabling real-time updates to the search index as new data is ingested. It can connect to various data sources, such as Azure Blob Storage, SQL databases, or Cosmos DB, to ingest documents continuously. Indexers are configured to monitor these sources for changes and update the search index accordingly. The indexer scans the data source for new, updated, or deleted documents. The time taken to index new documents depends on factors like the size of the data, complexity of the schema, and the indexing tier. For large datasets, indexing may take longer, especially if the indexer is resource starved. Once documents are indexed, they are available for querying. However, query latency can vary based on the size of the index, query complexity, and service tier. The minimum interval for indexer runs is 5 minutes. If this pull from data source is not sufficiently fast enough, individual data item can be indexed by directly pushing to index using the index client. This query planning and reranking example shows how decomposition and reranking can be layered on top of vector search to both widen and narrow the search space in a controlled way, without changing the underlying index.