链载Ai

标题: RAG 系统评测实践详细版:Coze 及相关产品评测对比,以及下一代 RAG 技术 [打印本页]

作者: 链载Ai    时间: 昨天 11:35
标题: RAG 系统评测实践详细版:Coze 及相关产品评测对比,以及下一代 RAG 技术

RAG 系统评测实践详细版:Coze 及相关产品评测对比,以及下一代 RAG 技术

RAG(检索增强生成)是一种 AI 框架,它将传统信息检索系统(例如数据库)的优势与生成式大语言模型 (LLM) 的功能结合在一起,通过将这些额外的知识与自己的语言技能相结合,AI 可以撰写更准确、更具时效性且更贴合您的具体需求的文字。

RAG 通过几个主要步骤来帮助增强生成式 AI 输出:

RAG 的运行方式是:首先使用从数据库中检索相关信息。然后将这种检索到的信息整合到 LLM 的查询输入中,使其能够生成更准确且与上下文更相关的文本。

以下是一个 RAG 的核心架构模式:在检索和生成之前还需要对数据做一些处理和索引的存储。

上次梳理了一些提升 RAG 效果的方法,然后在实际进行优化的过程中,有个比较关键的点,就是你做了这些事情对系统到底有什么影响,带来的收益和变化。为了系统地评估和优化 RAG 系统的性能,有效的评估必不可少:

RAG 评测对于理解系统能力、优化改进方案、保障应用质量至关重要,下面分享一些最近在评测上的一些经验。

  1. 评测概述

上面提到了 RAG 的定义是结合信息检索和大模型生成能力,为了全面评估 RAG 系统的性能,我们需要分别考察其在信息检索和答案生成两个子任务上的表现:

在实际的系统中,检索结果的质量在很大程度上决定了 RAG 系统的整体性能,如果召回的文档与问题无关或信息不足,即使后续的生成模型再强大,也难以产出满意的答案。

如果召回模块能够准确、全面地检索到问题相关的背景知识,生成模型就可以在此基础上进行知识整合和答案生成,最终输出高质量的回复,只有建立在高质量召回的基础之上,RAG 系统才能充分发挥大语言模型的生成能力。

因此,在影响 RAG 系统性能的诸多因素中,召回指标占据了相当大的权重。提升召回阶段的效果,是优化 RAG 系统的关键所在。

  1. 评测相关指标

2.1 检索指标

RAG 依赖于高质量的检索结果来生成准确和信息丰富的响应。通过对 RAG 系统的检索部分进行评测,可以评估其在检索相关文档方面的性能。

一些流行的基本信息检索指标包括,不考虑检索文档顺序的指标:

精确度 @k:精确度评估检索结果中的真实正例。它分析返回的结果中有多少与搜索查询相关。指标后面的 “@k” 描述了在评估期间分析的前 k 个结果。例如,精确度 @5 意味着前五个输出的精确度。

然而,排名指标受到检索结果顺序的影响。一些流行的排名指标包括:

信息检索指标参考【有相关例子解释说明】:

2.1.1 精确率 (Precision) - 查准率

精确率衡量检索结果的准确性,即检索出的相关文档占检索出的所有文档的比例。精确率越高,表示系统返回的结果中相关文档的比例越高。

在给定的上下文中,“Precision (精确率)是模型判定为真且实际为真的比例。

Precision@k  =  TruePositives@  k  TruePositives@  k +  FalsePositives@  k \text {Precision@k}=\frac{\text { TruePositives@ } k}{\text { TruePositives@ } k+\text { FalsePositives@ } k}  Precision@k = TruePositives@ k+ FalsePositives@ k TruePositives@ k

假设:

retrieval_result 必须包含 “test-1 或 test-2” 和 test-3,所有答案才能被视为正确。 因此,如果我们将 retrieval_result 标记为正确答案为 “1”,错误答案为 “0”,则它将是 [1, 0, 1, 0]。

在给定的示例中,检索得到的正确答案为 [1, 0, 1, 0],按照精度的计算公式,即(结果中正确答案的数量)/(结果的长度)

在此例中,正确答案数量为 2,结果长度为 4,所以精度为 2/4 = 0.5 。

