8.2 Redis Vector Indexing for Similarity Search

Beyond string GET/SET caches, Azure Managed Redis can host vector indexes so your AI solution performs similarity search in memory. On the AI-200 exam, “implement vector indexing to enable similarity search” means you can define a VECTOR field, load embeddings, and query nearest neighbors for retrieval-augmented generation (RAG), semantic caching, and clustering-style lookups—using Redis Query Engine / RediSearch-style capabilities available with Azure Managed Redis.

What a Redis vector index is

A vector index is a secondary index over hash (or JSON) documents that include a numeric vector attribute—typically a float embedding from Azure OpenAI or another embedding model. Each document also carries metadata: chunk text ID, source URI, language, access group, or prompt-cache payload pointer. Similarity search finds the K nearest vectors to a query embedding under a chosen distance metric.

Redis keeps both the vectors and the index structures in memory, which is why Managed Redis is attractive for hot retrieval sets, session-scoped corpora, and semantic caches that must answer in milliseconds. Cold or massive corpora may still live in Azure AI Search; Redis often holds a hot shard, a per-tenant slice, or a cache of recent embeddings.

RediSearch-style VECTOR fields

Conceptually you:

1. Choose a key prefix for documents in the index (for example emb:).
2. Create an index with FT.CREATE (or the equivalent SDK) that declares fields, including a VECTOR field.
3. Write hashes such as emb:chunk-17 with the vector bytes/floats plus TEXT/TAG/NUMERIC attributes.
4. Query with a KNN clause against a query vector.

A VECTOR field declaration specifies:

FLAT stores vectors for brute-force comparison—best recall, higher latency as N grows. HNSW (Hierarchical Navigable Small World) builds a graph for approximate nearest neighbor search—better latency at scale with recall that depends on construction and search parameters (for example M, EF_CONSTRUCTION, EF_RUNTIME in Redis vector options).

For exam scenarios: small hot sets and strict correctness lean FLAT; larger semantic caches and chunk stores lean HNSW.

Loading embeddings into the index

Pipeline for RAG chunk indexing:

1. Split source documents into chunks.
2. Call an embedding model; receive a DIM-length vector.
3. HSET emb:{chunkId} with fields such as content (or a pointer), source, updated, and vector.
4. Ensure the key prefix matches the index definition so the vector is indexed automatically.
5. Optionally EXPIRE ephemeral embeddings (for example user-upload session corpora); keep durable knowledge with long TTL or no expire plus explicit invalidation.

Because the index is tied to document fields, updating a chunk means overwriting the hash (new vector + metadata). Deleting a chunk (DEL) removes it from search. When source content changes, re-embed and HSET—do not leave an old vector searchable under a new document version without updating the key or version attribute.

Metadata filters with vectors

Real AI apps rarely search the entire keyspace. RediSearch-style queries combine a filter (@source:{policies}, @tenant:{id}, @lang:{en}) with a KNN vector clause. That pattern supports multi-tenant RAG and keeps semantic cache lookups inside one product line. Always declare TAG/TEXT/NUMERIC fields you will filter on at index creation time.

Running similarity search (KNN)

A typical query:

1. Embed the user question (same model and DIM as indexed vectors).
2. Issue a search: find top K documents by VECTOR distance, optionally with a pre-filter.
3. Read returned IDs and scores; fetch chunk text from the hash or from blob/SQL if only IDs are stored.
4. Pass the top chunks into the LLM prompt as grounding context.

Similarity search is not only for RAG. The same index powers:

• Semantic response cache — nearest prior prompt embedding above threshold → reuse completion
• Duplicate detection — near-identical support tickets or knowledge articles
• Routing — classify intent by nearest labeled exemplar vectors

Designing indexes for AI-200 scenarios

RAG hot cache

Index chunk embeddings for the active corpus subset. On a user query, KNN retrieve chunk IDs, then hydrate text. Pair with section 8.1 cache-aside for the final prompt package when useful. Invalidate or re-embed when SharePoint/Blob/SQL sources change.

Semantic LLM cache

Each cache entry is a hash: prompt embedding VECTOR + response string + model name TAG + created NUMERIC. Query with the new prompt’s embedding; if the best distance beats a threshold and model/tags match, return the cached response. Use short TTLs and delete entries when grounding policies change.

Hybrid with Azure AI Search

Azure Managed Redis vector search complements—not always replaces—Azure AI Search. A common architecture: AI Search for large-scale hybrid BM25+vector retrieval; Managed Redis for session memory, semantic cache, and ultra-hot entity embeddings. The exam cares that you know Redis can implement vector similarity, not that every corpus must live only in Redis.

Operational concerns tied to vectors

Memory — FLOAT32 vectors of DIM 1536 use about 6 KB per vector raw, plus HNSW graph overhead and metadata. Size the Managed Redis tier for peak document count × per-vector bytes × safety factor.

Consistency with caches — A vector hit that returns chunk ID chunk-17 is wrong if chunk-17 text in another Redis string or in Blob was updated without re-embedding. Treat embedding refresh as part of invalidation.

Security — Filter by tenant attributes in the query; do not rely on “obscure key names.” Combine Azure RBAC/network isolation for the cache with application-level filters on TAG fields.

Evaluation — Measure recall@K against a labeled set, latency under concurrency, and semantic-cache precision (how often reused answers are acceptable). Raise thresholds or K based on those metrics rather than guessing.

End-to-end flow to memorize

1. Embed documents → HSET under index prefix with VECTOR + metadata.
2. FT.CREATE (or SDK) with DIM, metric, FLAT/HNSW.
3. Embed query → KNN search → top-K IDs.
4. Ground the LLM or decide semantic-cache hit/miss.
5. On data change → re-embed/overwrite or DEL; align TTLs with section 8.1.

If you can map a scenario to those five steps—especially choosing VECTOR field parameters and explaining why similarity search belongs in Azure Managed Redis for that AI path—you have the implementation skill AI-200 targets in this objective.