RAG 系统评测实践详细版：Coze 及相关产品评测对比，以及下一代 RAG 技术
RAG（检索增强生成）是一种 AI 框架，它将传统信息检索系统（例如数据库）的优势与生成式大语言模型 (LLM) 的功能结合在一起，通过将这些额外的知识与自己的语言技能相结合，AI 可以撰写更准确、更具时效性且更贴合您的具体需求的文字。
RAG 通过几个主要步骤来帮助增强生成式 AI 输出：
检索和预处理：RAG 利用强大的搜索算法查询外部数据，例如网页、知识库和数据库。检索完毕后，相关信息会进行预处理，包括标记化、词干提取和停用词移除。生成：经过预处理的检索到的信息接着会无缝整合到预训练的 LLM 中。此整合增强了 LLM 的上下文，使其能够更全面地理解主题。这种增强的上下文使 LLM 能够生成更精确、更翔实且更具吸引力的回答。
RAG 的运行方式是：首先使用从数据库中检索相关信息。然后将这种检索到的信息整合到 LLM 的查询输入中，使其能够生成更准确且与上下文更相关的文本。
以下是一个 RAG 的核心架构模式：在检索和生成之前还需要对数据做一些处理和索引的存储。
上次梳理了一些提升 RAG 效果的方法，然后在实际进行优化的过程中，有个比较关键的点，就是你做了这些事情对系统到底有什么影响，带来的收益和变化。为了系统地评估和优化 RAG 系统的性能，有效的评估必不可少：
客观衡量系统性能：了解系统优势和不足，明确优化方向
发现并定位问题：空召回、答案冗余、检索的相关性不足等
RAG 评测对于理解系统能力、优化改进方案、保障应用质量至关重要，下面分享一些最近在评测上的一些经验。
评测概述
上面提到了 RAG 的定义是结合信息检索和大模型生成能力，为了全面评估 RAG 系统的性能，我们需要分别考察其在信息检索和答案生成两个子任务上的表现:
评测信息检索能力： 借鉴传统 IR(Information Retrieval) 系统的评估方法和指标，如平均倒数排序 (MRR)、精确率 (Precision)、召回率 (Recall) 等。
大模型生成能力： 主要依赖于语言模型本身的性能，看答案的流畅度、连贯性、准确性等方面，可以采用人工评分、BLEU 等自动化指标，以及问答准确率等任务相关指标。
在实际的系统中，检索结果的质量在很大程度上决定了 RAG 系统的整体性能，如果召回的文档与问题无关或信息不足，即使后续的生成模型再强大，也难以产出满意的答案。
如果召回模块能够准确、全面地检索到问题相关的背景知识，生成模型就可以在此基础上进行知识整合和答案生成，最终输出高质量的回复，只有建立在高质量召回的基础之上，RAG 系统才能充分发挥大语言模型的生成能力。
因此，在影响 RAG 系统性能的诸多因素中，召回指标占据了相当大的权重。提升召回阶段的效果，是优化 RAG 系统的关键所在。
评测相关指标
2.1 检索指标
RAG 依赖于高质量的检索结果来生成准确和信息丰富的响应。通过对 RAG 系统的检索部分进行评测，可以评估其在检索相关文档方面的性能。
一些流行的基本信息检索指标包括，不考虑检索文档顺序的指标：
精确度 @k：精确度评估检索结果中的真实正例。它分析返回的结果中有多少与搜索查询相关。指标后面的 “@k” 描述了在评估期间分析的前 k 个结果。例如，精确度 @5 意味着前五个输出的精确度。
召回率 @k：召回率通过分析返回的结果与数据库中所有相关项目的数量来评估 IR 系统。由于 k 值的影响很大，如果 k 等于整个数据集，召回率将是 1。必须根据应用要求设置 k 值。
F1 分数 @k：F1 是精确度和召回率之间的调和平均值。它提供了两个指标之间的平衡，并在上述两个评估都相关时使用。
然而，排名指标受到检索结果顺序的影响。一些流行的排名指标包括：
平均精度均值（MAP）：MAP 有两个部分。首先，它计算单个查询的多个 k 值（从 1 到 N）的平均精度。第二部分取所有可能查询的平均精度的平均值。
归一化折扣累积增益（NDCG）：NDCG 考虑与数据库中每个元素相关联的两个排名。第一个排名是用户分配的，并且根据与用户查询相关的元素的值而具有更高的值。IR 系统提供了第二个排名。NDCG 比较真实情况和系统生成的排名进行评估。
信息检索指标参考【有相关例子解释说明】：
https://zilliz.com.cn/blog/information-retrieval-metrics https://edai.notion.site/Retrieval-Metrics-dde3d9fa1d9547cdb8b31b94060d21e7
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 gt =
[['test-1'， 'test-2']， ['test-3']]实际的召回结果：retrieval result =
['test-1'， 'pred-1'， 'test-2'， 'pred-3']
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
U 是评估数据集中的用户总数（在推荐情况下）或查询总数（在信息检索情况下）。在 RAG 系统中指的是查询总数
排名 i 是用户 u 的第一个相关项目在前 K 个结果中的位置。
参考：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 的计算分为几个步骤:
首先，我们要给每颗糖果打分，分数越高表示糖果越好吃。这就像给搜索结果评分一样。
然后，我们把分数按照糖果的位置进行 “折扣”。离盒子开口越远的糖果，它的分数就要打折扣。这是因为排在后面的结果，用户不太可能看到或选择。
接下来，我们把所有糖果的 “折扣分数” 加起来，得到一个总分。这个总分反映了整个糖果盒的好坏。
最后，为了便于比较不同的糖果盒，我们还要对总分进行 “归一化” 处理。我们把实际的总分除以最理想情况下的总分 (即所有最好吃的糖果都排在前面)。这样，NDCG 的取值就在 0 到 1 之间了。
举个例子，假设小明有 5 颗糖果，他给每颗糖果打分如下:
如果糖果的排列顺序是 [5， 4， 3， 2， 1]，那么 NDCG 的计算过程如下:
折扣后的分数为: 5 + 4/log(3) + 3/log(4) + 2/log(5) + 1/log(6) ≈ 9.86
最理想情况下的折扣分数为: 5 + 4/log(3) + 3/log(4) + 2/log(5) + 1/log(6) ≈ 9.86
DCG = 9.86 / 9.86 = 1
这个结果表明，小明的糖果盒是最理想的排列，因为 NDCG 达到了最大值 1。
5 + 4/log(3) + 3/log(4) + 2/log(5) + 1/log(6)
这里的每一项对应着一个搜索结果的折扣分数:
第 1 个结果的原始分数是 5，它的位置是 0，所以它的折扣因子是 1/log(0+1)=1，折扣分数为 5×1=5。
第 2 个结果的原始分数是 4，它的位置是 1，所以它的折扣因子是 1/log(1+1)=1/log(2)，折扣分数为 4/log(2)。
第 3 个结果的原始分数是 3，它的位置是 2，所以它的折扣因子是 1/log(2+1)=1/log(3)，折扣分数为 3/log(3)。
第 4 个结果的原始分数是 2，它的位置是 3，所以它的折扣因子是 1/log(3+1)=1/log(4)，折扣分数为 2/log(4)。
第 5 个结果的原始分数是 1，它的位置是 4，所以它的折扣因子是 1/log(4+1)=1/log(5)，折扣分数为 1/log(5)。
将所有结果的折扣分数相加，就得到了整个结果列表的折扣累积增益 (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 步: 将生成的答案分解为单独的陈述。
陈述 1:“爱因斯坦出生于德国。” 陈述 2:“他于 1879 年 3 月 14 日出生。”
第 2 步: 对于每个生成的陈述，验证是否可以从给定的上下文中推断出它。
陈述 1: 可以从上下文中推断出，因为上下文明确提到 “他出生于德国”。因此，陈述 1 是忠实的。
陈述 2: 无法从上下文中推断出，因为上下文没有提到爱因斯坦的具体出生日期。因此，陈述 2 是不忠实的。
第 3 步：使用公式计算忠实度。 忠实度 = (忠实陈述的数量) / (总陈述数量)
在这个例子中，忠实度 = 1 / 2 = 0.5 或 50%
因此，模型生成的答案的忠实度为 50%，因为只有一半的陈述可以从给定的上下文中推断出来。
正确性 (Correctness)
答案正确性包含两个关键方面：生成的答案与基本事实之间的语义相似性，以及事实相似性。使用加权方案将这些方面结合起来以制定答案正确性分数。如果需要，用户还可以选择使用 “阈值” 将结果分数四舍五入为二进制。
正确性评估生成答案相对于参考答案 (ground truth) 的准确程度。分数在 0 到 1 之间，分数越高表示生成答案与参考答案越接近，正确性越高。
忠实度衡量生成答案中的信息是否能够被原始上下文所支持。分数在 0 到 1 之间，分数越高表示答案中的信息在原文中找到支持证据的比例越大，忠实度越高。
检索的 F1 综合考虑了准确率和召回率，衡量检索结果与真实相关文档集合的重叠程度。
正确性评估中的 F1 只用于计算事实正确性，然后再与语义相似度结合。重点是答案内容本身与参考答案的接近程度，而不是从一个集合中筛选相关项。
基于 N-gram 的指标
N-gram 是一种将文本数据划分为连续词语片段的方法。其中，“N” 表示片段中包含的单词数量。以下是几种常见的 N-gram 类型:
Unigram(1-gram): 将文本划分为单个单词。例如，“I love natural language processing” 划分为 “I”，“love”，“natural”，“language”，“processing”。
Bigram(2-gram): 将文本划分为连续的单词对。例如，“I love natural language processing” 划分为 “I love”，“love natural”，“natural language”，“language processing”。
Trigram(3-gram): 将文本划分为连续的三个单词组合。例如，“I love natural language processing” 划分为 “I love natural”，“love natural language”，“natural language processing”。
N-gram 可以扩展到任意数量的连续单词，但通常使用 Unigram 到 5-gram。N-gram 通过考虑单词的局部上下文信息，捕捉文本的局部语义和语法特征。
BLEU(Bilingual Evaluation Understudy)：计算机器翻译和文本生成结果与参考答案之间的 n-gram 重叠度，用于评估生成文本的流畅性和准确性。
ROUGE(Recall-Oriented Understudy for Gisting Evaluation)：通过比较生成文本与参考答案的 n-gram 重叠情况，评估自动摘要系统的性能。
METEOR：结合了精确率和召回率，同时考虑了同义词匹配，对机器翻译和文本生成质量进行评估。
N-gram 的指标有一些局限性：语义理解能力有限、只考虑局部的词语组合，难以处理长距离的语法和语义依赖，忽略了生成文本的整体一致性。适用于一些快速评估翻译或摘要的流畅性、辅助训练过程中的模型选择等。
在大模型的应用中，更多采用基于词向量、语义相似度的指标，如 BERTScore、Moverscore 等。这些指标利用预训练语言模型的词向量表示，捕捉语义层面的相似性，更适合评估大模型生成的文本质量。
基于传统模型的指标
BERTScore：基于预训练语言模型 BERT 计算生成文本与参考答案的相似度，捕捉语义层面的相似性。需要有对应的标准答案，判断生成答案和标准答案的相似度；
BARTScore：利用预训练的序列到序列模型 BART 对生成文本的质量进行无监督评估。BART 是通过大量阅读和写作训练而成的，它学会了什么样的文章是好的，什么样的文章是不够好的。BART，在没有参考答案的情况下，对文章的写作质量进行自动评估。
基于 LLM 的指标
G-Eval、UniEval：基于指令微调的语言模型，对生成文本的相关性、连贯性等方面进行评分。
GPTScore、TRUE：利用 GPT 等生成式预训练模型，通过无监督方式评估生成文本的质量。
SelfCheckGPT：生成文本后，使用语言模型检查其事实准确性，提高生成内容的可靠性。
ChatProtect：专门用于评估对话系统生成回复的安全性，防止产生不恰当或有害的内容。
Chainpoll：通过人工评分的方式，综合评估对话系统的多轮交互质量。
这些指标从不同角度评估自然语言生成系统和对话系统的性能，包括流畅性、准确性、相关性、安全性、事实准确性等方面。在实际应用中，可以根据任务需求选取适当的指标组合，全面评估系统的性能表现。同时，这些指标的计算方法也在不断改进，未来会有更多新的评估指标出现。
评测的数据集构建
建立优秀的 RAG 系统需要建立优秀的 RAG 评估数据集，一个真实而精确的数据集，即使只有一百个问题，也可以在优化 RAG 性能方面产生重大影响。
不同数据集上的 RAG 性能可能存在差异。
构建真实用户问题的 RAG 评估数据集是更好的选择。
不要依赖 LLM 来生成 “自然和真实” 的问题。LLM 生成的问题可能缺乏真实世界的语境和复杂性。
构建 100 个问题的 RAG 评估数据集就足够了。
错误的参考答案或不准确的检索结果会对评估结果产生不良影响
3.1 开源数据集
目前大多数开源数据集主要以英文为主，缺少一些中文场景的评估，还有使用开源数据集时，要对数据格式进行一定的转换和处理，以适应我们的评测流程。许多开源数据集的规模较大，而我们实际评测时可能并不需要如此大量的数据。因此，我们通常需要从中筛选出一部分与我们的应用场景相符的数据子集。
总的来说，现有的开源数据集在格式和语言方面与我们的评测需求存在一定的差距，当然做一些基本的评估也是可以的，最后找到了一个名为 CRUD_RAG 的中文数据集，该数据集主要由 GPT-4 生成的问题和答案构成，与真实用户的问答数据可能存在一定的区别。
CRUD_RAG
一个中文的 RAG 评估数据集：
全面支持中文 RAG Benchmark 评测，包括原生的中文数据集、评测任务、主流基座测试；
覆盖 CRUD(增删改查)，即大模型信息新增能力、信息缩减能力、信息校正能力、信息查询问答能力全方位评测；
总测试数据量达到 36166 个，为中文 RAG 测试最多；
多个指标类型覆盖，包括 ROUGE， BLEU， bertScore， RAGQuestEval，一键评估；
数据集主要是通过 GPT 生成的：
研究人员构建了单文档和多文档问答任务的数据集。对于单文档问答，他们使用 GPT-4 生成问题和答案。对于多文档问答，他们采用了链条思维（Chain-of-Thought）技术，通过 GPT-4 生成跨多篇文章的推理问题。
详细的论文介绍：https://arxiv.org/pdf/2401.17043
MS MARCO
Microsoft Machine Reading Comprehension (MS MARCO) 是一个大规模的问答数据集，广泛用于 RAG 系统的评测，它包含了大量的真实用户查询和相应的文档。MS MARCO 的特点包括：
超过 100 万个查询和 800 万个文档，规模庞大。 查询来自于真实的搜索引擎日志，反映用户的实际信息需求。 文档来源于 Web 页面，涵盖各种主题和领域。 手动标注的查询 - 文档相关性判断，质量较高。
MS MARCO 被广泛用于评测 RAG 系统在大规模数据集上的性能，是 RAG 研究中的重要基准数据集之一。
地址：
官网地址：https://microsoft.github.io/msmarco/ 数据集地址：https://huggingface.co/datasets/microsoft/ms_marco/viewer/v2.1?row=0
Natural Questions
Natural Questions (NQ) 是由 Google 发布的一个问答数据集，旨在评测系统在处理自然语言问题方面的能力。NQ 的特点包括：
包含超过 30 万个真实用户的问题，以及来自 Wikipedia 的相关文档。
问题来自于 Google 搜索引擎日志，反映了用户的真实信息需求。
涵盖各种类型的问题，如事实类问题、定义类问题等。
NQ 数据集对评测 RAG 系统在处理自然语言问题方面的性能非常有帮助，是 RAG 评测中常用的数据集之一。
数据集地址：https://ai.google.com/research/NaturalQuestions/download
TriviaQA
TriviaQA 是一个基于琐事问答的数据集，用于评测 RAG 系统在回答常识性问题方面的能力。TriviaQA 的特点包括：
包含超过 95，000 个问题，以及相应的支持性证据文档。
问题来自于在线琐事问答网站，涵盖各种主题，如历史、科学、娱乐等。
证据文档来自于 Web 页面和 Wikipedia，提供了回答问题所需的信息。
TriviaQA 对评测 RAG 系统在回答常识性问题方面的性能非常有帮助，是 RAG 评测中的另一个重要数据集。
官网地址：https://nlp.cs.washington.edu/triviaqa/
数据集地址：https://huggingface.co/datasets/mandarjoshi/trivia_qa/viewer/rc/train
3.2 大模型生成数据集
LLM 生成的问题可能缺乏真实世界的语境和复杂性，评估的结果也缺乏一定的说服力，不过使用大模型生成的问答对，可以快速的把系统流程走通。
在生成评估数据集时，主要有两种方式，每种方式都有其特点和缺点：
使用 RAGAS 框架生成数据集：RAGAS 框架提供了一套标准化的流程和工具，用于生成评估数据集。支持自定义配置，如测试集大小、问题分布等，可以根据需求进行调整。
缺点：生成数据集的过程比较耗费 TOKEN 和时间，生成的问题质量和多样性可能不够理想，与真实用户提出的问题相比，可能缺乏语境和复杂性。 直接使用大模型的后台，上传文件，写提示词让大模型根据上传的文档生成对应的问题，生成过程相对简单，不需要搭建复杂的框架和环境。可以通过调整提示词来控制生成问题的风格、难度和侧重点。
缺点：模型生成的问题可能存在与真实用户提问风格不一致的问题，依赖于提示词的设计，需要进行多次迭代和调整。
使用 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 评估数据集是更好的选择，当然也是需要投入人力相对较多的地方，同时也要考虑多个因素：
系统的数据埋点：清洗、过滤；也可以找一些关联我业务，客服、小蜜等清洗相关的评估数据，最后进行人工标注。 日志埋点 -> ODPS -> 清洗 -> 标注
兼顾不同类型、不同难度的问答样本的分布，简单问题、复杂问题、推理问题等不同类型。简单的文本文件、复杂的 PDF 文件 (图表、表格、图片)、结构化的数据等。
真实的评测数据集更能考察出系统的效果，但是需要持续的投入，但是对于系统的评估效果则是最好。
产品评测与分析
4.1 不同产品的评测与分析
在经过上述的准备之后，计划对当前的系统进行评估，同时也会关注相关同类产品的效果，了解当下一些同类产品的表现。
在 RAG 系统的评测中，由于生成能力涉及诸多因素，如提示词、模型等，差异较大，缺乏统一的参考对照；相比之下，召回结果更加确定，并且可以肯定的是，召回质量越高，整体效果也就越好。本次评测的重点各产品的召回能力，即上传文件后，系统能否有效地召回相关内容。
目前只有部分产品提供了完备的接口，能够满足我们的评测需求 (可以上传文件、检索文件内容)，市面上的大模型输入是用户 query，输出是模型的答案。 召回的内容并没有展示；
最后筛选下来就是关注了集团一个内部同类产品、Coze 以及自己开发的 RAG 系统的性能表现。阿里云百炼接口有点复杂只能手动验证了。
评估指标：精确率、召回率、F1 分数； 以及文件处理耗时；
评估数据集：每个数据集有 10 个问题。
脚本的主要执行过程：
根据传入的数据集，找到对应的 QA 文件；
清空对应产品的知识库文件，上传数据集的内容，让对应产品进行索引；
遍历 QA 文件的问题，调用不同的产品接口，获取召回的 context，如果有答案也一并保存下来；
把 QA + 召回的 Context 组合成新的文件保存下来；
调用 RAGAS 的接口对新的数据集进行评估；
QA 文件格式：
构建 QA + Context 的格式；
excel 数据集，coze 不支持 API 配置，通过后台操场查看 update 时间减去 createtime 计算的
标准数据集大家表现都不错：在开源的 CRUD 数据集上，AIDC 的 RAG 系统表现最高，但是大家整体表现都比较好； 常规的 txt 文件，一般来说效果不好特别差。
复杂的 PDF 文件，Coze 的表现是最差的：Coze 在解析 PDF 时，将图片链接等干扰性信息错误地混入了文本片段 (Chunk) 中，只放入了链接但是并没有真正的理解图片和表格的内容，这些不相关的信息对问答任务产生了负面影响，导致召回率降低。
结构化 Excel 文件，Coze 的表现是最好的，Coze 系统有关键词召回和 SQL 召回能力；
Idealab 文件处理耗时比较久：针对研究报告、或者 PDF、Excel 等，Idealab 处理效率耗时最久，6~10 分钟。
Coze 对各种数据集处理效率都比较快：对于开源数据集改成 TXT 格式，Coze 处理的效率最快；一般都在 1 分钟多点都能处理完。
AIDCRAG 普通文本处理效率可以接受，Excel 的还需要优化下：AIDCRAG 处理耗时一个看里面文字的长度，另外看文件的格式。TXT 长文字的，Embeding 过程当前有限流会慢一点，Excel 一条条处理也很慢，行数增加耗时也会增加，但是对于标准研究报告，PDF 这种字数比较少的，反而快一些。
分析：
Coze 的策略是非结构化数据只处理标准的一些文字报告，复杂的 PDF 不处理，但是在结构好的文档和表格上效果都基本上可以接受，虽然不是那么的好，效率挺快的。 构建速度、召回速度效果都比较快
4.2 平台内部不同组件的评测效果
这张图列出了可用于评估 RAG 系统的不同任务以及会影响 RAG 表现的各个组件节点。
在优化 RAG 系统时，可以针对这些组件分别进行优化。
通过持续对这些组件进行优化和迭代，能持续提升 RAG 系统的性能；
但是因为这里只考察 RAG 的检索效率，即 Read 能力，可以看下不同的组件对检索效果的影响。
做几个小实验：
不同 Chunksize 配合 topK 对召回效果的影响；
Rerank 对召回效果的影响；
不同 Embedding 模型对召回效果的影响；
合适的 Chunk 配合扩大窗口
不同 Chunksize 配合 topK 对召回效果的影响，假设模型容纳 3000 个字符的情况下，那么分几组参数：这里参考了 CRUD 论文提到的测试方法，这样的话最终对下游大模型输入的 Token 是不变的，看如何找到最优的组合参数。
chunksize 为 200，overlap 为 100，召回 15 个 Chunk； 这样字符长度大概在 3000
chunksize 为 200，overlap 为 100，召回 5 个 Chunk，但是对召回的结果做下窗口扩大，扩大 3 个 Chunk；
chunksize 为 500，overlap 为 100，召回 6 个 Chunk;
chunksize 为 500，overlap 为 100，召回 3 个 Chunk，但是对召回的结果做下窗口扩大，扩大 1 个 Chunk；
chunksize 为 1000，overlap 为 100，召回 3 个 Chunk;
扩大窗口会对重复的 chunk 进行去重，扩大的是上下窗口，字数更多了，信息也更多一些；
通过扩大文本分块的窗口大小，可以有效提升信息检索中的召回效果。
文本分块的大小并非越小越好。选择合适的分块大小对也很重要。根据实验结果，当分块大小设置为 500 个 token，并扩大 1 个窗口时，效果最好
另外 chunk 越小，在构建索引的时候时间花费越长，因为 Embeding 模型调用的次数更多…
Rerank 对召回效果的影响
在 RAG 系统中，Rerank 模型主要用于以下几个场景：
提高回答的相关性：在信息检索阶段，RAG 系统会从大量候选文档中检索出与问题相关的文档。rerank 模型的作用是对这些候选文档进行排序，确保最相关的文档排在前面，从而提高生成回答的相关性。
优化文档选择：RAG 系统可能会检索出多个相关的文档，但并不是所有文档的内容都适合用来生成回答。rerank 模型可以帮助筛选出最适合生成回答的文档或段落。
减少噪声：检索到的文档可能包含一些与问题不相关或者重复的信息，rerank 模型可以识别并降低这些噪声，提高生成回答的准确性。
评测的结论：
在只有向量召回的情况下，ReRank 模型效果不明显，甚至可能有负面效果，但是也是仅有略微的影响，0.01 的影响。
分析：OpenSearch 在进行向量召回时已经完成了一轮排序（RANK），那么单路召回的情况下 ReRank 和向量召回基本上没太多差异。一般 Rerank 在多路召回场景下会更有效果，这个是召回的文档中可能包含大量噪声信息。Rerank 作为最后一道把关，预计可以提升效果。多路召回肯定是要增加的，后面再看看多路召回之后结合 ReRank 的效果。
关于 Embeding 模型的影响
原计划对比几款主流的 embedding 模型，但发现它们的向量维度不同：
通义的模型是 1536 维：https://help.aliyun.com/zh/dashscope/developer-reference/text-embedding-quick-start?spm=a2c4g.11186623.0.0.959546d0EZ7iH2 BGE 是 1024 维：https://huggingface.co/BAAI/bge-m3 网易的 BCE 是 768 维：https://ai.youdao.com/DOCSIRMA/html/aigc/api/embedding/index.html
鉴于技术上的限制，就拿市面上的 embedding 模型评测报告。也能反映出不同 Embeding 模型对于检索召回的效果影响：
BGE-M3 的性能最好，其次是 ML-E5-Large、E5-mistral-7b 和 Nomic-Embed。BGE-M3 模型尚未在 MTEB 排行榜上进行基准测试，我们的结果表明它可能比其他模型排名更高。值得注意的是，虽然 BGE-M3 针对多语言数据进行了优化，但它在英语方面的表现也比其他模型更好。
五、关于下一代的 RAG
最近听了 AICON 大会的 RAG 相关的分享，一个讲技术细节的下一代 RAG 引擎的挑战，另外一个则是 RAG 应用在客服的具体场景；听下来的感受。
把 RAG 做好关键的两点：离线数据处理和在线检索
准确抽取数据信息： 离线数据处理需要从非结构化文档中准确抽取结构化信息，文档的解析，可以使用一些布局识别模型、表格识别模型。
TextIn 的文档解析服务，或者本地使用 Unstructured-IO 框架，都能达到不错的文档解析效果 多路召回 + 合适的 Embedding ：在线检索需要综合利用多种检索方式平衡召回率和效率，也可以考虑使用最好的文本嵌入模型，提升召回效率，多路召回加重排序提升效果。
关键词召回：基于关键词匹配的方式进行检索。无法处理同义词、多义词等语言现象，召回的结果往往比较粗粒度。
向量召回：计算效率高，可以快速检索出与查询相关的文档。向量表示通常难以捕捉查询和文档的细粒度语义信息，召回的结果可能不够精准。
张量召回（Tensor）：将查询和文档表示为高维张量，充分捕捉它们的语义信息。张量可以看作是向量的推广，能够表达更加丰富的语义关系。计算复杂度较高，对存储和计算资源的要求更高。 涉及到模型训练，索引等，资源消耗更大一些，但是效果更好。
做好了上面的两点，基本上就是工业级可用的水平；另外在实际场景中再兼顾效率的话会训练各种不同的小模型，应对业务中的场景。
上面的 RAG 在市面上已经比较成熟了，再接下来继续发展的 RAG 形态还可以做什么？
Agent RAG：通过自我反思和工具规划，能够更好地回答用户的问题，除了回答问题，主动帮助用户澄清问题，根据用户的反馈，动态调整回答策略，不断优化用户体验。
知识图谱：利用知识图谱构建领域知识的语义网络，捕捉实体之间的复杂关系。不仅有助于提高问答的准确性，还能支持更高级的推理和决策能力。 需要有更低成本的方式来构建知识图谱。
多模态 RAG：现实世界的信息往往以多种模态呈现，如文本、图像、视频等。多模态 RAG 同时处理不同模态的数据，实现跨模态的信息检索和知识融合。 当用户询问 “iPhone 13 的外观有哪些变化？” 时，多模态 RAG 可以从文本和图像中提取相关信息，生成更全面、直观的答案。
其它非技术上的点，就是用户的交互，体验、文档自动更新等：
交互方面，RAG 系统可以支持多轮对话，让用户通过自然语言与系统进行连续的交互，根据对话上下文，动态生成问题和回答，提供更加个性化的服务。
在用户体验上，RAG 系统可以引入解释机制，不仅提供答案，还能给出答案的来源和推理过程，增强系统的可信度。同时，系统可以提供多种答案呈现方式，如列表、表格、图表等，满足不同用户的偏好。
文档自动更新，随着新信息的不断产生，实时更新知识库，确保问答结果的时效性。
从技术上看，RAG 还可以继续做不少的探索，对这方面感兴趣的同学，希望分享更多相关的经验，一块学习进步下~
总结
这次讲了许多 RAG 评测的细节，最后再回顾下文章的大概内容：
RAG 系统评测看两个点：
召回评测：类似于传统的信息检索系统评测，关注召回的准确性和效率。
生成评测：考察大模型在生成回答方面的能力和质量。
针对召回和生成介绍了一些常见的指标和定义，如准确率、召回率、F1 值等。也有很多框架提供了对应的计算方式，对 RAG 系统来说，RAGAS 还是不错的选择。
评测数据集的获取方式：最有效的方式是获取自己业务的真实数据，构造数据集。
* 开源数据集：利用已有的公开数据集进行评测，中文数据集比较少，可以试下 CRUD。
* 大模型生成数据集：使用大模型生成合成数据集用于评测。
* 业务场景积累真实数据：最有效的方式，通过实际业务场景积累高质量的真实数据。
对一些相似的产品，和自身产品内部做了一些评测。
RAG 系统的未来探索方向：AgentRAG、知识图谱、多模态、NL2SQL 算一个需要建设的能力。
更多优质内容请关注公号：汀丶人工智能；会提供一些相关的资源和优质文章，免费获取阅读。
