真实 search 几乎总是「向量近邻 +
标量谓词」。db-frontier/09
已从算法侧拆开 pre-filter / post-filter / in-filter 与
ACORN。本文只回答:在 Milvus 段执行与 Knowhere
路径上,过滤结果如何变成 bitset,以及选择度如何打穿第 9 篇的
Top-\(k\)
归并假设。
本文是「向量检索引擎」系列第 11 篇(共 18 篇)。→ 系列目录
版本锚定:Milvus 2.6.x Bitset、Knowhere、Filter Templating、Data Processing。
一、形式化问题(与 frontier/09 对齐)
在满足谓词 \(\varphi\) 的子集上求近邻:
\[ \mathrm{Topk\_filter}(q,k,\varphi)=\arg\min_{\substack{x\in X\\ \varphi(x)=\mathrm{true}}}\mathrm{dist}(q,x) \]
选择度 \(s=|\{x:\varphi(x)\}|/|X|\) 跨多个数量级时,同一套索引参数可以从「很快」变成「召回崩或延迟崩」。
二、引擎落点:表达式 → bitset → 向量搜索
2.1 Bitset 的官方用途
Bitset 文档:bitset 用于 属性过滤、删除、以及与时间相关的查询视图。
- 过滤:满足条件的实体在过滤结果中标出(文档用
1表示满足过滤条件的中间表示,再与删除位图组合;最终「搜索阶段忽略」的实体在组合后以约定位表示——以文档示例为准)。 - 删除:段内某行已删则在删除 bitset 中标记,搜索/查询时不参与计算。
Knowhere 文档:软删 bitset 应用到暴露的索引查询 API(CPU/GPU)。Segcore 设计文档描述布尔表达式经 visitor 生成 bitmask,再交给向量执行(第 7 篇已引)。
因此混合检索的引擎骨架是:
标量表达式求值 → filter bitset
与删除 / 时间可见性 bitset 组合
→ Knowhere Search(..., bitset)
→ 段/shard/Proxy 归并
2.2 复杂表达式的解析成本
Filter Templating:超大 IN 列表、非
ASCII(如大量 CJK)字面量会显著增加 解析
开销。官方提供占位符 + filter_params
的模板化,用于 search / query / delete。这是引擎前的
字符串与 AST 成本,与 ANN
选择度正交——排障时先区分「解析慢」还是「过滤后候选不够」。
三、pre-filter / post-filter 在分段归并下的表现
frontier/09 的三种朴素策略在此只映射到引擎后果:
| 策略 | 引擎直觉 | 选择度陷阱 |
|---|---|---|
| Post-filter | 先 ANN 取较大 \(k'\),再套 bitset/表达式 | \(s\) 很小时局部 Top-\(k'\) 被滤空,全局归并凑不满 \(k\) |
| Pre-filter | 先得满足 \(\varphi\) 的行集,再在子集上搜或扫 | \(s\) 很大时子集仍巨大,暴力不可行 |
| In-filter / 图感知 | 检索游走时感知谓词(ACORN 等) | 实现与索引类型相关;不是所有 index_type
等价 |
Milvus 段路径上,Knowhere 带 bitset 的查询更接近「在索引遍历中跳过无效行」或「先得掩码再搜」的组合,具体随索引类型变化。不要假设「加了 filter 只是结果少一点、延迟不变」。
3.1 对第 9 篇归并假设的破坏
无过滤时,各段 Top-\(k\) 再合并可得正确全局 Top-\(k\)(在分区不交并、距离可比较前提下)。有过滤时:
- 某段局部 Top-\(k\) 可能 全部不满足 \(\varphi\);
- 必须放大局部候选或改策略,否则 Proxy 最终结果 条数不足或召回假高(返回的 \(k\) 条在满足 \(\varphi\) 的全集上并非真近邻)。
生产上应用自己的数据估 \(s\),对高选择性过滤单独做召回评测——本篇不伪造曲线。
四、与 ACORN 争论的衔接(不重写)
Patel et al., ACORN(SIGMOD 2024)等讨论 predicate-agnostic 索引与过滤感知检索的权衡——全文见 db-frontier/09。本系列引擎结论只取:
- 选择度是第一控制变量;
- 专用引擎必须把谓词结果推进到索引查询(bitset),而不是只在 Proxy 上后滤;
- 分区(Partition)可把部分等值过滤变成 少扫一些 segment,但不能替代任意布尔表达式。
五、工程间隙与开放问题
5.1 工程间隙
- Bitset 文档示例含 Time Travel 语义;产品默认路径以一致性级别 + 当前可见性为主(第 12 篇),阅读示例时注意历史 API 名。
- 标量倒排/bitmap 索引(Data Processing 提及)改变的是 生成 filter bitset 的成本,不是取消 ANN 侧选择度问题。
- 模板化降低解析成本,不提高低选择度下的召回。
5.2 开放问题
- 段级自适应:何时自动从 post 切到 pre 或扩大 \(k'\)?
- 多过滤器 AND/OR 下 bitset 物化顺序与 SIMD 友好布局?
- 与 llm-infra RAG 权限过滤叠加时,强制强过滤是否应默认 Strong 一致性?
六、小结
混合检索在引擎里是 表达式 → bitset(叠加删除/时间)→ Knowhere → 多级归并。选择度打穿朴素 Top-\(k\) 合并;算法策略争论外链 frontier/09。下一篇专门收束可见性:一致性模型。
参考资料
- Milvus Documentation v2.6.x, Bitset、Knowhere、Filter Templating。
- db-frontier/09(pre/post/in-filter、ACORN)。
- Patel et al., ACORN, SIGMOD 2024(经 frontier/09 引用)。
- 第 7、8、9 篇、系列 index。
返回 系列目录 | 上一篇:Data Node | 下一篇:一致性模型
同主题继续阅读
把当前热点继续串成多页阅读,而不是停在单篇消费。
【向量检索引擎】Knowhere:向量索引执行引擎与插件契约
按官方 Knowhere 文档说明其在 Milvus 中的位置、相对 Faiss 的扩展(bitset、SIMD 选择、二进制度量)、VecIndex 类层次与 IDMAP/IVF/HNSW 等类型,并与 db-frontier/08 的算法细节分工。
【向量检索引擎】Delete · Upsert · TTL:软删、覆盖写与过期回收
按官方文档说明 delete(主键/过滤)、upsert(override/merge)、collection TTL 的语义;结合 bitset 软删与 compaction 物理回收,划清「搜索不可见」与「对象存储已清理」的时间差。
【向量检索引擎】向量引擎全景:算法、RAG 与专用引擎之间的一层
定位专用向量检索引擎相对 ANN 算法、RAG 应用与湖仓格式的分工;以 Milvus 2.6.x 四层架构给出本系列 18 篇地图,并交代从 SIGMOD 2021 系统论文到存算分离演进的谱系。
【向量检索引擎】ANN 算法工程接口:从 HNSW/IVF 到 Knowhere 契约
把 HNSW、IVF、DiskANN、Flat 收成引擎侧的索引类型与参数面;说明 Train/Build/Search 生命周期如何贴着 Segment,并与 db-frontier/08 的算法细节、第 8 篇 Knowhere 实现分层分工。