如何评估大型语言模型应用-CSDN博客

本文链接：https://blog.csdn.net/qianggezhishen/article/details/140963039

现在，很多公司都在用一种特别厉害的工具——大型语言模型（LLMs），来让自己的产品和公司内部的工作方式变得更先进。这些工具就像是全新的电脑，让软件开发的工作变得更不一样，能做的事儿也越来越多。

但是，要让这些大型语言模型在实际工作中发挥好作用，我们得先对它们的表现心里有数。这对很多公司来说挺难的，因为这些模型都是新玩意儿，用起来复杂，而且评价它们的好坏不像以前那么简单，有时候还容易出些让人尴尬的错误。

这篇文章就是想聊聊怎么看这些大型语言模型的表现，分享一下我见过的一些在实际工作中效果不错的方法。

LLMs 不是你需要的全部

首先，我们得明白，当我们在工作中用到大型语言模型（LLMs）的时候，我们到底在评估什么。随着这些模型越来越牛，我们就得花更多精力去确保它们有足够的信息和权限去完成任务。

想象一下，就像给一个超级聪明的机器人安排工作，你得告诉它需要做什么，还得给它提供所有需要的信息和工具。

对于现在这些厉害的模型来说，任何一个用到LLM的应用基本上都是由下面这些东西组成的：

LLM模型：就像机器人的大脑，用来思考和解决问题。这个大脑可能是OpenAI、Anthropic、Google提供的，或者也可能是一些开源的替代品。
提示模板（Prompt template）：这就是给机器人的基本指令，每次工作的时候都会用到，就像食谱一样，需要按步骤来。
数据源(Data sources)：这就是给机器人提供信息的地方，比如数据库，可以是传统的，也可以是更高级的图形或者向量数据库。
内存：这就像是机器人的记忆，可以记住之前的交互，下次再用的时候就可以更快更好地完成任务。
工具(APIs/Tools)：这就是给机器人提供的一些特殊能力，比如让它能够调用其他软件或者执行一些代码。
代理控制流(Agent Control flow)：这就像是给机器人的工作流程，让它知道怎么一步步完成任务。
护栏(Guardrails)：这就是在机器人给出答案之前的最后一道检查，确保它给出的东西是对的，如果发现有问题，可能就需要人工来介入了。

就像这样，我们得确保每个部分都配合得很好，这样LLMs才能在工作中发挥最大的作用。

LLM应用是复杂的系统

这些单独的部分，就像是搭积木一样，每个都有它自己的特点和用途，我们得好好想想怎么把它们组合起来才能发挥最大的作用。这不只是写写提示那么简单了。

比如说，向量数据库吧，它就像是给模型提供信息的仓库，能让模型更好地理解我们要问的问题。市面上有很多这样的仓库可以选择，有的是公开的，有的则是私有的。然后，我们还得选择怎么把信息存进去（嵌入模型），用什么方法找到信息（检索技术），怎么判断信息之间的相似度，怎么把文档分成小块，怎么让仓库保持最新状态……要考虑的事情还有很多。

而且，这些部分之间有时候会互相影响，这种影响很难提前预料。比如，有时候提示模板的效果，可能就因为文档分块时忘了去掉的一些分隔符而变得不一样。

另外，我们看到有些应用是由好几个专家模块组成的，这些模块手拉手一起工作来解决问题。这就让评估整个系统变得更加复杂。现在，专业的工具越来越重要，它们能帮助团队造出更加健壮的应用。

就像我们平时测试软件一样，一个好的LLM评估框架的目的就是让我们有信心，确保系统能够正常工作，并且在出现问题的时候能够找出原因。和传统的软件开发不一样，用LLMs的时候需要更多的尝试和团队合作，从和领域专家一起写提示，到和工程师一起集成工具，都需要有系统的方法来记录我们的进展。

从传统软件中吸取教训

现在使用LLMs构建伟大产品的大部分团队都没有ML实践经验。方便的是，当考虑到LLM评估时，软件开发的许多目标和最佳实践仍然广泛相关。

