向量库怎么选
选型看四个维度：数据规模、过滤需求、运维成本与既有技术栈。已有 PostgreSQL 且规模在百万级以内，用扩展方案最省事，事务与备份都沿用现有流程；需要强过滤与中大规模时用独立向量服务；到亿级且团队有运维能力再考虑分布式方案。要特别注意：检索引擎库不是数据库，它不负责持久化与并发写入。
基本信息
| 选型维度 | 数据规模、过滤与元数据查询、运维成本、与现有系统一致性 |
|---|---|
| 小规模首选 | 复用现有关系库的向量扩展，减少一套运维 |
| 中大规模 | 独立向量服务，支持强过滤与水平扩展 |
| 超大规模 | 分布式集群，需要专门的运维投入 |
| 库形态方案 | 仅作为进程内索引使用，不做持久化服务 |
| 关键指标 | 查询延迟分位值、召回率、写入吞吐 |
常见方案对照
| 方案 | 形态 | 适用 |
|---|---|---|
| 关系库向量扩展 | 数据库扩展 | 已有该数据库、要求事务一致、百万级以内 |
| 独立向量服务 | 独立部署的服务 | 强过滤需求、中大规模、接口友好 |
| 分布式向量集群 | 集群部署 | 亿级向量、需要水平扩展、有运维团队 |
| 进程内索引库 | 程序库 | 离线实验与批处理，不适合当在线服务 |
| 轻量嵌入式方案 | 随应用启动 | 原型验证与小型应用 |
典型使用场景
- 知识库问答：文档片段向量与元数据一起入库并检索
- 去重与相似推荐：按向量距离找近似内容
- 多条件检索：既要语义相似又要按业务字段过滤
- 增量更新：文档变更后局部重建向量
- 多租户隔离：按租户维度限制检索范围
向量扩展建表与检索
向量扩展建表与检索
CREATE EXTENSION IF NOT EXISTS vector; -- 启用向量扩展
CREATE TABLE docs (
id bigserial PRIMARY KEY,
content text,
meta jsonb, -- 业务字段，便于过滤
embedding vector(1024)
);
SELECT id, content FROM docs
WHERE meta->>'tenant' = 'A' -- 元数据过滤
ORDER BY embedding <=> :query_vec LIMIT 8; -- 按距离排序取前若干条选型前的验证方法
| 验证项 | 怎么做 | 判断标准 |
|---|---|---|
| 延迟 | 用真实数据量与过滤条件压测 | 看分位延迟而非平均值 |
| 召回 | 用标注好的问题集测命中率 | 召回不达标的方案直接排除 |
| 过滤能力 | 模拟组合条件查询 | 过滤后延迟是否可接受 |
| 写入 | 按实际更新频率测试增量写入 | 写入是否阻塞查询 |
| 运维 | 评估备份、扩容与故障恢复流程 | 团队是否有能力长期维护 |
先用真实数据与真实查询做基准测试，再决定要不要引入独立向量服务：多数项目的规模，现有数据库加向量扩展完全够用。
把索引库当数据库用是经典误区：进程重启后索引丢失，删除与更新也不方便，在线服务必须选带持久化的方案。