向量数据库（Vector Database）：按含义搜索，而不是按字词搜索

向量数据库存储 embedding（把文本转换成的一串数字），并能极快地找出最相似的那些——这是 RAG 和语义搜索的基础。

向量数据库是做什么的

一个 embedding 模型会把文本（或图片）转换成一个向量——一长串数字，用来捕捉其含义。向量数据库存储大量这样的向量，并能极快地回答一个问题：在已存储的向量里，哪些和这个新向量最相似？

它的用途是什么

这正是 RAG（Retrieval-Augmented Generation，检索增强生成）和语义搜索的基础：数据库找的不是完全一致的字词，而是含义相近的文本片段，即使没有任何一个词完全匹配也没关系。比如搜索“怎么退订”，也能找到标题写着“终止合同”的那一段。

常见的向量数据库

pgvector：给普通 Postgres 数据库加的一个扩展，不需要额外的独立系统。
Chroma：轻量、开源，很受小型项目和快速上手场景欢迎。
Qdrant：独立的数据库，专为大数据量和生产环境设计。
其他常见的名字：Pinecone、Weaviate、Milvus。

什么时候不需要向量数据库

如果只有几百到几千条文本片段，一个存在内存里的简单数组、配合基础的相似度计算往往就够用了——只有当数据量、速度要求或并发访问超出这个范围时，专门搭一个向量数据库才划算。

示例

CREATE EXTENSION vector; CREATE TABLE docs (id bigserial PRIMARY KEY, content text, embedding vector(1024)); SELECT content FROM docs ORDER BY embedding <-> '[0.01, 0.02, ...]' LIMIT 5;

🛠️ 练习——自己动手试试

针对你自己的一个小项目，判断一下你到底需要向量数据库，还是一个简单数组就够了。

估算一下，你的知识库目前大概有多少个文本片段（chunk）。
如果数量在几千以内：试着用一个简单的内存数组，配合余弦相似度来实现。
如果你已经在用 Postgres：改用 pgvector，搭一张小的测试表试试看。
对比一下两种方案各自需要的工作量和响应速度。

✅ 自查清单

☐ 你估算过自己的知识库大概有多少个 chunk 吗？
☐ 你是不是真的把两种方案都试了一遍，而不只是想了想？
☐ 你现在知道哪种方案对你的项目来说工作量更小吗？

小测验

根据经验法则，什么时候你不需要专门的向量数据库？