面经策

LangChain 支持哪些向量数据库？如何选择？ ​

  • 标签：LangChain、向量数据库

🏛 业务架构师 ​

LangChain 支持的向量数据库覆盖主流产品：Milvus/Zilliz、Chroma、Qdrant、Weaviate、Pinecone、pgvector（PostgreSQL）、Elasticsearch、Redis、FAISS（内存库，本地实验）等——统一走 VectorStore 接口，切换成本接近零。

怎么选，我按业务阶段给决策树：

  1. POC/开发期：Chroma 或 FAISS——嵌入式零运维，pip 装完就能跑；数据百万以内、已有 PostgreSQL 的团队直接 pgvector，连新组件都不用引入；
  2. 单业务生产（百万级向量）：pgvector 依然是性价比之王（事务、权限、备份复用数据库生态）；要更高性能再考虑 Qdrant/Weaviate 单机；
  3. 多业务共享/亿级向量/高 QPS：Milvus 集群——存算分离、水平扩展，国产开源生产案例最多；
  4. 海外团队免运维：Pinecone（SaaS）；数据合规敏感的国内企业排除 SaaS 路线。

选型的四个硬指标：数据规模与增长预期、QPS 与延迟 SLA、运维能力储备（有没有团队养分布式组件）、合规约束。软指标：与现有技术栈亲和度（Java 团队可用 Spring AI 生态的集成）。

我的劝诫：别在 POC 期就上分布式向量库——运维成本会吃掉迭代速度；也别低估元数据过滤和权限能力的重要性，很多业务事故（越权召回）根因是选型时只看了向量性能没看过滤能力。先用最简单的跑通业务，用数据证明需要升级再升级。

🏗 系统架构师 ​

LangChain 支持的向量库覆盖主流全谱系，选型我按**"规模 × 运维成本 × 能力需求"**决策：

支持范围：PGVector（Postgres）、Chroma、FAISS（本地索引库）、Milvus、Qdrant、Weaviate、Pinecone、ElasticSearch/OpenSearch、Redis（向量搜索）、LanceDB 等——通过 VectorStore 统一抽象接入，切换成本一行初始化代码（但数据迁移是另一回事）。

选型决策树：

  • 已有 Postgres + 向量 <5000 万 → PGVector：不引入新存储，事务/权限/备份复用，TCO 最优；QPS 高时注意 HNSW 索引的内存与并发调优；
  • PoC / 单机 / 百万级以内 → Chromroma 或 FAISS：零运维，快验证（FAISS 是库不是服务，生产要自己包一层）；
  • 亿级以上 / 多租户 / 高 QPS → Milvus（分布式全功能，运维重）或 Qdrant（部署轻、过滤性能好）；
  • 不想运维 → Pinecone 或云托管（成本高，数据合规要审）；
  • 已有 ES/OpenSearch 且要混合检索 → 直接用它的 kNN + BM25，一套系统两路检索。

架构师提醒三点：

  • 抽象泄漏：LangChain 的统一接口只覆盖基本操作，各库特性（量化、分区、标量索引细节）要用原生客户端——别指望零成本切换，接口层自己包薄封装；
  • 容量公式先算：内存 ≈ 条数 × 维度 × 4B（float32），量化可省 4~10 倍——先估算再选型；
  • 评估先行：拿自己语料跑 recall@K 对比，各库的索引参数默认值差异会带来 5~10 个点的召回差。

💻 全栈开发专家 ​

LangChain 系支持的主流向量库（生态内有官方/社区集成包）：

  • PGVector：PostgreSQL 扩展，事务+元数据过滤+向量一站式；
  • Milvus：大规模自建首选，亿级向量、GPU 索引、多副本；
  • Qdrant：Rust 实现，性能好、payload 过滤强、部署简单；
  • Chroma：嵌入式轻量库，原型开发标配；
  • Weaviate：模块化、混合检索、多租户；
  • Elasticsearch/OpenSearch：BM25+dense 混合检索，已有 ES 团队首选；
  • Redis/RediSearch：超低延迟在线场景；
  • FAISS：Facebook 的库级引擎（不是服务），适合嵌入自有进程做研究；
  • 云托管：Pinecone、各云厂商托管向量库。

选型决策线（我的实操顺序）：

  1. 已有 PG 且数据量 < 千万级 → PGVector（运维零成本，元数据过滤与业务 Join 天然打通）；
  2. 全新部署、中小规模 → Qdrant（单二进制，Docker 一行起）；
  3. 亿级向量、专职运维团队 → Milvus；
  4. 强需求混合检索且已有 ES → Elasticsearch 8+；
  5. 原型/Demo → Chroma，但设计时用 Retriever/VectorStore 抽象隔离，方便换；
  6. 海外业务免运维 → Pinecone。

两个工程提醒：一是 LangChain 的 VectorStore 接口屏蔽了差异，但索引参数、过滤语法、距离度量各库不同，迁移成本真实存在，选型一次到位；二是压测再上线——不同库在不同数据规模/过滤条件下性能曲线差异巨大，拿自己的数据跑一轮「召回率-延迟」测试再做决定。