Embeddings and Vector Databases Explained Simply

What is an embedding?#

An embedding is a numerical representation of text that captures its meaning. Anthropic's documentation describes text embeddings as numerical representations of text that let you measure semantic similarity, and lists uses such as search, recommendations and anomaly detection. In practice, each sentence or passage becomes a long list of decimal numbers called a vector.

You never read these numbers yourself. What matters is the pattern: two passages about the same idea produce vectors that sit close together, while unrelated passages produce vectors that sit far apart. “How do I apply for annual leave?” and “What is the process for requesting time off?” share few words, but their embeddings would be close.

An embedding model is a type of AI model built to produce these vectors. It is usually separate from the chat model that writes answers. Anthropic's documentation, for example, notes that Anthropic does not offer its own embedding model and points to a third-party provider instead.

How do embeddings capture meaning?#

Embeddings capture meaning because the embedding model has learned, from large amounts of text, which words and phrases are used in similar ways. Similar meanings land in similar positions. To compare two pieces of text, a system measures how close their vectors are, using a similarity measure such as cosine similarity or dot product.

Anthropic's embeddings documentation lists three common measures: dot-product similarity, cosine similarity and Euclidean distance. It notes that when embeddings are normalised to length 1, cosine similarity and dot product give the same result, and dot product is faster to compute. You rarely need to choose this yourself, because most tools set a sensible default.

This is different from traditional keyword search. A 2020 research paper on dense passage retrieval, published on arXiv, describes sparse methods such as TF-IDF and BM25, which work by matching words, as the established approach for finding passages. The paper showed that retrieval can be done with dense representations alone, using embeddings learned from questions and passages. Matching by meaning in this way is called semantic search.

Many practical systems use both, because each covers the other's weak spots.

What is a vector database?#

A vector database is a store built to hold large numbers of embeddings and find the closest ones to a query quickly. Each entry usually keeps the vector, the original text and details such as the document name or date. When a question arrives, the database returns the entries whose vectors are nearest to the question's vector.

The paper describing the Faiss library, a toolkit for vector similarity search, puts it simply: vector databases typically manage large collections of embedding vectors, and vector similarity search is a core function of a vector database. Comparing a question against every stored vector one by one becomes slow as a collection grows, so these systems use indexes that trade a little accuracy for a lot of speed.

One technique, described in a research paper on Hierarchical Navigable Small World (HNSW) graphs, builds layers of linked points so that a search can start broadly and narrow down quickly. This is called approximate nearest neighbour search: the result is very likely, but not guaranteed, to be the closest match.

You do not need a dedicated product to start. For a small set of documents, similarity can be computed directly in memory, as the quickstart example in Anthropic's embeddings documentation does with six short documents. A dedicated vector database matters more as the collection grows.

How do they work together in a RAG system?#

In a retrieval-augmented generation (RAG) system, embeddings and a vector database form the search engine. Your documents are split into chunks, embedded and stored. Each question is embedded with the same model, the nearest chunks are retrieved and the large language model (LLM) writes its answer from them.

1. Chunk. Split each document into passages of a manageable size. This is called chunking.
2. Embed the documents. Turn each chunk into a vector with an embedding model.
3. Store. Save each vector with its text and source details in a vector database.
4. Embed the question. Turn the user's question into a vector with the same model. Anthropic's documentation shows the provider it describes using separate settings for queries and documents, which can improve retrieval.
5. Search. Find the stored vectors nearest to the question's vector.
6. Answer. Pass the matching chunks and the question to the language model, with instructions to answer from them and name the source.

The original 2020 RAG paper used this kind of setup: a dense vector index of Wikipedia, accessed with a neural retriever, alongside a language model.

What does a worked Singapore example look like?#

Imagine a family-run hardware supplier in Sungei Kadut whose sales staff search a long product catalogue to answer trade customers. This illustrative example shows how embeddings could help staff find products described in everyday words, without claiming any results or figures.

