向量数据库到底是什么

先把问题说清：它不是为了“存向量”而存在

第一次听到“向量数据库”这个词，很多人的直觉反应是：这不过是一个能把一串浮点数写进磁盘的数据库。这个理解过于表面。普通关系型数据库同样可以存一列 float[]，文档数据库也可以把一段 JSON 数组写进去，但这并不意味着它们就自动具备了向量数据库的能力。关键并不在“能不能存”，而在“能不能围绕这类数据做高效检索、过滤、更新与运维”。

向量数据库真正要解决的问题，是把文本、图片、音频乃至用户行为等对象，先通过模型映射为嵌入向量embeddingembeddingAn embedding is a dense numeric representation produced by a model so that items with similar meaning end up near each other in vector space. The database does not interpret the raw semantics itself; it depends on the geometry induced by the embedding model. ，再在这个几何空间里做“谁和谁更接近”的搜索。换句话说，它服务的不是精确值匹配，而是语义相似度语义相似度语义相似度指两个对象在含义层面上的接近程度。两段文本即使没有共同字面词汇，也可能因为表达的是同一件事而在向量空间里相互接近。向量数据库的核心就是把这种“含义上的近”变成可计算、可检索的对象。 。

这也是它和传统数据库最根本的分界线。传统数据库擅长回答“ID 等于 42 的记录是谁”“状态为 paid 且时间大于今天的数据有多少”“标题里包含这个关键词的文章有哪些”。而向量数据库擅长回答的，是“哪几段内容和这个问题表达的是一回事”“哪张图片和这张参考图风格最接近”“哪些用户行为模式和这次异常最相似”。前一类问题以布尔条件和排序为核心，后一类问题以距离和近邻为核心。

从精确匹配到近邻搜索

如果把传统数据库的查询看成在离散集合上筛选，那么向量数据库的查询更像是在连续空间里找邻居。每条记录除了原始文本或元数据，还会附带一个高维向量。查询发生时，系统先把查询语句也编码成向量，再计算它与库中各向量之间的距离，返回距离最近的前若干条。

这里的“距离”并不一定是中学里学到的几何长度。在工程里，常见的度量包括欧氏距离Euclidean distanceEuclidean distanceEuclidean distance measures straight-line separation in vector space. It works well when absolute magnitude matters, but in many text retrieval settings the direction of the vector is more informative than its raw length. 、内积和余弦相似度。不同度量对应的直觉不同。对于很多文本检索任务而言，我们更关心方向是否接近，而不是数值长度本身，所以余弦相似度常被采用；对于经过特定归一化的嵌入，内积检索也很常见。

这类搜索被称为最近邻搜索nearest neighbor searchnearest neighbor searchNearest neighbor search asks which stored vectors lie closest to a query vector under a chosen distance metric. The challenge is simple to state but becomes computationally expensive when the collection is large and the vectors are high-dimensional. 。当数据只有几千条时，直接把每条向量都扫一遍并不难；可一旦数据规模进入百万、千万乃至更高数量级，暴力扫描的延迟和成本就会迅速失控。向量数据库的价值，正是在这里开始显现。

为什么大模型时代突然需要它

在大模型普及之前，语义检索并不是一个全行业的基础能力。传统搜索系统更多依赖倒排索引、关键词召回和人工特征。它们对网页搜索、日志检索、商品过滤都足够有效，因为这些问题很大程度上可以通过“词是否出现过”来近似表达。

大模型改变了这个前提。今天的应用越来越常见的一步，是先把文档、知识库、工单、代码片段或图片描述转换为向量，然后在问答、推荐、相似案例查找、内容聚类与去重里反复使用。尤其是在RAGretrieval-augmented generationretrieval-augmented generationRAG combines retrieval with generation: fetch relevant external knowledge first, then feed it to the language model so the answer is grounded in retrieved context rather than the model's frozen parameters alone. 流程中，向量库几乎已经成为默认部件。模型本身负责理解与生成，向量数据库负责在外部知识中做快速、语义化的召回，两者分工非常清楚。

