Embedding Model 入门：语义向量、相似度与向量检索

Embedding Model 是 AI 原生应用的基础组件。RAG、语义搜索、相似问题匹配、文档聚类、推荐系统都离不开它。

一句话理解：

Embedding 模型把文本转换成一组数字，让机器可以用数学方式比较语义相似度。

例如下面三句话：

如何重置登录密码？
忘记密码怎么办？
账号无法登录，怎么找回密码？

它们字面不完全相同，但语义接近。Embedding 模型会把它们映射到向量空间中相对接近的位置。

为什么关键词搜索不够

传统搜索主要依赖关键词。

用户搜：

忘记密码怎么办

文档标题是：

账号登录凭证重置流程

关键词搜索可能匹配不好，因为“忘记密码”和“登录凭证重置”没有共享太多词。

Embedding 搜索关注语义，因此更容易找到相关文档。

关键词搜索适合精确匹配，Embedding 搜索适合语义匹配。生产系统经常把两者结合起来。

向量是什么

向量就是一组数字。

例如一个文本可能被转换成：

[0.012, -0.238, 0.781, ...]

真实 Embedding 向量维度通常是几百到几千维。每个维度不是人类可直接解释的标签，但整体向量可以表达文本的语义特征。

两个文本的语义越接近，它们的向量距离通常越近。

Embedding 的基本用法

以文档检索为例：

离线阶段：

1. 收集文档。
2. 切分文档。
3. 对每个文档片段生成 Embedding。
4. 把文本、向量、metadata 存入向量数据库。

在线阶段：

1. 用户提问。
2. 对问题生成 Embedding。
3. 在向量数据库中搜索相似向量。
4. 返回相关文档片段。
5. 把片段交给大模型回答。

伪代码：

doc_vectors = embedding_model.embed_documents(chunks)
vector_store.add(chunks, doc_vectors)

query_vector = embedding_model.embed_query(question)
results = vector_store.search(query_vector, top_k=5)

相似度怎么算

常见相似度指标有三种。

第一种是余弦相似度。它关注向量方向是否接近。

cosine_similarity(a, b)

第二种是点积。很多向量数据库会使用 dot product，速度快，也适合归一化后的向量。

dot(a, b)

第三种是欧氏距离。它关注两个向量在空间中的距离。

distance(a, b)

选择哪种指标通常要看模型文档和向量数据库配置。不要随意混用，因为不同 Embedding 模型可能对相似度计算有不同建议。

文本如何进入 Embedding 模型

Embedding 模型通常先用 tokenizer 把文本切成 token，再经过神经网络编码成向量。

这里有几个重要限制：

• 输入文本有最大长度。
• 超长文本需要切分。
• 不同模型对中文、英文、代码、表格的效果不同。
• 查询和文档最好使用同一个 Embedding 模型。
• 模型升级后，旧向量通常需要重新生成。

如果你换了 Embedding 模型，不要只替换在线查询模型。文档库里的历史向量也要重新索引，否则查询向量和文档向量不在同一个语义空间。

选择 Embedding 模型

选择模型时看几个指标：

• 支持语言：中文、英文、多语言。
• 向量维度：影响存储和检索成本。
• 最大输入长度：影响文档切分策略。
• 检索效果：是否适合你的业务文本。
• 调用成本：API 费用或本地推理成本。
• 延迟：在线查询是否能接受。
• 部署方式：云 API、本地模型、私有化部署。

中文知识库优先选择对中文表现稳定的模型。代码检索则要关注模型是否理解代码语义。

向量数据库保存什么

向量数据库不应该只保存向量。

推荐保存：

{
  "id": "doc-001-chunk-003",
  "text": "报销发票抬头应填写公司全称...",
  "vector": [0.012, -0.238, 0.781],
  "metadata": {
    "doc_id": "doc-001",
    "title": "报销制度",
    "source": "finance-policy.md",
    "section": "发票要求",
    "updated_at": "2026-06-01",
    "department": "finance",
    "permission": ["employee"]
  }
}

metadata 非常重要。它支持权限过滤、引用展示、增量更新和问题排查。

