为什么你的 RAG 系统只取决于翻译模型的质量

一位CIO聚焦AI代理所需的数据基础（赞助）

GlobalFoundries的首席信息官对此有着直截了当的看法：只有当AI代理底下的数据是实时且受控的时，才会有AI代理的。

于是他先重建了这一层——一个跨大洲晶圆厂传输数据的平台，身份、权限和审计追踪只处理一次，而非按项目处理。代理则在IT、采购及其他业务职能中跟随。

9月10日加入我们，听听他是如何做到的，并让你的疑问得到现场解答。

保住你的座位

RAG，即检索增强生成（Retrieval-Augmented Generation），正在帮助许多公司构建符合其需求的聊天机器人。然而，任何此类RAG系统的成功取决于RAG系统所使用的嵌入模型（即帮助将单词转换为数字的模型）的质量。

举例来说，某产品文档规定年度订阅只能在30天内退款。用RAG构建的聊天机器人应根据这些支持文档回答客户问题。然而，当客户询问45天前购买的订阅是否可以退款时，聊天机器人会自信地回答“可以”。

为什么聊天机器人会把这个看似简单的问题搞得一团糟？

答案在于嵌入模型的行为，它有点像人工智能的翻译器。这个模型控制着答案搜索过程，与生成实际答案的语言模型不同。无论语言模型多么优秀，如果嵌入模型不能正确完成工作，它也无法给出正确答案。

本文将探讨该嵌入模型在 RAG 设置中的工作原理，以及它为何成为系统中如此关键的一部分。以下是我们将涵盖的内容：

• 为什么RAG系统会先搜索再回答
• 嵌入如何使通过意义进行搜索成为可能
• 为什么相关信息并不总是正确的信息
• 为什么更好的语言模型无法修复糟糕的检索
• 什么样的嵌入模型适合RAG系统
• 如何在不盲目信任基准分数的情况下比较嵌入模型
• 在商业API和本地运行模型之间选择
• 为什么后来更换嵌入模型会变得昂贵
• 套娃嵌入如何更好地控制矢量大小

为什么RAG系统在回答前会先搜索

通用语言模型的知识取决于训练中所学内容。你不能指望这样的模型了解公司的私人文档、政策或内部源代码。它甚至不会知道模型训练后可能发布的最新信息。

从技术上讲，每次信息变化都重新训练语言模型成本很高。

这正是RAG发挥作用的地方。它将生成语言的能力与从存储知识池中寻找相关细节的能力分开。语言模型负责理解和写作部分，而外部知识集合则包含应用于写作答案的实际信息。

RAG有两个不同的阶段：索引和检索。

在索引阶段，系统准备以下文档：

• 它从各种来源（文件、网站、数据库等）收集文件。
• 它提取了他们的文本。
• 它将文本划分为称为“块”的小段落。
• 它会把每个块发送到一个嵌入模型中。
• 它会将生成的矢量与原始文本和元数据一起存储。

元数据可能包含文档标题、出版日期、语言、版本等细节。

在回收阶段，系统遵循以下步骤：

• 它通过相同的嵌入模型传递问题。
• 它会搜索与问题向量接近的文档向量。
• 它会检索少量的区块。比如说，最好的5个区块之类的。
• 它会过滤并重新排序这些区块，将它们置于语言模型的提示中。
• 最后，语言模型会根据所提供的提示写出答案。

主要结论是，RAG不会将整个文档集合放入模型的提示词中。这是因为这样做会超出模型的上下文限制，填充无关信息。这也会增加成本和延迟。

检索阶段由RAG的嵌入模型主导，作为选择步骤，将数千篇文章减少到一小部分，供语言模型检查。

嵌入如何使通过意义进行搜索成为可能

嵌入基本上就是表示一段文本的数字列表。真正的嵌入可能包含诸如384、768、1024或数千个数字。

这些单个数字没有简单的标签来描述它们的含义。你不能只看一个值就说这意味着“订阅”，而另一个值意味着“退款”。整体意义分布在整个完整向量上。

可以把向量想象成数学空间中一个点的坐标。嵌入模型被训练成将具有相关意义的文本在这个数学向量空间中彼此靠近。

这就是系统如何将“年度套餐”与“年度订阅”连接起来。它还能将复杂短语如“拿回我的钱”与“收到退款”联系起来。相比之下，关键词搜索在问题和文档用不同词汇解释同一概念时会显得困难。

但嵌入模型试图比较文本中存在的观点，而不仅仅是词汇。常见的技术包括余弦相似度、点积和欧几里得距离。简而言之，嵌入模型的目标是生成一个数学分数，表明两个向量之间的距离。

嵌入模型通常返回前k个结果。这被称为top-k检索。例如，如果k是5，检索返回排名最高的5个块。

