【LLM】系统的评估与优化

参考文章
BLEU：一种自动评估机器翻译的方法

系统的评估与优化

大型语言模型(LLM)展现出了杰出的性能，并为我们提供了新的解题思路。但在实际应用过程中，如何评估大型语言模型的输出质量对于我们来说也至关重要。因为大模型的输出是概率性的—这意味着同样的Prompt产生的结果都有可能不同，大模型评估能够衡量模型输出的质量水平，能够确保用户的体验。

评估 LLM 应用的方式

人工评估

准则一 量化评估
为保证很好地比较不同版本的系统性能，量化评估指标是非常必要的。我们应该对每一个验证案例的回答都给出打分，最后计算所有验证案例的平均分得到本版本系统的得分。

准则二 多维评估
一般而言，大模型的回答需要在多个维度上进行评估。例如，本项目的个人知识库问答项目上，用户提问一般是针对个人知识库的内容进行提问，模型的回答需要同时满足充分使用个人知识库内容、答案与问题一致、答案真实有效、回答语句通顺等。一个优秀的问答助手，应当既能够很好地回答用户的问题，保证答案的正确性，又能够体现出充分的智能性。

① 知识查找正确性

② 回答一致性

③ 回答幻觉比例

④ 回答正确性

⑤ 逻辑性

⑥ 通顺性

⑦ 智能性

可以从上面的维度对LLM的回答进行评分。

简单自动评估

方法一 构造客观题

为了能使用代码进行自动评估，因此需要构建客观题，让LLM的回答在确定的选项中，这样可以设计一个打分策略，进而实现自动评估。下面的实现客观题回答自动评估的参考示例代码：
注意，设计策略时候有个特殊点，如果LLM生成答案出现了错误答案和不选都评0分的话，那么LLM可能会生成幻读，这样不利于用户使用。因此评分策略中“生成答案出现了错误答案”评-1分，“不选”评0分，这样的评分策略就不会鼓励模型的幻觉回答。

def multi_select_score_v2(true_answer : str, generate_answer : str) -> float:
    # true_anser : 正确答案，str 类型，例如 'BCD'
    # generate_answer : 模型生成答案，str 类型
    true_answers = list(true_answer)
    '''为便于计算，我们假设每道题都只有 A B C D 四个选项'''
    # 先找出错误答案集合
    false_answers = [item for item in ['A', 'B', 'C', 'D'] if item not in true_answers]
    # 如果生成答案出现了错误答案
    for one_answer in false_answers:
        if one_answer in generate_answer:
            return -1
    # 再判断是否全选了正确答案
    if_correct = 0
    for one_answer in true_answers:
        if one_answer in generate_answer:
            if_correct += 1
            continue
    if if_correct == 0:
        # 不选
        return 0
    elif if_correct == len(true_answers):
        # 全选
        return 1
    else:
        # 漏选
        return 0.5

方法二：计算答案相似度
有一些问题是不方便构建客观题的，如：南瓜书的目标是什么？
因此我们需要采用计算答案相似度的方法进行自动评分，事前确定一个标准答案，通过计算LLM回答和标准答案的相似度确定评分。

通过计算答案相似度的方法有几个缺点：
① 需要人工构造标准答案。对于一些垂直领域而言，构造标准答案可能是一件困难的事情；
② 通过相似度来评估，可能存在问题。例如，如果生成回答与标准答案高度一致但在核心的几个地方恰恰相反导致答案完全错误，bleu 得分仍然会很高；
③ 通过计算与标准答案一致性灵活性很差，如果模型生成了比标准答案更好的回答，但评估得分反而会降低；
④ 无法评估回答的智能性、流畅性。如果回答是各个标准答案中的关键词拼接出来的，我们认为这样的回答是不可用无法理解的，但 bleu 得分会较高。

使用大模型进行评估

使用人工评估准确度高、全面性强，但人力成本与时间成本高；使用自动评估成本低、评估速度快，但存在准确性不足、评估不够全面的问题。那么，我们是否有一种方法综合两者的优点，实现快速、全面的生成问题评估呢？

