作者：来自 Elastic 杰瑞朱

随着现代深度学习模型的成熟，向量搜索在实现语义理解和搜索上面已经被证明非常有用，但它终究只是数据库的一种搜索能力，无法撑起一个独立的数据库赛道。用户和Agent们真正需要的是把向量能力 “并入” 现有数据搜索系统，与业务数据融合，实现结构化、非结构化和向量的混合搜索，而不是另外引入一个正在反向补课、期望成为更全功能的 “专用向量数据库（dedicated vector database）”。

专用向量数据库的过去和现在

向量搜索并不是近一两年才出现的技术，而是过去十多年逐步发展成熟的，先回顾一下历史：

• 2000-2010：学术研究起步，这一阶段主要是学术界在研究高维向量检索，代表性成果是 Approximate Nearest Neighbor（ANN）算法的出现和早期库。
• 2014-2017：深度学习普及，语义向量需求出现，随着词向量（Word2Vec，2013）、句向量、图像 Embedding、推荐向量等流行，  “向量 + 相似度搜索” 的需求开始在工业界出现，例如搜索、推荐、广告系统。
• 2017：FAISS 发布，工业级向量搜索开端，Facebook 开源 FAISS 被普遍认为是现代向量搜索工程化的里程碑，标志着向量搜索从理论走向大规模工业应用。
• 2018-2021：HNSW、Annoy 等开源工具出现，向量被更加普遍使用起来。
• 2022-现在：大模型的崛起 语义搜索和多模搜索的需求让向量搜索获得爆发式增长。

回顾这段历史可以看出来，向量搜索本身的工业化应用历史很短，从应用范围来讲，过去很长时间主要集中于大型互联网公司的推荐系统，并没有进入大量企业应用的视野。从这两点讲，向量数据库根本就没有流行过，甚至在 ChatGPT 横空出世之前，绝大多数开发者，根本不知道向量搜索，即使现在，很多对于向量搜索中的各种概念也不是很了解。

专用向量数据库进入大众视野就更为短暂，要不是大模型的崛起，可能永远不会进入大众开发者的视野。既然大模型已经带火了向量搜索，为何说很快就会把他们遗忘？

一、所有巨头和非巨头均已下场，赛道已垮塌

如果你网上搜索一下，经常能看到很多专用向量数据库和各种巨头进行比较来获得关注，比如 PGVector，ES 等等，为何专用向量数据库痴迷于几乎想和每个巨头较量一番？这在大模型崛起以前是很少见的。其实这本质上体现了一种深深的焦虑，因为在大模型产生震撼效应之后，各个数据库巨头都立刻扩展原有的引擎，把功能扩展到原来专用向量数据库的赛道。 比如开源巨头：Postgres、MongoDB、Elasticsearch、Redis。传统商业数据库巨头：Oracle、SQL Server。所有云厂的云原生数据库和所有的分析型数据库、数仓、数据湖。连 AWS S3 都下场提供向量搜索功能。专用向量数据库要一个个反击已是徒劳。

对于创业公司而言，经常会面对来自投资人的灵魂拷问：“如果巨头下场跟你做一样的东西，你该怎么办？” 但是对于专用向量数据库赛道而言，已经不是某个巨头的问题，而是所有的巨头和非巨头均已下场，甚至各种形态的数据库创业公司都支持了向量功能，所以这个赛道事实上已经被钢铁洪流冲垮了。

如果从巨头的视角来看，他们只是增加了一个维度就把这个赛道吞噬了，借用三体里面那句经典的话来说就是，“毁灭你，与你何干？”。倒不是巨头要刻意 “打压创业公司”，  而是用户需求和向量搜索本身的特性决定了最终会被吸收，成为现有各种形态数据库的一种能力，而不是一个独立的品类。

二、技术同质化，向量搜索没有真正的壁垒

从各大数据库支持的速度看，也就是近一两年就都支持了向量搜索、现在几乎都很难找到哪个不支持的，这本身体现了向量搜索的壁垒之低。