因此，大模型时代并不是“发明了”向量检索，而是把它从一个相对专门的技术，推到了应用基础设施的位置。过去你可以把相似度搜索当成一个附属功能；现在很多系统从一开始就围绕它设计数据流。

它到底比普通数据库多做了什么

如果抽去产品包装，一个成熟的向量数据库通常会同时处理四类问题。

• 第一类是索引问题：如何让高维向量的近邻搜索在大规模下仍然足够快。
• 第二类是过滤问题：在做相似度搜索之前或之后，如何叠加租户、时间、标签、权限等结构化条件。
• 第三类是存储问题：如何管理原始文档、向量、payload 与索引文件的一致性。
• 第四类是服务问题：如何提供集合管理、批量写入、持久化、复制、监控、扩缩容等数据库级能力。

也就是说，向量数据库并不只是一个“ANN 算法壳子”。它是在 ANN 检索内核之上，加上一整套可运维的服务层。很多项目原型阶段用 numpy 或 faiss 就够了，因为只需要“搜得到”；进入生产之后，就会发现还需要过滤、权限、备份、滚动升级、数据迁移、观测指标，这才是数据库产品真正补上的部分。

“数据库”这个词有时会误导人

向量数据库常被拿来和 MySQL、PostgreSQL、MongoDB 直接并列，但它和这些系统的抽象重点并不一样。传统数据库围绕事务、约束、联接、聚合展开；向量数据库围绕索引、距离计算、召回率和过滤效率展开。两边都在管理数据，却服务于不同的主问题。

这也是为什么很多生产系统不是“全量替换”，而是“并行协作”。业务主数据仍然放在关系库或文档库中，向量数据库维护一份用于相似检索的派生索引。查询时先在向量库取出候选，再回主库拿详情，或者反过来先按业务条件裁剪数据范围，再做向量近邻搜索。这种架构并不奇怪，反而是最常见的现实形态。

从语义空间理解它的价值

一旦接受“数据对象可以被投影到一个几何空间里”，很多原本难以表达的任务都会变得自然。客服知识库问答，不再依赖完全匹配某几个关键词；图像相册里的“相似照片”，不需要先写一堆规则；重复工单识别，也不再只看标题有没有相同字词。模型把复杂对象压缩成向量，向量数据库把这些向量组织起来，应用便获得了一种新的检索维度。

需要强调的是，向量数据库的上限并不只由数据库本身决定。嵌入模型质量、切分策略、元数据设计、过滤逻辑、重排策略，都会直接影响最终效果。数据库负责“找近邻”，但“近”是否真的等于“相关”，很大程度上要看你前面把对象表示成了什么向量。这也是做 RAG 时常见的误区：把结果不佳完全归咎于某个数据库，实际上问题可能出在 embedding 模型或切块方法上。

本篇要点

• 向量数据库的关键不在于“存储向量”，而在于围绕向量做高效、可运维的近邻检索。
• 它与传统数据库的根本区别，是前者主要处理语义相似度，后者主要处理精确条件匹配。
• 大模型时代让 embedding 与 RAG 普及，向量检索因此从专门技术变成通用基础设施。
• 一个成熟的向量数据库不仅包含 ANN 检索，还包含过滤、存储、复制、监控和服务化能力。
• 在生产里，向量数据库通常与关系库、对象存储并行协作，而不是简单替代。

下一篇

理解了“为什么需要向量数据库”之后，下一步就该进入它的计算内核：当库里有几百万个高维向量时，系统究竟如何在可接受的时间里找出最相近的结果。下一篇将从暴力扫描出发，讲到近似最近邻与 HNSW 图索引。

参考资料

• FAISS 文档
• Qdrant Concepts
• Weaviate Concepts
• Milvus Documentation