以 GPT-4 为代表的大模型为我们提供了一种新的方法：使用大模型进行评估。我们可以通过构造 Prompt Engineering 让大模型充当一个评估者的角色，从而替代人工评估的评估员；同时大模型可以给出类似于人工评估的结果，因此可以采取人工评估中的多维度量化评估的方式，实现快速全面的评估。

① 我们的目标是迭代改进 Prompt 以提升大模型表现，因此我们所选用的评估大模型需要有优于我们所使用的大模型基座的性能，例如，目前性能最强大的大模型仍然是 GPT-4，推荐使用 GPT-4 来进行评估，效果最好。

② 大模型具有强大的能力，但同样存在能力的边界。如果问题与回答太复杂、知识片段太长或是要求评估维度太多，即使是 GPT-4 也会出现错误评估、错误格式、无法理解指令等情况，针对这些情况，我们建议考虑如下方案来提升大模型表现：

改进 Prompt Engineering。以类似于系统本身 Prompt Engineering 改进的方式，迭代优化评估 Prompt Engineering，尤其是注意是否遵守了 Prompt Engineering 的基本准则、核心建议等；

拆分评估维度。如果评估维度太多，模型可能会出现错误格式导致返回无法解析，可以考虑将待评估的多个维度拆分，每个维度调用一次大模型进行评估，最后得到统一结果；

合并评估维度。如果评估维度太细，模型可能无法正确理解以至于评估不正确，可以考虑将待评估的多个维度合并，例如，将逻辑性、通顺性、智能性合并为智能性等；

提供详细的评估规范。如果没有评估规范，模型很难给出理想的评估结果。可以考虑给出详细、具体的评估规范，从而提升模型的评估能力；

提供少量示例。模型可能难以理解评估规范，此时可以给出少量评估的示例，供模型参考以实现正确评估。

混合评估

• 客观正确性。客观正确性指对于一些有固定正确答案的问题，模型可以给出正确的回答。我们可以选取部分案例，使用构造客观题的方式来进行模型评估，评估其客观正确性。

• 主观正确性。主观正确性指对于没有固定正确答案的主观问题，模型可以给出正确的、全面的回答。我们可以选取部分案例，使用大模型评估的方式来评估模型回答是否正确。

• 智能性。智能性指模型的回答是否足够拟人化。由于智能性与问题本身弱相关，与模型、Prompt 强相关，且模型判断智能性能力较弱，我们可以少量抽样进行人工评估其智能性。

• 知识查找正确性。知识查找正确性指对于特定问题，从知识库检索到的知识片段是否正确、是否足够回答问题。知识查找正确性推荐使用大模型进行评估，即要求模型判别给定的知识片段是否足够回答问题。同时，该维度评估结果结合主观正确性可以计算幻觉情况，即如果主观回答正确但知识查找不正确，则说明产生了模型幻觉。

评估并优化生成部分

RAG 全称为检索增强生成，其有两个核心部分：检索部分和生成部分。检索部分的核心功能是保证系统根据用户 query 能够查找到对应的答案片段，而生成部分的核心功能即是保证系统在获得了正确的答案片段之后，可以充分发挥大模型能力生成一个满足用户要求的正确回答。

提升直观回答质量

1. 编写清晰、具体的指令是构造 Prompt 的第一原则。Prompt需要明确表达需求，提供充足上下文，使语言模型准确理解意图。过于简略的Prompt会使模型难以完成任务。

2. 给予模型充足思考时间是构造Prompt的第二原则。语言模型需要时间推理和解决复杂问题，匆忙得出的结论可能不准确。因此，Prompt应该包含逐步推理的要求，让模型有足够时间思考，生成更准确的结果。

3. 在设计Prompt时，要指定完成任务所需的步骤。通过给定一个复杂任务，给出完成任务的一系列步骤，可以帮助模型更好地理解任务要求，提高任务完成的效率。

