评估概念
AI 应用程序的质量和开发速度通常受到高质量评估数据集和指标的限制,这些数据集和指标使您能够优化和测试您的应用程序。
LangSmith 使构建高质量评估变得容易。 本指南更广泛地介绍了 LangSmith 评估框架和 AI 评估技术。 LangSmith 框架的构建块是:
- 数据集:测试输入和参考输出的集合。
- Evaluators:用于对输出进行评分的函数。
数据
数据集是用于评估应用程序的示例集合。一个例子是 test input, reference output 对。

例子
每个示例包括:
- Inputs:要传递给应用程序的输入变量字典。
- Reference outputs (optional):参考输出的字典。这些不会传递给你的应用程序,它们只用于 evaluger。
- 元数据 (可选):可用于创建数据集的筛选视图的附加信息的字典。

数据集管理
有多种方法可以构建用于评估的数据集,包括:
手动精选示例
我们通常建议人们以这种方式开始创建数据集。 通过构建应用程序,您可能对希望应用程序能够处理哪些类型的输入有所了解。 以及什么是“好”的回应。 您可能希望涵盖一些您可以想象的不同常见边缘情况或情况。 即使是 10-20 个高质量的、手动策划的示例也可以大有帮助。
历史跟踪
一旦应用程序投入生产,您就会开始获得有价值的信息:用户实际如何使用它? 这些真实世界的运行是很好的示例,因为它们是最真实的!
如果您获得了大量流量,如何确定哪些运行值得添加到数据集中? 您可以使用一些技术:
- 用户反馈:如果可能 - 尝试收集最终用户反馈。然后,您可以查看哪些数据点收到了负面反馈。 这太有价值了!这些是您的应用程序表现不佳的地方。 您应该将这些添加到数据集中,以便将来进行测试。
- 启发式:您还可以使用其他启发式方法来识别“有趣”的数据点。例如,需要很长时间才能完成的运行可能很有趣,可以查看并添加到数据集中。
- LLM 反馈:您可以使用另一个 LLM 来检测值得注意的运行。例如,您可以使用 LLM 来标记聊天机器人对话,其中用户必须以某种方式改写他们的问题或更正模型,这表明聊天机器人最初没有正确响应。
合成数据
一旦你有了几个例子,你就可以尝试人工生成更多。 通常建议在此之前先有一些好的手工制作的例子,因为这些合成数据通常会在某种程度上与它们相似。 这可能是快速获取大量数据点的有用方法。
分裂
在设置评估时,您可能希望将数据集划分为不同的分片。例如,对于许多快速且成本较低的迭代,可以使用较小的拆分,而对最终评估使用较大的拆分。此外,拆分对于实验的可解释性也很重要。例如,如果您有一个 RAG 应用程序,您可能希望数据集拆分侧重于不同类型的问题(例如,事实、观点等),并分别在每个拆分上评估您的应用程序。
了解如何创建和管理数据集分割。
版本
数据集进行版本控制,因此每次在数据集中添加、更新或删除示例时,都会创建数据集的新版本。 这样,在您犯错时,可以轻松检查和还原对数据集的更改。 您还可以标记数据集的版本,为它们提供更易读的名称。 这对于标记数据集历史记录中的重要里程碑非常有用。
您可以对数据集的特定版本运行评估。在 CI 中运行评估时,这非常有用,可确保数据集更新不会意外中断 CI 管道。
评估员
Evaluator 是对应用程序在特定示例中的性能进行评分的函数。
赋值器输入
赋值器接收以下输入:
赋值器输出
计算器返回一个或多个指标。这些应作为字典或字典列表返回,格式如下:
key:指标的名称。score|value:指标的值。用score如果它是一个数值指标,并且value如果它是绝对的。comment(可选):证明分数合理性的原因或其他字符串信息。
定义赋值器
定义和运行赋值器的方法有很多种:
- 自定义代码:将自定义计算器定义为 Python 或 TypeScript 函数,并使用 SDK 在客户端运行它们,或通过 UI 在服务器端运行它们。
- 内置评估器:LangSmith 有许多内置评估器,您可以通过 UI 配置和运行这些评估器。
您可以使用 LangSmith SDK(Python 和 TypeScript)通过 Prompt Playground 运行赋值器,也可以通过配置规则以在特定跟踪项目或数据集上自动运行赋值器。
评估技术
LLM 评估有几种高级方法:
Anthropic
人工评估通常是评估的一个很好的起点。LangSmith 可以轻松查看您的 LLM 应用程序输出以及跟踪(所有中间步骤)。
LangSmith 的注释队列可以轻松获得有关应用程序输出的人工反馈。
启发式
启发式计算器是基于规则的确定性函数。这些适用于简单的检查,例如确保聊天机器人的响应不为空、生成的代码片段可以编译或分类是否完全正确。
LLM法官
LLM 作为裁判评估员使用 LLM 对申请的结果进行评分。要使用它们,您通常会在 LLM 提示中对评分规则/标准进行编码。它们可以是无参考的(例如,检查系统输出是否包含冒犯性内容或是否符合特定标准)。或者,他们可以将任务输出与参考输出进行比较(例如,检查输出相对于参考是否准确)。
对于 LLM 作为裁判的评估员,仔细审查结果分数并在需要时调整评分员提示非常重要。通常,将这些样本编写为小样本评估器会很有帮助,其中您需要提供输入、输出和预期成绩的示例作为评分器提示的一部分。
了解如何定义 LLM 作为裁判评估员。
成对
成对计算器允许您比较应用程序的两个版本的输出。 想想 LMSYS Chatbot Arena - 这是相同的概念,但更普遍地应用于 AI 应用程序,而不仅仅是模型! 这可以使用启发式(“哪个响应更长”)、LLM(带有特定的成对提示)或人工(要求他们手动注释示例)。
何时应该使用成对评估?
当难以直接对 LLM 输出进行评分,但更容易比较两个输出时,成对评估很有帮助。 对于摘要等任务来说,情况就是这种情况 - 可能很难给摘要一个绝对的分数,但很容易选择两个摘要中的哪一个信息量更大。
了解如何运行成对评估。
实验
每次我们在数据集上评估应用程序时,我们都会进行一次实验。 实验包含在数据集上运行特定版本应用程序的结果。 要了解如何使用 LangSmith 实验视图,请参阅如何分析实验结果。