在 RAGAS 框架中定义可以看做是上面定义的一点点变体,基于上述的指标做了一个加权平均得到的值,但是本质上还是上面的定义。

2.1.2 召回率 (Recall) - 查全率

召回率衡量检索结果的完整性,即检索出的相关文档占测试集中所有相关文档的比例。召回率越高,表示系统能够找到更多的相关文档。

召回率是模型预测为真的部分在实际为真的部分中所占的百分比。 在统计学中,它被称为敏感度,在其他领域,称为命中率。

context recall  = ∣  GT claims that can be attributed to context  ∣ ∣  Number of claims in GT  ∣ \text {context recall}=\frac{\mid \text { GT claims that can be attributed to context } \mid}{\mid \text { Number of claims in GT } \mid}  context recall =∣ Number of claims in GT ∣∣ GT claims that can be attributed to context ∣

召回率是将人工标注的答案 (ground truth) 作为参考标准,看检索到的上下文能够 “召回” 答案中的多少信息。

2.1.3 F1 分数

精确率和召回率两个指标是对比的,一个有效的 IR 系统必须显示两个指标的合理值。

MRR(Mean Reciprocal Rank)- 平均倒数排名

MRR 关注的是第一个相关结果出现的位置。如果第一个相关结果排在第 n 位,那么 MRR 的值就是 1/n。

MRR 的值越接近 1,表示系统返回的第一个相关结果平均排名越靠前,即系统能够更快地为用户提供所需信息。

平均倒数排名 (MRR) 是一种排名质量指标。它考虑排名列表中第一个相关项目的位置。可以将 MRR 计算为所有用户或查询的倒数排名的平均值。

倒数排名是第一个相关项目的位置的倒数。如果第一个相关项位于位置 2,则倒数排名为 1/2。

MRR 值范围从 0 到 1,其中 “1” 表示第一个相关项目始终位于顶部。

更高的 MRR 意味着更好的系统性能。

M R R = 1 U ∑ u = 1 U 1 rank ⁡ i \mathrm{MRR}=\frac{1}{U} \sum_{u=1}^U \frac{1}{\operatorname{rank}_i} MRR=U1u=1∑Uranki1

参考:https://www.evidentlyai.com/ranking-metrics/mean-reciprocal-rank-mrr

MAP(Mean Average Precision)- 平均精度均值

MAP 以精确度指标为核心。然而,MAP 不是使用单个 k 值,而是对不同 k 值计算的多个精确度值取平均值。

如果 k 设置为 5,MAP@5,精确度将计算 1、2、3、4 和 5 的值,然后平均以给出平均精度(AP)。然而,一个强大的信息检索系统应该适用于各种用户输入。MAP 对多个查询计算 AP,然后取所有值的平均值。最终的 MAP 值更好地代表了系统对不同输入的性能。

计算顺序:Precision → Average Precision → Mean Average Precision

NDCG(Normalized Discounted Cumulative Gain)- 归一化折扣累积增益

NDCG 是一种评估搜索结果排序质量的指标。它考虑了结果的相关性和位置两个因素,综合衡量了搜索引擎返回结果的好坏。NDCG 的取值范围在 0 到 1 之间,值越接近 1,表示搜索结果的排序质量越高。

用简单的语言为你解释 NDCG(Normalized Discounted Cumulative Gain):

从前,有一个叫小明的男孩,他特别喜欢吃糖果。小明有很多不同口味的糖果,有的他非常喜欢,有的他觉得一般,还有一些他不太喜欢。有一天,小明的朋友小红来找他玩。小明想把自己的糖果分享给小红,但他希望把最好吃的糖果先给小红。于是,小明按照自己的喜好,把糖果排成一列,最喜欢的放在最前面。小明的糖果盒就像一个搜索引擎,而每一颗糖果就像搜索结果。糖果的排列顺序反映了搜索结果的相关性和重要性。NDCG 就是用来衡量这个 “糖果盒” 的好坏的一种方法。

