In Arrival, the breakthrough is not learning what the aliens are saying. It is realizing how they write.
The heptapods do not write in sequences of words. Each logogram is a single circular shape that carries a complete thought, and the meaning lives in the geometry: the curl of an edge, the weight of a stroke, the distance between marks. Louise cracks the language by treating meaning as something you can measure.
That is an embedding. Meaning, converted into geometry, so it can be measured.
If your company touches semantic search, RAG, recommendations, or deduplication, embeddings are already load-bearing in your stack. Most people running those systems have never been told what the numbers actually are. This post fixes that, without asking you to train anything.
Meaning as Coordinates
An embedding is a list of numbers. That is the whole object. Feed a sentence into an embedding model and it returns something like 1,536 numbers between roughly -1 and 1.
The numbers are coordinates. The model was trained on enormous amounts of text with one objective: texts that mean similar things should land at nearby points, texts that mean different things should land far apart. "How do I reset my password" and "I'm locked out of my account" share almost no words, but they land close together, because the model learned they occur in the same kinds of contexts and mean the same kind of thing.
A useful mental model: it is a map of meaning with a few thousand dimensions instead of two. You cannot picture it. You do not need to. The only operation that matters is measuring the distance between two points, and computers do that in microseconds, across millions of points at once.
That one trick, similarity as distance, is the entire foundation.
What This Buys You
Once every document, ticket, product, and query is a point on the map, a family of previously-hard problems becomes the same easy problem: find the nearby points.
Semantic search: embed the query, return the closest documents. The user who searches "laptop won't turn on" finds the article titled "Troubleshooting power issues," even though they share zero keywords.
RAG retrieval: same operation, but the results get handed to a language model as context instead of shown to a user. Every RAG system you have read about is an embedding lookup with a model on top.
Deduplication: two support tickets, two CRM contacts, or two product listings that are worded differently but describe the same thing will sit close together. Distance below a threshold, flag as duplicates.
Clustering: run grouping over the points and topics emerge on their own. Ten thousand pieces of customer feedback organize themselves into "shipping complaints," "pricing confusion," and "feature requests" without anyone writing a taxonomy first.
Recommendations: people who liked this point may like the points around it.
Different product features. One operation underneath.
Where Embeddings Fail
The map has blind spots, and they are predictable.
Exact matching. Embeddings capture what text is about, not what it literally says. Part numbers, invoice IDs, email addresses, exact names: a vector search for "SKU-88213" might happily return SKU-88231, because to the geometry of meaning, those are practically the same document. Anything that must match exactly belongs in keyword search or SQL, not vectors.
Numbers in general. "Revenue grew 3%" and "revenue grew 30%" are nearly identical points on the map. The difference that matters most to your CFO barely moves the needle geometrically.
Negation. "This treatment is effective" and "this treatment is not effective" share almost all of their content. Models have improved here, but the failure still shows up in production, and it shows up quietly.
The lesson is not that embeddings are unreliable. It is that they answer one question, "what is this about?", and real systems usually need a second question answered too: "what does this literally say?" Mature retrieval stacks run both (vector search plus keyword search) and merge the results. The industry calls this hybrid search. You should assume you need it.
The Decisions You Actually Have to Make
You will not train an embedding model. The pre-trained ones from OpenAI, Cohere, Google, and the open-source ecosystem are strong, cheap, and a single API call away. Your decisions live one level up.
Which model. They differ in quality, price, speed, and vector size. Bigger vectors are not automatically better; they cost more to store and search. For most business workloads, the default model from your existing provider is fine, and switching for a marginal benchmark win is rarely worth what comes next.
Because here is the switching cost: vectors from different models are not comparable. Each model has its own coordinate system. Change models and every document in your index must be re-embedded, from scratch. For a corpus of millions of chunks, that is a real bill and a real migration. Pick deliberately, once.
What to embed. You embed chunks, not documents, and chunk size shapes retrieval quality more than model choice does. We covered that decision in depth in our chunking strategies post.
Keeping the index honest. Embeddings are a snapshot. When the source document changes, its vector is stale, and vector databases do not know that. Somebody has to own the pipeline that re-embeds on update. In our experience this is the most common failure in production RAG systems: not the model, not the search, but an index that quietly drifted out of sync with reality months ago.
What to Do With This
Next time a vendor says "semantic search," or an engineer says "we'll just embed it," you now know what is actually being proposed: convert meaning to coordinates, find nearby points. You also know the three questions that separate a working system from a demo.
Is anything in this workload an exact-match problem wearing a search costume? Then vectors alone will fail it.
Who owns re-embedding when documents change? If the answer is nobody, the index is already rotting.
And what happens the day you switch models? If nobody has priced the re-embed, nobody has actually chosen the model yet.
The geometry is the easy part. The map maintenance is the job.
