如何构建可靠的 RAG：深入探讨 7 个故障点和评估框架

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

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

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

RAG 故障的解剖 – 7 个故障点（FPs）

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

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

图 A. 为创建 RAG 系统所需的索引和查询过程。索引过程在开发时间进行，查询在运行时进行。研究中确定的故障点以红色框表示（来源）

让我们按照流程顺序，按照图 A 中从左上到右下的顺序，探索每个故障点。

FP1. 缺失内容

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

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

FP2. 未命中顶级文档

这是一个正确的文档存在于向量存储中，但检索器未能将其排名足够高，以便将其包含在提供给 LLM 的上下文中。

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

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

这是一个正确的文档存在并从向量存储中检索，但在整合过程中被排除。

这发生在太多文档被返回，并且系统必须将它们过滤掉，以便适应 LLM 的上下文窗口、令牌限制或速率限制。

FP4. 未提取

这是一个 LLM 未能在上下文中识别正确的信息，即使正确的信息存在于向量存储中，并且成功检索和整合。

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

FP5. 错误格式

这是一个存储、检索、整合和 LLM 解释都成功处理，但 LLM 未能遵循在提示中提供的特定格式说明，例如表格、项目符号列表或 JSON 模式。

FP6. 不正确的具体性

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

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

FP7. 不完整的答案

这是一个 LLM 生成的输出不一定是错误的，但缺少了上下文中可用的关键信息。

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

FPs 如何损害 RAG 流程性能

每个 FPs 都会影响 RAG 流程的性能：

数据完整性和信任故障

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

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

检索和效率瓶颈

RAG 流程可能在检索和整合阶段效率低下。主要 FPs 包括：

• FP2（未命中顶级）：嵌入模型未能选择前 k 个嵌入。
• FP3（整合策略）：脚本以 LLM 限制为条件，修剪文档以适应 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 Action 中的 CI/CD 回归测试套件中，DeepEval 运行 G-Eval 和其他指标，以测试用例为基础：

• 预期结果： 如果任何指标的分数低于阈值（0.85），则 PyTest 引发 AssertionError ，立即使 CI 构建失败，防止沉默回归到生产环境。

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

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

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

RAGAS – 大海捞针优化器

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 运行并排比较每次更新提示时的结果：

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

总结

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

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

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

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

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

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

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

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