A computer does not understand words. It understands numbers. For decades, the most common way to search for information was to match exact words: if you typed "invoice" but the document said "receipt", the search found nothing. Embeddings changed this by translating the meaning of words, sentences and documents into lists of numbers — vectors — that a machine can compare.
This idea sits behind almost everything we now call applied artificial intelligence: semantic search, assistants that answer based on a company's documents, recommendation systems and duplicate detection. And when there are many vectors to compare, a dedicated piece of infrastructure comes into play: the vector database.
In this article I explain, without too much jargon, what an embedding is, how meaning turns into geometry, what sets a vector database apart from a traditional one, and where this tends to go wrong in practice.
What an embedding actually is
An embedding is the representation of a piece of information — a word, a sentence, a paragraph, an image — as a vector of numbers. In practice, it is a list of hundreds or thousands of values. A model trained for the task reads the text and returns, for example, a list like [0.021, -0.874, 0.335, ...] with hundreds of values that summarise what the text "means".
What matters is not each number in isolation, but the position the vector occupies in a space with many dimensions. Texts with similar meanings end up close together; texts about different subjects end up far apart. "Invoice", "receipt" and "payment note" fall into the same neighbourhood, even without sharing a single letter.
How meaning turns into geometry
The model learns these representations from enormous amounts of text. By seeing millions of examples, it notices that certain words appear in similar contexts and adjusts the vectors to reflect those similarities. The result is a map in which distance has meaning: the closer, the more related.
This is why we talk about semantic search — searching by meaning rather than by letters. When you ask a question, the system turns the question into a vector and looks for the nearest vectors in the space. It does not matter whether you used exactly the same words; what matters is whether the meaning is close.
Keyword search vs semantic search
Classic keyword search is still useful and fast, especially for exact terms: an item code, a proper name, a reference. But it fails when the same idea can be phrased in many ways. Semantic search covers precisely that gap.
- Keywords: find exact matches, transparent and cheap, but blind to synonyms and rephrasings.
- Semantic: understand meaning and handle synonyms and whole sentences, but require embeddings and more compute.
- Hybrid: in practice, many solutions combine both, using keywords for precision and vectors for coverage.
What a vector database is
Storing ten vectors is trivial. Storing ten million and finding, in milliseconds, the ones most similar to a given vector is not. That is the job of a vector database: to store vectors and answer quickly the question "which are the k vectors closest to this one?".
Doing it exactly, comparing against all of them, would be far too slow at scale. So these databases use approximate nearest neighbour (ANN) indexes, which trade a little accuracy for a lot of speed. Structures such as navigation graphs (HNSW) or cluster partitions (IVF) allow searching only a fraction of the data. To decide whether two vectors are "close", you need a measure: the most common is cosine similarity, which compares the direction of the vectors and ignores their length. Using the wrong metric, or mixing vectors from different models, produces meaningless results — always use the same embedding model to index documents and to convert queries.
A dedicated store or vectors in the database you already have
There are two broad options. Dedicated vector databases were designed from the ground up for this problem and shine when volume is very large and latency is critical. Alternatively, many relational databases and search engines already offer vector search as a feature, which avoids adding yet another system to the architecture.
The decision should not follow fashion. If your data already lives in a relational database and the volume is moderate, built-in vector search is usually enough and simpler to maintain. Introducing a new system is only justified when scale and performance demand it.
Where embeddings pay off
- Internal search: find documents, policies or tickets by meaning, not by exact word.
- Assistants with context (RAG): fetch the relevant passages from a knowledge base to feed a language model before it answers.
- Recommendation: suggest articles, products or content similar to what a person has already seen.
- Deduplication and clustering: detect near-identical records or automatically group similar topics.
- Classification: route a request to the right team based on its similarity to past cases.
Common mistakes to avoid
The first mistake is splitting documents badly. Store texts that are too long and the vector becomes "diluted" and loses precision; cut them too short and you lose context. Chunk size deserves attention and testing.
Other frequent stumbles: mixing embeddings from different models in the same index; choosing the wrong distance metric; forgetting that vectors age — if documents change, they must be re-indexed; and ignoring the cost and latency of generating embeddings on every search. Finally, many projects move ahead without any way to evaluate result quality, which makes it impossible to know whether a change improved or worsened the search.
Mini-case: from search that found nothing
A retail company with a large catalogue kept getting complaints that its site search "found nothing". Looking at the logs, the team realised that around 30% of searches ended with no results even though the product existed — customers used words different from the internal descriptions.
The fix was to add semantic search: each product got an embedding of its description, stored with vector search in the database they already used, and queries were turned into vectors. They kept keywords for exact references and combined the two approaches. Within a few weeks, no-result searches fell below 10% and the conversion rate from search rose noticeably. The extra cost was modest because they reused existing infrastructure and only re-indexed when the catalogue changed.
In practice
Embeddings are the bridge between human language and the way machines compare information: they turn meaning into geometry and let you search by sense. Vector databases are the infrastructure that makes that comparison viable at scale. They are not magic — they depend on good decisions about text splitting, model choice, metric and evaluation.
If you are starting out, resist the temptation to build a complex system straight away. Begin with a concrete case that has clear value — an internal search, an assistant over documents — measure the results, and use the vector search your database already offers. Only later, if scale justifies it, move to dedicated solutions.
