随着 LLM(Large Language Model)的应用逐渐普及，人们对 RAG(Retrieval Augmented Generation)场景的关注也越来越多。然而，如何定量评估 RAG 应用的质量一直以来都是一个前沿课题。

很显然，简单的几个例子的对比，并不能准确地衡量出 RAG 应用的整体的回答的好坏，必须采用一些有说服力的指标，定量地、可复现地、来评估一个 RAG 应用。目前，业内已经形成一些主流的方法论，并出现了一些用于评估 RAG 应用的专业工具或服务，用户可以用它们快速进行定量评估。

今天我们就带大家来盘一盘自动化评估 RAG 应用的常用方法论以及比较典型的评估工具对比。

01.方法论

想要自动化定量评估 RAG 应用，并不是一个容易的事。很有可能会遇到一些常见的问题，比如，用什么指标评估 RAG？怎么样才有说服力？用什么数据集来评估？为此，我们将从“评估指标”“基于 LLM 定量评估”这两个角度来回答和阐述这些问题。

角度一：评估指标

a.RAG 三元组——无需 ground-truth 也能做评估

如果我们拿到一些知识文档，对于每个 query 提问，没有对应的 ground-truth，可以评估这个 RAG 应用吗？

答案是可以，而且这种方法还挺常见。我们首先引用 TruLens-Eval 里的一个概念，RAG 三元组(RAG Triad)来说明这个问题：

|RAG 三元组（https://www.trulens.org/trulens_eval/core_concepts_rag_triad/）

标准的 RAG 流程就是用户提出 Query 问题，RAG 应用去召回 Context，然后 LLM 将 Context 组装，生成满足 Query 的 Response 回答。那么在这里出现的三元组—— Query、Context 和 Response 就是 RAG 整个过程中最重要的三元组，它们之间两两相互牵制。我们可以通过检测三元组之间两两元素的相关度，来评估这个 RAG 应用的效果：

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

• Groundedness: 衡量 LLM 的 Response 遵从召回的 Context 的程度。如果该得分低，反应出了 LLM 的回答不遵从召回的知识，那么回答出现幻觉的可能就越大。

• Answer Relevance: 衡量最终的 Response 回答对 Query 提问的相关度。如果该得分低，反应出了可能答不对题。

以 Answer Relevance 为例:

Question: Where is France and what is it’s capital?
Low relevance answer: France is in western Europe.
High relevance answer: France is in western Europe and Paris is its capital.

因此，对于一个 RAG 系统来说，最基本的就是三元组指标得分，它反映了 RAG 效果的核心部分，整个过程中并不需要 ground-truth 的参与。

当然，具体怎么衡量这三个得分，也有不同的方式。最常见的就是基于目前最好的 LLM（如 GPT-4)做为一个裁判，给输入的这一对元组打分，判断它们的相似度，具体的例子将在后面介绍。

另外，三元指标其中的某个可能还有具体的一些细分，比如 Ragas 中就将 Context Relevance 这一步又分为Context Precision、Context Relevancy、Context Recall。或者，一些工具中不一定是这三个名字，比如 Groundedness 在有的工具中叫作 Faithfulness。

b. 基于 Ground-truth 的指标

• Ground-truth 是回答

当一个数据集已经标注好了ground-truth 回答，那就可以直接比较 RAG 应用的回答和 ground-truth 之间的相关性，来端到端地进行衡量。这种方法很直观也很容易想到，比如 Ragas 中相关的指标就有：Answer semantic similarity 和 Answer Correctness。

以 Answer Correctness 为例：

Ground truth: Einstein was born in 1879 at Germany .
High answer correctness: In 1879, in Germany, Einstein was born.
Low answer correctness: In Spain, Einstein was born in 1879.

具体怎么衡量相似性或相关性，可以用直接向 GPT-4 进行提示词工程打分，或用一些比较好的 embedding 模型来进行相似性打分。

• Ground-truth 是知识文档中的 chunks

常见的数据集中并没有回答的 ground-truth，而更多的情况是，数据集有 query 提问，和对应的文档内容中的 ground-truth doc chunks。这种情况下需要衡量的就是上文 RAG 三元组指标中的 Context Relevance，也就是对比 ground-truth doc chunks 和召回的 contexts 之间的相关性，这一步因为没有 LLM 生成的情况出现，对比的是相对固定的文本，所以在实现上可以使用一些传统的指标，比如 Exact Match (EM)、Rouge-L、F1 等。

其实这种情况下，本质上就是衡量 RAG 应用的召回效果，如果 RAG 应用只使用向量召回而没有用其它的召回方式，那这一步退化等效于衡量 embedding 模型的效果。

