A vector embedding is a list of numbers, produced by an embedding model, that represents a piece of content such as a sentence, document, image or product so that similar content has similar vectors. By comparing vectors, software can find items that mean the same thing even when they share no keywords. Vector embeddings power semantic search, recommendations and retrieval-augmented generation (RAG).
This page focuses on practical use in search and applications. For how embeddings work inside models, see What is an Embedding?
Key takeaways
- A vector embedding turns content into a fixed-length list of numbers, often hundreds to a few thousand long.
- Similarity is measured with cosine similarity, dot product or distance.
- Embeddings are stored and searched in vector databases or vector indexes.
- They are the backbone of RAG systems that ground LLM answers in your documents.
- Use the same embedding model for both documents and queries.
Vector embeddings explained in simple terms
Imagine giving every document in your company a GPS coordinate, but in a space of meaning rather than geography. Documents about refunds sit in one neighbourhood, onboarding guides in another. When someone asks a question, you compute its coordinate and look for the nearest documents. That is vector search, and the coordinates are vector embeddings.
How vector embeddings are created and used
- Choose an embedding model suited to your language and content.
- Chunk long documents into passages, often a few hundred tokens each.
- Embed each chunk to get a vector.
- Store vectors with their text and metadata in a vector database or index.
- Embed the query with the same model at search time.
- Retrieve the nearest vectors and return the matching chunks.
- Optional: pass the chunks to an LLM to generate a grounded answer (RAG).
Measuring similarity
Cosine similarity measures the angle between two vectors: 1 means the same direction (very similar), 0 means unrelated.
Worked example with tiny 3-dimensional vectors:
- Query “reset my password”: [0.9, 0.1, 0.2]
- Article A “How to change your password”: [0.8, 0.2, 0.1]
- Article B “Our refund policy”: [0.1, 0.9, 0.3]
Dot product of query and A = 0.72 + 0.02 + 0.02 = 0.76. Query and B = 0.09 + 0.09 + 0.06 = 0.24. After dividing by the vectors’ lengths, cosine similarity is about 0.99 for A and about 0.27 for B, so A is returned first. Real embeddings have far more dimensions, but the maths is the same.
Choosing an embedding model
| Factor | What to consider |
|---|---|
| Language support | Strong performance on your languages, including Indian languages if relevant |
| Dimensions | More dimensions can capture more nuance but cost more storage and search time |
| Maximum input length | How many tokens each chunk can contain |
| Domain fit | General models vs models tuned for code, law or medicine |
| Benchmarks | Leaderboards such as MTEB (Massive Text Embedding Benchmark) compare models |
| Hosting and cost | API-based or self-hosted open models |
Vector search at scale
Comparing a query with millions of vectors one by one is slow. Vector databases use approximate nearest neighbour (ANN) indexes, such as HNSW graphs, to find close matches quickly with a small accuracy trade-off. Many teams combine vector search with keyword search, called hybrid search, for the best results.
Common uses
- Semantic search across help centres, intranets and knowledge bases.
- RAG chatbots answering from company documents.
- Duplicate and near-duplicate detection.
- Product and content recommendations.
- Clustering feedback and support tickets by theme.
- Internal linking suggestions for content sites.
Limitations
- Similar is not the same as correct; retrieved chunks may be related but not answer the question.
- Exact terms, codes and numbers can be missed without keyword search.
- Changing embedding models requires re-embedding all content.
- Poor chunking can split key information across chunks.