Embedding 不是可有可无的组件，它是 RAG 的地基。地基歪了，后面 Retriever、Rerank、Prompt 再漂亮也救不回来。

一、Embedding 到底是什么？

Embedding，就是把一段文字变成一串数字。

这串数字不是随机数，而是语义坐标。意思相近的文本，向量距离更近；意思差得远的文本，距离更远。

LangChain 官方文档对 Embedding 的解释也很直接：Embedding 模型会把原始文本转换成固定长度的数字向量，这些向量能表达语义含义，让机器按“意思”比较文本，而不是只按关键词匹配。

这就是语义检索能工作的原因。

用户问“提前还款怎么操作”，知识库里写的是“如何结清贷款”，关键词不一样，但意思接近。Embedding 能把它们拉到同一个语义区域，向量库就能召回。

如果没有 Embedding，RAG 很容易退化成普通搜索。只能找关键词，找不到意思。

二、Embedding 在 RAG 里处在哪一层？

前面几章已经讲过：Loader 把资料读进来，Splitter 把长文档切成 Chunk。接下来，就轮到 Embedding。

它做一件事：把每个 Chunk Document 的 page_content 转成向量，然后交给 VectorStore 入库。

离线建库和在线查询两条链路，都要经过 Embedding

离线建库时，Embedding 面向的是一批文档。在线查询时，Embedding 面向的是用户的一句话。

所以 LangChain 在接口上故意拆成两个方法：

embed_documents(texts)：文档批量向量化。

embed_query(text)：问题单条向量化。

这两个方法看起来简单，但这是整个语义检索的分水岭。文档侧是“建索引”，问题侧是“查索引”。

三、Embeddings 抽象接口

打开 LangChain Core 的源码，可以看到 Embeddings 是一个抽象基类。它不是 OpenAI，也不是 HuggingFace。它只是规定：一个 Embedding 模型必须能把文档和查询变成向量。

源码的设计非常克制。核心就是四个方法：

class Embeddings(ABC):

def embed_documents(self, texts: list[str]) -> list[list[float]]: ...

def embed_query(self, text: str) -> list[float]: ...

async def aembed_documents(self, texts: list[str]) -> list[list[float]]: ...

async def aembed_query(self, text: str) -> list[float]: ...

这里最关键的是返回类型。

文档是 list[str]，所以返回 list[list[float]]。一个文本，对应一个向量。

查询是 str，所以返回 list[float]。一个问题，对应一个向量。

这就是 LangChain 抽象层的好处：上层 VectorStore 和 Retriever 不需要知道你底下接的是哪个模型。只要实现这个接口，就能被接入 RAG 流水线。

四、为什么要区分 embed_documents 和 embed_query？

很多人第一次看源码会疑惑：文档是文本，问题也是文本，为什么不统一叫 embed_text？

不同 Embedding 模型可能会对“文档”和“查询”使用不同提示方式。比如某些检索模型会要求：

文档侧：把这段内容编码成可检索资料。

查询侧：把这个问题编码成检索意图。

有些模型内部路径一样，有些模型内部路径不一样。LangChain 先把接口拆开，给不同模型留下扩展空间。

这就是好的框架设计：看起来多写了一个方法，实际是在给未来兼容性留口子。

五、OpenAIEmbeddings 怎么实现？

以 OpenAIEmbeddings 为例，源码链路很清晰。

它的 embed_documents 大致分两种情况：

如果不检查上下文长度：直接按 chunk_size 分批调用 embedding API。

如果检查上下文长度：先 tokenize，再按 embedding_ctx_length 切分，再批量请求。

源码里有一个细节很重要：长文本不会直接硬塞给 embedding API。它会被分成 token chunks，再请求向量，最后把多段结果合并。

embed_query 更直接。源码逻辑可以压缩成一句话：

def embed_query(self, text: str) -> list[float]:

return self.embed_documents([text])[0]