• 生成评估数据集

如果我们手头上的知识文档没有 ground-truth，并且只想评估一下 RAG 应用在这些文档上的效果，有办法可以实现吗？

既然 LLM 可以生成一切，那让 LLM 根据知识文档，来生成 query 和 ground-truth，这也是可行的。比如，在 ragas 的 Synthetic Test Data generation 和 llama-index 的 QuestionGeneration 中都有一些集成好的方法，可以直接方便地使用。

我们来看一下 Ragas 中根据知识文档生成的效果：

可以看到，上图生成了许多 query questions 和对应的 answers，包含对应的 context 出处。为保证生成问题的多样性，还可以选择各种各样的 question_type。这样，我们就可以方便地直接用这些生成的 question 和 ground-truth，去定量评估一个 RAG 应用，无需去网上找各种各样的 baseline 数据集。

c. LLM 回答本身的指标

这一类的指标就是单从 LLM 的回答本身来看的，比如评估回答本身是否友好，是否有害，是否简洁等，它们参考来源的是 LLM 本身的一些评估指标。

比如 Langchain 的 Criteria Evaluation，包括:

conciseness, relevance, correctness, coherence, harmfulness, maliciousness, helpfulness, controversiality, misogyny, criminality, insensitivity

比如 Ragas 中的 Aspect Critique 包含：

harmfulness, maliciousness, coherence, correctness, conciseness

以 Conciseness 举例：

Question: What's 2+2?
Low conciseness answer: What's 2+2? That's an elementary question. The answer you're looking for is that two and two is four.
High conciseness answer: 4

角度二：基于 LLM 的定量评估

上文提到的大部分指标，都需要输入一些文字，然后期望得到一个定量的得分。这在以往是不太容易实现的，有了 GPT-4 后，其可行性就提高了。我们只需设计好 prompt，将要打分的一些文字放入 prompt，访问GPT-4，就可以得到一个想要的得分结果。

举个例子，在 LLM-as-a-judge 这篇论文中，提到的一个 prompt 设计如下：

可以看到，这段 prompt 设计的目的就是让 LLM 对一个 question 的 answer 进行打分，要考虑多方面的因素，得分在 1 到 10 之间。

那么，GPT-4，或者 LLM 本身做为一个裁判打分，它就不会有错吗？

根据我们目前的观察，GPT-4 这在方面做得已经很好了。人类都有可能打错分，GPT-4 的表现和人类类似，误判的比例保持在很低就可以保证这种方法的有效性。因此，如何设计 prompt 同样重要，这就要用到一些高级的 prompt 工程技巧，比如 multi-shot，或 CoT(Chain-of-Thought)思维链技巧。在设计这些 prompt 时，有时还要考虑 LLM 的一些偏见，比如 LLM 常见的位置偏见：当 prompt 比较长时，LLM 容易注意到 prompt 里前面的一些内容，而忽略一些中间位置的内容。

好在这些 prompt 的设计已经被设计和集成在 RAG 应用的评估工具中，我们的关注点可以放在其他地方，例如，大量访问 GPT-4 这种 LLM 需要消耗大量的 API key，加下来期待有更便宜的 LLM 或本地 LLM，能够达到“当好一个裁判”的水平。

02.各类评估工具

接下来我们来介绍一下目前比较常见、好用的 RAG 评估工具的基本使用方法及其相应特点。

• Ragas

Ragas 是专注于评估 RAG 应用的工具，通过简单的接口即可实现评估：

from ragas import evaluate
from datasets import Dataset

# prepare your huggingface dataset in the format
# Dataset({
#     features: ['question', 'contexts', 'answer', 'ground_truths'],
#     num_rows: 25
# })

dataset: Dataset

results = evaluate(dataset)
# {'ragas_score': 0.860, 'context_precision': 0.817,
# 'faithfulness': 0.892, 'answer_relevancy': 0.874}

只要把 RAG 过程中的question, contexts, answer, ground_truths，构建成一个 Dataset 实例，即可一键启动测评，非常方便。

Ragas指标种类丰富多样，对 RAG 应用的框架无要求，也可以通过 langsmith 来监控每次评估的过程，帮助分析每次评估的原因和观察 API key 的消耗。

• Llama-Index

Llama-Index 很适合用来搭建 RAG 应用，且它的生态比较丰富，目前也处在快速迭代发展中。Llama-Index 也有一部分评估的功能，用户可以方便地对由 Llama-Index 本身搭建的 RAG 应用进行评估：

