Qdrant还是Milvus？内存吃紧时胜负会反转
新闻 3
Milvus还是Elasticsearch：同为0.83召回率，18毫秒不等于稳赢
一项RAG检索基准使用实际Docker服务测试1000篇文档，列出Milvus与Elasticsearch的Recall@10同为0.83，检索延迟分别为18毫秒和23毫秒。Milvus在这组配置下更快，但这段差距不足以直接决定生产选型：过滤条件、语料规模和全文检索需求都会影响最终请求的表现。
纯向量检索占主导时，Milvus值得重点评估；已有Elasticsearch集群同时承担关键词搜索与结构化筛选时，先利用现有系统建立向量检索基线通常更合理。迁移门槛应落在相同相关性目标下持续改善的请求延迟、资源消耗和维护成本上，而不是单次小规模测试的名次。
相同Recall@10，测到的是哪一段速度
Recall@10描述的是评估查询找回相关文档的情况。两套配置取得相同分数，说明它们在这批文档、查询和相关性判断下表现相近；这不是近似索引相对于穷举搜索的召回率，也不能推出所有查询类型都同样准确。专有名词、罕见术语和宽泛的自然语言问题，可能需要分别看结果，而不能被一个汇总分数代替。
延迟数字同样有明确边界。它衡量测试中的检索环节，不能直接充当包含查询向量生成、结果重排、网络传输与模型生成的RAG响应时间。汇总延迟也不会告诉开发者哪些请求最慢，或者并发升高时是否出现排队。若用户体验受慢查询支配，只依据这一项结果迁移，可能优化了最容易测量、却并非最影响体验的部分。
小语料还会弱化索引和资源配置的差异。候选文档有限时，扫描、缓存命中和服务开销在总耗时中的占比，与更大规模的数据集可能不同；文档持续写入或更新后，查询与索引维护还会争用资源。因此，这组成绩适合作为提出性能假设的起点。判断假设能否成立，需要让双方使用同一语料和嵌入模型，在相同硬件预算、返回数量与相关性目标下逐步扩大测试规模。
元数据过滤会改变检索路径
权限、租户、地区、时间范围和内容状态往往先决定哪些文档有资格进入结果。Milvus过滤检索文档区分标准过滤与迭代过滤：标准方式先按标量条件缩小搜索范围，再检索向量；迭代方式逐个检查向量搜索返回的候选，直到取得足够的合格结果。复杂标量表达式可能使前一种方式变慢，而后一种方式也可能因检查过多候选而增加耗时。
这意味着“支持元数据过滤”不足以说明性能。一个只留下少量文档的条件，与一个计算复杂却保留大量文档的条件，给系统带来的压力不同。对RAG知识库而言，访问权限过滤尤其不能随意省略来换取好看的数字：无过滤测试即使更快，也没有测到实际要运行的查询。应分别观察常见条件、严格条件与复杂组合条件下的相关性和慢查询表现。
Elasticsearch的kNN文档提供近似与精确搜索，并允许在向量查询中使用过滤条件。精确搜索对匹配文档逐一评分，适用于较小的数据集或过滤后很小的候选范围；近似搜索则通过缩小搜索范围服务于更大规模的低延迟需求。因此，比较过滤性能时还须记录实际使用的是哪种搜索方式，以及过滤后还剩多少候选。把两种执行路径的耗时混在一起，会遮住真正影响选择的条件。
全文检索与向量检索怎样共存
语义检索擅长处理不同措辞表达相近意思的查询，产品型号、错误代码和专有名称则常需要可靠的词项匹配。Milvus混合检索教程展示了在同一集合中保存稠密与稀疏向量，并将两路结果融合。选择Milvus并不必然放弃关键词信号，但应用需要准备相应的向量、索引和排序方案；已有全文搜索功能也未必能原样迁入。
Elasticsearch混合检索文档说明全文与向量搜索可在一次请求中运行并合成排序结果，推荐使用倒数排名融合。对已用Elasticsearch承载全文字段、筛选条件和搜索接口的系统，这提供了一条沿用现有检索链路的路径。混合查询仍会增加需要执行和调校的工作：关键词分支、向量分支与融合排序都应按最终返回的结果评估，而不能只沿用纯向量测试的成绩。
两套系统都能提供混合检索，差别便落在现有能力能否复用。若把向量交给Milvus、全文留在Elasticsearch，应用需要同步文档，并处理两边结果的合并、更新时序与故障排查。若全部留在Elasticsearch，也要确认向量查询在目标过滤条件和负载下达到要求。对最终送入生成模型的候选而言，排序质量与整次检索耗时比单一路径的速度更有意义。
四种工作负载的迁移门槛
- 纯向量检索：当关键词搜索很少参与结果，且真实规模下的向量查询已成为瓶颈，Milvus有明确的测试价值。只有在相同相关性目标和资源预算下，关键请求持续更快，并且写入、更新与恢复要求也能满足，迁移才获得充分依据。
- 复杂过滤：按过滤后的候选规模与条件复杂度分组，而非只看有无过滤。若某条执行路径在严格权限条件下产生明显慢查询，决定性指标应是业务允许的尾部延迟和合格结果质量，而不是无过滤查询的汇总成绩。
- 全文加向量：把精确术语与语义改写放进同一批业务问题，比较融合后的排序和请求耗时。拆分到两套系统只有在质量或性能收益足以覆盖数据同步、排序融合和故障处理成本时，才有清晰回报。
- 已有Elasticsearch集群：先在现有索引和接口上建立向量及混合检索基线。若调校查询、索引与资源配置后仍无法达到目标，再看Milvus的优势能否在并发、过滤和数据更新条件下稳定出现；否则新增服务会增加维护面，却未必改善用户实际等待的请求。
最终比较的应是两套可运行的检索方案，而非两个产品名称：同一批文档、同一嵌入模型、同一相关性要求和同一组业务过滤器，再计入全文融合及日常维护。这样的对照才能说明检索延迟上的差距，是否足以抵消一次迁移带来的系统成本。
相关阅读：
相关文章
订阅我们的新闻通讯
将最新 Web3、AI 和加密货币新闻直接发送到您的邮箱。
0