向量库选型——pgvector / Milvus / Chroma / FAISS 怎么挑

做 RAG 第一个纠结往往不是"用什么模型"，而是：向量存哪？

网上一搜，FAISS、Chroma、pgvector、Milvus、Qdrant、Weaviate……全冒出来。你还没动手，就先被选项淹了。然后有人告诉你"Milvus 最强"，你照着装，一圈下来发现光 Docker Compose 就要跑三个容器，调半天环境，最后实验项目三百条文档——杀鸡用了牛刀，还把自己搞蒙了。

这篇的目的只有一个：把每个库的定位说清楚，让你五分钟内知道自己该用哪个，不绕弯子。

---

为什么要选向量库

先说清楚为什么需要它。

RAG（检索增强生成） 的基本流程是：把文档切块 → 每块调嵌入模型转成向量 → 用户提问时把问题也转成向量 → 找出最相似的几块 → 塞进模型上下文 → 模型生成答案。

这里"找出最相似的几块"就是向量相似度搜索。传统数据库的 SQL WHERE 做不了这个，你得用专门能存向量、做近邻搜索的工具。这就是向量库（或向量搜索组件）的来头。

三层记忆架构——短期、向量、结构化 这节讲过，向量层是 Agent 长期记忆的核心骨架。一旦知识量超过上下文窗口，向量检索就是唯一可行的方案。

但不同的向量库，定位和复杂度差异极大，不是越专业越好。

---

逐个过一遍：四类向量库的真实定位

FAISS：本地库，入门首选

FAISS（Facebook AI Similarity Search）是 Meta 出的一个纯 Python/C++ 库，不是服务，没有服务端，没有 HTTP 接口——它就是一个库，你 import faiss，在内存里建索引、存向量、查向量。

适合谁：刚开始做 RAG 实验的人，或者向量量级在几万以内、不需要持久化服务的本地脚本。

规模上限：内存有多大，理论上能塞多少向量。几万到几十万条没问题；几百万条要开始考虑 IVF 分区索引，不然查询会慢；上亿条 FAISS 也能做但你要懂它的索引参数，且没有开箱即用的分布式能力。

上手成本：极低。pip install faiss-cpu，五行代码就能建个索引查询。

劣势：没有持久化服务（需要自己序列化保存 index 文件）、没有元数据过滤（只能过向量，配合文档 id 自己做 payload 管理）、没有 HTTP API（只能在同一个 Python 进程里用）。

import faiss
import numpy as np

# 维度 1536（OpenAI text-embedding-3-small 输出维度，以官方为准）
d = 1536
index = faiss.IndexFlatL2(d)

# 添加向量（这里用随机数模拟）
vectors = np.random.rand(100, d).astype('float32')
index.add(vectors)

# 查最近的 5 个
query = np.random.rand(1, d).astype('float32')
distances, indices = index.search(query, k=5)
print(indices)  # 返回最相似的 5 条的下标

一句话定位：FAISS 是向量搜索的"瑞士军刀小刀片"，能用，够快，但要自己管文件读写和元数据。

---

Chroma：Python 原生，实验和小项目最顺手

Chroma 是一个面向 Python 开发者设计的向量数据库，有两种用法：纯内存（in-memory）和本地持久化（持久化到本地文件），也支持以服务形式跑。

和 FAISS 不同，Chroma 自带元数据存储和过滤——你存向量的同时可以带 metadata 字段（比如文档 id、来源、标签），查询时可以用 where 过滤。

适合谁：用 LangChain、LlamaIndex 做 RAG 原型的人。这两个框架对 Chroma 的集成是开箱即用的，几行代码就接好了。小型知识库、个人项目、团队内部工具。

规模上限：本地单机几十万条没问题。要更大规模需要起 Chroma Server，但它不是为分布式设计的，数百万条以上建议换库。

上手成本：低。pip install chromadb，不需要额外服务器，本地就能跑。

import chromadb

client = chromadb.Client()  # 纯内存模式
# 持久化：chromadb.PersistentClient(path="./chroma_db")

collection = client.create_collection("my_docs")
collection.add(
    documents=["文档一的内容", "文档二的内容"],
    ids=["doc1", "doc2"],
    metadatas=[{"source": "内部文档"}, {"source": "外部网页"}]
)

results = collection.query(
    query_texts=["怎么处理退款"],
    n_results=2,
    where={"source": "内部文档"}  # 只在内部文档里找
)

一句话定位：Chroma 是实验阶段最顺手的向量库，带元数据、上手极快，小规模够用。

---

pgvector：Postgres 扩展，已经用 PG 就不用另起服务