from llama_index.evaluation import BatchEvalRunner
from llama_index.evaluation import (
    FaithfulnessEvaluator,
    RelevancyEvaluator,
)
service_context_gpt4 = ...
vector_index = ...
question_list = ...

faithfulness_gpt4 = FaithfulnessEvaluator(service_context=service_context_gpt4)
relevancy_gpt4 = RelevancyEvaluator(service_context=service_context_gpt4)

runner = BatchEvalRunner(
    {"faithfulness": faithfulness_gpt4, "relevancy": relevancy_gpt4},
    workers=8,
)

eval_results = runner.evaluate_queries(
    vector_index.as_query_engine(), queries=question_list
)

可以看到，在runner.evaluate_queries()中，需要传入一个BaseQueryEngine实例，也就是说，它比较适合评估 Llama-Index 本身搭建的 RAG 应用。如果是其它架构搭建的 RAG 应用，可能需要在工程上做一些转换。

• TruLens-Eval

Trulens-Eval 也是专门用于评估 RAG 指标的工具，它对 LangChain 和 Llama-Index 都有比较好的集成，可以方便地用于评估这两个框架搭建的 RAG 应用。我们以评估 LangChain 的 RAG 应用为例：

from trulens_eval import TruChain, Feedback, Tru，Select
from trulens_eval.feedback import Groundedness
from trulens_eval.feedback.provider import OpenAI
import numpy as np

tru = Tru()
rag_chain = ...

# Initialize provider class
openai = OpenAI()

grounded = Groundedness(groundedness_provider=OpenAI())
# Define a groundedness feedback function
f_groundedness = (
    Feedback(grounded.groundedness_measure_with_cot_reasons)
    .on(Select.RecordCalls.first.invoke.rets.context)
    .on_output()
    .aggregate(grounded.grounded_statements_aggregator)
)

# Question/answer relevance between overall question and answer.
f_qa_relevance = Feedback(openai.relevance).on_input_output()

tru_recorder = TruChain(rag_chain,
    app_id='Chain1_ChatApplication',
    feedbacks=[f_qa_relevance, f_groundedness])

tru.run_dashboard()

当然，Trulens-Eval 也可以评估原生的 RAG 应用。在代码上会相对复杂一些，需要使用 instrument在RAG 应用代码中注册，具体可以参考官方文档。此外，Trulens-Eval 也可以在浏览器中启动页面进行可视化地监控，帮助分析每次评估的原因和观察 API key 的消耗。

• Phoenix

Phoenix 有许多评估 LLM 的功能，比如评估 Embedding 效果、评估 LLM 本身。在评估 RAG 这个能力上，也留出接口，和生态对接，但目前看指标种类还不是很多。下面是用 Phoenix 评估 Llama-Index 搭建的 RAG 应用例子：

import phoenix as px
from llama_index import set_global_handler
from phoenix.experimental.evals import llm_classify, OpenAIModel, RAG_RELEVANCY_PROMPT_TEMPLATE, \
    RAG_RELEVANCY_PROMPT_RAILS_MAP
from phoenix.session.evaluation import get_retrieved_documents

px.launch_app()
set_global_handler("arize_phoenix")
print("phoenix URL", px.active_session().url)

query_engine = ...
question_list = ...

for question in question_list:
    response_vector = query_engine.query(question)

retrieved_documents = get_retrieved_documents(px.active_session())

retrieved_documents_relevance = llm_classify(
    dataframe=retrieved_documents,
    model=OpenAIModel(model_name="gpt-4-1106-preview"),
    template=RAG_RELEVANCY_PROMPT_TEMPLATE,
    rails=list(RAG_RELEVANCY_PROMPT_RAILS_MAP.values()),
    provide_explanation=True,
)

当px.launch_app()启动后，在本地可以打开一个网页，可以观察 RAG 应用链路中的每一步的过程。最近评估的结果还是放在retrieved_documents_relevance这里面。

• 其它

除上面这几个工具之外，DeepEval、LangSmith、OpenAI Evals 等工具都集成工评估 RAG 应用的能力，在使用方法和原理上大同小异，感兴趣的朋友可以深入了解。

03.总结

本文主要复盘了当前比较主流的评估框架和方法论，并介绍了相关工具的使用。因为当前 LLM 的各类应用发展迅速，在评估 RAG 这个赛道上，各种方法和工具如雨后春笋一样不断涌现。

虽然这些方法在大的框架上相似，但在具体实现方面，比如 prompt 的设计，仍处于百花齐放的状态。目前，我们还无法确定会有哪些工具能成为最后的王者，仍需时间的检验。期待在大浪淘沙后，开发者都能够找到最适合自己的工具。