RAG 中的 Embedding 到底是什么？

面试里问 RAG，很多人会把重点放在“向量数据库”和“Prompt 组装”上，却把 Embedding 轻轻带过：文本转向量嘛，调个 API 就行。

这其实是一个很危险的误区。RAG 能不能把正确资料找出来，第一步就卡在 Embedding。如果问题和文档被映射到错误的语义空间，后面的 Rerank、Prompt、LLM 都是在补漏洞。

这章用通俗方式讲清楚 5 件事：Embedding 到底是什么，为什么相似文本会靠近，RAG 里它怎么工作，模型应该怎么选，以及怎样用业务数据评估效果。

一、先给一个面试级简答

Embedding 是把文本映射成固定长度数字向量的过程。它的核心价值不是“变成数字”，而是让语义相近的文本在向量空间里距离更近。

在 RAG 里，系统会先把知识库 Chunk 转成向量存入向量数据库；用户提问时，再把 Query 转成向量，用相似度检索找到最相关的 Chunk，最后把这些 Chunk 作为上下文交给大模型回答。

选模型不能只看 MTEB 排行榜，也不能盲目相信某一个 API。实际工程里要看语言场景、数据合规、向量维度、最大输入长度、部署成本和业务评测结果。真正有参考价值的是在自己的业务数据上跑 Hit@K、MRR、nDCG 等指标。

二、Embedding 的本质：不是数字游戏，而是语义坐标

Embedding 模型做的事情，可以理解成“给文本找一个语义坐标”。一段话、一个标题、一个问句，都会被映射成一串浮点数。比如 768 维、1024 维、1536 维，本质上都是在高维空间里给文本定位。

这串数字单独看没有意义，真正有意义的是向量之间的距离。两个文本表达的意思越像，它们的向量方向越接近；意思越远，它们在空间里就越分散。

这也是为什么 RAG 能处理“同义不同字”的问题。用户说“iPhone 如何截屏”，知识库里写的是“苹果手机怎么截图”，关键词可能对不上，但语义向量可以把它们拉到同一个区域。

三、为什么常用余弦相似度？

衡量两个向量像不像，常见方法有余弦相似度、点积和欧氏距离。RAG 里最常见的是余弦相似度，因为它主要看两个向量的方向，而不是向量长度。

可以把每个向量想成一支箭头。如果两支箭头指向差不多的方向，说明两段文本在语义上接近；至于箭头长一点还是短一点，不是最重要。

工程里要特别注意：Embedding 模型、向量库和评测脚本必须使用一致的距离函数。如果离线评测用 cosine，线上向量库用 L2 或点积，排序结果可能会不一致。

四、RAG 里的 Embedding 有两条链路

第一条是离线建库链路：原始文档经过清洗、切块、加元数据后，每个 Chunk 都会送入 Embedding 模型，得到向量，然后和原文、来源、标题、更新时间等信息一起存入向量库。

第二条是在线问答链路：用户提问后，系统会把 Query 转成向量，去向量库里找最相似的 Chunk，再把这些 Chunk 拼进 Prompt，让大模型基于证据回答。

所以 Embedding 的质量，直接决定“正确资料能不能被召回”。一旦召回错了，大模型即使再强，也只能在错误资料上发挥。

五、Embedding 检索和关键词检索有什么不同？

关键词检索擅长精确匹配，比如合同编号、产品型号、错误码、专有名词。Embedding 检索擅长语义泛化，比如同义词、口语化表达、跨语言表达、不同说法的同一个问题。

但语义检索不是万能的。它可能把“意思像但事实不对”的内容也召回来；而关键词检索虽然死板，却能在精确约束上表现稳定。

成熟的 RAG 系统一般会采用混合检索：关键词召回保证精确性，向量召回保证语义泛化，再用 Reranker 做最终排序。

六、常见 Embedding 模型怎么选？

Embedding 模型大致可以分为 API 型、本地开源型、多模式型和专域增强型。API 型接入快、维护少，适合快速验证；本地开源型适合数据敏感、私有化部署的企业场景。

如果知识库主要是中文，不能只看英文排行榜。中文客服、金融、政务、医疗等场景，需要优先在自己的中文业务数据上测 BGE、Qwen3-Embedding 等模型。中英混合或多语言场景，可以重点测试 BGE-M3 这类多语言模型。

模型维度也不是越高越好。高维向量通常表达能力更强，但存储成本、检索延迟、索引构建时间都会提高。百万级以上知识库，维度差异会明显影响预算。

Embedding 模型选型矩阵。

维度、效果和成本之间存在取舍。

七、不要只看排行榜，要用业务数据评估

MTEB 这类通用榜单适合做初筛，但不能直接代表你的业务效果。因为你的知识库可能是法律条款、客服 FAQ、医疗病例、代码文档，也可能有大量行业缩写和内部黑话。

