Why Your RAG System Is Only as Good as Its Translator Model

你的 RAG 系统的质量取决于其翻译模型

ByteByteGo

2026年9月2日

一位 CIO 对 AI 代理所需数据基础的看法（赞助内容）

GlobalFoundries 的 CIO 对此有明确的观点：在数据实时且受控之前，你无法获得真正的 AI 代理。

因此，他首先重建了这一层——一个跨三大洲工厂的数据平台，身份、权限和审计追踪只需统一处理，而非每个项目单独处理。随后，AI 代理在 IT、采购和其他业务功能中逐步落地。

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

立即预留席位

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

以一个具体产品的文档为例，其中规定年度订阅仅在30天内可退款。使用 RAG 构建的聊天机器人应根据此支持文档回答客户问题。然而，当客户询问45天前购买的订阅是否可退款时，聊天机器人却自信地回答“可以”。

为什么这个看似简单的提问会让聊天机器人出错？

答案在于嵌入模型的行为，它某种程度上是 AI 的“翻译器”。该模型控制着答案搜索过程，与生成实际答案的语言模型不同。无论语言模型多么优秀，如果嵌入模型未能正确执行任务，它也无法给出正确答案。

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

• 为什么 RAG 系统在回答问题前需要先进行搜索
• 嵌入如何实现基于语义的搜索
• 相关信息未必总是正确信息
• 更好的语言模型无法修复糟糕的检索
• 哪些特性使嵌入模型适合 RAG 系统
• 如何在不盲目信任基准评分的情况下比较嵌入模型
• 在商业 API 与本地运行模型之间做出选择
• 为何后期更换嵌入模型会变得昂贵
• Matryoshka 嵌入如何提供更精细的向量尺寸控制

为什么 RAG 系统在回答问题前需要先进行搜索

通用语言模型的知识取决于训练期间所学习的内容。你不能指望此类模型了解公司的私有文档、政策或内部源代码。即使是最新的公司信息，如果在模型训练后发布，它也不会知道。从技术上讲，每次信息发生变化时重新训练语言模型的成本非常高。

这就是 RAG 的作用所在。它将生成语言的能力与从存储知识库中查找相关信息的能力分离。语言模型负责理解和撰写部分，而外部知识库则包含实际用于撰写答案的信息。

RAG 的工作分为两个阶段：索引和检索。

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

• 从各种来源（文件、网站、数据库等）收集文档。
• 提取它们的文本。

• 它将文本划分为更小的段落，称为块（chunks）。

• 它将每个块发送到嵌入模型（embedding model）中。

• 它将生成的向量与原始文本和元数据一起存储。

元数据可能包含文档标题、发布日期、语言、版本等详细信息。

在检索阶段，系统遵循以下步骤：

• 它将问题通过相同的嵌入模型发送。

• 它搜索与问题向量接近的文档向量。

• 它检索少量块。例如，最佳的5个块或其他类似情况。

• 它对这些块进行过滤和重新排序，并将它们放入语言模型的提示（prompt）中。

• 最后，语言模型使用提供的提示生成答案。

从所有这些内容中可以得出的主要结论是，RAG不会将整个文档集合放入模型的提示中。这是因为这样做会超出模型的上下文限制，并填充不相关信息。此外，这还会增加成本和延迟。由RAG的嵌入模型主导的检索阶段充当筛选步骤，将成千上万的段落减少到语言模型需要检查的小型集合。

嵌入如何使按语义搜索成为可能

嵌入本质上只是一组数字列表，用于表示一段文本。一个实际的嵌入可能包含384、768、1024或数千个数字。

这些单独的数字没有简单的标签来描述它们的含义。你不能查看某个值并说这代表“订阅”，而另一个代表“退款”。整体含义分布在完整的向量中。将向量视为数学空间中某一点的坐标。嵌入模型经过训练，使具有相关含义的文本在该数学向量空间中彼此靠近。

这就是系统能够将“yearly plan”（年度计划）与“annual subscription”（年度订阅）关联起来的原因。它也可以将“get my money back”（拿回我的钱）与“receive a refund”（获得退款）等复杂短语关联起来。相比之下，关键词搜索在问题和文档使用不同词语解释相同概念时会遇到困难。但嵌入模型试图比较文本中的概念，而不仅仅是词汇。背后常见的技术包括余弦相似度、点积和欧几里得距离。简而言之，嵌入模型的目标是生成一个数学分数，以表示两个向量之间的接近程度。

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

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

