RAG 修炼手册｜如何评估 RAG 应用？

　　如果你是一名用户，拥有两个不同的 RAG 应用，如何评判哪个更好？对于开发者而言，如何定量迭代提升你的 RAG 应用的性能？

$ w' v  @' Z, W9 R
　　显然，无论对于用户还是开发者而言，国产的向量数据库准确评估 RAG 应用的性能都十分重要。然而，简单的几个例子对比并不能全面衡量 RAG 应用的回答质量，需要采用可信、可复现的指标来量化评估 RAG 应用。

" r+ \9 r% k  H- J* Y1 k
　　本文将从黑盒和白盒两个角度来讨论如何定量地评估一个 RAG 应用。
$ q: Q' ?* l9 V+ G
5 X2 {. V  o# ^( c  [4 D' C
, l* K! X) S* X: j% O* Z　　01.黑盒方法 V.S. 白盒方法

! }9 J+ Q" d- @3 ^: V4 B
　　我们把评估 RAG 应用类比为测试一个软件系统，可以从两个途径来评估 RAG 系统的好坏，一个是黑盒方法，一个是白盒方法。

! v6 I! x$ k8 q' G% H) z$ W# D
2 g( t$ m& `3 y, p( z. ^　　当以黑盒方式来评估 RAG 应用时，我们看不到 RAG 应用的内部，只能从输入给 RAG 应用的信息和它返回的信息来评估 RAG 的效果。对于一般的 RAG 系统，我们只能访问这三个信息：用户提问（User's query）、RAG 系统召回的引用上下文（retrieved contexts）、RAG 系统的回答（RAG's response）。我们使用这三个信息来评估 RAG 应用的效果，黑盒方式是一种端到端的评估方式，也比较适用于评估闭源的 RAG 应用。
6 _. u6 p) C* F3 z  j# t
; T' p4 r/ A2 C/ y& v) x. q
% b2 \- u  o; K　　当以白盒方式来评估 RAG 应用时，我们能看到 RAG 应用的内部所有流程。因此内部的一些关键组件就可以决定这个 RAG 应用表现的好坏。以常见的 RAG 应用流程为例，一些关键的组件包括 embedding model、rerank model 和LLM。有的 RAG 具备多路召回能力，可能还会有 基于词频的搜索方法（term frequency search） 算法，更换和升级这些关键组件也能为 RAG 应用带来更好的效果。白盒方式可以用来评估开源 RAG 应用，或者提升自研 RAG 应用。


; V* q  }/ ^/ [4 e* T/ ^* e　　02.黑盒的端到端评估方法
& m1 }: j+ E) ]0 N+ z5 s

; Q# r0 W* v3 P$ C　　黑盒条件下评估指标


　　在 RAG 应用是一个黑盒的情况下，我们只能访问这三个信息：用户提问（User's query）、RAG 系统召回的引用上下文（retrieved contexts）、RAG 系统的回答（RAG's response）。它们是 RAG 整个过程中最重要的三元组，两两相互牵制。我们可以通过检测这三元组之间两两元素的相关度，来评估一个 RAG 应用的效果。


　　提出下面这三个对应的指标得分：
  A7 F( H$ \4 {  n3 H
# ~2 q( e0 {& @  d$ `
　　Context Relevance: 衡量召回的 Context 能够支持 Query 的程度。如果该得分低，反应出了召回了太多与 Query 问题无关的内容，这些错误的召回知识会对 LLM 的最终回答造成一定影响。
! @# @8 H. r" K  n
" _0 ^9 M1 \' k+ j
　　Faithfulness: 这个指标衡量了生成的答案在给定的上下文中的事实一致性。它是根据答案和检索到的上下文计算出来的如果该得分低，反应出了 LLM 的回答不遵从召回的知识，那么回答出现幻觉的可能就越大。
- ^" ^$ N; p; b8 z3 R& x) l
* T# s  O: c5 X% }6 K
, Y& i( r8 F; T& B( X' q2 A　　Answer Relevance: 侧重于评估生成的答案与给定查询提示的相关性。对于不完整或包含冗余信息的答案，会分配较低的分数。

楼主辛苦了，整理这么多内容，必须点赞收藏