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

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

为什么需要向量数据库？

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

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

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

1. 1. 存储：安全、持久地保存海量向量；
2. 2. 检索：通过相似度算法（余弦、点积等）快速找到最接近的向量；
3. 3. 扩展：支持 metadata 信息，方便做条件过滤，比如“只检索人事部的规章制度”。

Embedding 模型选型 — 一个容易被忽视的坑（修正版本）

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

1. 1. 同一模型与版本：理想情况是入库和查询使用完全相同的模型与版本（包括同样的 tokenizer/预处理）。不同模型通常位于不同向量空间，直接比较没有意义。
2. 2. 相同的向量处理：入库与查询阶段必须统一是否做归一化（L2-normalize）、是否截断/填充、相似度度量（cosine vs dot）。
3. 3. 维度匹配：不同模型输出维度可能不同，向量库索引一般要求固定维度，维度不一致会直接报错或导致错误结果。
4. 4. 如果必须换模型：要么重建索引（推荐），要么建立新 collection 并切换路由，或做复杂的向量对齐/转换（工程复杂且易出错）。 小结：把 embedding 模型当成索引协议的一部分——一旦选择并入库，就视为系统的基础设置，变更要规划重建或并行方案。

向量数据库的选型

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

1. 1. 易用性与生态
1. 1. 是否有成熟的 Python SDK？
2. 2. 和 LangChain、LlamaIndex 等框架的衔接是否方便？
3. 3. 是否支持常见的 embedding 向量维度（768、1024 等）？
2. 2. 性能与功能
1. 1. 检索延迟（latency）是否满足需求？
2. 2. 是否支持不同的相似度度量（cosine / dot product / L2）？
3. 3. 是否支持 filter / metadata 检索，能不能加上业务属性条件？
4. 4. 是否支持 混合检索（向量 + 关键词）？
3. 3. 部署与运维
1. 1. 本地嵌入式（如 Chroma）：轻量、无运维，适合原型和小项目。
2. 2. 独立数据库（如 Milvus、Weaviate）：需要单独服务部署，功能更丰富，适合企业级。
3. 3. 云服务（如 Pinecone、Qdrant Cloud）：免运维，但成本需要评估。
4. 4. 数据规模与成本
1. 1. 小规模 + 单机 → Chroma（轻量、嵌入式）。
2. 2. 中规模 + 高可用 → Qdrant / Weaviate（自带 API 服务）。
3. 3. 大规模 + 云原生 → Milvus（分布式）、Pinecone（SaaS 托管）。

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

LangChain 的作用

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

• • 封装向量模型：无论是 HuggingFace 模型还是 OpenAI API，调用方式统一；
• • 封装数据库接口：Chroma、Milvus、Pinecone，使用方法几乎一致。

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