RAG-Tester：检索增强大语言模型的自动化端到端测试（中文全译）

RAG-Tester：检索增强大语言模型的自动化端到端测试（中文全译）

翻译说明：本文是 arXiv 论文 RAG-Tester: Automated End-to-End Testing of Retrieval-Augmented Large Language Models（arXiv:2608.00054）的中文全译，由智测团队翻译。原作者：Ange Maiztegui、Jon Ayerdi、Miren Illarramendi、Aitor Arrieta（Mondragon University，西班牙）。原文以 CC BY 4.0 许可发布，允许翻译与再分发，须署名。译文保留原文全部章节、实验数据与结论；参考文献列表与文内引注编号从略，原文附录中的完整提示词与逐配置数据表从略并在文中指明。模型名、工具名、基准名、指标名保留英文。图 1（执行流架构）随文保留，版权归原作者。开源代码：https://github.com/Anje13/GBL_RAGTester ，复现包：https://zenodo.org/records/21606024 。

摘要

背景：检索增强生成（RAG）使大语言模型（LLM）能在推理时纳入外部的、最新的、领域特定的或专有的信息。然而，RAG 系统的可靠性取决于多个组件之间的交互，包括生成模型、嵌入模型、检索机制和提示构造策略。因此，这些组件的不同组合可能表现出截然不同的失败行为，这激发了系统性、自动化测试的需求。

目标：本工作旨在自动化 RAG 赋能 LLM 的端到端测试，并生成能跨不同 LLM 与嵌入模型组合暴露失败的测试用例。

方法：我们提出 RAG-Tester，一个由四个阶段组成的自动化测试方法：生成检索文档、生成测试输入与期望输出、执行生成的测试，以及用 LLM 当裁判做自动评估。测试生成策略纳入了复杂文档段落、无依据查询和文档覆盖准则。我们用八个 LLM 和六个嵌入模型评估 RAG-Tester，得到 24 个兼容的 LLM–嵌入配置，并与一个基线测试输入生成器比较。

结果：在 72,000 次测试执行中，RAG-Tester 检测到 21,633 个失败，而基线检测到 20,293 个，代表 6.6% 的增加。RAG-Tester 在 24 个被评估配置中的 20 个上优于基线，并暴露了包括检索不准、无依据回答、对检索上下文使用不完整，以及解读复杂段落的困难在内的失败。

结论：结果表明，自动化、面向覆盖的测试生成能有效暴露 RAG 系统中检索与生成组件交互产生的失败。RAG-Tester 提供了一个端到端机制，用于比较 LLM–嵌入配置并在部署前评估其可靠性。

关键词：LLM，测试，RAG

1 引言

大语言模型（LLM）的近期进展带来了自然语言理解和生成在广泛任务上的实质改进，包括问答、代码生成、对话 agent 和决策支持系统。尽管有这些进展，传统 LLM 主要依赖编码在其参数中的知识，使其固有地受限于过时的训练数据、易于幻觉，且无法提供可验证的、上下文特定的信息。

检索增强生成（RAG）作为缓解这些局限的有前景范式出现，它把外部知识检索机制与神经文本生成整合。通过在推理时纳入相关文档，RAG 系统能产出更准确、更新、有源材料根基的回答。因此，基于 RAG 的 LLM 正被越来越多地采用于法律、医疗和企业知识管理等高影响领域，那里可靠性和可追溯性至关重要。

然而，从软件工程视角，RAG 赋能 LLM 的开发引入了新挑战。与独立 LLM 不同，RAG 系统的正确性取决于多个交互组件，包括嵌入模型、检索流水线、排序机制和提示构造策略。因此，失败可能源于不同来源，如检索不准、上下文整合不完整或幻觉回答。这种复杂性使 RAG 系统的系统性、自动化测试至关重要，却不平凡。

现有评估 RAG 系统的方法大多依赖基于基准的评估或场景特定的评估框架。虽然基准技术提供标准化比较，它们在覆盖上固有受限，因为聚焦预定义数据集或狭窄应用场景。结果，它们常无法暴露多样的失败模式，尤其是检索与生成组件交互产生的那些。更重要的是，当前方法缺乏能系统生成测试输入、定义期望输出，并在不同条件下评估系统行为的端到端自动化测试机制。

为解决这些局限，我们提出 RAG-Tester，一个用于测试 RAG 赋能 LLM 的端到端自动化、系统性框架。我们的方法跨多个质量维度评估 RAG 系统，包括事实性、相关性、完整性和清晰度。所提框架由四个主要步骤组成。第一，它自动生成检索文档（本文聚焦 PDF 文件，同时保持对其他格式的可扩展性）。第二，它分析这些文档以生成多样的测试输入及其对应期望输出。第三，它在被测 RAG-LLM 上执行生成的查询。最后，它采用 LLM 当裁判机制来自动评估产出的输出是否与期望的匹配。