嵌入模型还支持非对称检索，查询和文档形式不同。查询可能是短问题。但匹配文档是较长的解释性段落。例如，查询可能是：“年订阅6周后退款吗？”答案段落是：“年订阅可在30天内退款。”

一个训练用于比较相似句子的嵌入模型，可能不如训练用于将问题与相关段落连接的模型表现良好。总结来说，嵌入模型定义了RAG系统认为的相似性。

为什么相关信息并不总是正确的信息

嵌入模型训练用于识别语义相似性。但RAG系统需要更严格的部分。它需要找到可能包含回答特定问题所需信息的段落。问题在于，一段文章可能与问题相关，但并不明确回答问题。

例如，客户询问退款需要多长时间，可能会收到一段说明谁符合退款资格的说明。这两条信息都涉及退款，但只有一条涉及实际处理时间。

请参见下图，展示了语义搜索空间的概念。

在这种情况下，可能会出现多种故障模式：

• 主题相似，问题不同：查询内容是“批准退款需要多长时间才能到达？”检索的段落写道：“购买可在30天内退款。”这段内容与退款相关，但未回答时间问题。
• 同样的话，不同的实体：查询内容是“如何更改账单地址？”检索到的段落解释了如何更改账户的电子邮件地址。两者都提到更改账户详情。但它们涉及的是完全不同的字段。
• 否定：请考虑两段文字：“管理员可以删除已归档的项目”和“管理员无法删除已归档的项目”。大多数词语是相同的。这意味着它们的嵌入可能很接近。但如你所见，它们的含义是相反的。
• 版本与日期：知识库可能包含旧策略及其替代内容。文本几乎相同，仅有日期、限制或价格差异。嵌入不会自动确定哪份文档是权威的。元数据过滤器或版本管理规则可能需要明确排除过时内容。
• 数字标识符：“年度订阅可在30天内退款”和“年度订阅可在60天内退款”这两个句子在语义上非常相似。但有一个数字有差异，这决定了最终答案。
• 领域特定的含义：通用模型可能会误解特殊词汇。例如，“捕获”在普通语言中有一种含义，在支付处理中则有特定含义。同样，“port”一词可以指网络、硬件或跨平台移动软件。通用网页文本的最佳模型可能不是法律合同、医疗报告、财务文件或源代码的最佳模型。
• 多部分问题：客户可能会提出多部分问题。例如，可能会有“我可以取消订阅吗？退款需要多长时间？”这个问题至少需要两篇文章。一篇可能解释取消资格。另一篇可能说明处理时间。只检索一个主题的模型可能会给出不完整的答案。

为什么更好的语言模型无法修复不良检索

在RAG系统中，语言模型只看到用户的问题和所选段落。它不会看到所有可能存储在向量数据库中的文档。

例如，如果未检索年度退款政策文件，语言模型将无法知道缺失信息。更强大的语言模型可能识别检索信息中不包含答案。这很有用，因为它至少可以选择不回复无效信息。

然而，这种检索失败的场景也会产生几种可能的结果：

• 模型基于其通用训练知识来回答。
• 它错误地应用了相关段落。
• 它可能会发明一个合理的规则。
• 它说现有信息不足。
• 它错误地将相互矛盾的段落组合在一起。

像“仅从提供的文件中回答”这样的提示可以减少无依据的答案。但它不能神奇地显示正确的文档。

这就是为什么在开发RAG系统时，测试和调试如此关键。开发者需要在更改提示或交换语言模型前检查检索到的块。在生成阶段解决检索问题需要更多时间。

什么样的嵌入模型适合RAG系统

选择嵌入模型时，最重要的关注点应是检索性能。模型应当非常擅长将短问题与可能包含答案的长句连接起来。

以下特征很重要：

• 领域与词汇：模型应理解文档和用户使用的语言。测试应包括缩写、内部产品名称、技术术语等。如果公司在界面中称年度订阅为“年度计划”，而在法律文件中称“年度合同”，模型应能连接这些表达。
• 语言支持：当文档、查询或两者都可能使用不同语言时，多语言模型至关重要。模型应能够将一种语言中的查询与另一种语言的答案连接起来。
• 嵌入维度：嵌入维度是每个存储向量中所包含的数值。向量越大，保留的信息越多。但尺寸并不保证更好的检索。此外，维度直接影响原始存储成本。
• 最大输入长度：限制为8192个令牌的模型可以嵌入比限制为512个令牌的模型更长的文本。但这并不意味着每份文档都应该成为一个大块。长块可能会讨论多个内容，比如退款、取消、账单地址等。一个聚焦的问题可能不如匹配与相关政策相关的较小段落更准确。
• 模型与查询速度：索引速度决定嵌入文档集合所需的时间。查询速度影响每一个用户请求。一些重要的指标包括每秒嵌入的块数、查询嵌入延迟、CPU或GPU需求、内存使用以及模型运行成本。一个以大幅增加延迟代价提升检索质量的模型，可能不是正确的选择。
• 部署要求：嵌入维度决定每个输出向量的大小。模型大小决定运行嵌入模型所需的内存和计算量。这些都是规划模型部署的关键细节。