从使用的技术来讲，基于 Faiss 修改肯定是最多的，从算法讲也主要是 HNSW、IVF、DiskANN，量化上大家也都大同小异。专用向量数据库很多也是基于 Faiss的，仅仅优化的不同难以形成技术代差，况且很多优化的手法业界都很类似。像 Lucene 这样从零开始写 HNSW、IVF 等算法实现的是非常少见的，但也没有很慢，很快就实现了。

那把 Faiss 改造成分布式系统算不算？现在的分布式技术已经非常成熟，用在向量索引，还是倒排索引、还是 Key-Value 列式存储上并没有实质区别，连各种技术概念几乎都是相同的。这也是为什么传统巨头可以很快集成向量搜索的原因之一。

那支持 GPU 算不算？这个就更加不算了，连基于 Java 的 Elasticsearch 和底层的 Lucene 都开始直接调用 CPU SIMD 和 GPU了！事实上 Nvidia 正联合每一家知名数据库和搜索引擎来推广他们的 CAGRA（CUDA ANN GRAph）和 Lib。这终究是老黄的核弹，不是专用向量数据库的。

专用向量数据库优化更好，性能更强吗？在几年前肯定是的，但是各大巨头入场后，各种优化也很快跟上了，比如优化 HNSW 图的构建和搜索、搜索并行化、剪枝等等大家都在做，各大巨头相较于创业公司拥有更多优秀的引擎高手，差距很快就缩小了。另外，高维度向量搜索天生对算力要求很高，必须通过 CPU 向量化指令（AVX2/AVX512/ARM NEON）等才能获得满意的性能，而数量级的提升则需要依赖 GPU，这也是非常擅长做数据结构和算法优化的 Lucene 也必须采用 SIMD 指令和 GPU 的根本原因。最后，在实际大规模向量搜索落地的时候，大家考虑的完全不是纯性能有多快，而是性能、精度、成本的平衡。 在多种维度的平衡下，现在大家都在做量化，但是技术路径也都非常相似，只会有先后，不存在技术壁垒。

反观专用向量数据库推出的各种向量搜索 benchmark，简直与现实完全脱节，测试用例仅仅是向量的搜索和有限的过滤，完全没有混合搜索。更离谱的是，搜索结果仅仅返回文档 ID 列表！ 你可以想想这种测试离现实有多远，任何做过数据库开发的人请回忆一下，你从数据库拿搜索结果仅仅返回 ID 列表吗？然后再去别的数据库拿明细？那这一整套的延迟不上天了？再严苛一点，比如 Mongo 和 ES 的用户，返回的搜索结果里面字段数量可能是几十，甚至是几百。另外一个非常技术的叫 Segment 数量，因为 Segment 数量对于向量搜索 QPS 的影响非常大，更多的 Segment 数量往往导致搜索 QPS 下降，所有的 benchmark 里面根本没有这方面的标注。

那专用向量数据库为何采用如此离谱的测试用例？可以从某些专用向量数据库的文档里面找到答案：默认搜索只返回 ID 列表，需要显示指定额外返回字段，并且注明：要尽量限制返回标量字段的数量，因为这会 2 次查询，而且是从对象存储拿，这会极大影响搜索速度。 我还专门测试了一下，果不其然，仅做向量搜索的简单情况下，仅仅结果里面返回了 12 个标量字段的值（其中一个字段包含一个段落的文本来贴近实际 RAG 应用），测试结果跟只返回 ID 的搜索比较，QPS 掉了 45%！ 简直令人瞠目结舌。所以提醒各位，一定要在实际项目中用真实用例测试，标准 benchmark 过于局限，参考价值非常有限。

所以从各方面来看，专用向量数据库都没有实质的壁垒，反而纯向量搜索本身的局限很大。

三、“混合搜索” 已成共识： 向量搜索只是其中一个手段，不是全部

专用向量数据库实际上过去很多年都火不起来，ChatGPT 的横空出世，让专用向量数据库仿佛抓住了续命稻草，立刻给公众和投资人描绘了向量就是未来，可以颠覆现在所有数据库的一副壮丽图景。 但这完全禁不起技术推敲和现实检验。

跟模型交互的是向量吗？传给模型的上下文里面是文字，而不是一串完全看不懂的数值向量，大语言模型返回给你的也是人读得懂的文本，也不是向量。传给修图模型的是原始图片，返回的是修改过的图片。

