RAGChecker为你的RAG系统提供全方位诊断

评估一个RAG系统到底难在哪儿？模块化架构让各组件相互耦合，长文本响应又缺乏统一的评价标尺，再加上现有指标本身就不太靠谱——这几个问题叠加在一起，想全面衡量一个RAG系统的表现，还真不是件容易的事。

亚马逊AWS AI最近开源了

，一个细粒度的评估框架，核心思路是基于声明级别的蕴含性检查。说白了，就是从模型响应和真实答案里分别提取出一个个“声明”，然后拿它们相互对照，看哪些说对了、哪些漏了、哪些凭空捏造。

。上面那张维恩图，把模型响应和真实答案做了对比：绿色的O代表正确声明，红色的X是错误声明，紫色的V则是缺失的声明。检索到的文档块，会根据它们包含的声明类型分成两类。下面那张表，则分别定义了整体指标、检索器指标和生成器指标——这样就能精准定位每个环节的表现。

RAGChecker让开发者和研究者能更深入地诊断自己的RAG系统，具体能提供这些能力：

• 全面评估
  ：给出整体指标，直接衡量整个RAG流程的效果。

• 诊断指标
  ：检索器有检索器的指标，生成器有生成器的指标。哪儿出问题一目了然，改进方向自然就清晰了。

• 细粒度评估
  ：核心就是声明级别的蕴含操作，每个细节都不放过。

• 基准数据集
  ：一个涵盖10个领域、包含4000个问题的RAG基准数据集（即将发布）。

• 元评估
  ：还附带一个人工标注的偏好数据集，用来检验RAGChecker的结果跟人类判断到底有多吻合。

他们在10个领域的公共数据集上，对8个最先进的RAG系统做了全面实验。结果相当亮眼：

，并且揭示了RAG系统组件行为背后的内在权衡——哪些设计选择更靠谱，哪些需要谨慎。

。这个基准测试从10个领域的公共数据中重新组装，整理出4162个问题。对于金融、生活、娱乐、科技、科学、小说等领域的短答案，已经用GPT-4扩展成了长篇答案。

图中展示了RAGCheck、TruLens、RAGAS、ARES、CRUD-RAG等框架的指标与人类评估在正确性、完整性和整体评估上的相关性。

RAGChecker的指标不仅能反映现状，还能给出优化建议。研究人员和实践者可以据此调整RAG系统的设置——

——从而持续提升效果。

。整体性能用精确度、召回率和F1分数来衡量。检索器按声明召回率（CR）和上下文精确度（CP）打分，生成器则用上下文利用度（CU）、相关噪声敏感性（NS(I)）、不相关噪声敏感性（NS(II)）、幻觉、自我知识（SK）和忠实度来诊断。每个系统还列出了平均响应声明数量。

。图中每个点代表元评估数据集中的一个实例，x轴是人类偏好标签，y轴是预测分数。彩色区域展示分布，虚线是平均值。

。Top-k选择和片段大小都影响着生成器接收到的噪声和有用信息的平衡，但方式截然不同。

• 增加k会引入更多可能不相关的上下文，而增大片段大小则提供了相关事实更丰富的周边上下文
  。所以k越大，上下文精确度越低；片段越大，精确度越高。但两者都会提升检索中的声明召回率。

• 生成器在上下文更多时往往更忠实
  ——当然，Llama3本身已经很忠实了，所以这个趋势不太明显。不过由于噪声增加，上下文利用度通常会下降，相关噪声敏感性反而升高。

• 端到端的RAG性能在更多上下文时略好
  ，主要是召回率上来了。建议适度增加这两个参数，既能提升忠实度，又不会让有用信息饱和。在上下文长度有限的情况下，优先选较大的片段大小和较小的k，尤其是面对金融、写作这类较容易的数据集时。比如，片段大小150且k=20的配置，就不如片段大小300且k=10的效果好。

Top-k选择的诊断

片段大小的诊断

论文原文：https://arxiv.org/pdf/2408.08067  
项目地址：https://github.com/amazon-science/RAGChecker