为什么以后更换嵌入模型会很昂贵

每个嵌入模型都创建了自己的向量空间，且该向量空间是该模型独一无二的。这意味着模型A产生的嵌入与模型B产生的嵌入没有可靠的关系。

举例来说，所有文档块都用模型A嵌入。如果我们突然开始用模型B嵌入输入问题，系统最终会比较来自不兼容空间的向量。这就像苹果和橘子的比较。

即使两个模型输出的维数相同，数字的含义也可能大不相同。

这意味着整个文档语料库都需要用模型B重新嵌入。换句话说，迁移嵌入模型需要远不止运行新模型那么简单。它包括以下步骤：

• 为每个区块生成新的向量。
• 建立一个新的向量索引。
• 应用正确的元数据并设置访问权限。
• 迁移过程中保持新文档或修改文档的同步。
• 测试检索质量。
• 将生产搜索迁移到新的索引。
• 如果新系统表现不佳，保留回滚路径。

迁移过程的成本包括嵌入API费用或GPU时间、索引构建时间、临时重复存储费用、数据传输成本、评估工作以及运营风险。

迁移过程还会影响排名。例如，基准分数较高的模型在应用的特定领域术语上表现可能更差。因此，针对应用程序的测试极为重要，以确保答案质量没有下降。

一些设计选择可以让未来更安全地实施变更：

• 原始区块应成为真实的来源。向量数据库不应是处理后文本的唯一存在。
• 每个区块应有稳定标识符和内容哈希值。哈希有助于判断文本是否发生变化，是否需要新的嵌入
• 嵌入记录应包括：
  • 型号名称
  • 模型版本或修订版
  • 嵌入维数
  • 查询与文章格式
  • 归一化方法
  • 分块版本
  • 创作时间
• 新模型应获得新的索引场或向量场。其嵌入不应与旧嵌入混合。

总之，安全迁移类似于经典的蓝绿部署方法，即旧索引继续服务生产流量，同时并行构建新的索引。

明确来说，更改嵌入模型只是需要重建的操作之一。更改分块策略、解析器、清理规则、前缀或存储维度也可能需要重建文档。

套娃嵌入如何更好地控制向量大小

一个基本的嵌入模型会产生一个固定大小的向量。其维度旨在协同工作。我们不能删除大多数维度，否则会严重降低检索质量。

相比之下，套娃模型的训练方式不同。在训练过程中，该模型会配置为生成不同前缀长度的有用表示，如前256、512、1024和完整维度。

初始维度包含有用的粗略表示，后面维度则包含更详细的信息。例如，在1024维嵌入中，前256维可能包含一个有用的小表示。同样，前512维也包含更详细的表示。

最后，所有1024维都提供了完整的表示。

支持套娃模型有三种实用的存储设计：

• 存储较小的向量：系统会创建一个嵌入。然后保留前256维，并在需要时对缩短后的向量进行归一化。只有这些维度被存储。这减少了索引大小和整体搜索成本。然而，丢弃的维度将永远消失。如果我们想将系统迁移到更大的维度，就需要重新生成嵌入。
• 用更小的搜索表示存储完整向量：系统将完整的向量存储在二级存储中。但它会在快速向量索引中放置较小的前缀。这支持了未来的灵活性。我们可以从存储的向量构建更大的索引，而无需重新运行模型。
• 存储更小且完整的向量以实现两阶段检索：系统仅用256维向量（约简维度）对整个语料库进行搜索。然后检索最佳候选者的完整向量并进行精确比较。这降低了大规模初始搜索的成本。但对入围候选者保持了完全的精度。

需要说明的是，套娃嵌入并不能解决不同模型之间的不兼容问题。它们主要帮助支持模型向量空间中不同可用的尺寸。切换到另一个嵌入模型仍然需要我们之前提到的整个重新嵌入过程。

结论

正如我们讨论的，RAG系统除非先获取该答案所需的详细信息，否则无法生成可靠的基准答案。这使得嵌入模型成为RAG构建中最重要的部分。

这并不意味着其他因素不重要。RAG系统的检索质量还取决于多种因素，例如：

• 正确文件的存在
• 解析过程如何保持内容完整
• 文件如何被划分为块
• 版本管理方式
• 元数据过滤器及其工作原理
• 重新排序者如何改进候选人名单

尽管如此，嵌入模型依然是核心，因为它帮助决定哪些信息进入语言模型的上下文。它是典型RAG流程中的第一个重大相关性决策。关键教训是选择一个能够以合理成本和速度获取问题正确证据的嵌入模型。