我们做了一个大规模实证评估，涉及八个最先进 LLM（四个闭源、四个开放权重），结合三种不同嵌入技术，得到 24 个不同配置。总体而言，我们生成了 3,000 个测试输入并执行了总计 72,000 个测试用例。我们的方法检测到 21,633 个失败，相比我们工具的一个基线变体识别的 20,293 个，失败检测增加 6.6%。这些结果表明 RAG-Tester 能有效揭示 RAG 系统中常被现有评估方法忽略的微妙、多样的失败模式。

2 背景

2.1 检索增强生成

检索增强生成（RAG）是一种把信息检索与语言生成结合、以产出有外部知识根基回答的架构范式。与回答主要基于训练期间编码知识的独立 LLM 不同，RAG 赋能的 LLM 在推理时从外部语料检索信息。这使其能纳入专有、领域特定或最近更新的信息，而无需重训底层模型。通过把生成条件化在检索到的证据上，RAG 能改进生成回答的事实根基、透明度和可追溯性。

一个典型 RAG 流水线由若干互连阶段组成。首先，源文档被收集、预处理并分成更小的段落或块。然后每个块用嵌入模型转换成向量表示。这些表示存进一个向量数据库，它通过像 FAISS 这样的实现支持高效的基于相似度的检索。在推理时，用户查询用与索引文档兼容的嵌入模型编码。所得查询向量与存储的文档向量比较，最相似的前 k 个段落被选为上下文证据。这些段落连同原始查询被纳入提示，之后生成模型产出以两个信息源为条件的回答。取决于具体架构，流水线在生成前还可能包括查询重写、元数据过滤、混合词汇-语义检索、段落重排或上下文压缩。

因此，最终回答的质量取决于多个组件的正确运行。嵌入模型必须保持查询与文档段落间的语义关系，检索机制必须识别相关证据，提示构造策略必须以生成模型能有效解读的形式呈现这些证据。然后模型必须提取、组合并表达检索到的信息，而不引入无依据的内容。

检索质量尤其重要，因为检索期间引入的错误会传播到生成阶段。当相关段落未被检索到时，模型可能缺乏回答查询所需的信息。反过来，检索到无关、不完整或矛盾的段落可能分散模型注意并导致不准确或误导性回答。然而，成功检索并不保证正确的最终回答：生成模型可能忽略相关证据、误解它、遗漏重要细节，或引入检索上下文不支持的信息。因此，RAG 系统必须被视为端到端系统，其行为从文档处理、嵌入、检索、提示构造和语言生成的交互中涌现。

2.2 RAG 系统的质量评估

RAG 系统的质量可在不同层级评估。组件级评估评价流水线的各个阶段，而端到端评估检查从查询和外部知识语料产出的最终回答的质量。两种视角都必要，因为单个组件的正确性不一定意味着完整系统的正确性。

检索组件通常用信息检索指标评估。精确率衡量检索到的段落中与查询相关的比例，而召回率衡量成功检索到的相关段落比例。像 Recall@k 这样的指标评估相关证据是否出现在前 k 个检索结果中。平均倒数排名衡量第一个相关结果排得多高，而归一化折损累计增益同时考虑多个检索段落的相关性和排序。这些指标提供了对嵌入和排序机制有效性的洞察，但它们不直接衡量生成模型是否正确使用检索到的证据。

端到端评估聚焦查询、检索上下文和生成回答之间的关系。RAG 评估中常考虑若干互补的质量维度。答案相关性捕捉回答是否直接处理用户的查询。忠实度（也称根基性）评估回答中包含的主张是否被检索证据支持。完整性衡量回答是否包含回答查询所需的基本信息，而清晰度关乎生成文本的连贯、精确和可读性。

这些维度捕捉不同的失败条件。一个回答可能相关但不忠实——当它用无依据信息直接回答查询时。它可能忠实但不完整——当所有包含的陈述都被上下文支持但重要事实被遗漏时。类似地，一个系统可能检索到正确段落却产出不正确答案，因为模型未能解读或综合可用证据。因此，只评估最终答案准确性可能掩盖 RAG 流水线内失败的起源和特征。

根基性尤其重要，因为检索增强减少但不消除幻觉。一个生成回答是有根基的，当它的事实主张能追溯到检索证据时。证据归属机制，如要求模型用引文或引用支持回答，能便利这一评估并改进生成信息的可验证性。然而，一个回答即使引用了正确的源材料，仍可能包含微妙的扭曲、无依据的概括或编造的细节。

2.3 RAG 系统的测试与测试 Oracle

（本节介绍 RAG 系统测试和测试 oracle 的背景，为第 3 节的方法铺垫。原文此处综述了 RAG 测试面临的 oracle 问题——由于回答是自由文本且依赖检索内容，难以预先定义唯一的正确输出，因此需要新的 oracle 机制。完整论述见英文原文 §2.3。）

3 RAG-Tester

3.1 概览

