Elasticsearch:评估 RAG - 指标之旅

作者:Quentin HerrerosThomas VeaseyThanos Papaoikonomou

2020年,Meta发表了一篇题为 "知识密集型NLP任务的检索增强生成" 的论文。 本文介绍了一种通过利用外部数据库将语言模型 (LLM) 知识扩展到初始训练数据之外的方法。 从那时起,这种方法引起了研究人员的极大关注,并且由于其巨大的好处仍然是一个突出且备受讨论的话题。 这些优点包括易于更新知识数据库、使较小的模型能够在特定任务上匹配较大模型的性能、允许生成泛化到训练数据之外的领域、减少幻觉的发生等等。

所有这些实验和发现总是围绕着测量模型在给定任务上的性能。 不幸的是,鉴于其固有的开放性和宽容性,评估生成文本的质量提出了重大挑战。 在 "搜索" 场景中,存在一个 "理想" 文档排名,它允许直接比较来衡量与该理想排名的吻合程度。 然而,当涉及到在回答问题或总结内容方面评估生成文本的质量时,任务变得相当复杂。

在本博客中,我们的主要重点将是 RAG(检索增强生成)问答任务,更具体地说是闭域 QA。 我们将深入研究该领域常用的一些各种指标。 我们将深入探讨这些指标并解释 Elastic 为有效监控模型性能而做出的决策。

N-gram 指标

在这一系列指标中,其想法是检查生成的文本与 "真实情况" 的相似程度。 基于这个想法有很多变体,我们只讨论其中的几个。

  • BLEU 分数:双语评估研究,称为 BLEU,是一种用于评估机器生成的段落与一个或多个参考段落进行比较的质量的指标。 它通过分析共享 n-grams(n 个连续单词的序列)的存在来量化相似性。 BLEU 分数的分配范围为 0 到 1,分数越高表示生成的文本与参考文本之间的对齐程度越接近(见下文)。

图 1 - 用于计算 BLEU 的 1-gram 精度(也称为 BLEU-1),BLEU 是根据不同 n-gram 的这些分数以及简洁的附加因素构建的

  • ROUGE 分数:面向召回的 Gisting 评估通常用于评估机器生成摘要的有效性。 它通过计算共享单词或短语来评估生成的段落与参考段落的相似程度。 ROUGE 与 BLEU 的评分不同,它计算召回率,而 BLEU 计算精度。 这意味着 ROUGE 主要关注确定生成的段落中包含多少来自参考段落的信息。 这一特性使得 ROUGE 成为与摘要相关的任务的流行选择。
  • METEOR 分数:显式排序翻译评估指标是机器生成领域广泛使用的指标。 METEOR 与前面提到的指标不同,它结合了精确率和召回率的调和平均值。 此外,在评估单词匹配时,它还会考虑同义词、词干和词序(通过碎片惩罚)。 与 BLEU 相比,这些属性有助于 METEOR 与人类判断实现更强的相关性。

虽然这些指标可以作为快速、直接评估 LLMs 的宝贵工具,但它们具有某些局限性,使其不太理想。 首先,他们在评估段落的流畅性、连贯性和整体意义方面存在不足。 他们对词序也相对不敏感。 此外,尽管 METEOR 试图通过同义词和词干来解决这个问题,但这些评估工具缺乏语义知识,使得它们对语义变化视而不见。 这个问题在有效评估长文本时尤其严重,因为将文本仅仅视为一组段落过于简单化。 此外,对 "模板答案" 的依赖使得它们在大规模评估中使用起来昂贵,并且引入了对模板中使用的确切措辞的偏见。 最后,对于特定任务,研究表明 BLEU 和 ROUGE 分数与人类判断之间的相关性实际上相当低。 出于这些原因,研究人员试图寻找改进的指标。

内在指标