通常,我们将在给定的数据集上运行多个实验,测试应用程序的不同配置(例如,不同的提示或 LLM)。 在 LangSmith 中,您可以轻松查看与数据集关联的所有实验。 此外,您还可以在对比视图中比较多个实验。

注释队列
人工反馈通常是您可以在应用程序中收集到的最有价值的反馈。 使用注释队列,您可以标记应用程序的运行以进行注释。 然后,人工注释者有一个简化的视图来查看队列中的运行并提供反馈。 通常(某些子集)这些带注释的运行随后会传输到数据集以供将来评估。 虽然您始终可以内联注释运行,但注释队列提供了另一个选项,用于将运行分组在一起、指定注释条件和配置权限。
了解有关注释队列和人工反馈的更多信息。
离线评估
在数据集上评估应用程序就是我们所说的 “离线” 评估。 它是离线的,因为我们正在评估一组预编译的数据。 另一方面,在线评估是指我们根据实际流量近乎实时地评估已部署应用程序的输出。 脱机评估用于测试应用程序预部署的版本。
您可以使用 LangSmith SDK(Python 和 TypeScript)在客户端运行离线评估。您可以通过 Prompt Playground 在服务器端运行它们,也可以通过配置自动化来针对特定数据集的每个新实验运行某些评估器。