4. 迭代优化是构造Prompt的常用策略。通过不断尝试、分析结果、改进Prompt的过程，逐步逼近最优的Prompt形式。成功的Prompt通常是通过多轮调整得出的。

5. 添加表格描述是优化Prompt的一种方法。要求模型抽取信息并组织成表格，指定表格的列、表名和格式，可以帮助模型更好地理解任务，并生成符合预期的结果。

总之，构造Prompt的原则包括清晰具体的指令、给予模型充足思考时间、指定完成任务所需的步骤、迭代优化和添加表格描述等。这些原则可以帮助开发者设计出高效、可靠的Prompt，发挥语言模型的最大潜力。

标明知识来源，提高可信度

构造思维链

增加一个指令解析

评估并优化检索部分

评估检索效果

优化检索的思路

1. 知识片段被割裂导致答案丢失
   该问题一般表现为，对于一个用户 query，我们可以确定其问题一定是存在于知识库之中的，但是我们发现检索到的知识片段将正确答案分割开了，导致不能形成一个完整、合理的答案。该种问题在需要较长回答的 query 上较为常见。

该类问题的一般优化思路是，优化文本切割方式。我们在《C3 搭建知识库》中使用到的是最原始的分割方式，即根据特定字符和 chunk 大小进行分割，但该类分割方式往往不能照顾到文本语义，容易造成同一主题的强相关上下文被切分到两个 chunk 总。对于一些格式统一、组织清晰的知识文档，我们可以针对性构建更合适的分割规则；对于格式混乱、无法形成统一的分割规则的文档，我们可以考虑纳入一定的人力进行分割。我们也可以考虑训练一个专用于文本分割的模型，来实现根据语义和主题的 chunk 切分。

2. query 提问需要长上下文概括回答
   该问题也是存在于知识库构建的一个问题。即部分 query 提出的问题需要检索部分跨越很长的上下文来做出概括性回答，也就是需要跨越多个 chunk 来综合回答问题。但是由于模型上下文限制，我们往往很难给出足够的 chunk 数。

该类问题的一般优化思路是，优化知识库构建方式。针对可能需要此类回答的文档，我们可以增加一个步骤，通过使用 LLM 来对长文档进行概括总结，或者预设提问让 LLM 做出回答，从而将此类问题的可能答案预先填入知识库作为单独的 chunk，来一定程度解决该问题。

3. 关键词误导
   该问题一般表现为，对于一个用户 query，系统检索到的知识片段有很多与 query 强相关的关键词，但知识片段本身并非针对 query 做出的回答。这种情况一般源于 query 中有多个关键词，其中次要关键词的匹配效果影响了主要关键词。

该类问题的一般优化思路是，对用户 query 进行改写，这也是目前很多大模型应用的常用思路。即对于用户输入 query，我们首先通过 LLM 来将用户 query 改写成一种合理的形式，去除次要关键词以及可能出现的错字、漏字的影响。具体改写成什么形式根据具体业务而定，可以要求 LLM 对 query 进行提炼形成 Json 对象，也可以要求 LLM 对 query 进行扩写等。

4. 匹配关系不合理
   该问题是较为常见的，即匹配到的强相关文本段并没有包含答案文本。该问题的核心问题在于，我们使用的向量模型和我们一开始的假设不符。在讲解 RAG 的框架时，我们有提到，RAG 起效果是有一个核心假设的，即我们假设我们匹配到的强相关文本段就是问题对应的答案文本段。但是很多向量模型其实构建的是“配对”的语义相似度而非“因果”的语义相似度，例如对于 query-“今天天气怎么样”，会认为“我想知道今天天气”的相关性比“天气不错”更高。

该类问题的一般优化思路是，优化向量模型或是构建倒排索引。我们可以选择效果更好的向量模型，或是收集部分数据，在自己的业务上微调一个更符合自己业务的向量模型。我们也可以考虑构建倒排索引，即针对知识库的每一个知识片段，构建一个能够表征该片段内容但和 query 的相对相关性更准确的索引，在检索时匹配索引和 query 的相关性而不是全文，从而提高匹配关系的准确性。