困惑度(通常缩写为 PPL)是评估语言模型 (LLM) 的最常见指标之一。 计算困惑度需要访问模型生成的每个单词的概率分布。 它衡量模型预测单词序列的信心程度。 困惑度越高,模型预测观察到的序列的信心就越低。 正式地,它的定义如下:

这里 是根据模型以句子中其他标记 (!= i) 为条件的 个标记的对数预测概率。 为了说明这一点,下面的示例说明了如何计算词汇量只有三个单词的模型的困惑度。

图 2 - 困惑度得分示例

困惑度的一个显着好处是它的计算速度,因为它仅依赖于输出概率并且不涉及外部模型。 此外,它往往与模型的质量具有很强的相关性(尽管这种相关性可能会根据所使用的测试数据集而有所不同)。

尽管如此,困惑度也伴随着某些可能带来挑战的限制。 首先,它依赖于模型的信息密度,因此很难比较词汇量大小或上下文长度不同的两个模型。 比较数据集之间的分数也是不可能的,因为某些评估数据本质上可能比其他数据具有更高的复杂度。 此外,它可能对词汇差异过于敏感,可能会惩罚以不同方式表达相同答案的模型,即使两个版本都有效。 最后,困惑度不太适合评估模型处理语言歧义、创造力或幻觉的能力。 特别是在歧义性方面,序列的其余部分很难确定的单词会增加困惑,但它们并不是生成或理解不良的指标。 它可能会惩罚一个比能力较差的模型更好地理解模糊性的模型。 由于这些缺点,NLP 社区探索了更先进的外在指标来解决这些问题。

基于模型的指标

内在和 N-gram 指标有一个显着的缺点,因为它们不利用语义理解来评估生成内容的准确性。 因此,它们可能不会像我们想要的那样与人类的判断紧密一致。 基于模型的指标已成为解决此问题的更有前景的解决方案。

  • BERTScore:为了从语义的角度理解句子的真正含义,BERTScore 使用著名的基于 Transformer 的模型 BERT。 它会查看我们想要评估的句子和参考句子,然后通过利用两个句子中标记的上下文嵌入来比较它们的相似程度。 最终分数计算为最接近标记对的余弦相似度的加权组合。
  • BLEURT:基本概念与 BERTScore 非常相似,因为它依赖于基于 Transformer 的模型来评估参考文本和候选文本之间的相似性。 然而,BLEURT 的训练包含两个关键的增强功能。 首先,它使用预训练步骤,使用基于维基百科内容进行随机更改的数据集来模拟生成的输出可变性。 此外,它还使用了一个微调步骤,其中结合了人类评分来改进其性能。
  • BARTScore:这个想法是将评估生成文本的问题转化为文本生成问题。 使用基于 BART 的经过专门训练的序列到序列模型,能够使用给定另一个输入文本 x 的一个生成文本 y 的加权对数概率来获得分数。 BARTScore 支持从不同角度(忠实度、精确度、召回率等)评估生成的文本,这使其功能强大。

图 3 - 来自 BARTScore 论文的 WMT19 数据集上不同指标的 Kendall Tau 相关性

BERTcore 和 BLEURT 本质上可以被视为 n-gram 召回,但使用上下文表示。 另一方面,BARTScore 更接近于目标和生成文本之间的困惑度测量,使用评估模型而不是模型本身。 虽然这些基于模型的指标提供了强大的评估功能,但它们比 BLEU 或 PPL 慢,因为它们涉及外部模型。 在许多世代背景下,BLEU 与人类判断之间的相关性相对较低,这意味着这种权衡是合理的。 基于简单相似性的指标在选择 LLMs 时仍然很受欢迎(如 Hugging Face 排行榜所示)。 这种方法可能可以作为一个合理的代理,但考虑到当前最先进的 LLMs 的能力,它还不够。

Elastic 的选择:UniEval

