下面,我们将讨论几种流行类型的 LLM 应用程序的评估。

智能体

由 LLM 驱动的自主智能体结合三个组件:(1) 工具调用,(2) 记忆,和 (3) 规划。智能体使用工具调用与规划(例如,通常通过提示)和记忆(例如,通常是短期消息历史)来生成响应。工具调用允许模型通过生成两件事来响应给定的提示:(1) 要调用的工具和 (2) 所需的输入参数。 Tool use 下面是 LangGraph 中的工具调用智能体。assistant node 是一个 LLM,它根据输入确定是否调用工具。tool condition 查看 assistant node 是否选择了工具,如果是,则路由到 tool nodetool node 执行工具并将输出作为工具消息返回给 assistant node。只要 assistant node 选择工具,此循环就会继续。如果未选择工具,则智能体直接返回 LLM 响应。 Agent 这设置了用户通常感兴趣的三种一般类型的智能体评估:
  • 最终响应:评估智能体的最终响应。
  • 单步:单独评估任何智能体步骤(例如,它是否选择了适当的工具)。
  • 轨迹:评估智能体是否采取了预期的路径(例如,工具调用)以得出最终答案。
Agent-eval 下面我们将介绍这些是什么,每个所需的组件(输入、输出、评估器)以及何时应考虑这一点。请注意,您可能希望进行多种(如果不是全部!)这些类型的评估 - 它们不是相互排斥的!

评估智能体的最终响应

评估智能体的一种方法是评估其在任务上的整体表现。这基本上涉及将智能体视为黑盒,并简单地评估它是否完成了工作。 输入应该是用户输入和(可选)工具列表。在某些情况下,工具作为智能体的一部分硬编码,不需要传入。在其他情况下,智能体更通用,这意味着它没有固定的工具集,需要在运行时传入工具。 输出应该是智能体的最终响应。 评估器根据您要求智能体执行的任务而有所不同。许多智能体执行相对复杂的一组步骤并输出最终文本响应。与 RAG 类似,LLM 作为评判者评估器在这些情况下通常有效,因为它们可以直接从文本响应评估智能体是否完成了工作。 然而,这种评估类型有几个缺点。首先,它通常需要一段时间才能运行。其次,您没有评估智能体内部发生的任何事情,因此当发生故障时很难调试。第三,有时很难定义适当的评估指标。

评估智能体的单个步骤

智能体通常执行多个操作。虽然端到端评估它们很有用,但评估这些单独的操作也可能很有用。这通常涉及评估智能体的单个步骤 - 它决定做什么的 LLM 调用。 输入应该是单个步骤的输入。根据您正在测试的内容,这可能只是原始用户输入(例如,提示和/或一组工具),或者它也可以包括先前完成的步骤。 输出只是该步骤的输出,通常是 LLM 响应。LLM 响应通常包含工具调用,指示智能体接下来应采取的操作。 这里的评估器通常是关于是否选择了正确工具调用的某个二元分数,以及关于工具输入是否正确的某个启发式。参考工具可以简单地指定为字符串。 这种评估类型有几个好处。它允许您评估单个操作,这可以让您磨练应用程序可能失败的地方。它们运行起来也相对较快(因为它们只涉及单个 LLM 调用),评估通常使用所选工具相对于参考工具的简单启发式评估。一个缺点是它们没有捕获完整的智能体 - 只有一个特定步骤。另一个缺点是数据集创建可能具有挑战性,特别是如果您想在智能体输入中包含过去的历史。为智能体轨迹早期的步骤生成数据集非常容易(例如,这可能只包括输入提示),但为轨迹后期的步骤生成数据集可能很困难(例如,包括许多先前的智能体操作和响应)。

评估智能体的轨迹

评估智能体的轨迹涉及评估智能体采取的所有步骤。 输入再次是整体智能体的输入(用户输入,可选地是工具列表)。 输出是工具调用列表,可以制定为”确切”轨迹(例如,预期的工具调用序列)或简单地是预期的一组工具调用(以任何顺序)。 这里的评估器是对所采取步骤的某个函数。评估”确切”轨迹可以使用单个二元分数来确认序列中每个工具名称的确切匹配。这很简单,但有一些缺陷。有时可能有多条正确的路径。此评估也没有捕获轨迹偏离一个步骤与完全错误之间的差异。 为了解决这些缺陷,评估指标可以集中在采取的”不正确”步骤的数量上,这更好地考虑了接近的轨迹与显著偏离的轨迹。评估指标也可以集中在是否以任何顺序调用了所有预期工具。 然而,这些方法都不评估工具的输入;它们只关注所选的工具。为了解决这个问题,另一种评估技术是将完整智能体的轨迹(连同参考轨迹)作为一组消息(例如,所有 LLM 响应和工具调用)传递给 LLM 作为评判者。这可以评估智能体的完整行为,但它是最具挑战性的参考编译(幸运的是,使用像 LangGraph 这样的框架可以帮助解决这个问题!)。另一个缺点是评估指标可能有点棘手。

