企业应用中向量数据库该怎么选？别盲目引入新数据库！
向量支持：融入现有数据资产的功能
对于大多数企业应用而言，向量支持应是融入现有数据资产的功能，而非引入第二个事实来源的理由。每种热门新工作负载都会催生专属数据库，但这只是一时现象。从搜索到 JSON（文档）再到图数据库，行业热衷于构建新数据库，DB - Engines 目前跟踪的数据库已达 434 种。现在，向量数据库几乎一夜之间被誉为 AI 必不可少的新持久层，理由是传统数据库无法理解向量，而 AI 应用需要向量，所以 AI 应用必须使用向量数据库，然而并非如此，第一个前提几乎立刻就站不住脚。
传统数据库也有向量支持
有人会问，是不是因为在甲骨文（Oracle）工作才这么说？甲骨文的 AI 数据库 26ai 可将向量嵌入与业务数据一起存储，还支持 HNSW 和 IVF 向量索引。但并非只有甲骨文如此，开发人员多年来使用的每个数据库如今都具备向量支持功能。微软已在 SQL Server 2025 中添加了原生 VECTOR 数据类型，以及向量搜索和向量索引。MongoDB 已将自动嵌入功能集成到 Atlas Vector Search 中，在数据库中生成嵌入并随数据变化进行同步。Postgres 通过 pgvector 也提供了向量支持。
对专门向量数据库的质疑
这并不意味着 Pinecone、Weaviate、Milvus 或其他专门的向量数据库供应商就会走向失败，但确实让人对它们风险投资推介材料背后的前提产生质疑。对于大多数企业应用来说，向量支持只是一项功能，应紧密融入现有的数据资产中，因为生产环境中 AI 最难的部分并非最近邻搜索，而是上下文。
数据孤岛的泛滥
向量搜索很重要，若构建检索增强生成（RAG）、推荐系统、个性化服务、智能体记忆或任何需要匹配语义而非关键词的应用，就需要高效比较向量的方法。专门的向量数据库供应商比传统数据库厂商更早让这一点变得显而易见，Pinecone、Weaviate、Milvus、Qdrant 等公司帮助确立了如今大家都认为理所当然的模式，这是真正的创新。
然而，这是一种不完整的创新。传统数据库厂商很快就意识到并迎头赶上。Pinecone 于 2021 年推出，同年 Postgres 发布了 pgvector。甲骨文、微软等公司在 MongoDB 之后不久也纷纷跟进。如今，每家厂商都提供向量支持，竞争已转向向量与更大产品的集成程度。在 AI 领域，提供上下文（智能体记忆）依赖于消除数据孤岛。让不同系统分别存储关系型数据、JSON 文档、向量等，应用代码必须同步这些混乱的数据，同时还要执行权限管理、数据时效性、数据血缘和业务规则，这在演示环境中或许可行，但在生产环境中就是一场噩梦。
想象一下，客户更新了一篇支持文章，或者编辑了一项合规政策。事务处理系统掌握了最新信息，但向量表示可能并未更新。然而，由于 AI 的特性，模型会以十足的信心检索到昨天的上下文，速度很快，信心满满，但却是错误的。企业 AI 记忆不仅仅是向量嵌入，还包括文档、事务、客户记录、政策、对话等，还需要知道哪些内容发生了变化，谁有权限查看，以及答案能否追溯到企业信任的数据源。向量数据库可以解决部分问题，但肯定无法自动解决所有问题。如果向量存储在一个系统中，文档在另一个系统中，事务在又一个系统中，图关系在其他地方，权限管理在应用代码中，那么“上下文层”就会变成一个前端带有聊天机器人的分布式一致性问题，这可不是什么好事。
向量搜索与受管理的数据越接近，开发人员需要编写的粘合代码就越少，需要维护的陈旧副本也就越少。因此，这并非是“传统厂商学习新技能”的问题，而是运营重心重新回到了已经掌握企业事实的系统上。
何时使用独立的向量数据库
这并不意味着开发人员永远不应使用独立的向量数据库，否则就是走向另一个极端的懒惰思维。当向量描述的是已经存储在现有数据库中的数据，当数据时效性很重要，当权限与运营记录相关，或者当语义搜索只是更广泛应用中的一个功能时，就使用现有的数据库。如果 AI 助手从客户记录、支持工单、产品目录、政策文档、发票或现有数据库已经管理的账户数据中进行检索，那就从这里开始，不要仅仅因为教程这么做，就添加第二个事实来源。
相反，当检索本身就是产品，而不仅仅是一个功能时，就可以考虑使用独立的向量数据库。如果正在构建一家搜索公司、一个推荐平台、一个大型多租户 RAG 服务，或者一个对延迟、排名复杂度、索引行为或运营隔离的要求超出了主数据库处理能力的系统，那么专门的基础设施可能是正确的选择，但这不会是常态。“有时需要专门的检索基础设施”这一说法显然是正确的，而“每个严肃的 AI 应用都需要一个独立的向量数据库”这一说法显然是错误的。
独立的向量数据库供应商越来越认识到，仅存储向量是不够的，因此他们正在向更高层次发展，关注检索质量、智能体记忆、延迟、评估、数据时效性和操作简便性。Pinecone 的 Nexus 发布就是一个很好的例子，其宣传不再仅仅是“在这里存储向量”，而是“让 AI 更具知识”。但 Pinecone 的发展也证明了，如果长期的竞争优势不在于存储向量，而在于为特定工作负载提供卓越的检索基础设施，那么独立向量数据库市场比许多人想象的要小且更具挑战性。它必须在质量、规模、延迟、开发人员体验和操作简便性方面取胜，而不能仅仅依靠成为嵌入向量的存储地，因为向量嵌入越来越多地存储在各个地方，这是一项更具挑战性的业务。当然，它可能仍然是一个不错的业务，但它不再是每个拥有大量文档和聊天机器人演示的 AI 团队的默认架构，对于需要将向量融入更广泛数据资产的企业来说也不应如此。
别急于引入新数据库
过去十年，一直被告知“专用数据库”是解决方案，但实际上它们只是云供应商推出其组织架构的一种方式。这种建议导致了一些架构的出现，简单的应用程序竟然需要五个持久层，还需要一组工程师来保持它们的同步，这简直是疯了。AI 让情况变得更糟，因为 AI 需要上下文。检索并非在真空中进行，而是基于具有所有权、时效性、权限、血缘和业务含义的数据。涉及的系统越多，就越难知道模型的答案是基于真实数据、过时的副本，还是上周还正确但现在已不再适用的信息。
这一切都说明，问题的关键并非向量本身，而是我们是否希望 AI 应用重蹈现代数据基础设施的覆辙：更多的服务、更多的管道、更多的副本、更多的粘合代码，以及更多真相可能偏离的地方。我们不应再创建另一个陈旧的上下文窗口，而应将向量搜索尽可能靠近它所描述的数据，这通常意味着从已经在使用的数据库开始，并使用已经信任的安全模型。当然，独立向量数据库仍然有存在的空间，就像搜索引擎、缓存和分析平台一样。如果 Pinecone 等公司能够不断证明专门的检索基础设施能带来足够的价值，证明引入另一个系统是合理的，那么它们仍有光明的未来。但举证责任已经转移。开发人员不应再问“为什么不使用向量数据库？”，而应问“当我现有的数据库在我的数据上能够以更好的性能和安全性完成这项工作时，为什么还要添加另一个数据库？”这对于背后有大量风险投资的市场来说可能会让人不舒服，但这是好事。当一项功能不再像一个独立的类别时，就会出现这种不适感，而且风险投资家并非开发人员工作所依赖的应用的构建者。