UniEval 将所有评估维度统一到布尔问答框架中,允许单个模型从各个角度评估生成的文本。 例如,如果其中一个评估维度是相关性,那么人们会直接询问模型"这是这个问题的相关答案吗?"。给定一组由评估维度确定的任务,训练一个模型,该模型能够 根据这些维度评估生成的文本。UniEval 采用 T5 作为基础模型,采用两步训练过程。第一步称为 "中间多任务学习",利用查询和上下文来处理统一为布尔 QA 任务的多个任务 来自预先存在的相关数据集。随后,第二步需要顺序训练,其中模型逐个维度地学习如何评估生成文本的不同方面。预训练的 UniEval 模型面向摘要,但我们认为 RAG 问答可以被视为一项积极的总结任务,它避免了参数记忆以获得准确的响应。它已经在以下维度进行了训练:

  • 连贯性,衡量所有句子的凝聚力的形成。
  • 一致性,评估答案与上下文之间的事实一致性。
  • 流利度,评估单个句子的质量。
  • 相关性,衡量答案与事实真相之间的事实一致性。

图 4 - Topical-Chat 基准上的 Pearson 和 Spearman 相关性在所有 UniEval 维度上平均

虽然 UniEval 非常强大,但截至我们撰写本文时,它目前还不具备 "最先进" 评估模型的称号。 似乎基于 GPT 的评估器(例如 G-Eval)可能比 UniEval 表现出与人类判断更强的相关性(仅在基于 GPT-4 的评估器的情况下)。 然而,必须考虑显着的成本差异。 UniEval 是一个包含 8 亿个参数的模型,而 GPT-4 估计拥有 1.76 万亿个参数。 我们坚信,G-Eval-4 的微小优势并不能因为成本的大幅增加而得到证明。

实际使用情况

我们刚刚开始探索 UniEval,并且打算在未来将其合并到许多涉及文本生成的令人兴奋的项目中。 然而,有了这个评估模型,我们决定通过解决三个具体问题来测试其功能。

我们可以轻松地使用 UniEval 来比较 LLMs 的质量吗?

当你有评估指标时,这可能是你首先想到的考虑因素。 它是预测 LLMs 质量的有效工具吗? 我们对 Mistral-7b-Instruct 和 Falcon-7b-Instruct 进行了基准测试,以评估这两个模型在流畅性、一致性、连贯性和相关性方面的区别程度。 对于此基准测试,我们使用了来自 18 个数据集的 200 个查询,确保了多样化的上下文(包括 BioASQ、BoolQ、CoQA、CosmosQA、HAGRID、HotpotQA、MSMARCO、MultiSpanQA、NarrativeQA、NewsQA、NQ、PopQA、QuAC、SearchQA、SleepQA、 SQuAD、ToolQA、TriviaQA、TruthfulQA)。 给予 Mistral/Falcon 的提示包括查询和包含回答查询所需信息的上下文。

图 5 - Mistral 和 Falcon 的 UniEval 评估以及 3600 个查询的分数分布。 分数越高越好。

在这个特定的例子中,很明显,Mistral 在所有评估维度上都优于 Falcon,因此决策非常简单。 然而,在其他情况下可能更具挑战性,特别是在相关性和一致性之间做出决定时,这两者对于 RAG 问答都至关重要。

"一致性得分"与模型产生的幻觉数量相关吗?

实验很简单。 我们从 SQuAD 2.0 数据集中收集了大约 100 个查询。 接下来,我们使用 UniEval 评估模型(在本例中具体为 Mistral-7B-Instruct-v0.1,但它可以是任何模型)。 接下来,我们手动检查并注释生成的表现出幻觉的文本。 之后,我们创建一条校准曲线来检查 "一致性分数" 是否可以作为幻觉概率的可靠预测因子。 简单来说,我们正在调查 "一致性分数" 和幻觉数量是否相关。

图 6 - 幻觉检测一致性校准曲线

