Redis 向量检索 KNN 查询如何限制候选集：FT.SEARCH、HYBRID_POLICY 与排序边界

线上知识库接入向量检索后，最容易出现的一类问题是“明明有相似内容，过滤后却只返回几条”。这通常不是向量模型突然失效，而是 Redis 的过滤表达式、KNN 候选数和混合策略没有按同一条查询路径理解。使用 FT.SEARCH 时，先让过滤条件限定候选集，再用 DIALECT 2 执行 KNN；需要显式控制过滤策略时，再选择 ADHOC_BF 或 BATCHES。

实用判断是：结果要“严格符合过滤条件”，优先确认预过滤语义和排序字段；结果要“在大量候选中保持吞吐”，再比较 ADHOC_BF 与 BATCHES，不要只盯着 KNN 的数字。

先把过滤范围和 KNN 排序拆开看

Redis 向量查询的表达式可以拆成两段：过滤表达式决定“哪些文档有资格参与”，KNN 决定“资格范围内哪些向量更接近”。下面用电影文档举例，字段名来自 Redis 官方向量检索示例：

FT.SEARCH movies
  "(@category:{drama | action})=>[KNN 10 @doc_embedding $BLOB AS movie_distance]"
  PARAMS 2 BLOB "..."
  SORTBY movie_distance
  DIALECT 2

这条查询的控制流是 过滤表达式 → KNN 10 → movie_distance。AS movie_distance 把距离暴露成排序字段；距离越小通常代表越接近，所以不要把它当成“相似度越大越好”直接降序排列。业务接入时，建议先用固定的 10 条结果检查排序，再决定是否扩大 K。

为什么过滤后结果会少：KNN 数字不是结果保证

KNN 10 表示在符合查询路径的候选中寻找近邻，不等于数据库一定能返回 10 个业务上可用的文档。如果 @category:{action} 只匹配 4 个文档，结果自然不会凭空补齐。反过来，如果过滤范围很宽，扩大 K 也可能增加计算和返回处理成本，却没有改善相关性。

用三个检查点确认查询是否按预期运行

• 先单独验证 @category:{action} 的命中量，再验证带 KNN 的同一表达式。
• 保留 AS movie_distance，检查返回值是否按距离升序排列。
• 确认查询使用 DIALECT 2，不要把旧语法下的结果和混合查询结果直接比较。

ADHOC_BF 和 BATCHES 怎么选

过滤条件和向量字段同时参与查询时，Redis 需要决定怎样把过滤与向量检索拼接起来。HYBRID_POLICY ADHOC_BF 表示按需处理过滤；HYBRID_POLICY BATCHES 则按批次处理候选，通常还要配合 BATCH_SIZE。它们是候选处理策略，不是新的向量距离算法。

FT.SEARCH movies
  "(@category:{action})=>[KNN 10 @doc_embedding $BLOB HYBRID_POLICY ADHOC_BF]"
  PARAMS 2 BLOB "..."
  SORTBY __vec_score
  DIALECT 2

FT.SEARCH movies
  "(@category:{action})=>[KNN 10 @doc_embedding $BLOB HYBRID_POLICY BATCHES BATCH_SIZE $BATCH_SIZE]"
  PARAMS 4 BLOB "..." BATCH_SIZE 50
  SORTBY __vec_score
  DIALECT 2

小范围、需要尽快得到严格过滤结果时，可以先从 ADHOC_BF 开始；候选很多、希望控制每批处理规模时，再用 BATCHES 做压测。不要仅凭一次本地请求决定策略，至少记录过滤命中量、返回数量和查询延迟。

兼容处理：先保留可退回的最小查询

线上升级时，建议先保留一条只使用过滤表达式、向量字段和 KNN 的最小查询，把排序字段和 DIALECT 2 明确写在请求中。确认索引字段、向量维度和客户端参数没有问题后，再加入 HYBRID_POLICY。如果客户端封装层不接受新参数，先绕过封装用原生命令核对，再决定是否升级客户端，而不是把参数静默丢弃。

不要把 FT.HYBRID 和 FT.SEARCH 混为一谈

Redis 官方文档将 FT.HYBRID 描述为统一的文本与向量混合查询接口，并标注 Redis Open Source 8.4.0 可用。本文的核心示例仍是 FT.SEARCH，因为它足以解释过滤、KNN 和混合策略的边界。只有确认部署版本和模块能力后，才考虑迁移到 FT.HYBRID。

常见问题：结果、排序和策略边界

KNN 10 为什么只返回 4 条？

先看过滤表达式的命中量。KNN 的 10 是近邻数量目标，不会制造不满足过滤条件的文档；过滤范围只有 4 条时，返回 4 条是正常结果。

movie_distance 应该升序还是降序？

Redis 向量距离通常是越小越接近，因此使用距离别名排序时优先按升序核对。若业务层转换成相似度分数，必须先确认转换公式再谈降序。

什么时候需要 BATCH_SIZE？

当采用 BATCHES 并需要控制每批候选规模时设置它；具体值应结合过滤命中量、延迟和返回质量压测，不要照搬示例数字。

是否必须马上改用 FT.HYBRID？

不必。已有 FT.SEARCH 查询可以先把过滤和 KNN 边界验证清楚；只有部署能力、文本融合需求和客户端支持都满足时，再评估 FT.HYBRID。

发布前的查询检查清单

1. 过滤字段、向量字段和参数名与索引定义一致。
2. 保留 DIALECT 2，并用距离别名核对排序方向。
3. 记录过滤命中量、返回数量和延迟，再比较 ADHOC_BF 与 BATCHES。
4. 升级 Redis 或客户端前，先用最小 FT.SEARCH 请求保留可回退基线。