谷歌前沿研究RAGO：系统优化RAG服务性能

随着人工智能技术的飞速发展，大型语言模型（LLM）在众多领域都展现出了强大的能力。但存在数据过时、容易生成错误或荒谬的信息，以及模型知识有限且难以更新。这些问题限制了它们在需要高准确性的知识密集型任务中的应用。

随着 RAG 变体的快速涌现以及不同变体之间工作负载特征的巨大差异，如何高效地部署 RAG 系统成为了一个亟待解决的挑战。

基于 RAGSchema，文章对四种具有代表性的 RAG 工作负载进行了详细的分析，揭示了它们在性能上的巨大差异。这些工作负载包括：

1. 具有超大规模检索的 RAG：在这种情况下，检索过程可能占据超过 80% 的总延迟，成为明显的瓶颈。
2. 用于长上下文序列处理的 RAG：与超大规模检索相反，在长上下文场景中，检索过程的延迟占比不到 1%，而其他部分则可能成为性能瓶颈。
3. 具有迭代检索的 RAG：在解码过程中进行迭代检索可能会阻塞整个流水线，因为解码过程需要等待检索结果。
4. 带有查询重写器和检索结果重排器模型的 RAG：即使是流水线中较小的模型，如数据库编码器，也可能因为需要处理大量标记而成为瓶颈。

RAG 为什么比纯 LLM 系统更出色？

RAG 系统的核心思想是将 LLM 的语言生成能力与实时知识检索结合起来。具体来说，RAG 在离线预处理阶段，会用 LLM 将外部文本知识编码成向量，并存储在一个向量数据库中。

与 LLM 系统不同，RAG 系统允许外部数据库独立更新，而不需要重新训练或微调模型。这意味着，当有新的知识需要加入时，只需更新数据库即可，大大简化了知识更新的流程。

1. 知识更新更灵活

与 LLM 系统不同，RAG 系统允许外部数据库独立更新，而不需要重新训练或微调模型。这意味着，当有新的知识需要加入时，只需更新数据库即可，大大简化了知识更新的流程。

2. 减少“幻觉”

RAG 系统通过依赖外部的、最新的数据库，能够有效减少 LLM 的“幻觉”现象。因为 RAG 的输出基于可检索的真实数据，而不是完全依赖模型内部的知识，这使得生成的内容更加可靠。

3. 更小的模型，更好的性能

RAG 系统可以在比 LLM 小一到两个数量级的模型上实现相当甚至更好的生成质量。这是因为 RAG 将部分知识存储外包给了外部数据库，在推理时只检索最相关的知识，从而减轻了模型的负担。

LLM 系统的服务流程

在了解 RAG 的优势之前，我们先来看看传统的 LLM 系统是如何工作的。LLM 系统的服务通常分为两个阶段：

1. 前缀阶段（Prefix Stage）

这个阶段处理输入提示，生成第一个输出标记，并填充与输入上下文相关的键值（KV）缓存。这个阶段的计算量非常大，即使在小批量处理时，也需要高计算吞吐量的加速器来高效处理整个输入序列。

2. 解码阶段（Decode Stage）

解码阶段则是逐个生成后续标记，依赖于前缀阶段生成的 KV 缓存。这个阶段是内存受限的，因为每次推理都需要访问之前标记的缓存，而计算量相对较小。

这两个阶段对性能的影响也不同：前缀阶段影响的是“首标记时间”（TTFT），而解码阶段影响的是“每输出标记时间”（TPOT）。优化 LLM 系统的性能，往往需要在这两个阶段之间进行高效的资源分配。

RAG 中的检索技术

RAG 系统的另一个核心技术是检索。检索的目的是从外部知识库中找到与输入提示相关的知识。最常见的检索方法是向量搜索，它通过将文档和查询编码为高维向量，并通过向量空间中的距离来衡量语义相似性。

1. 向量搜索的工作原理

向量搜索的目标是从一个包含大量向量的数据库中找到与给定查询向量最相似的 𝒦 个向量。由于精确的最近邻搜索在大规模数据集上成本过高，实际系统通常采用近似最近邻（ANN）搜索算法，通过牺牲一定的召回率来换取更高的性能。

2. IVF-PQ 算法

