多阶段检索：一次 API 调用，融合稠密+稀疏+过滤

真实业务里，搜索从不是“找相似”这么简单。一份上千页的年报，里面全是强结构信息：品牌、季度、章节、财务指标。只靠向量召回，经常把对的答案放在错的上下文里。好的解法是多阶段查询：一次 API 调用完成语义检索、关键词匹配、结构过滤三件事。

过滤是硬约束，不是软偏好

假设场景：从美妆集团 H 的年报中，找品牌 B 在 FY25 报告期“风险因素”章节里，关于“活性成分供应链风险”的内容。系统会应用类似 SQL WHERE 的规则：

brand_name = '品牌B'
fiscal_year = 'FY25'
document_section = '风险因素'

这些规则是一票否决项。来自品牌 A 的段落，即使余弦相似度高达 0.99，只要品牌不符，直接丢弃。

过去团队常用 Postgres 管结构数据，向量索引管 embedding，然后在内存里做合并胶水代码。能跑，但慢、脆弱、难同步。如果向量数据库原生支持过滤，架构会简洁得多。

选哪个向量数据库？

过去两年，每家厂商都在喊混合检索。真正决定体验的，是检索时过滤到底发生在哪个环节。对比主流引擎：

Pinecone：上手快，但云托管、闭源，过滤经常在 ANN 召回之后才执行，高选择性过滤会导致结果稀疏甚至为空。
Weaviate：内置 schema 和 BM25，但 schema 先行不够灵活，GraphQL 有学习曲线。
Milvus：面向十亿级向量，运维复杂，对文档场景是过度设计。
pgvector：Postgres 扩展很简洁，但原生不支持稀疏向量，大向量集性能受限。
Chroma：适合原型验证，生产级过滤和持久化仍在成熟中。
Elasticsearch：BM25 和过滤很强，但稠密向量是后加的，操作起来有点“油改电”的感觉。

为什么选 Qdrant

在这个负载下，Qdrant 有三个关键优势：

过滤和图遍历同步进行。payload 索引与 HNSW 图一起构建，过滤不会拖累召回率。
支持无 schema 的 JSON payload。随时加新字段，不用迁移。
Rust 编写，内存占用低，延迟稳定。

摄入：分块、打标签、Upsert

PDF 解析成 text chunk，用规则和 LLM 对每个 chunk 打上品牌、章节、财年标签，然后统一 embedding，连同 payload 写入 Qdrant。payload 与向量同库同索引，一次写入，后续查询直接从库里过滤。

查询：一个 API 调用全搞定

用户输入“品牌B在FY25风险因素章节中，供应链风险里的活性成分有哪些？”

from qdrant_client.models import Filter, FieldCondition, MatchValue

results = client.search(
    collection_name='enterprise_docs',
    query_vector=query_vector,
    query_filter=Filter(must=[
        FieldCondition(key='entity_name', match=MatchValue(value='品牌B')),
        FieldCondition(key='document_section', match=MatchValue(value='风险因素')),
        FieldCondition(key='fiscal_year', match=MatchValue(value='FY25')),
    ]),
    limit=5,
)

Qdrant 在遍历向量图时同步应用过滤。不符合品牌、章节、财年约束的 chunk，在打分前就被移除。一个来自品牌 A 的高相似度段落，永远不会进入候选集。这就是“演示级 AI”和“业务级 AI”的分水岭。