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

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

" i" |, o& z2 J
　　显然，无论对于用户还是开发者而言，国产的向量数据库准确评估 RAG 应用的性能都十分重要。然而，简单的几个例子对比并不能全面衡量 RAG 应用的回答质量，需要采用可信、可复现的指标来量化评估 RAG 应用。
. r/ w8 o. k4 u% r( Z- e8 ~( Z' @7 g

8 ]! R# o# T* k/ S9 {8 c) [　　本文将从黑盒和白盒两个角度来讨论如何定量地评估一个 RAG 应用。
1 ^8 N  [- j  a

: x5 W  _: r# }3 Y　　01.黑盒方法 V.S. 白盒方法
& {( j' @" X9 v5 r$ Z4 Y; z
2 ~) `) L9 d% a$ A6 r3 g
* Z8 N* M% T0 c# t' H, V+ x! R　　我们把评估 RAG 应用类比为测试一个软件系统，可以从两个途径来评估 RAG 系统的好坏，一个是黑盒方法，一个是白盒方法。


: r8 |6 g  }& G. i- _5 T　　当以黑盒方式来评估 RAG 应用时，我们看不到 RAG 应用的内部，只能从输入给 RAG 应用的信息和它返回的信息来评估 RAG 的效果。对于一般的 RAG 系统，我们只能访问这三个信息：用户提问（User's query）、RAG 系统召回的引用上下文（retrieved contexts）、RAG 系统的回答（RAG's response）。我们使用这三个信息来评估 RAG 应用的效果，黑盒方式是一种端到端的评估方式，也比较适用于评估闭源的 RAG 应用。
1 U2 Z/ o# n( h( e3 @' x
/ g" c! k, \8 j: |& L
　　当以白盒方式来评估 RAG 应用时，我们能看到 RAG 应用的内部所有流程。因此内部的一些关键组件就可以决定这个 RAG 应用表现的好坏。以常见的 RAG 应用流程为例，一些关键的组件包括 embedding model、rerank model 和LLM。有的 RAG 具备多路召回能力，可能还会有 基于词频的搜索方法（term frequency search） 算法，更换和升级这些关键组件也能为 RAG 应用带来更好的效果。白盒方式可以用来评估开源 RAG 应用，或者提升自研 RAG 应用。

* {* `" P. o4 @( i9 Y1 K0 c  t7 u
　　02.黑盒的端到端评估方法


/ M5 v' S9 Y0 l: l8 O$ l+ ?　　黑盒条件下评估指标


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


　　提出下面这三个对应的指标得分：
" ?; h' r+ w8 A4 j7 S& y, J. L7 D

4 `* _6 |3 h; h. [- z　　Context Relevance: 衡量召回的 Context 能够支持 Query 的程度。如果该得分低，反应出了召回了太多与 Query 问题无关的内容，这些错误的召回知识会对 LLM 的最终回答造成一定影响。


2 V6 r6 j3 l6 ~: D0 x) M　　Faithfulness: 这个指标衡量了生成的答案在给定的上下文中的事实一致性。它是根据答案和检索到的上下文计算出来的如果该得分低，反应出了 LLM 的回答不遵从召回的知识，那么回答出现幻觉的可能就越大。
3 l0 x  C4 v- ~% d( V" L; L; c/ @/ f
: u* ?- o6 V1 l( E! \$ R- g# J' s" J& p
! i! ]% E  i# Y　　Answer Relevance: 侧重于评估生成的答案与给定查询提示的相关性。对于不完整或包含冗余信息的答案，会分配较低的分数。
1 \/ M: ?$ o& l$ z

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