更可靠的方式，是准备几百到几千条业务评测样本：每条样本包含一个真实用户问题，以及它对应的正确答案 Chunk。然后用候选 Embedding 模型分别建库、检索，看正确 Chunk 是否出现在 TopK。

Hit@5 = 0.80 的意思是：100 个问题里，有 80 个问题的正确答案出现在检索结果前 5 条。这个指标很直观，也很适合和业务方沟通。

八、代码示例：生成向量并计算相似度

下面是一个最小化示例：把 query 和文档都转成向量，然后用余弦相似度排序。实际项目里需要把文档向量提前存入向量库，不会每次现算。

from openaiimportOpenAIimportnumpy as np client=OpenAI()def embed(text: str)->np.ndarray: resp=client.embeddings.create(model="text-embedding-3-small",input=text,)returnnp.array(resp.data[0].embedding,dtype=np.float32)def cosine(a: np.ndarray, b: np.ndarray)->float:returnfloat(np.dot(a, b)/(np.linalg.norm(a)* np.linalg.norm(b)))query="iPhone 如何截屏？"docs=["苹果手机截图可以同时按侧边键和音量上键。","苹果汁可以用榨汁机制作。","安卓手机通常可以通过电源键和音量键截图。",]q_vec=embed(query)ranked=sorted([(doc, cosine(q_vec, embed(doc)))fordocindocs],key=lambda x: x[1],reverse=True,)fordoc, scoreinranked: print(round(score,4), doc)

如果你使用本地模型，代码结构类似，只是把 API 调用换成本地推理服务。关键不是代码长短，而是要确保文档和 Query 使用同一个模型版本、同一个维度、同一种归一化策略。

九、代码示例：用 Hit@K 做业务评测

下面这个评测函数可以帮助你判断：正确答案是否出现在 TopK 结果里。真实项目中，retriever 可以是向量库，也可以是混合检索 + Rerank。

from typingimportList, Dict# eval_set 示例：# [# {"query": "如何重置密码？", "gold_chunk_id": "faq_001"},# {"query": "发票在哪里下载？", "gold_chunk_id": "faq_102"},# ]def hit_at_k(eval_set: List[Dict], retriever, k: int=5)->float: hit=0foritemineval_set: query=item["query"]gold_id=item["gold_chunk_id"]results=retriever.search(query,top_k=k)retrieved_ids=[r.chunk_idforrinresults]ifgold_idinretrieved_ids: hit+=1returnhit / len(eval_set)score=hit_at_k(eval_set, retriever,k=5)print(f"Hit@5 = {score:.2%}")

如果候选模型 A 的 Hit@5 是 82%，模型 B 是 76%，但模型 A 延迟是模型 B 的三倍，就不能只看准确率。生产选型要把召回质量、延迟、成本、合规一起算。

十、生产级 Embedding 服务怎么设计？

生产环境不要把 Embedding 当成一个简单函数。它应该是一个可观测、可回滚、可灰度的基础服务。

文档入库时，要记录 embedding_model、dimension、normalize、version、created_at 等元数据。因为一旦模型升级，历史向量通常需要重建；如果新旧向量混在一个索引里，检索结果会变得不可控。

在线检索时，要关注 P95 延迟、TopK 命中率、空召回率、Rerank 后排名变化、Embedding API 错误率和成本。尤其是大规模知识库，Embedding 成本不只在调用 API，还在存储、索引、备份和重建。

十一、常见坑：RAG 效果差，往往错在检索地基

第一，只看排行榜，不做业务评测。通用榜单适合初筛，但业务分布不同，模型效果可能完全不同。

第二，不区分 Query 和 Document。有些模型建议为查询和文档使用不同的输入提示，如果全部按普通文本处理，检索效果可能打折。

第三，换模型不重建索引。不同模型产生的向量空间并不一致，把不同模型的向量混在一起检索，等于把地图坐标系混用了。

第四，忽略 Chunking。Embedding 模型再好，如果 Chunk 把语义切碎，正确答案也很难被召回。

第五，只有向量检索，没有关键词兜底。订单号、错误码、型号、日期、法律条文编号这类信息，关键词检索往往更稳定。

十二、面试回答模板

Embedding 是 RAG 的检索基础，它把文本映射成固定长度的语义向量，让语义相近的 Query 和 Chunk 在向量空间里靠近。检索时，我们把用户问题也转成向量，用余弦相似度或点积从向量库里找 TopK 相关 Chunk，再交给大模型回答。

模型选型上，我不会只看排行榜。会先根据语言、合规、维度、最大输入长度和部署成本做初筛，再用自己的业务评测集跑 Hit@K、MRR、nDCG，同时关注 P95 延迟和存储成本。中文或私有化场景会重点测 BGE、Qwen3-Embedding 等本地模型；快速验证或英文场景可以测试 OpenAI、Voyage、Cohere 等 API 模型。

上线后还要做版本管理和监控。每条向量都要记录模型版本和维度；模型升级时要重建索引；召回效果要持续监控，避免知识库更新或用户问题变化后效果漂移。