据观察,一致性被证明是幻觉概率的可靠指标,尽管它并非完美无缺。 我们遇到过幻觉很微妙且难以识别的情况。 此外,我们测试的模型偶尔会提供正确的答案,这些答案并非来自提示的上下文,而是来自其参数记忆。 就一致性指标而言,这类似于幻觉,尽管答案是准确的。 这就是为什么平均而言,我们检测到的幻觉数量多于实际数量。 值得注意的是,在某些实验中,我们故意加入误导性提示,从而误导了生成过程和我们对其的评估。 这证明 UniEval 并不是灵丹妙药。

解码策略如何影响评估维度?

在本实验中,我们想要比较 Falcon-7b-Instruct 中解码信息的不同方式。 我们在 18 个数据集上尝试了多种方法,每个数据集使用 5 个查询(总共 90 个查询):

  • 贪婪解码,我们选择最有可能的标记。
  • 波束解码,涉及维护多个可能的路径并选择总体概率最高的路径(使用 5 个波束)。
  • TopK 解码,我们选择顶部候选者,在它们之间重新分配概率,然后对令牌进行采样(顶部 k 值为 4)。
  • 核解码,与 TopK 类似,但基于概率质量阈值(阈值=0.95,max_topk=50)具有可变数量的候选者。
  • 对比解码,对排名靠前的候选者进行惩罚,以鼓励选择过程中的多样性(penalty_alpha=0.6,topk=4)。

图 7 - 使用 UniEval 进行解码策略基准测试

根据早期的研究,最有效的方法是对比解码。 值得注意的是,贪婪解码在这种情况下表现得相当好,尽管它被认为是一种有些受限的策略。 这可能归因于对简短答案(最多 64 个新标记)的关注,或者 UniEval 没有准确评估 "多样性" 方面的可能性。

结论

在这篇博客中,我们旨在深入了解评估 LLMs 所涉及的挑战,特别是在使用 RAG 回答问题的背景下。 该领域仍处于早期阶段,有大量关于该主题的论文发表。 虽然 UniEval 不是万能的解决方案,但我们发现它是一种引人注目的方法,可以更准确地评估我们的 RAG 管道的性能。 这标志着 Elastic 正在进行的研究工作迈出了第一步。 一如既往,我们的目标是增强搜索体验,我们相信 UniEval 等解决方案或类似方法将有助于为我们的用户开发有价值的工具。

本文中描述的任何特性或功能的发布和时间安排均由 Elastic 自行决定。 当前不可用的任何特性或功能可能无法按时交付或根本无法交付。

Elastic、Elasticsearch 和相关标志是 Elasticsearch N.V. 在美国和其他国家/地区的商标、徽标或注册商标。 所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。

原文:www.elastic.co/search-labs...

相关推荐
forestsea28 分钟前
【Elasticsearch】分片与副本机制:优化数据存储与查询性能
大数据·elasticsearch·搜索引擎
运维&陈同学39 分钟前
【Beats01】企业级日志分析系统ELK之Metricbeat与Heartbeat 监控
运维·elk·elasticsearch·云原生·kibana·heartbeat·metricbeat
INFINI Labs1 小时前
Elasticsearch filter context 的使用原理
大数据·elasticsearch·jenkins·filter·querycache
chengpei1471 小时前
Elasticsearch介绍及安装部署
elasticsearch·搜索引擎
it噩梦11 小时前
es 中 terms set 使用
大数据·elasticsearch
喝醉酒的小白14 小时前
Elasticsearch 配置文件
大数据·elasticsearch·搜索引擎
missay_nine18 小时前
Elasticsearch
大数据·elasticsearch·搜索引擎
it噩梦19 小时前
深度分析 es multi_match 中most_fields、best_fields、cross_fields区别
java·elasticsearch
喝醉酒的小白20 小时前
ES 集群 A 和 ES 集群 B 数据流通
大数据·elasticsearch·搜索引擎
炭烤玛卡巴卡20 小时前
初学elasticsearch
大数据·学习·elasticsearch·搜索引擎