RAG-Tester 由四个主要组件组成，它们共同形成一个针对检索增强 LLM 的端到端自动化测试执行框架。算法 1 和图 1 概述了 RAG-Tester 的主要步骤并说明这四个组件如何交互。作为输入，RAG-Tester 接收一个文本文档和一些指令，产出一组测试结果作为输出。RAG-Tester 执行的第一个任务是测试文件的自动生成（第 2 行），这些文件稍后将被被测 LLM（LLMUT）检索。为完成这一点，我们的工具用一个 LLM 创建不同长度、复杂度和主题的文件。然后这些文件与 D_man 中的其他文档合并（第 3 行）——测试工程师可选地手工纳入后者。这带来诸多好处，包括在特定应用上下文中评估 RAG 系统。在第二阶段，RAG-Tester 处理 D 中的文档并生成测试输入（TI）和期望测试输出（TO_exp）的配对（第 4 行）。D 中每个文档生成的测试用例数是 N_test。然后这些测试输入被批量执行（第 5 行），所得输出（TO）通过用我们的测试 oracle 把它们与期望输出比较来评估（第 6 行），oracle 提供测试结果。

算法 1：RAG-Tester 整体概览

输入：N_f：要检索的文件数
      D_man = {d_1, d_2, ..., d_m}：手工纳入的要检索文件
      N_test：为每个检索文档生成的测试用例数
输出：TR：最终测试结果

1  function RAG-Tester
2      D ← GenerateFiles(N_f)
3      D ← D ∪ D_man
4      TI, TO_exp ← GenerateTestInputs(D, N_test)
5      TO ← ExecuteTestInputs(LLM_UT, TI)
6      TR ← EvaluateTests(TO, TO_exp)
7      return TR

3.2 测试文件生成器

我们的初始原型聚焦于生成供 LLMUT 检索的 PDF 文件，尽管 RAG-Tester 能轻松扩展以支持其他文件类型。RAG-Tester 利用一个 LLM（具体是 GPT-5 Nano）自动产出不同大小、复杂度和主题的 PDF 文件。设计有效的系统和用户提示对引导这一生成过程至关重要。原文附录 A 和 B 展示了用于这个 LLM 的提示词。

一方面，我们在系统提示中指定文档的技术方面，即期望长度、细节层级（如全面详尽、简洁摘要、高度技术性……），以及语气或写作风格（如正式或随意）。我们进一步定义与文档结构、内容要求和格式指南相关的元素。这些配置为后续用户提示准备好 LLM。另一方面，在用户提示中，可选地提供文档的主题和名称，尽管 LLM 能自主定义两者。用户还可提供文档是否应包含任何特定章节的信息。

负责生成可检索文件的 LLM 以 Markdown 格式产出其输出。然后文件生成器自动把这一 Markdown 内容转换成 PDF 文件。

3.3 测试输入生成器

在生成供 LLMUT 检索的文件后，RAG-Tester 聚焦于测试输入（TI）和期望测试输出（TO_exp）的生成。对 D 中的每个文件，测试输入生成器生成一组 N_test 个测试用例。

值得一提，每个被测源文档被分成 N_test 个章节（取决于指定查询的数量），每个章节由段落结尾或最大 token 数界定。分割完成后，每个块只用于一个测试查询，确保没有文本区域被多次使用。

为生成这些查询，使用一个系统和用户提示策略，类似测试文件生成。系统提示（原文附录 C）用于确定技术指令，如问题类型规格——即每个测试要包含的标签、简短描述，以及生成时要遵循的一组规则——所需输出格式（即 LLM 需要提供的信息列表）和质量标准，使查询清晰、测试文档的不同方面，且不能只用是或否回答。用户提示（原文附录 D）指定要考察的文档块和要生成的查询数。当所选问题类型是自然语言处理时，块可按其 Flesch 阅读易读度分数排序。具体来说，生成器首先用 Flesch 阅读易读度分数——一个成熟的、范围 0 到 100 的可读性指标，值越低表示文本复杂度越高——衡量每个文档章节的复杂度。然后章节按分数升序排序，测试输入生成器选择 N_complex 个最复杂的段落，RAG-Tester 借此暴露失败。

第二，RAG-Tester 的测试输入生成策略还产出一组否定拒绝型查询。这些问题有意围绕源文档中不存在的信息构造。它们的目的是验证 LLMUT 是否恰当拒绝无依据的主张，而非幻觉出答案。为生成这些查询，RAG-Tester 用两种互补方法。第一种方法旨在不包含文档中可用的章节，要求 LLM 随机生成问题。第二种方法从 D 中选一个不同文档，重复前述相同的分块过程，确保生成的问题与最初选来检索的文档无关。这两种方法让 RAG-Tester 能评估模型在处理缺失或不完整证据时的稳健性。

最后，我们的策略纳入一个基于覆盖的机制，旨在最大化前两步尚未生成的文档部分。虽然基于复杂度和拒绝型的查询瞄准特定类型的弱点，它们可能无法均匀覆盖输入文档的所有章节。为解决这一点，测试输入生成器分析哪些段落或内容区域尚未贡献于任何测试用例，并选择额外片段以确保更广覆盖。通过提示一个 LLM 从文档中这些代表不足的部分生成问题，RAG-Tester 增加了测试输入的多样性，并提高了暴露可能源于被忽略或较不显眼内容的失败的可能性。

3.4 测试执行器

一旦为所有选定文档生成了测试用例文件，这些测试查询就能用不同的被测模型组合来回答，每个组合由一个 LLM 和一个嵌入模型构成。测试执行器的一些基本组件包括：RAG 链、向量存储和提示模板。

