向量数据库做RAG时，为什么加了metadata过滤反而变慢了？

这问题我遇到过，Milvus的metadata过滤其实不是严格先过滤再算相似度，得看filter的字段有没有建索引，还有过滤条件的选择性。20万条数据量不大，但如果你按部门过滤后还剩十几万条，那跟全量检索差别就不大，延迟自然降不下来。建议你先看看过滤后实际命中的条数，再用排他性强的条件试试。另外ES加向量插件确实在复杂过滤上更灵活，但性能瓶颈也常见，关键还是得看你的过滤逻辑能不能把候选集压到几千以内。

我之前也遇到过类似情况，20万条数据量其实不算大，问题大概率出在过滤字段没建索引上，Milvus的标量过滤默认是暴力扫描的，给部门、时间这些字段加上倒排索引能好很多。另外你查一下过滤后的数据占比，如果过滤完还剩一大半数据，那确实还不如全量向量检索再在应用层过滤，成本反而低。至于换ES，如果你对向量检索性能要求没那么极致，倒是可行，但混合查询的灵活性可能不如Milvus顺手。我调完索引之后基本能压回80ms左右，你可以先试试。

遇到过类似的情况，问题大概率出在filter没走对索引上。Milvus的标量过滤和向量检索虽然是两个阶段，但如果过滤字段没建倒排索引，它会先暴力扫全量标量再去做向量计算，延迟自然就上去了。你可以试试给部门、时间这些字段单独建scalar index，然后把filter条件改成表达式形式，让查询引擎能提前下推过滤逻辑。另外20万条数据量其实不大，要不要考虑把过滤后的子集直接缓存在内存里？我上次就是这么干的，效果立竿见影。ES那套组合拳我也试过，但向量召回精度和Milvus还是有差距，建议先排查索引再决定换不换。

20万条数据真不算多，延迟飙到300ms大概率不是数据量的问题。Milvus的标量过滤和向量检索确实是两段式，但底层实现是bitset过滤后再做向量计算，如果你过滤条件能筛掉大部分数据，理论上应该更快才对。我怀疑你那个部门或时间字段没建索引，或者建的索引类型不对，Milvus里倒排索引和普通标量索引的性能差异很大，尤其时间范围这种，用range过滤时如果没有合适的索引，它可能得全量扫描一遍元数据，那当然慢。另外你确认下过滤字段的基数高不高，如果部门就几个值，选择性太差，过滤完还剩十几万条，那跟不过滤没啥区别，反而多了层bitset开销。我之前用Qdrant也遇到过类似坑，后来把高频过滤字段单独建了字典索引，延迟就下来了。至于换ES，我觉得没必要，ES的向量检索在过滤场景下其实也强不到哪去，而且你数据量这么小，优化空间很大，先试试调下Milvus的索引参数，比如把过滤字段的索引类型改成Trie或字典，再看下查询profile是不是走了正确的执行计划。

过滤没走对的话基本就是全表扫，试试把过滤字段建成倒排索引或者换标量枚举查询，能快不少。

我之前也踩过类似的坑，20万条数据量其实不大，问题大概率出在过滤字段没建索引，或者filter和向量检索的执行顺序不是你想的那样，Milvus内部可能是先暴力扫了metadata再走向量。你试试给过滤字段单独建倒排索引，然后看下explain计划里filter下推了没，我这边加了索引后延迟就降回80ms左右了。另外如果你过滤条件特别复杂，比如多字段组合，那确实不如ES，毕竟ES的filter cache是杀手锏，向量检索对它来说就是附加功能。

这问题我熟，之前用pgvector也遇到过类似的坑。Milvus的filter其实是在向量召回之后才做的，除非你主动开filtered index或者把过滤条件写进query里的布尔表达式，否则20万数据量下那种简单的按部门过滤根本压不到预过滤阶段。你可以试试把metadata里的时间字段单独建个倒排索引，再配合segment级别的partitioning，但说实话这个数据量下直接上ES的kNN加filter确实更省心，向量插件现在成熟度也不差。

另外你查过没，是不是用了默认的HNSW参数导致候选集太大？如果M和efConstruction没调好，过滤后的空搜索反而会触发全表扫描。我当时的解法是把filter字段做成milvus的partition key，虽然建索引慢点但查询能稳定在100ms内。不过要是业务过滤条件经常变，那还是别折腾了，ES的filter缓存优势太明显。