自动化和持续集成仍然是目标

厉害的团队都知道，要想软件可靠，就得有一套强大的测试计划。每次对软件做了点改动，这套计划就会自动跑一遍，确保一切都没问题后，才敢把软件放到实际使用的环境中去。这个过程叫做持续集成（CI），它能防止问题的出现，确保软件按照程序员的想法正常工作。测试计划一般包括三种测试：单元测试、集成测试和端到端测试。

但是，对于大型语言模型（LLMs）来说，要模拟单元测试就有点难了。因为它们的特点包括：

随机性 - 这些模型生成文字是随机的，同一个问题，每次生成的答案可能都不一样。有些任务需要固定的答案，但有些创意写作的任务就需要这种多样性。
主观性 - 我们希望这些模型能像真人一样交流，这就不容易评估了，因为“好”或“坏”往往取决于上下文或者个人喜好。
成本和延迟 - 运行这些高级的模型可能要花不少钱，而且反应时间也可能比较长，尤其是那些需要分几步来完成的模型。
范围 - 这些模型能处理的任务越来越广泛，也越来越模糊，所以评估起来比传统的软件应用要复杂得多。

所以，在评估LLM应用的时候，我们主要依靠集成测试和端到端测试，这些测试要自动化，并且要在CI流程中好好管理。

可观察性需要发展

在实际工作中，我们需要时刻注意我们的系统是不是运行得好好的。我们用一些工具，比如Datadog和New Relic，来监控系统是不是健康，如果发现问题，这些工具会发出警告。但这些工具主要是用来处理一些简单问题，比如系统出错或者性能下降，它们用一些基本的规则和错误代码来判断。不过，对于大型语言模型（LLMs）来说，这些可能就不够用了。因为LLMs越强大，越复杂，我们就越难确定是不是真的出了问题，这时候，能够清楚地看到系统内部发生了什么（可观察性）和事情发生的顺序（可追溯性）就变得特别重要。

使用LLMs的一个好处是，我们可以更快地做出调整和尝试新东西。比如，如果发现问题，我们可以通过改改我们给模型的指令来解决，或者让模型表现得更好。而且，因为LLMs比较容易用，那些不太懂技术的人也能参与进来，这就改变了团队的组成。这就要求我们的监控工具要能更好地和开发环境结合起来，让不是工程师的人也能参与进来，一起改进系统。这种快速尝试新东西的承诺也让我们更重视回归测试，也就是确保我们改了东西之后，原来好的部分还是好的。

在深入讨论评估的阶段和它们怎么和我们现在用的CI（持续集成）和监控工具结合之前，我们先了解一下评估的不同类型是很重要的。

评估类型可能有很大差异

在评估LLM块的一个或多个组件时，根据您的目标、任务的复杂性和可用资源，适当的评估类型可能会有所不同。拥有对系统整体质量可能产生影响的组件的良好覆盖是很重要的。

这些不同类型的评估可以通过以下方式大致描述：

判断返回类型最好保持简单

在评价一个东西好不好的时候，我们通常会用几种常见的方法，从最简单的到复杂的：

二元 - 就是说，这个东西要么好，要么不好，没有中间地带。
分类 - 比二元多几个选项，比如好、一般、不好，或者再加上一个“说不准”。
排名 - 把东西按照好坏顺序排个队，最好的放最前面，最差的放最后面。
数值 - 给东西打分，比如0到100分，或者给个百分比，看看它到底表现怎么样。
文本 - 写一些文字来评论，可能是简单的“好”或者“不好”，或者更详细地说说为什么好或者不好。
多任务 - 就是同时用好几种评价方法来看一个东西，比如既给它打个分，又写点评论。

我们通常用一些大家都知道的标准来把很多个评价合在一起看。比如，在看分类做得好不好的时候，我们会用精确度和召回率这样的标准。如果是排名的话，可能会用NDCG或者Elo评级这样的标准。如果是打分的话，可能会用Bleu分数这样的标准。