IVF-PQ 算法是 RAG 系统中最常用的向量搜索方法之一。它结合了倒排索引（IVF）和乘积量化（PQ），在大规模数据集上表现出色。这种算法特别适合处理包含数十亿甚至数百亿向量的数据库，因为它具有很高的内存效率。

3. 不同的实现方式

目前有两种流行的 IVF-PQ 实现库：Faiss 和 ScaNN。Faiss 使用高精度量化，因此搜索过程主要受限于 CPU。而 ScaNN 则采用低精度量化，能够实现更高的 CPU 吞吐量，但会更多地依赖内存。

RAG 系统的多样性：四种代表性范式

范式 I：超大规模检索

超大规模检索是 RAG 的一种常见形式。它通过在大规模语料库上进行检索，并结合较小的 LLM，来替代更大的 LLM 系统。研究表明，当数据库规模足够大时，RAG 系统可以匹配甚至超越纯 LLM 系统的质量，同时使用的模型参数量仅为 LLM 系统的十分之一。这是因为 RAG 系统在推理时动态集成外部知识，减少了对模型内部参数的依赖。

范式 II：长上下文序列处理

长上下文处理是 RAG 的另一个常见应用场景。例如，当需要基于用户上传的长文档（如超过 10 万标记）回答问题时，直接将整个文档作为提示输入是不现实的，因为这会大大增加计算成本。相反，RAG 系统将长文档视为知识库，只检索与问题相关的部分信息。这种方法大大减少了提示的大小，同时保持了与使用整个文档相似的响应质量。

与超大规模检索不同，长上下文处理引入了两个关键变化：首先，需要一个数据库编码器来构建初始的长上下文数据库；其次，数据库规模要小得多。例如，对于 10 万标记的上下文和 100 标记的片段大小，数据库可能只有 1000 个向量，而超大规模检索的数据库可能包含数十亿甚至数百亿向量。

范式 III：迭代检索

在某些场景下，仅在生成开始时进行一次检索可能不够。研究表明，迭代检索——在生成过程中定期更新检索内容——可以显著提升模型质量。这种配置特别适用于需要多跳推理的场景，每次检索提供额外的上下文以指导后续的标记生成。

在这种配置中，解码器在生成过程中灵活地发起检索。每次检索时，生成过程会暂停，将新检索到的内容通过前缀阶段处理，然后解码器才会继续生成剩余的序列。

范式 IV：查询重写器和重排器

用户提出的查询往往是模糊或复杂的，这使得直接检索相关信息变得困难。为了解决这一问题，RAG 系统引入了查询重写器和结果重排器。

查询重写器是一个 LLM，它可以重新表述用户查询，使其更清晰，或者将复杂问题分解为多个简单问题。而结果重排器则在检索结果返回后，对结果进行评分，选择与用户意图更接近的文档。这种预处理和后处理步骤显著提高了检索质量。

RAGSchema：管理复杂性的“利器”

面对如此多样化的 RAG 系统，如何有效地管理和优化它们的性能成为了一个关键问题。文章提出了 RAGSchema，这是一个结构化和模块化的抽象模型，用于捕捉各种 RAG 服务工作负载的关键性能相关属性。

RAGSchema 定义了 RAG 流水线的执行流程和组件配置。它包括以下几个关键部分：

• 文档编码器：用于将数据库文档和查询转换为向量表示的模型大小。
• 向量维度：每个数据库向量的维度。
• 数据库向量数量：取决于语料库大小和片段长度。
• 检索频率：是否允许在解码过程中进行迭代检索，以及每次序列的检索次数。
• 每次检索的查询向量数量：每次检索中使用的查询向量数量。
• 查询重写器：用于重写用户查询的模型大小。
• 结果重排器：用于对检索结果进行评分的模型大小。
• 生成型 LLM：用于生成回答的主 LLM 的模型大小。

RAG 性能的权衡分析

1. 推理组件的性能

对于一个大小为 M、序列长度为 L 的模型，处理整个序列所需的浮点运算量大约为：FLOPsinference ≈ 2 × M × L。对于较短的序列（例如 L ≤ 10³），注意力机制的二次复杂性影响较小。

2. 检索组件的性能

