向量数据库选型指南：RAG场景下如何选对存储与检索
本文目录
- 向量库在RAG中的真实角色
- 选型要看的六项能力
- 常见产品形态对比
- 规模与成本粗算
- 与关键词检索如何配合
- 落地检查清单
做RAG时，很多人第一反应是「先上一个向量数据库」。结果往往是：Demo能跑，权限过滤做不动，更新索引很痛苦，检索不准却归咎于模型。向量库是检索基础设施，不是魔法记忆；选型应围绕过滤、一致性、运维与成本，而不是参数榜。
一、向量库在RAG中的真实角色
向量库存储文档块的嵌入向量，并在查询时返回语义相近的Top-K结果。它不负责理解问题，也不保证答案正确。正确性取决于：切分质量、嵌入模型、混合检索、重排与生成约束（详见RAG详解）。
因此，向量库再强，也补不齐「文档没清洗」「权限没隔离」「没有评测集」。
二、选型要看的六项能力
- 元数据过滤：按租户、部门、文档类型、生效日期过滤；最好在检索时过滤，而不是召回后再丢弃。
- 混合检索：是否原生或易接入BM25/关键词，专有名词场景几乎必备。
- 更新与删除：文档变更后能否增量更新，删除是否及时对用户不可见。
- 一致性与多副本：写入后多久可查；故障切换是否可接受。
- 运维复杂度：托管还是自建；备份、监控、版本升级成本。
- 生态与锁定：SDK、迁移导出、与现有云账号集成。
若业务强依赖「按客户ACL检索」，过滤能力应排在「向量维度上限」之前。
三、常见产品形态对比
| 形态 | 例子方向 | 优点 | 代价 |
|---|---|---|---|
| 专用向量库/托管 | 各类云向量服务、开源向量引擎 | 上手快、检索API完整 | 成本随量涨、需评估锁定 |
| 在已有搜索上扩展 | Elasticsearch/OpenSearch等 | 关键词+向量一体、运维熟悉 | 向量性能与调参需经验 |
| 在已有数据库扩展 | PostgreSQL+pgvector等 | 事务与权限模型统一 | 超大规模需仔细设计 |
| 轻量本地库 | 嵌入式/单机方案 | 原型便宜 | 不适合多租户生产 |
没有绝对最优：百人团队内部知识库，用「已有PG/ES + 向量」往往更省；多租户SaaS高QPS，再评估专用引擎或托管。
四、规模与成本粗算
- 块数 ≈ 文档页数 × 每页块数（常见0.5–2）
- 存储 ≈ 块数 × 维度 × 每维字节（再加元数据与索引开销，通常×2以上）
- 查询成本：QPS × 延迟目标决定副本与缓存
- 隐藏成本：嵌入API费用、重建索引算力、人工清洗
建议先用Token估算控制块大小，再用小流量压测延迟，而不是一上来按「亿级向量」采购。
五、与关键词检索如何配合
政策编号、错误码、人名、SKU等，纯向量容易漏。生产推荐：向量召回 + 关键词召回 → 融合/重排。若向量库不支持混合，可在应用层并行查ES/DB再合并。
六、落地检查清单
- 是否按租户/权限在检索阶段过滤？
- 是否有文档版本与重建策略？
- 是否准备了黄金问题集评估召回？
- 删除/下架内容是否能在约定时间内不可检索？
- 是否监控空结果率、P95延迟、索引滞后？