1、RAG评估的依据和指标

基于大模型的 RAG 应用与传统应用有很大的不同：传统应用的输出大多是确定的且易于衡量的，比如输出一个确定的数值；
RAG 应用的输入和输出都是自然语言，其输出一般是一段文字，无法通过简单的定量判断评估其相关性与准确性等，往往需要借助更智能的工具与评估模型。

任何RAG系统的有效性和性能都严重依赖于这两个核心组件：检索器和生成器。
检索器必须高效地识别和检索最相关的文档，而生成器应该使用检索到的信息生成连贯、相关和准确的响应。
在部署之前，对这些组件进行严格评估对于确保RAG模型的最佳性能和可靠性至关重要。

1.1、RAG应用的评估方法

1、人工评估
人工评估是RAG评估的基础方法，通过邀请专家或人工评估员对RAG生成的结果进行质量评估。评估标准通常包括准确性、连贯性、相关性等。
尽管人工评估能够提供高质量的反馈，但这种方法耗时费力，且受限于评估员的主观性和经验差异。

2、自动化评估
自动化评估是当前RAG评估的主流和发展方向。通过利用大型语言模型和相关算法，自动化评估工具能够实现对RAG生成文本的质量评分，从而快速评估模型性能。
这种方法不仅提高了评估效率，还降低了人力成本。

1.2、RAG的评估类型和输入

评估RAG系统通常有两种方式
1、检索评估
检索评估的主要目标是评估上下文相关性，即检索到的文档与用户查询的匹配程度。
它确保提供给生成组件的上下文是相关和准确的。

2、响应评估
响应评估适用于系统的生成组件。
这些评估衡量系统根据检索到的文档提供的上下文有效地生成响应的能力。

1.3、RAG的评估依据

RAG 应用的评估依据，即评估模块的输入一般包括以下要素：

输入问题（ question）：用户在使用 RAG 应用时的输入问题。
生成的答案（ answer）：需要评估的 RAG 应用的输出，即问题的答案。
上下文（ context）：用于增强 RAG 应用输出的参考上下文，通常在检索阶段生成。
参考答案（ reference_answer）：输入问题的真实的正确答案，通常需要人类标注。

基于这些评估依据，对 RAG 应用进行评估时，按评估类型的常见指标如下：

上下文相关性（ Context Relevancy）
上下文精度（ Context Precision）
上下文召回率（ Context Recall）
忠实度（Faithfulness）(适用于系统的生成组件)
答案相关性（Answer Relevancy）(适用于系统的生成组件)

1.3.1、上下文相关性（ Context Relevancy）：

检索出的上下文与输入问题之间的相关性，即上下文中有多少内容与输入问题相关。

若用户提问 “埃菲尔铁塔的建造年份？”，
检索器返回：
  埃菲尔铁塔于 1887 年动工，1889 年竣工。
  巴黎是法国的文化中心。
尽管第二个片段与巴黎相关，但未包含建造年份的信息。
此时context_relevancy会根据关键信息（如 “1887”“1889”）的存在与否进行评分，而非仅统计相关片段的数量，这个一般用的比较少。

1.3.2、上下文精度（ Context Precision）：

有两种说法：
1、检索出的上下文（context）中与参考答案（reference_answer）相关的部分在上下文（context）中是否出现在最前面的位置，这种较为常用。
2、检索到的上下文（context）中相关信息的比例，可以理解为
$Context Precision=\frac{上下文中与问题相关的信息数量}{上下文总信息数量 }$

问题：“苹果公司的总部在哪里？”
上下文：“苹果公司（Apple Inc.）成立于 1976 年，总部位于美国加利福尼亚州库比蒂诺市，CEO 是蒂姆・库克，主要产品包括 iPhone 和 Mac。”
分析：问题关注 “总部位置”，上下文中仅 “加利福尼亚州库比蒂诺市” 相关，其余（成立时间、CEO、产品）无关 → 精确率 = 1/4=25%。

1.3.4、上下文召回率（ Context Recall）：

衡量检索到的上下文中是否包含回答问题所需的全部关键信息，或者说检索到的上下文（context）与参考答案（ reference_answer）之间的一致程度，有时也称为命中率（ hit_rate） $Context Recall=\frac{上下文中包含的关键信息数量}{参考答案中关键信息数量 }$