也就是说：问题向量化，本质上还是复用文档向量化能力。先把单个问题包装成列表，再取第一个结果。

这不是偷懒。恰恰是工程复用。

六、从源码看 VectorStore 为什么能自动调用 Embedding？

很多人写代码时会发现，自己明明只写了 from_texts、add_documents 或 retriever.invoke，为什么 Embedding 就自动被调用了？

因为 VectorStore 和 Retriever 在内部已经接上了 Embeddings 接口。

文档入库时：

VectorStore.add_documents(documents)

-> 取出 page_content

-> embeddings.embed_documents(texts)

-> 向量 + metadata + id 入库

查询检索时：

retriever.invoke(query)

-> vectorstore.similarity_search(query)

-> embeddings.embed_query(query)

-> 用 query_vector 去向量库查近邻

-> 返回 List[Document]

所以，Embedding 是隐藏在 RAG 后面的发动机。你看不到它转，但它一直在转。

七、向量怎么比较？三个常见相似度指标

文本变成向量后，下一步就是比较。LangChain 官方文档列出了常见的三类距离或相似度指标：余弦相似度、欧氏距离、点积。

余弦相似度：看两个向量方向是否接近。常用于语义相似度。

欧氏距离：看两个点在空间里的直线距离。

点积：看一个向量在另一个方向上的投影强度。

实际项目里，你不一定要自己手写这些公式。向量库会帮你算。但你必须知道：不同指标会影响召回结果，向量是否归一化也会影响结果。

八、Embedding 模型怎么选？这张图比参数更重要

选 Embedding 模型，不要只看榜单。

真正上线时，最关键的是业务评测。你要拿自己的问题、自己的知识库、自己的标准答案去测。

比如智能客服要测：用户口语化提问能不能召回制度文档。股票研报助手要测：同一公司不同公告、行业新闻、研报摘要之间能不能建立语义关联。

如果只拿通用 benchmark 选模型，很容易线上翻车。

九、缓存为什么重要？Embedding 不是一次性成本

很多人以为 Embedding 只在建库时花钱。错。

查询也要 embed_query。每个用户问题都可能触发一次向量化。高并发下，延迟和成本都会上来。

所以生产系统至少要做三类缓存：

文档向量缓存：同一 Chunk 内容不重复向量化。

查询向量缓存：高频问题不重复调用 embedding 模型。

索引版本缓存：模型版本、切分版本、向量库版本要绑定。

只要文档内容、切分策略、Embedding 模型版本任何一个变了，历史向量就可能需要重建。

十、企业级落地：Embedding 不该只是一个函数

如果只是 Demo，Embedding 可以写成一行代码。

如果是企业系统，Embedding 必须进入数据流水线。

Java 主服务负责文档上传、任务调度、权限审计、索引版本。

Python AI 服务负责 Loader、Splitter、Embedding、Retriever。

Milvus / ES 负责向量和关键词索引。

Redis 做缓存，MySQL 记录元数据和版本。

日志系统记录每次向量化耗时、模型名称、维度、token、失败原因。

Embedding 是基础设施，不是工具函数。

十一、Embedding 最容易踩的坑

RAG 效果差，很多时候不是大模型的问题，而是 Embedding 链路的问题。

最常见的就是：文档切得不好、模型版本乱换、向量没有重建、metadata 没带、只做向量检索不做关键词融合。

尤其是模型版本。

同一个向量库里，不能混着放不同 Embedding 模型生成的向量。维度可能不同，语义空间也可能不同。哪怕维度一样，距离也不一定有可比性。

十二、总结

Embedding 把文本变成向量，VectorStore 按距离找资料，Retriever 把相关 Document 交给 Prompt，Model 再基于资料生成答案。

所以，RAG 的第一性原理不是“把资料塞给大模型”，而是：先把资料变成可计算的语义坐标，再按问题找到最相关的上下文。

学 LangChain，Embedding 这一章必须吃透。因为从这里开始，RAG 才真正从“文本处理”进入“语义计算”。