如何在Redis中为复杂数据构建向量相似度搜索的数据结构？

问题1：单个Redisearch VSS查询能否传入多个哈希集？ #

• 可行性：Redisearch的索引绑定到特定Key模式（创建索引时通过PREFIX指定）。如果多个哈希集的Key符合索引的前缀规则（比如统一以vec:开头），索引会自动包含这些哈希Key，查询时无需额外“传入”，直接查索引就能覆盖所有符合前缀的哈希向量。但如果多个哈希集属于不同索引（前缀不同），Redisearch本身不支持单次查询跨多个索引，只能在客户端分别查询后合并结果。
• 最优性：这种思路不是最优解。跨索引查询需要客户端处理结果合并，会增加延迟和复杂度；且多个索引的维护成本更高（比如同步更新配置）。

问题2：能否为Redisearch哈希集查询添加子上下文筛选条件？ #

• 可行性：完全可行，这是Redisearch的原生能力。具体实现方式：
  1. 数据存储设计：每个向量嵌入作为独立的哈希Key，示例结构：

     HSET vec:ctx1:sc1:001 context_id "ctx1" subcontext_id "sc1" embedding "[0.1,0.2,...]"
     HSET vec:ctx1:sc2:001 context_id "ctx1" subcontext_id "sc2" embedding "[0.3,0.4,...]"
     

     其中context_id和subcontext_id作为筛选字段，embedding作为向量字段。
  2. 创建带筛选字段的索引：

     FT.CREATE vec_idx ON HASH PREFIX 1 vec: SCHEMA
       context_id TAG
       subcontext_id TAG
       embedding VECTOR FLAT 6 DIM 1536 DISTANCE_METRIC COSINE
     

     用TAG类型存储上下文ID，适合离散值快速筛选；向量字段根据实际嵌入维度调整DIM参数。
  3. 带筛选条件的向量查询：
     • 包含指定子上下文：查询ctx1下的sc1和sc2子上下文，返回Top10相似向量

       FT.SEARCH vec_idx "*=>[KNN 10 @embedding $query_vec]" FILTER "@context_id:{ctx1} @subcontext_id:{sc1 | sc2}" PARAMS 2 query_vec "[0.5,0.6,...]"
       

     • 排除指定子上下文：查询ctx1下除sc3外的所有子上下文

       FT.SEARCH vec_idx "*=>[KNN 10 @embedding $query_vec]" FILTER "@context_id:{ctx1} -@subcontext_id:{sc3}" PARAMS 2 query_vec "[0.5,0.6,...]"
       

• 最优性：这是当前场景的最优解。利用Redisearch原生的筛选+向量查询能力，无需客户端额外处理，性能更高；单索引维护更简单，且能灵活支持包含/排除任意子上下文的查询需求。

总结 #

优先选择第二种思路：将所有向量存入统一前缀的哈希Key，为上下文ID、子上下文ID创建TAG类型的索引字段，通过Redisearch的FILTER语法结合向量KNN查询实现需求。这种方案既能满足指定上下文内的查询，又能灵活筛选子上下文，且性能和可维护性最优。

内容的提问来源于stack exchange，提问作者SteroidMan