Embedding (AI)
An embedding is a vector, a list of numbers, produced by a machine learning model to represent the meaning of a piece of content: text, an image, audio or code. Two pieces of content with similar meaning end up with vectors that sit close together in this numeric space, even when they share no words in common. This is what lets software compare meaning instead of matching exact keywords, and it is the mechanism behind semantic search, recommendation systems and retrieval-augmented generation (RAG). Embeddings turn unstructured content, articles, product descriptions, support tickets, into something a machine can search, cluster and rank mathematically, which is why they sit at the core of most modern AI applications. Before embeddings became standard, systems relied on exact keyword matching or hand-built taxonomies to connect a query to relevant content, an approach that broke down as soon as the wording differed even slightly from what was indexed.
How embeddings work
An embedding model reads a piece of content and outputs a fixed-length vector, typically between 256 and 3072 numbers depending on the model. Content only needs to be converted once: the resulting vectors are stored in a vector database, then compared to a query vector at search time using a distance metric. The closer the vectors, the closer the meaning, regardless of the exact words used in either piece of content.
const vector = await embed("what is an embedding?");
// vector => [0.0123, -0.0456, 0.0891, ...] (1536 numbers for many models)
const score = cosineSimilarity(vector, storedVector);
Dimensionality is a direct trade-off between accuracy and cost: a 3072-dimension vector captures more nuance than a 256-dimension one, but it takes more storage and more compute to compare at query time. Most production systems settle on a model in the 768 to 1536 range, which balances retrieval quality against the size of the index and the latency budget of the application.
The distance metrics used in practice:
- Cosine similarity: measures the angle between two vectors, the standard choice for text.
- Dot product: fast to compute, used once vectors are already normalised.
- Euclidean distance: straight-line distance, more common for image or audio embeddings.
Types of embeddings
Not every embedding represents the same kind of content, and the model has to match the use case:
- Word embeddings (Word2Vec, GloVe): one vector per word, now largely superseded by sentence-level models.
- Sentence or document embeddings: one vector per paragraph, page or chunk, the standard for search and RAG.
- Image embeddings (CLIP and similar): place an image and a text description in the same space, so a system can compare them directly.
- Code embeddings: used by IDE assistants and code search to find similar functions or snippets.
- Multimodal embeddings: combine text, image and audio in a single shared vector space.
Choosing the wrong type is a common source of poor results: a word-level model cannot capture the meaning of a full support ticket, and a general-purpose text model will underperform a code-specific one on a codebase search feature. Matching the embedding type to the content and the query is as important as the choice of vector database.
Embedding search vs keyword search
Keyword search and embedding search solve the same problem, finding relevant content, with very different mechanics underneath:
| Aspect | Keyword search | Embedding search |
|---|---|---|
| Matching logic | Exact or fuzzy string match | Vector distance (meaning) |
| Handles synonyms / paraphrase | No, needs a synonym list | Yes, natively |
| Typical use case | Site search, SQL filters | RAG, semantic search, recommendations |
| Infrastructure | Text index (Elasticsearch, SQL) | Vector database (Pinecone, pgvector) |
Best practices and common pitfalls
- Chunk long documents before embedding: a single vector for a 20-page PDF loses too much detail to be useful for retrieval.
- Never mix embeddings from different models: each model has its own vector space, so distances are not comparable across them.
- Re-embed the whole corpus whenever the embedding model is upgraded, old and new vectors cannot be searched together reliably.
- Normalise vectors before computing cosine similarity to keep scores consistent across content types.
- Pair embedding search with a reranker for the final short list when precision matters more than recall.
- Monitor for stale content: a vector index that is not refreshed when the source content changes will keep returning outdated results.
Embeddings, RAG and AI search engines
Retrieval-augmented generation uses embeddings to find the passages most relevant to a user's question before a language model drafts an answer, which keeps responses grounded in real content instead of the model's training data alone. The same logic increasingly drives AI answer engines and AI overviews: a page that is clearly structured into well-defined chunks, headings, short paragraphs, explicit definitions, embeds more accurately and is easier for an AI system to retrieve and cite correctly. This is why embedding quality has become a GEO consideration, not only a backend detail for developers, and why well-structured, definitional content tends to outperform vague marketing copy in AI-generated answers. A page written to answer one clear question at a time, without burying the definition under filler, is simply easier for an embedding model to represent well.
Embedding at BeBranded
At BeBranded, we build embedding-based pipelines for clients who need semantic search on their own content, an AI chatbot grounded in their documentation, or a RAG workflow connected to their existing tools. This work is part of our Automation service.