检索工作负载可以通过每次查询处理的数据库向量字节数来描述。与模型推理不同，解码量化数据库向量是一种完全不同的工作负载，浮点运算量并不是合适的度量标准。给定一个包含 Ndbvec 个向量的数据库，每个向量包含 Bvec 字节，每个查询扫描数据库向量的 Pscan 百分比，则每次查询扫描的总字节数大约为：Bretrieval ≈ Ndbvec × Bvec × Pscan/100。

3. 端到端 RAG 性能

RAG 服务的延迟是 RAG 流水线中每个阶段延迟的总和，而流水线的吞吐量则由最慢的阶段决定。对于一个包含 m 个阶段的 RAG 流水线，每个阶段的吞吐量为 QPSi，则端到端 RAG 服务的吞吐量为：QPSRAG = min(QPS1, QPS2, …, QPSm)。

从这个高级别模型中，我们可以得出以下几点：

• 当检索工作负载（Ndbvec × Bvec × Pscan/100）较高，而推理工作负载（2 × M × L）相对较低时，检索可能成为瓶颈。
• 在包含多个推理组件的范式中，任何模型都可能成为关键瓶颈，具体取决于其大小 M 和处理的序列长度 L。
• 多个推理阶段和检索的累积效应可能显著影响整体服务性能。

RAG 性能优化全解析

• 大型语言模型（LLM）的选择：为了全面评估 RAG 的性能，实验选取了四种不同规模的 LLM：Llama-3 1B、8B、70B 和 405B。
• 超大规模数据库的构建：既然 RAG 的优势之一是能够利用外部知识库，那么数据库的规模和质量就至关重要了。实验中采用了一个超大规模的数据库，包含 640 亿个片段，每个片段被编码为一个 768 维的向量。
• LLM 序列长度的设定：在 RAG 的应用场景中，例如问答任务，输入的序列长度（包括问题和检索到的相关内容）以及输出的生成长度（解码阶段）都会影响性能。实验参考了真实的问答数据集，将典型的问题长度设定为 32 个标记。

实验假设了一个数据中心环境，拥有丰富的资源来支持各种系统配置。主机 CPU 则模拟了 AMD EPYC Milan 处理器，具备 96 个核心、384 GB 内存和 460 GB/s 的内存带宽。

实验使用了一个经过校准的 XPU 模拟器来模拟推理过程，检索性能的模拟基于 ScaNN 库，检索到的文档需要从 CPU 传输到 XPU，实验将每次检索的数据量建模为 Ntoken × Btoken（Ntoken 为标记数量，Btoken 为每个标记的字节数）。

实验采用了以下几种常见的性能指标来评估 RAG 系统：

• TTFT（Time-to-First-Token）：从接收请求到生成第一个输出标记的平均延迟。
• TPOT（Time-Per-Output-Token）：生成序列中每个输出标记之间的平均延迟。
• QPS（Queries-Per-Second）：系统每秒能够处理的最大请求数量，即吞吐量。
• QPS/Chip：每秒请求数量与芯片数量的比值，反映系统的成本效率。

四大案例剖析 RAG 性能

案例 I：超大规模检索

超大规模检索是 RAG 的一种常见形式，类似于 RETRO [18] 的设置。这种配置在数据库规模和模型大小上都达到了极致，每次检索可能涉及一个或多个查询向量。

1. 检索瓶颈显著：超大规模检索可能成为 RAG 流水线中的主要瓶颈，尤其是在以下情况下：

• 使用较小的 LLM；
• 多查询检索；
• 推理加速器性能更好；
• 序列长度较短；
• 检索质量要求更高。

2. 系统性能对比（RAG vs. LLM-only）：RAG 8B 在 QPS/Chip 上比 LLM-only 70B 高出 1.5 倍。尽管模型参数减少了约 10 倍，但由于检索开销和需要更长的提示来整合检索信息，推理 FLOPs 仅减少了 3.2 倍。因此，QPS/Chip 的提升并不与参数减少成正比。

3. 模型大小敏感性：对于 8B 模型，检索是主要瓶颈；查询向量数量翻倍时，QPS 几乎减半。而对于 70B 模型，推理最初限制性能，直到每个检索有 4 个查询向量。当查询向量数量更多时，检索开始主导性能。

4. 硬件敏感性：随着 XPU 能力的提升，检索所占时间比例增加多达 25%。对于小模型（如 1B 和 8B），检索成为主导因素（占 50%-75% 的时间），而对于大模型（如 405B），推理仍然是瓶颈。

