前两篇讲了加载和切分。这一篇讲第三段——Embeddings：把文本块转成向量。
这一段是 RAG 能做「语义检索」的基础。理解它，才懂为什么「相关问题能找到相关文档」。
Embedding 是什么
Embedding 就是把文本映射成一串数字（向量）。关键在于：语义相近的文本，转向量后在空间里也相近。
「怎么退款」和「退款流程是什么」，字面不同，但语义相近——embedding 后它们的向量距离很近。「怎么退款」和「今天天气不错」，语义无关，向量距离远。
这就是语义检索的基础：把问题和文档都转向量，比谁的向量离得近，近的就是相关的。相比关键词匹配（字面一样才算相关），embedding 能抓住语义，更准。
为什么这能做相似搜索
embedding 能做相似搜索，核心是「语义相近 → 向量相近」这个性质。它来自 embedding 模型的训练方式：模型在海量语料上学习，让真正语义相关的文本向量靠近，无关的拉远。
检索时，算问题和每个文档块的向量距离（常用余弦相似度），距离最近的几块就是最相关的。整个过程不依赖字面匹配，而是依赖语义理解。
这也是为什么 embedding 模型很重要——它决定了「语义理解的质量」。模型不好，语义相近的文本可能被转向量后离得远，检索就错了。
中文场景的模型选型
embedding 模型选型有个重要提醒：中文场景别无脑用 OpenAI 的模型。
OpenAI 的 embedding 模型（text-embedding 系列）在英文上很强，但中文支持不是最优。中文场景下，有几个值得考虑的方向：
- bge 系列（智源）：中文效果好，有开源可本地部署
- 国产闭源模型：部分中文场景表现优于 OpenAI
- 本地部署的开源模型：数据不出域、可控成本
选型考虑三个维度：中文质量、是否可本地部署（数据隐私）、成本。数据敏感的场景优先本地部署的开源模型。
建库和查询要用同一个模型
一个硬约束：建库时用什么 embedding 模型，查询时必须用同一个。
为什么？因为不同模型把同一文本转向量的空间不同——A 模型下「退款」的向量和 B 模型下「退款」的向量，根本不在一个空间里，没法比距离。
这就是第 25 篇说「换 embedding 模型要重建库」的原因——换了模型，原来存的向量全作废，必须用新模型重新把所有文档向量化一遍。所以 embedding 选型要慎重，尽量一次选对。
Embeddings 也是 Runnable
和其它组件一样，Embeddings 也是 Runnable（Phase 1）。它有 embed_query（转向量一条查询）和 embed_documents（转向量一批文档）两个主要方法。建库脚本里批量 embed，查询链里 embed 当前问题。
收束：向量化是语义检索的基础
这一篇讲了 Embeddings：
- 把文本转向量，语义相近则向量相近
- 这是语义检索（非关键词匹配）的基础
- 中文场景别无脑用 OpenAI，考虑 bge / 国产 / 本地模型
- 建库和查询必须用同一个模型，换了要重建库
- 也是 Runnable
下一篇讲第四段——Vector Stores：把向量存起来，支持相似搜索。会讲几种主流向量库和它们的选型。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。我相信 AI 是程序员的最佳搭档。
如果你想跟完这套「图解 LangChain」，欢迎关注公众号 「十三Tech」。全系列 42 篇，会按认识基础、LangGraph 状态机、Agent 与 middleware、RAG 检索、Tools/MCP/记忆、生产化收束这条线更新。
