Easiest way to understand Vector Embeddings and Vector Search

Why Searching 1 Million Arrays of 1536 Numbers Does NOT Melt Your CPU

Before I start part 2 of my previous blog :

[embed]Using Spring AI 4, Ollama, and MongoDB Atlas - Building Local AI Stack FREE FREE FREE - Building a High-Performance Local AI Stack: Spring Boot 4, Spring AI, Ollama, and MongoDB Atlas Java…neemo.medium.com

I want to explain Vector Embeddings as you may need this knowledge on explanation of ways of embedding dimensions.

What is Vector?

The first thing that came to mind when I heard this word was vectors from Physics — a quantity defined by both magnitude and direction, always relative to something else. Naturally, I was confused.

But these are different.

In the world of data and AI, a vector is simply a list of numbers — each number representing a dimension, together capturing the meaning of something: an image, a word, a song, a face.

Confused? Don’t worry. By the end of this blog, you’ll clearly understand what vectors are, how they’re created, stored, and searched — from scratch.

Let’s begin.

Vector Databases: How Machines Find Meaning

Not just what matches — but what’s close in meaning. A ground-up explanation of embeddings, dimensions, and the algorithms that make semantic search fast.

The Problem: The Icon SQL Can’t Find

Look at this navigation bar:

Five icons: home, play, messages, search, profile. Now try finding “profile icon” with SQL.

You have 10,000 such images. A user searches: "profile icon"

Classic SQL would need:

SELECT * FROM images WHERE object = 'profile'

But nobody tagged every image. Nobody wrote object=profile for every icon in every screenshot. SQL fails completely. So we will never be able to find the required image?

We absolutely can, and this is where vector search begins.

Step 01 — How an Image Becomes Numbers

The first move: pass the image through an embedding model — a neural network trained to compress visual meaning into a list of numbers. Models like CLIP, ViT (Vision Transformer), or OpenAI’s image encoder do this. I have specifically used text only embedding models for RAG using PDF documents, qwen3-embedding:8b and voyage4, information in the below blog:

[embed]Using Spring AI 4, Ollama, and MongoDB Atlas - Building Local AI Stack FREE FREE FREE - Building a High-Performance Local AI Stack: Spring Boot 4, Spring AI, Ollama, and MongoDB Atlas Java…neemo.medium.com

Profile Icon  →  CLIP / ViT  →  [0.13, -0.72, 0.54, 0.91, ...]

The output isn’t pixels. It isn’t profile=true. It's a list of floating-point numbers — called an embedding vector — that encodes the semantic meaning of the image in compressed mathematical form.

Key point: One image → one vector. Not one million comparisons. Not one value per pixel. One dense list of numbers that captures meaning.

Step 02 — Dimensions simplified: 2D → 3D → 1536D

Every model has a dimension concept, based on few properties. Lets find out what those properties might be.

2D — The simplest case — for our understanding

This is how I understand any concept, by breaking any concept into any smallest module possible. Let’s describe a person with two numbers: height and age.

person_A = [170, 25]   # height=170cm, age=25
person_B = [172, 26]   # height=172cm, age=26  → close to A
person_C = [160, 60]   # height=160cm, age=60  → far from A

A and B are close together in 2D space. C is far away. You can plot this on paper.

3D — Add one more feature

Add income. Your vector becomes [height, age, income]. You can't draw it on paper anymore, but the math works the same — distance in 3D space still tells you which points are similar.

person_A = [170, 25, 15000]   # height=170cm, age=25, income=15000
person_B = [172, 26, 5000]   # height=172cm, age=26, income=5000  → little far to A
person_C = [180, 20, 20000]   # height=180cm, age=20, income=20000  → close from A

This is similar to mathematical model with (x, y, z) coordinates.

1536D — Actual Models which are comparing 1536 properties

Now describe an image — not with 2 or 3 features, but with 1,536 learned features.

Dimension What it might loosely encode Feature 1 “has rounded edges” Feature 47 “appears in a navigation context” Feature 892 “human silhouette shape” Feature 1201 “dark background” Features 1–1536 Learned automatically — no human wrote these rules

The key insight: You don’t define what each dimension means. The model learns them during training on millions of image-text pairs. Each dimension captures some abstract aspect of visual meaning that humans couldn’t easily name.

