UMAP vs PCA for Embedding Visualization — and When Each One Lies to You

Both project your embeddings to 2D. Both distort. Knowing exactly how each one lies is the difference between a real insight and a confident mistake.

If you've ever projected an embedding collection to 2D to "see the clusters," you've used one of these two. And if you've ever drawn a conclusion from that picture — "these groups are far apart, so they're very different" — there's a real chance the projection lied to you and you didn't know it.

Both UMAP and PCA are honest tools. They just preserve different things, and each one throws away exactly the information the other keeps. Use them without knowing which is which and you'll read structure that isn't there.

What each one actually preserves

PCA (Principal Component Analysis) finds the directions of greatest variance in your data and projects onto the top two. It's a linear projection: fast, deterministic, and it preserves global variance. The big-picture spread of your data is faithful. What it sacrifices is local detail — if your interesting structure is non-linear (and embedding structure usually is), PCA flattens tight, curved clusters into overlapping smears.

UMAP (Uniform Manifold Approximation and Projection) optimizes to keep each point near the neighbors it had in the original high-dimensional space. It preserves local neighborhoods. Clusters that are genuinely distinct pop apart into clean, separated islands — which is why UMAP plots look so much more satisfying. The price: the distances between those islands are essentially arbitrary. Two UMAP clusters sitting far apart tells you nothing reliable about how different they really are.

(same embeddings, two projections)

Same data. On the left, PCA honors the global layout but the three groups bleed together. On the right, UMAP separates them crisply — but you must not read the gaps between them as real distances.

The two lies, concretely

PCA's lie: false overlap. Two clusters that are cleanly separable in the original space can land on top of each other in a PCA plot, simply because the axis that separates them wasn't one of the top-two variance directions. You look at the plot, conclude "these topics are entangled," and you're wrong — they're perfectly separable, just not along the axes PCA happened to pick.

UMAP's lie: false geography. UMAP will show you three tidy islands and tempt you to say "cluster A is close to B and far from C." That is not information UMAP encodes. Inter-cluster distances, and even the relative sizes of clusters, are artifacts of the layout optimization and its parameters. The membership is trustworthy; the map is not.

There's a subtler UMAP trap too: with the wrong parameters it will happily manufacture clusters out of what is actually uniform noise. Which brings us to the knobs.

The parameters that change the story

UMAP's two most consequential parameters:

• n_neighbors — how much neighborhood each point considers. Low values (~5) emphasize very local, fine-grained structure and fragment the plot into many small clusters. High values (~50) emphasize the big picture and merge them. The "right" value depends on the scale of structure you're hunting for — there isn't a universal default.
• min_dist — how tightly points are allowed to pack. Low values (~0.0–0.1) produce dense, clumpy clusters; higher values spread points out for a more even look. It's purely cosmetic in terms of membership, but it dramatically changes how the plot reads.

Change these and the same data tells a different story. That's not a bug — it's the reason you should never treat a single UMAP plot as ground truth. Sweep the parameters, and if a cluster survives across settings, it's probably real.

A rule of thumb that won't burn you

1. PCA first. It's fast and it won't invent structure. Use it for a sanity-check overview and to gauge how much variance the top components actually capture.
2. UMAP for cluster structure, once you know roughly what you're looking for. Vary n_neighbors and min_dist; trust clusters that persist, distrust the gaps between them.
3. Always confirm by reading the documents. A projection tells you where to look, never what's true. The moment a cluster looks suspicious, open the actual points behind it. (This is the whole diagnostic loop from "Your RAG Pipeline Isn't Broken — Your Vector Store Is.")

Doing it yourself

Both are a few lines in Python:

from sklearn.decomposition import PCA
import umap

# X.shape == (n_docs, dim)
pca_proj  = PCA(n_components=2).fit_transform(X)
umap_proj = umap.UMAP(n_components=2, n_neighbors=15, min_dist=0.1).fit_transform(X)nsform(X)

The friction isn't the projection — it's the loop. Re-pull the vectors, re-run both, sweep parameters, and wire each point back to its source document so you can hover and read. It's entirely doable in a notebook; it's just enough steps that most people run it once and never again.

Full disclosure: I work on VectorLens, a native desktop GUI for ChromaDB, Qdrant, Weaviate, and Milvus. It offers both projections, puts n_neighbors and min_dist on live sliders when you're in UMAP, and gives you hover-to-read on every point — so the "sweep the parameters and confirm by reading" loop is interactive instead of a notebook rerun. Both run off the UI thread, so a re-project doesn't freeze the window. Runs locally, connects straight to your database, installer 4 MB.

Whichever route you take, the discipline is the same: a 2D projection is a lead, not a verdict. Know how your tool distorts, vary its parameters, and always read the documents before you believe the picture.