【大模型实战 3】向量数据库选型：Chroma / Milvus / FAISS 怎么选？

程序学到昏

144人浏览 · 2026-05-09 07:15:00

程序学到昏 · 2026-05-09 07:15:00 发布

上回说到
文档切分好了，咱们手里有了一堆碎卡片。

接下来的问题是：这些卡片存哪儿？

你可能会想：存数据库啊，MySQL、Redis 随便选一个。

打住！普通的数据库只认识“精确匹配”（比如 ID=1001），它们不懂“意思相近”。

今天我们要请出的主角，是 AI 时代的专属仓库 —— 向量数据库。

🧐 向量数据库到底是个啥？

先回顾一下上一篇提到的“向量化”。

我们把一段文字变成了一串数字，比如 [0.12, -0.45, 0.88, ...]。
这串数字代表了这段话的“意思”。在数学上，它就是一个向量。

普通的数据库（关系型）长这样：

ID	内容	作者
1	苹果很好吃	小明
2	香蕉是黄色的	小红

向量数据库长这样：

ID	向量（意思）	内容
1	`[0.1, 0.2...]`	苹果很好吃
2	`[0.8, 0.9...]`	香蕉是黄色的
3	`[0.12, 0.21...]`	橘子也不错

核心区别在于：
当你问向量数据库：“我想找和‘苹果很好吃’意思相近的句子”。
它不是找包含“苹果”这两个字的句子，而是计算距离。

它发现 ID 1 和 ID 3 的向量在空间里离得很近（意思相似），而 ID 2 离得很远。
于是它把 ID 1 和 ID 3 返回给你。

这就是向量数据库的看家本领：相似度检索。

🥊 三大主流选手对比

市面上的向量数据库很多，但最适合咱们个人开发者和中小企业的主要是这三家：

特性	FAISS (Facebook)	Chroma	Milvus
上手难度	⭐⭐⭐ (偏底层)	⭐ (极简)	⭐⭐⭐ (需部署)
存储方式	内存为主 (可存文件)	本地磁盘 (SQLite+文件)	分布式集群 (S3+MySQL)
适用场景	离线分析、单机跑通	原型开发、中小应用	生产环境、海量数据
并发支持	弱	中	强
一句话评价	算法库，不是正经数据库	轻量级，开箱即用	工业级，企业标配

下面咱们一个个拆解。

🥉 选手一：FAISS —— 算法大神的玩具

FAISS 是 Facebook 开源的库。严格来说，它不是个“数据库”，而是一个向量检索算法库。

它把向量计算优化到了极致，速度极快。

优点：

快：在单机上处理几亿个向量毫无压力。
灵活：支持各种复杂的索引算法（IVF, HNSW, PQ）。

缺点：

难用：没有 REST API，没有现成的 CRUD 接口，你得自己写 Python 代码去管理数据。
不支持多用户：基本上是“单机单线程”逻辑，并发多了容易崩。
数据持久化麻烦：虽然可以保存文件，但不像传统数据库那样方便备份和恢复。

结论：适合做离线测试、跑算法验证，或者你是底层大佬想自己造轮子。新手不推荐直接用它做 RAG 后端。

🥈 选手二：Chroma —— 新手之友

Chroma 是专门为 LLM 应用设计的。

它的目标只有一个：让开发者用最少的代码把向量跑起来。

你不需要安装服务器，不需要配 Docker，直接 pip install chromadb 就能用。它底层用 SQLite 存元数据，把向量存在本地磁盘里。

代码演示（太简单了）：

import chromadb

# 1. 创建客户端（自动在当前目录建数据库）
client = chromadb.Client()

# 2. 创建一个集合（相当于建表）
collection = client.create_collection(name="my_knowledge")

# 3. 添加数据
collection.add(
    documents=["苹果很好吃", "香蕉是黄色的"],
    ids=["id1", "id2"]
)
# 注意：Chroma 可以自动帮你把文本转成向量，省去 Embedding 步骤！

# 4. 查询
results = collection.query(
    query_texts=["我想找关于水果的描述"],
    n_results=1
)

print(results)

