Create embeddings

Now the interesting part. We turn each chunk of text into an embedding: a list of numbers that captures its meaning. Passages about the same topic get similar numbers, even when they use different words, which is what lets us search by meaning rather than by keyword.

Choosing a model

An embedding model is trained to produce these vectors. You can call a paid embedding API, but we will use a small open model that runs locally and free: all-MiniLM-L6-v2. It produces 384-number vectors, it is fast, and it is more than good enough to learn with.

When you want better quality later, you swap this one line for a stronger model (the BGE and E5 families are popular). The MTEB leaderboard is the place to compare them, and the choice of embedding model is one of the biggest levers on retrieval quality, so it is worth revisiting.

Embed the chunks

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("sentence-transformers/all-MiniLM-L6-v2")

def embed(texts):
    return model.encode(texts, normalize_embeddings=True)

chunk_texts = [c["text"] for c in chunks]
embeddings = embed(chunk_texts)

print(embeddings.shape)   # (number of chunks, 384)

The first time you run this, the model downloads (a few hundred megabytes); after that it is cached.

Why normalize_embeddings=True

That one argument scales every vector to length 1. It sounds fiddly, but it pays off in the next lesson: with normalised vectors, measuring how similar two of them are becomes a plain dot product. It makes our search code a single line, so leave it on.

One rule to remember

Embed your documents once, and embed each question at search time with the same model. The query and the passages have to live in the same vector space for comparison to mean anything. If you ever change the embedding model, you must re-embed the whole corpus.

Next steps

We have a vector for every chunk. Next we store them and build the search that finds the closest ones to a question.