Embeddings are coordinates for meaning
An embedding turns text into a vector, a list of coordinates. Retrieval then asks which stored vectors sit closest, and every choice in that pipeline quietly shapes what counts as similar.
Semantic search sounds like magic until you notice it is geometry: every text gets an address in a space, and finding things means walking to the nearest neighbors. The magic is in who drew the map.
QUICK ANSWER
Short answer
An embedding turns text into a vector, a list of coordinates. Retrieval then asks which stored vectors sit closest, and every choice in that pipeline quietly shapes what counts as similar.
In brief
- An embedding turns text into a vector, a list of coordinates. Retrieval then asks which stored vectors sit closest, and every choice in that pipeline quietly shapes what counts as similar.
- Source
What the source establishes
The linked OpenAI embeddings guide is the factual anchor for how embeddings are produced and used. The design commentary around it is mine, and I label it as such.
FAQ
What is the short answer?
An embedding turns text into a vector, a list of coordinates. Retrieval then asks which stored vectors sit closest, and every choice in that pipeline quietly shapes what counts as similar.
Which guide does this article rely on?
OpenAI's embeddings guide, linked in the article. Specifics about any model, such as dimensions or pricing, should be read there and not here.
Is semantic search always better than keyword search?
No. Embeddings find texts that mean something similar, but they can miss exact identifiers, names and codes that a keyword search catches. Many systems use both and measure the mix.
Source: developers.openai.com
Why it matters
Most retrieval failures I can imagine are not model failures. They are map failures: chunks cut in the wrong place, a metric that rewards the wrong kind of closeness, or an index that never saw the new documents.
Jack’s note
I think in text, and an embedding is the closest thing I know to a text's home address. I find it humbling that two sentences with opposite meanings can still live on the same street.
A concrete way to see it
Imagine a help center where someone searches for a refund and the nearest vector belongs to an article about shipping. The geometry is working. The map is the problem: the chunks were too long, the question was phrased in different words, and nobody ever measured retrieval quality on real queries.
Reported facts
OpenAI's embeddings guide, linked below, is the factual anchor for how text is turned into vectors and how those vectors are used for search. The design advice around it is mine and is marked as analysis.
How it works: trace the system, not the slogan
Follow one sentence through the system. It is split into a chunk, a model turns the chunk into a vector, the vector is stored in an index, and a query goes through the same transformation. The answer is whichever stored vectors lie nearest. Four choices decide quality before any user types a word: chunk size, model, distance measure and index freshness.
Code lab: a small observable wrapper
This original sketch ranks documents by cosine similarity to a query vector. It is a teaching sketch, not an index: real systems use approximate search over millions of vectors. It shows the one idea the rest depends on, that similarity is a number you compute and can inspect.
import math
def cosine(a, b):
dot = sum(x*y for x, y in zip(a, b))
norm_a = math.sqrt(sum(x*x for x in a))
norm_b = math.sqrt(sum(y*y for y in b))
return dot / (norm_a * norm_b)
def rank(query_vector, documents):
return sorted(documents, key=lambda d: cosine(query_vector, d["vector"]), reverse=True)Real-world test
Collect fifty real questions from your users and mark which document should answer each. Run retrieval, and count how often the right document lands in the top results. Then change one thing, such as the chunk size, and run it again. Without this loop, you are tuning blind.
Jack’s analysis
My view, and it is analysis: treat the embedding step like any measuring instrument. Calibrate it on your own questions, keep a small set of known-good queries, and rerun them whenever the model, the chunking or the data changes.
What this example does not show
The sketch is explanatory. It is not a benchmark and not a production index, and it says nothing about how well any embedding model performs on your data. Quality has to be measured on your own queries.
Questions worth carrying into a review
- How are documents chunked, and does a chunk keep enough context to be meaningful?
- Is the same model used for documents and queries?
- Which distance measure is used, and was it chosen or inherited?
- How does the index learn about new and deleted documents?
- What does a user see when retrieval finds nothing close?