经过训练以比较相似句子的嵌入模型，可能不如经过训练以将问题与相关段落关联的模型表现好。总结来说，嵌入模型定义了RAG系统认为相似的内容。

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

例如，客户询问退款需要多长时间时，可能会收到一段解释谁有资格获得退款的段落。这两段信息都涉及退款，但只有一段谈论了实际处理时间。请参见下图，该图展示了语义搜索空间的概念。

在这种情况下可能出现多种失败模式：

• 相关主题，不同问题：查询问“已批准的退款需要多长时间才能到账？”，检索到的段落说：“购买商品可在30天内退款。”该段落与退款相关，但没有回答时间问题。

• 相同词语，不同实体：查询问“如何更改账单地址？”，检索到的段落解释了如何更改账户的电子邮件地址。两者都涉及更改账户信息，但指的是完全不同的字段。

• 否定：考虑以下两段：“管理员可以删除已归档的项目”，“管理员不能删除已归档的项目”。大部分词语相同。这意味着它们的嵌入可能接近。但如您所见，它们的含义完全相反。

• 版本和日期：知识库可能包含旧政策及其替代政策。文本可能几乎相同，除了日期、限制或价格。嵌入无法自动知道哪份文档具有权威性。可能需要显式使用元数据过滤器或版本管理规则来排除过时内容。

• 数值标识符：两句话“年度订阅可在30天内退款”和“年度订阅可在60天内退款”在语义上非常相似。但有一个数字的差异，这决定了最终答案。

• 领域特定含义：通用模型可能误解专业术语。例如，“capture”在普通语言中有一个含义，在支付处理中有特定含义。同样，“port”可以指网络、硬件或在平台之间移动软件。最适合通用网页文本的模型可能不是处理法律合同、医疗报告、财务文件或源代码的最佳模型。

• 多部分问题：客户可能会提出多部分问题。例如，可能会有类似“我可以取消订阅吗？退款需要多长时间？”的问题。回答这个问题至少需要两段内容。一段可能解释取消资格，另一段可能解释处理时间。只检索一个主题的模型可能会产生不完整的答案。

为什么更强大的语言模型无法修复糟糕的检索

在 RAG 系统中，语言模型只能看到用户的提问和选择的段落。它看不到向量数据库中可能存储的每一份文档。

例如，如果年度退款政策文档未被检索，语言模型将对缺失的信息一无所知。更强大的语言模型可能意识到检索到的信息不包含答案。这很有用，因为它至少可以选择不提供无效信息。然而，这种检索失败的情况也会导致几种可能的结果：

• 模型根据其通用训练知识进行回答。

• 错误地应用了相关段落。

• 可能编造一个看似合理的规则。

• 表示现有信息不足。

• 错误地将矛盾段落进行组合。

类似“仅根据提供的文档回答”的提示可以减少无依据的回答。但它无法让正确的文档凭空出现。

这就是为什么在RAG系统开发过程中测试和调试如此关键。开发人员需要在修改提示或更换语言模型之前检查检索到的片段。在生成阶段解决检索问题所需的时间要多得多。

什么特性使嵌入模型适合RAG系统

选择嵌入模型时最重要的考量应是检索性能。模型应非常擅长将简短问题与可能包含答案的长句进行关联。

以下特性值得关注：

• 领域和词汇：模型应理解文档和用户使用的语言。测试应包含缩写、内部产品名称、技术术语等的使用。如果公司UI中将年度订阅称为“年计划”，但法律文件中称为“年度合同”，模型应能将这些表达方式关联起来。

• 语言支持：当文档、查询或两者可能使用不同语言时，多语言模型至关重要。模型应能将一种语言的查询与另一种语言中的答案关联起来。

• 嵌入维度：嵌入维度是每个存储向量中的数值数量。更大的向量能保留更多信息。但尺寸大小并不能保证更好的检索效果。同时，维度会直接影响原始存储成本。

• 最大输入长度：限制为8192个标记的模型可以嵌入比仅限512个标记的模型长得多的文本。但这并不意味着每个文档都应该成为一大块内容。一个长段可能涉及退款、取消、账单地址等多个主题。针对特定政策的精准问题可能比匹配包含多个主题的长段更精确。