pgvector 是 PostgreSQL 的一个扩展，给 PG 加上了存向量和做相似度搜索的能力。你的业务数据已经在 Postgres 里，装了 pgvector 之后，直接在同一个数据库里加一列 vector 类型，向量和业务数据坐在同一张表或关联表里，可以用 SQL JOIN、WHERE 联合查询。

适合谁：项目已经在用 PostgreSQL（比如后端用 Supabase、Railway、自建 PG），不想额外维护一个向量服务的团队。中小规模 SaaS、内部工具、知识库 API。

规模上限：几十万到几百万条向量，PG 的 IVFFlat 或 HNSW 索引都能扛。几千万条以上查询延迟会上升，需要精细调参；再大就要考虑专业向量库了。

上手成本：中等。需要先在 PG 里装扩展（CREATE EXTENSION vector），Supabase 默认已开启；然后加列、建索引、写 SQL。对已熟悉 PG 的人来说没有学习曲线，对不熟悉的人来说多一层数据库操作。

-- 建表
CREATE TABLE documents (
  id SERIAL PRIMARY KEY,
  content TEXT,
  embedding vector(1536)
);

-- 建 HNSW 索引（查询更快，以官方文档为准选参数）
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

-- 查最相似的 5 条
SELECT id, content, 1 - (embedding <=> '[0.1, 0.2, ...]') AS similarity
FROM documents
ORDER BY embedding <=> '[0.1, 0.2, ...]'
LIMIT 5;

Python 里用 psycopg2 或 asyncpg 操作，和普通 PG 查询一样。

一句话定位：pgvector 是"不多加一个服务"的最优解，前提是你已经在用 PostgreSQL。

---

Milvus / Qdrant：专业向量数据库，大规模分布式场景

Milvus 和 Qdrant 是专门为向量搜索设计的独立数据库服务，有完整的分布式架构、水平扩展能力、丰富的索引类型（HNSW、IVF、Disk-based index 等）、完善的 payload/元数据过滤、TTL、权限控制……

这两个是真正的"向量数据库"，不是附加在别的系统上的。

• Milvus：阿里云等国内大厂有托管版本，社区活跃，适合对国内生态有需求的团队；部署需要 etcd + MinIO + milvus 三件套，重但功能全。
• Qdrant：Rust 写的，单节点性能好，配置比 Milvus 简单，云端有 Qdrant Cloud 托管；对过滤条件要求复杂的场景表现特别好。

适合谁：向量量级在百万级以上，或者需要分布式、多副本、高可用；生产级 AI 产品，不是实验性项目。

规模上限：理论上可扩展到十亿级向量（以官方文档为准）。

上手成本：高。需要运维独立服务（Docker/K8s），Milvus 尤其重；Qdrant 相对轻一些，但仍比 Chroma/pgvector 重。

# Qdrant 简单示例（以官方文档为准）
from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct

client = QdrantClient("localhost", port=6333)
client.create_collection(
    collection_name="my_docs",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)
client.upsert(
    collection_name="my_docs",
    points=[PointStruct(id=1, vector=[0.1]*1536, payload={"source": "内部文档"})]
)
results = client.search(
    collection_name="my_docs",
    query_vector=[0.1]*1536,
    limit=5
)

一句话定位：Milvus / Qdrant 是生产级大规模向量搜索的正确选择，但别在实验阶段就上，运维成本不值得。

---

选型对比表

向量库	部署难度	规模上限（参考）	需独立服务	元数据过滤	最适合谁
FAISS	极低（pip install）	百万级（内存限制）	不需要	无（自管）	入门实验、本地脚本、无服务需求
Chroma	低（本地 or 服务）	十万至百万级	可选	有	RAG 原型、小项目、LangChain 集成
pgvector	中（装 PG 扩展）	百万至千万级	已有 PG	完整 SQL	已用 PG 的项目、中小规模 SaaS
Milvus	高（三件套）	十亿级	必须	有	大规模生产、国内云托管需求
Qdrant	中高（Docker）	十亿级	必须	强	大规模生产、过滤条件复杂、高性能单节点

规模数字是量级参考，实际取决于向量维度、索引配置、机器资源，以各库官方文档基准测试为准。

---

按你的情况选哪个

场景 1：第一次做 RAG，拿来学习或验证想法 → 选 Chroma。几行代码跑起来，不用操心服务器，LangChain/LlamaIndex 原生支持。等验证完了再考虑换。

场景 2：项目已经在用 PostgreSQL（Supabase、Railway、自建 PG 都算） → 选 pgvector。不多加服务，SQL 联表查询很方便，几十万条完全够用。Supabase 直接在控制台开 pgvector，一行 SQL。

