RAG 应用测试：性能与质量双门禁

文章主旨：

对 RAG 应用做测试不能只测响应速度，必须设置性能与质量两道独立门禁：用 k6 测延迟与负载，用 DeepEval 以 LLM 为裁判评估答案是否忠实、是否相关，并将这两道门接入 CI/CD，在拉取请求进入生产前自动拦截性能回退与幻觉问题。

关键要点：

• RAG 接口包含“检索上下文”和“流式生成 Token”两个昂贵阶段，将请求耗时当作单一指标，会掩盖“模型多久开始回答”和“开始后生成多快”这两个不同问题。
• 性能门用 k6 关注 TTFT、ITL、Tokens/sec、p95/p99；其中 TTFT 对用户最可见，但传统负载测试工具擅长原子化的请求/响应测量，并不擅长测量流式响应。
• 质量门用 DeepEval 覆盖忠实度、答案相关性、上下文精确率、上下文召回率；前两项属于生成侧，后两项属于检索侧。若忠实度低但上下文召回率高，说明检索结果可用，问题可能出在模型没有正确利用上下文。
• DeepEval 将评估包装为带通过/失败阈值的 pytest 测试用例，适合作为 CI/CD 门禁；同时支持任意 LLM 作为裁判模型，可避免被单一供应商锁定。
• 由于 k6 的 SSE 扩展 xk6-sse 与 k6 v2 尚不兼容，原文采用务实折衷：用标准 k6 测试非流式 /chat/complete 接口，从而只能得到端到端延迟，无法获得真实 TTFT；该指标仍能提示系统变慢，但无法解释慢的原因。

内容结构：

1. 引言：RAG 需要两个测试面

原文以“一个面向小型知识库的文档助手”为例，说明它回答“如何以非 GUI 模式运行 JMeter”。RAG 应用可能“又快又自信地给出完全错误的答案”，因此负载测试之外还必须增加质量测试。

2. RAG 颠覆传统压测

传统 API 返回完整响应，测量的是单次往返耗时；RAG 接口在回答前需要先检索上下文，再逐 Token 流式生成响应。一次请求会在数秒内流式输出数百个 Token，因此仅看总耗时，会掩盖“启动慢、生成快”和“启动快、生成慢”两类不同体验问题。

3. 性能与质量双门禁

性能门回答“它有多快，负载升高时是否仍能支撑”，由 k6 负责；质量门回答“答案是否真正基于检索到的上下文，还是模型编造内容”，由 DeepEval 负责。任何一道门都无法单独反映全貌：快但幻觉多的应用比慢但准确的应用更糟；再准确但需要 8 秒才响应的应用也会失去用户。

4. 关键指标

性能指标包括：

• TTFT，用户等待首个内容出现的时长；
• ITL 和 Tokens/sec，衡量开始生成后是否顺畅、生成速度如何；
• p95/p99，衡量尾部用户体验。

质量指标包括：

• Faithfulness，答案是否有检索上下文支撑；
• Answer relevancy，答案是否回答实际问题；
• Context precision，检索分片是否正确且排序合理；
• Context recall，检索是否遗漏必要信息。

这些指标可用于区分生成侧与检索侧问题：低忠实度、高上下文召回率，说明检索器工作正常，模型可能忽略了上下文；应先区分提示词问题与检索问题，再开始调优。

5. DeepEval 检测幻觉

原文选择 DeepEval 而非 RAGAS，主要因为它能把评估变成带通过/失败阈值的 pytest 测试用例，便于接入 CI/CD，并且允许使用任意 LLM 作为裁判模型。

示例测试针对 JMeter 文档助手的问题 How do I run JMeter in non-GUI mode?，调用 RAG 应用后构造 LLMTestCase，再使用 GeminiModel 分别计算忠实度与答案相关性，任一指标低于阈值则抛出 AssertionError。示例阈值分别为 0.75 和 0.8，但原文提醒应结合业务基线与容错范围校准，不应照搬。测试套件还包含针对 Gemini API 临时 503 错误的指数退避重试，最多 3 次；DeepEval 会生成 JUnit XML 与 HTML 报告，方便接入 CI 系统。

6. k6 负载测试与 TTFT

原文指出，xk6-sse 扩展不兼容 k6 v2；在扩展更新前，无法同时获得 k6 v2 的改进行架构与流式指标测量能力。因此配套仓库采用务实方案：不使用自定义二进制文件或扩展，而是用标准 k6 内置 http 模块测试非流式 /chat/complete 接口。代价是拿不到真实 TTFT，只能得到端到端延迟。该指标仍可提示系统是否变慢，却无法解释为什么慢。示例 k6 脚本使用 ramping-vus 场景，设置 30 秒升到 10 个虚拟用户、持续 1 分钟、再 30 秒降至 0，并记录了响应时长与每秒 Token 数等指标。

文章总结：

文章持务实工程视角，主张 RAG 性能测试应拆成独立的速度门与质量门，并以 CI/CD 门禁的方式落地；同时强调阈值需根据业务校准，在流式测试工具尚不完善时，用非流式接口得到端到端延迟是合理的折衷。