思考

对比各种LLM评估方法的优劣

人工评估
使用人工评估准确度高、全面性强，但人力成本与时间成本高；使用自动评估成本低、评估速度快，但存在准确性不足、评估不够全面的问题。人工评估可以说是最可靠的，但实施起来最慢、最昂贵，尤其是当需要高技能的人类专家时。试图收集人类评估是非常有趣的，但只能根据他们的一般技能提供模型排名。这使得它们在特定于任务的模型选择中不那么有用。

简单自动评估
简单自动评估可以减少时间成本，通过构建客观题或计算答案相似度完成，但是需要事先定义好打分策略，或确定标准参考答案。生成回答与标准答案高度一致但在核心的几个地方恰恰相反导致答案完全错误，bleu 得分仍然会很高，这样也会导致结果适得其反。

使用大模型进行评估
大模型评估综合上述两者的优点，实现快速、全面的生成问题评估。通过构造 Prompt Engineering 让大模型充当一个评估者的角色，从而替代人工评估的评估员；同时大模型可以给出类似于人工评估的结果，因此可以采取人工评估中的多维度量化评估的方式，实现快速全面的评估。
使用大模型进行评估对模型有要求，评估的模型的专业性应当优于测评LLM，这样的评估才有说服力。

总结

本节学习了大模型的常见评估方法：人工评估、简单自动评估、大模型评估和混合评估，其中人工评估耗费人力成本高，且需要确定量化评估指标、从多个维度进行评估。简单自动评估通过构建客观题让LLM进行回答，并且用代码方式实现打分策略，因此实现完全自动化，从而实现了高效的验证。对于无法构建客观题的问题，可以通过计算答案相似度方法进行评分，具体实现原理：对生成问题采用人工构造标准答案并计算回答与标准答案相似度的方法来实现自动评估。使用大模型评估，可以通过构造 Prompt Engineering 让大模型充当一个评估者的角色，从而减少人工评估带来的时间成本、人力成本，并且大模型所生成的参考回答具有一定标准代表性，可以用带充当计算向量相似度的参考回答。本节以构建知识库助手举例混合评估的方法。
RAG 全称为检索增强生成，其有两个核心部分：检索部分和生成部分。检索部分的核心功能是保证系统根据用户 query 能够查找到对应的答案片段，而生成部分的核心功能即是保证系统在获得了正确的答案片段之后，可以充分发挥大模型能力生成一个满足用户要求的正确回答。
对于生成部分的优化，可以从提升prompt质量入手，确定初次回答存在不足的地方（找出bad case），修改prompt模版，使得LLM的回答更贴合用户体验。除此之外，还可以在prompt中增加可信的参考知识，供LLM总结回答，从而减少幻觉。构造思维链也是一个很好获取优质答案的方式，通过LLM独有的推理能力，可以将问题进行拆分提问，这样LLM可以结合多个问题的答案（上下文对话内容）进行反思，以尽可能消除大模型的幻觉问题。指令解析能加强LLM的回答，让回答内容不再受限于文字方面，还可以是一些api的操作（结合api能力就是大模型的agent了）。
在检索部分，评估标准可以为准确率，通过对比检索得到的K个答案是否包含正确答案来衡量系统的检索能力。优化方法有多种，在向量数据库一节中对知识库的文本知识预处理（去除特殊符号、设计合适的chuck、切分句子时保存共有前后缀）；去除prompt次要关键词干扰；设计回答的倒排索引。
听说即将推出的第二部分《LLM 开发技巧》，很期待会出现什么好玩的内容。

【提问】为什么本节大纲先讲解’评估并优化生成部分’，再到’评估并优化检索部分’。
RAG 全称为检索增强生成，不是应该先有检索部分、再有生成增强部分嘛。