场景 3：只需要本地跑脚本，不需要 HTTP 服务，纯 Python 环境 → 选 FAISS。装包即用，查询极快，就是自己管 index 文件的序列化。

场景 4：知识库量级在百万条以上，或者已经是面向用户的生产系统 → 选 Qdrant（轻一点、性能强）或 Milvus（更重、国内托管多）。这时候运维复杂度值得。

场景 5：在用 LangChain / LlamaIndex 搭完整 RAG 管道 → 这两个框架对 Chroma、pgvector、Milvus、Qdrant 都有内置集成，先用 Chroma 跑通，需要换库时只改 vectorstore 那一行，其余逻辑不动。

---

别过早上专业向量库

这一点值得专门说。

很多人刚开始做 RAG，听说 Milvus 强就直接上，结果：

• 本地要起三个 Docker 容器（etcd、MinIO、Milvus）
• 学习一套新的 SDK 和索引参数
• 调通之后发现自己的知识库才 500 条文档，SQLite + FAISS 一样秒出结果

专业向量库的优势，在大规模、多副本、并发高的时候才体现出来。在实验和早期产品阶段，它带来的是纯粹的运维负担，而不是价值。

经验规则：

• 文档量 < 10 万条：Chroma 或 pgvector 够用
• 10 万到 100 万：pgvector HNSW 认真调参仍够用，或 Qdrant 单节点
• 100 万以上、高并发、要多副本：再认真考虑 Milvus / Qdrant 集群

RAG 知识库实战——文档到问答 那节用的就是 Chroma，从文档切块到检索到模型生成，整条链在本地跑通，没起任何独立服务。等你把这条链跑熟了，换库只是一件事的事。

---

常见问题

Q：pgvector 和 Chroma 我两个都想用，有没有统一的接口？

LangChain 和 LlamaIndex 都有抽象 vectorstore 层，你可以在 Chroma 上做实验，换 pgvector 时只改 vectorstore 初始化那一行，不动检索逻辑。这是选主流框架的好处之一——降低换库成本。

Q：Chroma 的数据格式和 FAISS 能互相迁移吗？

不直接支持。但本质都是浮点向量，迁移的思路是：把原始文本和 embedding 存好（不要只存索引），换库时重新建索引导入。所以实际操作里，保留原始文本 + embedding 数组 比保留向量库文件更重要。

Q：我用 Supabase 做后端，向量搜索该用 pgvector 还是另外起 Chroma？

优先 pgvector。Supabase 自带 pgvector 扩展，一行 SQL 开启，向量和业务数据在同一数据库里，也能直接用 Supabase 的 RPC 或 REST 接口调向量搜索，省去另起服务。只有当你的向量量级超出 PG 能承受的范围，才值得另起专业向量库。

Q：Qdrant Cloud 免费版够用吗？

Qdrant Cloud 有免费 tier，以官方当前政策为准（截稿 2026-06，政策随时变）。对于原型和小规模项目，免费 tier 通常够用。商业项目建议确认 SLA 和数据所有权条款。

Q：FAISS 真的没有持久化？

FAISS 本身没有数据库，但可以手动序列化：faiss.write_index(index, "my_index.faiss") 保存、faiss.read_index("my_index.faiss") 加载。配合一个 JSON 或 SQLite 存 id → 文本的映射，就能实现基础持久化。简陋但够用。

Q：向量维度选多少？

取决于你用的嵌入模型。各嵌入模型的输出维度以官方文档为准（截稿 2026-06）——典型值有 768、1024、1536 等，不同模型不一样。建库时维度必须和嵌入模型匹配，不然会报错。更换嵌入模型时要重建索引。

---

小结

向量库选型没有最优解，只有当前阶段最合适的选择：

• 刚开始做 RAG / 小项目：Chroma，装包即用
• 已经在用 PostgreSQL：pgvector，不多起服务
• 只要本地脚本：FAISS，极轻无服务
• 百万级以上、生产高并发：Qdrant 或 Milvus

别被"专业向量库才是正经方案"的说法带偏。文件级记忆与 Hermes Agent 里的知识检索用的就是本地向量索引，够用就是最好的。等规模真的上去了，换库成本并不高——前提是你的代码没有把向量库和业务逻辑耦合死。

更多 Agent 记忆和 RAG 实战，看 AI 数字员工落地指南 里的完整阶梯。

👉 看看 AI 数字员工落地指南，或了解 数字员工搭建实战课。需要为企业落地方案，欢迎找我们聊 企业服务。