What is learned entry-point selection?
Learned entry-point selection is any method that chooses where a graph ANN walk begins by conditioning on the query – and often on filters, past traffic, or a trained or clustered map of the space – instead of always starting from one fixed top-layer node.
Why does the starting node matter so much for greedy search?
Graph ANN search is a hill climb: from a seed, the engine repeatedly moves to a closer neighbor until it cannot improve. If the seed sits in the wrong region of the space, the walk may spend many hops correcting course, expand a huge candidate set, or settle in a local basin far from the true neighbors. Classic HNSW softens that risk with hierarchy: a sparse upper layer acts as a long-range highway, and search descends until layer zero. That fixed top entry is often good enough on homogeneous corpora. It is less reliable when the data is strongly clustered, when queries concentrate in a few modes, when filters delete most of the natural landing region, or when you run a flat proximity graph without upper layers. In those regimes, which node you start from can dominate both hop count and recall.
Learning or adapting the seed is the frontier answer to that sensitivity.
How do systems learn or adapt an entry point?
One family partitions the corpus offline – for example by clustering – and stores a representative vector for each region. At query time the engine scores those representatives against the query and begins greedy search from the best-matching representatives (sometimes several). Theory and experiments on flat navigable graphs show that such adaptive seeds can bound hop counts more tightly than a single global center when the graph behaves like a roughly monotonic search network. Another family treats entry selection as a prediction problem: train a light model or hash on query vectors (or on successful historical queries) to propose hubs or previously good landing nodes. A third family does not replace hierarchy so much as augment it: after descending, or when filters are present, it seeds extra base-layer starts that already satisfy predicates so the walk does not thrash in a high-similarity but filter-empty pocket. Shared themes are query-conditioned starts, optional multi-start beams, and maintenance of a small auxiliary map that is cheaper to score than scanning the full graph.
These ideas sit beside – not instead of – the usual ef and degree knobs.
When is learned entry selection worth the complexity?
Prefer a fixed hierarchical entry when the index is healthy HNSW, filters are mild or well correlated with vectors, and latency already meets targets after tuning ef. Invest in adaptive or multi-entry strategies when profiles show long base-layer expansions from a bad landing, when filtered recall collapses despite high ef, when you operate a largely flat graph, or when query traffic is highly multimodal and a single highway start systematically underserves rare modes. Watch the cost of the selector itself: scoring hundreds of cluster centroids per query can erase hop savings if the map is too fine. Also retrain or refresh the map when the corpus drifts – a stale entry catalog is a new failure mode. Learned entry selection is about reducing wasted exploration at the beginning of the walk; it does not fix broken connectivity, wrong metrics, or under-built graphs.
Production systems already borrow pieces of this idea even when they do not ship a full learned selector.
How does Weaviate relate entry points to search today?
Weaviate’s HNSW search follows the hierarchical pattern: navigation uses the multilayer graph so the effective start is the engineered top of that structure, then refinement happens on denser lower layers. Filtered search adds a more explicit entry-point tactic under the ACORN-inspired filter strategy. When a predicate has low correlation with the query vector, landing near the unfiltered nearest neighbors can leave the walk in a region where almost nothing matches the filter. Weaviate addresses that by seeding additional entry points that already match the filter, helping the search reach a productive filtered zone faster while still using multi-hop neighborhood checks when intermediate nodes fail the predicate. That is adaptive entry behavior conditioned on the filter allow-list, not a separate ML model over raw query vectors – but it is the same underlying insight: the walk should begin where it can actually succeed. Separately, dynamic ef adapts beam width during search; that tunes exploration depth, not the seed. Operators should treat filter strategy, ef / dynamic ef bounds, and graph quality as a set: a smarter start helps most when the graph remains connected under the predicate.
Judging a selector means measuring early-path waste, not only final recall.
How should you evaluate learned entry-point selection?
Compare fixed-entry versus adaptive-entry runs at matched recall@k: track distance computations, hops to first useful candidate, p95/p99 latency, and – for filtered workloads – how often the walk escapes empty regions. Ablate the size of the entry catalog and the number of simultaneous starts; more seeds usually cut comparisons until selector and merge overhead dominate. Replay production query logs, including rare modes and strict filters, because synthetic uniform queries understate entry-point pain. If adaptive starts help only a thin slice of traffic, gate them behind those query classes rather than paying the selector on every request. Next in the glossary, routing research asks what happens after the first hop – how the walk chooses among neighbors – which is the natural sequel to choosing the seed.
Learned entry-point selection turns the first step of ANN search into a query-aware decision. Next, read "What is learned routing in ANN search?" for how walks choose edges after they start, or revisit predicate-robust connectivity and Weaviate’s ACORN filter strategy when filtered landings are the bottleneck you need to fix first.