关于嵌入，使用 Chroma 向量存储。这样，每个文档能有其专属的嵌入存储，且由于文档被重复使用，一旦创建向量存储就消除了创建新存储的需要，在计算和时间上都更高效。嵌入、RAG 链和提示模板用 LangChain 创建。RAG 链通过组合 LLM 和提示模板构成，前者来自 OpenAI 或 Ollama，提示模板指定模型的角色和要遵循的指令——它被告知，如果没有足够信息恰当回答测试，应输出「信息不足以回答此问题」或「我不知道」。此外，它还包含问题和文档章节，以及如何格式化生成输出。

执行流程始于把测试文件匹配到其原始文档，因此在每次迭代中信息只取自源文本文件。选定文档后，所有测试查询由所有 LLMUT 执行，以 JSON 格式输出结果并解析到一个 JSON 文件。每个 LLMUT 和 D 创建一个答案文件。

3.5 测试 Oracle

我们方法的最后阶段是评估。为此，我们采用 LLM 当裁判策略来解决在测试 LLM 语境中众所周知的测试 oracle 问题。虽然简单，这一策略也被其他 LLM 测试技术采用。评估器获得由 LLMUT 提供的一组测试输出（TO）和由测试输入生成器生成的一组期望测试输出（TO_exp）。oracle 逐一检查两个输出是否语义等价。用于此任务的特定提示见原文附录 F。基于初步分析，我们选择 GPT-4.1 Nano 作为 RAG-Tester 的 LLM 裁判，尽管我们的方法能轻松整合任何其他 LLM。重要的是，这个 LLM 最好不同于被测的那个。给定 TO 和 TO_exp，LLM 裁判评估以下四个准则：

• 忠实度：衡量模型答案在事实上扎根于、并在语义上一致于期望答案和检索证据的程度。一个回答被视为忠实的，如果它不引入源文档所不能证成的无依据主张、矛盾或幻觉信息。这一准则在 RAG 系统中尤其关键，那里生成必须严格与检索上下文对齐。任何偏离真值事实内容的情况，包括微妙扭曲或编造细节，都负面影响忠实度分数。在我们的框架中，忠实度充当主要正确性条件：如果它被评估为 false，总体判定自动为失败。

• 相关性：评估生成回答是否直接处理测试输入中提出的查询。一个回答可能事实正确却部分无关——如果它包含切线信息、题外话或对回答特定问题无贡献的多余解释。因此相关性准则聚焦查询意图与产出答案之间的对齐。高相关性表明模型保持聚焦于任务并避免不必要的内容生成。

• 完整性：评估答案覆盖期望输出中所有基本元素的程度。在许多 RAG 场景中，正确答案需要包含从源文档提取的多个事实、条件或关系。一个遗漏关键组件的答案被视为部分完整，即使所包含的信息正确。重要的是，如果被测模型提供了超出参考答案的额外正确且有依据的细节，只要忠实度得到保持，这被正面评估。因此完整性捕捉所需信息的覆盖，而非措辞上的严格等价。

• 清晰度：检查回答的语言和结构质量。这包括连贯性、逻辑组织、语法正确性和语言精确性。即使一个回答事实正确，糟糕的组织或模糊的措辞可能降低其实用价值。清晰度确保答案不仅正确，还可理解、结构良好。这一准则在真实 RAG 应用中尤其相关，那里输出直接被最终用户消费。

• 关键词匹配：提供一个额外的词汇级验证机制。在测试生成期间，每个期望答案关联一组基本关键词，代表正确答案中应出现的关键实体、概念或术语。oracle 检查这些关键词是否出现在模型答案中。评级为 true 表示所有必需关键词都出现，partially 表示只有子集出现，false 表示都不出现。虽然仅关键词匹配不足以判定语义正确性，它充当强化完整性和忠实度评估的补充信号。

每个准则被赋予三个可能评级之一：True、Partially 或 False，为计分目的分别映射到数值 1、0.5 和 0。总体判定通过取五个准则分数的算术平均计算。如果最终平均低于 0.5，答案得到失败判定。如果平均为 0.5 或更高，答案得到通过判定。还要注意，如果忠实度准则为 False，我们把测试视为失败。

4 工具支持

我们把 RAG-Tester 作为开源的端到端 RAG-LLM 测试生成工具提供，它通过用户友好的 Web 界面或基于代码的环境测试检索增强语言模型。两种界面在核心功能上对等：PDF 生成、测试生成、测试执行和测试评估。

虽然基于代码的版本允许直接执行和调试，Web 界面提供更有吸引力的测试结果可视化，使识别优势和弱点更容易。此外，RAG-Tester 用模块化架构设计，因此如果开发者想实现新的 LLM 提供者、文档加载器等，过程保持简单且可扩展。使用 Web 界面的工具演示可在线找到。

5 实验设计

5.1 研究问题

我们的评估旨在回答以下四个研究问题（RQ）：

