系统的评估与优化

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

评估 LLM 应用的方式

人工评估

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

准则二 多维评估

简单自动评估

方法一 构造客观题

方法二：计算答案相似度

使用大模型进行评估

混合评估

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

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

• 智能性。智能性指模型的回答是否足够拟人化。由于智能性与问题本身弱相关，与模型、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评估方法的优劣

使用人工评估准确度高、全面性强，但人力成本与时间成本高；使用自动评估成本低、评估速度快，但存在准确性不足、评估不够全面的问题。

总结

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

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