Embedding Models in RAG Explained: From Knowledge Base Construction to Similarity Retrieval

Retrieval-Augmented Generation (RAG) is rapidly becoming the go-to approach for deploying large language models in enterprise settings. Rather than relying solely on knowledge baked into model parameters, RAG enables LLMs to reference external knowledge bases when answering questions — turning a "closed-book exam" into an "open-book exam." Within this pipeline, the Embedding model is often the most critical and most overlooked component. This article, based on a RAG hands-on tutorial, breaks down how Embedding models work within RAG and how to optimize them.

What Problem Does RAG Actually Solve

The core capability of a large language model is to receive a user query and produce an answer. But relying purely on internal parameters has well-known limitations: knowledge can be outdated, domain-specific details may be missing, and the model may confidently generate incorrect information.

RAG takes a straightforward approach: before the model answers, retrieve relevant documents from a knowledge-based vector database and pass them to the model as context alongside the original query. The model now has both the question and relevant reference material, leading to more accurate responses.

A useful analogy from the tutorial: this is equivalent to turning a closed-book exam into an open-book one — the model can even look up the exact answer from the provided context before responding. This explains why RAG has been so widely adopted for enterprise Q&A systems, document assistants, and similar use cases.

How the Knowledge Base Is Built

Before the model can "open the book," you need to prepare the book itself — the vector knowledge base. This process involves several steps.

It starts with raw text: large collections of documents, books, or other unstructured content. These can't be used as-is; they must go through chunking, where the content is split into smaller text segments — referred to in the tutorial as documents.

Each chunk is then fed into an Embedding model, which performs one simple but essential operation: converting each piece of text into a vector. These vectors are then stored in a vector database.

It's worth noting that while there are many choices for which vector database to use, the Embedding model is solely responsible for the text-to-vector conversion step — the choice of database is a relatively independent engineering decision. This entire pipeline is an offline preprocessing step; the knowledge base must be built before any retrieval can happen.

Chunking strategy has a significant impact on retrieval quality. Common approaches include splitting by fixed character count, splitting at sentence or paragraph boundaries, and sliding-window splits with overlap. Overlapping chunks matter because meaningful semantic content often spans the boundary between two adjacent chunks — hard splits risk missing both. In practice, retaining 10–20% overlap between adjacent chunks helps reduce information fragmentation. Chunk size is also a hyperparameter that requires careful tuning: chunks that are too small lose semantic completeness, while chunks that are too large introduce noise and consume more of the context window, increasing inference costs.

Retrieval and Assembly: The Embedding Model's Second Appearance

At inference time, the pipeline mirrors the construction phase. When a user submits a query, the system doesn't immediately pass it to the LLM — it first performs a retrieval step.

The user's query is also a piece of text, so it too is passed through the Embedding model and converted into a vector (referred to in the tutorial as factor A). This vector is then compared against all the pre-stored vectors in the database (factor 1 through factor N) to compute similarity scores.

The system then selects the top-k similar documents — the most relevant chunks — and uses them as context. This context is concatenated with the user's query to form the LLM's input, more formally known as the prompt.

The LLM then receives this assembled prompt — containing both the user's question and the retrieved reference material — and generates a more informed, accurate response.

Notably, the Embedding model appears twice in the RAG pipeline: once during offline knowledge base construction, and once during online retrieval. Both times, the goal is the same — mapping text into a shared vector space.

Relevance Is the Lifeline of RAG Quality

The tutorial repeatedly emphasizes one point: the retrieved context must be as relevant to the user's query as possible.

If the retrieval step surfaces a large amount of unrelated documents, that content doesn't help the model — it becomes noise. The more noise, the more the model gets distracted, and answer quality degrades. Finding the right documents is therefore the key determinant of RAG performance.

This judgment of "relevance" ultimately comes down to vector similarity. Whether two vectors (say, factor A and factor E) are related depends on their distance or angular relationship in the vector space. This naturally raises a deeper question: what exactly does a vector look like? What does text actually become after being converted into a vector?

This is precisely the starting point for understanding Embedding fine-tuning — only by understanding the nature of vectors and how similarity is computed can you appreciate why fine-tuning an Embedding model on domain-specific data can significantly improve retrieval precision.

The two most common vector similarity metrics are Cosine Similarity and Dot Product. Cosine similarity measures the cosine of the angle between two vectors, producing values between -1 and 1. Because it's independent of vector magnitude, it's insensitive to text length and is the most widely used metric for text retrieval. Dot product is influenced by both direction and magnitude; when vectors are L2-normalized (magnitude = 1), dot product and cosine similarity become equivalent. Euclidean (L2) distance is another option, where smaller distances indicate greater similarity. Different vector databases and Embedding models have varying levels of support for these metrics — when selecting your stack, make sure the similarity objective used during model training matches the metric used at retrieval time, or you'll introduce systematic errors.

Why Embedding Models Deserve Dedicated Optimization

In many RAG implementations, engineers invest heavily in prompt engineering and LLM selection while simply plugging in an off-the-shelf general-purpose Embedding model. But as the pipeline above makes clear: if the Embedding model doesn't accurately represent domain-specific text in vector space, retrieval will surface the wrong documents — and no matter how capable the downstream LLM is, it can't compensate for irrelevant context.

Fine-tuning an Embedding model on domain-specific corpora (such as medical, legal, or financial text) — so that related documents cluster closer together in vector space while unrelated documents drift further apart — is one of the most cost-effective ways to improve overall RAG performance. This is precisely why the tutorial treats Embedding fine-tuning as its central hands-on topic.

This article covers the foundational mechanics of RAG and Embedding models. The specific structure of vectors, similarity algorithms, and the practical details of fine-tuning are natural next steps. With a clear understanding of the full pipeline — text → vector → similarity → retrieval → assembly → generation — you can approach fine-tuning with a precise, targeted strategy rather than guesswork.

Embedding fine-tuning typically uses a Contrastive Learning framework. The core idea is to construct positive pairs (semantically related sentence pairs) and negative pairs (semantically unrelated pairs), then train the model to pull positive pairs closer and push negative pairs further apart in vector space. Common loss functions include InfoNCE Loss and Multiple Negatives Ranking Loss. In vertical domain scenarios, positive pairs often come from Q&A pairs in domain documents, paraphrases of the same passage, or manually labeled relevant document pairs. The quality of negative sample construction has an outsized impact on fine-tuning effectiveness — randomly sampled "easy negatives" tend to cause the model to converge quickly but generalize poorly. Incorporating hard negatives (text that is semantically similar but actually irrelevant) is essential for building genuine discriminative power in domain-specific retrieval.