优点：

极简：几行代码搞定，不需要运维。
内置 Embedding：你给文本，它帮你转（虽然模型一般，但够用）。
轻量：纯本地文件，不占资源。

缺点：

性能瓶颈：数据量超过几十万级别时，查询速度会下降。
不适合分布式：很难横向扩展。

结论：个人项目、Demo 演示、中小规模知识库的首选。咱们这个系列的前几篇实战，都会用 Chroma。

🥇 选手三：Milvus —— 企业级大杀器

如果你的知识库有几千万条数据，每天有几万次查询，Chroma 就扛不住了。这时候得请出 Milvus。

Milvus 是国产开源之光（Zilliz 公司），专为海量数据设计。它支持分布式部署，能跑在几百台机器上，存千亿级向量。

特点：

强：分布式架构，高可用，高并发。
全：支持混合检索（向量 + 关键词过滤），支持动态 Schema。
重：部署比较麻烦，依赖 etcd、MinIO、Pulsar 等一堆组件（虽然也有单机版 Milvus Lite）。

代码演示：
Milvus 通常需要起一个 Docker 容器或者连远程服务。

from pymilvus import connections, Collection

# 连接服务
connections.connect("default", host="localhost", port="19530")

# 这里的代码就比 Chroma 复杂多了...
# 需要定义 Schema（字段类型）、创建索引等

结论：企业生产环境的标准选择。如果是公司内部大项目，直接上 Milvus，省心（运维省心，代码稍微繁琐点）。

🤔 到底怎么选？一张图帮你决定

别纠结，按这个标准来：

1. 我刚开始学 RAG / 做个人小工具：

👉 Chroma。别犹豫，闭眼选。简单就是王道。

2. 我是公司项目，数据量几百万，要高并发：

👉 Milvus。稳定性压倒一切。

3. 我想研究底层算法 / 跑离线评测：

👉 FAISS。

4. 公司已经有 Elasticsearch，不想多一套系统：

👉 直接在 ES 上加向量字段。一套系统，关键词 + 向量都能查。

5. 公司是 PostgreSQL 重度用户，数据量中等：

👉 装个 pgvector 插件。SQL 就能搞定向量检索，零额外运维。

6. 数据是 MongoDB 存的，喜欢灵活 Schema：

👉 MongoDB Atlas Vector Search。文档和向量一起管理。

🔄 进阶选择：传统数据库的向量扩展

很多公司会说：“我们已经有 Elasticsearch、PostgreSQL、MongoDB 了，再搞一套向量数据库，运维成本太高，数据还得同步两遍。”

好消息：传统数据库现在也能支持向量了！

如果你公司已有这些基础设施，直接在上面加向量能力，比从零搭建新系统更省心。

Elasticsearch：搜索老牌选手的向量进化

Elasticsearch 本来就是搜索界的扛把子（BM25 就是它家的）。
从 8.x 版本开始，ES 正式支持向量搜索。

适用场景：

公司已经在用 ES 做日志分析、全文搜索。
需要混合检索：关键词（BM25）+ 向量，一个查询搞定。
数据量大，但对向量精度要求不是极致。

怎么用：

# 创建索引时定义向量字段
PUT /my_knowledge
{
  "mappings": {
    "properties": {
      "content": {"type": "text"},
      "embedding": {
        "type": "dense_vector",
        "dims": 384,           # 向量维度，根据 Embedding 模型定
        "index": true,
        "similarity": "cosine"
      }
    }
  }
}

# 查询：混合检索（ES 8.x 推荐语法）
# knn 查询放在顶层，与 query 并列，自动合并结果
GET /my_knowledge/_search
{
  "knn": {
    "field": "embedding",
    "query_vector": [0.1, 0.2, ...],
    "k": 5,
    "num_candidates": 10
  },
  "query": {
    "match": {
      "content": "年假怎么休"
    }
  },
  "rank": {
    "rrf": {}      # 使用 RRF（倒数排名融合）合并 knn 和 query 的结果
  }
}

优点：

