精通 Llm 摘要：有效评估 Ai 摘要的 5 个关键指标
评估 AI 摘要的实用有效指南
图片来自 Unsplash
Summarization 是 LLMs 赋能的最实用和便捷的任务之一。然而，与问答或分类等其他 LLM 任务相比，评估 LLMs 在摘要方面的表现更具挑战性。
因此，即使我构建的两个应用程序严重依赖摘要（Podsmart 总结播客，而 aiRead 根据您的突出显示创建个性化的 PDF 摘要），我自己也忽略了对摘要的评估。
但最近，我被说服了——这要归功于 AI 行业思想领袖的深刻见解——评估在系统地评估和改进 LLM 系统中的关键作用。（链接 和 链接）。这促使我开始研究摘要的评估。
因此，在本文中，我将讨论一个易于实施、有研究支持且量化的框架来评估摘要，该框架改进了 Confident AI 创建的 DeepEval 框架中的 Summarization 指标。
我将通过一个示例笔记本来说明我的过程（代码在 Github 中），尝试评估一篇约 2500 字文章的约 500 字的摘要，该文章是 Securing the AGI Laurel: Export Controls, the Compute Gap, and China’s Counterstrategy（可在 此处 找到，于 2024 年 12 月发布）。
目录
- 为什么评估摘要很困难
- 什么构成一个好的摘要
- DeepEval 简介
- DeepEval 的 Summarization 指标
- 改进 Summarization 指标
- 简洁性指标
- 连贯性指标
- 整合所有内容
- 未来工作
为什么评估摘要很困难
在我开始之前，让我详细说明一下为什么我说摘要是一个难以评估的任务。
首先，摘要的输出本质上是开放式的（与分类或实体提取等任务相反）。因此，什么构成一个好的摘要取决于流畅性、连贯性和一致性等定性指标，这些指标不容易进行量化衡量。此外，这些指标通常是主观的——例如，相关性取决于上下文和受众。
其次，创建金标数据集来评估您的系统摘要非常困难。对于 RAG，创建合成问答对数据集来评估检索器非常简单（请参阅这个 不错的演练）。
对于摘要，没有明显的方法可以自动生成参考摘要，因此我们必须求助于人类来创建它们。虽然研究人员已经策划了摘要数据集，但这些数据集不会根据您的用例进行定制。
第三，我发现学术文献中的大多数摘要指标不适合面向实践的 AI 开发人员实施。一些论文训练了神经摘要指标（例如 Seahorse, Summac 等），它们有几个 GB 大，并且难以大规模运行（也许我只是懒惰，应该学习如何在本地和 GPU 集群上运行 HuggingFace 模型，但这仍然是大多数人的入门障碍）。其他传统指标（如 BLEU 和 ROUGE）依赖于确切的单词/短语重叠，并且是在 LLM 时代之前为提取式摘要创建的，可能不适用于评估 LLMs 生成的抽象摘要，LLMs 可能会释义源文本。
尽管如此，根据我的经验，人类可以轻松地区分好的摘要和坏的摘要。一种常见的失败模式是含糊不清和迂回（例如，“此摘要描述了……的原因”）。
什么构成一个好的摘要
那么，什么是一个好的摘要呢？Eugene Yan 的 文章 提供了关于各种摘要指标的良好细节。对我来说，我将它们提炼成 4 个关键品质：
- 相关 — 摘要保留了源文本中的重要要点和细节
- 简洁 — 摘要信息量大，不会多次重复相同的要点，并且不会不必要地冗长
- 连贯 — 摘要结构良好且易于理解，而不仅仅是一堆压缩的事实
- 忠实 — 摘要不会幻觉源文本不支持的信息
一个关键的见解是，您实际上可以将前两个表述为精确度和召回率问题——源文本中有多少事实保留在摘要中（召回率），以及摘要中有多少事实得到主文本的支持（精确度）。
这种表述将我们带回了 ML 中更熟悉的分类问题领域，并提出了一种量化评估摘要的方法。
这里的一些区别在于：首先，更高的召回率更好，保持摘要长度不变。您不希望使用与源文本长度相同的摘要获得 100% 的召回率。其次，您理想情况下希望精确度尽可能接近 100%——幻觉信息非常糟糕。稍后我将回到这些问题。
DeepEval 简介
您可以使用那里所有不同的 LLM 评估框架——从 Braintrust 到 Langfuse 等等——来做出选择。但是，今天我将使用 DeepEval，这是一个非常用户友好的框架，可以快速上手，既可以用于一般情况，也可以专门用于摘要。
DeepEval 具有许多关键 RAG 指标的现成实现，并且它有一个灵活的基于思维链的 LLM 作为判断工具，称为 GEval，供您定义您想要的任何自定义标准（我稍后会使用它）
此外，它还具有有用的基础设施来组织和加速评估：他们已经使用异步很好地并行化了所有内容，因此您可以快速地对整个数据集运行评估。他们有方便的功能来生成合成数据（将在后面的文章中介绍），并且他们允许您定义自定义指标以调整他们的指标（这正是我们今天要做的事情），或者定义非基于 LLM 的评估指标，以实现更具成本效益和鲁棒性的评估（例如，实体密度，稍后）。
DeepEval 的摘要指标
DeepEval 的摘要指标（在此处阅读更多信息 here）是一个无参考指标（即不需要黄金标准摘要），只需要作为 input 字段的源文本和要评估的生成摘要（actual_output 字段）。正如您所看到的，下面的设置和评估代码非常简单！
## Create a DeepEval test case for the purposes of the evaluation
test_case = LLMTestCase(
input = text,
actual_output = summary
)
## Instantiate the summarization metric
summarization_metric = SummarizationMetric(verbose_mode = True, n = 20, truths_extraction_limit = 20)
## Run the evaluation on the test case
eval_result = evaluate([test_case], [summarization_metric])
摘要指标实际上在后台评估两个独立的组件：* 对齐 * 和 * 覆盖率 *。这些与我之前介绍的 * 精度 * 和 * 召回率 * 公式密切相关！
对于对齐，评估器 LLM 从摘要中生成一份 * 声明 * 列表，并且对于每个声明，LLM 将确定源文本中提取的 * 真理 * 支持多少个这些声明，从而产生 * 对齐分数 *。
在覆盖率的情况下，LLM 从源文本中生成一份评估问题列表，然后尝试仅使用摘要作为上下文来回答这些问题。如果找不到答案，则会提示 LLM 回复“idk”。然后，LLM 将确定其中有多少个答案是正确的，以获得 * 覆盖率分数 *。
最终的摘要分数是对齐分数和覆盖率分数的最小值。
改进摘要指标
然而，尽管 DeepEval 已经做了一个很好的开端，但在其当前形式下，有三个关键问题阻碍了摘要指标的可靠性和实用性。
因此，我构建了一个自定义摘要指标，它改编了 DeepEval 的版本。下面，我将解释每一个问题以及我为克服它而实施的相应解决方案：
1：使用是/否问题作为覆盖率指标过于简单
目前，评估问题被限制为是/否问题，问题的答案是“是”——看看这些问题：
作者提供的图片
这有两个问题：
首先，将问题构建为二元的“是/否”会限制其信息量，尤其是在确定细微的定性点时。
其次，如果回答摘要的 LLM 幻觉出一个“是”的答案（因为只有 3 个可能的答案：“是”、“否”、“不知道”，它幻觉出“是”的可能性并不小），评估者会错误地认为这个答案是正确的。对于开放式问题，幻觉出正确答案要困难得多。此外，如果你查看这些问题，它们的措辞方式很做作，几乎暗示答案是“是”（例如，“中国是否采用信息不透明作为一种策略？”），因此增加了幻觉出“是”的可能性。
我的解决方案是让 LLM 从源文本生成开放式问题——在代码中，这些被称为“复杂问题”。
此外，我要求 LLM 分配一个问题的重要性（这样我们也许可以在覆盖率分数中提高更重要问题的权重）。
由于这些问题现在是开放式的，我使用一个用于评估的 LLM——我要求 LLM 给出一个0-5 分的相似度评分，评估从摘要生成的答案与从源文本（参考答案）生成的答案的相似程度，并给出解释。
def generate_complex_verdicts(answers):
return f"""You are given a list of JSON objects. Each contains 'original_answer' and 'summary_answer'.
Original answer is the correct answer to a question.
Your job is to assess if the summary answer is correct, based on the model answer which is the original answer.
Give a score from 0 to 5, with 0 being completely wrong, and 5 being completely correct.
If the 'summary_answer' is 'idk', return a score of 0.
Return a JSON object with the key 'verdicts', which is a list of JSON objects, with the keys: 'score', and 'reason': a concise 1 sentence explanation for the score.
..."""
def generate_complex_questions(text, n):
return f"""Based on the given text, generate a list of {n} questions that can be answered with the information in this document.
The questions should be related to the main points of this document.
Then, provide a concise 1 sentence answer to the question, using only information that can be found in the document.
Answer concisely, your answer does not need to be in full sentences.
Make sure the questions are different from each other.
They should cover a combination of questions on cause, impact, policy, advantages/disadvantages, etc.
Lastly, rate the importance of this question to the document on a scale of 1 to 5, with 1 being not important and 5 being most important.
Important question means the question is related to an essential or main point of the document,
and that not knowing the answer to this question would mean that the reader has not understood the document's main point at all.
A less important question is one asking about a smaller detail, that is not essential to understanding the document's main point.
..."""
2：从源文本中提取事实以进行对齐是有缺陷的
目前，对于对齐指标，使用 LLM 从源文本中提取一个事实列表（一个可以控制的参数truths_extraction_limit）。这导致源文本中的一些事实/细节从事实中省略，然后将摘要的声明与这些事实进行比较。
老实说，我不确定团队在这样实施时是怎么想的——也许我错过了细微差别或误解了他们的意图。
然而，这导致了两个问题，根据Github 上的一个用户的说法，这使得对齐分数“无法使用”。
首先，LLM 生成的事实列表是不确定的，因此人们报告了对齐分数的变化很大。这种不一致可能源于 LLM 每次选择不同的事实子集。更关键的是，事实提取过程使得这不能公平地判断摘要的忠实度，因为摘要中的一个细节可能在源文本中找到，但不在提取的事实中。根据传闻，所有被检测为不忠实的声明确实都在正文中，但不在提取的事实中。此外，有人报告，当你将摘要作为输入传递时，对齐分数小于 1，这很奇怪。
为了解决这个问题，我做了一个简单的调整——将整个源文本传递给评估摘要声明的 LLM，而不是事实列表。由于所有声明都在一个 LLM 调用中一起评估，这不会显著增加 token 成本。
3：最终分数是 min(对齐分数，覆盖率分数) 是有缺陷的
目前，输出的分数是对齐分数和覆盖率分数的最小值（实际上，如果不将其放入日志中，就无法访问各个分数）。
这是有问题的，因为覆盖率分数可能低于对齐分数（如果不是，那么就会出现真正的问题！）。这意味着对齐分数的改变不会影响最终分数。然而，这并不意味着我们可以忽略对齐分数的恶化（例如从 1 到 0.8），这可以说表明摘要存在更严重的问题（即幻觉声明）。
我的解决方案是将最终分数更改为 F1 分数，就像在 ML 分类中一样，以捕捉精确度和召回率的重要性。一个扩展是可以更改精确度和召回率的权重。（例如，如果你认为幻觉是需要不惜一切代价避免的事情，可以提高精确度的权重——参见这里)
通过这 3 个更改，摘要指标现在可以更好地反映生成摘要的相关性和忠实度。
简洁性指标
然而，这仍然给出了一个不完整的画面。一个摘要也应该简洁且信息密集，将关键信息浓缩成一个较短的版本。
实体密度是一个有用且廉价的指标。Chain-of-Density 论文表明，人类创建的摘要以及人类偏好的 AI 生成的摘要的实体密度约为 0.15 个实体/词元，在清晰度（倾向于密度较低）和信息量（倾向于密度较高）之间取得了适当的平衡。
因此，我们可以创建一个密度分数，该分数会惩罚实体密度离 0.15 较远的摘要（要么太密集，要么不够密集）。最初的 AI 生成的摘要通常密度较低（0.10 或更低），并且 Chain-of-Density 论文 显示了一个迭代过程来增加摘要的密度。Ivan Leo & Jason Liu 写了一篇关于使用实体密度作为关键指标来微调 Chain-of-Density 摘要的优秀文章。
import nltk
import spacy
nlp = spacy.load("en_core_web_sm")
def get_entity_density(text):
summary_tokens = nltk.word_tokenize(text)
num_tokens = len(summary_tokens)
# Extract entities
doc = nlp(text)
num_entities = len(doc.ents)
entity_density = num_entities / num_tokens
return entity_density
接下来，我使用一个句子模糊度指标来明确惩罚模糊的句子（‘此摘要描述了……的原因’），这些句子实际上并没有说明关键信息。
为此，我将摘要分解成句子（类似于对齐指标），并要求 LLM 对每个句子进行分类，判断其是否模糊，最终得分是分类为模糊的句子的比例。
prompt = ChatPromptTemplate.from_template(
"""You are given a list of sentences from a summary of a text.
For each sentence, your job is to evaluate if the sentence is vague, and hence does not help in summarizing the key points of the text.
Vague sentences are those that do not directly mention a main point, e.g. 'this summary describes the reasons for China's AI policy'.
Such a sentence does not mention the specific reasons, and is vague and uninformative.
Sentences that use phrases such as 'the article suggests', 'the author describes', 'the text discusses' are also considered vague and verbose.
...
OUTPUT:"""
)
class SentenceVagueness(BaseModel):
sentence_id: int
is_vague: bool
reason: str
class SentencesVagueness(BaseModel):
sentences: List[SentenceVagueness]
chain = prompt | llm.with_structured_output(SentencesVagueness)
最后，一个重复相同信息的摘要是低效的，因为它浪费了可以用来传达新的有意义见解的宝贵空间。
因此，我们使用GEval构建一个重复性分数。正如我上面简要提到的，GEval 使用 LLM-as-a-judge 评估任何自定义标准。由于检测重复概念是一个更复杂的问题，我们需要一个更智能的检测器，也就是一个 LLM。（警告：此指标的结果似乎很不稳定——当我反复对同一输入运行它时，LLM 会更改其答案。也许可以尝试一些提示工程)
from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCaseParams
repetitiveness_metric = GEval(
name="Repetitiveness",
criteria="""I do not want my summary to contain unnecessary repetitive information.
Return 1 if the summary does not contain unnecessarily repetitive information, and 0 if the summary contains unnecessary repetitive information.
facts or main points that are repeated more than once. Points on the same topic, but talking about different aspects, are OK. In your reasoning, point out any unnecessarily repetitive points.""",
evaluation_params=[LLMTestCaseParams.ACTUAL_OUTPUT],
verbose_mode = True
)
连贯性指标
最后，我们希望确保 LLM 的输出是连贯的——具有逻辑流程，将相关点放在一起并进行平滑的过渡。Meta 最近的 Large Concept Models 论文 使用了 Parola 等人（2023 年）的局部连贯性指标——每第 n 个和第 n+2 个句子之间的平均余弦相似度。一个易于实现的简单指标。我们发现 LLM 摘要的得分为 ~0.45。作为一种检查，如果我们随机排列摘要的句子，连贯性得分会降至 0.4 以下。
## Calculate cosine similarity between each nth and n+2th sentence
def compute_coherence_score(sentences):
embedding_model = OpenAIEmbeddings(model="text-embedding-3-small")
sentences_embeddings = embedding_model.embed_documents(sentences)
sentence_similarities = []
for i in range(len(sentences_embeddings) - 2):
# Convert embeddings to numpy arrays and reshape to 2D
emb1 = np.array(sentences_embeddings[i])
emb2 = np.array(sentences_embeddings[i+2])
# Calculate cosine distance
distance = cosine(emb1, emb2)
similarity = 1 - distance
sentence_similarities.append(similarity)
coherence_score = np.mean(sentence_similarities)
return coherence_score
整合所有内容
我们可以将上述每个指标打包到自定义指标中。好处是我们可以并行评估您的摘要数据集中的所有指标，并在一个地方获得所有结果！（请参阅代码笔记本）
但是，需要注意的是，对于某些指标（如连贯性或召回率），对于摘要来说，没有什么是“最佳”值，我们只能比较不同 AI 生成的摘要的得分来确定更好或更差。
未来工作
我在本文中介绍的内容为评估您的摘要提供了一个坚实的起点！
但这并不完美，还有一些领域需要进一步探索和改进。
一个领域是更好地测试摘要是否捕捉了源文本中的重要点。您不希望摘要具有高召回率，但却包含不重要的细节。
目前，当我们生成评估问题时，我们会要求 LLM 评估它们的重要性。然而，也很难将这些重要性评级作为事实依据——如果您仔细想想，当 LLM 总结时，它们本质上也会对不同事实的重要性进行评级。因此，我们需要一种LLM 之外的重要性度量。当然，理想的情况是有人工参考摘要，但这些成本高昂且不可扩展。另一种参考摘要来源将是带有执行摘要的报告（例如，财务推介、幻灯片组的结论、论文的摘要）。我们还可以使用诸如嵌入的 PageRank 之类的技术来以算法方式识别核心概念。
一个有趣的尝试是生成合成源文章——从一组关于给定主题的主要点（代表事实依据的“重要”点）开始，然后要求 LLM 将其扩展为一篇完整的文章（使用高温多次运行此过程以生成许多不同的合成文章！）。然后，通过总结过程运行完整的文章，并根据保留原始要点来评估摘要。
最后但同样重要的是，确保我介绍的每个总结指标都与人类对摘要偏好的评估相关非常重要。虽然研究人员已经对大型总结数据集上的一些指标进行了研究，但这些发现可能无法推广到您的文本和/或受众。（也许您的公司更喜欢特定风格的摘要，例如，包含许多统计数据）。
关于这个主题的精彩讨论，请参阅 Hamel Husain 的 关于评估的文章 的“第 2 级”。例如，如果您发现 LLM 的句子模糊度分数与您认为模糊的句子没有很好的相关性，那么一些提示工程（提供模糊句子的示例，进行更详细的阐述）有望提高相关性。
虽然这一步可能很耗时，但它至关重要，以确保您可以信任 LLM 评估。从长远来看，这将为您节省时间——当您的 LLM 评估对齐时，您本质上会获得一个无限可扩展的评估器，该评估器已根据您的需求和偏好进行了定制。
您可以通过创建一个易于使用的 Gradio 注释界面来加快您的人工评估过程——我使用 OpenAI o1 一键创建了一个不错的界面！
在未来的文章中，我将讨论如何实际使用这些见解来改进我的总结过程。两年前，我写道了如何总结长文本，但 LLM 的进步和 2 年的经验使我的总结方法发生了巨大变化。
非常感谢您的阅读！如果您错过了，所有代码都可以在 GitHub 存储库这里找到。