• 模型和查询速度：索引速度决定了嵌入文档集合所需的时间。查询速度影响每个用户请求。需要考虑的重要指标包括每秒嵌入的片段数量、查询-嵌入延迟、CPU或GPU需求、内存使用情况以及运行模型的成本。一个通过增加延迟显著换取少量检索质量提升的模型可能不是最佳选择。

• 部署需求：嵌入维度决定了每个输出向量的大小。模型尺寸决定了运行嵌入模型所需的内存和计算资源。这些是规划模型部署时的关键细节。

之后更换嵌入模型的成本为何高昂

每个嵌入模型都会创建自己的向量空间，这个空间是特定于该模型的。这意味着模型A生成的嵌入与模型B生成的嵌入之间没有可靠的关联性。

考虑一个示例：假设所有文档块都使用模型A进行嵌入。如果我们突然开始使用模型B对新问题进行嵌入，系统将不得不比较来自不兼容空间的向量。这就像在进行橘子与苹果的比较。即使两个模型输出的维度数量相同，这些数字所代表的含义可能完全不同。

这意味着整个文档语料库都需要使用模型B重新进行嵌入。换句话说，迁移嵌入模型需要的不仅仅是运行新模型，还涉及以下步骤：

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

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

迁移还会改变检索排名。例如，基准测试得分更高的模型可能在特定领域术语的应用场景中表现更差。因此，针对应用场景的专项测试至关重要，以确保答案质量没有下降。

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

• 原始文档块应作为事实来源。向量数据库不应是唯一存储处理后文本的地方
• 每个文档块应具有稳定的标识符和内容哈希值。哈希值有助于判断文本是否已更改并需要新的嵌入
• 嵌入记录应包含：模型名称、模型版本或修订号、嵌入维度、查询和段落格式、归一化方法、分块版本、创建时间
• 新模型应获得新的索引或向量字段。其嵌入不应与旧嵌入混合

总结来说，安全的迁移类似于经典的蓝绿部署方法，即使新索引正在并行构建，旧索引仍会继续处理生产流量。

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

Matryoshka嵌入如何提供更精细的向量尺寸控制

基础嵌入模型会生成固定尺寸的向量。这些维度是协同工作的，我们无法删除大部分维度而不严重降低检索质量。

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

虽然初始维度包含有用的粗粒度表示，但后续维度包含更详细的信息。例如，在1024维嵌入中，前256维可以包含有用的紧凑表示。同样，前512维包含更详细的表示。最后，所有1024维共同提供完整的表示。

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

• 存储较小的向量：系统生成一个嵌入表示。随后保留前256个维度，并在需要时对缩短后的向量进行归一化处理。仅存储这些维度。这减少了索引体积和整体搜索成本。但被丢弃的维度将永久丢失。如果需要将系统迁移至更高维度空间，必须重新生成嵌入表示。

• 存储完整向量并使用较小的搜索表示：系统将完整向量存储在次级存储中。但会在快速向量索引中放置一个较小的前缀。这为未来灵活性提供支持。我们可以直接从已存储的向量构建更大索引，无需重新运行模型。

• 存储小向量和完整向量实现两阶段检索：系统仅使用256维向量（降维后的表示）对整个语料库进行初步搜索。随后获取最优候选的完整向量并进行精确比较。这降低了大规模初始搜索的成本，同时保持对候选列表的完整精度。

需要明确的是，Matryoshka嵌入并不能解决不同模型之间的兼容性问题。它们主要的作用是支持模型向量空间内不同可用尺寸的适配。切换到其他嵌入模型仍然需要重新进行完整的嵌入生成过程。

结论

正如我们讨论的，RAG系统只有在先检索到生成可靠答案所需细节后，才能产生有依据的答案。这使嵌入模型成为RAG系统中最重要的组成部分。

这并不是说其他因素不重要。RAG系统的检索质量还取决于诸多因素，包括：

• 正确文档的存在性
• 解析过程对内容完整性的保持程度
• 文档的分块方式
• 版本管理机制
• 元数据过滤器及其工作方式
• 重排序器对候选列表的优化效果

尽管如此，嵌入模型依然处于核心地位，因为它决定了哪些信息能够进入语言模型的上下文。在典型的RAG流程中，它构成了第一个关键的相关性判断环节。核心经验是：选择一个能够在可接受成本和速度下，为问题检索到正确证据的嵌入模型。