Qdrant 加筛选就变慢：检查 payload 索引与字段类型

把语义查找与属性过滤分开观察 “寻找相似内容”和“只在某类文档中查找”是两个维度。官方索引指南说明，向量索引加速相似检索，payload 索引加速属性过滤，并帮助估计符合条件的数据规模。若不加筛选很快、加筛选变慢，应先检查字段索引，而不是立即更换 embedding 模型。 按实际条件选择字段类型 精确标签、整数范围、时间区间和全文匹配需要不同索引语义。先列出应用实际生成的筛选表达式，再核对字段值在数据中到底是字符串、数字还是时间。名称叫 date 的字符串并不自动具有时间索引的行为，测试数据应保留真实类型。 先用三个字段验证类型 以自拟知识库为例，doc_type 用 manual、faq 等标签进行精确筛选，可考察 keyword；page_no 是数字页码并需要范围筛选，应按实际数值类型建立对应索引；正文中的词句查找则属于 text 的全文匹配。给一个字段建了索引，不代表所有比较方式都获得同样支持。 准备同一份记录的类型对照：page_no 为数字 12，与字符串 "12"。应用若发出数字范围条件，应先确保真实数据与索引的类型约定一致，而不是在查询慢或漏结果时增加返回数量。字段名相同也可能因不同来源导入而出现混合类型，检查时要覆盖这些来源。 再为 doc_type=manual 和一个确定不存在的标签各发一次相同查询。前者的每条结果都应符合标签，后者应为空；若仍返回其他类型，先检查请求是否带上筛选以及字段路径是否正确。只有结果范围正确，比较耗时才有意义。 不要为所有属性无差别建索引 索引消耗额外内存、磁盘与构建资源。官方建议优先针对实际用于筛选的字段；资源有限时，考虑哪些条件最能缩小搜索范围。编辑建议将查询频率与选择范围一起记录，先解决常用瓶颈，再决定是否覆盖低频字段。 创建时机为什么有影响 官方要求尽量在导入前建立 payload 索引，因为过滤感知的 HNSW 需要在构建时利用这些信息。已有数据之后再添加 payload 索引，为获得相应图结构收益可能需要重建 HNSW。这里应区分“字段索引存在”与“向量图已按新过滤信息构建”，不能只检查一次创建成功响应。 严格模式能暴露缺失配置 Qdrant 提供拒绝未索引字段检索的严格模式设置。它能让误用字段直接表现为错误，而不是悄悄拖慢查询。正式开启前，应收集应用当前可能产生的过滤条件并完成配置，否则原本可用的请求可能转为失败。 用相同问题比较筛选结果 选择一组固定查询，分别测试不带条件、宽松条件与较严格条件。除了耗时，还应核对结果确实满足字段范围，避免只关注速度而漏掉数据类型或表达式错误。记录返回数量与系统资源，可以帮助判断改变是否符合预期。 完成后的维护 应用新增筛选维度时，把索引与查询一起评审，并在真实数据规模下复测。更多索引不一定更合适，字段选择应由查询需要和资源约束共同决定。

本篇涉及的工具1

Qdrant

支持向量检索中的属性筛选

适合场景

已有向量检索，需要按类型、时间或其他属性筛选资料的开发者。

需要留意

字段类型、索引成本与 HNSW 构建时机需要一起核对。

了解项目 访问官网