Embedding 在 RAG 中有什么作用？向量化、检索和召回怎么串起来？
你有没有遇到过这种情况：问 AI 一个它"明明应该知道"的问题，它却一本正经地胡说八道？
比如问"去年 Q3 我们的营收是多少"，它可能信誓旦旦地说"5.8亿元"。但如果你去查内部数据，发现实际上是4.2亿元。这不是 AI 笨，而是它真的"不知道"——它的知识停留在训练那一刻，而且经常混淆相似概念。
上篇文章我们聊了怎么选 Embedding 模型：维度怎么看、中文效果怎么测、成本怎么算。但光有模型还不够，你得把这些向量用起来才行。今天我们就来看看，Embedding 在 RAG 里到底怎么工作，向量化、检索、召回是怎么串成一条链的。
AI 为什么会"一本正经地胡说八道"？
要理解 RAG，先得搞清楚 AI 为啥会胡说八道。
LLM 的知识来源于训练数据。训练完之后，它的认知就"凝固"了——不知道最新的新闻，不记得你昨天上传的合同细节，更分不清"苹果股价"和"苹果公司"在某个上下文里的区别。
更坑的是，当模型不确定答案时，它会"想象"一个听起来合理的回答。这叫幻觉（Hallucination）。不是 Bug，是大模型的"天性"。
怎么办？
RAG 的思路很直接：不是让模型变聪明，而是给它配一个随叫随到的外置知识库。你问"去年Q3营收"，RAG 先去知识库里查，找到真实数字，再让 AI 基于这个数字回答。
你可以把 LLM 想象成一个记忆力有缺陷的学霸——理解能力很强，但记不住所有细节。RAG 就是给它配了一个百科全书助手，随时帮它翻书找答案。
Embedding：让文字变成"坐标点"
那么问题来了：RAG 怎么知道去哪找答案？
这就轮到 Embedding 出场了。
还记得上篇说的吗？Embedding 就是把文本、图片、代码等内容，映射成几百到几千维的浮点数组——也就是向量。
但 Embedding 的真正价值，不只是"翻译"，而是它能捕捉语义相似性。
怎么理解呢？
想象把所有文本都映射到一个巨大的"语义地图"上。"如何申请退货？"和"退货流程是什么？"这两个问题，意思差不多，所以在地图上会落得很近。"今天天气怎么样？"问的是天气，就会落在另一个区域。
相似的内容，在向量空间中距离很近。不相似的则距离很远。
这个"近不近"怎么判断？用的是余弦相似度——看两个向量的方向是否一致。角度越小，相似度越高。
Embedding 就是给每个文本发了一张"藏宝图坐标"。语义相关的宝藏会画在相近的位置。
向量数据库：海量向量的高效"图书馆"
现在我们有了大量文本的向量。但这些向量存哪？怎么快速找到最相关的那几个？
传统数据库存的是表格数据，存不了高维向量。这就需要向量数据库。
打个比方：
传统搜索像是按字母顺序在字典里找词，一个个比对。"退货"...不对，"退换"...也不对，要翻半天。
向量数据库则是按内容主题分类。你找"退货相关的问题"，管理员直接带你到"售后服务区"，而不是逐本核对书名。
向量数据库提供的是近似最近邻搜索（ANN）能力——不需要遍历所有向量，就能找到最相似的 Top-K 个。
怎么做到的？靠的是各种索引算法。
最常用的是 HNSW（分层可导航小世界图）。它的思想是这样的：
构建一个多层图。最上层连接的是距离较远的"枢纽节点"，越往下连接越细。最后一层就是所有向量的详细连接。
搜索时，从最上层开始快速定位到大概区域，然后逐层下降，最终在最底层找到最相似的几个。
这就是为什么向量数据库能在毫秒级从海量数据中返回结果——它不是大海捞针，而是先缩小范围，再精准打捞。
RAG 完整链路：四步串联向量化、检索与召回
好了，现在 Embedding 和向量数据库都有了。它们在 RAG 里是怎么配合的？
完整的 RAG 流程分四步，像是一次图书馆查资料：
第一步：Query Embedding（问题向量化）
用户问："这个订单什么时候能发货？"
系统用同一个 Embedding 模型，把这个问题转成向量。
为什么要"同一个"模型？因为只有用相同的 Embedding 模型，向量空间才能对齐。你用中文模型给问题向量化的内容，得用同一个中文模型生成的向量库去匹配。
第二步：向量检索（ANN 搜索）
拿着这个问题向量，去向量数据库里找最相似的知识片段。
比如可能召回："发货时间通常在付款后1-3个工作日"、"节假日可能延迟"、"如何查看物流进度"这几个相关片段。
第三步：上下文增强（构造 Prompt）
把用户问题和召回的片段组合成"增强 Prompt"：
用户问题：我的订单什么时候能发货？
相关知识：
- 发货时间通常在付款后1-3个工作日
- 节假日可能导致延迟
- 可在APP内查看物流进度
请根据以上信息回答用户问题。第四步：LLM 生成
把增强 Prompt 发给大模型，让它基于提供的知识生成回答。
大模型不再需要"凭记忆编"，而是"照着资料答"。
整个链路跑一遍通常在几百毫秒左右。用户感觉就像在和一个"什么都知道"的 AI 对话。
语义检索 vs 关键词检索：为什么 Embedding 更聪明
你可能会想：搜索嘛，我用关键词匹配不行吗？为什么非要用 Embedding？
还真不一样。
关键词检索只匹配字面词。用户问"怎么退钱"，但知识库里写的是"退款流程"，查不到。用户写的是"退货"，知识库写的是"商品退回"，也查不到。
语义检索就不一样了。它能理解"退钱"和"退款"是一回事，"退货"和"商品退回"说的是同一类问题。
差距在哪？
关键词检索像是"按名字找人"——你得知道对方全名才行。
语义检索像是"找一个笑起来像邻家大哥哥、喜欢穿白衬衫的产品经理"——根据特征描述找到人，不依赖精确姓名。
实际业务中经常两者结合用：
先用向量检索快速召回一批候选，再用关键词匹配或元数据过滤做精排。比如限制搜索范围是"2024年的文档"，或者必须在标题中包含某个关键词。
取长补短，效果更好。
实战选型：你的业务该用哪个向量数据库？
最后聊聊实战。
选向量数据库和选住房差不多：
- 小规模（<100万向量）：PostgreSQL + pgvector 够用了。直接在你现有的数据库上加个插件，运维简单，学习成本低。
- 中大规模（100万-10亿）：推荐 Milvus。性能强，生态完善，社区活跃。HNSW、IVF-PQ 等算法都支持。
- 超大规模或不想运维：Pinecone、Zilliz Cloud 这类 SaaS 服务。用多少付多少，省心。
有个参数可以调：HNSW 的 ef_search 值。
ef_search 越大，召回率越高，但延迟也增加。起步时用默认值就行，发现召回效果不好再逐步调大。
选对了数据库，就相当于有了一个又快又准的"图书馆管理员"。接下来就看你怎么整理"书架"——也就是怎么切分文档、设计索引策略。这部分我们下次再聊。