如何构建可靠的 RAG：深入解析七个故障点与评估框架

检索增强生成（RAG） 是现代 AI 架构的关键组件，作为构建上下文感知代理的基本框架。

但从基本原型到生产就绪系统的转变，需要克服数据检索、上下文整合和回答生成方面的重大障碍。

本文深入探讨了七个典型的 RAG 故障点和评估指标，并提供了实际的编码示例。

RAG 故障剖析 – 7 个故障点（FPs）

根据研究人员 Barnett 等 的说法，检索增强生成（RAG）系统 在整个流程中会遇到七个特定的 故障点（FPs） 。

下面的图表说明了这些阶段：

图 A. 构建 RAG 系统所需的索引与查询流程。索引在开发阶段建立，查询在运行时执行。本研究识别出的故障点以红色框标出（来源）

下面按照图 A中从左上到右下的流程顺序，逐一分析各个故障点。

FP1. 缺失内容

缺失内容发生在系统被问及一个无法回答的问题，因为相关信息一开始就不存在于可用的向量存储中。

故障发生在大型语言模型（LLM）提供一个听起来合理但不正确的响应，而不是说明 它不知道 。

FP2. 未命中顶级文档

向量存储中存在正确的文档，但检索器未能将其排在足够靠前的位置，因此它没有进入作为上下文传给 LLM 的 top-k 文档集合。

因此，正确的信息永远不会到达 LLM。

FP3. 不在上下文中（整合策略限制）

正确的文档存在于向量存储中，也已成功检索出来，却在整合过程中被排除。

这发生在太多文档被返回，并且系统必须对这些文档进行筛选和删减，以便适应 LLM 的上下文窗口、令牌限制或速率限制。

FP4. 未提取

正确的信息存在于向量存储中，且已成功检索并整合，但 LLM 仍未能从上下文中识别这些信息。

这发生在上下文过于嘈杂或包含相互矛盾的信息时，会让 LLM 混乱。

FP5. 格式错误

存储、检索、整合和 LLM 的理解都已成功完成，但 LLM 未能遵循提示中的特定格式要求，例如表格、项目符号列表或 JSON 模式。

FP6. 详细程度不当

LLM 的输出在技术上存在，但 要么太一般，要么与用户的需求相比太复杂 。

例如，LLM 为具有复杂专业目标的用户查询生成简单的答案。

FP7. 不完整的答案

LLM 生成的输出不一定有误，但遗漏了上下文中已有的关键信息。

例如，当用户询问一个复杂的问题，如 “文档 A、B 和 C 的关键点是什么？” 时，LLM 只涵盖其中一个或两个来源。

FPs 如何损害 RAG 流程性能

每个故障点都会影响 RAG 流程的性能：

数据完整性和信任故障

当信息缺失或有误时，系统不再是可靠的信息来源。主要 FPs 包括：

• FP1（缺失内容）：答案不在文档中。
• FP4（未提取）：LLM 决定忽略文档中的正确答案。
• FP7（不完整）：LLM 提供半真半假的信息，缺少重要的部分。

检索和效率瓶颈

RAG 流程在检索和整合阶段遗漏关键信息时，可能会变得低效。主要 FPs 包括：

• FP2（未命中顶级）：嵌入模型未能选择前 k 个嵌入。
• FP3（整合策略）：为满足 LLM 限制而裁剪文档的脚本，丢弃了最重要的部分。

用户体验和格式错误

虽然输出是正确的，但具有糟糕的可读性或错误的格式的输出会损害用户体验。主要 FPs 包括：

• FP5（格式错误）：LLM 未能遵循特定的输出格式，如 JSON。
• FP6（详细程度不当）：LLM 为简单的是/否问题生成冗长的输出，或者相反（对于复杂的问题生成过于简短的答案）。

评估堆栈：减轻 FPs 的框架

评估指标旨在系统地减轻这些 FPs。

本节探讨了主要的评估指标及其实际应用。

主要 RAG 评估指标：

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – 部署前的单元测试

DeepEval 根据标准计算加权分数。

由充当评审的 LLM（例如 GPT-4o）按各项标准评估 LLM 的输出：

DeepEval 利用 G-eval ，一种 思维链（CoT） 框架，它采用多步骤方法来评估输出：

1. 定义标准 来衡量（例如“连贯性”、“流畅性”或“相关性”）。
2. 生成 评估步骤 （使用评估器 LLM）。
3. 按照评估步骤并分析输入和 LLM 输出。
4. 计算各项标准得分的期望加权和。

实际应用场景

• 情况： 一个技术文档助手（机器人）用于复杂的软件产品，似乎在工程团队更新代码库时每次都能正常工作。
• 问题： 没有量化的证据证明机器人仍能回答用户查询（您只是“认为”它有效…）。
• 解决方案： 将 PyTest 函数集成到 GitHub Actions 中的 CI/CD 回归测试套件中，DeepEval 运行 G-Eval 和其他指标，以测试用例为基础：

• 预期结果： 如果任何指标的分数低于阈值（0.85），则 PyTest 引发 AssertionError ，立即使 CI 构建失败，防止未被察觉的功能退化进入生产环境。

