Diagnose Embedding Anisotropy Before Tuning Vector Search

A vector search system can behave strangely even when its indexing code and similarity calculation are correct. Unrelated items may receive surprisingly high cosine similarities, score differences may look compressed, or many embeddings may point in broadly similar directions.

One possible cause is embedding anisotropy: the vectors occupy some directions much more strongly than others instead of being distributed evenly through the representation space. Anisotropy is a property of the embedding geometry, not proof that retrieval is broken. The useful question is whether that geometry is hurting the decisions your system makes.

This article builds a practical mental model for embedding anisotropy, shows small diagnostics you can run without a specialized vector database, and explains why geometry measurements should lead to retrieval evaluation rather than automatic vector transformations.

Start with direction, not distance

Consider three two-dimensional embeddings:

A = [10, 1]
B = [10, 2]
C = [10, -1]

The second coordinate changes, but all three vectors are dominated by the first coordinate. Their directions are therefore similar.

Cosine similarity measures the angle between two nonzero vectors:

cos(x, y) = (x · y) / (||x|| ||y||)

For A and C:

A · C = 10*10 + 1*(-1) = 99
||A|| = ||C|| = sqrt(101)
cos(A, C) = 99 / 101 ≈ 0.980

A cosine similarity near 0.98 may look like strong semantic agreement if you interpret the number in isolation. In this toy space, it mostly reflects the shared dominant direction.

Now remove the mean of these three vectors. Their mean is:

mean = [10, 2/3]

The centered vectors become:

A' = [0,  1/3]
B' = [0,  4/3]
C' = [0, -5/3]

The example is intentionally extreme, but it exposes the idea: a large shared component can make vectors appear directionally similar even when the variation that distinguishes them lies elsewhere.

Real embedding spaces have hundreds or thousands of dimensions, so you won’t inspect them coordinate by coordinate. You can still measure whether a few directions dominate the collection.

What embedding anisotropy means

An isotropic distribution has no strongly preferred direction under the particular geometric criterion being considered. An anisotropic embedding distribution is directionally uneven: some directions account for substantially more of the vectors’ structure than others.

This does not require every vector to point almost identically. A collection can have clusters, semantic structure, and useful nearest neighbors while still having a strong global directional bias.

That distinction matters because useful embeddings are not expected to resemble random points on a sphere. Their geometry reflects training objectives, data, architecture, and any post-processing. Detecting anisotropy tells you something about that geometry; it does not tell you by itself whether the representation is good or bad for your task.

A practical mental model is:

shared directional structure
        |
        v
many vectors inherit similar components
        |
        v
cosine scores can become concentrated
        |
        v
ranking may become harder to interpret or discriminate

The last arrow is deliberately conditional. A compressed score range can coexist with excellent rankings because ranking depends on relative order, not on a universal meaning for a cosine value.

Diagnose the geometry with simple measurements

You usually want more than one diagnostic. Each measurement answers a different question, and none should be treated as a standalone quality metric.

Inspect pairwise cosine similarities

Sample pairs of embeddings that are not deliberately chosen as semantic matches, then examine their cosine-similarity distribution.

Conceptually:

for many sampled pairs (i, j):
    score = cosine(embedding[i], embedding[j])
    record(score)

If most unrelated pairs have high positive cosine similarity, the space may contain a strong shared direction. Compare this with a meaningful baseline rather than assuming that cosine similarity should be centered on zero for every embedding model.

The sampling strategy matters. If your corpus contains many near-duplicates or documents from one narrow topic, high similarities can reflect the data rather than a global representation problem. Sample by known groups or metadata when possible so you know what kinds of pairs you are measuring.

Measure the mean vector

For embeddings x_1 ... x_n, compute the component-wise mean:

mu = (1/n) * sum_i x_i

Then inspect its norm relative to typical embedding norms. A substantial mean direction is one simple sign that the cloud is shifted away from the origin.

This measurement is easy to understand, but it is incomplete. A dataset can have a mean near zero and still be anisotropic if variance is concentrated along a few axes or directions.

Look at variance across principal directions

Principal component analysis gives a more general view. After centering the embeddings, PCA finds orthogonal directions ordered by how much sample variance they explain.

If a small number of principal components account for a large share of the observed variance, the representation is concentrated along those directions. That is evidence of anisotropic structure under this variance-based view.

You do not need to decide on a universal threshold such as “the first component must explain less than X percent.” The expected spectrum depends on the model and data. A more useful comparison is often between known-good and problematic slices produced by the same embedding pipeline.

For example, you might compare:

production corpus      -> first 20 PCA variance ratios
new ingestion source   -> first 20 PCA variance ratios
known-good evaluation  -> first 20 PCA variance ratios

A large shift can tell you where to investigate even when no single ratio is inherently wrong.

Connect geometry to retrieval behavior

Suppose a documentation retriever returns five chunks for each query. You notice that cosine scores for both relevant and irrelevant candidates mostly fall between 0.78 and 0.92.

That narrow range is worth inspecting, but changing the embeddings immediately would skip the main question: does the score compression damage ranking?

