一、RAG 不是「接个向量库就完事」

RAG（检索增强生成）的目标，是让模型在回答前先拿到可引用的私有知识。向量数据库只是检索层的一种实现；从 0 到 1，你还要定：文档切分、嵌入模型、召回策略、重排、引用格式与更新流水线。本文聚焦最容易卡住的决策：向量数据库怎么选。

二、先分清你的数据规模与约束

  • 个人/小团队 PoC：万级～十万级切片，单机可接受
  • 业务内测：百万级切片，要备份、要权限、要增量更新
  • 生产多租户：隔离、SLA、水平扩展、审计

约束不同，选型结论完全不同；别用「排行榜第一」替代自己的规模判断。

三、常见选项对比（工程视角）

  • Chroma：上手快，适合本地 Demo；生产要评估持久化与运维边界。
  • FAISS：检索性能强，偏库而非「带服务的数据库」；常嵌在应用进程中。
  • Milvus / Zilliz：面向规模化检索，生态完整；运维与资源成本更高。
  • Qdrant：过滤条件友好，部署相对清晰，中小团队常用。
  • pgvector（PostgreSQL）：已有 Postgres 时很香，运维统一；超大规模向量可能要拆分。
  • 云厂商托管向量检索：省运维，注意数据出境、锁定与计费模型。

四、选型时盯住这 6 个问题

  1. 是否需要元数据过滤（按租户、目录、权限）？
  2. 更新是全量重建还是增量 upsert？
  3. 是否要混合检索（关键词 + 向量）？
  4. 延迟目标是多少（P95）？
  5. 备份/迁移成本能否接受？
  6. 与 Agent 工具调用如何集成（同步检索还是异步预取）？

五、从 0 到 1 的推荐路径

  1. 第 1 周：选 pgvector 或 Qdrant/Chroma 之一，跑通「切分 → 嵌入 → 召回 → 生成」。
  2. 第 2 周：加引用片段与「答不上来就说不知道」；评估召回命中率。
  3. 第 3 周：再决定是否上重排模型、混合检索或迁更大规模引擎。

过早上分布式向量集群，通常不如先把切分质量与评测集做好。

六、和 Agent 的关系

对 Agent 来说，向量库往往以「检索工具」出现。工具要返回：标题、链接/路径、片段、分数；并限制返回条数，避免把上下文塞爆。RAG 稳了，Agent 才会少幻觉、少瞎调用。

七、小结

向量数据库没有万能答案：小团队优先运维简单 + 过滤好用；已有 Postgres 优先 pgvector；明确要规模化再上 Milvus/Qdrant 集群。从 0 到 1，先闭环，再优化检索质量，最后才是「换更贵的引擎」。