Embedding 与 RAG

理解 Embedding、向量数据库、语义检索、切分、召回、重排、上下文组装、引用与 RAG 评估。

「产品经理的大模型基础」系列之五
上一篇：模型 API 与基础编程 · 系列入口 · 下一篇：工具调用与 Workflow

大模型在训练中学到了大量通用知识，但产品中的许多信息并不适合只依赖模型参数。例如企业内部制度会变化，商品库存需要实时查询，项目文档要求准确引用，用户也可能只允许系统读取特定范围的资料。

这类场景通常需要把外部知识提供给模型。Embedding 和 RAG 是其中最常见的基础技术。

Embedding 主要解决“怎样按语义找到相关内容”，RAG 则把检索到的内容放进模型上下文，让模型基于这些资料回答。

一、为什么不能只依赖模型本身的知识

模型参数中的知识有几个天然限制：

训练完成后，不会自动知道后来发生的变化。
很难明确指出某个结论来自哪份原始文档。
企业内部资料未必出现在训练数据中。
不能直接表达每个用户当前拥有的访问权限。
对精确、长尾事实的记忆并不稳定。

因此，在企业知识问答、客服政策、产品文档助手等场景中，更合理的分工通常是：模型负责理解问题和组织语言，外部知识库负责提供当前、可引用的事实。

二、Embedding 是什么

Embedding 通常译为“嵌入”或“向量表示”。它会把文字、图片等内容转换成一组数字，也就是向量。

这组数字不是人工定义的标签，而是模型根据内容形成的语义表示。意思相近的内容，在向量空间中通常会更接近。

例如，下面几句话用词不同，但表达相似：

怎样取消订单？
我不想买了，在哪里撤销？
订单提交后还能作废吗？

关键词搜索可能因为缺少相同词语而漏掉结果。Embedding 可以帮助系统发现它们在语义上都与“订单取消”有关。

三、语义相似度怎样用于搜索

建立语义搜索时，系统通常会先把文档片段转换成向量并保存。用户提问时，也把问题转换成向量，然后计算问题向量与文档向量的相似程度。

简化过程是：

文档片段 → Embedding → 保存向量
用户问题 → Embedding → 查询相近向量
→ 返回最相似的文档片段

常见的相似度计算方式包括余弦相似度等。产品经理不需要掌握公式，但要理解搜索结果不是简单的“有或没有”，而是根据相似度排序的候选集合。

这些向量通常保存在向量数据库或带向量索引的搜索系统中。它们的核心作用不是“替模型记住答案”，而是高效完成近邻搜索：从大量向量中快速找出最接近的候选，同时结合时间、权限、产品线等元数据过滤。

四、Embedding 不只用于知识库搜索

只要任务与“哪些内容在语义上更接近”有关，Embedding 就可能发挥作用：

用途	专业说法	大白话理解
语义搜索	Nearest-neighbor Retrieval	不要求用词相同，也能找到意思相近的内容
内容聚类	Clustering	自动把一堆反馈按主题分堆
推荐	Similarity-based Recommendation	找到与用户喜欢内容相近的其他内容
去重	Semantic Deduplication	发现换了说法但本质重复的需求或工单
分类辅助	Prototype / k-NN Classification	看新内容更接近哪一类已有样本

Embedding 给出的是相似性信号，不直接等于业务结论。例如，两条需求很相似，不代表一定应该合并；两个用户兴趣相近，也不代表权限和适用条件相同。产品规则与人工判断仍需参与。

五、相似不等于正确

语义检索比关键词搜索灵活，但仍然可能找错。

例如，“退出账号”和“删除账号”在语义上很接近，但业务后果完全不同；“企业会员退款”和“个人会员退款”可能使用大量相同词语，却适用不同政策。

因此，检索通常还要结合：

文档类型。
产品或业务线。
用户权限。
生效时间和版本。
地区、语言等元数据。
关键词或规则过滤。
对候选结果的再次排序。

实际系统常把关键词搜索、向量搜索和业务过滤组合起来，而不是只依赖一种方法。

六、为什么需要文档切分

企业文档可能很长，直接把整份文档作为一个向量，会让不同主题混在一起；检索时返回整份文档，也会浪费上下文空间。

因此，系统通常会先把文档切分为较小片段，也就是 Chunk。

切分需要在两种风险之间平衡：

Chunk 太大：主题不集中，检索结果不够精确，占用上下文更多。
Chunk 太小：完整意思被拆散，答案所需条件可能分布在多个片段中。

切分方式可以按固定长度、段落、标题层级、页面或语义边界进行。合同、产品手册、FAQ 和代码文档，适合的切分策略可能不同。

切分时还要保存元数据，例如文档标题、章节、版本、发布时间和访问权限。否则系统即使找到了文字，也可能无法判断它是否适用。

七、RAG 的完整流程

RAG 是 Retrieval-Augmented Generation 的缩写，通常译为“检索增强生成”。

它的核心流程是：

准备文档
→ 解析与切分
→ 生成 Embedding
→ 建立检索索引
→ 用户提出问题
→ 必要时改写或拆分问题
→ 召回相关片段
→ 过滤与重排
→ 组装上下文
→ 模型基于片段生成回答
→ 标注引用
→ 评估与记录

原始 RAG 研究提出了把模型参数中的知识与可检索的外部记忆结合起来的思路。今天产品中所说的 RAG 范围更广，通常还包括数据清洗、问题改写、混合检索、重排、引用、权限控制和效果评估。

八、召回、重排与上下文组装

检索阶段常见两个概念：召回和重排。

召回

召回的目标是从大量文档中快速找到一批可能相关的候选。这个阶段更重视“不要漏掉真正相关的内容”。

如果真正需要的文档没有进入候选集合，后面的模型再强也看不到它。

重排

重排会对候选内容做更精细的相关性判断，把更适合当前问题的片段排在前面。它通常计算更慢，因此只处理召回阶段得到的少量候选。

可以把它理解为：召回负责从图书馆找出几十本可能相关的书，重排负责从中挑出最值得先读的几页。

上下文组装

Context Assembly（上下文组装）是把最终选中的片段、来源和回答规则组织成模型可读的输入。它不只是机械地粘贴文本，还要处理：

哪些片段优先放入有限的上下文预算。
同一政策的新旧版本怎样排序或去重。
不同来源相互冲突时，是否要求模型明确指出冲突。
原文、元数据和指令之间怎样分隔，避免模型把材料中的话误当成系统命令。

大白话说，检索负责把资料找到，上下文组装负责把资料摆对位置。资料再多，如果新旧混杂、顺序混乱或挤掉了关键规则，模型依然可能答错。

九、引用是怎样产生的

带来源的知识库问答，通常会把文档标题、链接、页码或片段编号一起放入上下文，并要求模型在回答中标注使用了哪些材料。

但模型生成了一个引用标记，不代表引用一定正确。系统还需要确认：

引用指向的原文确实存在。
原文能够支持对应结论。
回答没有把不同文档的条件错误拼接。
用户拥有查看来源的权限。

更可靠的产品会让引用可以直接跳转到原文位置，并把“模型的总结”和“原始资料”清楚区分。

十、RAG 的常见失败

RAG 出错并不总是模型生成的问题。

失败阶段	典型问题
文档准备	文档没有收录、解析失败、内容过期
切分	条件和结论被拆到不同片段
检索	没召回正确片段，或找到了相似但不适用的内容
重排	正确材料排序太低，未进入上下文
上下文	新旧版本同时出现，模型无法判断优先级
生成	模型误读材料，或加入材料外内容
引用	引用存在，但并不支持对应结论