RAG 评估指南：从检索到生成的 LLM 性能评估方法

数据集应该确保问答数据集中的问题均衡，既有来自文本的问题，也有来自图像和文本的问题，还有一些问题仅来自图像。还确保问题分布在各种源文档中。

当评估集相对较小时，可以通过纳入各种边缘情况来确保其多样性。可以从彻底的探索性数据分析 (EDA) 开始，图片中的例子提取了诸如文章长度、表格长度和文本表格数量以及图像类型、分辨率和图像数量等特征。然后，仔细地将评估集分布在这些特征上，以实现特征空间的全面表示和稳健覆盖。此外，该系统还支持同一问题的替代来源和图像。

评估图片实操

# 模拟的检索结果，即检索算法返回的结果
retrieved_images = ['img1.jpg', 'img2.jpg', 'img3.jpg', 'img4.jpg', 'img5.jpg']

# 真实的标注结果，即与查询图像相关的所有图像
ground_truth_images = ['img1.jpg', 'img2.jpg', 'img3.jpg', 'img6.jpg', 'img7.jpg']

# 计算召回率
def calculate_recall(retrieved, ground_truth):
    # 将列表转换为集合，以便使用集合操作
    retrieved_set = set(retrieved)
    ground_truth_set = set(ground_truth)
    
    # 计算召回率
    recall = len(retrieved_set.intersection(ground_truth_set)) / len(ground_truth_set)
    return recall

# 调用函数计算召回率
recall = calculate_recall(retrieved_images, ground_truth_images)
print(f"召回率：{recall:.2f}")

我们这里用比较简单的方式抽象一下，具体从 markdown 中提取图像的标签的细节就不罗嗦了，实际上是差不多的。

各评估方式综述

评估方法衡量我们系统的表现。对每个摘要进行手动评估（人工审核）既耗时又费钱，而且不可扩展，因此通常用自动评估来补充。许多自动评估方法试图衡量人类评估者会考虑的文本质量。这些质量包括流畅性、连贯性、相关性、事实一致性和公平性。内容或风格与参考文本的相似性也是生成文本的重要质量。

下图包括用于评估 LLM 生成内容的许多指标及其分类方法。

Reference-based Metrics

基于参考的指标用于将生成的文本与参考（人工注释的地面实况文本）进行比较。许多此类指标是在 LLM 开发之前为传统 NLP 任务开发的，但仍然适用于 LLM 生成的文本。

N-gram based metrics

指标 BLEU (Bilingual Evaluation Understudy), ROUGE (Recall-Oriented Understudy for Gisting Evaluation), and JS divergence (JS2) 是基于重叠的指标，使用 n-gram 来衡量输出文本和参考文本的相似性。

BLEU Score

BLEU（双语评估测试）分数用于评估从一种自然语言到另一种自然语言的机器翻译文本的质量。因此，它通常用于机器翻译任务，但也用于其他任务，如文本生成、释义生成和文本摘要。其基本思想是计算精度，即参考翻译中候选词的比例。通过将单个翻译片段（通常是句子）与一组高质量的参考翻译进行比较，计算出分数。然后，将这些分数在整个语料库中取平均值，以估计翻译的整体质量。评分时不考虑标点符号或语法正确性。

很少有人工翻译能获得完美的 BLEU 分数，因为完美的分数表明候选译文与其中一个参考译文完全相同。因此，没有必要获得完美的分数。考虑到随着多个参考译文的增加，匹配的机会更多，我们鼓励提供一个或多个参考译文，这将有助于最大化 BLEU 分数。

通常，上述计算会考虑目标中出现的候选单词或单元词组。但是，为了更准确地评估匹配，可以计算二元词组甚至三元词组，并对从各种 n 元词组获得的分数取平均值，以计算总体 BLEU 分数。

ROUGE

与 BLEU 分数相反，面向召回率的摘要评估 (ROUGE) 评估指标衡量的是召回率。它通常用于评估生成文本的质量和机器翻译任务。但是，由于它衡量的是召回率，因此它用于摘要任务。在这些类型的任务中，评估模型可以召回的单词数量更为重要。

ROUGE 类中最流行的评估指标是 ROUGE-N 和 ROUGE-L：

Text Similarity metrics

文本相似度指标评估器专注于通过比较文本元素之间单词或单词序列的重叠来计算相似度。它们可用于为 LLM 和参考标准文本的预测输出生成相似度分数。这些指标还可以指示模型在各个任务中的表现如何。

Levenshtein Similarity Ratio

编辑相似度比率是用于衡量两个序列之间相似度的字符串指标。此度量基于编辑距离。通俗地说，两个字符串之间的编辑距离是将一个字符串更改为另一个字符串所需的最小单字符编辑（插入、删除或替换）次数。编辑相似度比率可以使用编辑距离值和两个序列的总长度来计算。