问题：“《三体》的作者是谁？哪一年出版？”
参考答案：“刘慈欣，2006 年。”
上下文：“刘慈欣，中国科幻作家，2006 年开始在《科幻世界》连载《三体》。”
分析：参考答案的关键信息是 “刘慈欣” 和 “2006 年”，上下文均包含 → 召回率 = 100%。
反例：若上下文仅包含 “刘慈欣”，未提 “2006 年”，则召回率 = 50%

1.3.5、忠实度（Faithfulness）:

生成的答案（ answer）是否完全基于提供的上下文（context）信息，没有捏造、幻觉或与上下文矛盾的内容。
将生成答案拆解为原子事实（如时间、地点、事件），逐一检查是否能在上下文中找到直接依据，如果存在上下文未提及的信息，即使正确，若上下文无依据也视为不忠实

问题：“爱因斯坦在哪一年获得诺贝尔奖？”
生成答案：“爱因斯坦于 1921 年因光电效应研究获得诺贝尔物理学奖。”
上下文：“1921 年诺贝尔物理学奖得主阿尔伯特・爱因斯坦，获奖理由为‘发现光电效应定律’。”
分析：答案中 “1921 年”“光电效应”“诺贝尔物理学奖” 均来自上下文，无额外信息 → 忠实度 = 100%。
反例：若答案添加 “他当时在普林斯顿大学任教”（上下文未提及），则忠实度下降。

1.3.6、答案相关性（Answer Relevancy）:

生成的答案（answer）是否直接、清晰地回答了用户原始的查询问题（question）。即使答案忠实于上下文，但如果答非所问，那么这个答案也是无效的。

问题：“如何煮咖啡？”
生成答案：“咖啡豆需研磨至中粗度，用 90℃热水冲泡 3 分钟。”
分析：答案直接针对 “如何煮” 的步骤，包含关键动作（研磨、冲泡温度、时间）→ 相关性高。
反例：若答案为 “咖啡豆起源于埃塞俄比亚”（回答 “起源” 而非 “方法”），则相关性低。

1.4、评估指标总结

指标	归属	相关评估输入	含义
context_recall	检索	上下文 (context)、参考答案 (reference_answer)	上下文中覆盖用户问题所需关键信息的比例
context_precision	检索	上下文 (context) + 参考答案 (reference_answer) 或者问题 (question) + 上下文 (context)	上下文的关键信息位置是否靠前或者是上下文的关键信息所占比例
faithfulness	响应	答案 (answer)、上下文 (context)	生成的答案是否完全基于提供的上下文信息
answer_relevancy	响应	答案 (answer)、问题 (question)	生成的答案是否直接、清晰地回答了用户原始的查询问题
context_relevancy	检索	问题 (question)、上下文 (context)	上下文中有多少内容与输入问题相关，较少使用

2、常用的RAG评估工具

2.1、Ragas

RAGAs是一个用于评测检索增强生成（RAG）应用的评测框架，它的核心目标是提供一套综合性的评测指标和方法，以量化地评测RAG管道(RAG Pipeline)在不同组件层面上的性能。
RAGAs特别适用于那些结合了检索（Retrieval）和生成（Generation）两个主要组件的RAG系统，支持Langchain 和 Llama-Index。

RAGAs评估标准

2.1.1、RAGAs评估指标相互之间的关系

检索器 Context Recall 和 Context Precision 直接决定了输入给生成器的上下文质量。
理想状态：高召回率 + 高精确率。检索器能找到所有相关信息，且只找到相关信息。
现实权衡：在大规模数据集中，召回率和精确率往往难以兼得。提高召回率（找全）可能牺牲精确率（引入噪声），反之亦然。

如果上下文不完整（低 Context Recall），生成器可能因缺乏信息而无法给出完整或准确的答案（影响 Answer Relevancy），甚至可能被迫“猜测”（影响 Faithfulness）。
如果上下文充满噪声（低 Context Precision），生成器可能难以聚焦关键信息，导致答案冗余、偏题（影响 Answer Relevancy），或错误地依据了不相关信息（影响 Faithfulness）。

2.1.2、F1分数

同时对于context_recall和context_precision这两个指标，如果各有高低，比较难判断的时候，我们还会引入F1分数进行综合评估，F1分数用来平衡精确度和召回率，目标是找到适合特定应用需求的最佳平衡，是精确度和召回率的调和平均值
$F1分数=2∗\frac{准确率∗召回率}{准确率+召回率}$

