What is a vector embedding?

Every chapter in the previous two Parts assumed retrieval simply works: ask for what’s relevant, and the right memories come back. That assumption rests on a specific piece of machinery that’s been mentioned in passing dozens of times without ever being explained directly, the vector embedding. Understanding what an embedding actually is, and why it lets a computer judge “similar meaning” rather than just “matching words,” is the foundation everything else in this new Part builds on.

What Is a Vector Embedding, in the Simplest Possible Terms?

A vector embedding is a list of numbers that represents the meaning of a piece of content, whether that’s a word, a sentence, an image, or something else entirely. The list has a fixed length, often hundreds or thousands of numbers, and each number contributes to describing some aspect of what the content means, even if no single number corresponds to anything a person could point to and name directly. Two pieces of content with similar meaning end up with embeddings that are numerically close to each other, while two pieces of content with unrelated meaning end up numerically far apart.

This is genuinely the entire concept in its simplest form: meaning gets converted into coordinates in a space, and distance in that space corresponds to difference in meaning. Everything else about embeddings is really just detail on top of that one core idea.

How Does Converting Meaning Into Numbers Actually Solve a Real Problem?

Plain text matching can only find content that shares the same words. A search for “seafood pairing” using pure keyword matching won’t find a note that says “goes well with fish,” even though the two phrases mean essentially the same thing, because they don’t share any of the same words. Embeddings solve exactly this problem: a machine learning model trained to understand language converts both phrases into vectors, and those vectors end up close together because the model has learned that “seafood” and “fish” relate to similar concepts, even without either phrase literally containing the other’s words.

This is the entire reason embedding-based search gets called “semantic” search rather than just “search.” It isn’t matching on the literal characters in a query, it’s matching on the meaning those characters are trying to express, at least to whatever degree the underlying model has actually learned to capture that meaning well.

What Does It Mean for a Vector to Have “Dimensions,” and Why Does That Number Vary?

Each individual number in an embedding is called a dimension, and the total count of these numbers, sometimes a few hundred, sometimes several thousand, depends entirely on which specific embedding model produced the vector. More dimensions generally allow a model to capture more nuance about what’s being represented, at the cost of the vector being larger and more computationally expensive to compare against others. There’s no universally correct dimension count, the right tradeoff depends on how much nuance a particular use case actually needs weighed against how much computational cost is acceptable.

What matters practically is that every embedding being compared against every other one has to come from the same model, and therefore live in the same dimensional space. A vector from one model and a vector from a different model aren’t directly comparable, even if both happen to have the same number of dimensions, because each model has its own internal, learned sense of what each dimension represents.

Is a Vector Embedding Only Useful for Text, or Does This Concept Apply More Broadly?

The underlying concept, meaning converted into numerical coordinates where distance corresponds to difference in meaning, applies well beyond text. Images, audio, and other kinds of content can each be embedded by a model trained specifically for that content type, producing vectors that behave the same way: perceptually or conceptually similar images end up with nearby vectors, just as semantically similar sentences do. This is exactly the foundation the earlier chapter on multi-modal memory rested on without spelling it out explicitly at the time, since embedding multiple modalities into a shared space is what makes cross-modal comparison possible at all.

How Does Weaviate Engram Rely on Vector Embeddings to Make Memory Search Actually Work?

Every memory Weaviate Engram stores gets automatically converted into a vector embedding at write time, which is precisely what makes semantic memory search possible rather than requiring an exact wording match between a query and a stored memory. Consider a chess-coaching assistant helping a student review their games by finding conceptually similar historical positions and past feedback, where the exact wording a student uses to describe a position rarely matches how it was originally recorded:

from engram import EngramClient

client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])

client.memories.add(
    "Student consistently struggles with knight outposts in the center of the board, often trading them off too early instead of using them as a long-term structural advantage.",
    user_id="student-4471",
)

Weeks later, the student asks a question phrased entirely differently from how this feedback was originally written:

relevant_feedback = client.memories.search(
    query="Why does my coach keep telling me not to trade my centralized knight?",
    user_id="student-4471",
)

Nothing about this query shares exact wording with the stored feedback, “centralized knight” versus “knight outposts,” “trade” appearing in both but framed completely differently. Yet the search still surfaces the right memory, because both the stored fact and the new query were converted into vector embeddings that landed close together in the same meaning-space, reflecting that they’re both fundamentally about the same underlying chess concept. This is what makes memory search in Engram behave the way it does throughout this entire knowledge base: not a brittle exact-match lookup, but a comparison of meaning, made possible entirely by the vector embedding this chapter has just introduced.

Understanding what an embedding is explains how meaning gets represented numerically. The next natural question is how a specific machine learning model actually produces those numbers, and what “semantic similarity” concretely means once two pieces of content have both been converted into vectors. Our next chapter, What are embedding models and semantic similarity?, takes up exactly that question.