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

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

( \+ H  K' |" ?$ p+ c& E
& H8 I) E7 R- [# _" r: n5 G- T　　显然，无论对于用户还是开发者而言，国产的向量数据库准确评估 RAG 应用的性能都十分重要。然而，简单的几个例子对比并不能全面衡量 RAG 应用的回答质量，需要采用可信、可复现的指标来量化评估 RAG 应用。

# e9 T& p2 c0 Z
0 A; a4 @3 u" B$ v　　本文将从黑盒和白盒两个角度来讨论如何定量地评估一个 RAG 应用。
2 z' \, }3 ]6 n' E3 y
0 ^$ r, n, Q5 [6 ^' j. g
　　01.黑盒方法 V.S. 白盒方法
1 r; D9 J) g5 _- _+ G. @

　　我们把评估 RAG 应用类比为测试一个软件系统，可以从两个途径来评估 RAG 系统的好坏，一个是黑盒方法，一个是白盒方法。
/ L' m8 N4 I4 F

. d, p) {/ G# k: B　　当以黑盒方式来评估 RAG 应用时，我们看不到 RAG 应用的内部，只能从输入给 RAG 应用的信息和它返回的信息来评估 RAG 的效果。对于一般的 RAG 系统，我们只能访问这三个信息：用户提问（User's query）、RAG 系统召回的引用上下文（retrieved contexts）、RAG 系统的回答（RAG's response）。我们使用这三个信息来评估 RAG 应用的效果，黑盒方式是一种端到端的评估方式，也比较适用于评估闭源的 RAG 应用。
# V% S" m1 E9 a: ]" B
4 [  q6 O! }# |* k% j
) E2 w, {" Q( I6 m! v* A　　当以白盒方式来评估 RAG 应用时，我们能看到 RAG 应用的内部所有流程。因此内部的一些关键组件就可以决定这个 RAG 应用表现的好坏。以常见的 RAG 应用流程为例，一些关键的组件包括 embedding model、rerank model 和LLM。有的 RAG 具备多路召回能力，可能还会有 基于词频的搜索方法（term frequency search） 算法，更换和升级这些关键组件也能为 RAG 应用带来更好的效果。白盒方式可以用来评估开源 RAG 应用，或者提升自研 RAG 应用。


! m" y$ k' E/ j% B& r　　02.黑盒的端到端评估方法

1 k/ i+ G# r6 T, Z8 O) b3 Z( X
1 m$ `* k; G4 U1 u　　黑盒条件下评估指标
) P) u5 }" c3 R& H- Z; j7 x$ Y

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

6 e1 p8 {% k9 B8 l: V: j6 y1 K
　　提出下面这三个对应的指标得分：


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

4 n8 K. v( v6 h0 w- V
9 J( v- Z) {* ?1 z# b- X　　Faithfulness: 这个指标衡量了生成的答案在给定的上下文中的事实一致性。它是根据答案和检索到的上下文计算出来的如果该得分低，反应出了 LLM 的回答不遵从召回的知识，那么回答出现幻觉的可能就越大。
% j% V% @. W- b9 [4 L

　　Answer Relevance: 侧重于评估生成的答案与给定查询提示的相关性。对于不完整或包含冗余信息的答案，会分配较低的分数。

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