Introducing the MLPerf End-to-End RAG Inference Benchmark

介绍 MLPerf 端到端 RAG 推理基准测试

端到端评估检索增强生成（RAG）——从构建向量数据库到部署迭代式多跳问答推理流水线

2026年8月26日

MLCommons MLPerf 推理工作组很高兴推出首个全新的端到端检索增强生成（RAG）基准测试。通过在查询时从检索到的文档而非仅依赖模型权重生成答案，RAG 有效减少幻觉并利用最新私有知识，这使其成为语言模型部署的主流方式。实际生产中的 RAG 系统很少是单一模型，而是由多个模型组成的流水线，这些模型协同工作以检索相关文档并进行推理，最终生成基于事实的答案。

检索增强生成（RAG）流水线会摄入并切分源数据，将其转换为语义向量嵌入以实现存储和检索，然后将检索到的相关数据与用户查询结合，生成准确且由模型驱动的响应。该基准测试衡量整个流水线的性能。其围绕两个工作负载构建：

• 一个从文档语料库构建向量数据库的摄入流水线。
• 一个问答（QnA）流水线，通过在向量数据库上迭代多跳检索与推理步骤来回答查询，直到收集到足够证据。

这两部分共同体现了真实 RAG 部署的核心特征——由多个不同角色和规模的模型组成的流水线，通过迭代循环协同工作——这些特征是单一模型基准测试无法衡量的。

这是首个能够端到端评分完整 RAG 流水线的多组件 MLPerf 推理基准测试。本文将介绍该工作负载的独特之处、数据集与任务、模型与指标，以及参考实现。

为何需要端到端 RAG？

RAG 正变得越来越流行，对许多部署场景而言至关重要。通过将答案基于查询时检索到的文档，RAG 减少幻觉、保持答案时效性，并使通用模型能够使用其从未训练过的专有或私有知识——这正是企业所需的关键特性。

本质上，RAG 是一个多组件系统，其行为源于组件的组合方式和协同服务方式，而非单个组件本身。单一模型大语言模型（LLM）基准测试无法捕捉这一点：它们通常仅对单一提示（多数情况下不涉及分词器/反分词器）评估一个模型，因此实际 RAG 部署中由流水线特性的行为无法被衡量，同时多个模型协同服务的优化机会也从未被探索。

它也是向代理人工智能（agentic AI）基准测试迈进的重要一步。RAG 本身是代理可使用的工具之一，其多组件、多模型服务的挑战为完整代理基准测试提供了初步方向——为未来代理基准测试奠定基础。

此外，它还开辟了以往大语言模型基准测试中未涉及的优化路径。由于流水线会运行多个具有不同角色和规模的模型（而非单一模型处理单一提示），提交者可以利用单一模型基准测试无法暴露的优化杠杆。其中一些包括：

– 模型部署：组件在系统中的映射方式——例如，将小型和大型语言模型分配到不同加速器上，或在CPU上以不同精度级别运行轻量级组件，同时不损害端到端准确性标准。

– 共置：如何通过内存分区或硬件级隔离实现多模型共享单个设备。

– 多阶段调用队列调度：如何在异构加速器上通过宏批处理和微批处理实现多个并发任务的流水线重叠，覆盖整个流水线及各组件内部。

– 前缀缓存：多跳上下文在每次跳转时持续增长，因此通过复用共享前缀可将计算密集型预填充转换为内存密集型操作。

– 系统级优化/KPI：跨CPU/GPU/NIC/存储实现有效的流水线执行，展示系统级KPI以模拟真实部署场景

数据集与任务选择

任务是基于一组维基百科文档的多跳查询回答，使用FRAMES基准测试：

• 824个查询，每个查询包含真实答案及回答该问题所需的维基百科文章URL。

• 2,515篇维基百科HTML文章，基准测试附带冻结快照确保所有提交者索引相同语料库。

• ~107,000个段落——将文章切分为768字符段落，每段重叠32字符用于嵌入和索引。

选择FRAMES基准测试是因为其公开且事实性强，具有明确的地面真相，查询涵盖多种推理类型——数值型、表格型、时序型、多约束型和后处理型。

最重要的是，其查询均为多跳查询，这使得FRAMES成为对RAG系统极具挑战性的测试。多跳查询无法通过单个段落回答，需要串联多个从未同时出现的事实，每个阶段都必须发挥作用。例如（图1）：

"在社交媒体公司总部与Rahul Ligma和Daniel Johnson合影的人声称自己患有某种综合征，尽管从未获得正式诊断。这个综合征是以谁的名字命名的？" → 真实答案：Hans Asperger

没有单个段落包含答案。流水线必须跨三篇文章串联三个事实：谁发布了这张照片（Elon Musk）、他声称患有的综合征（阿斯伯格综合征）、以及该综合征的命名来源（Hans Asperger）——通过逐步重构搜索条件直到证据链形成。

图1：多跳端到端RAG示例

该基准测试通过两个独立流水线执行此数据集，每个流水线对应独立的MLPerf工作负载：