• RQ1 - 总体性能：RAG-Tester 在检测 RAG 赋能 LLM 的失败上表现如何？借此我们想评估 RAG-Tester 在测试不同 LLM 和嵌入组合时提供的总体性能。
• RQ2 - 与基线比较：RAG-Tester 与一个基线测试输入生成器相比如何？借此我们想把 RAG-Tester 与我们开发的测试输入生成器的简化版本比较。
• RQ3 - PDF 生成策略：自动生成上下文 PDF 文件与使用现有 PDF 文件之间有何差异？在第三个 RQ 中我们想回答以自动化方式生成上下文文件是否存在差异。
• RQ4 - Oracle 精确率：RAG-Tester 的测试 oracle 精确率如何？由于 RAG-Tester 的 oracle 采用 LLM 裁判，它可能对幻觉有一定倾向。这一 RQ 旨在检查其精确率，以调查所提测试 oracle 是否及在多大程度上触发假阳性。

5.2 评估指标

为评估测试 oracle 的性能，用 Cochran 样本量公式从总计 41,926 个检测到的失败中（结合所有基线和 RAG-Tester 测试，在 OpenAI 和 Ollama 上）抽取了 382 个失败测试的样本。目标是检查这一样本并把每个测试分入两类之一：

• 真阳性（TP）：被正确识别为失败的失败测试
• 假阳性（FP）：被错误识别为失败的通过测试

虽然未使用，另外两类也被定义：假阴性（FN，被错误识别为通过的失败测试）和真阴性（TN，被正确识别为通过的通过测试）。

从这些分类，计算两个关键性能指标：oracle 精确率（衡量被标记为失败的测试中真正失败的比例）和假发现率（FDR，捕捉被错误标记的比例）。这两个指标共同清晰描绘了测试 oracle 区分真失败与假警报的可靠程度。

由于人工审查全部 382 个测试极其耗时，改用多数投票策略。四个比测试 oracle 更大的 LLM（GPT-4o、GPT-5、Llama 3.1 70B 和 Qwen 2.5 72B）各自独立评估每个测试，四个模型中最常见的判定被选为最终分类。

5.3 基线技术

对基线，我们移除了原始测试输入生成算法的一些关键特征。具体来说，基线获取上下文文档（即一个 PDF）并通过不遵循任何策略（例如不考虑文档覆盖或段落复杂度）生成 N_test 个测试输入。

5.4 测试生成设置

在我们的评估中，我们自动生成了 30 个 PDF 文件，并从 Kaggle 手工选择了 30 个 PDF 文件，即我们用总计 60 个 PDF 文件作上下文。对每个文档，每种技术（即 RAG-Tester 和基线）生成 50 个不同测试输入。也就是说，RAG-Tester 及其基线版本各生成 3,000 个测试用例。

从 Kaggle 选择 30 个 PDF 的理由如下：每个文档必须至少 5 页长，且整体选择需覆盖多样格式，包括带表格和图像的文档以及更简单的纯文本文件。包含页眉、页脚和图形元素的文档被优先考虑，此外还有带多样文本样式和字体大小的文档。这种多样性是有意的，因为跨不同文档结构测试能更全面地描绘模型处理真实 PDF 的好坏。

5.5 所选大语言模型与嵌入

我们选择闭源和开放权重 LLM 作为测试对象。具体来说，我们用四个 OpenAI 模型（GPT-3.5 Turbo、GPT-4.1 Mini、GPT-4o Mini 和 GPT-5 Nano）和四个开放权重模型（Gemma 3:8b、Qwen 3:8b、DeepSeek R1:8b 和 Llama 3.2:3b）。选择闭源模型的标准是（1）它们被广泛使用并构成最先进 LLM，（2）它们的 token 成本不过高。另一方面，对开放权重模型，我们用广泛使用的 LLM，但能在我们 GPU 集群上通过 Ollama 执行。更高参数的 LLM 因计算成本高而无法执行。

此外，选择了不同的文本嵌入。对 OpenAI 的模型，OpenAI 提供了使用三种不同嵌入的选项：text-embedding-3-small、text-embedding-3-large、text-embedding-ada-002。同时，对开放权重 LLM，我们用另外三种兼容嵌入：bge-large:335m-en-v1.5-fp16、nomic-embed-text:v1.5 和 intfloat-e5-base-v2:q8_0。注意 OpenAI 的那些嵌入与 Ollama 不兼容。

6 结果分析与讨论

6.1 RQ1 - 总体有效性

RAG-Tester 在全部 24 个被测组合（2 个 LLM 提供者中的 4 个 LLM × 3 个嵌入模型）上都被证明在检测 RAG 赋能 LLM 的失败上高度有效。原文表 6 呈现了四个 OpenAI 模型（GPT-3.5-Turbo、GPT-4.1-Mini、GPT-4o-Mini 和 GPT-5 Nano）配三个 OpenAI 嵌入模型的失败计数。原文表 7 显示四个开放权重模型（Gemma-3:8b、Qwen-3:8b、DeepSeek-R1:8b 和 Llama-3.2:3b）配三个兼容嵌入的等价结果。