A profile icon and a person avatar will land near each other in 1536D space — because they encode similar meaning — even though their pixels look completely different.

Dimensions Description Example 2D Two numbers, flat map (x, y) 3D Three numbers, space (x, y, z) 1536D 1,536 learned features Meaning-space point

Step 03 — How Convolutional Neural Networks (CNN) Turns Pixels Into Vectors

The magic is done by CNNs — the architecture at the core of most image embedding models.

The CLIP model goes further — it trains on image-text pairs, so "profile icon" (text) and the actual profile icon (image) end up with similar vectors. That's how text queries can find images.

Step 04 — Why We Measure Angles, Not Distance

Once both the query and stored images are vectors, we need to compare them. The most common measure is Cosine Similarity — and it deliberately ignores magnitude, comparing only direction.

The formula

cos(θ) = (A · B) / (||A|| × ||B||)

Why direction over distance?

A = [1, 2]   # small vector, pointing up-right
B = [2, 4]   # larger vector, same direction

cosine_similarity(A, B) = 1.0    # identical direction = identical meaning

euclidean_distance(A, B) = 2.24  # different distance → wrong conclusion

Why this matters: A small profile icon and a large one have different pixel counts (different magnitude), but they encode the same meaning. Cosine similarity captures that. Euclidean distance would say they’re far apart. We care about direction, not size.

Similarity score reference

Step 05 — The Scale Problem: Why Not Check Everything?

Lets assume, we have 1 million images, each a 1536-dimensional vector. For each search query, do we compare against all million?

Brute Force (Exact):
  N × D = 1,000,000 × 1,536 = 1.5 billion operations per query  

This doesn’t seem feasible right? The trade-off: Approximate Nearest Neighbor (ANN) skips most vectors entirely — but might occasionally miss the single closest match.

ANN (Approximate):
  k × D = 300 × 1,536 = 460,800 operations per query

In practice, getting the top 10 results with 99% accuracy is far more valuable than getting the perfect top-1 with a 10-second wait. That’s why our AI model gives you closest match sometimes instead of exact match. Ever read the statement “AI can make mistakes, please validate your response”?

This is because of the same reason.

Step 06 — ANN: The Family of Algorithms

Approximate Nearest Neighbor (ANN) isn’t a single algorithm — it’s a category. Multiple approaches solve the same problem: find the closest vectors quickly, without checking all of them.

LSH — Locality-Sensitive Hashing

Hash similar vectors into the same “bucket.” Only compare vectors in the same bucket.

Similar vectors → same hash bucket → only compare within bucket

Profile Icon hash:  bucket_47
Avatar Icon hash:   bucket_47  ← same bucket, will be compared
Weather Icon hash:  bucket_891 ← different bucket, skipped

Pros: Fast to build, low memory Used by: Early Spotify music recommendation

IVF — Inverted File Index

Cluster all vectors using k-means first. At query time, only search the nearest clusters.

Cluster 1: [icon vectors]          ← search here
Cluster 2: [landscape vectors]     ← skip
Cluster 3: [person photo vectors]  ← search here (if nearby)
Cluster 4: [document vectors]      ← skip

Pros: Good for billion-scale, memory efficient Used by: Pinecone, Weaviate (one of the option)

HNSW — Hierarchical Navigable Small World

Build a multi-layer graph. Search from the top (fast, coarse) down to the bottom (slow, precise). Current gold standard.

Pros: Best recall-speed tradeoff Used by: Qdrant, pgvector, Weaviate, Pinecone

FAISS — Facebook AI Similarity Search

Meta’s library. Supports GPU acceleration. Combines Product Quantization (PQ) with IVF. Compresses vectors to save memory.

Pros: Billion-vector scale, GPU support Used by: Meta’s internal search, many production RAG systems

Step 07 — HNSW: The Algorithm That Runs Most Vector DBs

Hierarchical Navigable Small World is the most widely deployed vector search algorithm today. Think of it as Google Maps navigation — you don’t travel house-to-house, you use highways → city roads → streets.

Its kind of BFS, goes deep for a match only. Not exactly though, since indexing comes to the rescue.

Layer structure

