系统评估与优化
一、如何评估 LLM 应用
1.1 验证评估的一般思路
本章将逐个介绍大模型应用验证评估的一般方法，并设计本项目验证迭代的过程，从而实现应用功能的优化。但是由于系统评估与优化是一个与业务密切相关的话题，因此下文内容以理论介绍为主。
在使用LLM构建应用程序时，通常会经历以下流程：首先，你会在一到三个样本的小样本中调整 Prompt ，尝试使其在这些样本上起效。随后，当你对系统进行进一步测试时，可能会遇到一些棘手的例子，这些例子无法通过 Prompt 或者算法解决。这就是使用 LLM 构建应用程序的开发者所面临的挑战。在这种情况下，你可以将这些额外的几个例子添加到你正在测试的集合中，有机地添加其他难以处理的例子。最终，你会将足够多的这些例子添加到你逐步扩大的开发集中，以至于手动运行每一个例子以测试 Prompt 变得有些不便。然后，你开始开发一些用于衡量这些小样本集性能的指标，例如平均准确度。这个过程的有趣之处在于，如果你觉得你的系统已经足够好了，你可以随时停止，不再进行改进。实际上，很多已经部署的应用程序就在第一步或第二步就停下来了，而且它们运行得非常好。
首先介绍大模型开发评估的几种方法。对于有简单标准答案的任务来说，评估很容易得到实现；但大模型开发一般是需要实现复杂的生成任务，如何在没有简单答案甚至没有标准答案的情况下实现评估，能够准确地反映应用的效果，我们将简要介绍几种方法。
随着我们不断寻找到 Bad Case 并做出针对性优化，我们可以将这些 Bad Case 逐步加入到验证集，从而形成一个有一定样例数的验证集。针对这种验证集，一个一个进行评估就是不切实际的了。我们需要一种自动评估方法，实现对该验证集上性能的整体评估。
掌握了一般思路，我们会具体到基于 RAG 范式的大模型应用中来探究如何评估并优化应用性能。由于基于 RAG 范式开发的大模型应用一般包括两个核心部分：检索和生成。所以，我们的评估优化也会分别聚焦到这两个部分，分别以优化系统检索精度和在确定给定材料下的生成质量。
在每一个部分，我们都会首先介绍如何找出 Bad Case 的一些思路提示，以及针对 Bad Case 针对性做出检索优化或 Prompt 优化的一般思路。注意，在这一过程中，你应该时刻谨记我们在之前章节中所讲述的一系列大模型开发原则与技巧，并时刻保证优化后的系统不会在原先表现良好的样例上出现失误。
验证迭代是构建以 LLM 为中心的应用程序所必不能少的重要步骤，通过不断寻找 Bad Case，针对性调整 Prompt 或优化检索性能，来推动应用达到我们目标中的性能与精度。接下来，我们将简要介绍大模型开发评估的几种方法，并概括性介绍从少数 Bad Case 针对性优化到整体自动化评估的一般思路。
1.2 大模型评估方法
在具体的大模型应用开发中，我们可以找到 Bad Cases，并不断针对性优化 Prompt 或检索架构来解决 Bad Cases，从而优化系统的表现。我们会将找到的每一个 Bad Case 都加入到我们的验证集中，每一次优化之后，我们会重新对验证集中所有验证案例进行验证，从而保证优化后的系统不会在原有 Good Case 上失去能力或表现降级。
当验证集体量较小时，我们可以采用人工评估的方法，即对验证集中的每一个验证案例，人工评估系统输出的优劣；但是，当验证集随着系统的优化而不断扩张，其体量会不断增大，以至于人工评估的时间和人力成本扩大到我们无法接受的程度。因此，我们需要采用自动评估的方法，自动评估系统对每一个验证案例的输出质量，从而评估系统的整体性能。
1.2.1 人工评估的一般思路
在系统开发的初期，验证集体量较小，最简单、直观的方法即为人工对验证集中的每一个验证案例进行评估。但是，人工评估也有一些基本准则与思路，此处简要介绍供学习者参考。但请注意，系统的评估与业务强相关，设计具体的评估方法与维度需要结合具体业务深入考虑。
（1）准则一 量化评估
为保证很好地比较不同版本的系统性能，量化评估指标是非常必要的。我们应该对每一个验证案例的回答都给出打分，最后计算所有验证案例的平均分得到本版本系统的得分。量化的量纲可以是05，也可以是0100，可以根据个人风格和业务实际情况而定。
量化后的评估指标应当有一定的评估规范，例如在满足条件 A 的情况下可以打分为 y 分，以保证不同评估员之间评估的相对一致。
（2）准则二 多维评估
大模型是典型的生成模型，即其回答为一个由模型生成的语句。一般而言，大模型的回答需要在多个维度上进行评估。例如，本项目的个人知识库问答项目上，用户提问一般是针对个人知识库的内容进行提问，模型的回答需要同时满足充分使用个人知识库内容、答案与问题一致、答案真实有效、回答语句通顺等。一个优秀的问答助手，应当既能够很好地回答用户的问题，保证答案的正确性，又能够体现出充分的智能性。
因此，我们往往需要从多个维度出发，设计每个维度的评估指标，在每个维度上都进行打分，从而综合评估系统性能。同时需要注意的是，多维评估应当和量化评估有效结合，对每一个维度，可以设置相同的量纲也可以设置不同的量纲，应充分结合业务实际。
例如，在本项目中，我们可以设计如下几个维度的评估：
① 知识查找正确性。该维度需要查看系统从向量数据库查找相关知识片段的中间结果，评估系统查找到的知识片段是否能够对问题做出回答。该维度为0-1评估，即打分为0指查找到的知识片段不能做出回答，打分为1指查找到的知识片段可以做出回答。
② 回答一致性。该维度评估系统的回答是否针对用户问题展开，是否有偏题、错误理解题意的情况，该维度量纲同样设计为0~1，0为完全偏题，1为完全切题，中间结果可以任取。
③ 回答幻觉比例。该维度需要综合系统回答与查找到的知识片段，评估系统的回答是否出现幻觉，幻觉比例有多高。该维度同样设计为0~1,0为全部是模型幻觉，1为没有任何幻觉。
④ 回答正确性。该维度评估系统回答是否正确，是否充分解答了用户问题，是系统最核心的评估指标之一。该维度可以在0~1之间任意打分。
上述四个维度都围绕知识、回答的正确性展开，与问题高度相关；接下来几个维度将围绕大模型生成结果的拟人性、语法正确性展开，与问题相关性较小：
⑤ 逻辑性。该维度评估系统回答是否逻辑连贯，是否出现前后冲突、逻辑混乱的情况。该维度为0-1评估。
⑥ 通顺性。该维度评估系统回答是否通顺、合乎语法，可以在0~1之间任意打分。
⑦ 智能性。该维度评估系统回答是否拟人化、智能化，是否能充分让用户混淆人工回答与智能回答。该维度可以在0~1之间任意打分。
综合上述七个维度，我们可以全面、综合地评估系统在每个案例上的表现，综合考虑所有案例的得分，就可以评估系统在每个维度的表现。如果将所有维度量纲统一，那么我们还可以计算所有维度的平均得分来评估系统的得分。我们也可以针对不同维度的不同重要性赋予权值，再计算所有维度的加权平均来代表系统得分。
但是，我们可以看到，越全面、具体的评估，其评估难度、评估成本就越大。以上述七维评估为例，对系统每一个版本的每一个案例，我们都需要进行七次评估。如果我们有两个版本的系统，验证集中有10个验证案例，那么我们每一次评估就需要 $ 10 \times 2 \times 7 = 140$ 次；但当我们的系统不断改进迭代，验证集会迅速扩大，一般来说，一个成熟的系统验证集应该至少在几百的体量，迭代改进版本至少有数十个，那么我们评估的总次数会达到上万次，带来的人力成本与时间成本就很高了。因此，我们需要一种自动评估模型回答的方法。
1.2.2 简单自动评估
大模型评估之所以复杂，一个重要原因在于生成模型的答案很难判别，即客观题评估判别很简单，主观题评估判别则很困难。尤其是对于一些没有标准答案的问题，实现自动评估就显得难度尤大。但是，在牺牲一定评估准确性的情况下，我们可以将复杂的没有标准答案的主观题进行转化，从而变成有标准答案的问题，进而通过简单的自动评估来实现。此处介绍两种方法：构造客观题与计算标准答案相似度。
（1）方法一 构造客观题
主观题的评估是非常困难的，但是客观题可以直接对比系统答案与标准答案是否一致，从而实现简单评估。我们可以将部分主观题构造为多项或单项选择的客观题，进而实现简单评估。
例子见如何评估 LLM 应用
这样我们就可以实现快速、自动又有区分度的自动评估。在这样的方法下，我们只需对每一个验证案例进行构造，之后每一次验证、迭代都可以完全自动化进行，从而实现了高效的验证。
但是，不是所有的案例都可以构造为客观题，针对一些不能构造为客观题或构造为客观题会导致题目难度骤降的情况，我们需要用到第二种方法：计算答案相似度。
（2）方法二：计算答案相似度
生成问题的答案评估在 NLP 中实则也不是一个新问题了，不管是机器翻译、自动文摘等任务，其实都需要评估生成答案的质量。NLP 一般对生成问题采用人工构造标准答案并计算回答与标准答案相似度的方法来实现自动评估。
例子见如何评估 LLM 应用
可以发现，答案与标准答案一致性越高，则评估打分就越高。通过此种方法，我们同样只需对验证集中每一个问题构造一个标准答案，之后就可以实现自动、高效的评估。
但是，该种方法同样存在几个问题：① 需要人工构造标准答案。对于一些垂直领域而言，构造标准答案可能是一件困难的事情；② 通过相似度来评估，可能存在问题。例如，如果生成回答与标准答案高度一致但在核心的几个地方恰恰相反导致答案完全错误，bleu 得分仍然会很高；③ 通过计算与标准答案一致性灵活性很差，如果模型生成了比标准答案更好的回答，但评估得分反而会降低；④ 无法评估回答的智能性、流畅性。如果回答是各个标准答案中的关键词拼接出来的，我们认为这样的回答是不可用无法理解的，但 bleu 得分会较高。
因此，针对业务情况，有时我们还需要一些不需要构造标准答案的、进阶的评估方法。
1.2.3 使用大模型进行评估
使用人工评估准确度高、全面性强，但人力成本与时间成本高；使用自动评估成本低、评估速度快，但存在准确性不足、评估不够全面的问题。那么，我们是否有一种方法综合两者的优点，实现快速、全面的生成问题评估呢？
以 GPT-4 为代表的大模型为我们提供了一种新的方法：使用大模型进行评估。我们可以通过构造 Prompt Engineering 让大模型充当一个评估者的角色，从而替代人工评估的评估员；同时大模型可以给出类似于人工评估的结果，因此可以采取人工评估中的多维度量化评估的方式，实现快速全面的评估。
例子见如何评估 LLM 应用
但是注意，使用大模型进行评估仍然存在问题：
① 我们的目标是迭代改进 Prompt 以提升大模型表现，因此我们所选用的评估大模型需要有优于我们所使用的大模型基座的性能，例如，目前性能最强大的大模型仍然是 GPT-4，推荐使用 GPT-4 来进行评估，效果最好。
② 大模型具有强大的能力，但同样存在能力的边界。如果问题与回答太复杂、知识片段太长或是要求评估维度太多，即使是 GPT-4 也会出现错误评估、错误格式、无法理解指令等情况，针对这些情况，我们建议考虑如下方案来提升大模型表现：
1、改进 Prompt Engineering。以类似于系统本身 Prompt Engineering 改进的方式，迭代优化评估 Prompt Engineering，尤其是注意是否遵守了 Prompt Engineering 的基本准则、核心建议等；
2、拆分评估维度。如果评估维度太多，模型可能会出现错误格式导致返回无法解析，可以考虑将待评估的多个维度拆分，每个维度调用一次大模型进行评估，最后得到统一结果；
3、合并评估维度。如果评估维度太细，模型可能无法正确理解以至于评估不正确，可以考虑将待评估的多个维度合并，例如，将逻辑性、通顺性、智能性合并为智能性等；
4、提供详细的评估规范。如果没有评估规范，模型很难给出理想的评估结果。可以考虑给出详细、具体的评估规范，从而提升模型的评估能力；
5、提供少量示例。模型可能难以理解评估规范，此时可以给出少量评估的示例，供模型参考以实现正确评估。
1.2.4 混合评估
事实上，上述评估方法都不是孤立、对立的，相较于独立地使用某一种评估方法，我们更推荐将多种评估方法混合起来，对于每一种维度选取其适合的评估方法，兼顾评估的全面、准确和高效。
例如，针对本项目个人知识库助手，我们可以设计以下混合评估方法：
1、客观正确性。客观正确性指对于一些有固定正确答案的问题，模型可以给出正确的回答。我们可以选取部分案例，使用构造客观题的方式来进行模型评估，评估其客观正确性。
2、主观正确性。主观正确性指对于没有固定正确答案的主观问题，模型可以给出正确的、全面的回答。我们可以选取部分案例，使用大模型评估的方式来评估模型回答是否正确。
3、智能性。智能性指模型的回答是否足够拟人化。由于智能性与问题本身弱相关，与模型、Prompt 强相关，且模型判断智能性能力较弱，我们可以少量抽样进行人工评估其智能性。
4、知识查找正确性。知识查找正确性指对于特定问题，从知识库检索到的知识片段是否正确、是否足够回答问题。知识查找正确性推荐使用大模型进行评估，即要求模型判别给定的知识片段是否足够回答问题。同时，该维度评估结果结合主观正确性可以计算幻觉情况，即如果主观回答正确但知识查找不正确，则说明产生了模型幻觉。
二、评估并优化生成部分
在前面的章节中，我们讲到了如何评估一个基于 RAG 框架的大模型应用的整体性能。通过针对性构造验证集，可以采用多种方法从多个维度对系统性能进行评估。但是，评估的目的是为了更好地优化应用效果，要优化应用性能，我们需要结合评估结果，对评估出的 Bad Case 进行拆分，并分别对每一部分做出评估和优化。
RAG 全称为检索增强生成，因此，其有两个核心部分：检索部分和生成部分。检索部分的核心功能是保证系统根据用户 query 能够查找到对应的答案片段，而生成部分的核心功能即是保证系统在获得了正确的答案片段之后，可以充分发挥大模型能力生成一个满足用户要求的正确回答。
优化一个大模型应用，我们往往需要从这两部分同时入手，分别评估检索部分和优化部分的性能，找出 Bad Case 并针对性进行性能的优化。而具体到生成部分，在已限定使用的大模型基座的情况下，我们往往会通过优化 Prompt Engineering 来优化生成的回答。在本章中，我们将首先结合我们刚刚搭建出的大模型应用实例——个人知识库助手，向大家讲解如何评估分析生成部分性能，针对性找出 Bad Case，并通过优化 Prompt Engineering 的方式来优化生成部分。
2.1 提升直观回答质量
寻找 Bad Case 的思路有很多，最直观也最简单的就是评估直观回答的质量，结合原有资料内容，判断在什么方面有所不足。例子见评估并优化生成部分
提升回答质量的方法还有很多，核心是围绕具体业务展开思考，找出初始回答中不足以让人满意的点，并针对性进行提升改进，此处不再赘述。
2.2 标明知识来源，提高可信度
由于大模型存在幻觉问题，有时我们会怀疑模型回答并非源于已有知识库内容，这对一些需要保证真实性的场景来说尤为重要。例子见评估并优化生成部分
但是，附上原文来源往往会导致上下文的增加以及回复速度的降低，我们需要根据业务场景酌情考虑是否要求附上原文。
2.3 构造思维链
大模型往往可以很好地理解并执行指令，但模型本身还存在一些能力的限制，例如大模型的幻觉、无法理解较为复杂的指令、无法执行复杂步骤等。我们可以通过构造思维链，将 Prompt 构造成一系列步骤来尽量减少其能力限制，例如，我们可以构造一个两步的思维链，要求模型在第二步做出反思，以尽可能消除大模型的幻觉问题。例子见评估并优化生成部分
要求模型做出自我反思之后，模型修复了自己的幻觉，给出了正确的答案。我们还可以通过构造思维链完成更多功能，此处就不再赘述了，欢迎读者尝试。
2.4 增加一个指令解析
我们往往会面临一个需求，即我们需要模型以我们指定的格式进行输出。但是，由于我们使用了 Prompt Template 来填充用户问题，用户问题中存在的格式要求往往会被忽略。例子见评估并优化生成部分
经过如上步骤，我们就成功地实现了输出格式的限定。当然，在上面代码中，核心为介绍 Agent 思想，事实上，不管是 Agent 机制还是 Parser 机制（也就是限定输出格式），LangChain 都提供了成熟的工具链供使用，欢迎感兴趣的读者深入探讨，此处就不展开讲解了。
通过上述讲解的思路，结合实际业务情况，我们可以不断发现 Bad Case 并针对性优化 Prompt，从而提升生成部分的性能。但是，上述优化的前提是检索部分能够检索到正确的答案片段，也就是检索的准确率和召回率尽可能高。那么，如何能够评估并优化检索部分的性能呢？下一章我们会深入探讨这个问题。
三、评估并优化检索部分
在上一章，我们讲解了如何针对生成部分评估优化 Prompt Engineering，来提高大模型的生成质量。但生成的前提是检索，只有当我们应用的检索部分能够根据用户 query 检索到正确的答案文档时，大模型的生成结果才可能是正确的。因此，检索部分的检索精确率和召回率其实更大程度影响了应用的整体性能。但是，检索部分的优化是一个更工程也更深入的命题，我们往往需要使用到很多高级的、源于搜索的进阶技巧并探索更多实用工具，甚至手写一些工具来进行优化。因此，在本章中，我们仅大致讨论检索部分评估与优化的思路，而不深入展开代码实践。
3.1 评估检索效果
详见评估检索效果
3.2 优化检索的思路
上文陈述来评估检索效果的几种一般思路，当我们对系统的检索效果做出合理评估，找到对应的 Bad Case 之后，我们就可以将 Bad Case 拆解到多个维度来针对性优化检索部分。注意，虽然在上文评估部分，我们强调了评估检索效果的验证 query 一定要保证其正确答案存在于知识库之中，但是在此处，我们默认知识库构建也作为检索部分的一部分，因此，我们也需要在这一部分解决由于知识库构建有误带来的 Bad Case。在此，我们分享一些常见的 Bad Case 归因和可行的优化思路。
3.2.1 知识片段被割裂导致答案丢失
该问题一般表现为，对于一个用户 query，我们可以确定其问题一定是存在于知识库之中的，但是我们发现检索到的知识片段将正确答案分割开了，导致不能形成一个完整、合理的答案。该种问题在需要较长回答的 query 上较为常见。
该类问题的一般优化思路是，优化文本切割方式。我们在《C3 搭建知识库》中使用到的是最原始的分割方式，即根据特定字符和 chunk 大小进行分割，但该类分割方式往往不能照顾到文本语义，容易造成同一主题的强相关上下文被切分到两个 chunk 总。对于一些格式统一、组织清晰的知识文档，我们可以针对性构建更合适的分割规则；对于格式混乱、无法形成统一的分割规则的文档，我们可以考虑纳入一定的人力进行分割。我们也可以考虑训练一个专用于文本分割的模型，来实现根据语义和主题的 chunk 切分。
3.2.2 query 提问需要长上下文概括回答
该问题也是存在于知识库构建的一个问题。即部分 query 提出的问题需要检索部分跨越很长的上下文来做出概括性回答，也就是需要跨越多个 chunk 来综合回答问题。但是由于模型上下文限制，我们往往很难给出足够的 chunk 数。
该类问题的一般优化思路是，优化知识库构建方式。针对可能需要此类回答的文档，我们可以增加一个步骤，通过使用 LLM 来对长文档进行概括总结，或者预设提问让 LLM 做出回答，从而将此类问题的可能答案预先填入知识库作为单独的 chunk，来一定程度解决该问题。
3.2.3 关键词误导
该问题一般表现为，对于一个用户 query，系统检索到的知识片段有很多与 query 强相关的关键词，但知识片段本身并非针对 query 做出的回答。这种情况一般源于 query 中有多个关键词，其中次要关键词的匹配效果影响了主要关键词。
该类问题的一般优化思路是，对用户 query 进行改写，这也是目前很多大模型应用的常用思路。即对于用户输入 query，我们首先通过 LLM 来将用户 query 改写成一种合理的形式，去除次要关键词以及可能出现的错字、漏字的影响。具体改写成什么形式根据具体业务而定，可以要求 LLM 对 query 进行提炼形成 Json 对象，也可以要求 LLM 对 query 进行扩写等。
3.2.4 匹配关系不合理
该问题是较为常见的，即匹配到的强相关文本段并没有包含答案文本。该问题的核心问题在于，我们使用的向量模型和我们一开始的假设不符。在讲解 RAG 的框架时，我们有提到，RAG 起效果是有一个核心假设的，即我们假设我们匹配到的强相关文本段就是问题对应的答案文本段。但是很多向量模型其实构建的是“配对”的语义相似度而非“因果”的语义相似度，例如对于 query-“今天天气怎么样”，会认为“我想知道今天天气”的相关性比“天气不错”更高。
该类问题的一般优化思路是，优化向量模型或是构建倒排索引。我们可以选择效果更好的向量模型，或是收集部分数据，在自己的业务上微调一个更符合自己业务的向量模型。我们也可以考虑构建倒排索引，即针对知识库的每一个知识片段，构建一个能够表征该片段内容但和 query 的相对相关性更准确的索引，在检索时匹配索引和 query 的相关性而不是全文，从而提高匹配关系的准确性。
优化检索部分的思路还有很多，事实上，检索部分的优化往往是 RAG 应用开发的核心工程部分。
本文内容来源于Datawhale的llm-universe项目
