We've loaded our documents (Part 1) and sliced them into clean chunks (Part 2). Now comes the step at the heart of RAG: turning text into embeddings — lists of numbers that capture meaning. This is what lets a computer find the refund policy when you ask about "returning a faulty laptop," even though those exact words never appear together. Let's walk through how it works, step by step and visually.
From words to numbers: the core idea
Computers can't compare meanings directly — they compare numbers. So we need a way to translate "what this text is about" into numbers that can be measured. An embedding model does exactly that: feed it any text, and it returns a fixed-length list of numbers. The same model always returns the same length — often 384, 768, or 1,536 numbers — no matter how long or short the input.
Notice the first two vectors look alike (similar topic); the third is clearly different. That similarity is the whole point.
Look closely at the numbers above. The first two phrases are about the same thing — returns and refunds — and their vectors are nearly identical, number for number. The third, about leave, has visibly different numbers. The embedding model has placed "meaning" into the numbers themselves.
What do the numbers actually mean?
Each number is a coordinate along some hidden "dimension of meaning" the model learned from reading enormous amounts of text. We can't usually name these dimensions, but you can imagine made-up ones to build intuition: maybe one axis loosely tracks "money/payment-ness," another "time/duration-ness," another "formality." A chunk about refunds scores high on the money axis; a chunk about leave scores high on the time axis.
Real models use hundreds or thousands of these axes at once, which is why they capture nuance so well — but you don't need to picture 1,536 dimensions. The key takeaway is simply: similar meaning → nearby numbers; different meaning → distant numbers.
Picturing meaning as a map
Thousands of dimensions are impossible to draw, so imagine we squash them down to just two so they fit on a page. Each chunk becomes a dot. Chunks about the same topic cluster together; unrelated topics drift apart. When a question arrives, it becomes a dot too — and we simply look for the nearest dots:
The purple query dot lands right inside the refund/returns cluster — so those chunks are retrieved, even though the question never said "refund."
This picture is the heart of RAG. Searching is just "find the dots nearest to the query dot." Because the embedding model placed the dots by meaning, nearness in this space means relevance — and that's why vector search beats keyword search for questions phrased in the user's own words.
Why this beats keyword search
Traditional keyword search matches letters. If the user types "return a faulty laptop" but your document says "refunds for defective equipment," keyword search finds nothing — there's no shared word. Embeddings match meaning, so the two land near each other anyway. A few concrete cases where keywords fail and embeddings shine:
| User asks | Document says | Keyword search | Vector search |
|---|---|---|---|
| "return a faulty laptop" | "refunds for defective equipment" | ✗ no shared words | ✓ same meaning, nearby |
| "time off for a new baby" | "parental leave entitlement" | ✗ misses | ✓ close in meaning |
| "can I expense my taxi?" | "travel reimbursement policy" | ✗ misses | ✓ close in meaning |
The one rule you must not break
You have to embed your chunks and your queries with the same embedding model. Every model builds its own private meaning-space with its own axes; vectors from two different models aren't comparable, any more than a price in dollars is comparable to a temperature in Celsius. If you re-index with a new model, you must re-embed everything — old chunk vectors and new query vectors won't line up otherwise.
Choosing an embedding model
You don't train these yourself — you call a ready-made one. The practical trade-offs:
| Factor | What to weigh |
|---|---|
| Dimensions (vector length) | More dimensions can capture more nuance but cost more storage and compute. 768–1,536 is a common sweet spot. |
| Quality on your domain | Some models are tuned for general text, others for code, legal, or multilingual content. Match the model to your data. |
| Max input length | The model can only embed so much text at once — another reason chunks must be modestly sized (Part 2). |
| Cost & latency | You pay per embedding and you embed every chunk plus every query. At scale this adds up. |
| Hosting & privacy | Cloud API vs self-hosted. For sensitive data, where the text is sent matters. |
In a Microsoft setup, Azure OpenAI embedding models (e.g. the text-embedding-3 family) are a common choice, and Azure AI Search can even call the embedding model for you during indexing — "integrated vectorization" — so you don't wire it up by hand. The principle is identical regardless of vendor: pick one good model, use it on both sides, and only change it deliberately.
Putting it together
After this step, every chunk from Part 2 has a companion vector, and any incoming question can be turned into a vector on demand. We now have everything we need to search by meaning — we just need somewhere to store millions of vectors and a way to find the nearest ones in milliseconds.
Chunks
Part 2 ✓
Embeddings
Part 3 ✓ (here)
Vector index
Part 4 →
What's next
Part 4: Vector Indexing & Similarity Search answers the obvious question this part raises — once you have millions of vectors, how do you find the nearest ones fast? We'll cover how "closeness" is actually measured (cosine similarity), what a vector database does, and the clever approximate-search trick (HNSW) that makes million-scale search feel instant.