数据摄入（e2e-rag-db）仅运行一次以构建数据库；问答（e2e-rag-qna）是被评分的端到端流水线。

图2：端到端RAG的数据摄入和问答流水线

数据摄入流水线将语料库转换为可搜索的向量数据库，这是一个一次性操作。解析过程从附带基准测试的2,515个维基百科HTML文件中提取文章正文，去除维基百科元数据如参考文献和导航栏。表格和列表逐行转换为文本而非直接丢弃。分块处理将文本切分为768字符段落，每个段落标记原始维基百科URL以便溯源。块大小经过调优：较大块会混入无关文本，较小块会拆分相关事实。32字符重叠可保持边界处事实完整性。嵌入过程将每个段落编码为768维向量，向量通过FAISS HNSW图进行索引以实现快速近似相似性搜索。最终生成所有问答运行查询的向量数据库。

问答流程通过循环遍历由摄入流程（E2E-RAG-DB）生成的数据库来回答查询。回答查询并非单次模型调用，而是一个问答任务：查询会通过迭代循环运行多个组件，利用子查询逐步逼近答案。首先，查询重写器将查询分解为最多三个聚焦的子查询。每个子查询使用与摄入流程相同的嵌入器进行嵌入，并用于从数据库中检索最相似的段落。随后，重排序器会对这些候选结果进行去重并按相关性重新排序，保留最相关的几个结果。文档评分器会判断每个检索到的段落是否相关，并仅保留有帮助的结果，而充分性检查器则决定累积的证据是否足以回答查询。如果证据不足，查询重写器会生成新的子查询，重新表述并扩大搜索范围，循环最多重复五次。一旦证据充分（或达到跳转次数上限），答案生成器将基于保留的段落生成最终答案，若证据不足则返回“Unknown”。

模型选择

| 组件 | 模型 | 参数 | 精度参考 | 层数 | 向量维度 | |------------------|-----------------------|----------------|----------|------|----------------| | 嵌入 | intfloat/e5-base-v2 | 110M | FP32 | 12 | 每段落768 | | 重排序 | ColBERTv2.0 | 128 per token | - | - | - | | 查询重写器 | GPT-OSS-120B | 120B / 5.1B Active | MXFP4 | 36 | - | | 充分性检查器 | 最终答案生成 | - | - | - | - | | 文档评分器 | GPT-OSS-20B | 20B / 3.6B Active | 24 | Judge| - | | 判定 | Llama-3.1-8B | 8B | BF16 | - | - |

所有模型均可从MLCommons-Storage下载

• intfloat/e5-base-v2 是嵌入模型。该模型专为检索训练，采用独立的查询和段落编码，符合RAG的查询-文档匹配需求，在标准基准测试（MTEB、BEIR）中表现优异，且参数量仅为110M，体积紧凑且被广泛采用。

• ColBERTv2.0 是重排序模型，采用晚交互机制而非典型的交叉编码器。其基于token级别的匹配比将段落压缩为单一向量能捕捉更细粒度的相关性，且在新领域上的泛化能力更强，这符合企业场景中常见的私有文档集合需求。

• GPT-OSS-120B 负责将查询重写为优质子查询、判断证据是否充分以及生成最终答案等推理密集型任务。该模型已开放，且已被MLPerf提交者广泛部署和优化。

• GPT-OSS-20B 用于文档评分，判断检索到的段落是否相关。这是一项高吞吐量分类任务，使用较小模型能更贴近实际部署中将简单任务路由至合适规模模型的实践，而非将所有任务发送至最大模型。该模型与120B模型共享gpt-oss架构，因此支持成本较低。

• Llama-3.1-8B-Instruct 是判定模型，特意选用与GPT-OSS模型不同家族的模型以避免自我偏好偏差。它在准确率测试完成后对答案进行评分。

性能指标

MLPerf Inference传统上定义了两种服务场景：离线（Offline）和服务器（Server）。本次实现聚焦于离线场景，所有请求一次性可用且可调度以实现最大吞吐量；服务器场景将留待后续版本。每个流程报告自己的吞吐量指标：摄入流程为每秒文档数，问答流程为每秒任务数。

对于数据摄入，每秒文档数是自然的衡量单位。每个文档依次经过解析、分块、嵌入和索引处理，文档是每个提交者开始处理的固定工作单元，这使得不同系统之间的每秒文档数可以直接比较。更多细节可参考推断规则。

对于问答任务，通常的语言模型指标“每秒令牌数”并不适用：该流水线并行运行两个不同规模的语言模型和非语言模型组件，因此单一的令牌速率无法代表整个系统。类似“每秒跳步数”的跳步级指标难以解释，因为问答任务需要的跳步数是可变的。每秒任务数通过衡量真正关键的单位——一个端到端回答的查询——避免了这两个问题。与其他基准相比，这个数值看起来较小，因为单个查询可能需要多达五次跳步和十几次语言模型调用。