NDCG 的计算分为几个步骤:

  1. 首先,我们要给每颗糖果打分,分数越高表示糖果越好吃。这就像给搜索结果评分一样。

  2. 然后,我们把分数按照糖果的位置进行 “折扣”。离盒子开口越远的糖果,它的分数就要打折扣。这是因为排在后面的结果,用户不太可能看到或选择。

  3. 接下来,我们把所有糖果的 “折扣分数” 加起来,得到一个总分。这个总分反映了整个糖果盒的好坏。

  4. 最后,为了便于比较不同的糖果盒,我们还要对总分进行 “归一化” 处理。我们把实际的总分除以最理想情况下的总分 (即所有最好吃的糖果都排在前面)。这样,NDCG 的取值就在 0 到 1 之间了。

举个例子,假设小明有 5 颗糖果,他给每颗糖果打分如下:

如果糖果的排列顺序是 [5, 4, 3, 2, 1],那么 NDCG 的计算过程如下:

  1. 折扣后的分数为: 5 + 4/log(3) + 3/log(4) + 2/log(5) + 1/log(6) ≈ 9.86

  2. 最理想情况下的折扣分数为: 5 + 4/log(3) + 3/log(4) + 2/log(5) + 1/log(6) ≈ 9.86

  3. DCG = 9.86 / 9.86 = 1

这个结果表明,小明的糖果盒是最理想的排列,因为 NDCG 达到了最大值 1。

5 + 4/log(3) + 3/log(4) + 2/log(5) + 1/log(6)

这里的每一项对应着一个搜索结果的折扣分数:

将所有结果的折扣分数相加,就得到了整个结果列表的折扣累积增益 (DCG)。

NDCG 的值越接近 1,表示搜索结果的排序质量越高,越能满足用户的需求。NDCG 综合考虑了结果的相关性和位置因素,是评估搜索引擎、推荐系统等排序算法的重要指标。

2.2 生成指标

忠实度 (Faithfulness)

Faithfulness score  = ∣  Number of claims in the generated answer that can be inferred from given context  ∣ ∣  Total number of claims in the generated answer  ∣ \text {Faithfulness score}=\frac{\mid \text { Number of claims in the generated answer that can be inferred from given context } \mid}{\mid \text { Total number of claims in the generated answer } \mid}  Faithfulness score =∣ Total number of claims in the generated answer ∣∣ Number of claims in the generated answer that can be inferred from given context ∣

假设模型生成了以下答案:“爱因斯坦出生于德国。他于 1879 年 3 月 14 日出生。”

计算忠实度的步骤:

第 1 步: 将生成的答案分解为单独的陈述。

第 2 步: 对于每个生成的陈述,验证是否可以从给定的上下文中推断出它。

第 3 步:使用公式计算忠实度。 忠实度 = (忠实陈述的数量) / (总陈述数量)

在这个例子中,忠实度 = 1 / 2 = 0.5 或 50%

因此,模型生成的答案的忠实度为 50%,因为只有一半的陈述可以从给定的上下文中推断出来。

正确性 (Correctness)

答案正确性包含两个关键方面:生成的答案与基本事实之间的语义相似性,以及事实相似性。使用加权方案将这些方面结合起来以制定答案正确性分数。如果需要,用户还可以选择使用 “阈值” 将结果分数四舍五入为二进制。

检索的 F1 综合考虑了准确率和召回率,衡量检索结果与真实相关文档集合的重叠程度。

正确性评估中的 F1 只用于计算事实正确性,然后再与语义相似度结合。重点是答案内容本身与参考答案的接近程度,而不是从一个集合中筛选相关项。

基于 N-gram 的指标

N-gram 是一种将文本数据划分为连续词语片段的方法。其中,“N” 表示片段中包含的单词数量。以下是几种常见的 N-gram 类型:

  1. Unigram(1-gram): 将文本划分为单个单词。例如,“I love natural language processing” 划分为 “I”,“love”,“natural”,“language”,“processing”。

  2. Bigram(2-gram): 将文本划分为连续的单词对。例如,“I love natural language processing” 划分为 “I love”,“love natural”,“natural language”,“language processing”。

  3. Trigram(3-gram): 将文本划分为连续的三个单词组合。例如,“I love natural language processing” 划分为 “I love natural”,“love natural language”,“natural language processing”。

N-gram 可以扩展到任意数量的连续单词,但通常使用 Unigram 到 5-gram。N-gram 通过考虑单词的局部上下文信息,捕捉文本的局部语义和语法特征。

