向量数据库是什么？RAG 的「记忆仓库」

上一篇Embedding讲了怎么把文字变成向量。但接下来有个现实问题：这些向量存哪儿？成千上万条向量，又怎么快速找到「最相似」的那几条？ 答案就是向量数据库（Vector Database）。这篇讲清它是什么、为什么需要它。

一句话理解

向量数据库，是专门用来「存向量」并且能「按相似度极快检索」的数据库。

普通数据库擅长「精确查找」——按 ID 查、按值匹配。但它不擅长回答「哪几条内容跟这句话意思最像」。向量数据库就是为这件事而生的。

和普通数据库有什么不同

	普通数据库	向量数据库
存什么	结构化数据（数字、文本、日期）	高维向量（一串数字）
怎么查	精确匹配（=、>、LIKE）	相似度（找最近的邻居）
典型问题	「ID=123 的订单」	「和这句话最像的 5 段」

一句话：普通数据库查「相等」，向量数据库查「相近」。

为什么需要专门的数据库

你可能会想：算两个向量的距离不就行了，为什么要专门的库？

问题出在规模。当你有几百万、上千万条向量时，挨个算一遍距离太慢了。向量数据库的核心本领，是用一种叫 ANN（近似最近邻） 的索引技术：

不追求「绝对最准」，而是「足够准 + 极快」
靠预先建好的索引结构，把「大海捞针」变成「几毫秒返回」

正是这种「近似但飞快」的检索，让海量知识库的实时问答成为可能。

它在 RAG 里的角色

回顾一下 RAG 的流程，向量数据库是其中的关键一环：

建库（离线）：把文档切分 → 用 Embedding 转成向量 → 存进向量数据库
提问（在线）：把用户问题也转成向量 → 在向量库里检索最相似的片段 → 连同问题交给大模型作答

所以：Embedding 负责「把语义变成坐标」，向量数据库负责「存好这些坐标并飞快地找邻居」，两者配合，才撑起了 RAG。

常见的向量数据库

Pinecone：托管服务，开箱即用，省运维
Milvus / Qdrant：开源、可自建，适合规模化
Chroma：轻量，适合本地开发和小项目
pgvector：给 PostgreSQL 加向量能力，已有 PG 的团队很方便

我一定要用向量数据库吗

不一定，看规模：

资料很少（几十上百条）：直接在内存里算距离就够，不必上专门的库
资料多、要更新、要上生产：用向量数据库，检索又快又稳
已有 PostgreSQL：加个 pgvector 往往是最省事的起点

关于「什么时候用 RAG、什么时候用微调」，可参考定制大模型的三种方式。

小结

向量数据库是 RAG 技术栈里那个「记忆仓库」——它把 Embedding 生成的向量存起来，并用 ANN 索引实现「按意思、极快地找相似」。理解了 Embedding（造坐标）+ 向量数据库（存与找）+ 大模型（读资料作答） 这条链，你就看懂了现代 AI 应用「让 AI 懂私有知识」的完整套路。