对于各种大模型来讲，对你的要求是提供最相关的上下文，而这个要求里面，向量搜索只是一个对现有搜索的语义补充，而不是代替。 我曾经在很多场合和很多开发者交流，他们很多曾经想只用向量搜索来组织上下文窗口，但是应用在真实场景下，效果都非常差，最后他们都回到了 “混合搜索”。

最近还发生了一个更惊人的事件打破了专用向量数据库的叙事逻辑，就是 Claude Code 用 Grep 来组织上下文。这个事件暂且不论是不是最好的做法，但是从根本上教育了一直以来被误导的开发者，对 LLM 来讲，组织高质量的上下文是目标，至于你如何组织并不是关键，如果在你的应用场景，Grep 是最高效的那就Grep。

我们常说，要辩证地看事物，向量搜索最大的缺点是相似度匹配的模糊性，对于绝大多数企业应用场景，精确返回搜索结果是必要且不能代替的，比如 商品编号、门牌号、手机号、专利号、各种专用术语、函数名称、经纬度 等等，精确的匹配肯定要比近似匹配优先级高，放弃快速而精准的搜索，仅用近似匹配就是舍近求远，更别提向量搜索的算力成本要远远大于传统的搜索。

所以，当下业界普遍的共识是 “混合搜索”，前 Vespa 首席科学家 Jo Kristian Bergum 2024年末在 X 发了一篇向量搜索的年度总结，浏览量高达 26万 《The rise and fall of the vector database infrastructure category》 里面指出：

仅靠向量搜索无法满足实际的、真实世界的用例需求。向量搜索不是一个独立的类别，而是现代搜索工具箱中不可或缺的能力。

现在很多数据库也开始支持倒排、稀疏向量、全文搜索等等 ，大家的目标都是要做好“混合搜索”，就连专用向量数据库也是这么想的！开始反向补课，开始做全文搜索等等。但问题在于，对于现有非常成熟的引擎来讲，去补向量的课并没有太大难度，但是反向补传统数据库和搜索引擎的课要做的工作是非常多的，即使他们花了大量时间和资源去补了课，也不会让他们成为比现有成熟方案更好的数据库。

当下已经在极速迈向 Agentic 时代，反而发现 Agent 对于获取精确结构化数据的需求越来越高，所以衍生出 MCP 协议，让 Agent 自主地去获取各个业务的数据，而这里面很多是传统的结构化、半结构化数据、分析统计结果，比如数据库记录、JSON 对象、各种分析报表等等。

专用向量数据库的未来非常迷茫

“专用” 这个词，本质上就已经放弃了大规模的普适性，未来只能是走向更加窄而专的方向，而不是更加普遍的场景。就连数据库巨头生态内的用户，都很难因为向量搜索去投奔另外一个阵营。 现有系统使用的成熟度、技术惯性都是很难短期改变的，与其从头用一个新东西，不如在原有技术栈用向量搜索改进原有的搜索，更何况各家的实现并没有质的区别。大家最终会在既有生态内获得满意的向量搜索体验。

走向超大规模，超强性能的道路？走这个路更加放弃了普适性，因为需求越极致、优化就会越奇葩，甚至可能要牺牲易用性、安全性等等，否则这些都会成为极致规模和速度的拖累。但是这个方向很难独立创业成功，因为有这样需求的往往是互联网公司和科技巨头，他们往往有非常强的技术实力，他们更希望基于开源产品魔改来适合自己超大的规模。这和投资人期望的大规模应用和指数级增长目标相悖。

从底层数据库跳出来，往上走向业务？比如做各种垂直行业的方案，这是更加艰辛的道路，往往会陷入一个个做项目的过程中，最终偏离技术创业的道路。

结语

•  向量搜索已经成为数据库的标配，混合搜索是共同的目标。

• 专用向量数据库的独立赛道已经崩塌，现实需求必然把“向量搜索”吸收进更大的数据平台。

• 未来不会存在向量搜索的霸主，现有生态的格局不会因为向量搜索产生根本性变化。与其再造一个数据库，不如让向量无缝融入用户已经熟悉和信任的数据库。