Skip to main content
以下,我们将讨论几种流行的LLM应用类型的评估。

智能体

基于LLM的自主智能体 结合了三个组件:(1) 工具调用,(2) 记忆,和(3) 规划。智能体通过工具调用与规划(例如,通常通过提示)和记忆(例如,通常为短期消息历史)来生成响应。工具调用 允许模型通过生成两个东西来响应给定的提示:(1) 要调用的工具,和(2) 所需的输入参数。 工具使用 以下是在 LangGraph 中的工具调用智能体。assistant node 是一个 LLM,根据输入决定是否调用工具。tool condition 检查是否由 assistant node 选择了一个工具,如果是,则路由到 tool nodetool node 执行工具并将输出作为工具消息返回给 assistant node。这个循环会一直持续到 assistant node 选择一个工具为止。如果没有选择工具,则智能体直接返回 LLM 的响应。 Agent 这设置了三种用户通常感兴趣的智能体评估类型:
  • Final Response: 评估智能体的最终响应。
  • Single step: 独立评估智能体的任何步骤(例如,是否选择了适当的工具)。
  • Trajectory: 评估智能体是否采取了预期的路径(例如,工具调用)来得出最终答案。
Agent-eval 以下我们将介绍这些类型是什么,每个类型所需的组件(输入、输出、评估器),以及何时应该考虑使用它们。请注意,你可能需要做多种(如果不是所有!)这类评估——它们不是相互排斥的!

评估智能体的最终响应

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

评估智能体的单个步骤

智能体通常执行多个动作。虽然评估其端到端性能很有用,但评估这些单个动作也同样有用。这通常涉及评估智能体的单个步骤——即LLM调用,它决定要做什么。 输入应该是单个步骤的输入。根据您要测试的内容,这可以仅仅是原始用户输入(例如,一个提示和/或一系列工具)或也可以包括之前完成的步骤。 输出仅仅是该步骤的输出,通常是LLM的响应。LLM的响应通常包含工具调用,指示智能体下一步应该采取什么行动。 此评估器通常是对是否选择了正确的工具调用的一些二元评分,以及一些关于工具输入是否正确的启发式方法。参考工具可以简单地指定为一个字符串。 这种评估方式有多个优点。它允许您评估单个动作,这有助于您聚焦于应用程序可能失败的地方。它们运行起来也相对较快(因为只涉及一次LLM调用),并且评估通常使用相对于参考工具的简单启发式评估。一个缺点是它们无法捕捉到整个智能体——只捕获一个特定的步骤。另一个缺点是数据集创建可能具有挑战性,尤其是如果您想在智能体输入中包含历史记录。对于智能体轨迹早期步骤的数据集生成相对容易(例如,这可能仅包括输入提示),但对于轨迹后期步骤的数据集生成则可能比较困难(例如,包括许多先前的智能体动作和响应)。

评估智能体的轨迹

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

检索增强生成(RAG)

检索增强生成(RAG)是一种强大的技术,它涉及根据用户的输入检索相关文档,并将它们传递给语言模型进行处理。RAG通过利用外部知识,使人工智能应用能够生成更全面、更具情境意识的响应。
要全面了解RAG概念,请参阅我们的RAG From Scratch系列

数据集

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

评估器

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

应用RAG评估

在应用RAG评估时,请考虑以下方法:
  1. Offline evaluation:对于依赖于参考答案的任何提示,请使用离线评估。这通常用于RAG答案正确性评估,其中参考答案是真实(正确)答案。
  2. Online evaluation:对任何无参考提示采用在线评估。这允许您实时评估RAG应用在真实场景中的性能。
  3. Pairwise evaluation:利用成对评估来比较不同RAG链生成的答案。这种评估侧重于用户指定的标准(例如,答案格式或风格),而不是正确性,正确性可以通过自洽性或基准真实参考来评估。

RAG评估摘要

评估者详情需要参考输出作为裁判的LLM?成对相关
文档相关性文档与问题相关吗?是 - 提示
答案可信度答案是否基于文档?是 - 提示
答案有用性答案是否有助于解答问题?是 - 提示
答案正确性答案是否与参考答案一致?是 - 提示
成对比较多个答案版本如何比较?是 - 提示

摘要

摘要是一种特定的自由形式写作。评估目标通常是检查写作(摘要)相对于一组标准。 文本摘要的 Developer curated examples 通常用于评估(参见数据集示例此处)。然而,来自生产(摘要)应用的 user logs 可以用于以下任何 Reference-free 评估提示的在线评估。 LLM-as-judge 通常用于使用 Reference-free 提示进行摘要评估(以及其他类型的写作),这些提示遵循提供的标准来评分摘要。提供特定的 Reference 摘要较为少见,因为摘要是一项创造性任务,存在许多可能的正确答案。 由于使用了 Reference-free 提示,OnlineOffline 评估是可行的。Pairwise 评估也是在不同摘要链(例如,不同的摘要提示或 LLM)之间进行比较的强大方式:
用例详情需要参考输出作为裁判的LLM?对应相关性
事实准确性摘要相对于源文档是否准确?是 - 提示
忠实度摘要是否基于源文档(例如,没有幻觉)?是 - 提示
有用性摘要相对于用户需求是否有用?是 - 提示

分类与标记

分类和标记将标签应用于给定的输入(例如,用于毒性检测、情感分析等)。分类/标记评估通常采用以下组件,我们将在下文详细讨论: 分类/标记评估的一个关键考虑因素是您是否有一个带有 reference 标签的数据集。如果没有,用户通常会希望定义一个使用标准来将标签(例如,毒性等)应用于输入(例如,文本、用户问题等)的评估器。然而,如果提供了真实标签类别,那么评估目标就集中在相对于真实标签类别对分类/标记链进行评分(例如,使用精确度、召回率等指标)。 如果提供了地面真实参考标签,那么通常简单地定义一个自定义启发式评估器来比较地面真实标签与链输出。然而,随着大型语言模型的出现,越来越常见的是直接使用 LLM-as-judge 根据指定的标准对输入进行分类/标记(无需地面真实参考)。 使用 LLM-as-judgeReference-free 提示词时,OnlineOffline 评估是可行的。特别是,当用户想要对应用程序输入进行标记/分类(例如,用于毒性等)时,这非常适合 Online 评估。 | 用例 | 详细说明 | 需要参考输出 | 作为裁判的LLM? | 成对相关 | | 准确度 | 标准定义 | 是 | 否 | 否 | | 精确度 | 标准定义 | 是 | 否 | 否 | | 召回率 | 标准定义 | 是 | 否 | 否 |