Type "songs for a rainy Sunday morning" into a music app and you'll get results that match the mood, even though none of those words appear in the track titles. That kind of result is often powered by vector embeddings, numerical representations of meaning that let software compare a query and a song by how close their ideas are, not how many words they share. In production, this semantic retrieval usually runs alongside ranking signals and filters.
If you're building modern semantic search, recommendations, retrieval-augmented generation (RAG) pipelines, or AI agents, vector embeddings often underpin these systems. This guide covers what vector embeddings are (and what they aren't), how models create them, how similarity search works, where they show up in production apps, and what it takes to store and query them for large vector datasets.
What is a vector embedding & what isn't it?
To see why those search and recommendation examples work, start with the basic unit. A vector embedding is a dense list of numbers that represents an item, such as a sentence, image, or product. Semantically similar items land near each other in this numerical space, known as vector space. Terms like "cat," "dog," and "lion" cluster together because they share semantic characteristics, while "car," "truck," and "vehicle" form a separate cluster. Distance in this space becomes a stand-in for similarity in meaning.
Before vector embeddings, a common way to represent a word as numbers was one-hot encoding: give every word in your vocabulary its own dedicated slot, then mark that word's slot with a 1 and every other slot with a 0. For a 100,000-word vocabulary, that means each word becomes a 100,000-dimension vector that's almost entirely zeros. Because every word gets its own isolated slot, every word sits equally far from every other word. There's no sense that "cat" is any closer to "dog" than it is to "car." A vector embedding fixes that: it compresses the same word into a few hundred or a few thousand real-valued numbers, and the geometry of those numbers actually encodes the relationships between words. OpenAI's text-embedding-3-large, for instance, produces 3,072 dimensions by default.
That relationship-encoding geometry is exactly what makes vector embeddings look like magic in practice. They can match "I forgot my password" with "how do I reset my login" even though the two share no words. They aren't magic, though, and they aren't human-readable either. They're just numerical fingerprints learned from statistical patterns in training data, and they're only as good as the model that produced them.
Redis Iris serves agent context in milliseconds
Redis Iris connects memory, live data, and retrieval in one place.How are vector embeddings created?
Those fingerprints come from neural networks trained to place similar things close together. The idea traces back to Word2Vec in 2013, which learned word representations by predicting surrounding context words. Words that appear in similar contexts end up with similar weights, and those weights become the vector embedding. That's the distributional hypothesis in action: words used in similar contexts tend to have similar meanings.
Modern vector embedding models follow a pipeline that builds on the same principle. Your text gets tokenized, a transformer, such as Bidirectional Encoder Representations from Transformers (BERT), processes the tokens into hidden state vectors, and a pooling step collapses those token-level vectors into a single vector embedding for the whole input. Many pipelines also normalize the final vector so that similarity math is simpler downstream.
Later models specialized this same approach for specific comparison tasks. Sentence-BERT, introduced in 2019, is a variant of BERT trained to produce sentence-level vectors that can be compared directly with cosine similarity, and it made large-scale sentence similarity search practical: in its benchmark, it cut the time to find the most similar sentence pair from 65 hours with BERT directly to about 5 seconds. Contrastive Language–Image Pre-training (CLIP) takes that specialization further, training an image encoder and a text encoder jointly so both produce vectors in a shared multimodal space, which is what makes searching images with text queries possible.
One practical consequence follows from all this: the model defines the space. Vectors from two different vector embedding models usually aren't directly comparable, even at the same dimensionality, unless the models are designed or aligned to share a vector space. Swapping models generally means re-generating vector embeddings for your entire corpus. Teams that skip this step often see retrieval quality degrade quietly rather than fail loudly.
How does similarity search work?
Once your data lives in vector space, finding relevant items becomes a geometry problem: given a query vector, which stored vectors are closest? Answering that requires two decisions, a distance metric and a search strategy.
For metrics, cosine similarity measures the angle between two vectors and ignores magnitude, which makes it a common default for text vector embeddings. Dot product factors in vector length and is appropriate when magnitude carries meaning or when the model was trained for dot-product similarity. Euclidean distance measures straight-line distance and tends to suit spatial or count-based data more than text. When vectors are normalized to unit length, these metrics often produce the same nearest-neighbor ranking.
The search strategy is where scale enters the picture. Exact k-nearest neighbor search compares the query against every stored vector, which guarantees the true nearest neighbors but scales linearly with the dataset. That can be fine for tens of thousands of vectors, depending on latency targets and hardware, but it often gets painful at tens of millions.
Approximate nearest neighbor (ANN) algorithms trade a small amount of accuracy for large speed gains by building an index ahead of time. One of the most widely used is Hierarchical Navigable Small World (HNSW), which constructs a multi-layer graph where upper layers provide coarse shortcuts and lower layers refine the search. Queries start at the top and navigate downward toward the neighborhood of the answer. The trade-off: HNSW stores graph links alongside the vectors, which increases memory use in exchange for fast, high-recall approximate search. Results are approximate rather than guaranteed, and recall depends on the dataset and how the index is tuned.
Search meaning, not just keywords
Use Redis vector search to deliver smarter results instantly.Where do vector embeddings show up in real apps?
That recall-versus-speed machinery isn't academic. It's running behind products you probably used today. Here's where vector embeddings most often appear in production:
- Semantic search. Users describe what they want in natural language instead of guessing keywords. Spotify built natural language search for podcast episodes so a query like "cozy true crime" returns relevant shows.
- Recommendations. Similar items get grouped by behavior patterns, not just tags. Airbnb trained 32-dimensional vector embeddings on more than 800 million search-click sessions and reported a 21% increase in Similar Listing carousel click-through rate in an A/B test.
- Retrieval-augmented generation. LLMs answer questions using your own data instead of just their training data. The app embeds each document chunk, retrieves the closest matches at query time, and passes them as context, an approach shown to generate more factual responses than fine-tuned baselines alone.
- Semantic caching. Repeated questions return cached answers without calling the LLM again. One query log analysis found roughly 33% of queries submitted to web search engines were repeated, so the savings potential is real.
- Agent memory. AI agents recall past interactions by meaning, not exact wording. Stanford's Generative Agents framework scores stored memories on recency, importance, and relevance, where relevance is the cosine similarity between a memory and the current query.
Redis Iris, Redis' context engine for AI agents, brings semantic caching together with vector search, agent memory, and real-time data sync on top of the sub-millisecond access that many caching, session, and core data-access workloads already run on. Its semantic caching component, Redis LangCache, reported up to 73% lower LLM inference costs in high-repetition workloads and up to 15x faster responses for cache hits.
Agent memory runs on that same foundation, and the demand for it keeps growing. 84% of developers now use or plan to use AI tools in their development process. As AI features become more common, the infrastructure behind them matters more.
What does it take to store & query vector embeddings at scale?
Every use case above eventually hits the same infrastructure questions. The first is memory. Vector embeddings are dense by design, so storing them at scale adds up fast: a typical 1,536-dimension vector in float32 format takes about 6 KB, and a corpus of 100 million vectors runs into hundreds of gigabytes before the index itself adds more on top. Compression techniques like int8 quantization can shrink that footprint substantially. Redis reported up to 75% memory savings with int8 quantization in its tested workloads.
Index choice is the second lever, since different index types trade memory, speed, and accuracy differently. Redis supports several vector index types: FLAT for exact search on smaller datasets, HNSW for most general-purpose workloads, and Scalable Vector Search (SVS-VAMANA) for larger-scale workloads, which pairs the Vamana graph algorithm with compression to cut memory further.
Latency is the second question, because retrieval often sits directly on the request path of an LLM call, so slower search adds directly to the user's wait. That's why benchmarks at scale matter. In a billion-vector benchmark, Redis reported 90% precision with median latency around 200 ms when retrieving the top 100 nearest neighbors under 50 concurrent queries.
Beyond raw speed, production systems typically need more than pure similarity search. Filtered vector search combines vector similarity with metadata filters like category tags or timestamps, so a query can ask for "documents similar to this one, published in the last 30 days." Hybrid search goes further by blending keyword retrieval with vector similarity for cases where exact terms still matter. Data freshness is another consideration: new data should be insertable without rebuilding the index, and swapping vector embedding models usually means re-embedding the historical corpus.
Put these requirements together and a pattern emerges: many teams end up managing three separate systems, a vector database, a cache, and an operational store, each with its own failure modes and bills. Redis Iris brings vector search, semantic caching, and agent memory together in one context engine built on Redis' memory-first architecture, and a managed Redis Cloud deployment can reduce the operational burden of maintaining separate systems.
Fresh context, every call
Redis Iris keeps agent data current so answers stay accurate.Why retrieval speed decides whether vector embeddings pay off
After the storage, indexing, and freshness questions, the takeaway is simple: retrieval speed heavily shapes whether vector embeddings pay off. The rest of the stack determines whether that semantic signal becomes a fast product experience or another slow dependency. Vector embeddings make semantic retrieval possible, but production value depends on the retrieval layer, along with model choice, chunking, freshness, and evaluation. If similarity search is slow, your RAG pipeline lags, your semantic cache loses some of its latency and cost benefits, and your agents feel sluggish.
Redis Iris keeps vector search, semantic caching, and agent memory close to the caching and session data your app already depends on, so you can add features powered by vector embeddings without adding another database layer to your stack. If you're moving from embedding theory to a working app, try Redis Iris free to test vector search against your own workload, or talk to our team about what your AI infrastructure needs for production workloads.
Get started with Redis today
Speak to a Redis expert and learn more about enterprise-grade Redis today.