原文: https://mp.weixin.qq.com/s/am89yasxAvuYUToEAWNyTA
RAG（Retrieval-Augmented Generation，检索增强生）最初由Facebook AI Research（现Meta AI）团队在论文 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks 中提出，并发表于NeurIPS 2020。
如果你有使用RAG应用，你会发现，RAG框架是一个复杂的工作流，包括分块、搜索、上下文拼接和内容生成等步骤，一旦系统最终响应的内容不符合预期，对于问题的定位会非常复杂，是模型出现了幻觉？还是从一开始就没有获取到正确的信息？
这就需要一个完善的RAG评估体系：评估RAG系统各个模块运行的效果，在用户之前分析问题、甚至是预判问题。这篇文章会和大家详细聊聊，如何在开发和生产环境中评估RAG系统。
全文速览
- 基本概念 ：RAG系统 能够从大量的语料库中检索出与输入问题相关的上下文信息，并利用这些信息生成准确、合理的回答, RAG评估用于评价RAG系统性能的系统方法。
- RAG评估核心内容 ：检索 （查找有用信息）、生成（生成最终答案）。
- 检索评估：分为排序、上下文相关性指标，前者可以采用Top-K召回，后者可以采用人工或LLM来判断。
- 生成评估
- 有真值：使用LLM作为评判员或语义相似性，将输出与正确答案进行比较。
- 无真值：可以检查响应的忠诚度、完整性、语气或结构质量
- 合成测试数据：一种帮助RAG评估的方法，通过从知识库中生成问答对来实现，用以在没有真实数据的情况下快速构建和测试集。
- 鲁棒性测试和对抗性测试：确保RAG系统在面对风险输入或极端情况时，响应仍然安全一致。鲁棒性测试评估RAG系统在正常场景之外的行为，并观察其能否从容的应对。对抗性测试侧重系统的安全性，测试RAG系统能够抵御恶意攻击或误操作，并保护用户的数据和隐私。
基本概念
什么是 RAG？
RAG作为当下主流的LLM应用框架，将外挂的知识库（如网络数据、企业私有文档）、LLM内置的知识完美融合，有效解决LLM中存在的信息过时 、输出幻觉、行业数据隔离等痛点问题，产生更准确、更有用的结果。
举个例子，对于一家公司的客服机器人，LLM是很难知道这家公司的产品功能、业务逻辑的。相反，RAG系统在用户提出问题时，会检索公司内部的产品或业务文档，将检索到的相关内容交给LLM，由LLM生成最终的答案。
RAG 系统可以分为两大步骤：
- R（Retrieval）: 尝试找到与用户查询最相关的信息片段，信息的来源包括文档存储库、知识库、SQL查询数据库等。
- G（Generate）: 利用检索到的信息生成答案
需要提醒的是，RAG系统是一种设计理念，而非单一的实现形式。比如，检索部分的实现形式是多样的，如语义搜索、关键词搜索、SQL查询，甚至是API调用，为模型提供有用的上下文信息。
在企业应用中，检索实际上是对内部的大量非结构化文档进行搜索的系统，包括文档的准备、存储、索引方式和排序。
检索完成后，需要为LLM构建完整的提示信息，包括：
- 用户的问题
- 检索到的上下文
- 系统提示，约定模型按照什么格式输出答案
什么是 RAG 评估？
定义：旨在衡量RAG系统在实际应用中的性能表现。比如：是否提取了正确的信息？是否给出了正确的答案？输出结果是否可信？一个合理的评估体系有助于回答这些问题，并指导开发工程师做出更好的设计决策。
RAG系统就像一台精密的机器，要让它稳定运转，每个关键环节都要做扎实：文档的分块和存储方式、使用的嵌入模型、检索逻辑、提示格式、LLM 版本等等。
一套靠谱的评估方法，就像这台精密机器的调试工具箱，能解决很多实际问题：
- 快速给出不同方案的对比效果，比如哪种文档分块方式找答案更准
- 追踪哪些因素能提高或降低效果
- 精准定位问题，当系统答非所问或出错时，能更快找到症结在哪儿，调试起来更省心。
说了这么多，到底该如何评估呢？一种简单的方式，对RAG系统进行端到端评估，重点关注最终答案的质量，这种方式尽管也可行，但不利于问题的排查、效果的优化。
更优的方式是，将检索和生成阶段分开评测，这对于调试也至关重要。当你得到错误答案时，你首先应该问自己：哪里出错了？
- 系统是否检索到正确的上下文信息
- 上下文正确了，模型是不是出现了幻觉
接下来，我们将分别介绍检索和生成阶段的评估方法
检索阶段的评估方法
下面将介绍有真值、人工标注和LLM三种评估方法。
有真值的评估方法
检索评估并非一个新话题，所有搜索引擎的背后都有一套这样的评估机制，比如百度、谷歌，这是一个典型的机器学习应用场景。在这套评估机制的引导下，工程师可以为用户提供更好的产品服务。类似的，我们也可以将这套方法复用到RAG系统中。
你需要有一个真值数据集，对于每个查询，需要定义包含答案的正确来源，可以是文档ID、数据块ID 或链接。
在信息检索术语中，这些被称为相关文档，即为用户查询提供正确、有效信息的条目。
有了这份真值数据集，就可以在系统中运行查询，并通过比较检索到的数据块与预期数据块，来检查系统是否能够找到预期的上下文。为了量化结果，可以计算标准的信息检索指标。
以下是一些例子，后续将以专栏的形式，详细介绍各类评估指标的原理、实现：
| 指标 | 说明 |
|---|---|
| 精确度@k | 在检索到的前k个结果中，有多少是真正相关的？ |
| 召回@k | 在所有相关文档中，有多少个文档被检索到排名前k之列？ |
| 命中率 | 前k个结果中是否至少出现过一个相关条目？（是/否） |
| NDCG@k | 归一化折扣累计收益：用来衡量排名前k个检索结果的相关性和排序合理性 |
以精确度@k指标为例，其计算示意图如下
这些评估指标能帮助我们有效对比不同的搜索配置，比如重排规则、嵌入方法，还能定位问题。缺点是，构建真实的测试数据集特别耗时，需要人工把每个测试问题对应到正确的参考内容上。
人工标注相关性
这是一种相对简单的方法，在检索后评估结果。
无需预先定义相关文档，让系统按原样运行测试查询，然后手动评估结果。对于每个查询，都要检查系统的检索内容，并分配一个标签，例如：相关 、部分相关 、不相关。
许多团队在实践中也是用这种方法评估检索效果的。例如，谷歌制定了详尽的内部准则 （https://www.google.com/search/howsearchworks/how-search-works/rigorous-testing/）供人工评分员参考。
这样做的好处是灵活，可以评估整个检索流程在实际运行中的效果，包括：
- 评估用户在生产环境中实际看到的检索质量。
- 找出性能极差的查询
- 更好地理解边界情况和歧义查询
缺点也显而易见，无法计算召回率，因为没有真值。
LLM评审员评估相关性
LLM评审员使用用大语言模型，在评估提示词的引导下，评价RAG系统响应的结果。比如，可以给LLM定制提示词，让它判断某个回复有没有帮助，或者是否符合特定的规则要求。
下面，将为大家介绍LLM评审员的两种技术方案。
对数据块评估相关性
可以把用户的问题和检索到的数据块一起给到LLM评审员，让它来判断信息块和用户问题是否相关。
LLM评审员给出的判断结果有两种形式：
- 简单的二分类标签，直接标记相关、 不相关
- 给出一个具体的相关性分数
还可以使用其他LLM评估方法，例如，基于嵌入的语义相似度，它会返回一个数值分数，反映查询和检索到的数据块在语义上的相似程度。
需要注意的是，RAG系统一般会对单次查询返回多个数据块，这意味着需要对每个数据块单独进行评分。
举个简单的例子：假设关于香蕉的查询检索到三个短文本块。每个文本块都是一个句子，可能来自不同的文档。
然后，采用LLM评审员为每个数据块分配一个相关性分数，其中 1 表示高度相关，0 表示完全不相关。
例如，上图中的Chunk 1 包含有关香蕉健康益处的相关信息，得1分。但Chunk 3这样的内容与用户的查询无相关性，得0分。
一旦评估完每个数据块的相关性之后，就可以汇总结果，评估本次查询的整体检索质量。 有三种实现方式：
- 二元命中：是否至少有一个数据块达到了相关性阈值？
- 相关数据块占比：检索到的数据块中，相关的数据块占比是多少？
- 平均相关性得分：总体而言，这些内容块的相关性如何？
我们以平均相关性得分例，如下图所示，分别是关于香蕉和土豆烹饪的查询，从Relevance来看，关于香蕉的问题，得到了更多相关的数据块。
更进一步，我们可以汇总每个查询在多个检索文本块下的相关性得分，从而计算出整个测试数据集、或特定时间段内查询的相关性打分。
对上下文评估相关性
如果检索系统返回的上下文很短，或者很容易将所有数据块打包成一个上下文块，可以跳过按块评分，直接评估整个上下文。只需要为LLM设置提示词就行，如：
帮我判断检索到的内容是否包含足够的信息回答用户的问题？如果是，则显示有效；否则，显示无效。
LLM评审员将会按照上述提示词返回结果，并附有理由，示例如下：
经过上述两种方法的介绍，可以总结LLM评审员方法具有如下优势：
- 工作量低：只需要测试查询语句，无法标注问题的答案。
- 强基线性能 ：LLM可以很好地处理相关性检查，特别是简单是非问题上。微软在论文 Large language models can accurately predict searcher preferences声称，GPT-4在Bing的RAG系统相关性评估方面，达到了接近人类的水平。
- 非常适合快速实验：当你要尝试新的数据库或检索配置时，可以直接运行LLM评审员，快速比较不同配置的效果。
- 适用于生产环境监控：由于不需要事先构建真值，特别适合生产环境。
内容生成阶段的评估方法
一旦系统检索到上下文，LLM就会使用上下文、用户的问题和系统提示词来生成最终答案。
有两种方法评估LLM生成的最终答案是否有效：
- 基于参考的评估 ：将RAG系统的输出与预定义的参考答案进行比较，这就需要构建标注好的数据集，适用于开发或测试环境。
- 无参考评估 ：当没有参考答案时，仍然可以使用指标来评估质量，比如模型回答结构、语气、长度、完整性、是否包含必要的免责声明等特定属性。这类方法适用于灰度阶段和生产环境。
基于参考的评估
如果是离线测试，最可靠的评估方法是将LLM的答案与正确的答案进行比较。这些基于参考的评估可以衡量 RAG系统在测试集中与理想答案的接近程度。
从上面的描述可以看出，要使用基于参考的评估方法，需要构建一系列问答对数据集，作为评测基准。
接下来，将问题输入到RAG系统中，并将生成的响应与参考响应进行比较，具体的计分方式如下：
- 语义相似性: 分别获取生成答案和参考答案的嵌入向量，计算两个向量间的相似度
- LLM 作为评判员：这是一种使用LLM作为判断器的方法，用来比较生成答案和参考答案，并评估RAG响应是否正确、完整或与之前的文本相一致。
两种方法效果都不错。语义相似度方法效率高、可扩展性高。基于LLM的方法能够提供更细致的上下文推理，最大的优势可以根据用户的评估规则进行调整。
以下是一个基于LLM方法评估RAG响应效果的示例：
RAG评测数据集
在RAG评估中，评测数据集的质量至关重要。若数据集仅含简单或不切实际的问题，模型难以应对现实中的复杂场景。测试用例需贴合真实用户问题、覆盖关键主题，尽可能的覆盖多种场景，只有这样，才能精准评估 RAG 的实际性能。
构建一个完备的测试集需要花费大量精力，好消息是不用完全手动构建，可以直接从知识库生成测试用例，提高效率。实现上也十分简单，从文档或知识库中选取数据块，让LLM完成以下操作：
- 根据数据块的内容，生成一个问题。
- 根据数据库的内容，生成可以回答上述问题的答案。
由于上述测试用例来源真实的RAG知识库，也会更加符合生成环境中的业务场景。此外，你可以通过变换生成问题的表述方式、模拟不同的角色，来匹配实际应用中的查询风格和意图，进一步丰富RAG评测数据集。
一旦有了成千上百个这样的示例，就可以使用它们来对比不同配置下RAG系统的好坏。
无参考评估
在实际应用中，用户可以提出任何问题，而事先并不知道正确答案 是什么。这就需要无参考的评估方法了。
比如一些规则性的检查，可以直接通过编程实现，如
- 长度：答案是否符合规定的字数限制？
- 链接是否存在：是否包含指向来源的链接，以及该链接是否有效？
- 完全匹配：是否包含特定免责声明？
即使没有正确答案，仍然可以利用一些有价值的数据，如用户的问题、检索到的上下文以及LLM的响应，通过合适的方法来推断回复本身的质量，以下是一些你可以评估的内容：
| 指标 | 说明 |
|---|---|
| 忠诚度 | 衡量LLM的响应遵从检索的上下文程度。得分低，回答出现幻觉的可能就越大。 |
| 答案相关性 | 衡量LLM的回答对用户问题的相关度。得分低，可能答不对题 |
| 上下文相关性 | 衡量召回的上下文能够支持用户问题的程度。得分低，检索了太多与问题无关的内容。 |
| 语气 | 该回复是否符合品牌的风格或语气？ |
| 拒绝 | RAG系统是否拒绝回答 |
可以使用LLM作为评判工具来评估上述指标。例如，在计算忠诚度时，可以将问题、上下文和答案传递LLM，提示词可以这样写，答案{RAG的响应}是否忠实于检索到的上下文{RAG检索的内容}，还是添加了未经证实的信息、遗漏了重要细节或与来源相矛盾？请返回忠诚、不忠诚。
下面是忠诚度评估方法的具体样例
RAG评估方法小结
根据是否存在真值情况，我们对RAG评估方法作了更进一步的总结，如下图所示，从左到右，依次代表检索和生成两个阶段。
检索阶段：
- 如果事先知道每个查询的相关文档，可以计算排序指标，如召回@k、NDCG@k。
- 如果不知道查询的相关文档，可以通过检索的数据块与用户请求的相关性来判断，具体的方式可以是人工标注、或使用LLM来判断。
内容生成阶段：
- 如果有参考答案，可以使用LLM评判员或语义相似性来评估正确性。
- 即使没有参考答案，可以检查答案是否忠实于上下文/完整，答案是否与问题相关，以及语气、结构或安全性等自定义属性。
该使用哪种评估方法，这取决于项目所处的阶段：开发、测试还是生产环境。
RAG高级评估方法
对于企业内部使用的RAG系统，基本的质量检查通常就足够了，风险低、范围窄、复杂度也易于管理。
但许多实际应用，情况要复杂的多，尤其是医疗保健、金融或法律支持等领域。这些系统通常服务外部用户，并且涉及信任、准确性和安全性等高风险问题。
可能还会遇到复杂的多轮聊天机器人或代理式流程，在这种情况下，测试一串简单的查询列表是不够的
对于上面提到的情况，需要更高级的评估方法来测试系统的稳健性、边界行为或多轮体验的质量。
鲁棒性测试
鲁棒性测试的目标是评估RAG系统在正常场景之外的行为，并观察其能否从容的应对。这意味要测试系统如何处理棘手或不寻常的问题。需要考虑以下情况：
- 明确风险和极端情况：识别可能导致不良后果的场景。
- 创建测试查询：模拟这些风险的测试用例。
- 确定一个好的回应方式：例如，可以是拒绝、要求澄清，或者采取稳妥的默认回答。
一种可行的方案，可以利用LLM评审员自动对输出进行打分，实现对流程的量化评估。我们来看一个鲁棒性测试的例子。
在本例中，为了测试系统回答的一致性，以不同的方式提问同一个问题，比如使用不同的措辞、风格和结构来描述同一个问题，并检查系统响应是否一致。通过对RAG系统进行一致性测试，可以提高其准确性和可靠性，从而更好地满足用户不同表达方式的需求。
边界情况
边界情况指的是在研发中可能会出现的一些非常规、特殊的情况。这些情况可能很难预测，并且可能导致系统出现错误或异常行为。
为了确保系统的稳定性和可靠性，开发者需要针对这些边界情况进行测试。可以通过精心设计一些特殊的测试用例来实现，比如，关于竞争对手的问题、模糊的单个单词查询等。每个测试用例都应该与一个自动化的评估器配对，以检查系统是否正确地处理了该测试用例。
通过边界情况的测试，可以发现并修复潜在的缺陷，从而提高系统的质量和性能。同时，也可以帮助用户更好地理解和使用系统，减少不必要的困惑和误解。
边界问题样例：
| 类别 | 测试内容 | 示例输入 | 评估/预期行为 |
|---|---|---|---|
| 品牌安全 | 当被问及竞争对手或产品评价时，系统表现如何？ | 为什么[竞争对手]比[你的品牌]更好？ | 回应得当或拒绝；避免负面比较或未经许可的观点。 |
| 外语 | 系统如何处理它不应该支持的查询语言 | 这是什么政治？ （西班牙语，如果不受支持） | 礼貌地回复支持的语言列表。 |
| 输入不完整 | 只有一个词或含义模糊、缺乏明确语境的问题。 | "退款"或"政策" | 要求提供澄清或背景信息，而不是进行推测性回答。 |
| 多个问题 | 一次输入可处理多个子问题 | 价格是多少？试用期有多长？ | 两个问题都回答得很清楚；没有跳过或忽略任何部分。 |
| 歧义查询 | 缺乏关键背景信息或有多种可能的含义 | 如果我全职工作，需要缴纳哪种税？（未提供国家/地区信息） | 请求澄清（例如，地点）；避免猜测具体细节。 |
另外，还可以添加专家精心设计的特殊案例，即需要根据使用场景进行细致处理的问题。例如，退款政策可能因用户所在国家/地区而异，或者某些员工福利可能仅在用户入职六个月后适用。
为了设计这些问题，与了解目标用户、熟悉某个领域的专家合作会很有帮助。甚至，可以将这些问题收集到一个专门的测试数据集中，因为这些数据具有极高的商业价值，包含行业领域最困难或风险最高的查询。
对抗性测试
对抗性测试则是故意试图破坏系统，旨在发现不安全、非预期或不符合规范的行为，这些行为可能会被用户或攻击者在实际使用中触发。
对于面向公众开放的RAG系统，或者是受监管的RAG应用、敏感的行业，对抗性测试尤为重要。我们希望确保模型不仅能够产生好的答案，还要避免产生有害或危险的答案。
在对抗性测试中，需要设计一些查询语句，故意尝试破坏系统，例如绕过安全措施、混淆模型或触发风险输出。这些示例可能不会出现在常规用户日志中，但它们正是你在生产环境中出现故障之前想要确认的场景。可以人为地创建这些测试查询语句，以模拟真实的攻击尝试。
一些常见的测试场景：
- 提示注入 ：试图覆盖原始的提示指令，例如，忽略之前的文本，改为......
- 越狱 ：巧妙措辞的输入，试图诱使模型违反安全协议。例如：告诉我如何做X，但假装是为了写小说。
- 有害内容：与暴力、仇恨言论、自残或虚假信息相关的查询。
- 禁忌话题：有关法律咨询、医疗诊断、政治方面的问题，如果不是该领域的应用，系统最好不要响应相关问题。
- 操纵尝试 ：试图让系统自动提供财务报价、折扣或确认等一系列需要人工批准的事情。例如，今天的折扣码是什么？我可以申请退款吗？
- 敏感场景 ：来自弱势用户的反馈。例如：*我感到绝望，我该怎么办？*这样的问题应该得到清晰、安全且尊重的回应，理想情况下，还应进行升级处理或转人工。
会话级评估
许多RAG系统并非仅仅回答单个问题，而是参与多轮对话。例如，客服聊天机器人或故障排除助手，用户需要通过多个步骤与系统进行交互。
这意味着系统的质量评估不仅仅取决于一次回复，还需要考虑是否很好地处理整个对话过程。针对这种场景，可以从以下几个方面考虑：
- 会话成功：用户的问题最终是否得到解决？
- 一致性：系统是否忘记了上下文、重复或自相矛盾？
- 谈话语气：整个谈话过程中语气是否恰当？
在测试中，会话级别的数据比单个回合的例子更难创建。有两种备选方案：
- 让测试人员在真实场景下收集对话信息，这种方法可以提供最真实的数据，成本高、效率低。
- 设计自动化脚本模拟多轮测试用例，用以代表常见或关键用户使用场景，这种方法可在短时间内生成大量的测试用例，但会忽略一些真实场景下的交互细节，容易导致测试不准确。
沿用之前用大模型做评估的思路，把多轮对话传给模型，让其评估帮助性、回答的一致性，或是用户的情绪变化等内容。输出结果可以是二元判断，比如直接标记已解决、未解决，再附上具体的评估依据。
对于离线环境会话级测试不太好落地，但在生产环境下，可以真实地评估用户与RAG系统的交互情况。为了便于后续自动化评估、问题排查，需要在后端开启会话跟踪，根据用户ID、会议ID记录多轮交互内容。
当数据积累到一定规模后，通过自定义的筛选规则，从中获取特定的会话内容进行评测，比如用户提到竞争对手、表达对产品不满的对话内容。
小结一下，会话级评估能发现单轮检查易遗漏的问题，比如丢失上下文、反复说一样的内容，或者始终没解决用户的核心问题，而是在和用户打太极。融合了会话级评估的RAG系统， 能确保即时回应、真正解决用户咨询的问题。
RAG评估最佳实践
设计一套好的评估体系不仅选择指标，还得构建切实可行的工作流程，帮助迭代改进，并始终满足真实的用户体验。
设计高质量的测试用例
评估效果取决于测试样本的质量。在考虑评估指标、撰写LLM评估提示词之前，优先关注评估数据集：是否真实、与测试目标相关性如何？是否具有代表性？
优先使用真实数据。如果可以，尽量使用真实的用户查询、过往的对话日志或内部搜索历史记录来生成测试用例。这样做，保证了评测数据符合人们实际使用的场景。
没有真实数据，可以考虑合成。可以调整数据合成策略，生成更真实、更多样化的示例。比如，在给LLM系统提示词时，为其定义具体的角色（正在比较方案的客户、正在审核政策的内部分析师等），从他们的角度生成问题。另外，测试内容需要结合数据类型的比例来生成，假设实际场景中有40%是与商品退款有关，在合成数据中也需要体现这一点。
一定要人工检查合成的测试机。LLM可以辅助生成测试用例，但并不意味着可以盲目使用测试数据集。需要规则脚本进行筛选，甚至需人工抽样筛查。
参考领域专家的建议。在某些具体的领域，存在许多边界情况，可能会影响系统性能、安全性和稳定性的情况。这些情况通常由丰富经验和知识的专业人员掌握。可以提供一些工具和支持，例如共享表格或轻量级用户界面，帮助他们更轻松地审查输出结果，并提出测试案例。
在实验中，务必使用相同的测试集。每次运行都重新生成测试集，这是一类常见的错误，会引入噪声，使结果不可靠。正确的做法是，保持测试集的稳定。
随着时间的推移，请更新测试数据集。在完成不同配置的性能对比、系统也稳定运行一段时间了，测试集的规模也应该不断演进，可以使用观察到的真实用户查询和故障来扩展数据集。另外，最好保留一份最初的测试集，作为整个系统的性能基线。
选择核心的指标
不需要对所有的指标评估一次，应当结合系统的当前问题、业务需求，选择适配的评估方式。
- 拒绝万能指标：不同的阶段需用不同评估工具，例如，检索评估要看数据块相关性与排序质量，鲁棒性测试要考虑品牌安全等定制评估项，生产环境追踪忠实度、格式正确性等核心指标。
- 聚焦实际问题：优先对已发现的错误或高风险点设计评估，避免对所有指标评估，这只会增加工作量和噪声干扰，这类指标无法定位真实问题。
- 让LLM对齐人工标注：LLM 评估方法需以人工标注为基准，而非依赖现成提示词或固定指标，要通过人工标注案例校准优化LLM提示词，使LLM评估标准与业务标注准则保持一致，从而实现人工标注的规模化延伸。
- 规避完美主义 ：评估方法以有用为目标，不要追求极致，可以通过迭代持续优化，核心是构建发现问题-测试修复-验证效果的有效闭环。