5. 序列长度敏感性：检索开销对解码长度和前缀长度的变化非常敏感。随着序列长度的增加，检索瓶颈逐渐减弱。例如，在较短序列长度（如 128 或 256）时，检索占 86.3% 的时间；而在较长序列长度（如 2048 和 512）时，检索开销降至 30.9%。

6. 检索配置敏感性：检索性能对每次搜索扫描的数据库向量百分比非常敏感。增加扫描的向量数量会显著增加检索所占时间比例，凸显了不同 RAG 配置下检索性能的巨大差异。

案例 II：长上下文序列处理

长上下文处理是 RAG 的另一种常见应用场景，适用于处理用户上传的长文档（如超过 10 万标记）。这种配置使用了一个小型数据库编码器（120M 参数）来处理长上下文，并通过检索来截断提示，从而显著减少了输入提示的长度。

1. 数据库编码器成瓶颈：与超大规模检索不同，长上下文处理中检索性能的影响最小。相反，数据库向量的编码过程成为瓶颈，即使编码器模型较小，但由于需要处理的上下文长度远大于生成型 LLM，编码时间随着上下文长度的增加而显著增加。

2. 上下文长度敏感性：随着输入上下文长度从 10 万标记增加到 1000 万标记，RAG 性能逐渐下降。尽管检索使生成型 LLM 的提示截断，但数据库编码器的计算成本仍然很高，尤其是在上下文长度超过 100 万标记时。

3. 与长上下文 LLM 的对比：尽管编码成本很高，但 RAG 仍然比直接处理整个长上下文的 LLM 系统高效得多。例如，在处理 100 万标记上下文时，RAG 将所需提示长度从 100 万标记减少到 512 标记，TTFT 加速了 2852.6 倍，QPS/Chip 提高了 6633.9 倍。这种效率提升主要源于两个原因：

• RAG 使用小型数据库编码器（如 120M 参数），计算成本远低于处理整个上下文的大型 LLM。
• RAG 显著减少了提示长度，节省了 XPU 内存，从而在生成阶段能够处理更大的批量，提高了 QPS/Chip。

案例 III：迭代检索 + 前缀

在超大规模检索的基础上，这种配置引入了迭代检索，允许在 256 标记的解码过程中随机触发 2、4 或 8 次检索。

1. 迭代检索频率敏感性：TPOT 延迟随着检索频率和解码批量大小的增加而增加。在较小的解码批量大小（如 1、4 和 16）时，解码步骤仍然是 TPOT 延迟的主要贡献者，检索频率的影响较小。然而，在较大的解码批量大小时，解码步骤的 QPS/Chip 提高，检索频率的影响变得更加显著。
2. 迭代检索批量大小敏感性：解码批量大小、迭代检索批量大小和 TPOT 延迟之间存在复杂的相互作用。在较小的解码批量大小时，增加迭代检索批量大小会导致延迟显著增加，因为难以在给定时间间隔内找到足够的检索请求进行批量处理，从而引入停顿。而在较大的解码批量大小时，增加迭代检索批量大小可以降低延迟，因为有足够的活跃解码序列来快速批量处理检索请求。
3. 解码停顿现象：由于批量处理引入的等待时间，解码延迟显著增加。当解码批量大小与迭代检索批量大小相似时（如均为 64），归一化解码延迟可达 2.77 倍。这表明在选择批量大小时需要仔细权衡，以避免因批量处理导致的解码停顿。

案例 IV：查询重写器和重排器

这种配置在超大规模检索的基础上，引入了一个 8B 的查询重写器和一个 120M 的重排器。查询重写器处理 32 标记的问题并生成相同长度的重写问题，而重排器评估 16 个最近片段（每个 100 标记），并返回前 5 个最近邻。

1. 重排器影响小：重排器对整体 RAG 性能的影响可以忽略不计，因为它只处理少量数据。
2. 查询重写器影响大：查询重写器显著增加了 TTFT 延迟（2.4 倍），因为它是自回归生成模型，处理时间较长。这表明在引入查询重写器时，需要考虑应用的延迟容忍度。

RAG 服务系统优化：RAGO

RAG 系统的组件复杂多样，工作负载差异巨大（如第 5 节所述），传统的“一刀切”解决方案根本无法实现最优的服务效率。为了解决这一挑战，文章提出了 RAGO，这是一个系统化的框架，用于设计和优化各种配置下的 RAG 服务系统。

