Embeddings for Beginners: The Playbook on Vector Search

Meera works at a small company in Pune. Her team keeps a help centre with about 300 articles. A customer types “how do I stop my plan?” into the search box and gets zero results. The article they need exists. Its title is “Cancel your subscription”.

The search box looks for the same words. “Stop” and “cancel” are different words, so it finds nothing. Meera wants a search that understands meaning. That is exactly what embeddings for beginners is about, and this playbook walks through it one small step at a time.

Last verified: 28 October 2026. AI tools change fast; check the linked sources for anything newer.

Who this is for: complete beginners who have used a chatbot but never built anything with AI. Time needed: about 30-40 minutes. No maths background required.

Embeddings for beginners: what they are, in simple words

An embedding is a list of numbers that stands for the meaning of a piece of content, such as a sentence, an image or a bit of code. An AI model creates it for you. That list of numbers is called a vector.

Think of a big map of a city. Every shop has an address. Shops that sell similar things, like all the tea stalls, sit on the same street. An embedding is the address of a sentence on a “map of meaning”. Sentences with similar meaning get addresses close together.

The precise version: the model turns each item into a vector, and items with related meaning get vectors that sit close together.

What is vector search?

Vector search means: turn the question into a vector, then find the stored items whose vectors are closest to it. It is also called semantic search, because it searches by meaning instead of exact words.

Keyword search is like a clerk who only matches the exact words on a label. Vector search is like a clerk who understands what you mean, even when you use different words.

The playbook at a glance

1. Play 1: Pick what you want to search.
2. Play 2: Turn each piece into an embedding.
3. Play 3: Store the vectors where you can search them.
4. Play 4: Search by meaning with a question.
5. Play 5: Test the results and fix what is weak.

Play 1: Pick what you want to search

Goal: decide the pieces of content that the search will return.

1. List your content: help articles, product descriptions, notes.
2. Cut long documents into small pieces, called chunks, of a few short paragraphs each.
3. Keep a title or link with each chunk so you can show it later.

Meera splits her 300 articles into short chunks, so one chunk talks about one idea. A whole article about ten topics would get one blurry address.

You are done when: every chunk is short, about one idea, and has a title attached.

Play 2: Turn each piece into an embedding

Goal: give every chunk its address on the map of meaning.

1. Choose an embedding model. It is a different kind of model from a chat model; its only job is to turn content into vectors.
2. Send each chunk to the model and get a vector back.
3. Always use the same model for your chunks and for later questions. Addresses from two different models do not live on the same map.

Meera picks one embedding model from her cloud provider and runs all 300 articles through it once. If you want to see how models read text first, see our How LLMs work playbook.

You are done when: every chunk has a vector saved next to it, all from the same model.

Play 3: Store the vectors where you can search them

Goal: keep the vectors in a place that can quickly find the closest ones.

1. For a few hundred chunks, a plain list in memory or a file is enough.
2. For many thousands or more, use a vector database. Pinecone, Weaviate, Qdrant, Milvus and the pgvector add-on for PostgreSQL are common examples.
3. Save each vector together with its chunk text and title.

Meera already runs PostgreSQL, so she adds pgvector instead of learning a new product. With millions of vectors, databases use shortcuts that find nearly the closest items very fast instead of checking every one.

You are done when: you can fetch a chunk and its vector back by id.

Play 4: Search by meaning with a question

Goal: return the chunks closest in meaning to what the user typed.

1. Turn the user’s question into a vector with the same model.
2. Score every stored vector against it. The common score is cosine similarity, which compares the angle between two vectors. A higher score means closer meaning.
3. Return the top 3 to 5 chunks.

Here is a small illustration. The embed function stands for a call to your embedding model; the name differs between tools.

import math

def cosine(a, b):
    dot = sum(x * y for x, y in zip(a, b))
    return dot / (math.sqrt(sum(x * x for x in a)) * math.sqrt(sum(y * y for y in b)))

query = embed("how do I stop my plan?")
best = sorted(chunks, key=lambda c: cosine(query, c.vector), reverse=True)[:3]
for c in best:
    print(c.title)

In plain steps: embed the question, compare it with every chunk, sort from most similar to least, and keep the top three.

Meera types “how do I stop my plan?” and “Cancel your subscription” comes first, even though the words differ.

You are done when: a question phrased in new words still finds the right chunk.

Play 5: Test the results and fix what is weak

Goal: prove the search is good, not just good in one demo.

1. Write 20 real questions and note which article should come back for each.
2. Run them and count how often the right article is in the top 3.
3. For misses, try different chunk sizes, add titles to chunks, or mix in keyword search.

Meera finds that product codes like “PLAN-77” are found badly by meaning search. Exact names and ids are where keyword search is still better, so she combines both. This mix is called hybrid search.

You are done when: you have a written list of test questions and a score you can re-check after every change.

Do you need this?

Mistakes to avoid

• Mixing models. Chunks embedded with one model and questions with another will not match. Use one model, and re-embed everything if you change it.
• Huge chunks. A chunk with ten topics gets one blurry address. Keep each chunk to one idea.
• Trusting similar as correct. Close in meaning does not mean the right answer. Always test with real questions.
• Dropping keyword search. Ids and exact names still need it. Use hybrid search.

How to know it is working

• Rephrased questions find the same article.
• The right article is in the top 3 for most of your 20 test questions.
• Questions with no good answer return low scores, so you can show “nothing found”.

Your checklist

• ☐ Content cut into short chunks with titles
• ☐ One embedding model used everywhere
• ☐ Vectors stored with their chunk text
• ☐ Question search returns the top 3 to 5 chunks
• ☐ 20 test questions written and scored

Frequently asked questions

What is an embedding in AI?

It is a list of numbers, made by a model, that captures the meaning of content. Content with related meaning gets numbers that sit close together.

How is vector search different from keyword search?

Keyword search matches exact words. Vector search compares meaning, so “stop my plan” can find “cancel your subscription”.

Do I need a vector database?

Not at the start. A few hundred chunks fit in memory. Move to a vector database when the data grows large or must be shared by many users.

How do embeddings relate to RAG?

RAG lets a language model answer using your own documents. Embeddings and vector search are the step that finds the right documents to hand to the model. Our RAG app with Spring AI guide shows it in code.

Where Meera goes next

A week later, Meera’s customer types “how do I stop my plan?” and lands on the cancel page in one click. She did not teach the search any rules. She only gave every article an address on the map of meaning.

Your next action: embed ten of your own notes and search them. Then read the AI agents playbook, where search becomes one tool an agent can use.

Sources: Embeddings Explained for Beginners (Startupik), read on 28 October 2026. Meera and her help centre are a made-up example.