What are embeddings?

In Prompt Engineering you learned RAG from the outside: retrieve relevant chunks, ground the answer. This course builds the machine — and the machine runs on one idea: **an embedding model turns a piece of text into a list of numbers (a vector) positioned so that texts with similar meaning land close together.**

'Can I send this back?' and 'What is your returns policy?' share almost no words — a keyword search sees strangers. An embedding model maps both to nearby points, because it was trained on billions of examples of which texts mean the same thing. Meaning becomes geometry, and geometry is something computers can search fast.

What the numbers actually are

• A modern embedding is typically 256–3,072 numbers per text. No single number means anything readable; meaning lives in the pattern, the direction the vector points in a space with thousands of axes.
• Embedding models are not chat models. They're smaller, cheaper, faster specialists that output vectors, not words — you'll call one thousands of times per corpus and barely notice the bill.
• Same model in, same space out. Vectors from different embedding models are incompatible coordinate systems. Rule one of RAG: the model that embeds your documents must be the model that embeds your queries.
• Common choices: hosted APIs (Voyage AI, OpenAI, Cohere) or open-source models you run yourself (the sentence-transformers family). The course code uses a hosted API behind a one-function wrapper so you can swap providers freely.

Why RAG needs this

The RAG promise is 'find the passages relevant to this question, out of thousands'. Users don't phrase questions with your documents' vocabulary — they say 'send it back' when the doc says 'return authorization'. Keyword search misses; embeddings bridge, because relevance is a semantic relationship. The whole pipeline you'll build — chunk, embed, index, retrieve, ground — exists to exploit this bridge reliably.