What Are Vector Embeddings? Semantic Email Search Explained

A vector embedding is a list of numbers — typically hundreds or thousands of them — that represents the meaning of a piece of text. Two phrases that mean roughly the same thing produce numbers that point in roughly the same direction in that high-dimensional space. Search systems use that geometry: instead of checking whether a query word appears verbatim in a document, they measure how similar the query's direction is to each stored chunk, and return the closest ones. That is what makes email search semantic — the comparison is on meaning, not character patterns.

The term "vector embeddings in search" refers to this whole pipeline: convert text to numbers, store the numbers, compare the query's numbers to the stored ones at search time. The underlying model was trained on large amounts of text with a simple objective: text with similar meaning should end up near each other in numeric space. That training is what gives the numbers their meaning-preserving property.

This post explains how the pipeline works in practice, what the honest limitations are, and where semantic email search sits relative to the keyword alternative.

How does a vector embedding actually work?#

Three steps happen every time text is converted to an embedding.

First, the text is split into chunks. A long email thread cannot fit through an embedding model in one pass, so it is divided into overlapping segments — typically a few hundred tokens each. The overlap preserves context that would otherwise be cut at a boundary. This step is called chunking, and it is why search can return a specific passage from a long thread rather than just pointing to the whole conversation.

Second, each chunk passes through an embedding model — a neural network whose output is a fixed-length list of floating-point numbers. The model was trained so that chunks with similar meaning end up near each other in that numeric space. "Q3 budget review" ends up near "quarterly financial summary." "Budget review" ends up far from "cancel my dentist appointment." The model does not store a lookup table of synonyms; it learned the geometry of meaning from the training data itself.

Third, those vectors are stored in a database built for vector lookups — often called a vector database or vector index. When a search query arrives, it goes through the same embedding model to produce its own vector. The search then finds stored chunks whose vectors sit closest to the query vector and returns the original text they came from.

The similarity measure used is typically cosine similarity: it measures the angle between two vectors rather than the distance between their endpoints. Two vectors pointing in roughly the same direction score near 1. Two pointing in opposite directions score near -1. Shared meaning produces a small angle, and a small angle produces a high cosine similarity score — which is why the search surfaces topically related content rather than just character-matched content.

Why does keyword search fail where embeddings succeed?#

Keyword search is exact by design. It checks whether the tokens in your query appear in the indexed document. That works reliably when you know the exact words that were written. It fails whenever the writer used different words than the searcher.

Search your inbox for "cost breakdown" when the email used "budget analysis" and a keyword system returns nothing. The meaning is present; the character match is not. A recruiter searching for "software engineer" misses every thread where the sender wrote "SWE." A founder searching for "investor update" misses the email titled "Q2 report." Those are not edge cases — they are the normal way people recall a conversation: by what it was about, not by the specific words used.

Embeddings fix that class of failure. A query for "cost breakdown" produces a vector that sits close to the vector for "budget analysis" in the embedding space, and the search returns the right document. The retrieval system never compared character strings — it compared directions in numeric space.

The failure mode runs the other direction too. Exact-match queries — a tracking number, a specific error code, a name with an unusual spelling — can trip semantic search. The embedding model returns results that are topically adjacent to the query, not necessarily the one document containing that precise string. That is not a flaw in the concept; it is an inherent tradeoff. The reason production search systems almost always combine vector search with traditional keyword scoring is that the two failure modes are complementary: one handles meaning, the other handles exactness.

Vector search vs keyword search: what actually differs#

The table below compares the two on the dimensions that matter most for an inbox search system. Neither approach is strictly better — each has a domain where it outperforms the other.

Why hybrid retrieval is the practical answer#

Running both approaches and merging their results — called hybrid retrieval — is what most production search systems use. The keyword layer catches the exact-match queries that semantic search fuzzifies; the vector layer catches the paraphrase and synonym queries that keyword search misses entirely. The merge is typically done with a ranking formula that weights scores from both passes.

The infrastructure cost of adding vector search is real: the system needs an embedding model, a vector index, and the compute to reindex as new mail arrives. That overhead is why semantic inbox search arrived in enterprise products before consumer clients — it was not practical at mailbox scale until recently. A self-hosted setup using PostgreSQL with the pgvector extension is now one of the more common approaches, since it stores both vectors and message metadata in the same database without a separate vector service.

Three things people get wrong about embeddings#

The first misconception is that embeddings capture whether content is accurate. An embedding captures topical shape, not truth. A thread full of incorrect claims and a thread with correct information on the same topic can produce nearly identical vectors if they discuss the same subject. Vector search returns topically related content — it says nothing about factual accuracy, recency, or the quality of the reasoning inside the text.

The second misconception is that embeddings can be reversed to recover the original email. Vector embeddings are a lossy compression of meaning: you cannot reconstruct the original text from the numbers. Multiple different sentences can produce nearly identical vectors. What the vector enables is finding similar text — not reading the source back out of it. The email content itself is stored separately; the embedding is the search index, not the document.

The third misconception is that semantic search alone is enough. Pure vector retrieval is imprecise for exact-match queries. If you need a specific invoice number, a quoted name, or an error string, a semantic search may return documents on the right topic but not the one containing that precise text. Hybrid retrieval — not pure vector search — is the right architecture for an inbox where users alternate between intent-based queries and exact lookups.

How this shows up in AI Emaily#

AI Emaily's semantic search uses vector embeddings to search your inbox by meaning rather than by exact words. Queries like "budget questions from the board" or "anything about the contractor invoice" return the right threads even when none of those exact phrases appear in the messages. The system runs on pgvector — a PostgreSQL extension for vector storage and similarity search — so embeddings are stored and queried in the same database as your mail metadata, without a separate vector service. We build AI Emaily.

The search is hybrid: a vector retrieval pass runs alongside keyword scoring, so exact-match queries for specific codes or names still work reliably. The result is a search that handles the way you actually think about a conversation — by what it was about, not by the specific words used. Explore the feature at /features/smart-search, learn more at aiemaily.com, or see plan details and the 7-day free trial at /pricing.