Customers rarely use catalogue names. One asks for “something to stop a door slamming”, another for “the bracket that holds a shelf to the wall”. A keyword search for “slamming” finds nothing, because the catalogue says “hydraulic door closer”.

A simple plan might be:

• Embed the catalogue. Each product description becomes one chunk with its own embedding, stored with the product code and price list reference.
• Search by meaning. A staff member types the customer's words. The system finds the products whose descriptions are closest in meaning, including the door closer.
• Keep keyword search for codes. When a customer quotes an exact product code, a plain keyword lookup is more reliable.
• Check the top results. Staff confirm the match before quoting, because the closest meaning is not always the right product.

Because the catalogue contains no customer details, the team avoids personal data questions at this stage. Adding order history later would need a separate check on which tools are approved for that data.

Common mistakes#

The most common mistakes are mixing embedding models, choosing chunks that are too long or too short, storing vectors without their source details, forgetting to re-embed documents that change, relying on embeddings alone for exact codes and numbers, and adding confidential or personal data to tools that have not been approved for it.

• Mixing models. Vectors from different embedding models are not comparable. Embed questions and documents with the same model, and re-embed everything if you switch.
• Bad chunk sizes. Very long chunks blur several topics together; very short ones lose context.
• No source details. Without the document name and section, you cannot show where an answer came from.
• Stale vectors. When a document changes, its chunks must be embedded again.
• Meaning-only search for exact items. Codes, IDs and amounts are often better found by keyword.
• Not testing retrieval. Check that the right passages come back for real questions before you judge the answers. Our guide on testing AI-generated outputs helps.

What to learn next#

Now that you know how embeddings and vector databases find relevant text, the next step is to see how that text is used to produce answers, and when retrieval is worth adding at all. After that, practise building a small app so you can test retrieval with your own questions.

• Read what RAG is to see the full pipeline, then compare prompting, RAG and fine-tuning.
• Browse more guides in AI for builders, or follow the AI learning pathway.
• To plan, build, test and launch a simple AI app in a classroom, see GenAI Builder Sprint, a 2-day course with no previous AI or programming experience needed, although formal entry requirements apply.

Sources#

1. Embeddings, Anthropic (Claude Platform Docs), accessed 8 November 2026
2. Dense Passage Retrieval for Open-Domain Question Answering, arXiv, accessed 8 November 2026
3. The Faiss library, arXiv, accessed 8 November 2026
4. Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs, arXiv, accessed 8 November 2026
5. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, arXiv, accessed 8 November 2026

Frequently asked questions#

What is an embedding in simple terms?+

An embedding is a list of numbers that represents the meaning of a piece of text. Anthropic's documentation describes text embeddings as numerical representations of text that let you measure semantic similarity. Texts with similar meanings get similar numbers, so they sit close together.

What is a vector database?+

A vector database stores large collections of embeddings, along with the original text and details such as the document name, and quickly finds the embeddings closest to a question. Vector similarity search is described in the Faiss library paper as a core function of vector databases.

How is semantic search different from keyword search?+

Keyword search matches the words you typed, while semantic search compares embeddings to match meaning. A search for a way to stop a door slamming can find a product called a door closer, even though the words differ.

How is similarity between embeddings measured?+

Common measures are dot product, cosine similarity and Euclidean distance. Anthropic's embeddings documentation notes that embeddings normalised to length 1 give the same result for dot product and cosine similarity, with dot product faster to compute.

How do embeddings relate to RAG?+

In a RAG system, documents are split into chunks, embedded and stored in a vector database. Each question is embedded too, the closest chunks are retrieved, and they are passed to a language model, which writes the answer from them.

What are common mistakes with embeddings?+

Mixing embedding models, using chunks that are too long or too short, storing no source details, forgetting to re-embed changed documents, relying on embeddings alone for exact codes or numbers, and adding confidential or personal data without approval.