N-gram 的指标有一些局限性:语义理解能力有限、只考虑局部的词语组合,难以处理长距离的语法和语义依赖,忽略了生成文本的整体一致性。适用于一些快速评估翻译或摘要的流畅性、辅助训练过程中的模型选择等。

在大模型的应用中,更多采用基于词向量、语义相似度的指标,如 BERTScore、Moverscore 等。这些指标利用预训练语言模型的词向量表示,捕捉语义层面的相似性,更适合评估大模型生成的文本质量。

基于传统模型的指标

基于 LLM 的指标

这些指标从不同角度评估自然语言生成系统和对话系统的性能,包括流畅性、准确性、相关性、安全性、事实准确性等方面。在实际应用中,可以根据任务需求选取适当的指标组合,全面评估系统的性能表现。同时,这些指标的计算方法也在不断改进,未来会有更多新的评估指标出现。

  1. 评测的数据集构建

建立优秀的 RAG 系统需要建立优秀的 RAG 评估数据集,一个真实而精确的数据集,即使只有一百个问题,也可以在优化 RAG 性能方面产生重大影响。

3.1 开源数据集

目前大多数开源数据集主要以英文为主,缺少一些中文场景的评估,还有使用开源数据集时,要对数据格式进行一定的转换和处理,以适应我们的评测流程。许多开源数据集的规模较大,而我们实际评测时可能并不需要如此大量的数据。因此,我们通常需要从中筛选出一部分与我们的应用场景相符的数据子集。

总的来说,现有的开源数据集在格式和语言方面与我们的评测需求存在一定的差距,当然做一些基本的评估也是可以的,最后找到了一个名为 CRUD_RAG 的中文数据集,该数据集主要由 GPT-4 生成的问题和答案构成,与真实用户的问答数据可能存在一定的区别。

CRUD_RAG

一个中文的 RAG 评估数据集:

数据集主要是通过 GPT 生成的:

研究人员构建了单文档和多文档问答任务的数据集。对于单文档问答,他们使用 GPT-4 生成问题和答案。对于多文档问答,他们采用了链条思维(Chain-of-Thought)技术,通过 GPT-4 生成跨多篇文章的推理问题。

MS MARCO

Microsoft Machine Reading Comprehension (MS MARCO) 是一个大规模的问答数据集,广泛用于 RAG 系统的评测,它包含了大量的真实用户查询和相应的文档。MS MARCO 的特点包括:

MS MARCO 被广泛用于评测 RAG 系统在大规模数据集上的性能,是 RAG 研究中的重要基准数据集之一。

地址:

Natural Questions

Natural Questions (NQ) 是由 Google 发布的一个问答数据集,旨在评测系统在处理自然语言问题方面的能力。NQ 的特点包括:

NQ 数据集对评测 RAG 系统在处理自然语言问题方面的性能非常有帮助,是 RAG 评测中常用的数据集之一。

数据集地址:https://ai.google.com/research/NaturalQuestions/download

TriviaQA

TriviaQA 是一个基于琐事问答的数据集,用于评测 RAG 系统在回答常识性问题方面的能力。TriviaQA 的特点包括:

TriviaQA 对评测 RAG 系统在回答常识性问题方面的性能非常有帮助,是 RAG 评测中的另一个重要数据集。

官网地址:https://nlp.cs.washington.edu/triviaqa/
数据集地址:https://huggingface.co/datasets/mandarjoshi/trivia_qa/viewer/rc/train

3.2 大模型生成数据集

LLM 生成的问题可能缺乏真实世界的语境和复杂性,评估的结果也缺乏一定的说服力,不过使用大模型生成的问答对,可以快速的把系统流程走通。

在生成评估数据集时,主要有两种方式,每种方式都有其特点和缺点:

使用 RAGAS 框架生成

里面我自定义了 Apaas 的嵌入模型和生成模型,实际使用时可以直接使用 LangChain 内置的模型就可以。

from langchain_community.document_loaders import TextLoader

from ragas import RunConfig

from ragas.testset import TestsetGenerator

from ragas.testset.evolutions import simple, reasoning, multi_context