Create or reuse a small evaluation set with queries and relevance judgments. Measure retrieval quality before touching the vectors. Depending on the task, useful metrics may include recall at k, precision at k, mean reciprocal rank, or another ranking metric that matches how results are consumed.

Then inspect score distributions alongside those judgments:

query                    candidate             cosine   relevant?
reset my password        password reset guide   0.91     yes
reset my password        webhook retries        0.87     no
reset my password        account recovery       0.89     yes

The absolute values are less informative than the ordering and separation. If relevant candidates consistently outrank irrelevant ones, the embedding space may be useful despite high baseline cosine similarities. If the distributions overlap heavily and rankings are poor, anisotropy becomes one plausible contributor to investigate.

This evaluation also protects you from a common mistake: making a geometric statistic look cleaner while making retrieval worse.

Mean centering changes the space

A tempting response to a large shared mean is to subtract it:

x_centered = x - mu

Mean centering removes the collection mean by construction. It can also change every pairwise angle, so cosine rankings after centering are not generally the same as rankings before centering.

Consider a query and document that were encoded with the original model. If you center stored documents but forget to apply the same transformation to queries, you are no longer comparing representations in the same transformed space. Even when you center both, the new ranking is an empirical choice, not a mathematical guarantee of better semantic retrieval.

There is another operational detail: which mean should you use? A mean estimated from one corpus snapshot may stop representing the data after the corpus changes. Recomputing it can change stored vectors and therefore rankings. If centering helps enough to deploy, treat the mean as a versioned model artifact and apply the same version consistently during indexing and querying.

Removing dominant components is a stronger intervention

Another family of post-processing methods removes or downweights high-variance principal directions. The intuition is that a dominant component may encode broadly shared information that contributes little to semantic discrimination.

A simplified removal of one unit-length principal direction v looks like:

x_adjusted = x - (x · v) * v

Removing several components repeats the projection for several orthogonal directions.

This operation is stronger than mean centering. It deliberately discards variation. If a dominant direction carries information your task needs, retrieval quality can fall even though pairwise cosine similarities become more spread out.

The safe workflow is experimental:

original embeddings
      |
      +-> geometry diagnostics
      |
      +-> retrieval evaluation --------------+
                                             |
center/remove selected components            |
      |                                      |
      +-> same retrieval evaluation ---------+
                     |
                     v
             compare task outcomes

Fit any data-dependent transformation on an appropriate reference set, keep evaluation data separate when you are tuning transformation choices, and evaluate the complete query-to-result pipeline.

Anisotropy is not the same as hubness

Embedding anisotropy and hubness can both produce suspicious nearest-neighbor behavior, but they describe different things.

Anisotropy concerns the overall directional geometry of the embedding distribution. Hubness concerns how often particular items appear as nearest neighbors across many queries. A collection can show anisotropy without one document dominating result lists, and a retrieval system can have hubs for reasons that are not captured by a simple anisotropy measurement.

If the symptom is “cosine scores are all unusually similar,” inspect directional geometry. If the symptom is “the same few documents appear for unrelated queries,” measure neighbor occurrence frequencies as well. Those diagnostics can complement each other, but one should not be used as a synonym for the other.

Common mistakes when diagnosing embedding anisotropy

The first mistake is assuming that high cosine similarity means two texts are semantically equivalent. Cosine values are model- and data-dependent. Treat them as signals produced by a particular representation space, not universal semantic percentages.

Another mistake is diagnosing the model from a tiny or biased corpus sample. If all sampled documents discuss the same product feature, their directional similarity may be expected. Use a sample that represents the variety your retrieval system actually handles.

A third mistake is optimizing a geometry statistic instead of the application. Lower mean cosine similarity or a flatter PCA spectrum may look attractive, but neither is the product goal. A retriever needs to put useful items where users or downstream models can use them.

Finally, do not apply a transformation only at indexing time. Centering, projection, normalization, or any other deterministic embedding transformation must be applied consistently wherever comparable vectors are produced. Version the transformation so an old index cannot silently receive queries processed with new parameters.

When a simpler explanation is more likely

Anisotropy is only one reason vector retrieval can disappoint. Before changing representation geometry, check simpler failure modes.

Poor chunk boundaries can mix unrelated ideas. A query and document may use terminology the embedding model does not represent well. The corpus may contain duplicate or generic documents. Approximate nearest-neighbor settings can reduce recall. Metadata filters can remove the correct candidate before vector ranking even begins. A mismatch between the embedding model used for queries and the one used for stored documents can invalidate the comparison entirely.

These problems require different fixes. Geometry diagnostics are most useful after you have confirmed that the pipeline is comparing the intended vectors and that the evaluation set captures the failure you care about.

Turn the diagnosis into an engineering decision

A good anisotropy investigation produces two sets of evidence: a description of the vector geometry and a measurement of task behavior. Keep them separate at first.

Measure pairwise similarities, the mean vector, and principal-direction variance to understand the representation. Then measure retrieval on labeled or otherwise defensible examples. If a post-processing method changes the geometry, rerun the same retrieval evaluation and account for its operational cost, including transformation versioning and reindexing.

The goal is not to make embeddings look isotropic. It is to understand whether directional concentration is contributing to a real retrieval failure and, if so, choose the smallest intervention that improves the system you actually operate.