开发者注意 – DeepEval 测试用例
一组 LLMTestCase 对象定义了 DeepEval 运行的测试用例。

在实践中，该测试用例应包含最重要的用户查询和带有检索上下文的标记输出。

这些可以从 JSON 或 CSV 文件中检索。

RAGAS – 大海捞针优化器

Retrieval Augmented Generation Assessment（Ragas）旨在通过生成合成测试集来评估 RAG，而无需人工注释的数据集。

然后，它计算核心指标：

图 B. RAGAS 评估三角图，通过精度、召回、忠实度和相关性指标连接问题、上下文和答案（由 Kuriko IWAI 创建）

核心指标分为三个类别：

• 检索流程（黑色实线，图 B）：上下文精度 、 上下文召回 。
• 生成流程（黑色虚线，图 B）：忠实度 、 答案相关性 。
• 标准答案（红色框，图 B）：答案语义相似度 、 答案正确性 。

实际应用场景

• 情况： 法律合同的 RAG 系统缺少关键条款。您不确定问题出在检索（检索器）还是阅读（生成器）阶段。
• 问题： 无法确定最佳的 top-k 值（检索的文本块数量）。
• 解决方案： 使用 RAGAS 创建一个包含 100 对问题及其支持证据的合成测试集。然后，对测试集运行 RAG 流程以计算上下文召回和上下文精度：
• 预期结果： 根据指标结果，行动计划可以是以下：

表 1. RAGAS 诊断行动计划 – 将分数映射到系统调整。

TruLens – 反馈循环专家

TruLens 关注 RAG 过程的内部机制，而不仅仅是最终输出，使用 反馈函数 。

它还使用一个基于 LLM 的评分，反映了响应如何满足查询的意图，使用 4 点 Likert 量表（0-3），使其在 排名不同搜索结果的质量 方面更为出色。

实际应用场景

• 情况： 一个医疗顾问机器人正确回答了用户的问题，但添加了一个不在经过审核的 PDF 资料库中的额外建议。
• 问题： 额外建议可能有用，但没有来源资料的支持。
• 解决方案： 使用 TruLens 实现一个以 score > 0.8 为阈值、评估来源依据的反馈函数：

• 预期结果： 当 LLM 生成一个包含不在检索的文档中的信息的响应时，TruLens 会在您的仪表板中标记该记录。

Arize Phoenix – 沉默故障映射

Arize Phoenix 是一个开源的可观察性和评估工具，用于评估 LLM 输出，包括复杂的 RAG 系统。

由 Arize AI 基于 OpenTelemetry 构建，Phoenix 专注于可观察性，将 LLM 评估视为 MLOps 的一个子集。

在 RAG 评估的背景下，Phoenix 在 嵌入分析 方面表现出色，使用 统一流形近似和投影（UMAP） 将高维向量嵌入降维到 2D/3D 空间。

这种嵌入分析从数学上揭示了失败的查询是否在语义上被分组在一起，表明向量数据库中存在缺口。

实际应用场景

• 情况： 一个客户支持机器人对退款工作得很好，但对保修索赔的回答毫无意义。
• 问题： 数据库中存在数据空洞（无法在日志中找到）。
• 解决方案： 使用 Arize Phoenix 生成一个 UMAP 嵌入可视化（UEV），一个 3D 地图，用于向量数据库 – 将用户查询叠加在文档块上：
• 预期结果： 可视化地看到一组用户查询落在没有文档的黑暗区域，这表明一些文档被遗忘上传到向量存储中。

Braintrust – 提示回归安全网

Braintrust 专为高频迭代周期而设计，使用 跨模型比较 。

实际应用场景

• 情况： 一个工程团队将提示从“回答问题”（案例 A）升级到一段更复杂、长达 500 个词的系统指令（案例 B）。
• 问题： 提升案例 B 的提示可能会无意中破坏案例 A。
• 解决方案： 使用 Braintrust 创建一个包含 N 个完美示例（例如 N = 50 ）的金标准数据集。让 Braintrust 在团队每次修改提示中的一个词时，都进行并排比较（SxS）：

• 预期结果： 显示金标准数据集（N = 50）中哪些案例变得更好或更差的差异报告。

总结

当使用适当的评估框架处理时，RAG 可以成为一个有竞争力的工具，提供与用户查询最相关的 LLM 上下文。

实施策略：将指标映射到故障点

虽然没有万能的解决方案，但 表 2 显示了针对本文中介绍的每个故障点应用哪些评估指标：

表 2. 故障点缓解矩阵 – 哪个工具解决哪个 FP？

DeepEval 和 RAGAS 可以利用其忠实度指标来衡量数据完整性故障（FP1、FP4、FP7）。

TruLens 利用其上下文精度/召回来衡量上下文与输出的相关性 – 有效地评估 FP2。

Arize Phoenix 提供检索过程的可视化跟踪，使得可以轻松地看到检索的文档是否在整合过程中丢失（FP3）。

对于用户体验故障，DeepEval 创建自定义指标来评估用户体验故障，而 Braintrust 则擅长基准数据集比较。