从简单编辑相似度比率中衍生出几种不同的方法：

• 部分比率：通过取最短字符串计算相似度，并将其与较长字符串中相同长度的子字符串进行比较。
• 标记排序比率：首先将字符串拆分为单个单词或标记，然后按字母顺序对标记进行排序，最后将它们重新组合成一个新字符串，以此计算相似度。然后使用简单比率方法比较这个新字符串。
• Token-set Ratio：首先将字符串拆分成单个单词或者 Token，然后计算两个字符串之间 Token 集的交集与并集，以此来计算相似度。

Semantic Similarity metrics

BERTScore, MoverScore 和 Sentence Mover Similarity (SMS) 这些指标都依赖于语境化嵌入来衡量两段文本之间的相似性。虽然与基于 LLM 的指标相比，这些指标相对简单、快速且计算成本低廉，但研究表明，它们与人类评估者的相关性较差、缺乏可解释性、固有偏见、对各种任务的适应性较差，并且无法捕捉语言中的细微差别。

两个句子之间的语义相似度是指它们的含义有多紧密相关。为此，首先将每个字符串表示为一个特征向量，以捕获其语义含义。一种常用的方法是生成字符串的嵌入（例如，使用 LLM），然后使用余弦相似度来测量两个嵌入向量之间的相似度。更具体地说，给定一个表示目标字符串的嵌入向量 (A) 和一个表示参考字符串的嵌入向量 (B)，余弦相似度计算如下：

如上所示，该度量测量两个非零向量之间角度的余弦，范围从 -1 到 1。1 表示两个向量相同，-1 表示它们不相似。

Reference-free Metrics

无参考（基于上下文）指标会为生成的文本生成分数，并且不依赖于基本事实。评估基于上下文或源文档。许多此类指标都是为了应对创建基本事实数据的挑战而开发的。这些方法往往比基于参考的技术更新，反映了随着 PTM 变得越来越强大，对可扩展文本评估的需求日益增长。这些指标包括基于质量、基于蕴涵、基于事实、基于问答 (QA) 和基于问题生成 (QG) 的指标。