RAGO 的三大调度决策

RAGO 的每个调度解决方案都包含三个关键的系统决策：任务放置、资源分配 和 批量策略。

RAGO 支持混合的共置-分离任务放置策略。对于一些计算密集型的组件（如数据库编码器、重排器、查询重写器的前缀阶段和主 LLM 的前缀阶段），将它们共置在同一组 XPU 上可以平衡工作负载。

资源分配

对于共置的推理阶段，RAGO 选择合适的加速器数量以确保高效执行。对于检索操作，RAGO 确定所需的 CPU 服务器数量以满足工作负载需求。框架平衡吞吐量需求和延迟约束，以确保最优性能。

批量策略

RAGO 允许流水线的每个阶段采用不同的批量大小，以在每个阶段灵活平衡延迟和吞吐量。在接收到用户请求的突发时，可以选择在解码之前的所有阶段使用相同的批量大小，或者将请求划分为具有相同或不同批量大小的微批量。

RAGO 评估

为了评估 RAGO 的性能，我们选择了第 5 节中的四个 RAG 案例研究。这些案例涵盖了从超大规模检索（C-I）到长上下文序列处理（C-II）以及带有查询重写器和重排器的 RAG（C-IV）等多种场景。

RAGO 与基线的对比

在 C-II 中，RAGO 在最大 QPS/Chip 上比基线提高了 1.7 倍。V），在 C-IV 中，RAGO 在 QPS/Chip 上比基线提高了 1.5 倍。

RAGO 通过优化的任务放置、资源分配和批量策略，缓解了这些瓶颈。

帕累托前沿分析

虚线表示全局帕累托前沿，而每条实线对应于特定的放置和分配策略组合。整体帕累托前沿由多个不同的计划构成，每个计划都体现了 TTFT 和 QPS/Chip 之间的独特权衡。

例如，在 C-IV 中，选择最优化吞吐量的计划会导致 TTFT 约增加 40%，但 QPS/Chip 提高了 1.5 倍。

那么，如何系统的去学习大模型LLM？

作为一名从业五年的资深大模型算法工程师，我经常会收到一些评论和私信，我是小白，学习大模型该从哪里入手呢？我自学没有方向怎么办？这个地方我不会啊。如果你也有类似的经历，一定要继续看下去！这些问题啊，也不是三言两语啊就能讲明白的。

所以我综合了大模型的所有知识点，给大家带来一套全网最全最细的大模型零基础教程。在做这套教程之前呢，我就曾放空大脑，以一个大模型小白的角度去重新解析它，采用基础知识和实战项目相结合的教学方式，历时3个月，终于完成了这样的课程，让你真正体会到什么是每一秒都在疯狂输出知识点。

由于篇幅有限，⚡️ 朋友们如果有需要全套 《2025全新制作的大模型全套资料》，扫码获取~

👉大模型学习指南+路线汇总👈

我们这套大模型资料呢，会从基础篇、进阶篇和项目实战篇等三大方面来讲解。

👉①.基础篇👈

基础篇里面包括了Python快速入门、AI开发环境搭建及提示词工程，带你学习大模型核心原理、prompt使用技巧、Transformer架构和预训练、SFT、RLHF等一些基础概念，用最易懂的方式带你入门大模型。

👉②.进阶篇👈

接下来是进阶篇，你将掌握RAG、Agent、Langchain、大模型微调和私有化部署，学习如何构建外挂知识库并和自己的企业相结合，学习如何使用langchain框架提高开发效率和代码质量、学习如何选择合适的基座模型并进行数据集的收集预处理以及具体的模型微调等等。

👉③.实战篇👈

实战篇会手把手带着大家练习企业级的落地项目（已脱敏），比如RAG医疗问答系统、Agent智能电商客服系统、数字人项目实战、教育行业智能助教等等，从而帮助大家更好的应对大模型时代的挑战。

👉④.福利篇👈

最后呢，会给大家一个小福利，课程视频中的所有素材，有搭建AI开发环境资料包，还有学习计划表，几十上百G素材、电子书和课件等等，只要你能想到的素材，我这里几乎都有。我已经全部上传到优快云，朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】

相信我，这套大模型系统教程将会是全网最齐全 最易懂的小白专用课！！