为生产环境选择向量数据库:基准测试不会告诉你的事
当工程师评估向量数据库时,他们通常会加载 ANN 基准测试,并选择在 recall-at-10 排行榜上名列前茅的产品。三个月后,他们就开始提交迁移工单了。这些基准测试是在单一客户端、静态且索引完美的索引数据集上测量查询吞吐量的。但生产环境完全不是这样。
本指南涵盖了预测向量数据库在实际工作负载下能否撑住的五个维度,以及一个将这些维度与你的技术栈进行匹配的决策框架。
当工程师评估向量数据库时,他们通常会加载 ANN 基准测试,并选择在 recall-at-10 排行榜上名列前茅的产品。三个月后,他们就开始提交迁移工单了。这些基准测试是在单一客户端、静态且索引完美的索引数据集上测量查询吞吐量的。但生产环境完全不是这样。
本指南涵盖了预测向量数据库在实际工作负载下能否撑住的五个维度,以及一个将这些维度与你的技术栈进行匹配的决策框架。
大多数 RAG 实现都以同样的方式开始:启动一个向量数据库,使用一个不错的模型嵌入文档,在查询时运行余弦相似度,然后发布。演示效果看起来很棒。相关性感觉出奇地好。然后你将其部署到生产环境,发现“Error 221”检索到了关于“Error 222”的文档,搜索特定的产品 SKU 会出现语义相似但错误的条目,而添加日期过滤器会导致检索质量大幅下降。
向量搜索是一个真正强大的工具。但在大多数生产环境的检索工作负载中,仅靠它是不够的。在 2025 年,通过 RAG 获胜的团队并不会在稠密嵌入(dense embeddings)和关键词搜索之间做选择——他们会刻意同时使用两者。
这是一个决策框架,用于判断混合检索何时值得增加复杂性,以及如何在不破坏延迟预算的情况下构建每一层。
你的语义搜索很可能正在悄然恶化,而你的监控面板对此毫无显示。
没有错误日志,没有 p99 毛刺,没有健康检查失败。查询依然返回结果,余弦相似度评分依然看起来正常。但相关性正在一点一点地悄然下滑——每一个被遗漏的新词,都在拉大用户语言与嵌入模型训练语言之间的距离。
这就是嵌入漂移问题。它之所以难以察觉,正是因为它不产生任何可见的失败信号——只有检索质量的缓慢侵蚀。用户会说产品"越来越没用了",然后悄悄离开。
大多数团队把 embedding 生成当作一次性的 ETL 任务:跑一个脚本、填充向量数据库、然后就不管了。这在演示中行得通,在生产环境中却是慢动作式的灾难。你的向量索引不是一个静态的产物——它是一条持续运行的流水线,有自己的故障模式、数据新鲜度保证和运维手册。与主数据库不同的是,它出问题时没有任何异常会被抛出。系统照样返回结果,只是这些结果悄悄地、自信地错了。
如果你在运行一个检索增强生成(RAG)系统、语义搜索功能,或任何依赖 embedding 的产品,你的向量索引值得获得与 PostgreSQL 集群同等的严谨对待。以下是大多数团队在这件事上犯错的原因,以及生产级 embedding 基础设施究竟应该是什么样子。