标杆
也许最常见的离线评估类型是这样一种类型:我们策划一个具有代表性输入的数据集,定义关键性能指标,并对应用程序的多个版本进行基准测试以找到最佳版本。 基准测试可能很费力,因为对于许多用例,您必须管理具有黄金标准参考输出的数据集,并设计良好的指标来将实验输出与它们进行比较。 对于 RAG Q&A 机器人,这可能看起来像一个问题和参考答案的数据集,以及一个 LLM 作为裁判的评估器,用于确定实际答案在语义上是否等同于参考答案。 对于 ReACT 代理,这可能看起来像一个用户请求的数据集和模型应该进行的所有工具调用的参考集,以及一个检查是否进行了所有参考工具调用的启发式计算器。
单元测试
在软件开发中,使用单元测试来验证各个系统组件的正确性。LLM 上下文中的单元测试通常是对 LLM 输入或输出的基于规则的断言(例如,检查 LLM 生成的代码是否可以编译、JSON 是否可以加载等),用于验证基本功能。
编写单元测试时,通常期望它们应该始终通过。 这些类型的测试非常适合作为 CI 的一部分运行。 请注意,在这样做时,设置缓存以最小化 LLM 调用很有用(因为这些调用会很快累积起来!
回归测试
回归测试用于测量应用程序各个版本随时间推移的性能。 它们至少用于确保新的应用程序版本不会根据当前版本正确处理的示例进行回归,理想情况下,它们用于衡量新版本相对于当前版本好多少。 通常,当您进行预期会影响用户体验的应用程序更新(例如,更新模型或架构)时,会触发这些错误。
LangSmith 的比较视图具有对回归测试的本机支持,允许您快速查看相对于基线发生变化的示例。 回归以红色突出显示,改进以绿色突出显示。

回测
回溯测试是一种将数据集创建(如上所述)与评估相结合的方法。如果您有生产日志的集合,则可以将它们转换为数据集。然后,您可以使用较新的应用程序版本重新运行这些生产示例。这允许您根据过去和实际的用户输入评估性能。
这通常用于评估新的模型版本。 Anthropic 放弃了新模型?没关系!获取应用程序中的 1000 次最新运行,并将其传递到新模型。 然后将这些结果与生产中实际发生的情况进行比较。
成对评估
对于某些任务,人工或 LLM 评分者更容易确定“版本 A 是否优于 B”,而不是为 A 或 B 分配绝对分数。 成对评估就是这样的 — 两个版本的输出相互比较的评分,而不是根据某些参考输出或绝对标准进行评分。 在更一般的任务中使用 LLM 作为评判评估器时,成对评估通常很有用。 例如,如果您有一个摘要应用程序,那么作为 LLM 的裁判可能更容易确定“这两个摘要中哪一个更清晰简洁”,而不是给出像“在清晰度和简洁性方面给这个摘要打 1-10 分”这样的绝对分数。
了解如何运行成对评估。
在线评估
(大致)实时评估已部署应用程序的输出就是我们所说的 “在线” 评估。 在这种情况下,不涉及数据集,也不可能有参考输出 — 我们在生成真实输入和实际输出时运行评估器。 这对于监控应用程序和标记意外行为非常有用。 在线评估也可以与离线评估结合使用:例如,在线评估器可用于将输入问题分类为一组类别,这些类别稍后可用于管理用于离线评估的数据集。
在线评估器通常旨在在服务器端运行。LangSmith 具有内置的 LLM 作为裁判评估器,您可以配置这些评估器,也可以定义也在 LangSmith 中运行的自定义代码评估器。

测试
评估 vs 测试
测试和评估是非常相似且重叠的概念,经常让人感到困惑。
评估根据量度衡量性能。评估指标可以是模糊的或主观的,并且相对指标比绝对指标更有用。 也就是说,它们通常用于将两个系统相互比较,而不是断言单个系统的某些内容。
测试断言正确性。系统只有在通过所有测试后才能部署。
评估指标可以转换为测试。 例如,您可以编写回归测试来断言系统的任何新版本在相关评估指标上的性能必须优于系统的某个基线版本。
如果您的系统运行成本很高,并且测试和评估的数据集重叠,则同时运行测试和评估也可以更高效地使用资源。
您还可以选择使用标准软件测试工具编写评估,例如pytest或vitest/jest出于方便。
用pytest和vitest/jest
LangSmith SDK 附带了 pytest 和vitest/jest.
这些功能使以下作变得容易:
- 在 LangSmith 中跟踪测试结果
- 将评估编写为测试
在 LangSmith 中跟踪测试结果可以轻松共享结果、比较系统和调试失败的测试。
当您要评估的每个示例都需要自定义逻辑来运行应用程序和/或评估器时,将评估编写为测试可能很有用。 标准评估流程假定您可以对数据集中的每个示例以相同的方式运行应用程序和评估器。 但对于更复杂的系统或全面的评估,您可能希望使用特定类型的输入和指标来评估系统的特定子集。 这些类型的异构 eval 更容易编写为一组不同的测试用例,这些测试用例都一起被跟踪,而不是使用标准的 evaluate flow。
当您想评估系统的输出并断言有关它们的一些基本信息时,使用测试工具也很有帮助。
特定于应用程序的技术
下面,我们将讨论一些特定的、流行的 LLM 应用程序的评估。
代理
由 LLM 提供支持的自主代理结合了三个组件 (1) 工具调用,(2) 内存和 (3) 规划。代理使用带有计划 (例如,通常通过提示) 和记忆 (例如,通常是短期消息历史记录) 的工具调用来生成响应。工具调用允许模型通过生成两项内容来响应给定的提示:(1) 要调用的工具,以及 (2) 所需的输入参数。

下面是 LangGraph 中的工具调用代理。这assistant node是一个 LLM,用于根据输入确定是否调用工具。这tool condition查看工具是否被assistant node如果是这样,则路由到tool node.这tool node执行该工具,并将输出作为工具消息返回到assistant node.此循环一直持续到assistant node选择工具。如果未选择任何工具,则代理将直接返回 LLM 响应。

这设置了用户通常感兴趣的三种常规类型的代理评估:
Final Response:评估代理的最终响应。Single step:单独评估任何代理步骤(例如,它是否选择了适当的工具)。Trajectory:评估代理是否采取了预期的路径(例如,工具调用)来获得最终答案。

下面我们将介绍这些是什么,每个组件所需的组件(输入、输出、评估器),以及何时应该考虑这一点。 请注意,您可能希望进行多种(如果不是全部)这些类型的评估 - 它们并不相互排斥!
评估代理的最终响应
评估代理的一种方法是评估其在任务中的整体表现。这基本上涉及将代理视为一个黑匣子,并简单地评估它是否能完成工作。
输入应该是用户输入和(可选)工具列表。在某些情况下,tool 作为代理的一部分进行硬编码,不需要传入。在其他情况下,代理更通用,这意味着它没有固定的工具集,需要在运行时传入工具。
输出应该是代理的最终响应。
评估器根据您要求代理执行的任务而有所不同。许多代理执行一组相对复杂的步骤,并输出最终的文本响应。与 RAG 类似,在这些情况下,LLM 作为法官的评估员通常对评估有效,因为他们可以评估代理人是否直接从文本回复中完成了工作。
但是,这种类型的评估有几个缺点。首先,它通常需要一段时间才能运行。其次,您没有评估代理内部发生的任何事情,因此在发生故障时可能很难进行调试。第三,有时很难定义适当的评估指标。
评估代理的单个步骤
代理通常执行多个作。虽然端到端评估它们很有用,但评估这些单独的作也很有用。这通常涉及评估代理的单个步骤 - LLM 调用,它决定做什么。
inputs 应该是单个步骤的 input。根据你正在测试的内容,这可能只是原始用户输入(例如,提示和/或一组工具),也可能包括以前完成的步骤。
outputs只是该step的输出,通常是LLM响应。LLM 响应通常包含工具调用,指示代理接下来应采取的作。
此评估程序通常是一些二进制分数,用于表示是否选择了正确的工具调用,以及一些启发式方法,用于表示工具的输入是否正确。参考工具可以简单地指定为字符串。
这种类型的评估有几个好处。它允许您评估各个作,从而让您专注于应用程序可能失败的位置。它们的运行速度也相对较快(因为它们只涉及单个 LLM 调用),并且评估通常使用相对于参考工具的所选工具的简单启发式评估。一个缺点是它们没有捕获完整的代理 - 只有一个特定的步骤。另一个缺点是数据集创建可能具有挑战性,特别是如果您想在代理输入中包含过去的历史记录。为智能体轨迹的早期步骤生成数据集非常容易(例如,这可能只包括输入提示),但为轨迹后期的步骤生成数据集可能很困难(例如,包括许多先前的智能体动作和响应)。
评估代理的轨迹
评估代理的轨迹涉及评估代理采取的所有步骤。
输入再次是整个代理的输入(用户输入,以及可选的工具列表)。
输出是一个工具调用列表,可以表述为“精确”轨迹(例如,预期的工具调用序列)或简单的一组预期的工具调用(按任意顺序)。
这里的评估器是所采取步骤的一些功能。评估“精确”轨迹可以使用单个二进制分数来确认序列中每个工具名称的精确匹配。这很简单,但有一些缺陷。有时可能会有多个正确的路径。该评估也没有捕捉到轨迹偏离一步与完全错误之间的区别。
为了解决这些缺陷,评估指标可以侧重于所采取的“错误”步骤的数量,这更好地解释了接近的轨迹与显著偏离的轨迹。评估指标还可以侧重于是否按任何顺序调用所有预期工具。
但是,这些方法都不会评估工具的输入;它们只关注所选工具。为了解决这个问题,另一种评估技术是将完整代理的轨迹(以及参考轨迹)作为一组消息(例如,所有 LLM 响应和工具调用)传递给 LLM 作为判断。这可以评估代理的完整行为,但它是最具挑战性的编译参考(幸运的是,使用像 LangGraph 这样的框架可以帮助解决这个问题!另一个缺点是评估指标可能有点棘手。
检索增强生成 (RAG)
检索增强生成 (RAG) 是一种强大的技术,涉及根据用户的输入检索相关文档并将其传递给语言模型进行处理。RAG 使 AI 应用程序能够利用外部知识生成更明智和上下文感知的响应。
有关 RAG 概念的全面回顾,请参阅我们的RAG From Scratch系列.
数据
在评估 RAG 应用程序时,一个关键的考虑因素是您是否拥有(或可以轻松获得)每个输入问题的参考答案。参考答案用作评估生成的响应的正确性的基本事实。但是,即使没有参考答案,仍然可以使用无参考的 RAG 评估提示(下面提供的示例)进行各种评估。
计算器
LLM-as-judge是 RAG 的常用评估器,因为它是评估文本之间事实准确性或一致性的有效方法。

在评估 RAG 应用程序时,您可以拥有需要参考输出的评估器,而不需要:
- 需要参考输出:将 RAG 链生成的答案或检索与参考答案(或检索)进行比较,以评估其正确性。
- 不需要参考输出:使用不需要参考答案的提示(在上图中由橙色、绿色和红色表示)执行自一致性检查。
应用 RAG 评估
应用 RAG 评估时,请考虑以下方法:
-
Offline evaluation:对依赖参考答案的任何提示使用离线评估。这最常用于 RAG 答案正确性评估,其中参考是真实(正确)答案。 -
Online evaluation:对任何无参考提示采用在线评估。这使您可以评估 RAG 应用程序在实时场景中的性能。 -
Pairwise evaluation:利用成对评估来比较不同 RAG 链产生的答案。此评估侧重于用户指定的标准(例如,答案格式或样式)而不是正确性,可以使用自洽性或真实参考来评估。
RAG 评估摘要
| 计算器 | 细节 | 需要参考输出 | LLM作为法官? | 成对相关 |
|---|---|---|---|---|
| Document relevance | Are documents relevant to the question? | No | Yes - prompt | No |
| Answer faithfulness | Is the answer grounded in the documents? | No | Yes - prompt | No |
| Answer helpfulness | Does the answer help address the question? | No | Yes - prompt | No |
| Answer correctness | Is the answer consistent with a reference answer? | Yes | Yes - prompt | No |
| Pairwise comparison | How do multiple answer versions compare? | No | Yes - prompt | Yes |
综述
摘要是一种特定类型的自由格式写作。评估目的通常是检查相对于一组标准的写作(摘要)。
Developer curated examples的要总结的文本通常用于评估(请参阅此处的数据集示例)。然而user logsfrom a production (summarization) 应用程序可用于在线评估,其中包含任何Reference-free评估提示。
LLM-as-judge通常用于评估摘要(以及其他类型的写作),使用Reference-free遵循提供的标准的提示可对摘要评分。提供特定的Reference总结,因为总结是一项创造性的任务,并且有许多可能的正确答案。
Online或Offline评估是可行的,因为Reference-free提示使用。Pairwise评估也是在不同摘要链(例如,不同的摘要提示或 LLM)之间进行比较的有效方法:
| 用例 | 细节 | 需要参考输出 | LLM作为法官? | 成对相关 |
|---|---|---|---|---|
| Factual accuracy | Is the summary accurate relative to the source documents? | No | Yes - prompt | Yes |
| Faithfulness | Is the summary grounded in the source documents (e.g., no hallucinations)? | No | Yes - prompt | Yes |
| Helpfulness | Is summary helpful relative to user need? | No | Yes - prompt | Yes |
分类和标记
分类和标记将标签应用于给定的输入(例如,用于毒性检测、情绪分析等)。分类/标记评估通常采用以下组件,我们将在下面详细介绍:
分类/标记评估的一个主要考虑因素是,您的数据集是否具有reference标签与否。否则,用户经常希望定义一个评估器,该评估器使用标准将标签(例如,毒性等)应用于输入(例如,文本、用户问题等)。但是,如果提供了真值类标签,则评估目标的重点是相对于真值类标签对分类/标记链进行评分(例如,使用精确率、召回率等指标)。
如果提供了真值参考标签,则通常只需定义一个自定义启发式赋值器,即可将真值标签与链输出进行比较。然而,鉴于 LLM 的出现,它越来越普遍,简单地使用LLM-as-judge根据指定的条件(没有 Ground Truth 引用)对输入执行分类/标记。
Online或Offline使用LLM-as-judge使用Reference-free提示使用。特别是,这非常适合Online当用户想要标记/分类应用程序输入时进行评估(例如,毒性等)。
| 用例 | 细节 | 需要参考输出 | LLM作为法官? | 成对相关 |
|---|---|---|---|---|
| Accuracy | Standard definition | Yes | No | No |
| Precision | Standard definition | Yes | No | No |
| Recall | Standard definition | Yes | No | No |
实验配置
LangSmith 支持多种实验配置,可以更轻松地以您想要的方式运行评估。
重复
多次运行实验可能会有所帮助,因为 LLM 输出不是确定性的,并且每次重复都可能不同。通过运行多次重复,您可以更准确地估计系统的性能。
可以通过传递num_repetitionsargument 设置为evaluate / aevaluate (Python、TypeScript)。
重复实验涉及重新运行 target 函数以生成输出和重新运行计算器。
要了解有关在实验中运行重复的更多信息,请阅读操作指南。
并发
通过传递max_concurrencyargument 设置为evaluate / aevaluate中,您可以指定实验的并发性。这max_concurrencyargument 的语义略有不同,具体取决于您是否使用evaluate或aevaluate.
evaluate
这max_concurrencyargument 设置为evaluate指定运行实验时要使用的最大并发线程数。
这既适用于运行目标函数时,也适用于计算器。
aevaluate
这max_concurrencyargument 设置为aevaluate与evaluate,而是使用信号量来限制
可以一次运行的并发任务。aevaluate的工作原理是为数据集中的每个示例创建一个任务。每个任务都包括运行目标函数
以及该特定示例的所有评估者。这max_concurrency参数指定并发任务的最大数量,或者换句话说 - 示例,
立即运行。
缓存
最后,您还可以通过设置LANGSMITH_TEST_CACHE添加到设备上具有写入权限的有效文件夹。
这将导致在实验中进行的 API 调用缓存到磁盘,这意味着将来进行相同 API 调用的实验将大大加快速度。