向量数据库先做元数据过滤再向量召回的实现方法

当一个知识库同时服务多个租户时，最容易出错的做法是先按向量相似度取一批结果，再在应用层删除不属于当前租户的文档。这样既浪费召回名额，也可能因为候选太少而返回空结果。更稳妥的方式是把 tenant_id、doc_type 等硬约束写入 payload，在向量查询中用 Filter 表达，让数据库在召回范围内处理过滤。

官方地址：https://qdrant.tech/

先把不可违背的条件放进 payload

向量只能表达文本或多模态内容的相似性，不能可靠表达“只能看当前租户”“只要已发布文档”这类业务边界。Qdrant 的 point 可以同时保存向量和 payload，例如把租户、文档类型、发布状态拆成稳定字段。字段值要统一类型：tenant_id、doc_type适合关键词匹配，publish_year适合范围条件。

这里的原则是先建模，再写查询。字段名不要把动态属性直接铺成大量 payload key；如果过滤字段来自开放式属性，应整理为固定字段或受控结构，否则索引数量和维护成本会迅速增长。

在写入前为过滤字段建立 payload index

Qdrant 官方文档把 payload index 定义为面向字段和类型的索引，并用它帮助快速定位过滤点和估计过滤基数。以 Python 客户端为例，可以先为租户和文档类型创建关键词索引：

from qdrant_client import QdrantClient, models

# 连接示例只表达调用关系，生产环境应从配置注入地址和凭据
client = QdrantClient(url="http://localhost:6333")

# 先建立租户索引，让硬边界可以参与过滤规划
client.create_payload_index(
    collection_name="knowledge_base",
    field_name="tenant_id",
    field_schema=models.PayloadSchemaType.KEYWORD,
)

# 文档类型也是稳定的低基数字段，使用同类索引
client.create_payload_index(
    collection_name="knowledge_base",
    field_name="doc_type",
    field_schema=models.PayloadSchemaType.KEYWORD,
)

索引会占用内存和磁盘，所以只为真实过滤字段创建。若集合已经写入大量数据，再补索引还要考虑已有段和 HNSW 过滤边的重建成本；新集合通常在导入前完成索引规划更省事。

把过滤条件直接绑定到向量召回

查询时用 must 表示同时满足多个条件。下面的代码把租户和发布状态绑定在一次向量查询中，返回的候选天然属于允许范围：

from qdrant_client import models

# query_vector 是上游模型生成的查询向量，此处只展示过滤与召回的边界
hits = client.query_points(
    collection_name="knowledge_base",
    query=query_vector,
    query_filter=models.Filter(
        must=[
            models.FieldCondition(
                key="tenant_id",
                match=models.MatchValue(value="tenant-acme"),
            ),
            models.FieldCondition(
                key="status",
                match=models.MatchValue(value="published"),
            ),
        ]
    ),
    limit=8,  # limit 只约束过滤边界内的召回数量
)

# 业务层只消费命中点；异常处理应记录请求上下文但不要泄露租户数据
for point in hits.points:
    print(point.id, point.score, point.payload)

should 适合“文档类型为 manual 或 faq”的并集，must_not 适合排除已归档内容。不要把同一组硬条件先转成向量文本再依赖相似度判断，那会把确定性约束变成概率结果。

用检查表判断过滤是否真的在召回边界内

过滤选择性也要纳入容量判断。条件很宽时，向量索引仍是主要入口；条件很窄时，payload index 能快速缩小范围；中间选择性则要观察召回质量、索引内存和查询延迟。不要用一次压测结果推断所有租户，至少按大租户、小租户和多条件组合分别检查。

常见问题

过滤字段没有索引还能返回结果吗？

通常仍可能返回结果，但查询可能变慢并消耗更多资源。生产环境应把高频过滤字段纳入索引清单，并考虑启用未索引过滤的严格限制，让配置错误尽早暴露。

过滤应该写在应用层还是向量数据库里？

租户、状态、类型等确定性条件应尽量写进向量查询；应用层可以做权限补充和最终展示裁剪，但不应承担主要候选筛选。

payload index 建得越多越好吗？

不是。每个索引都有存储和维护成本，优先覆盖真正参与过滤、且能明显缩小候选范围的字段，再用实际查询组合验证收益。