向量检索不是数据库查询的替代品

Embedding 适合找语义相关内容，但不适合替代精确查询。

如果用户问：

订单 202607200001 的支付状态是什么？

这应该查数据库，不应该靠向量检索。

如果用户问：

订单退款失败一般有哪些原因？

这适合用 RAG 检索知识库。

AI 应用里要区分：

• 精确事实：查数据库或业务 API。
• 解释性知识：查文档和知识库。
• 开放生成：调用 LLM。

常见应用场景

第一，语义搜索。

用户用自然语言搜索，系统返回语义相关文档。

第二，RAG。

Embedding 用于从知识库中召回相关片段。

第三，相似问题匹配。

客服系统可以把用户问题与历史 FAQ 匹配。

第四，聚类。

把大量反馈、工单、评论按语义分组。

第五，推荐。

根据用户兴趣文本和内容文本向量做匹配。

第六，去重。

识别语义重复或高度相似的文本。

Chunk 对 Embedding 的影响

Embedding 不是对越长文本越好。长文本中如果包含多个主题，向量会变得“平均”，导致检索不准。

例如一个 chunk 同时包含：

• 登录问题
• 支付问题
• 发票问题

用户问发票时，这个 chunk 可能被召回，但里面有很多无关内容。

好的 chunk 应该语义集中，能独立表达一个主题。

建议：

• 保留标题作为上下文。
• 不要把多个无关主题放在一个 chunk。
• 对 FAQ 可以一问一答作为一个 chunk。
• 对技术文档可以按标题层级切分。
• 对代码可以按函数、类或模块切分。

向量维度和成本

向量维度越高，可能表达能力更强，但成本也更高。

成本体现在：

• 存储空间。
• 索引构建时间。
• 检索延迟。
• 网络传输。
• 内存占用。

假设一个向量有 1536 维，每个维度用 float32 存储，大约需要：

1536 * 4 bytes = 6144 bytes

一百万个向量约 6GB，还不包括索引和 metadata。

所以生产环境要关注向量数量、维度和索引类型。

Embedding 的评估

不要只看模型排行榜。你应该用自己的业务问题评估。

准备测试集：

问题 -> 应该命中的文档

例如：

忘记密码怎么办 -> 账号登录凭证重置流程
发票抬头怎么写 -> 差旅报销制度 / 发票要求
接口返回 E2031 -> 支付错误码说明

评估：

• Top 1 是否命中。
• Top 5 是否命中。
• 是否召回无关内容。
• 中文同义表达是否命中。
• 专有名词是否命中。
• 错误码和编号是否命中。

如果精确编号类问题表现差，可以加入关键词检索和 rerank。

常见坑

第一，换模型但不重建索引。查询向量和文档向量来自不同模型，检索会失真。

第二，chunk 太大。导致召回内容模糊，Prompt 噪声多。

第三，chunk 太小。导致上下文不足，模型无法回答。

第四，没有保存 metadata。后期无法做权限、引用和增量更新。

第五，把向量检索当万能查询。订单状态、库存数量、用户余额这类实时事实应该查数据库。

第六，不做评估。没有测试集，就不知道检索质量是否提升。

与 RAG、Cross Encoder 的关系

Embedding 是 RAG 的召回层。

Cross Encoder 是 RAG 的排序增强层。

LLM 是 RAG 的生成层。

可以这样理解：

Embedding：先从大量文档里快速找候选
Cross Encoder：再判断候选里谁更相关
LLM：最后基于最相关内容生成答案

这三者分工不同，不要混为一谈。

参考资料

• OpenAI 文档：Embeddings
• LangChain 文档：Text embedding models
• Sentence Transformers 文档
• FAISS 文档
• pgvector 项目

总结

Embedding Model 的价值是把自然语言变成可检索、可计算的语义向量。

掌握 Embedding，需要理解向量、相似度、chunk、metadata、向量数据库、模型选择和评估。它不是最终答案生成器，而是 AI 应用里的“语义召回引擎”。只有召回质量稳定，RAG 和 Agent 才有可靠的知识基础。