在 RAG-Tester 总计 72,000 次测试执行中（每种技术 3,000 个查询 × 24 个组合，在 60 个上下文 PDF 上执行），RAG-Tester 一致地浮现出源于检索不准、上下文整合不完整、否定查询上的幻觉内容，以及对复杂段落处理不佳的失败。具体来说，RAG-Tester 在 OpenAI 的 LLM 中触发了总计 8,880 个失败，在开放权重模型中触发了 12,753 个失败。失败率因模型系列和嵌入质量而异，较低参数的开放权重模型和较小嵌入表现出明显更高的失败计数。这些结果确认 RAG-Tester 成功暴露了微妙的失败模式，验证了它对系统性 RAG-LLM 评估的效用。

这些结果表明 RAG-Tester 在浮现传统基准（如 Natural Questions 上的精确匹配）完全错过的微妙、真实 RAG 弱点上高度有效。即使最强配置（GPT-4.1 Mini + text-embedding-3-large）仍有 16.93% 的时间失败，表明「最先进」不一定意味着「可靠的 RAG」。闭源与开放权重模型之间的宽性能差距（OpenAI 组平均 24.67% 失败对 Ollama 的 35.43%）也凸显了专有与开放生态之间当前的成熟度差异。实践上，这意味着开发者绝不应在未运行像 RAG-Tester 这样系统性测试套件的情况下部署 RAG 系统，尤其在法律、医疗、金融等高风险领域，那里幻觉或不完整答案可能有严重后果。

我们发现的一些失败类型示例与（1）幻觉、（2）检索不准和（3）理解缺陷相关。这些失败在前述测试查询类型中最突出：

• 否定拒绝：模型幻觉出一个貌似合理但无依据的答案（如原文表 1），在所有检索文本章节都缺乏必要知识时未能提供清晰的拒绝信号。
• 文档最大化：需要从整个文本综合数据的「通用」查询，当系统未能聚合多个相关段落时常导致检索到的上下文不正确（如原文表 2）。
• 自然语言处理（低 Flesch 分数）：使用高度复杂、密集文本章节的测试，模型频繁表现出因无法解析细微技术结构而生成失败（如原文表 3）。

6.2 RQ2 - 与基线比较

对 24 个不同的模型和嵌入组合，RAG-Tester 在 20 个情形中优于基线。总体而言，RAG-Tester 比基线多检测 6.22% 的失败（21,633 对 20,293）。对闭环模型（原文表 6），RAG-Tester 发现 8,880 个失败对基线的 7,132 个（+19.68%）。相反，在开放权重模型中，基线检测到略多的失败（13,161 对 12,753），但这是由 Llama 3.2 模型造成的，它被发现特别弱。在这个特定模型中，基线优于 RAG-Tester，而在其余模型中（除 Gemma 3 和 intfloat-e5-base-v2 嵌入外），RAG-Tester 表现更好。

这些结果表明 RAG-Tester 中先进的测试输入生成策略（基于 Flesch 的复杂度排序、全文档覆盖保证，以及针对性的否定拒绝合成）在更强、生产级的模型上尤其强大。在闭源 LLM 上，结构化方法揭示出朴素随机基线错过的、明显更多的真实失败模式。基线表现更好的三个情形（Llama-3.2 跨所有嵌入）由该模型的极端弱点解释：其总体失败率超过 50%，因此即使随机查询也频繁触发可检测的错误。Gemma-3 配 intfloat-e5-base-v2 的单一例外是次要的，不改变总体趋势。从实践角度，闭源模型上 19.68% 的改进极其显著，因为使用 GPT 级模型的组织用简单基线会严重低估风险。这些发现验证了为 RAG 赋能 LLM 研究先进测试生成策略的必要性；当可靠性至上时，我们强烈推荐使用完整的 RAG-Tester 生成器而非任何更简单的基线。

与 RAG-Tester 相比，基线上发现的失败类型与（1）检索不准和（2）错误生成的答案相关。基线中未使用不同的测试查询类型，因此未检测到幻觉失败。检测到的失败可这样描述：

• 检索不准：当检索器拉取无关、部分相关但不完整，或完全是噪声（与查询无关）的文本时（如原文表 4）。
• 错误生成的答案：即使提示中有正确源材料，模型也未能提取、推理（如原文表 5）或正确格式化答案。

RQ2 的答案：RAG-Tester 在 24 个被评估 LLM–嵌入配置中的 20 个上优于基线，检测到 21,633 个失败，而基线为 20,293 个。这代表失败检测 6.6% 的改进。此外，它的针对性生成策略暴露了更广范围的失败模式，尤其是由无依据查询触发的幻觉，这些未被基线检测到。

6.3 RQ3 - PDF 生成策略

手工选择的互联网 PDF 被证明是比 GPT-5 Nano 自动生成的 PDF 强得多的测试用例。原文表 6 和表 7 显示，手工选择的 PDF 在全部 24 个组合中都比 GPT-5-nano 生成的 PDF 显示明显更高的失败计数。在 OpenAI 模型的情形，RAG-Tester 在互联网 PDF 上揭示了总计 5,595 个失败，显著高于 AI 生成 PDF 的 3,285 个，即 70.3% 的增加。在开放权重 LLM 情形，RAG-Tester 在互联网 PDF 上发现 7,855 个失败，高于 AI 生成 PDF 的 4,898 个。这些结果也适用于基线算法。

