做 RAG 知识库、语义搜索或 AI Agent 长期记忆，绕不开一个问题：向量存在哪里。选错向量数据库，轻则本地跑个 Demo 就要拉起三个容器，重则数据涨到千万级后检索延迟直接崩盘。本文横向实测 6 款完全免费（开源自托管）的向量数据库，从「本地嵌入式」到「分布式集群」全覆盖，并给出一条可直接套用的选型决策路径。
一、选向量数据库时，90% 的人踩的三个坑
在具体对比之前，先说清楚三个最常见的误判，它们比「谁的 QPS 高」重要得多：
- 把 Demo 场景当生产场景选型：几万条文档的个人知识库，用嵌入式方案（Chroma、LanceDB、pgvector）几行代码就能跑通；却有人一上来就部署分布式 Milvus 集群，运维成本远超收益。反过来，用纯内存方案硬扛千万级向量，也必然翻车。
- 忽略「带过滤条件的检索」：真实业务几乎不存在裸向量检索，通常是「在某个租户、某个时间范围、某个文档类型内做相似度检索」。不同引擎对 payload / metadata 过滤的实现差异极大，有的先过滤再检索（精确但慢），有的先近似检索再过滤（快但可能召回不足）。这才是线上效果差异的主因。
- 只看向量检索，不看混合检索：纯向量检索对专有名词、型号、错误码这类「字面命中」场景表现很差。生产级 RAG 基本都要 BM25 关键词检索 + 向量检索融合（Hybrid Search），选型时必须确认引擎是否原生支持稀疏向量或全文索引。
把这三点想清楚，再看下面的对比表，选型基本不会跑偏。关于 RAG 整体链路的搭建思路，可以先看这篇 大模型RAG知识库搭建实战教程 打底。
二、6款免费向量数据库横向对比
| 工具 | 形态 | 核心索引 | 混合检索 | 免费方式 | 推荐场景 |
|---|---|---|---|---|---|
| Chroma | 嵌入式 / 独立服务 | HNSW | 支持全文与元数据过滤 | Apache 2.0 开源，pip 安装即用 | 原型验证、个人知识库 |
| Qdrant | 独立服务 / 嵌入式 | HNSW + 量化 | 原生稀疏向量 + 融合查询 | Apache 2.0 开源，可自托管 | 生产级 RAG、复杂过滤 |
| Milvus | Lite / 单机 / 分布式 | HNSW、IVF、DiskANN | 支持稀疏向量与多路召回 | Apache 2.0 开源，Lite 版零依赖 | 亿级规模、企业检索 |
| pgvector | PostgreSQL 扩展 | HNSW、IVFFlat | 与 tsvector 全文检索天然结合 | 开源扩展，复用现有 PG | 已有 PG 的业务系统 |
| Weaviate | 独立服务 | HNSW（支持 flat / 动态） | 原生 Hybrid Search（BM25+向量） | BSD 开源，可自托管 | 需要开箱即用混合检索 |
| LanceDB | 嵌入式 / 对象存储原生 | IVF-PQ 等磁盘索引 | 支持全文索引与过滤 | Apache 2.0 开源，pip 安装即用 | 多模态、大数据集低成本 |
表格里「免费方式」一栏统一指开源自托管路径——这 6 款都能在自己机器上零成本跑起来。各家官方云服务的免费额度会随政策调整，本文不做承诺，以官网当前页面为准。
三、逐款实测与边界说明
1. Chroma：上手最快，适合把想法先跑通
Chroma 的设计目标非常明确：让开发者用最少的代码把向量检索跑起来。安装后不需要任何外部依赖，直接在本地目录持久化：
pip install chromadb
import chromadb
client = chromadb.PersistentClient(path="./kb")
col = client.get_or_create_collection("docs")
col.add(documents=["向量数据库用于语义检索", "HNSW 是常用的近似最近邻索引"],
metadatas=[{"src": "a"}, {"src": "b"}],
ids=["1", "2"])
print(col.query(query_texts=["什么是近似最近邻"], n_results=2))
实测体验：不传向量时它会自动调用内置的默认嵌入模型，首次运行会下载模型文件，之后完全离线可用。这一点对个人知识库非常友好——不需要先申请任何 API Key。
边界：单机嵌入式形态在数据量上到百万级以上时，内存占用和写入吞吐会成为瓶颈；多进程并发写同一个持久化目录也不是它擅长的场景。定位清晰：先验证效果，跑通了再考虑迁移。
2. Qdrant：过滤条件复杂时的首选
Qdrant 用 Rust 编写，最大的差异化在于 payload 过滤与向量检索是深度耦合的——它在 HNSW 图遍历过程中就应用过滤条件，而不是先检索完再丢弃结果。这直接决定了「多租户 + 强过滤」场景的召回质量。
docker run -p 6333:6333 -v $(pwd)/qdrant_data:/qdrant/storage qdrant/qdrant
from qdrant_client import QdrantClient, models
c = QdrantClient(url="http://localhost:6333")
c.create_collection("docs",
vectors_config=models.VectorParams(size=1024, distance=models.Distance.COSINE))
c.query_points("docs", query=[0.1]*1024, limit=5,
query_filter=models.Filter(must=[
models.FieldCondition(key="tenant", match=models.MatchValue(value="t1"))]))
亮点：官方支持标量量化与二值量化，把 float32 压成低精度表示后内存占用可显著下降，配合原始向量重打分（rescoring）可以在精度损失可控的前提下大幅降本；同时原生支持稀疏向量，做 BM25 风格的混合检索不需要额外挂一个搜索引擎。官方还提供了嵌入式的 Edge 形态和 MCP Server，方便直接接进 AI 客户端。
边界：单机自托管非常省心，但分布式分片与副本的运维仍需要自己规划；Docker 部署时记得挂载持久化卷，否则容器重建数据即丢失。容器编排不熟的话，可以配合 AI Dockerfile生成工具 快速产出规范配置。
3. Milvus：从 Lite 到集群的一条平滑路径
Milvus 最被低估的能力是「形态可伸缩」：同一套 pymilvus API，本地开发用 Milvus Lite（一个本地文件，零外部依赖），中等规模用 Standalone（Docker 单机），大规模再切到 Kubernetes 分布式集群，业务代码几乎不用改。
pip install -U pymilvus
from pymilvus import MilvusClient
client = MilvusClient("./milvus_demo.db") # 本地文件即 Milvus Lite
client.create_collection(collection_name="docs", dimension=768)
client.insert(collection_name="docs", data=[{"id": 1, "vector": [0.1]*768, "text": "hello"}])
client.search(collection_name="docs", data=[[0.1]*768], limit=3)
亮点：索引类型最全，HNSW 之外还有 IVF 系列与 DiskANN（把索引放磁盘，用有限内存扛超大数据集），并支持 GPU 索引。数据量确定会长到亿级时，它是运维复杂度换扩展性的标准答案。
边界：完整版依赖 etcd、对象存储、消息队列等组件，自建集群的心智负担明显高于 Qdrant/Weaviate；Milvus Lite 主要面向开发与小规模场景，别拿它跑生产。
4. pgvector：已经有 PostgreSQL 的团队不用犹豫
pgvector 是 PostgreSQL 扩展，把向量当成一种字段类型，检索直接写 SQL。对绝大多数中小业务，这是综合成本最低的方案——不用新增一套存储、不用做双写、事务和备份策略全部复用现有体系。
CREATE EXTENSION vector;
CREATE TABLE docs (id bigserial PRIMARY KEY, content text, embedding vector(768));
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops);
SELECT id, content
FROM docs
WHERE tenant_id = 42
ORDER BY embedding <=> '[0.1, 0.2, ...]'
LIMIT 5;
亮点：支持 HNSW 与 IVFFlat 两类索引，距离运算符可选余弦、L2、内积；由于跑在关系库里，向量检索能和 JOIN、事务、行级权限、tsvector 全文检索自由组合，做混合检索非常自然。
边界：索引构建对 maintenance_work_mem 敏感，参数给小了建索引会慢到怀疑人生；数据量很大时召回率受 ef_search / probes 等参数影响明显，要针对业务做调参。别忘了向量检索也是查询，执行计划同样需要观察，必要时结合 AI SQL慢查询优化工具 排查索引是否真的被用上。表结构设计阶段则可以参考 AI数据库设计工具 的思路。
5. Weaviate：混合检索开箱即用
Weaviate 的定位是「带 AI 能力的搜索引擎」，最大卖点是原生 Hybrid Search：一次查询同时跑 BM25 关键词检索和向量检索，再用融合算法合并排序，只需要一个 alpha 参数控制两者权重。
collection.query.hybrid(
query="Nginx 502 错误排查",
alpha=0.5, # 0=纯关键词，1=纯向量
limit=5
)
亮点：模块化设计，向量化、重排序（reranker）、生成式回答都能以模块形式挂载，「存文本进去、直接问问题出来」的链路可以在服务端闭环；对多租户也有原生支持。
边界：概念抽象度较高（collection、property、模块配置），初学者上手曲线比 Chroma 陡；若只做纯向量检索，它的功能会显得偏重。
6. LanceDB：对象存储原生，大数据集成本最低
LanceDB 基于 Lance 列式格式（Apache Arrow 生态），最特别的是数据可以直接放在 S3 / OSS 这类对象存储上，计算节点无状态。对「数据量大但查询频次不高」的场景，这种存算分离形态的成本优势非常明显。
pip install lancedb
import lancedb
db = lancedb.connect("./lance_db") # 也可以填 s3://bucket/path
tbl = db.create_table("docs", data=[{"vector": [0.1]*768, "text": "hello"}])
tbl.search([0.1]*768).limit(5).to_pandas()
亮点：嵌入式使用，无需起服务；对多模态数据（图片、音频、视频帧）友好，能把原始数据和向量放在同一张表里；支持磁盘索引，不要求把全部向量塞进内存。
边界：生态成熟度不如 Milvus / Qdrant，高并发在线服务场景的实践案例相对少；跑在对象存储上时首次查询有冷启动延迟，对毫秒级实时检索要求高的场景需要实测确认。
四、一条能直接套用的选型决策路径
- 你已经在用 PostgreSQL，且向量量级在百万以内 → 直接上 pgvector，不要引入新组件。这是最省人力的答案。
- 还在验证效果、数据在十万条以内 → Chroma 或 LanceDB，pip 装完就能写代码，跑通再说。
- 要上生产，过滤条件复杂（多租户 / 权限 / 时间范围） → Qdrant，过滤与检索耦合的设计在这类场景优势最大。
- 检索质量强依赖关键词命中（型号、错误码、专有名词） → Weaviate 的原生 Hybrid Search 最省事，Qdrant 的稀疏向量方案次之。
- 数据确定会长到亿级，且有专职运维 → Milvus 分布式，用运维复杂度换扩展天花板。
- 数据量大但查询稀疏，想压存储成本 → LanceDB + 对象存储。
补充一条容易被忽略的原则：先固定嵌入模型，再选数据库。检索效果的上限由嵌入模型质量决定，数据库只决定这个上限能不能在可接受的延迟和成本内兑现。换模型意味着全量重新嵌入，代价远大于换数据库。本地跑嵌入模型的方案可以参考 AI本地部署工具免费版推荐。
五、30 分钟跑通一个最小 RAG 检索
- 准备语料（5 分钟）：先用 30～50 篇文档做验证，别一上来就灌全量数据。文档来源如果需要抓取，可参考 AI爬虫工具免费推荐。
- 切分文本（5 分钟）：按语义段落切，单块控制在 300～800 字，块间保留 10%～15% 重叠，避免答案被切在两块中间。
- 生成向量（5 分钟）：选一个中文表现稳定的嵌入模型，记录下模型名与向量维度——这两个值后面建表时要用，且必须全程一致。
- 写入并建索引（5 分钟）：先写数据再建 HNSW 索引，比边写边建快得多；建索引前把内存参数调足。
- 验证召回（10 分钟）：准备 20 条真实业务问题，人工标注期望命中的文档，跑一遍统计 Top-5 命中率。低于 60% 时先怀疑切分策略和嵌入模型，而不是急着换数据库。
把这套检索接进 Agent 时，工具调用的参数 Schema 可以用 AI Function Calling生成工具 快速产出；多步任务的编排思路参考 AI Agent任务拆解规划工具；如果目标是给 AI 助手加长期记忆，AI记忆与上下文管理工具 里的方案可以直接复用。
六、五条能少踩坑的实践纪律
- 向量维度写进配置，不要硬编码：换模型时维度必变，硬编码会让迁移变成全局搜索替换。数据库连接串与 API Key 一律走环境变量管理，做法见 AI环境变量与密钥管理工具。
- metadata 里必须存原文定位信息：文档 ID、块序号、原始 URL 一个都不能少，否则检索出来的结果无法回溯，用户也没法验证答案来源。
- 过滤字段要单独建索引：Qdrant 的 payload index、pgvector 场景下的普通 B-tree 索引，都需要显式创建，否则过滤会退化成全表扫描。
- 建立召回评测集并纳入回归：每次改切分策略、换模型、调参数，都跑一遍固定的 20～50 条问题集，用数字判断好坏，别靠感觉。检索异常时结合 AI日志分析工具 定位是嵌入服务超时还是索引未命中。
- 提前规划重建索引的窗口：嵌入模型升级、维度变更、大批量删除后的索引膨胀，都需要重建。把这件事当成常规运维项，而不是事故处理。
七、常见问题
Q1：非要上专用向量数据库吗？用 numpy 暴力检索行不行？
几千条以内完全可以，暴力检索的召回率是 100%。到十万条量级时延迟就无法接受了，这时才需要 ANN 索引。别为了「技术看起来先进」提前引入复杂度。
Q2：HNSW 和 IVF 到底怎么选？
HNSW 查询快、召回高，但内存占用大、构建慢；IVF 系列构建快、内存友好，召回依赖聚类质量和探测数量。内存够就用 HNSW，数据量大到内存放不下时考虑 IVF-PQ 或 DiskANN 这类磁盘索引。
Q3：混合检索的权重怎么定？
从 alpha=0.5 起步，用自己的评测集扫 0.3 / 0.5 / 0.7 三个点。专有名词多的场景（技术文档、商品型号）关键词权重要高，问答式、口语化查询多的场景向量权重要高。
Q4：向量数据要不要做备份？
要，但备份的重点是原始文档和 metadata。向量本身是可再生的——只要嵌入模型和切分逻辑没变，随时可以重新生成。真正不可再生的是原文与业务字段。
Q5：知识图谱和向量检索冲突吗？
不冲突，是互补关系。向量检索擅长模糊语义匹配，知识图谱擅长精确的多跳关系推理，成熟方案常常两者并用，具体做法可参考 AI知识图谱构建工具。
八、总结
向量数据库选型没有唯一答案，但有清晰的判断顺序：先看现有技术栈（有 PG 就用 pgvector），再看数据规模（十万以内嵌入式、百万到千万单机服务、亿级才上分布式），最后看检索特征（强过滤选 Qdrant、强关键词选 Weaviate）。这 6 款全部开源免费，本地起一个跑真实语料，一小时就能得到比任何评测文章都可靠的结论。
最后提醒一句：向量数据库只是 RAG 链路里的一环，检索效果差的时候，八成问题出在文本切分和嵌入模型上，而不是数据库本身。先把评测集建起来，再谈优化。
相关阅读
版权声明
本文仅代表个人观点。
本文系AI辅助作者原创，未经许可，转载请保留原文链接。
发表评论