Vector embeddings are numerical representations of text that capture semantic meaning. In RAG systems, they work in three key steps: 1. **Embedding**: Documents are split into chunks, then passed through an embedding model that converts each chunk into a high-dimensional vector (e.g., 1536 dimensions). 2. **Storage**: These vectors are stored in a vector database (Pinecone, Weaviate, Chroma) along with the original text. 3. **Retrieval**: When a user asks a question, the query is embedded using the same model, then the database finds the closest vectors using cosine similarity. The top-K results are injected into the LLM's context window. This allows the LLM to access up-to-date or private data without retraining.

Retrieval latency depends on the database and index size: • **Pinecone** (managed): ~20-50ms for 1M vectors • **Weaviate** (self-hosted): ~30-80ms • **Chroma** (local): ~5-15ms for <100K vectors • **pgvector** (Postgres): ~50-200ms HNSW (Hierarchical Navigable Small World) indexes are the standard — they trade a small accuracy loss for O(log N) search speed. For production RAG, budget ~100ms total for embedding + retrieval.