这些结果的一个潜在原因可能是，真实世界互联网 PDF 因不规则结构、多样写作风格、领域特定术语、嘈杂格式，以及 GPT-5 Nano 生成器（即使用精心制作的提示）无法完全复现的微妙事实相互依赖，而显著更具挑战性。这解释了为什么它们暴露远更多的失败——它们本身就是更强的测试材料。实践启示很清楚：虽然自动 PDF 生成器极其方便并启用完全可复现、零努力的测试语料，它目前相比真实文档低估了风险。对生产级 RAG 评估（尤其在企业或高风险设置中），团队应结合两种策略，即用 AI 生成的 PDF 做快速迭代和规模化，但总用一组真实来源文档验证最终结果，以捕捉最难的失败模式。这也指向一个明确的未来工作方向：增强 PDF 生成器（例如通过在真实 PDF 上微调提示、注入受控噪声/变异性，或添加多文档合成），使自动生成语料变得与真实世界的一样强。因此 RQ3 表明自动化文档生成可行且可扩展，但尚不是手工策划真实文档的完整替代。

RQ3 的答案：真实世界 PDF 在全部 24 个配置中都比自动生成 PDF 在暴露失败上明显更有效。总体而言，手工选择的 PDF 触发了 13,450 个失败，而 GPT-5 Nano 生成的 PDF 为 8,183 个，对应 64.4% 的增加。因此，自动生成文档提供了一个可扩展、可复现的测试机制，但它们尚未完全复现真实世界文档的结构和语义复杂性。

6.4 RQ4 - Oracle 精确率

应用多数投票策略后，302 个测试被正确识别为失败（真阳性），74 个在实际通过时被错误标记为失败（假阳性），其余 6 个产生模糊结果，LLM 无法达成自信共识。这 6 个案例被人工审查并全部分类为真阳性。

测试 oracle 达到 80.6% 的精确率，意味着它标记为失败的测试中大约每 5 个有 4 个是真实的。其余 19.4% 代表假阳性，即 oracle 不必要地发出警报的情形。虽然仍有改进空间，这些结果表明测试 oracle 表现相当好，正确识别了绝大多数真失败，同时把假警报保持在可管理水平。

RQ4 的答案：测试 oracle 达到 80.6% 的精确率，正确识别了每五个报告失败中的约四个。具体来说，382 个被检查案例中 308 个被确认为真失败，而 74 个是假阳性，导致 19.4% 的假发现率。虽然 oracle 对自动化大规模测试足够可靠，但当单个失败分类至关重要时，其判定应谨慎解读。

7 相关工作

当前 RAG 测试方法优先采用组件级诊断策略，隔离检索和生成阶段以精确定位特定架构失败模式。对检索测试，像 RAGatouille 这样的工具暴露语义失配或糟糕的文档排序，RanX 衡量低召回和低精确。为测试生成组件，G-Eval 用一个「思维链」方法，其中一个更优 LLM 充当类人裁判，有效测试流畅度、语气和连贯性。另一方面，UpTrain 则重点聚焦答案完整性和事实准确性，通过提供特定信号来判断生成器是否提供了正确答案但遗漏了检索文本中存在的关键细节。

这主要通过 RAG 三元组来操作化，它评估上下文相关性（查询到上下文）、忠实度或根基性（上下文到答案）和答案相关性（查询到答案），见于 RAGAS。检索有效性也可用像 Recall@K、平均倒数排名（MRR）和归一化折损累计增益（NDCG）这样的指标衡量，而生成质量通过「LLM 当裁判」框架评估，这些框架用先进模型给语义准确性打分并检测幻觉。现代测试还纳入自动化红队和安全扫描，以主动识别像提示注入、有偏输出和敏感数据泄漏这样的漏洞。

RAG 基准的前沿已从简单问答转向评估复杂多步推理、多模态整合和语料级分析。像 RGB 和 CRUD-RAG 这样的既定框架评估噪声鲁棒性和「创建、读取、更新、删除」任务分类等基础能力，而 HaluEval 提供了一组全面的人工标注样本用于检测幻觉。近期研究引入了 GlobalQA（第一个专为语料级排序和计数等全局推理任务设计的基准）和 mtRAG（处理多轮对话一致性的独特挑战）。为确保高风险领域的可靠性，像 RAGguard 和 RARE 这样的基准针对误导性检索和文档扰动对系统做压力测试。此外，像 UDCG（效用与分心感知累计增益）这样的新兴指标正被提出以替代经典信息检索指标，因为它们展示与端到端 RAG 准确性的显著更强相关。

LLM 的安全和鲁棒性测试已演化为一个严格学科，聚焦确保模型抵抗有害指令并在对抗条件下保持稳定。这主要通过自动化红队操作化，其中像 HarmBench 和 JailbreakBench 这样的框架用数百个精选的「滥用行为」和「越狱产物」系统探查漏洞。评估进一步由专门数据集和方法论结构化：ToxiGen 评估微妙、隐性的毒性；问答偏见基准（BBQ）衡量跨九个受保护类别的社会刻板印象；Retromorphic Testing 引入层级验证以专门检测 RAG 工作流内的幻觉。此外，advERSEM 测试对像模棱两可措辞这样微妙语言操纵的韧性。为把这些技术测试与组织标准对齐，企业日益采用 NIST AI 风险管理框架（AI RMF），特别利用其「衡量」功能在 AI 生命周期中验证可信度的七个关键支柱——包括安全、公平和韧性。