• 基于质量的摘要指标：这些方法检测摘要是否包含相关信息。SUPERT 质量衡量摘要与基于 BERT 的伪参考的相似性，而 BLANC 质量衡量两个掩码标记重建的准确性差异。ROUGE-C 是 ROUGE 的修改版，无需参考，并使用源文本作为比较的上下文。
• 基于蕴涵的指标：基于蕴涵的指标基于自然语言推理 (NLI) 任务，对于给定的文本（前提），它确定输出文本（假设）是否蕴涵、与前提相矛盾或破坏前提。这有助于检测事实不一致。SummaC (Summary Consistency) benchmark、FactCC 和 DAE (Dependency Arc Entailment) 指标可用作检测与源文本的事实不一致的方法。基于蕴涵的指标被设计为带有'一致'或'不一致'标签的分类任务。
• 基于事实性、QA 和 QG 的指标：基于事实性的指标（如 SRLScore (Semantic Role Labeling）和 QAFactEval）评估生成的文本是否包含与源文本不符的不正确信息。基于 QA（如 QuestEval）和基于 QG 的指标被用作另一种衡量事实一致性和相关性的方法。

与基于参考的指标相比，无参考指标与人类评估者的相关性有所提高，但使用无参考指标作为任务进度的单一衡量标准存在局限性。一些 limitations 包括对其底层模型输出的偏见和对更高质量文本的偏见。

LLM-based Evaluators

LLM 的卓越能力使其不仅可用于生成文本，还可用于文本评估。这些评估器具有可扩展性和可解释性。

Prompt-based evaluators

基于 LLM 的评估者会要求 LLM 评判一些文本。评判可以基于 (i) 文本本身（无参考），LLM 评判流畅性和连贯性等品质；(ii) 生成的文本、原始文本以及可能的主题或问题（无参考），LLM 评判一致性和相关性等品质；(iii) 生成的文本与基本事实之间的比较（基于参考），LLM 评判质量和相似性。这些评估提示的一些框架包括推理然后评分 (RTS)、多项选择题评分 (MCQ)、面对面评分 (H2H) 和 G-Eval。GEMBA 是评估翻译质量的指标。

LLM 评估是一个新兴的研究领域，尚未得到系统研究。研究人员已经发现 LLM 评估人员的可靠性存在问题，例如位置偏见、冗长偏见、自我提升偏见、有限的数学和推理能力，以及 LLM 在分配数字分数方面的成功问题。为减轻位置偏见而提出的策略包括多重证据校准 (MEC)、平衡位置校准 (BPC) 和人机交互校准 (HITLC)。

Example of a prompt-based evaluator

我们可以获取模型产生的输出，并提示模型确定生成的完成的质量。使用此评估方法通常需要以下步骤：

1. 从给定的测试集生成输出预测。
2. 提示模型重点评估输出的质量——给定参考文本和足够的上下文（例如，评估标准）。
3. 将提示输入模型并分析结果。

在提供足够的提示和上下文的情况下，模型应该能够给出分数。虽然 GPT-4 通过这种评估方法取得了相当不错的结果，但仍需要人工来验证模型生成的输出。在特定领域的任务或涉及应用特定方法评估输出的情况下，模型可能表现不佳。因此，应根据数据集的性质仔细研究模型的行为。请记住，执行基于 LLM 的评估需要自己的提示工程。下面是 NL2Python 应用程序中使用的示例提示模板。

You are an AI-based evaluator. Given an input (starts with --INPUT) that consists or a user prompt (denoted by STATEMENT)
and the two completions (labelled EXPECTED and GENERATED), please do the following:
1- Parse user prompt (STATEMENT) and EXPECTED output to understand task and expected outcome.
2- Check GENERATED code for syntax errors and key variables/functions.
3- Compare GENERATED code to EXPECTED output for similarities/differences, including the use of appropriate Python functions and syntax.
4- Perform a static analysis of the GENERATED code to check for potential functional issues, such as incorrect data types, uninitialized variables,
   and improper use of functions.
5- Evaluate the GENERATED code based on other criteria such as readability, efficiency, and adherence to best programming practices.
6- Use the results of steps 2-5 to assign a score to the GENERATED code between 1 to 5, with a higher score indicating better quality.
   The score can be based on a weighted combination of the different criteria.
7- Come up an explanation for the score assigned to the GENERATED code. This should also mention if the code is valid or not
When the above is done, please generate an ANSWER that includes outputs:
--ANSWER
EXPLANATION:
SCORE:
Below are two example:
# Example 1
--INPUT
STATEMENT = create a cube
EXPECTED = makeCube()
GENERATED = makeCube(n='cube1')
--ANSWER
SCORE: 4
EXPLANATION: Both completions are valid for creating the cubes. However, the GENERATED one differs by including the cube name (n=cube1), which is not necessary.
# Example 2
--INPUT
STATEMENT = make cube1 red
EXPECTED = changeColor(color=(1, 0, 0), objects=["cube1"])
GENERATED = makeItRed(n='cube1')
--ANSWER
SCORE: 0
EXPLANATION: There is no function in the API called makeItRed. Therefore, this is a made-up function.
Now please process the example blow
--INPUT
STATEMENT = {prompt}
EXPECTED = {expected_output}
GENERATED = {completion}
--ANSWER

LLM 评估器的输出通常是一个分数（例如 0-1）和一个可选的解释，这是我们通过传统指标不一定能得到的。

LLM embedding-base metrics

最近，来自 LLM 的嵌入模型（例如 GPT3 的 text-embedding-ada-002）也已用于计算语义相似度的基于嵌入的度量。

Metrics for LLM-generated code

当使用 LLM 生成代码时，适用以下指标。

功能正确性

当 LLM 负责为自然语言中的特定任务生成代码时，功能正确性会评估 NL 到代码生成任务的准确性。在这种情况下，功能正确性评估用于评估生成的代码是否针对给定输入产生所需的输出。

例如，为了使用功能正确性评估，我们可以定义一组涵盖不同输入及其预期输出的测试用例。例如，我们可以定义以下测试用例：

Input: 0
Expected Output: 1
Input: 1
Expected Output: 1
Input: 2
Expected Output: 2
Input: 5
Expected Output: 120
Input: 10
Expected Output: 3628800

然后，我们可以使用 LLM 生成的代码来计算每个输入的阶乘，并将生成的输出与预期输出进行比较。如果生成的输出与每个输入的预期输出相匹配，则我们认为测试用例已通过，并得出结论，LLM 在功能上对于该任务是正确的。

功能正确性评估的局限性在于，有时设置用于实现生成代码的执行环境的成本过高。此外，功能正确性评估没有考虑生成代码的以下重要因素：

• 可读性
• 可维护性
• 效率

此外，定义一套全面的测试用例来覆盖给定任务的所有可能输入和边缘情况非常困难。这种困难会限制功能正确性评估的有效性。

Rule-based Metrics

对于特定领域的应用和实验，实施基于规则的指标可能会很有用。例如，假设我们要求模型为给定任务生成多个完成。我们可能有兴趣选择最大化某些关键字出现在提示中的概率的输出。此外，在某些情况下，整个提示可能没有用 - 只有关键实体才有用。创建一个对生成的输出执行实体提取的模型也可用于评估预测输出的质量。考虑到许多可能性，考虑针对特定领域任务量身定制的基于规则的自定义指标是一种很好的做法。在这里，我们为 NL2Code 和 NL2NL 用例提供了一些广泛使用的基于规则的评估指标的示例：

• 语法正确性：此指标衡量生成的代码是否符合所用编程语言的语法规则。可以使用一组检查常见语法错误的规则来评估此指标。常见语法错误的例子包括缺少分号、变量名称不正确或函数调用不正确。
• 格式检查：可用于评估 NL2Code 模型的另一个指标是生成的代码的格式。此指标衡量生成的代码是否遵循一致且可读的格式。可以使用一组检查常见格式问题的规则来评估它，例如缩进、换行符和空格。
• 语言检查：语言检查指标评估生成的文本或代码是否易于理解并与用户输入一致。可以使用一组规则来评估此检查，这些规则检查常见的语言问题，例如错误的词汇选择或语法。
• 关键词存在：此指标衡量生成的文本是否包含自然语言输入中使用的关键词或关键短语。可以使用一组规则对其进行评估。这些规则检查是否存在与正在执行的任务相关的特定关键词或关键短语。

自动测试生成

我们还可以使用 LLM 进行自动测试生成，其中 LLM 生成各种各样的测试用例，包括不同的输入类型、上下文和难度级别：

• 生成的测试用例：正在评估的 LLM 的任务是解决生成的测试用例。
• 预定义指标：基于 LLM 的评估系统使用预定义的指标（例如相关性和流畅性）来衡量模型的性能。
• 比较和排名：将结果与基线或其他 LLM 进行比较，提供对模型相对优势和劣势的了解。

Metrics for RAG pattern

检索增强生成 (RAG) 模式是一种提高 LLM 性能的常用方法。该模式涉及从知识库中检索相关信息，然后使用生成模型生成最终输出。检索和生成模型都可以是 LLM。来自 RAGAS 实现的以下指标（RAGAS 是检索增强生成管道的评估框架）需要每个查询检索到的上下文，可用于评估检索模型和生成模型的性能：

与生成相关的指标：

• 忠实度：衡量生成的答案与给定上下文的事实一致性。如果答案中有任何无法从上下文中推断出来的主张，那么这些主张将受到惩罚。这是使用两步范式完成的，包括从生成的答案中创建陈述，然后根据上下文验证每个陈述（推理）。它是根据答案和检索到的上下文计算出来的。答案被缩放到 (0,1) 范围，其中 1 是最佳值。
• 答案相关性：指答案直接针对给定问题或上下文的程度。这不考虑答案的真实性，而是惩罚问题中存在的冗余信息或不完整答案。它是根据问题和答案计算得出的。

检索相关指标：

• 上下文相关性：衡量检索到的上下文与问题的相关性。理想情况下，上下文应仅包含回答问题所需的信息。上下文中存在冗余信息会受到惩罚。反映检索管道的质量。它是根据问题和检索到的上下文计算得出的。
• 语境回忆率：使用带注释的答案作为基本事实来衡量检索到的语境的回忆率。带注释的答案被视为基本事实语境的代理。它是根据基本事实和检索到的语境计算得出的。

实现框架

• Azure Machine Learning prompt flow：提供九种内置评估方法，包括分类指标。

• OpenAI Evals：Evals 是一个用于评估 LLM 和 LLM 系统的框架，也是一个基准的开源注册表。

评估策略选择建议

在实际项目中，选择合适的评估策略至关重要。以下是针对不同场景的建议：

1. 资源受限场景：优先使用计算成本较低的指标，如 BLEU、ROUGE 或基于嵌入的语义相似度（BERTScore）。这些指标可以快速迭代，适合早期原型验证。
2. 高可靠性需求场景：对于医疗、法律等高风险领域，必须引入基于事实性的指标（如 QAFactEval）和人工抽检。结合 LLM 作为评估器进行深度审查，确保输出内容的准确性和安全性。
3. 多模态 RAG 场景：除了传统的文本指标外，需特别关注图文检索的召回率（Recall@K）和跨模态语义对齐。使用专门的图像检索评估代码（如前文示例）来量化检索效果。
4. 代码生成场景：重点关注功能正确性（通过单元测试）和语法规范性。结合静态分析工具（如 Pylint）与动态执行测试，确保生成的代码可运行且符合规范。

通过综合使用上述指标和框架，开发者可以更全面地监控和优化 RAG 系统的性能，确保最终交付的产品满足业务需求。