from eval.apaasembedding import ApaasEmbeddings

from eval.apaasllm import ApaasLLM

def generate_testset(documents, test_size, distributions):

"""

生成测试数据集

Args:

documents: 文档列表

test_size: 测试集大小

distributions: 测试集分布

Returns:

生成的测试数据集

"""

generator_llm = ApaasLLM()

critic_llm = ApaasLLM()

embeddings = ApaasEmbeddings()

generator = TestsetGenerator.from_langchain(

generator_llm,

critic_llm,

embeddings,

run_config=RunConfig(

timeout=6000,

max_retries=5,

max_wait=6000,

max_workers=3,

thread_timeout=6000,

log_tenacity=True

),

)

return generator.generate_with_langchain_docs(

documents,

test_size=test_size,

distributions=distributions

)

def save_testset_to_json(testset, output_file):

"""

将测试数据集保存为JSON文件

Args:

testset: 测试数据集

output_file: 输出文件路径

"""

testset_df = testset.to_pandas()

testset_df.to_json(output_file, orient='records', indent=4, force_ascii=False)

def main():

#加载文档

loader = TextLoader("/Users/aihe/PycharmProjects/rag_eval_2/eval/crdu/crud_3_200.txt")

documents = loader.load()

#打印文档内容

for document in documents:

print(document)

#生成测试数据集

testset = generate_testset(

documents,

test_size=10,

distributions={simple: 0.5, reasoning: 0.25, multi_context: 0.25}

)

#将测试数据集保存到JSON文件

output_file = "testset.json"

save_testset_to_json(testset, output_file)

if __name__ == "__main__":

main()


耗时比较久,而且感觉生成的问题和答案也不是那么理想。

使用大模型产品生成

根据用户上传的文档,按以下要求构建5个问答对:

##要求

1. 深入理解文档内容,提取关键信息,构建高质量的问答对。保持文档原有的风格、格式、情感和语气。

2. 问题类型要多样化,包括但不限于:

- 简单的事实问答

- 需要推理、分析和综合多段内容才能回答的复杂问题

- 需要在整篇文档范围内找出答案的开放式问题

- 涉及上下文理解的多轮对话式问题

3. 答案要准确、简洁,直接摘取原文相关内容,避免臆测或编造。如文中没有足够信息回答,可以回答"根据文中内容无法确定"。

4. 以JSON格式输出,每个问答对包含question和answer两个字段。

##流程

1. 仔细阅读文档,把握整体脉络,标记关键信息点

2. 围绕关键信息,设计多样化的问题,兼顾覆盖面和难度梯度

3. 在文档中找出相关段落,提炼出简洁准确的答案

4. 以JSON格式整理问答对,进行自查和修改

5. 输出5个问答对的JSON

##回答格式

[

{

"questions": "",

"answers": ""

}

]


3.3 真实场景的数据集

构建真实用户问题的 RAG 评估数据集是更好的选择,当然也是需要投入人力相对较多的地方,同时也要考虑多个因素:

真实的评测数据集更能考察出系统的效果,但是需要持续的投入,但是对于系统的评估效果则是最好。

  1. 产品评测与分析

4.1 不同产品的评测与分析

在经过上述的准备之后,计划对当前的系统进行评估,同时也会关注相关同类产品的效果,了解当下一些同类产品的表现。

评估指标:精确率、召回率、F1 分数; 以及文件处理耗时;

评估数据集:每个数据集有 10 个问题。

脚本的主要执行过程:

  1. 根据传入的数据集,找到对应的 QA 文件;

  2. 清空对应产品的知识库文件,上传数据集的内容,让对应产品进行索引;

  3. 遍历 QA 文件的问题,调用不同的产品接口,获取召回的 context,如果有答案也一并保存下来;

  4. 把 QA + 召回的 Context 组合成新的文件保存下来;

  5. 调用 RAGAS 的接口对新的数据集进行评估;

QA 文件格式:

构建 QA + Context 的格式;

分析:

4.2 平台内部不同组件的评测效果

这张图列出了可用于评估 RAG 系统的不同任务以及会影响 RAG 表现的各个组件节点。

但是因为这里只考察 RAG 的检索效率,即 Read 能力,可以看下不同的组件对检索效果的影响。

