对于大多数企业应用而言，向量支持应当是一项融入现有数据资产的功能，而不是再增加第二个数据可信来源的理由。

　　每一个热门的新工作负载似乎都会催生一个新的数据库。你一定熟悉这个套路：从搜索引擎到 JSON（文档）数据库，再到图数据库，我们这个行业总是热衷于构建新的数据库。目前 DB-Engines 已经收录了 434 种数据库。现在，我们又迎来了向量数据库，它几乎在一夜之间被捧为 AI 必不可少的持久化层。这个故事的逻辑很简单，而且一度很有说服力：传统数据库不理解向量！AI 应用需要向量！因此，AI 应用必然需要向量数据库。对吗？

　　不对。事实上，第一个前提几乎立刻就变得不成立了。

　　你可能会说，我当然会这么说——毕竟我在甲骨文工作，而 Oracle Database 23ai 就能将向量嵌入与业务数据一起存储，同时支持 HNSW 和 IVF 向量索引。但这不仅仅是甲骨文的事。实际上，开发人员多年来使用的每一个数据库，如今几乎都提供了向量支持。微软在 SQL Server 2025 中添加了原生 VECTOR数据类型，以及向量搜索和向量索引。MongoDB 已将自动嵌入功能集成到 Atlas Vector Search 中，嵌入在数据库内部生成，并随着数据变化而同步。Postgres 通过 pgvector 也提供了向量支持。类似的例子不胜枚举。

　　这并不是说 Pinecone、Weaviate、Milvus 或其他专业向量数据库供应商注定会失败，但它确实质疑了它们风险投资演示文稿背后的基本前提。对于大多数企业应用来说，向量支持只是一种功能，应当紧密地交织在现有的数据资产中。

　　这一点之所以重要，是因为生产环境中 AI 最难的部分并不是最近邻搜索，而是上下文。

　　扩散的数据孤岛

　　我并不是说向量搜索不重要——它非常重要。如果你正在构建检索增强生成（RAG）、推荐系统、个性化服务、智能体记忆，或者任何需要匹配语义而非关键词的应用，你都需要一种有效比较向量的方法。而且在传统数据库厂商行动之前，专业向量数据库供应商已经把这一点讲得很清楚了。我在 MongoDB 工作时，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 和其他公司能够持续证明，专门的检索基础设施提供的价值足以证明新增一个系统是合理的，那么它们就拥有可信的未来。但举证责任已经转移。开发人员不应该再问：“我为什么不使用向量数据库？”而应该问：“当我已经拥有的数据库就能很好地完成这项工作，并且对我的数据的性能和安全性明显更高时，我为什么还要再增加一个数据库？”

　　对于一个背后有大量风险资本支持的市场来说，这可能会令人不适。很好。当一个功能不再像是一个独立品类时，不适就会发生——而风险投资家们并不是构建应用开发人员日常工作所依赖的那些人。