我发现在实际中，二元和分类这两种方法最常用，因为它们简单，容易操作，也容易得到可靠的结果。如果评价的方法太复杂，就可能产生误解，也不容易得出明确的结论。

模型来源的判断越来越有希望

获取判断是大型语言模型（LLMs）等基础模型周围出现的一个不断发展的新领域。我们可以将其标准化为以下几种典型来源：

启发式/代码 - 利用基于成本、令牌使用、延迟、输出上的正则表达式规则等属性的简单确定性规则来进行判断。这种方式通常可以快速且成本较低地大规模运行。
模型（或'AI'） - 使用其他基础模型来对组件的输出提供判断，这样可以以较低的成本提供更定性和微妙的判断。
人类 - 从应用程序的最终用户或内部领域专家那里获取黄金标准的判断。这可能是最昂贵和最慢的选择，但也是最可靠的。

模型判断，特别是使用AI作为评估者，是一个非常有前景的研究方向。例如，在论文《Judging LLM-as-a-Judge》中，展示了一个经过适当提示的GPT-4模型在对LLM模型对问题的回答进行1-10评分时，与人类判断的一致性超过80%，这相当于人类之间的一致性水平。

这种评估者同样适用于评估重要的非LLM组件，如检索增强生成（RAG）中的检索组件。在论文《Automated Evaluation of Retrieval Augmented Generation》中，GPT-3模型被赋予了从检索到的上下文中提取最相关句子的任务。然后，通过计算相关句子与不相关句子数量的比率来得出相关性的数值判断，这与专家人类判断高度相关。

然而，也存在风险。评估LLMs的困难同样适用于使用它们作为评估者。最近的研究还表明，LLMs具有可能污染评估过程的偏见。在论文《Benchmarking Cognitive Biases in Large Language Models as Evaluators》中，研究者在15种不同的LLM变体中测量了6种认知偏见，发现向模型呈现结果的顺序等简单细节可能对评估产生重大影响。

因此，在信任LLM评估者之前，需要在目标用例上进行性能实验——也就是要评估评估者本身。所有常用的提示工程技术，如包括少数示例，在这里同样适用。此外，使用人类判断来微调专家级的、更经济的评估模型可能是一个真正的突破。

建议团队考虑将更多的人类判断工作转移到一个更高层次上，专注于帮助改进模型评估者。这将最终导致一个更具可扩展性、可重复性和成本效益的评估过程，同时人类专业知识可以更有针对性地用于最重要的高价值场景。

判断标准是大多数定制发生的地方

在评估大型语言模型（LLMs）或任何其他系统时，判断标准应当针对特定用例的需求来设定。这些标准可能在代码中明确定义，或者通过提示（prompt）来指导模型，也可能嵌入在模型的参数中，具体取决于评估是由代码、另一个模型还是人类来执行。

以下是一些可以参考的广泛主题和类别：

一般性能：包括系统的响应时间（延迟）、运行成本和可接受的错误阈值。
行为：涉及系统的输出特征，如语调、写作风格、回答的多样性、事实准确性和内容的相关性。
伦理：包括系统的偏见、安全性、隐私保护等伦理考量。
用户体验：涉及用户与系统交互时的参与度、满意度和生产力。

开始时，选择一小部分覆盖最重要标准的评估者是明智的。随着对需求的更深入了解和新出现的边缘情况，这些评估标准可以逐步调整和扩展。同时，不同标准之间可能需要权衡。例如，追求回答的多样性可能会增加吸引力，但也可能增加错误的风险；而更高的输出质量可能以牺牲响应时间为代价。

在项目初期就考虑这些评估标准，有助于确保团队对应用程序的最终目标有深刻的理解。这不仅有助于指导开发过程，还能帮助在评估系统性能时做出更明智的决策。

不同的评估阶段是必要的

