LangChain实战教程（16）：RAG知识库构建，向量模型选型、数据库选型与向量持久化

基于上一篇文章，来聊一下，在RAG中，怎么做向量数据库的选型和使用方法。

为什么需要向量数据库？

向量化后的文档片段，都是几百维、上千维的浮点数数组。

如果直接放在内存里，根本无法高效检索。

向量数据库能帮我们解决三个关键问题：

1. 存储：安全、持久地保存海量向量；

2. 检索：通过相似度算法（余弦、点积等）快速找到最接近的向量；

3. 扩展：支持 metadata 信息，方便做条件过滤，比如“只检索人事部的规章制度”。

---

Embedding 模型选型：一个容易被忽视的坑

选 embedding 模型时，要从「准确性 / 性能 / 成本 / 部署」四个维度考虑。但更重要的一点是：对一个向量索引，入库（indexing）和查询（query）必须使用兼容的 embedding 流程。 具体要求包括：

1. 同一模型与版本：理想情况是入库和查询使用完全相同的模型与版本（包括同样的 tokenizer/预处理）。不同模型通常位于不同向量空间，直接比较没有意义。

2. 相同的向量处理：入库与查询阶段必须统一是否做归一化（L2-normalize）、是否截断/填充、相似度度量（cosine vs dot）。

3. 维度匹配：不同模型输出维度可能不同，向量库索引一般要求固定维度，维度不一致会直接报错或导致错误结果。

4. 如果必须换模型：要么重建索引（推荐），要么建立新 collection 并切换路由，或做复杂的向量对齐/转换（工程复杂且易出错）。 小结：把 embedding 模型当成索引协议的一部分——一旦选择并入库，就视为系统的基础设置，变更要规划重建或并行方案。

---

向量数据库的选型

选择向量数据库，要结合业务场景和数据库的特性。主要可以从四个角度来考虑：

1. 易用性与生态

   1. 是否有成熟的 Python SDK？

   2. 和 LangChain、LlamaIndex 等框架的衔接是否方便？

   3. 是否支持常见的 embedding 向量维度（768、1024 等）？

2. 性能与功能

   1. 检索延迟（latency）是否满足需求？

   2. 是否支持不同的相似度度量（cosine / dot product / L2）？

   3. 是否支持 filter / metadata 检索，能不能加上业务属性条件？

   4. 是否支持 混合检索（向量 + 关键词）？

3. 部署与运维

   1. 本地嵌入式（如 Chroma）：轻量、无运维，适合原型和小项目。

   2. 独立数据库（如 Milvus、Weaviate）：需要单独服务部署，功能更丰富，适合企业级。

   3. 云服务（如 Pinecone、Qdrant Cloud）：免运维，但成本需要评估。

4. 数据规模与成本

   1. 小规模 + 单机 → Chroma（轻量、嵌入式）。

   2. 中规模 + 高可用 → Qdrant / Weaviate（自带 API 服务）。

   3. 大规模 + 云原生 → Milvus（分布式）、Pinecone（SaaS 托管）。

如果是在学习阶段，我比较推荐 Chroma，因为它零配置，开箱即用。能帮助我们快速理解 RAG 的完整流程

---

LangChain 的作用

在整个RAG过程中，LangChain 做了两件关键的事：

• 封装向量模型：无论是 HuggingFace 模型还是 OpenAI API，调用方式统一；

• 封装数据库接口：Chroma、Milvus、Pinecone，使用方法几乎一致。

这让我们不用关心底层实现，专注在业务逻辑上。

想要学习AI应用开发的同学，可以参照我的代码跑起来，举一反三，一天一个脚印的进步，我相信，会足够坚实。

如果你也想了解AI应用开发到底是什么，如果你也在考虑转型但还在犹豫，那就跟着我的记录，一起探索。

继续折腾中，有问题随时交流