Redis FT.PROFILE 拆分向量查询的延迟来源

Redis 向量查询变慢时，先别只盯着总耗时。我的排查习惯是用 FT.PROFILE 把一次查询拆成迭代器和结果处理器两层：先确认 VECTOR 迭代器采用了哪种搜索模式，再看读取次数、候选规模以及 Metrics Applier、Sorter、Loader 各自处理了多少结果。这样才能判断延迟来自过滤后的候选过多、距离计算，还是返回内容太重。

先看 FT.PROFILE 的查询结构

FT.PROFILE 的基本形式是 FT.PROFILE index SEARCH QUERY query，也支持 HYBRID 和 AGGREGATE。它返回两部分：第一部分是原查询的结果，第二部分包含查询创建、迭代器和结果处理器的 profile 信息。向量 KNN 查询仍然要写在 FT.SEARCH 的查询表达式里，过滤条件位于 => 左侧，KNN 子句位于右侧。

# 用固定的 K 和返回范围建立可比较的向量查询基线
FT.PROFILE vss_idx SEARCH QUERY "(*)=>[KNN 10 @embedding $query_vec AS vector_score] SORTBY vector_score DIALECT 2 PARAMS 2 query_vec "" LIMIT 0 10

这里的 $query_vec 通过 PARAMS 传入二进制向量；示例中的 LIMIT 0 10 只是让返回规模稳定，并不代表 Redis 已经只计算了十个候选。要解释候选遍历范围，还得读 profile 里的迭代器字段。

从 VECTOR 迭代器判断延迟来源

向量 profile 会补充 Vector search mode。没有过滤条件的纯 KNN 通常对应 STANDARD_KNN；带过滤条件时，可能看到 HYBRID_ADHOC_BF、HYBRID_BATCHES，或者在批量候选不足时切换到 HYBRID_BATCHES_TO_ADHOC_BF。这些名称描述的是执行策略，不等于某个固定的性能结论。

接着对比迭代器的 Time、Number of reading operations 和 Estimated number of matches。读取次数远高于其他迭代器，通常值得优先排查过滤选择性和候选补充；但它仍是定位线索，不应脱离数据规模、索引类型和负载直接下结论。

# 只看 profile 结构，减少结果内容造成的噪声
FT.PROFILE vss_idx SEARCH LIMITED QUERY "(@tenant:{acme} @kind:{doc})=>[KNN 10 @embedding $query_vec AS vector_score] DIALECT 2 PARAMS 2 query_vec "" NOCONTENT LIMIT 0 0

LIMITED 会省略部分 reader iterator 的细节，适合先看主要结构；如果正在分析某个复杂过滤器的内部 reader，则应保留完整 profile。NOCONTENT 和 LIMIT 0 0 只减少返回内容或结果条目，不会把查询改成另一个业务语义。

把延迟拆成迭代器与结果处理器

如果 VECTOR 迭代器时间和读取次数都高，先检查过滤条件是否让大量候选无法满足；如果迭代器不突出，却是 Loader 或排序处理器处理的结果很多，优先减少返回字段、结果数量或排序工作。Metrics Applier 负责应用距离或相似度相关指标，不能把它的存在误认为额外的一次数据库查询。

复测时保留哪些边界

每次只改一个变量：先固定索引、向量维度、K、过滤条件和查询参数，再分别对比完整输出与 NOCONTENT、完整 profile 与 LIMITED。如果过滤条件会改变结果集，不能把两次 profile 的绝对时间直接当作同一基线。

还要注意版本差异：官方文档说明 profile 输出会随 RediSearch/Redis 版本和 RESP 协议表现不同。生产排查时应把 Redis 版本、索引定义、查询文本和 profile 摘要一起记录；不要只保存一个“总耗时更高”的结论。

常见问题

FT.PROFILE 会改变原查询结果吗？

它执行指定的搜索、混合搜索或聚合查询并额外收集 profile 信息，返回中第一部分仍是原查询结果。比较时仍需保持查询参数和返回选项一致。

为什么 LIMIT 10 了，读取次数还可能很高？

LIMIT 控制返回窗口，不等于过滤后的向量候选只检查十条。混合向量查询可能需要读取更多候选才能得到满足过滤条件的结果，具体要看迭代器 profile。

LIMITED 适合所有排查吗？

不适合。它适合先看主要迭代器和处理器结构；如果问题正好出在复杂 reader iterator 内部，就应该保留完整 profile，再用 NOCONTENT 控制结果体积。