In vector search, why does one chunk appear in the top-10 for most queries?

## The phenomenon Hubness is one of the concrete faces of the curse of dimensionality. In low dimensions, being someone's nearest neighbour is roughly reciprocal and evenly distributed. As dimension grows, distances between points concentrate — the spread of pairwise distances shrinks relative to their mean — and small, systematic differences in a point's position start to dominate who ends up on whose neighbour list. The result is a skewed distribution: a few points appear in a hugely disproportionate share of k-nearest-neighbour lists (hubs), and a long tail of points appear in almost none (antihubs). This is not caused by a bug in the index or by bad chunking. It is a geometric property of high-dimensional point clouds, and every dense retrieval system has some degree of it. ## Why boilerplate becomes a hub The strongest predictor of hubness is proximity to the centre of the data distribution. A vector near the mean is moderately close to everything, so it clears the bar for many different queries without being the best answer to any of them. Generic text lands there naturally. A "Terms of Service" paragraph, a document footer, a standard disclaimer, a navigation blurb — none of these have a distinctive semantic direction. Their embeddings are dominated by the shared component every text carries, which is exactly the centre of the cone. The symptom in production is unmistakable once you look: the same boilerplate chunk is in the top-10 for 40% of unrelated user queries, occupying context-window budget and, in a retrieval-augmented pipeline, diluting the evidence the model reasons over. ## Consequences beyond wasted slots Hubs do more than clutter results. They crowd out genuinely relevant chunks in a fixed-size top-k, which directly lowers answer quality downstream. They distort evaluation: retrieval metrics averaged over queries look mediocre for reasons that are the same one document every time. And in graph-based approximate indexes, hub points accumulate high in-degree, meaning search traversals repeatedly pass through the same nodes — which affects both the shape of the graph and the recall of the approximate search for the antihubs on the other end of the distribution. The mirror problem is often the more expensive one: antihub documents are effectively invisible in your product even though they are correctly indexed. ## Detecting it The measurement is simple and belongs in any retrieval health dashboard. Take a large sample of real queries, run retrieval, and count occurrences of each chunk identifier across all the top-k lists. Sort descending. A healthy system has a broad distribution with a modest head; a hubness problem shows a handful of identifiers with retrieval frequency orders of magnitude above the median. Track the top offenders over time — new hubs appear when the corpus changes. A complementary view is the reverse: how many chunks were never retrieved at all across the whole query sample. A large dead zone signals antihubs and tells you that part of the corpus is not reachable in practice. ## Mitigations **Center the space.** Subtracting the corpus mean vector moves the origin to the middle of the distribution, which directly attacks the mechanism, since hubs are the points nearest that centre. This must be applied identically at index and query time. **Use hubness-corrected scoring.** Established methods rescale similarity by how similar a point is to its own neighbourhood, so points that are close to everything are penalized. Local scaling and its variants, mutual proximity, and cross-domain similarity local scaling (CSLS) all follow this shape. They cost an extra pass over neighbourhood statistics, which is usually done offline. **Remove the boilerplate.** Often the cheapest fix is not geometric at all: detect near-duplicate text across documents at ingestion time and drop or merge it, since a footer repeated in five thousand documents contributes nothing retrievable anyway. This does not cure hubness in general, but it removes its most common instance. **Diversify the returned set.** Selecting the final k with a relevance-versus-redundancy criterion such as maximal marginal relevance stops a single hub, and its near-duplicates, from consuming every slot. **Filter with metadata.** Restricting candidates by document type, recency, or section removes whole classes of hub before scoring, and is often the most operationally boring and effective control. ## What to say in an interview Name the phenomenon, tie it to distance concentration in high dimensions, explain the proximity-to-the-mean intuition for why generic text hubs, and — most importantly — describe the measurement. Interviewers are listening for someone who counts retrieval frequency per document rather than someone who reacts to a single bad query by adjusting a threshold.