为什么你的RAG系统只和它的翻译模型一样好
GlobalFoundries 的 CIO 对此有一个很直接的观点：底层数据没有做到实时且可治理，就谈不上 AI Agent。
于是他先重构了这一层——用一个平台打通三大洲晶圆厂之间的数据，身份、权限、审计日志统一管理一次，而不是每个项目各搞一套。随后 IT、采购等各业务部门的 Agent 便顺势落地。
9 月 10 日，欢迎来听他分享具体做法，并现场解答你的问题。
RAG（检索增强生成）正在帮助许多企业打造满足自身特定需求的聊天机器人。但一个 RAG 系统能否成功，很大程度上取决于它所使用的 embedding 模型（即把文字转换成数字的模型）的质量。
举个例子：某产品的文档写明，年度订阅只能在 30 天内退款。基于 RAG 搭建的聊天机器人本应依据这份支持文档回答客户问题。然而，当客户询问 45 天前购买的订阅能否退款时，聊天机器人却信心十足地回答“可以”。
为什么一个看似简单的问题会被聊天机器人搞得一团糟？
问题出在 embedding 模型的行为上——它有点像 AI 的“翻译官”。答案的检索过程由它掌控，而它和负责生成最终回答的语言模型是两回事。语言模型再强，如果 embedding 模型没干好活，系统照样给不出正确答案。
本文将带你了解 embedding 模型在 RAG 架构中的工作原理，以及它为何如此关键。内容涵盖：
为什么 RAG 系统要先检索再回答
embedding 如何实现按语义检索
为什么相关的信息未必是正确的信息
为什么再好的语言模型也救不回糟糕的检索
什么样的 embedding 模型才适合 RAG 系统
如何在不盲目依赖基准分的情况下比较嵌入模型
商业 API 与本地运行模型之间的选择
为何后续更换嵌入模型成本高昂
Matryoshka 嵌入如何让你更灵活地控制向量维度
为什么 RAG 系统在回答问题前要先进行搜索
通用语言模型的知识来源于训练数据。你无法指望它了解某个公司的私有文档、内部政策或源代码，甚至连模型训练完成后才发布的企业最新信息它也无法获知。从技术角度看，每当信息发生变更就重新训练语言模型，代价相当高昂。
这正是 RAG 的用武之地：它将语言生成能力与从存储知识中检索相关细节的能力分离开来。语言模型负责理解与生成，而外部知识库则承载用于生成答案的实际信息。
RAG 包含两个阶段：索引和检索。
在索引阶段，系统对文档进行预处理：
从各种来源（文件、网站、数据库等）收集文档
提取文本内容
将文本切分为更小的段落，称为 chunk
将每个 chunk 输入嵌入模型
它将生成的向量与原始文本及元数据一起存储。
元数据可能包含文档标题、发布日期、语言、版本等信息。
在检索阶段，系统执行以下步骤：
通过同一个嵌入模型处理问题。
搜索与问题向量相近的文档向量。
检索少量文本块。例如最好的 5 个块，或类似的数量。
对这些文本块进行过滤和重新排序，并将其放入语言模型的提示词中。
最后，语言模型根据提供的提示词生成答案。
这一切的核心要点是：RAG 并不会将整个文档集合直接放入模型的提示词中。这样做会超出模型的最大上下文限制，并填入大量无关信息。同时，它还会增加成本和延迟。由 RAG 嵌入模型主导的检索阶段充当了筛选步骤，将成千上万个文本块缩减为一小部分，供语言模型查阅。
嵌入如何实现基于语义的搜索
嵌入本质上只是一个代表一段文本的数字列表。一个实际的嵌入可能包含 384、768、1024 或数千个数字。
这些数字本身并没有简单直观的标签来说明各自的含义。你无法指着某个具体的值说它代表“订阅”，而另一个代表“退款”。整体含义是分布在完整的向量中的。可以把向量理解为数学空间中某个点的坐标。Embedding 模型经过训练后，会把语义相近的文本放在这个数学向量空间中彼此靠近的位置。
正是通过这种方式，系统能把“年度套餐”和“年费订阅”关联起来，也能把“把钱退给我”和“办理退款”这样的复杂短语联系起来。相比之下，关键词搜索在问题和文档用不同词汇表达同一概念时就会捉襟见肘。而 embedding 模型比较的是文本所承载的含义，而不只是字面上的词汇。常见的技术手段包括 cosine similarity（余弦相似度）、dot product（点积）和 Euclidean distance（欧氏距离）。简单来说，embedding 模型的目标就是给出一个数学分数，衡量两个向量之间的接近程度。
Embedding 模型通常返回前 k 个结果，这就是所谓的 top-k 检索。比如 k 为 5，检索就会返回排名最高的 5 个 chunk。
Embedding 模型还支持非对称检索，即查询和文档的形式不同。查询可能是一个简短的问题，而匹配到的文档则是一段较长的说明文字。例如，查询可能是：“年度订阅 6 周后还能退款吗？”对应的答案段落则是一句陈述：“年度订阅可在 30 天内退款。”
一个只训练过比较相似句子的 embedding 模型，表现可能不如专门训练过将问题与相关段落匹配的模型。总而言之，embedding 模型决定了 RAG 系统如何界定“相似”。
为什么相关信息不等于正确信息
Embedding 模型经过训练，用于识别语义相似性。但 RAG 系统需要的是更为严格的标准：它必须找到可能包含回答特定问题所需信息的段落。问题在于，一个段落可能与问题相关，却并未明确给出答案。
举个例子，客户询问退款需要多长时间，系统却返回了一段解释“谁有资格获得退款”的内容。这两段信息都与退款有关，但只有一段涉及实际处理时间。请看下图，展示了语义搜索空间的概念。
在这种情境下，可能出现多种失败模式：
主题相似，问题不同：查询问的是“审批通过的退款多久能到账？”，检索到的段落却是“商品可在30天内退款”。该段落与退款相关，但并未回答关于时效的问题。
用词相同，实体不同：查询问的是“如何更改账单地址”，检索到的段落却讲解如何更改账号邮箱。两者都涉及更改账户信息，但指向的字段完全不同。
否定含义：考虑两段文字：“管理员可以删除归档项目”与“管理员不可以删除归档项目”。绝大多数词语完全一致，意味着它们的 embedding 可能非常接近。但显然，两者的含义截然相反。
版本与日期：知识库中可能同时存在旧政策和其替换版本。两段文本几乎完全相同，仅日期、限额或价格不同。Embedding 无法自动