问答流水线本身是一个复杂且动态的工作负载，其可重复性本来就很难保证，再加上语言模型生成的固有非确定性。在性能测试中，每个跳步的每个阶段都会提供记录的参考输入，从而固定跳步次数和检索的文档数量。输出仍然正常生成但会被丢弃，这样流水线可以执行真实工作，同时运行间的变化保持最小。

准确性指标

检索质量（针对所需的维基百科URL）不是官方指标。这是一个数据库完整性检查，用于确认提交者独立构建的向量数据库的行为与参考数据库一致，确保所有人都基于相同的语料库进行回答。

完整824个查询集的参考值：

指标

数值

最终答案

35%

精确率/召回率/F1值

75% / 70% / 69%

如果提交的问答准确率至少达到参考准确率的97%，则该提交有效。

答案准确率还会根据查询所需的推理类型而变化：

答案准确率还会根据查询所需的推理类型而变化。以下分类仅作参考，单个查询可能包含多种推理类型。

推理类型

答案准确率

多约束

38%

后处理

34%

时间相关

32%

表格型

31%

数值型

多约束查询得分最高，因为它们主要需要收集离散事实，而这正是密集检索和语言模型擅长的领域。数值型和表格型查询最难：答案需要从文本或表格中提取精确数值，然后进行计算，因此单个数字误读或表格被分块边界分割都会导致整个查询失败。时间相关和后处理查询则处于中间位置，需要进行日期计算或在正确检索的基础上进行最终转换。

缩小这些差距自然指向更智能的流水线：构建系统可查询的实体和关系的知识图谱或结构化索引，实现表格感知的解析和分块以确保数值完整摄入，为答案步骤配备代码解释器等工具来处理算术和单位转换。每一步都是从当前固定的“检索-阅读”循环向能够自主选择如何查找和处理所需信息的智能代理迈进。

优化机会

E2E RAG 管道有意设计为暴露多个优化机会层，贯穿从向量数据库生成（遵循规则算法标准）到推理服务框架的完整推理堆栈，包含密集和稀疏内核以及基于 KV 缓存的调度。参考实现在此多个维度上提供了清晰但未优化的基准，为提交者在保持准确性的同时探索系统和内核改进留下了空间。

• CPU 管道：MLPerf Loadgen 将全部 824 个查询/任务一次性（在该离线场景中）发送到服务框架。这为提交者提供了探索如何在 CPU 的多个核心上分配任务的绝佳机会，通过适当的亲和性策略将任务分配到对应的加速器，并采用内存放置策略来优化 E2E 管道及管道中每个组件的性能。

• GPU 分区与 KV 缓存平衡：在加速器内部和跨加速器之间实现低延迟的多模型部署，以充分利用所有参与计算/通信/存储的组件加速器。这包括高效的低延迟高吞吐 CPU-GPU 交互、GPU-GPU/加速器之间的交互/计算与通信平衡，通过宏观和微观批量处理保持紧密的流水线。

• 不同精度的多模型：只要满足 E2E 准确性标准，所有选定模型都可以以不同精度运行。这为选择最适合系统级性能的精度提供了更大的创新机会。

结论

这是 MLPerf 首个端到端测量完整 RAG 管道的基准，而非单独测量单个模型。它捕捉到了实际部署的 RAG 系统的核心：通过迭代的多跳循环，共同提供多个不同角色和规模的模型。

这为未来的智能体 RAG 奠定了基础。其核心的检索-推理-决策循环与驱动智能体的循环相同，下一步的自然演进——工具使用、结构化检索、系统在信息查找和处理中的更多自主性——将逐步推动其向完整的智能体基准发展。我们期待与社区合作，通过 EndPoints/智能体拦截功能在不久的将来进一步完善该基准。

参考文献

• E2E-RAG 参考实现入门
• 参考实现
• MLPerf 推理基准数据下载
• 一个新的 GPT-OSS 基准和 DeepSeek R1 用于延迟优化推理的更新 – MLCommons
• MLPerf E2E-RAG 推理规则
• FRAMES 论文

致谢

（注：原文未提供具体内容，此处保留原文结构）

我们感谢 MLCommons E2E RAG 任务组成员、MLPerf 推理工作组以及 MLCommons 平台工程团队在开发此基准测试过程中提供的反馈、支持和指导。衷心感谢来自工业界和学术界的各位贡献者，你们对各种提案的评估起到了关键作用！感谢所有参与跨时区协作的人员，使这个首个独特的基准定义得以实现。

我们特别感谢 Multi-Turn 任务组，他们的思路帮助我们解决了多跳基准测试中固有的非确定性问题。

我们尤其感谢 FRAMES 数据集的作者之一 Satyapriya Krishna，她参与了我们的讨论并提供了澄清和指导。

类别

MLPerf 推理

新闻

作者

Ramesh Chukka - 任务组联合主席，Manasa Kankanala，Rajesh Poornachandran - 任务组联合主席，Saehanseul Yi

分享

• 通过电子邮件分享
• 在 Facebook 上分享
• 在 LinkedIn 上分享
• 在 X 上分享
• 复制链接