向量数据库怎么选？

详细解析#

几类方案#

原型阶段也可以用 FAISS 这类向量检索库，或者 Chroma、LanceDB 这类嵌入式的向量库，但要留意它们在持久化、过滤和并发写入上的能力差异。

选型要考虑什么#

规模可以先粗算：向量本身的存储 = 条数 × 维度 × 4 字节（float32）。假设有 100 万条 1024 维的向量，原始数据约 4 GB；HNSW 这类索引还要额外存储图结构，而且通常要放在内存里才快（原理见 HNSW 和 IVF）。

一个实用的决策顺序#

1. 已经在用 PostgreSQL，估算下来单机放得下 → pgvector
2. 已经有 Elasticsearch/OpenSearch，关键词检索很重要 → 直接用它做混合检索
3. 数据量大、查询压力高，需要多种索引和量化 → 专用向量数据库
4. 团队没有精力运维 → 托管服务

不管选哪个，都在业务代码和数据库之间封装一层检索接口（如 search(query, filters, k)），以后换库只需要改这一层。

代码示例#

用 pgvector 存储和检索，语法以 pgvector 官方文档为准：

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunks (
  id        bigserial PRIMARY KEY,
  doc_id    bigint NOT NULL,
  dept      text NOT NULL,           -- 权限过滤用
  content   text NOT NULL,
  embedding vector(1024) NOT NULL    -- 维度要和 Embedding 模型的输出一致
);

-- HNSW 索引，使用余弦距离
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);

-- 查询时的候选数（默认 40），调大召回更高、查询更慢
SET hnsw.ef_search = 100;

-- <=> 是余弦距离，越小越相似；1 - 距离 就是余弦相似度
SELECT id, doc_id, content, 1 - (embedding <=> $1) AS similarity
FROM chunks
WHERE dept = $2
ORDER BY embedding <=> $1
LIMIT 5;

面试官可能追问#

易错点#

• 把向量库当成效果的决定因素：检索效果主要取决于切分、Embedding 模型和检索策略，向量库决定的是规模、性能和运维成本
• 只存向量，不存原文和元数据，检索后还要回查，也没法按条件过滤
• 建索引用的距离度量和查询用的不一致，索引就用不上；比如 pgvector 的余弦索引（vector_cosine_ops）只对 <=> 运算符生效
• 拿别人的基准测试数字做决定，没有用自己的数据量、维度和过滤条件压测