同样RAG，换个Embedding召回率从62%飙升到89%

前两篇讲了RAG的核心原理和文档切分，这篇进入RAG的"心脏"——Embedding和向量数据库。

你可能觉得Embedding不就是调个API把文本转成向量嘛，选哪个都差不多。我之前也是这么想的，直到我在一个金融知识库项目里换了Embedding模型，检索准确率直接从62%涨到89%。同样的切分、同样的提示词、同样的模型，就换了个Embedding，效果天差地别。

Embedding模型决定了你的向量空间长什么样，向量数据库决定了你能不能高效地在这个空间里搜索。 这两个选对了，检索的天花板才够高。

Embedding是什么？30秒说清楚

Embedding就是把文本映射成一组数字（向量），语义相近的文本在向量空间里距离近，语义远的距离远。

"苹果手机" → [0.12, -0.34, 0.56, ...]  ← 跟下面距离近
"iPhone"   → [0.15, -0.31, 0.52, ...]  ← 跟上面距离近
"水果店"   → [-0.23, 0.45, -0.12, ...] ← 跟上面距离远

RAG的检索就是：把用户问题转成向量，在向量空间里找距离最近的文档向量。Embedding模型的质量直接决定了"距离近"是否等于"语义相关"。

主流Embedding模型对比

英文为主的开源模型

中文为主的开源模型

商用API模型

我的推荐

中文项目无脑选bge-m3。原因：

1. 多语言：中英混排的文档也能处理，不用分语言建库
2. 长上下文：8192 tokens，比bge-large-zh的512长了16倍
3. 多功能：同时支持稠密检索、稀疏检索、多向量检索
4. 免费开源：本地部署，数据不出境

from langchain_community.embeddings import HuggingFaceBgeEmbeddings

embedding = HuggingFaceBgeEmbeddings(
    model_name="BAAI/bge-m3",
    model_kwargs={"device": "cuda"},  # 有GPU用GPU，没有用cpu
    encode_kwargs={"normalize_embeddings": True},  # 归一化，余弦相似度
)

英文项目或追求极致方便：用OpenAI的text-embedding-3-small，调API就行。

from langchain_openai import OpenAIEmbeddings

embedding = OpenAIEmbeddings(model="text-embedding-3-small")

向量数据库选型：6个主流方案对比

我的选择建议

开发阶段：Chroma或FAISS

# Chroma：最简单
from langchain_community.vectorstores import Chroma

vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=embedding,
    persist_directory="./chroma_db",
)

# FAISS：最快
from langchain_community.vectorstores import FAISS

vectorstore = FAISS.from_documents(chunks, embedding)
vectorstore.save_local("./faiss_db")

生产环境：Milvus或Qdrant

# Milvus
from langchain_community.vectorstores import Milvus

vectorstore = Milvus.from_documents(
    documents=chunks,
    embedding=embedding,
    connection_args={"host": "localhost", "port": "19530"},
    collection_name="knowledge_base",
)

已有PostgreSQL：pgvector，不用额外部署新服务

Java类比：向量数据库选型就像你选缓存方案——开发阶段用HashMap或Caffeine（Chroma/FAISS），生产环境上Redis集群（Milvus/Qdrant），如果已经有了Redis就不折腾别的（pgvector）。别一上来就上Milvus，就像你不会在本地开发用Redis集群一样。

from langchain_community.vectorstores import PGVector

vectorstore = PGVector.from_documents(
    documents=chunks,
    embedding=embedding,
    connection_string="postgresql://user:pass@localhost:5432/vectordb",
)

向量检索的三种方式

1. 余弦相似度（最常用）

衡量两个向量方向的一致性，值域[-1, 1]，1表示完全相同：

results = vectorstore.similarity_search(
    query="年假怎么申请",
    k=5,  # 返回最相似的5个文档
)

2. MMR（最大边际相关性）

兼顾相关性和多样性——避免返回5个内容几乎一样的chunk：

results = vectorstore.max_marginal_relevance_search(
    query="年假怎么申请",
    k=5,
    fetch_k=20,  # 先取20个候选
    lambda_mult=0.5,  # 0=最大多样性，1=最大相关性
)

当你的检索结果重复度很高时，MMR特别管用。

3. 相似度+分数阈值

只返回相似度高于某个阈值的结果，过滤掉不太相关的：

results = vectorstore.similarity_search_with_relevance_scores(
    query="年假怎么申请",
    k=10,
    score_threshold=0.7,  # 只返回分数>0.7的
)

向量库的增量更新

知识库不是一成不变的，文档会更新、新增、删除。

新增文档

# 加载新文档
new_docs = loader.load()
new_chunks = splitter.split_documents(new_docs)

# 追加到现有向量库
vectorstore.add_documents(new_chunks)

删除文档

# Chroma
vectorstore._collection.delete(
    where={"source": "old_policy.pdf"}  # 按元数据删除
)

# Milvus
vectorstore.delete(expr='source == "old_policy.pdf"')

生产环境的增量更新策略

不要每次更新都重建整个向量库，太慢了。推荐方案：

1. 给每个文档分配唯一ID（如文件名的哈希值）
2. 更新时：删旧版本的chunk → 加新版本的chunk
3. 用定时任务扫描文档目录，自动检测变更
4. 大规模更新时用批量写入（batch insert），别一条条加

我踩过的向量库坑

1. Embedding维度不一致

你换了Embedding模型，向量维度变了，旧的向量库就不能用了。建议在项目初期就确定好Embedding模型，后续不要换。如果必须换，就得重建整个向量库。

2. 没有做归一化

余弦相似度要求向量是归一化的。有些Embedding模型输出的向量没归一化，直接算余弦相似度结果不对。解决：在encode_kwargs里加"normalize_embeddings": True。

3. 中文Embedding用错了模型

用英文为主的Embedding（如text-embedding-ada-002）处理中文文档，检索效果惨不忍睹。中文项目一定要用bge-m3或bge-large-zh这类中文优化的模型。

4. FAISS持久化路径问题

FAISS保存和加载时路径要一致，而且它会生成多个文件（.faiss + .pkl），移动时别漏了。