# Embedding (/academy/embedding)



You cannot hand a computer "the vibe" of a sentence. It does not smell meaning. It does not know that "I forgot my login" and "reset my password" are the same ticket. It only knows numbers.

An **embedding** is what you get when you force meaning through a translator that only speaks lists of floats. A model reads your sentence, then emits a long, boring vector — hundreds or thousands of numbers — that stands in for what the sentence was about. Two tickets that belong in the same pile come out looking alike. Two sentences that share zero words can still match. Two sentences that share a word but not a job — "I love the packaging" vs "my package never arrived" — come out looking different.

That is the leap past old search. Keyword search hunts for the letters you typed. Embeddings hunt for the job you meant. You describe the bug badly. The right paragraph still surfaces, because the two lists are close.

You have already used this without the word:

* Search that survives a typo or a synonym
* "More like this" on a playlist or a store
* An [agent](/academy/agent) that finds the relevant file in a repo you never indexed by title
* Anything called [RAG](/academy/rag): fetch the nearby chunks, then answer

A [vector database](/academy/vector-database) is storage built to ask "who is nearest?" instead of "who has this exact key?" The embedding is the thing you store. The [tokens](/academy/token) you send to *make* that embedding still cost money — you pay to turn the sentence into the list.

One catch, said plainly: close means "showed up in similar company in the training text." That is usually meaning. It is not always truth. A biased corpus makes biased neighbors. Do not treat nearest as correct.

**What this unlocks**

Once meaning is a number, an agent can search your help center the way a teammate searches their memory — by what you asked, not by the filename. That is how a Saturday demo answers from *your* docs instead of inventing a policy.