向量数据库是必要之恶，但不是银弹
原创 小小寰宇 2026年4月28日 10:58 最近两年，向量数据库是 VC 和媒体的热词：Pinecone 拿了 1 亿美元融资，Milvus 社区越来越火，各种新数据库名字一个比一个难拼。 我见过不止一个团队，数据量不到 10 万，第一反应却是"上 Milvus"。花两周搭环境、调参数，跑出来的效果不如直接用 Elasticsearch 的 BM25。 向量数据库是强力工具，但用错场景就是给自己找麻烦。本文来把这个问题说清楚： 什么时候用它，什么时候不用它。 向量数据库解决的是传统数据库解决不了的问题—— 语义相似度检索 。 传统数据库检索是"精确匹配"：你搜"苹果"，返回包含"苹果"这个词的文档。它不知道"苹果"是水果还是公司。 向量数据库的思路完全不同。先把文档和 Query 都转成向量（Embedding），然后在向量空间里找"距离最近"的内容。 用户搜"水果"，可能返回"苹果"、"香蕉"、"橙子"——它们在向量空间里距离近，语义相似。这就是语义匹配：不依赖关键词，理解语义本身。 全量计算两两向量的距离，复杂度是 O(n²)，100 万条数据就是 1 万亿次计算，不现实。ANN（Approximate Nearest Neighbor）算法的思路是"近似"：牺牲一点精度，换取速度。 Milvus、Qdrant 都默认使用 HNSW。 这些场景的共同特点： 精确匹配解决不了，必须靠语义理解 。 说完擅长的，再说不擅长的。 当你向向量数据库新增或删除一条文档时，对应的向量也要新增或删除。这看起来很正常——普通数据库也这样做。 但问题在于，向量索引的结构依赖所有向量。 以 HNSW 为例。它像一个多层蜘蛛网：最上面那层网眼大，帮你快速定位到大致的区域；越往下网眼越小，最后在最底层找到最精确的结果。 为什么搞成多层？ 单层"平板网"搜索要挨个问过去，100 万条数据问 100 万次，复杂度 O(n)。多层结构实现的是"先跳远、再找近处"：最上层节点稀疏、跨度大，几步就能划到目标区域附近；下层节点密集，再做精细比较。搜索复杂度从 O(n) 降到 O(log n)，这就是 HNSW 搜索快的原因。 代价是：搜索路径不是"全局最优"路径，而是"每步不退步"的贪心路径。快和有召回损失，是同一个设计选择的两面。 这和 B-Tree 索引很不一样。MySQL、PostgreSQL 里的 B-Tree 像一本按拼音排序的字典——插入新节点只需要找到叶子层的对应位置，把路径上几个节点分裂一下，不影响其他分支的顺序。HNSW 没有"大小顺序"，边连的是"谁和谁语义相近"。插入一个新向量，要重新计算它和所有已有节点的距离关系，改的可能是一片区域，而不是几个节点。 所以 HNSW 的"更新"不是修修补补，而是 标记旧节点失效，把新节点当作全新的插进去 。失效节点积累多了，每隔一段时间需要整体重建索引——把 100 万个向量全部重新"织网"，耗时数十分钟，期间服务性能明显下降。 工程上的几种应对方式：批量更新（夜间统一重建）、接受局部索引退化、新旧索引双跑（切换时无感知）。没有完美的方案，只有适合业务的权衡。 向量数据库的第二个局限： 带过滤条件的检索效率低 。 这是被严重低估的问题。 实际应用中，几乎不可能只做纯向量检索。你需要： 这些元数据过滤是强需求。 但向量数据库做过滤的方式是： 先向量检索，再内存过滤 。 Embedding 模型把文字"翻译"成一组数字——比如"苹果"变成 但元数据（时间、分类、状态）是另一种完全不同的信息。 所以向量数据库面对带过滤的查询时，只能分两步走：第一步，不管过滤条件，只管语义，找到语义上最接近的结果；第二步，再用过滤条件在这些结果里筛选一遍。如果过滤条件很严格，筛掉了太多结果，第一步就必须多找一些，召回成本就上去了。 这导致两个问题： 召回效率低 ——你明明只需要 10 条结果，但为了满足过滤条件，可能要先召回 1000 条； 精度损失 ——过滤后的结果可能不是最优的，因为向量检索时没考虑过滤条件。 某些向量数据库（Milvus、Qdrant）支持标量过滤，把过滤下推到索引层面，减少无效召回。但"先召后筛"的基本模式没有改变——这是向量数据库娘胎里带来的限制。 ANN 是"近似"最近邻搜索，不是"精确"最近邻搜索。 HNSW 的搜索过程像一个贪心向导：从最高层出发，每次都走向周围最近的邻居，一路向下走到最底层。好处是快，坏处是——它可能在某个岔路口走错方向，然后越走越远。 高维空间中这个问题更突出。当向量维度达到 1024 以上时，各维度的数值稀释了语义信息，真正最相似的结果和次优结果在数值上几乎无法区分，向导很容易在岔路口选错方向。这不是算法写得不好，而是高维几何本身的脾气。 对于高精度需求的场景（法律文档检索、医学文献查询），ANN 的召回损失是不可接受的。 向量数据库的第三个局限： 运维复杂度高，而且贵 。 相比 MySQL、PostgreSQL，向量数据库的生态还很年轻。 内存管理 是第一道坎。HNSW 索引全部加载在内存里，不像普通数据库那样能把冷数据丢到磁盘上。具体占用可以拆成三笔账： 100 万条 768 维向量，内存占用约 10-17 GB （不是很多人以为的"才 3 GB"）；1 亿条则对应约 1-1.7 TB 。 集群调优 是另一道坎。分片、副本、负载均衡，每个向量数据库的实现都不一样。版本升级时索引格式可能不兼容，需要数据迁移。监控告警没有成熟体系，很多指标要自己搭。 硬件成本是大头。HNSW 全内存的要求决定了必须用大内存机器，存储空间是原始数据的好几倍。向量数据库的投入远高于普通数据库，这是决策时必须算进去的账。 实际项目中，这类运维事故通常发生在最忙的时候——白天流量高峰刚过，夜间重建索引恰好启动，服务开始抖动，用户开始投诉，DBA 被 pager 叫醒，手动回滚。 如果你的团队没有专职 DBA，没有足够的运维资源，搭一个高可用的向量数据库集群是个挑战。 说了这么多局限，不是说向量数据库不能用。普通数据库能干的事，不要强行上向量数据库。 如果你的需求是精确匹配，普通数据库完全够用： 这些场景，向量数据库没有任何优势。相反，还增加了复杂度。 如果你的主要检索需求是按结构化字段筛选——按时间范围、按分类标签、按作者来源——普通数据库是最佳选择。MySQL、PostgreSQL 的 B-Tree 索引、Elasticsearch 的倒排索引，都对这类查询做了大量优化。 向量数据库的元数据过滤能力，远不如原生索引。 如果你的数据量在百万级以下，普通数据库 + 简单 Embedding 完全够用。 几个实际选项： 这些方案的优势是 统一 ：一套系统，两种能力，不需要维护两套数据库。 有时候，BM25 就够了。 BM25（Elasticsearch、Solr 默认的检索算法）是基于关键词的统计排序。它不考虑语义，但对于很多场景，这已经足够了。 比如：电商搜索"iPhone 15 手机壳"，BM25 能找到匹配标题的宝贝；文档搜索中，用户输入的 Query 通常包含关键术语，BM25 能有效召回。 BM25 的优势：不需要 Embedding 模型，省去模型部署成本；精确匹配关键词，用户期望明确；解释性强，可以直接看到为什么这个词匹配度高。 什么时候 BM25 不够用？用户 Query 和文档表述不同但意图相同时（比如"如何做大米"和"煮饭方法"），以及需要跨语言检索或处理拼写错误、同义词时。 但如果你的用户 Query 写得比较规范，BM25 能 cover 80% 的需求。 不要非此即彼。 实际项目中，关键词精确匹配和语义扩展检索都很重要，混合架构往往比纯向量方案效果更好。 混合检索的核心思想是：不同的检索方式，解决不同的问题。 BM25 负责精确匹配（用户写了什么词就召回什么词，处理大小写、拼写错误），向量检索负责语义扩展（用户没写但意思相近的内容也能被召回）。两者互补，召回质量明显优于单一方案。 当 BM25 和向量检索各自返回 Top-20 时，如何合并成一个统一的排序？ 倒数融合法（Reciprocal Rank Fusion, RRF） 是最常用的方案： 简单理解： 在任意一种检索方式中排名越靠前，最终分数越高 。这个公式的好处是：不需要训练权重参数；某一路检索出问题时，不至于完全失效；既重视精确匹配，也重视语义扩展。 这类转型我见过不止一次。典型的故事：某技术文档问答系统最初用了 Milvus + OpenAI Embedding 的纯向量方案。上线后用户反馈："搜'部署'，文档里明明写了'上线'，为什么找不到？"——向量检索能召回语义相近的内容，但对这类同义词问题无能为力。还有用户搜"Python"，文档里是小写的"python"，向量检索也不认。 团队后来加了一路 Elasticsearch 做 BM25 检索，两路并行、RRF 融合输出结果。结果关键词召回率显著提升，用户反馈"同义词搜不到"的问题基本消失，延迟增加约 40ms，在可接受范围内。 如果你的团队已经在用 PostgreSQL，还有一个省事的折中方案：装个 pgvector 扩展，让 PostgreSQL 原生支持向量检索。结构化数据和向量数据放在同一个库，备份、监控、事务都能用同一套工具，中小规模（千万级以下）完全够用。 pgvector 的局限：性能不如专用向量数据库，规模大了需要分片。但对于以 PostgreSQL 为主力栈的团队，它是一个不增加系统复杂度就获得向量能力的好选择。 回到开篇的问题： 你的场景真的需要向量数据库吗？ 答案是：看情况。 向量数据库解决了传统数据库解决不了的问题——语义相似度检索。但它也有明显的局限：更新困难、过滤弱、ANN 有召回损失、运维复杂、成本高。 正确的态度是不追捧、不排斥，根据场景选择合适的工具。 混合检索 + 场景适配 ，是比"All in 向量数据库"更务实的选择。 文章首发于向量数据库是必要之恶，但不是银弹
当所有人都在 All in 向量数据库时，你需要冷静思考：你的场景真的需要它吗？
一、向量数据库热潮下，你需要想清楚的几件事
二、向量数据库擅长什么
2.1 语义相似度检索
2.2 ANN 算法：快速搜索的原理
算法 原理 特点 HNSW 多层图结构，高层快速定位区域，低层精确定位 速度快，精度高，内存占用大 IVF K-Means 聚类，先定位簇，再在簇内搜索 内存占用小，建索引时需加载聚类中心，初次查询较慢 PQ 向量量化，用小向量近似表示原向量 内存占用极小，精度有所损失 
2.3 典型适用场景
三、向量数据库的局限
3.1 更新困难
3.2 过滤查询弱
[0.73, 0.21, -0.48, ...] ，压缩的是语义，是"这个词平时出现在什么语境里"。向量之间的距离，对应的是语义上的相似程度。"创建于 2024 年" 是判断条件，不是语义； "分类是技术文档" 是标签，不是数字。这两种信息不在同一个频道上——你没法用"距离"来回答"是不是 2024 年创建的"。
3.3 精度与性能的权衡
ef 参数控制的是"向导愿意多看几个人"： ef=50 意味着向导在最后一层愿意多看 50 个候选再决定， ef=200 则愿意多看 200 个。看得多，越可能找到真正最像的那个——但代价是得多等一会儿。从 ef=50 升级到 ef=200，精度大约提升 4 个百分点，搜索时间却要增加 2-3 倍。 快和准，ANN 只能二选一。3.4 运维复杂度和成本
四、什么时候用普通数据库就够了
4.1 精确匹配
4.2 结构化过滤
4.3 数据量在百万级以下
4.4 BM25 已经够用
五、混合检索架构：务实之选
5.1 BM25 + 向量检索：各司其职
Query
├── BM25检索（关键词精确匹配）→ Top-20
└── 向量检索（语义扩展匹配） → Top-20
↓
分数归一化 + 融合（RRF）
↓
Rerank（精排） → Top-5
↓
大模型生成答案
5.2 RRF 融合：如何合并结果
RRF_score(doc) = Σ 1 / (k + rank_i(doc))rank_i(doc) 是 doc 在第 i 种检索方式中的排名， k 通常设为 60。5.3 实践案例
5.4 不想维护两套系统？试试 pgvector
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);
SELECT content, 1 - (embedding <=> '[0.1, 0.2, ...]') AS similarity
FROM documents ORDER BY embedding <=> '[0.1, 0.2, ...]' LIMIT 5;六、选型速查
场景 推荐选择 原因 原型验证 / 实验 Chroma 零运维，三行代码跑起来 中小规模生产 Qdrant 性能好，API 友好，Docker 一键部署 大规模生产 Milvus 功能全，生态成熟，可分布式 企业级云服务 Pinecone 零运维，99.99% SLA 混合检索优先 Weaviate 原生支持 BM25 + 向量，无需自建融合层 已有 PostgreSQL pgvector 不引入新系统，备份监控一致，中小规模够用 七、总结
