Dimensions refers to the length of an embedding vector — how many numbers it contains. More dimensions can capture more nuanced distinctions in meaning, at the cost of more storage and slower comparison at scale.
What Dimensionality Looks Like in Practice
A 384-dimension embedding: [0.02, -0.15, 0.33, ..., 0.08]
└──────── 384 numbers total ────────┘
A 1536-dimension embedding: [0.01, -0.09, 0.21, ..., 0.14]
└──────── 1536 numbers total ────────┘Different embedding models produce different fixed dimensionalities — this is a property of the specific model, not something you choose freely per-request.
The Practical Tradeoff
| Higher Dimensions | Lower Dimensions | |
|---|---|---|
| Semantic nuance captured | Generally more | Generally less |
| Storage per vector | More | Less |
| Comparison speed at scale | Slower (more numbers to compare per vector) | Faster |
| Cost at large scale (millions of vectors) | Higher storage/compute cost | Lower |
More dimensions isn't automatically "better" for every application — it's a real engineering tradeoff between retrieval quality and system cost/performance at scale.
Dimensionality Reduction — A Real Technique
Some systems deliberately reduce embedding dimensionality (via techniques like PCA or model-specific truncation features some providers now support) to save storage and speed up search, accepting some loss in retrieval precision as a tradeoff. This is a genuine, sometimes worthwhile optimization for very large-scale systems — not something to do casually without measuring the quality impact.
Practical Use Case
A system storing embeddings for 100 million documents faces meaningfully different storage and compute costs at 1536 dimensions versus 384 dimensions — for very large-scale systems, this tradeoff is worth evaluating explicitly rather than defaulting to the largest available embedding model.
Common Mistakes
- Assuming a higher-dimension embedding model is always the right choice regardless of scale — for small-to-medium datasets, the storage/speed difference rarely matters enough to sacrifice quality
- Mixing vectors of different dimensionality in the same comparison — this typically isn't even possible mechanically (a similarity calculation between vectors of different length isn't valid), but it's a real integration bug when switching models
Interview Relevance
"Why wouldn't you always choose the embedding model with the most dimensions?" — storage cost and search speed at scale are the practical tradeoffs, not just raw semantic capability.
Practice Question
A system needs to store and search embeddings for 500 million product listings. Explain why dimensionality is a more significant practical concern here than for a 5,000-document internal wiki.