评估大语言模型 (LLMs) 是一个复杂的过程。LLMs 的输入和输出都是任意的文本，而我们设定的任务又各不相同。然而，严格而周密的评估至关重要——OpenAI 的技术领导者们在评估和提供反馈方面投诉了大量精力绝非偶然。
评估 LLM 应用程序的方式多种多样：有些人认为它像单元测试，有些人觉得它更类似于可观察性，还有人认为它就是数据科学的一部分。我们发现这些观点各有其价值。在接下来的部分中，我们将分享一些我们在构建评估和监控管道方面的重要经验教训。
创建基于断言（Assertion）的单元测试并使用真实输入/输出样本
创建由实际生产环境中的输入和输出样本组成的单元测试，并基于至少三个标准对输出进行预期。虽然三个标准看起来可能是任意的，但这是一个实际的起点；如果少于三个，可能表明你的任务定义不充分或过于开放，类似于一个通用聊天机器人的任务。这些单元测试或断言应在对流程管道进行任何更改时触发，无论是编辑提示、通过 RAG 添加新上下文，还是其他修改，本文提供了一个基于断言测试的实际用例示例。
可以从指定在所有响应中包含或排除的短语或思想的断言开始。还可以考虑检查字数、项目数或句子数是否在范围内。对于其他类型的生成，断言可能有所不同。“执行 - 评估方法”是一种强大的代码生成评估方法，其中你运行生成的代码并确定运行时的状态是否足够满足用户请求。
例如，如果用户要求一个名为 foo 的新函数；那么在执行智能体生成的代码后，foo 应该是可调用的！“执行-评估方法”的一个挑战是，智能体代码经常会使运行时状态与目标代码略有不同。将断言“放宽”到任何可行答案都会满足的最弱假设是有效的。
最后，按客户预期使用你的产品可以提供关于实际数据故障模式的见解。这种方法不仅有助于识别潜在的弱点，还提供了有用的生产样本，可以转换为评估。
LLM-as-Judge 可以工作，但它不是万能的
LLM-as-Judge 是指我们使用一个强大的大语言模型来评估其他大语言模型的输出，这种方法曾受到一些人的质疑。(我们中的一些人最初也持怀疑态度。) 然而，当这种方法实施得当时，LLM-as-Judge 能与人类的判断结果有相当好的相关性，并且至少能帮助我们预测新提示或技术的表现。具体来说，在进行成对比较 (例如，对照组与实验组) 时，LLM-as-Judge 通常能正确判断出结果的方向，尽管判断胜负的幅度可能会有些误差。
以下是一些充分利用 LLM-as-Judge 的建议：
使用成对比较：不要让大语言模型在 Likert 量表上对单个输出进行评分，而是给它呈现两个选项并让它选择较好的一个。这往往能带来更稳定的结果。
控制位置偏差：选项的呈现顺序会影响大语言模型的决策。为了减少这种偏差，每次成对比较时都交换选项的顺序进行两次。只要确保在交换后将胜利归因于正确的选项即可。
允许平局：在某些情况下，两种选项可能同样好。因此，允许大语言模型宣告平局，以避免其不得不随意选择一个优胜者。
使用 Chain-of-Thought 方法：在给出最终选择前，要求大语言模型解释其决策过程，这可以提高评估的可靠性。一个额外的好处是，你可以使用一个较弱但更快的大语言模型，仍能达到类似的结果。因为这一部分通常是在批处理模式下进行的，Chain-of-Thought 增加的延迟并不是问题。
控制回复长度：大语言模型倾向于偏向较长的回复。为了减少这种偏差，确保回复的长度相似。
LLM-as-Judge 的一个特别有用的应用是检查新的提示策略是否会出现退步。如果你记录了一些生产结果，有时可以用新的提示策略重新运行这些例子，并用 LLM-as-Judge 快速评估新策略的表现。
这里有一个简单但有效的例子，用于迭代 LLM-as-Judge。我们简单地记录大语言模型的回复、评判的解释 (即 Chain-of-Thought) 和最终结果。然后与相关利益者一起审查这些记录，以确定改进的领域。经过三次迭代，人类与大语言模型的判断一致性从 68% 提高到了 94%！
LLM-as-Judge 并非万能。在一些微妙的语言方面，即使是最强大的模型也无法进行可靠的评估。此外，我们发现传统分类器和奖励模型比 LLM-as-Judge 更准确，且成本更低、延迟更短。在代码生成方面，LLM-as-Judge 的表现可能不如直接执行代码的评估策略。
用于评估生成结果的“实习生测试”
我们在评估生成结果时喜欢使用“实习生测试”：如果你把给语言模型的确切输入，包括上下文，作为任务交给一个相关专业的普通大学生，他们能成功完成吗？需要多长时间？
如果答案是否定的，因为 LLM 缺乏所需的知识，可以考虑通过丰富上下文来解决。
如果答案是否定的，并且我们无法改进上下文来解决问题，那么这个任务可能对当前的 LLM 来说过于复杂。
如果答案是肯定的，但需要较长时间，我们可以尝试简化任务。任务是否可以被分解？某些部分是否可以模板化？
如果答案是肯定的，而且很快就能完成，那么就需要深入分析数据。模型出错的原因是什么？能找到失败的模式吗？可以尝试在模型响应前后让它解释自己的思路，以帮助我们理解模型的工作原理。
过分强调某些评估指标可能损害整体性能
一个例子是“针堆中的针 (NIAH)”评估。最初的评估是为了量化随着上下文规模的增加，模型的召回率及其受针的位置影响的程度。然而，这一评估被过分强调，以至于在 Gemini 1.5的报告中成为图 1 的内容。该评估方法是在一个包含多篇 Paul Graham 文章的长文档中插入一个特定短语 (“The special magic number is:”)，然后要求模型回忆出这个魔术数字。
尽管一些模型在此任务上表现出了近乎完美的召回率，但 NIAH 是否真正反映了实际应用中所需的推理和召回能力仍存疑问。考虑一个更实际的场景：如果给定一个长达一小时的会议记录，大语言模型能否总结出关键决策和后续步骤，并准确归因到相关人员？这一任务更加贴近现实，不仅需要死记硬背，还需要解析复杂讨论、识别关键信息并进行综合总结的能力。
这是一个实际应用中的NIAH评估的例子。使用医生与患者视频通话的记录，大语言模型被询问关于患者药物的信息。它还包括一个更具挑战性的 NIAH 评估，插入了一个关于随机披萨配料的短语，例如“制作完美披萨所需的秘密配料是：浓咖啡浸泡的枣子、柠檬和山羊奶酪。”在药物任务上的召回率约为 80%，而在披萨任务上的召回率约为 30%。
此外，过分强调 NIAH 评估可能会降低在信息提取和总结任务上的表现。由于这些大语言模型被微调到关注每一句话，它们可能会将无关的细节和干扰信息视为重要内容，从而在最终输出中包含这些信息 (实际上不应该包含它们)。
这种情况也可能适用于其他评估和使用场景。例如，在生成摘要时，过分强调事实一致性可能导致摘要内容不够具体 (因此不太可能在事实上一致) 并且可能不够相关。反之，过分强调写作风格和文采可能导致语言更加华丽，但同时可能引入事实上的不一致。
将标注任务简化为二元判断或成对比较
开放式反馈或用李克特量表 对模型输出进行评分，认知负担较大，导致数据因评估者间的差异而较为杂乱，降低了数据的可靠性。更有效的方法是简化任务，减轻标注者的认知负担，其中二元判断和成对比较是两种有效的方式。
在二元判断中，标注者只需对模型输出做简单的是或否判断，比如生成的摘要是否与源文档一致，回答是否相关，或是否包含有害内容。相比李克特量表，二元判断更精确、一致性更高、处理速度更快。这也是Doordash通过一系列是非问题标记菜单项的方法。
在成对比较中，标注者对比一对模型输出，判断哪个更好。人们更容易判断“A 比 B 好”而不是单独为 A 或 B 评分，因此这种方法比李克特量表更快更可靠。在Llama2见面会上，Llama2 论文作者 Thomas Scialom 证实，成对比较比收集监督微调数据更快更便宜，前者每单位成本为3.5，而后者为25。
如果你需要编写标注指南，可以参考这些来自 Google 和 Bing 搜索的 指南。
（无参考）评估和保护措施可以互换使用
保护措施有助于捕捉不适当或有害的内容，而评估则有助于衡量模型输出的质量和准确性。对于无参考评估而言，它们可以被视为一体两面。无参考评估是指不依赖于“标准”参考（例如人类编写的答案）的评估，能够仅基于输入提示和模型的响应来评估输出的质量。
例如，摘要评估中，我们只需考虑输入文档即可评估摘要在事实一致性和相关性方面的表现。如果摘要在这些指标上得分较低，我们可以选择不向用户展示它，有效地将评估作为保护措施。类似地，无参考的翻译评估 可以在不需要人工翻译参考的情况下评估翻译质量，同样允许我们将其作为保护措施使用。
大语言模型有时会在不该生成内容时生成输出
使用大语言模型时的一个主要挑战是，它们经常会在不该生成内容时生成输出。这可能导致无害但无意义的回答，或者更严重的问题如有害或危险的内容。例如，当被要求从文档中提取特定属性或元数据时，大语言模型可能自信地返回实际上并不存在的值。另外，由于我们在上下文中提供了非英语文档，模型可能会以非英语的语言作答。
尽管我们可以尝试提示大语言模型返回“不可用”或“未知”的回答，但这并非万无一失。即使有日志概率 (log probabilities) 可用，它们也无法准确指示输出质量。虽然日志概率显示了一个词元在输出中出现的可能性，但它们不一定反映生成文本的正确性。相反，对于那些经过指令微调 (instruction-tuned) 的模型，即训练来响应查询并生成连贯回答的模型，日志概率可能校准得不够好。因此，高日志概率可能意味着输出流畅且连贯，但不代表其准确或相关。
尽管精心设计的提示词工程 (prompt engineering) 在一定程度上有所帮助，但我们应该辅以强有力的保护措施来检测和过滤/再生不良输出。例如，OpenAI 提供了一个内容审核API，可以识别不安全的回答，如仇恨言论、自残或色情内容。同样，也有许多用于检测个人身份信息(PII)的软件包。一个好处是，保护措施在很大程度上与具体用例无关，因此可以广泛应用于特定语言的所有输出。此外，通过精确的检索，如果没有相关文档，我们的系统可以确定性地回答“我不知道”。
相应地，大语言模型有时在应该生成内容时却未能生成。这可能是由于各种原因，从 API 提供者的长尾延迟等简单问题到内容审核过滤器阻止输出等复杂问题。因此，持续记录输入和 (可能缺失的) 输出对于调试和监控非常重要。
幻觉问题难以解决
为了解决这一问题，我们可以结合提示工程（生成前）和事实不一致防护措施（生成后）。在提示工程中，使用如 CoT 这样的技术可以通过让大语言模型解释其推理过程，从而减少幻觉的产生。然后，我们可以应用一个事实不一致防护措施，来评估摘要的事实性，并过滤或重新生成幻觉。在某些情况下，幻觉可以通过确定性方法检测出来。当使用 RAG 检索的资源时，如果输出是结构化的并且标识了资源的来源，就可以手动验证这些资源是否来自输入的上下文。
参考链接：https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms-part-i/