Layer 3 (Highway)  — Few nodes, long jumps
  A ─────────────────────── D

Layer 2 (City Roads) — More nodes, medium jumps
  A ─────── B         D ─────── E

Layer 1 (Street Level) — All nodes, precise match
  A ─── B ─── C ─── D ─── E ─── F ─── G

How search works step-by-step

Query: find vector most similar to “profile icon”

1. Enter at Layer 3 (top)
   → Jump to nearest neighbor — long jump, rough direction
2. Drop to Layer 2
   → Explore local neighborhood, move toward query vector
3. Drop to Layer 1
   → Fine-grained search, check all nearby neighbors
4. Return top-K results 

It uses Best-First Search — NOT BFS or DFS

Priority Queue — max-heap by similarity score — NOT deepest first (DFS) — NOT level-by-level (BFS) — ALWAYS most promising next

queue = [
    (0.94, node_D),   <------  most similar → explore first
    (0.87, node_B),
    (0.61, node_A),
]

Why the hierarchy solves the “unreachable node” problem

Without layers:

Group 1: A — B — C
                        ← no connection between groups, imagine disjoint graph 
Group 2: D — E — F

Search starts at A. Real answer is F. You never reach F. With HNSW layers, every node is reachable from the top via long-range shortcuts. (A->D->E->F)

Step 08 — Real Example: Image Search in Action

Let’s make this concrete with a real image. Building a sports gaming app, searching players by appearance:

*Player: NEEMO #10 · Blue kit · Tattooed arm · Celebration pose*

When this image goes through an embedding model (CLIP / ViT):

# What CNN layers detected, layer by layer:
layer_1 = 'Blue fabric texture, white number edges, skin tones'
layer_2 = 'Jersey shape, human torso, arm position'
layer_3 = 'Football kit pattern, tattoo, celebration stance'
layer_4 = 'Footballer in blue kit, back to camera, #10'

# Final embedding vector (abbreviated):
neemo_vector = [
     0.82,   # strong: 'sports context'
    -0.31,   # weak:   'facing camera' (back-facing, so negative)
     0.74,   # strong: 'blue uniform'
     0.91,   # strong: 'human figure'
     0.67,   # strong: 'celebration / arms extended'
    ...      # 1,531 more learned features
]

A user searches "footballer celebrating back-facing". That text becomes its own 1536D vector. The database finds this image because its vector lands nearby in meaning-space — not because anyone wrote a caption with those exact words.

Cross-modal search: CLIP was trained on image-text pairs so that "profile icon" (text) and the actual profile icon image land near each other in the same vector space. Text finds images. Images find text. Same space, different modalities. Amazing isn’t it? Feels magical, but mathematical.

This is why someone said, mathematics is the base of the whole universe.

Step 09 — How Vectors Are Actually Stored

People assume vector databases store pre-computed similarities between every pair. That would be catastrophic at scale.

// What IS stored per vector:
{
  "id": 12847,
  "vector": [0.13, -0.72, 0.54, ...],
  "neighbors": [8821, 4423, 19002],
  "metadata": {
    "source": "nav_bar_v2.png",
    "layer": 2
  }
}

What is NOT stored: — similarity(12847, 8821) — computed dynamically on every query this is why storage doesn’t explode.

Mathematics behind this?

Storing the vectors:
  1,000,000 vectors × 1,536 floats × 4 bytes = ~6 GB  # this is manageable

# impossible and it keeps on increasing exponentially
Storing all pair similarities:
  1,000,000² pairs × 4 bytes = ~4 Petabytes 

Step 10 — Full Production Pipeline

Mental Model

Forget the ML jargon. Vector search is just four familiar data structures:

Vector Search = HashMap + Graph + Priority Queue + Geometry

The hardest part of vector databases isn’t the machine learning. It’s accepting that search no longer means “find exact values”. It means: find nearby meaning.

Once that clicks — RAG pipelines, semantic search, image search, recommendation engines, AI assistants — they all start making sense.

They’re all just asking: what’s close in meaning-space?

Algorithm Cheat Sheet

Next ones in the queue:

• Effective RAG search including chatting
• Customize the Data in Embeddings Document (if interested).
• How embeddings are trained — and why one image encodes 1,536 features without anyone writing the rules.