更近期，Kim 等人引入了块覆盖（CC），一个用于 RAG 系统检索组件的、与 oracle 无关的测试充分性准则。CC 衡量被测试套件至少检索一次的语料块比例，并用运行时检索反馈引导查询的选择或生成走向先前未演练的块。因此该方法聚焦于确定测试套件在多大程度上演练了由嵌入模型和向量存储配置诱导的检索行为，独立于生成答案的正确性。RAG-Tester 处理一个互补目标。它不是隔离检索器，而是通过生成可检索文档、测试查询和期望输出，执行不同 LLM 和嵌入模型组合，并对所得答案应用自动化测试 oracle，来自动测试完整的检索-生成流水线。此外，RAG-Tester 生成不同类别的面向失败的测试，包括瞄准复杂段落的查询和系统应拒绝的无依据请求的否定查询。覆盖机制也不同：CC 衡量测试执行期间实际检索到哪些块，而 RAG-Tester 的文档覆盖策略选择尚未贡献于测试生成的源区域。因此，CC 刻画被演练检索空间的充分性，而我们的方法旨在暴露检索与生成交互产生的失败。

RAG-Tester 实现了一个全面的「全栈」评估生命周期，紧密镜像像 DeepEval 和 Maxim AI 这样领先工业框架的自动化工作流。通过自动化从源文档（PDF）生成合成测试数据集并对各种 LLM 和嵌入配置做基准，我们的方法与工业界向高速 RAGOps 流水线的转变对齐。然而，虽然当前设置提供了基于 RAG 三元组标准（忠实度、相关性和根基性）的稳健端到端评估，当代研究方案已专门化进入更深的推理类别。例如，RAG-Tester 测试一般检索，而 GlobalQA 和 CRUD-RAG 为语料级操作（如全局排序和多文档摘要）引入了严格分类。此外，LLM 当裁判机制可通过采用像 UDCG 这样面向机器的指标进一步精炼，它超越简单正确性去具体量化无关检索 PDF 对模型最终回答的「分心」效应——这是由像 RAGuard 这样鲁棒性基准处理的一个关键安全维度。

8 结论与未来工作

测试检索增强生成系统具挑战性，因为其行为取决于文档处理、检索、嵌入和语言生成之间的交互。本文介绍了 RAG-Tester，一个自动化端到端方法，它生成检索文档和测试输入，跨不同 LLM 嵌入配置执行测试，并用基于 LLM 的 oracle 评估所得答案。我们在 24 个 LLM 嵌入配置上通过 72,000 次测试执行评估了 RAG-Tester。该方法检测到 21,633 个失败，并在 24 个配置中的 20 个上优于基线，总体多识别 6.6% 的失败。结果还表明真实世界 PDF 比自动生成文档暴露明显更多的失败，而测试 oracle 达到 80.6% 的精确率。总体而言，这些发现表明系统性测试生成能揭示检索不准、无依据回答、上下文整合不完整，以及处理复杂段落的困难——这些可能通过常规基于基准的评估而不被察觉。

未来工作将把 RAG-Tester 扩展到额外文档格式和更复杂的查询类型，包括多文档、多跳和对抗性测试用例。我们还计划改进测试 oracle、纳入检索特定指标，并调查更真实的文档生成策略。最后，我们将致力于把 CC 作为一个新颖的充分性指标纳入 RAG-Tester。

复现包

我们方法的代码见 https://github.com/Anje13/GBL_RAGTester 。复现包见 https://zenodo.org/records/21606024 。

致谢

Jon Ayerdi、Miren Illarramendi 和 Aitor Arrieta 是 Mondragon Unibertsitatea 系统与软件工程研究组（IT1919-26）的成员，受巴斯克地区教育、大学与研究部支持。

署名与许可：原文 RAG-Tester: Automated End-to-End Testing of Retrieval-Augmented Large Language Models，作者 Ange Maiztegui、Jon Ayerdi、Miren Illarramendi、Aitor Arrieta（Mondragon University，西班牙），arXiv:2608.00054 [cs.SE]。原文以 CC BY 4.0 许可发布。中文全译由智测团队完成，译文同样以 CC BY 4.0 发布；图 1 版权归原作者。原文地址：https://arxiv.org/abs/2608.00054 。代码：https://github.com/Anje13/GBL_RAGTester ，复现包：https://zenodo.org/records/21606024 。译文中省略了参考文献列表、文内引注编号、原文附录 A–F 的完整提示词，以及表 1–7 的逐配置数据（正文已引用其关键数字与结论）；§2.3 为背景综述、做了压缩并指明出处。模型名、工具名、基准名、指标名保留英文。如译文与原文有出入，以英文原文为准。