✅ 无缝衔接：ES 本身的全文搜索能力 + 向量能力，一个系统两用。
✅ 混合检索原生支持：不用自己写合并逻辑。
✅ 运维成熟：ES 的监控、备份、集群方案都很完善。

缺点：

⚠️ 向量检索性能不如专业向量库（Milvus、Qdrant）。
⚠️ 高维向量（比如 1536 维）存储成本较高。

结论：已有 ES 生态的公司首选，一套系统搞定关键词 + 向量检索。

PostgreSQL (pgvector)：SQL 老兵的 AI 加成

PostgreSQL 是很多公司的“万能数据库”。
通过 pgvector 扩展插件，它也能存向量、做相似度检索了。

适用场景：

中小规模应用（百万级向量）。
需要事务支持：向量数据和业务数据一起管理，保证一致性。
团队熟悉 SQL，不想学新 API。

怎么用：

-- 1. 启用扩展
CREATE EXTENSION vector;

-- 2. 创建带向量字段的表
CREATE TABLE documents (
  id SERIAL PRIMARY KEY,
  content TEXT,
  embedding vector(384)   # 384 维向量
);

-- 3. 插入数据
INSERT INTO documents (content, embedding)
VALUES (&#x27;年假怎么休&#x27;, &#x27;[0.1, 0.2, 0.3, ...]&#x27;::vector);

-- 4. 向量检索（找最相似的 5 条）
SELECT content, 1 - (embedding <=> &#x27;[0.1, 0.2, ...]&#x27;::vector) AS similarity
FROM documents
ORDER BY embedding <=> &#x27;[0.1, 0.2, ...]&#x27;::vector
LIMIT 5;

优点：

✅ SQL 即可操作：不用学新语言，SELECT 就能查向量。
✅ 事务支持：插入、更新、删除都能回滚，数据一致性有保障。
✅ 零额外运维：不增加新组件。

缺点：

⚠️ 性能有限：千万级以上数据时，检索速度会下降。
⚠️ 缺少分布式能力：单机数据库，难以横向扩展。

结论：中小项目、PostgreSQL 重度用户的最佳选择。

MongoDB：文档数据库的向量融合

MongoDB 本来就是存“文档”的，和 RAG 的文本块天然契合。
Atlas（MongoDB 官方云服务）现在内置了 Vector Search 功能。

适用场景：

公司已经在用 MongoDB 存业务数据。
需要文档 + 向量混合存储：一条记录里既有结构化字段，又有向量。
团队习惯 MongoDB 的灵活 Schema。

怎么用：

// 定义 Vector Search Index（在 Atlas 界面配置）
{
  "fields": [
    {
      "type": "vector",
      "path": "embedding",
      "numDimensions": 384,
      "similarity": "cosine"
    }
  ]
}

// 查询（MongoDB 聚合语法）
db.documents.aggregate([
  {
    $vectorSearch: {
      index: "vector_index",
      path: "embedding",
      queryVector: [0.1, 0.2, ...],
      numCandidates: 100,
      limit: 5
    }
  }
])

优点：

✅ 文档与向量同存：一条记录里包含内容、元数据、向量，不用分开管理。
✅ 灵活 Schema：随时加字段，不像 SQL 那样要改表结构。
✅ Atlas 云托管：不用自己运维向量索引。

缺点：

⚠️ 自建 MongoDB（非 Atlas）向量能力有限。
⚠️ Atlas 是云服务，国内访问可能有延迟。

结论：MongoDB 用户、Atlas 云用户的便捷选择。

📊 六路选手横向对比

方案	上手难度	数据规模	混合检索	事务支持	运维成本	适合谁
FAISS	⭐⭐⭐	亿级	❌	❌	低	算法研究者
Chroma	⭐	十万级	❌	❌	低	个人/Demo
Milvus	⭐⭐⭐	千亿级	✅	❌	中高	企业大项目
Elasticsearch	⭐⭐	百万级	✅	❌	中	有 ES 生态的公司
PostgreSQL	⭐⭐	百万级	❌	✅	低	PG 重度用户
MongoDB	⭐⭐	百万级	❌	✅	低（Atlas）	文档型场景