Embedding 模型选型与文本向量化实战：RAG 检索质量基石

Embedding 模型（文本向量化模型）是 RAG 检索系统的地基：它把”苹果手机”和”iPhone”映射到相近的向量，让语义检索替代死板的关键词匹配。很多团队 RAG 效果差，根因不在大模型，而在 Embedding 选错或向量化姿势不对。本文讲清 Embedding 的原理、主流模型横评，并给出可落地的文本向量化代码与选型清单。

在动手搭 RAG 之前，先想清楚一个事实：用户问”电池续航差怎么解决”，知识库里写的是”设备满电状态下持续使用时间偏短的处理建议”。这两者没有任何共同关键词，却能表达同一件事——只有 Embedding 才能把它们拉到一起。所以检索召回的质量，几乎完全由 Embedding 模型决定，大模型只是下游的”二传手”。

一、什么是 Embedding：把文本变成可计算的向量

Embedding 本质是一个神经网络映射函数 f(text) → ℝⁿ，把一段文本压成一个 n 维稠密向量。关键不在”维度高”，而在”语义相近的文本，向量也相近”。这种相近通常用余弦相似度衡量：两个向量夹角越小，语义越接近。训练时模型在海量文本对上学习”哪些句子该靠近、哪些该远离”，于是向量空间里天然形成了语义拓扑。

和传统的 TF-IDF / BM25 关键词检索相比，Embedding 检索有两个质变：① 跨表述——同义改写也能召回；② 跨语言——中英混排时”手机”和”phone”在向量空间里彼此靠拢。代价是它看不见精确的术语匹配，所以生产 RAG 往往是”稠密向量检索 + 稀疏关键词检索”混合，再用重排序收口（详见 RAG 混合检索与重排序优化）。

二、为什么 Embedding 选型决定 RAG 上限

1. 维度不是越大越好

维度越高，表达能力越强，但存储和检索成本也线性上涨。1024 维在中文场景已经非常够用，3072 维的 text-embedding-3-large 主要在超长、多语言、强区分需求下才显优势。盲目上高维，向量库体积和查询延迟都会吃亏，而召回收益未必成正比。

2. 归一化与相似度口径必须一致

绝大多数现代 Embedding 在输出时已经做了 L2 归一化（向量模长=1），此时”点积”和”余弦相似度”数值等价，向量库里用内积检索最快。如果你自己又额外归一化一次、或混用了不同归一化策略的模型，相似度会失真。务必保证检索端和入库端的向量来自同一模型、同一预处理。

三、主流 Embedding 模型横评

一句话结论：中文知识库优先 bge 系列；要私有化且不依赖外网就选 bge-large-zh 或 m3e；做出海或跨语言召回用 bge-m3（它同时输出稠密、稀疏、colbert 三种向量，能直接做混合检索）；已有 OpenAI 体系且不在意成本，text-embedding-3 系列最省心。具体怎么落，看第七节决策清单。

四、文本向量化实战

1. 调用 OpenAI 兼容接口（硅基流动 / 智谱 / 阿里云均可）

国内很多平台都提供了 OpenAI 兼容的 embeddings 端点，换 base_url 即可，代码零改动：

from openai import OpenAI

client = OpenAI(
    api_key="sk-xxx",
    base_url="https://api.openai-compatible.com/v1"  # 换成你的服务商地址
)

def embed(texts):
    resp = client.embeddings.create(
        model="BAAI/bge-large-zh-v1.5",  # 或 text-embedding-3-large
        input=texts
    )
    return [d.embedding for d in resp.data]

vec = embed(["苹果手机续航怎么样", "iPhone 电池表现如何"])
print(len(vec[0]))   # 向量维度，例如 1024
print(vec[0][:3])    # 前三个分量，感受稠密分布

2. 本地用 FlagEmbedding 跑 bge-m3（多语言 / 混合检索）

对数据隐私敏感、或想完全私有化的团队，直接在本机加载 bge-m3，它一次性返回稠密、稀疏、colbert 三种向量：

from FlagEmbedding import BGEM3FlagModel

model = BGEM3FlagModel("BAAI/bge-m3", use_fp16=True)

# encode 返回 dense / sparse / colbert 三种表示
outputs = model.encode(
    ["如何部署本地大模型", "RAG 检索质量优化"],
    batch_size=8, max_length=512
)
dense_vecs = outputs["dense_vecs"]    # 稠密向量，用于语义检索
sparse_vecs = outputs["lexical_weights"]  # 稀疏权重，用于关键词召回
print(dense_vecs.shape)               # (2, 1024)

3. 归一化与余弦相似度

import numpy as np

def cos_sim(a, b):
    a = np.asarray(a, dtype=np.float32)
    b = np.asarray(b, dtype=np.float32)
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

# 多数 Embedding 已内置 L2 归一化，点积 ≈ 余弦相似度
score = cos_sim(vec[0], vec[1])
print(f"语义相似度: {score:.4f}")

五、Chunk 切分与向量化的工程细节

向量化不是”把整篇文档丢进去”就行。长文档要切成 chunk，切法直接决定召回质量：

• 重叠窗口：相邻 chunk 留 10–20% 重叠，避免一句话被切断导致语义丢失；
• 按结构切：优先按标题、段落、表格边界切，而不是机械按字数；
• 带元数据：每个 chunk 记录 source、section、页码，检索后可做来源过滤与展示；
• 批量 + 同模型：入库和查询必须用同一模型，批量向量化时注意 batch_size 与 max_length。

下面把切好的 chunk 连同元数据一起写入 Chroma 向量数据库，这是 RAG 存储选型里最轻量的落地方式：

import chromadb

client = chromadb.PersistentClient(path="./rag_db")
col = client.get_or_create_collection(
    "docs", metadata={"hnsw:space": "cosine"})

col.add(
    ids=[f"doc-{i}" for i in range(len(chunks))],
    documents=chunks,
    embeddings=embed(chunks),
    metadatas=[{"source": src[i], "section": sec[i]}
               for i in range(len(chunks))]
)

hits = col.query(query_texts=["电池续航差怎么解决"], n_results=3)
print(hits["documents"][0])   # 最相似的 3 个 chunk

六、检索召回如何与重排序衔接

向量检索召回的 top-K 往往”广而不精”——语义相关但未必最切题。工程上标准做法是用 Embedding 做粗排召回（取 top-20~50），再接一个 Cross-Encoder 重排序模型做精排（取 top-3~5 喂给大模型）。这套混合检索 + 重排序的链路，在 RAG 进阶实战 里有完整代码；而召回质量到底如何，要用 向量检索评测（Recall@K） 量化，不能靠”感觉”。

特别提醒：如果你把 Embedding 接入 Dify + Ollama 这类低代码平台，它的召回效果天花板就是你所选 Embedding 的上限。换一个更好的模型，往往比调提示词收益更大。这也是为什么选型要前置——它决定了整条 RAG 链路的底座水位。

七、Embedding 选型决策清单

八、小结

Embedding 模型是 RAG 的”地基工程”：它用稠密向量把语义相近的文本拉近，让检索从”找相同词”升级为”找相同意思”。选型时记住三件事——中文优先 bge 系列、维度够用即可、入库与查询必须同模型同预处理；落地时叠加重叠切分、元数据、混合检索与重排序。今天就可以挑一个 bge 模型，按上面的代码把你的第一篇文档向量化、写进 Chroma，亲手验证”语义召回”比关键词匹配强在哪。把底座打牢，后面接 大模型工具调用 和 Agent 编排时，RAG 才不会成为整条链路的短板。