2.3.2. Vector Indexing for Similarity Search

💡 First Principle: Redis can run the same nearest-neighbor geometry as Cosmos DB and pgvector, but entirely in memory — which makes it less a primary vector database and more a semantic reflex layer: answering "have I seen something like this before?" faster than any disk-backed store can.

Redis gains vector search through its search module (RediSearch, included in Azure Managed Redis). You declare an index over hashes or JSON documents with a VECTOR field specifying algorithm, dimensions, and metric:

FT.CREATE idx:prompts ON HASH PREFIX 1 prompt:
  SCHEMA text TEXT
         embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 1536 DISTANCE_METRIC COSINE

Both FLAT (exact) and HNSW (approximate) algorithms are available — the very same trade-off from 2.2.3, third appearance, same reasoning. KNN queries retrieve nearest neighbors:

FT.SEARCH idx:prompts "*=>[KNN 3 @embedding $vec AS score]" PARAMS 2 vec <bytes> DIALECT 2

The flagship AI pattern here is the semantic cache: before calling the model, embed the incoming prompt and search Redis for previously answered prompts within a similarity threshold. Close enough match → return the cached answer, skipping the model call entirely; miss → call the model, store prompt-embedding + answer with a TTL. This fuses 2.3.1's caching discipline with vector search: the "key" is no longer exact bytes but meaning, so "How do I reset my password?" and "password reset steps?" hit the same cache entry. For high-traffic assistants, semantic caching is often the single largest cost lever — every hit saves a full model invocation.

Placement follows from the first principle: Redis holds the hot vector subset (recent prompts, top FAQs) while PostgreSQL or Cosmos DB holds the durable corpus — short-term versus long-term memory, exactly as framed in 2.3. And per that section's misconception: vectors in Redis expire and evict like everything else, so they must be rebuildable from the durable store.

⚠️ Exam Trap: A semantic-cache threshold set too loose returns wrong answers confidently — similar-sounding but semantically different questions hit the same entry. If a scenario reports "users get answers to slightly different questions," tighten the similarity threshold; don't reach for a bigger cache.

Reflection Question: Why does a semantic cache need a similarity threshold at all, when a normal cache needs only key equality?