2.1.3、RAGAs评估指标标准

指标	高	中	低	满分
context_recall	$\ge 0.8$	$0.5 \sim 0.8$	$< 0.5$	1.0
context_precision	$\ge 0.7$	$0.4 \sim 0.7$	$< 0.4$	1.0
faithfulness	$\ge 0.9$	$0.7 \sim 0.9$	$< 0.7$	1.0
answer_relevancy	$\ge 0.9$	$0.7 \sim 0.9$	$< 0.7$	1.0

2.1.4、RAGAs评估指标偏低的原因

指标	可能的问题场景	核心问题指向
context_recall 低	检索器未覆盖关键文档（如知识库缺失）、嵌入模型语义匹配能力不足等	检索器
context_precision 低	检索器返回大量无关文档、向量数据库索引策略有误、相关文档排名低等	检索器
faithfulness 低	生成模型未严格遵循上下文（如提示词未明确要求“基于提供的信息回答”）、上下文过长导致信息稀释等	生成器
answer_relevancy 低	生成模型未准确理解问题意图（如问题复杂时未使用链式提示分解）、上下文与问题关联性弱等	生成器
四个指标均低	系统性问题，很可能是检索质量极差（Recall 和 Precision 都低），导致生成器输入混乱，进而影响 Faithfulness 和 Relevancy。也可能是问题本身超出系统能力范围。	检索器优先

2.1.5、RAGAs评估指标具体优化策略

系统性优化路径与策略：从基础到协同
当面临性能问题，特别是多个指标偏低时，应该如何着手优化？

核心优化原则：先固根基，再求精进 (检索器优先)
依赖关系：生成器的输出质量上限受限于检索器提供的输入质量。“Garbage In, Garbage Out”。优化检索器是提升整体性能的杠杆点。
成本效益：优化检索策略（如调整参数、混合检索、重排序）通常比大规模微调生成模型或复杂的提示工程更快见效，成本也相对较低。
分阶段优化策略：
第一阶段：夯实检索基础 (优化 Context Recall & Context Precision)
第二阶段：提升生成质量 (优化 Faithfulness & Answer Relevancy)
1、提升context_recall（上下文召回率）
检索器增强：
•混合检索：结合BM25（关键词匹配）和向量检索，例如在医疗场景中，使用BM25召回包含特定症状术语的文档，再用向量检索补充相关病例。
•查询改写：通过 LLM 将用户问题扩展为多个同义词或子问题，例如将 “如何治疗糖尿病” 改写为 “糖尿病的药物治疗方案” 和 “饮食管理方法”，提升检索覆盖范围。
知识库优化：
•数据清洗：去除重复或低质量文档（如网页爬取的广告内容），确保检索空间的有效性。
•增量更新：定期补充新数据（如行业报告、政策文件），并重新构建索引，避免知识滞后。

2、提升context_precision（上下文精度）
重排序技术，对检索结果进行二次排序，例如在法律场景中，优先展示与案件类型匹配的法律条文。
分块策略优化，语义分块、调整块大小、动态分块。
调整检索参数: 优化 Top-K、相似度阈值、通过实验确定混合检索权重的最优权重、平衡召回率和精度等。

3、提升faithfulness（忠实度）
生成器约束：
•提示词工程：在提示中明确要求 “仅基于提供的上下文回答”，并添加示例（如 “根据上下文，以下哪项是正确的：...”）。
•事实核查：在生成答案后，使用 LLM 对答案进行二次验证等。
上下文质量增强（上下文本身存在缺失、冗余、无关、矛盾，模型必然会出现幻觉（忠实度下降））：
•截断策略：上下文太长时优先保留上下文开头和结尾的关键信息（如论文摘要、法律条文标题），避免因 LLM 注意力涣散导致中间信息丢失。重排序也是可以考虑的方法。
•元数据增强：为每个文档块添加标题、关键词等元数据，帮助生成模型快速定位关键信息。
•提升上下文纯度和语义完整性：如上下文压缩和过滤、合适的分块大小

4、提升answer_relevancy（答案相关性）
问题理解优化：
•问题分类：对用户问题进行分类（如 “事实型”“比较型”“建议型”），并针对不同类型生成结构化提示（如 “请分点回答...”）。
•多轮对话：在答案中添加追问提示（如 “是否需要更详细的解释？”），引导用户明确需求。
生成策略调整：
•摘要压缩：对上下文进行摘要，去除冗余信息后再输入生成器，提升回答的针对性。
•对比学习：微调生成模型，使其学习问题与答案的匹配模式。