做几个小实验:

合适的 Chunk 配合扩大窗口

不同 Chunksize 配合 topK 对召回效果的影响,假设模型容纳 3000 个字符的情况下,那么分几组参数:这里参考了 CRUD 论文提到的测试方法,这样的话最终对下游大模型输入的 Token 是不变的,看如何找到最优的组合参数。

扩大窗口会对重复的 chunk 进行去重,扩大的是上下窗口,字数更多了,信息也更多一些;

Rerank 对召回效果的影响

在 RAG 系统中,Rerank 模型主要用于以下几个场景:

  1. 提高回答的相关性:在信息检索阶段,RAG 系统会从大量候选文档中检索出与问题相关的文档。rerank 模型的作用是对这些候选文档进行排序,确保最相关的文档排在前面,从而提高生成回答的相关性。

  2. 优化文档选择:RAG 系统可能会检索出多个相关的文档,但并不是所有文档的内容都适合用来生成回答。rerank 模型可以帮助筛选出最适合生成回答的文档或段落。

  3. 减少噪声:检索到的文档可能包含一些与问题不相关或者重复的信息,rerank 模型可以识别并降低这些噪声,提高生成回答的准确性。

评测的结论:

分析:OpenSearch 在进行向量召回时已经完成了一轮排序(RANK),那么单路召回的情况下 ReRank 和向量召回基本上没太多差异。一般 Rerank 在多路召回场景下会更有效果,这个是召回的文档中可能包含大量噪声信息。Rerank 作为最后一道把关,预计可以提升效果。多路召回肯定是要增加的,后面再看看多路召回之后结合 ReRank 的效果。

关于 Embeding 模型的影响

原计划对比几款主流的 embedding 模型,但发现它们的向量维度不同:

鉴于技术上的限制,就拿市面上的 embedding 模型评测报告。也能反映出不同 Embeding 模型对于检索召回的效果影响:

BGE-M3 的性能最好,其次是 ML-E5-Large、E5-mistral-7b 和 Nomic-Embed。BGE-M3 模型尚未在 MTEB 排行榜上进行基准测试,我们的结果表明它可能比其他模型排名更高。值得注意的是,虽然 BGE-M3 针对多语言数据进行了优化,但它在英语方面的表现也比其他模型更好。

  1. 五、关于下一代的 RAG

最近听了 AICON 大会的 RAG 相关的分享,一个讲技术细节的下一代 RAG 引擎的挑战,另外一个则是 RAG 应用在客服的具体场景;听下来的感受。

把 RAG 做好关键的两点:离线数据处理和在线检索

做好了上面的两点,基本上就是工业级可用的水平;另外在实际场景中再兼顾效率的话会训练各种不同的小模型,应对业务中的场景。

上面的 RAG 在市面上已经比较成熟了,再接下来继续发展的 RAG 形态还可以做什么?

从技术上看,RAG 还可以继续做不少的探索,对这方面感兴趣的同学,希望分享更多相关的经验,一块学习进步下~

  1. 总结

这次讲了许多 RAG 评测的细节,最后再回顾下文章的大概内容:

  1. RAG 系统评测看两个点:

  • 针对召回和生成介绍了一些常见的指标和定义,如准确率、召回率、F1 值等。也有很多框架提供了对应的计算方式,对 RAG 系统来说,RAGAS 还是不错的选择。

  • 评测数据集的获取方式:最有效的方式是获取自己业务的真实数据,构造数据集。

  • * 开源数据集:利用已有的公开数据集进行评测,中文数据集比较少,可以试下 CRUD。

    * 大模型生成数据集:使用大模型生成合成数据集用于评测。

    * 业务场景积累真实数据:最有效的方式,通过实际业务场景积累高质量的真实数据。

    1. 对一些相似的产品,和自身产品内部做了一些评测。

    2. RAG 系统的未来探索方向:AgentRAG、知识图谱、多模态、NL2SQL 算一个需要建设的能力。

    更多优质内容请关注公号:汀丶人工智能;会提供一些相关的资源和优质文章,免费获取阅读。







    欢迎光临 链载Ai (https://www.lianzai.com/) Powered by Discuz! X3.5