检索增强生成 (RAG)

检索增强生成 (RAG) 是一种强大的技术,涉及根据用户的输入检索相关文档并将其传递给语言模型进行处理。RAG 通过利用外部知识使 AI 应用程序能够生成更明智和上下文感知的响应。
有关 RAG 概念的全面回顾,请参阅我们的 RAG From Scratch 系列

数据集

在评估 RAG 应用程序时,一个关键考虑因素是您是否拥有(或可以轻松获得)每个输入问题的参考答案。参考答案作为评估生成的响应正确性的基本事实。然而,即使在没有参考答案的情况下,仍然可以使用无参考的 RAG 评估提示执行各种评估(下面提供示例)。

评估器

LLM 作为评判者是 RAG 常用的评估器,因为它是评估文本之间的事实准确性或一致性的有效方法。 rag-types.png 评估 RAG 应用程序时,您可以拥有需要参考输出的评估器和不需要参考输出的评估器:
  1. 需要参考输出:将 RAG 链的生成答案或检索与参考答案(或检索)进行比较以评估其正确性。
  2. 不需要参考输出:使用不需要参考答案的提示执行自我一致性检查(在上图中用橙色、绿色和红色表示)。

应用 RAG 评估

应用 RAG 评估时,请考虑以下方法:
  1. 离线评估:对依赖于参考答案的任何提示使用离线评估。这最常用于 RAG 答案正确性评估,其中参考是基本事实(正确)答案。
  2. 在线评估:对任何无参考提示使用在线评估。这允许您在实时场景中评估 RAG 应用程序的性能。
  3. 配对评估:利用配对评估来比较不同 RAG 链产生的答案。此评估侧重于用户指定的标准(例如,答案格式或样式),而不是正确性,可以使用自我一致性或基本事实参考进行评估。

RAG 评估摘要

评估器详细信息需要参考输出LLM 作为评判者?配对相关
文档相关性文档是否与问题相关?是 - 提示
答案忠实性答案是否基于文档?是 - 提示
答案有用性答案是否有助于解决问题?是 - 提示
答案正确性答案是否与参考答案一致?是 - 提示
配对比较多个答案版本如何比较?是 - 提示

摘要

摘要是一种特定类型的自由形式写作。评估目标通常是相对于一组标准检查写作(摘要)。 要摘要的文本的开发人员策划示例通常用于评估(请参阅数据集示例此处)。然而,来自生产(摘要)应用的用户日志可以与下面的任何无参考评估提示一起用于在线评估。 LLM 作为评判者通常用于使用遵循提供的标准对摘要进行评分的无参考提示来评估摘要(以及其他类型的写作)。提供特定参考摘要的情况较少,因为摘要是一项创造性任务,可能有许多正确答案。 由于使用了无参考提示,在线离线评估都是可行的。配对评估也是在不同摘要链(例如,不同的摘要提示或 LLM)之间执行比较的强大方法:
用例详细信息需要参考输出LLM 作为评判者?配对相关
事实准确性摘要相对于源文档是否准确?是 - 提示
忠实性摘要是否基于源文档(例如,没有幻觉)?是 - 提示
有用性摘要相对于用户需求是否有用?是 - 提示

分类和标记

分类和标记将标签应用于给定输入(例如,用于毒性检测、情感分析等)。分类/标记评估通常采用以下组件,我们将在下面详细回顾: 分类/标记评估的一个核心考虑因素是您是否拥有带有参考标签的数据集。如果没有,用户经常希望定义一个评估器,使用标准将标签(例如,毒性等)应用于输入(例如,文本、用户问题等)。然而,如果提供了基本事实类别标签,则评估目标侧重于相对于基本事实类别标签对分类/标记链进行评分(例如,使用精度、召回率等指标)。 如果提供了基本事实参考标签,则通常只需定义自定义启发式评估器来将基本事实标签与链输出进行比较。然而,鉴于 LLM 的出现,越来越常见的是简单地使用 LLM 作为评判者根据指定的标准(没有基本事实参考)执行输入的分类/标记。 当使用带有无参考提示的 LLM 作为评判者时,在线离线评估是可行的。特别是,当用户想要标记/分类应用程序输入(例如,用于毒性等)时,这非常适合在线评估。
用例详细信息需要参考输出LLM 作为评判者?配对相关
准确性标准定义
精度标准定义
召回率标准定义

Connect these docs programmatically to Claude, VSCode, and more via MCP for real-time answers.