2.1.6、RAGAs评估指标参考范围

指标的理想值并非一成不变，需结合业务场景的风险和需求来设定
核心指标通用基准范围 (参考)：

Faithfulness: ≥ 0.85 是行业普遍追求的目标。低于 0.7 可能存在严重幻觉。
Answer Relevancy: ≥ 0.8 保证较好的用户体验。低于 0.6 可能用户难以接受。开放域问答≥0.7也可以接受（如维基百科 QA 场景中，RAGAS 默认测试集平均得分 0.72）
Context Recall: ≥ 0.7-0.8 是常见目标。知识密集型场景要求更高。若知识库规模庞大且允许部分信息缺失（如新闻摘要），可降至 0.6
Context Precision: ≥ 0.7 通常是好的起点。高风险场景要求更高。

2.1.7、RAGAs评估指标具体行业的阈值建议

医疗 / 法律 (高风险):

核心: Faithfulness ≥ 0.9, Context Recall ≥ 0.9。
关注: 任何事实错误或信息遗漏都可能导致严重后果。
客服 / 电商 / 咨询 (效率与体验并重):
核心: Answer Relevancy ≥ 0.8, Context Precision ≥ 0.7。
关注: 回答需直接解决问题，避免冗余信息干扰用户。
通用问答 / 内容生成 (平衡信息覆盖与相关性):
核心: Answer Relevancy ≥ 0.7, Context Recall ≥ 0.7。
关注: 在开放域中，保持答案相关性和信息覆盖面的平衡。

2.1.8、RAGAs持续评估与优化的闭环

通过 RAGAS 的四大核心指标，可以通过以下步骤持续优化：

量化理解 RAG 应用在检索和生成环节的具体表现。
诊断分析指标间的协同关系和潜在的性能瓶颈。
指导优化遵循“检索优先、生成增强、协同调优”的系统性路径。
设定目标结合业务场景制定合理的性能阈值。
最终，RAG 应用的性能提升是一个持续迭代的过程。定期使用这些指标进行评估，结合用户反馈，不断调整优化策略，才能打造出真正高效、可靠的 RAG 系统。

2.2、Trulens

TruLens是一款旨在评估和改进 LLM 应用的软件工具，相对独立，可以集成 LangChain 或 LlamaIndex 等 LLM 开发框架。
使用反馈功能来客观地衡量 LLM 应用的质量和效果。包括分析相关性、适用性和有害性等方面。TruLens 提供程序化反馈，支持 LLM 应用的快速迭代，这比人工反馈更快速、更可扩展。

Trulens特点

3、评估选择合适的知识块大小

1、 chunk_size 越小，产生的知识块越多、粒度越小。尽管知识块越小，语义越精确，但是风险是携带的上下文越少，可能导致需要的重要信息不出现在检索出的顶部知识块中（特别是当 top_K 比较小时）。
2、chunk_size 越大，携带的上下文越完整，但也带来语义不精确的隐患。此外，过大的 chunk_size 可能导致性能下降、携带的上下文过多，从而导致上下文窗口溢出及 token 成本升高
3、对于常见的事实性问答，只需要少量特定的知识块，而对于摘要、总结、对比之类的任务，需要更大的知识块甚至全部知识块。
4、128-512 tokens：这是最常见的分块区间，平衡了上下文完整性和检索效率。例如：微软研究指出，512 tokens 是较小块的基准，而企业级应用中甚至会采用 100 tokens 的块大小以提升精准度。
Databricks 实验使用 512 tokens 块大小和 256 tokens 重叠步幅，在长上下文场景中表现优异。
5、1024 tokens：LlamaIndex 测试显示，该大小在响应时间和质量（忠实度、相关性）之间取得最佳平衡，尤其适合需要更多上下文的复杂任务
6、技术文档 / 学术论文：采用200-300 tokens，确保专业术语和逻辑结构的完整性。例如，微软分析显示，技术文档分块过大会导致术语稀释，影响检索准确性。
7、长叙事文本（如小说）：可扩展至500-1000 tokens，减少分块数量以保留情节连贯性。
8、社交媒体 / 短文本：使用100-200 tokens，适配碎片化内容的检索需求。

RAG应用评估技能和工具