After defining RAG, we need the representation that makes “find similar meaning” computable. Embeddings for retrieval turn queries and chunks into vectors ranked by similarity—building on Vol. 12 dense embeddings and contrasting with sparse signals used later in hybrid search.
The next lecture chooses an embedding model; here we focus on what the vectors mean in a RAG pipeline.
Learning Objectives
By the end of this lesson, students should be able to:
- Define a retrieval embedding as a fixed vector for a query or passage.
- Explain asymmetric query–document encoding in bi-encoder setups.
- Encode text with
sentence-transformersand rank by cosine similarity. - Distinguish embedding use in retrieval vs generative LM token embeddings.
- List failure modes: domain shift, length bias, and keyword blindness.
- State why offline document embedding + online query embedding is standard.
A retrieval embedding is a fixed-length continuous vector produced by an encoder so that texts with related meaning (or matching intent) land near each other under a chosen similarity metric—most often cosine similarity or inner product after L2 normalization.
Retrieval vs LM Token Embeddings
| Kind | Unit | Role in RAG |
|---|---|---|
| Token / LM table | Subword | Inside the generator—not your search index |
| Passage embedding | Chunk / doc | Stored in the vector index |
| Query embedding | User question | Computed online; searches the index |
Symmetric
- Same encoder for q & d
- Good for similar text pairs
- Common FAQ setups
Asymmetric
- Query vs long passage
- May use prefixes / dual towers
- Typical web/search RAG
Sparse companion
- BM25 / learned sparse
- Exact terms & IDs
- See hybrid later
Code: Query vs Corpus Vectors
Strengths
- Semantic paraphrase match
- Compact, ANN-friendly vectors
- Fast online query encode
Tradeoffs
- Weak on rare exact strings
- Must re-embed if model changes
- Chunk text quality dominates
“Any vector from the chat LLM is fine for search.” Generative models are not automatically trained for cosine retrieval. Use embedding-specialized checkpoints (or fine-tune with contrastive pairs). Mixing embedding spaces across models silently breaks recall.
Knowledge Check
- Short Answer: What is stored in the index: query or document embeddings? Answer: Document/chunk embeddings (queries are encoded online).
- True/False: Retrieval embeddings are usually sparse one-hots. Answer: False—dense continuous vectors (unless using sparse retrievers).
- Multiple Choice: After L2 normalize, cosine equals: (a) Hamming, (b) dot product, (c) edit distance. Answer: (b).
- Short Answer: Why encode documents offline? Answer: Avoid re-encoding the corpus on every query; enable ANN search.
- True/False: Changing the embedding model requires re-indexing. Answer: True.
- Multiple Choice: Bi-encoders primarily support: (a) cheap independent encode + ANN, (b) pixel shaders, (c) SQL joins only. Answer: (a).
- Short Answer: Name a failure mode of dense retrieval. Answer: Domain shift, length bias, or missing exact keywords (any).
- True/False: Sparse embeddings from Vol. 12 are irrelevant to RAG. Answer: False—they power hybrid search.
- Multiple Choice: Next lecture focuses on: (a) Embedding Model, (b) CSS Grid, (c) PCA only. Answer: (a).
- Short Answer: What Python library encodes MiniLM passages here? Answer: sentence-transformers.
Key Takeaways
- Retrieval embeddings map queries and chunks into a shared similarity space.
- Encode corpus offline; encode queries online.
- Use retrieval-trained encoders—not arbitrary LM states.
- Next: Embedding Model.
Lab: Encode 30 mixed FAQ lines; plot top-3 neighbors for paraphrase vs exact-ID queries.
Prompt: When would asymmetric models outperform a single shared encoder?
Recap: Embeddings make semantic retrieval numeric. Continue with Embedding Model.