正如持续集成（CI）和可观察性之间的区别所讨论的，应用程序的开发生命周期在不同阶段有着不同的评估需求。我发现这个生命周期自然地包括了规划和界定范围的初步练习，随后是开发、部署和监控的循环过程。

这些循环在LLM应用的整个生命周期中重复进行，目的是为了进行干预和提升性能。一个强大的团队会使这个过程更加敏捷和连续。

开发阶段包括了典型的应用程序开发活动，比如在代码中组织LLM模块、设置用户界面等，同时也包括了更特定于LLM的干预和实验，如提示工程、上下文调整、工具集成更新和微调等。如果实施了适当的评估阶段，那么优化LLM性能的选择和质量将得到显著提升。这促进了一种更以数据为驱动、系统化的方法。

根据我的经验，有三个互补的评估阶段，它们对于支持LLM模块相关干预的快速迭代周期具有最高的投资回报率：

交互式评估 - 拥有一个交互式的、类似游乐场的编辑器环境对于快速实验模型组件并提供即时评估反馈非常有用。这种方式在处理较少数量的场景时效果最佳。它允许团队（无论是技术团队还是非技术团队）快速探索LLM应用的设计空间，并非正式地了解哪些方法有效。
批量离线评估 - 在一个更广泛的、策划好的场景集上进行基准测试或回归测试最有希望的变化，以提供更系统的评估。理想情况下，针对应用程序不同组件的不同评估者可以为这个阶段做出贡献，一些评估可以与任务的黄金标准预期结果进行比较。这可以自然地融入现有的CI流程中。
在线监控 - 部署后，可以持续评估真实用户交互以监控模型的性能。这个过程可以驱动警报，收集离线评估的额外场景，并通知何时需要进行进一步的干预。通过内部环境或首先与选定的用户群体进行beta测试进行分阶段部署通常非常有价值。

通过这些评估阶段，团队可以更有信心地快速迭代和改进他们的LLM应用，确保它们在生产环境中表现良好。

通常需要在一定程度上共同发展评估框架和应用程序开发，因为随着更多数据的可用性和需求的明确化，可以显著提高这个过程的效率。能够轻松地跨阶段和团队进行版本控制和共享评估者以及应用程序配置。

高质量数据集仍然至关重要

确实，缺乏高质量数据会严重影响评估框架的有效性。一个优秀的评估数据集应该全面代表在实际应用中预期遇到的各种情况，包括输入数据和相应的预期输出。同时，确保评估数据集能够覆盖应用程序所有组件的预期行为同样重要。

以下是一些可以考虑的策略来获取或创建高质量的评估数据集：

利用公共/学术基准测试：这些基准测试通常由学术界和公共研究机构制定，用于评估模型在特定任务上的性能。它们可以帮助你了解模型在通用任务上的表现，并作为选择或改进模型的基础。
从自己的系统中收集数据：通过收集用户与系统实际交互的数据，可以获得最直接、最相关的评估信息。这些数据可以揭示用户的真实使用模式和系统在实际运行中的表现。
创建合成数据：使用现有的高质量数据作为种子，通过LLMs生成更多的输入示例，可以帮助扩展数据集。这种方法可以通过少数示例提示和现有数据的代表性子集来引导模型生成多样化的补充例子。
模型红队测试：这是一种使用一个模型来对抗另一个模型的方法，目的是生成能够挑战系统鲁棒性的对抗性例子。这可以帮助识别和修复潜在的问题或漏洞。
反馈循环：建立机制来收集用户对系统输出的直接反馈，无论是显式的（如评分或评论）还是隐式的（如用户对建议的接受或修改）。
模拟和场景规划：在开发阶段，可以通过模拟不同的使用场景来生成数据，这有助于预测和准备模型可能遇到的各种情况。
数据增强技术：应用数据增强技术，如旋转、缩放或颜色变化（对于图像数据），或同义词替换、句子重构（对于文本数据），来增加数据集的多样性和覆盖范围。
多源数据集成：集成来自不同来源的数据，以确保评估数据集的全面性和多样性。