评估概念
AI 应用的质量和开发速度通常受限于高质量评估数据集和指标,这些资源能够同时优化和测试您的应用。
LangSmith 让构建高质量评估变得简单。 本指南将解释 LangSmith 评估框架以及更广泛的 AI 评估技术。 LangSmith 框架的构建模块包括:
数据集
数据集是用于评估应用程序的一组示例集合。一个示例是测试输入与参考输出的配对。

示例
每个示例包含:
- 输入: 一个字典形式的输入变量,用于传递给您的应用程序。
- 参考输出(可选):参考输出的字典。这些不会传递给您的应用程序,仅用于评估器。
- 元数据(可选):一个包含额外信息的字典,可用于创建数据集的过滤视图。

数据集策划
构建用于评估的数据集有多种方法,包括:
手动精选示例
这是我们通常建议人们开始创建数据集的方式。 在构建您的应用程序时,您可能已经对您的应用程序能够处理哪些类型的输入有了大致了解, 以及什么样的“好”响应可能是怎样的。 您可能希望涵盖一些不同的常见边缘情况或您能想象到的场景。 即使是 10-20 个高质量、人工精心策划的示例也能发挥巨大作用。
历史痕迹
一旦您的应用投入生产,您就开始获得有价值的信息:用户实际上是如何使用它的? 这些真实世界的运行是极好的示例,因为它们,嗯,最真实!
如果您收到大量流量,如何确定哪些运行值得添加到数据集中? 您可以使用以下几种技术:
- 用户反馈: 如果可能——尝试收集最终用户的反馈。这样你就可以看到哪些数据点收到了负面反馈。 这非常有价值!这些是应用程序表现不佳的地方。 你应该将这些添加到你的数据集中,以便在未来进行测试。
- 启发式方法: 您还可以使用其他启发式方法来识别\"有趣\"的数据点。例如,运行时间较长的任务可能值得查看并添加到数据集中。
- LLM 反馈: 您可以使用另一个 LLM 来检测值得注意的运行。例如,您可以使用 LLM 标记那些用户不得不重新表述问题或在某些方面纠正模型的回答的聊天对话,这表明聊天机器人最初没有正确响应。
合成数据
一旦你有了几个示例,就可以尝试人工生成更多。 通常建议在此之前先准备几个良好的手工制作的示例,因为这种合成数据在某种程度上往往会与它们相似。 这是一种快速获取大量数据点的有效方法。
拆分
在设置您的评估时,您可能希望将数据集划分为不同的子集。例如,您可以使用较小的子集进行多次快速且低成本的迭代,而使用较大的子集进行最终评估。此外,子集对于实验的可解释性也很重要。例如,如果您有一个 RAG(检索增强生成)应用,可能希望您的数据集子集专注于不同类型的提问(如事实型、观点型等),并分别对每个子集评估您的应用。
了解如何创建和管理数据集分割。
版本
数据集是版本化的,这样每当您在数据集中添加、更新或删除示例时,都会创建一个新的数据集版本。 这使得在出现错误时,可以轻松检查并回滚对数据集的更改。 您还可以为数据集版本打标签,以便赋予它们更易读的英文名称。 这对于标记数据集中的重要里程碑非常有用。
您可以在数据集的特定版本上运行评估。这在 CI 中运行评估时非常有用,可确保数据集更新不会意外破坏您的 CI 流水线。
评估器
评估器是用于衡量您的应用程序在特定示例上表现如何的函数。
评估器输入
评估器接收这些输入:
评估器输出
评估器返回一个或多个指标。这些指标应以字典或字典列表的形式返回,格式如下:
key: 指标的名称。score|value: 指标的值。如果是数值型指标,请使用score;如果是分类指标,请使用value。comment(可选):用于解释该评分的推理过程或附加字符串信息。
定义评估器
有多种方式可以定义和运行评估器:
- 自定义代码: 将 自定义评估器 定义为 Python 或 TypeScript 函数,并使用 SDK 在客户端运行,或通过 UI 在服务器端运行。
- 内置评估器: LangSmith 拥有多个内置评估器,您可以通过 UI 进行配置和运行。
您可以使用 LangSmith SDK(Python 和 TypeScript)运行评估器,或通过 提示词游乐场 运行,也可以配置 规则 以在特定的追踪项目或数据集上自动运行它们。
评估技术
LLM评估有几种高级方法:
人类
人工评估通常是评估的绝佳起点。 LangSmith 让您能够轻松审查您的 LLM 应用输出以及追踪(所有中间步骤)。
LangSmith 的 标注队列 可让您轻松获取对应用程序输出的用户反馈。
启发式
启发式评估器是确定性的、基于规则的函数。它们适用于简单的检查,例如确保聊天机器人的回复不为空、生成的代码片段可以编译,或者分类结果完全正确。
LLM-as-judge
LLM-as-judge 评估器使用大语言模型(LLM)对应用程序的输出进行评分。要使用它们,通常需要将评分规则或标准编码到 LLM 的提示词中。它们可以是无参考的(例如,检查系统输出是否包含不当内容或是否符合特定标准),也可以将任务输出与参考输出进行比较(例如,检查输出相对于参考是否在事实层面准确)。
使用LLM-as-judge评估器时,仔细审查生成的评分并在需要时调整评估提示至关重要。通常将这些编写为少样本评估器会有所帮助,即在评估提示中提供输入、输出和预期评分的示例。
了解如何定义一个\"LLM-as-a-judge\"评估器。
成对比较
成对评估器允许您比较应用程序两个版本的输出。 请想象 LMSYS 聊天机器人竞技场——这是相同的概念,但更广泛地应用于 AI 应用程序,而不仅仅是模型! 它可以使用启发式规则(\"哪个响应更长\")、大型语言模型(带有特定的成对提示)或人工(要求他们手动标注示例)来实现。
何时应使用成对评估?
成对评估在难以直接为 LLM 输出打分,但更容易比较两个输出时非常有用。 这种情况可能出现在摘要任务中——给一个摘要给出绝对评分可能很难,但选择两个摘要中哪一个信息量更大则相对容易。
学习 如何运行成对评估。
实验
每次我们在数据集上评估一个应用程序时,都是在进行一次实验。 实验包含将您应用程序的特定版本在该数据集上运行后的结果。 要了解如何使用 LangSmith 实验视图,请参阅如何分析实验结果。

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

标注队列
人类反馈通常是你能为应用程序收集到的最有价值的反馈。 通过 标注队列,你可以标记应用程序的运行以便进行标注。 人类标注员随后拥有一个简化的视图,用于审查队列中的运行并提供反馈。 通常(部分)这些已标注的运行会被转移到 数据集 中,以供未来评估使用。 虽然你始终可以 内联标注运行,但标注队列提供了另一种选项,可将运行分组、指定标注标准并配置权限。
了解更多关于标注队列和人类反馈的内容。
离线评估
在数据集上评估应用程序是我们所称的“离线”评估。 之所以称为离线,是因为我们在预先编译的数据集上进行评估。 另一方面,在线评估是指在近实时环境中,对已部署应用程序的输出在实际流量上的评估。 离线评估用于在部署前测试您的应用程序的一个或多个版本。
您可以使用 LangSmith SDK(Python 和 TypeScript)在客户端进行离线评估。您也可以通过 提示词游乐场 在服务器端运行评估,或通过配置 自动化流程,针对特定数据集对每个新实验自动运行某些评估器。

基准测试
或许最常见的离线评估类型是:我们整理一组具有代表性的输入数据集,定义关键性能指标,并对应用程序的多个版本进行基准测试,以找出最佳版本。 基准测试可能非常耗时,因为对于许多应用场景,您需要整理包含金标准参考输出的数据集,并设计良好的指标,以便将实验输出与这些参考输出进行比较。 对于一个 RAG(检索增强生成)问答机器人,这可能表现为一个由问题和参考答案组成的数据集,以及一个“大语言模型即裁判”评估器,用于判断实际回答在语义上是否与参考答案等价。 对于一个 ReACT 智能体,这可能表现为一个由用户请求组成的数据集和一个参考工具调用集合(即模型本应执行的所有工具调用),以及一个启发式评估器,用于检查是否执行了所有参考中的工具调用。
单元测试
单元测试用于软件开发中验证各个系统组件的正确性。 在大型语言模型(LLM)语境下的单元测试通常基于规则的断言,针对 LLM 的输入或输出(例如,检查 LLM 生成的代码能否编译、JSON 能否被加载等),以验证基本功能。
单元测试通常编写时期望它们始终通过。 这类测试作为 CI 的一部分运行非常合适。 注意,在执行此类操作时,设置缓存以最小化 LLM 调用次数(因为这些调用可能会迅速累积!)是非常有用的。
回归测试
回归测试用于衡量应用程序在不同版本之间的性能随时间的变化。 它们至少用于确保新版本不会在旧版本能正确处理的示例上出现性能退化,理想情况下还能衡量新版本相对于当前版本的改进程度。 通常,当您进行预期会影响用户体验的应用程序更新(例如更新模型或架构)时,会触发这些测试。
LangSmith 的比较视图原生支持回归测试,使您能够快速查看相对于基线发生变化的示例。 回归问题以红色高亮显示,改进项以绿色高亮显示。

回测
回测是一种结合数据集创建(如上所述)与评估的方法。如果你拥有生产日志集合,可以将其转化为数据集。随后,你可以使用更新的应用程序版本重新运行这些生产示例。这使得你能够评估模型在过往且贴近真实场景的用户输入上的表现。
这通常用于评估新模型版本。 Anthropic 发布了新模型?没问题!通过您的应用获取最近的 1000 次运行,并将它们传入新模型。 然后将这些结果与生产环境中实际发生的情况进行比较。
成对评估
对于某些任务,让人类或 LLM 评估者判断“版本 A 是否优于版本 B"}
学习 如何运行成对评估。
在线评估
在(大致)实时评估已部署应用程序的输出,就是我们所说的“在线”评估。 在这种情况下,不涉及数据集,也没有参考输出的可能性——我们在产生真实输入和真实输出时,直接在它们上面运行评估器。 这对于监控您的应用程序并标记意外行为非常有用。 在线评估也可以与离线评估协同工作:例如,在线评估器可用于将输入问题分类为一组类别,这些类别随后可用于策划用于离线评估的数据集。
在线评估器通常设计为在服务器端运行。LangSmith 内置了 LLM-as-judge 评估器,您可以对其进行配置,也可以定义自定义代码评估器,这些评估器同样在 LangSmith 内运行。

测试
评估与测试
测试和评估是非常相似且相互重叠的概念,经常被混淆。
评估根据一个或多个指标来衡量性能。 评估指标可能是模糊的或主观的,在相对意义上比绝对意义更有用。 也就是说,它们通常用于比较两个系统之间的差异,而不是用来断言关于某个独立系统的结论。
测试断言正确性。 系统只有通过所有测试才能部署。
评估指标可以转化为测试。 例如,您可以编写回归测试,断言系统的任何新版本在相关评估指标上必须优于该系统的某些基线版本。
如果您的系统运行成本高昂,且测试和评估使用的数据集存在重叠,那么将测试和评估一起运行可能会更加节省资源。
您也可以选择使用标准的软件测试工具(如 pytest 或 vitest/jest)来编写评估,以方便操作。
使用 pytest 和 vitest/jest
LangSmith SDK 提供了对 pytest 和 vitest/jest 的集成。 这使得以下操作变得简单:
- 在 LangSmith 中跟踪测试结果
- 将评估编写为测试
在 LangSmith 中跟踪测试结果可以轻松共享结果、比较系统和调试失败的测试。
将评估编写为测试在以下情况下很有用:每个需要评估的示例都需要自定义逻辑来运行应用程序和/或评估器。 标准评估流程假设您能以相同的方式在数据集中的每个示例上运行应用程序和评估器。 但对于更复杂的系统或全面的评估,您可能希望使用特定类型的输入和指标来评估系统的特定子集。 这类异构评估作为一组独立的测试用例编写要容易得多,所有用例都会被统一跟踪,而不是使用标准的评估流程。
使用测试工具在想要 同时 评估系统输出 和 断言其基本特性时也很有帮助。
应用特定技术
下面,我们将讨论几个特定、流行的 LLM 应用的评估。
代理
由大型语言模型驱动的自主智能体 结合了三个组件:(1) 工具调用,(2) 记忆,以及 (3) 规划。智能体 利用工具调用,结合规划(例如,通常通过提示实现)和记忆(例如,通常是短期的消息历史),以生成响应。工具调用 使模型能够根据给定提示生成两样内容:(1) 要调用的工具,以及 (2) 所需的输入参数。

以下是 LangGraph 中的一个工具调用智能体。assistant node 是一个大语言模型(LLM),它根据输入决定是否需要调用工具。tool condition 检查assistant node是否选择了某个工具,如果是,则路由到tool node。tool node执行该工具,并将输出作为工具消息返回给assistant node。只要assistant node选择了一个工具,这个循环就会持续进行。如果没有选择任何工具,则智能体直接返回大语言模型的响应。

这设置了用户通常感兴趣的三种通用类型的智能体评估:
Final Response: 评估代理的最终响应。Single step: 独立评估任意智能体步骤(例如,它是否选择了合适的工具)。Trajectory: 评估代理是否走了预期的路径(例如工具调用序列)以得出最终答案。

下面我们将介绍这些内容、每种评估所需的组件(输入、输出、评估器),以及何时应考虑使用它们。 请注意,您可能需要进行多种(如果不是全部!)类型的评估——它们并非互斥的!
评估智能体的最终响应
评估代理的一种方法是评估其在任务上的整体表现。这基本上涉及将代理视为黑盒,并简单地评估它是否完成了工作。
输入应为用户输入和(可选)工具列表。在某些情况下,工具作为代理的一部分被硬编码,无需传入。在其他情况下,代理更为通用,意味着它没有固定的工具集,需要在运行时传入工具。
输出应为智能体的最终响应。
评估器根据您要求代理执行的任务而有所不同。许多代理执行相对复杂的步骤集并输出最终的文本响应。与 RAG 类似,LLM-as-judge(大语言模型作为裁判)评估器在这些情况下通常很有效,因为它们可以直接从文本响应中评估代理是否完成了任务。
然而,这种类型的评估存在几个缺点。首先,它通常需要一些时间才能运行。其次,您没有评估智能体内部发生的任何内容,因此当失败发生时很难进行调试。第三,有时很难定义适当的评估指标。
评估智能体的单一步骤
代理通常执行多个操作。虽然端到端地评估它们很有用,但评估这些单个操作也很有用。这通常涉及评估代理的单个步骤——即它决定做什么的 LLM 调用。
输入应为单个步骤的输入。根据您测试的内容,这可能仅仅是原始用户输入(例如,一个提示和/或一组工具),也可能包括先前已完成的步骤。
输出仅是该步骤的输出,通常是 LLM 的响应。LLM 响应通常包含工具调用,指示代理下一步应采取的操作。
\ 此评估器通常使用二元分数来判断是否选择了正确的工具调用,以及使用某种启发式方法判断输入到工具的内容是否正确。参考工具可以简单地指定为字符串。
这种类型的评估有诸多好处。它允许你评估单个动作,从而帮助你精准定位应用可能出错的环节。此外,它们的运行速度相对较快(因为它们仅涉及一次 LLM 调用),并且评估通常采用简单的启发式方法,将所选工具与参考工具进行比较。一个缺点是它们无法捕捉完整的智能体行为——仅针对某一个特定步骤。另一个缺点是数据集的构建可能具有挑战性,特别是当你希望将历史上下文纳入智能体输入时。为智能体轨迹早期的步骤生成数据集相当容易(例如,可能仅包含输入提示),但为轨迹后期的步骤生成数据集则较为困难(例如,需包含大量先前的智能体动作和响应)。
评估代理的轨迹
评估智能体的轨迹涉及评估智能体所采取的所有步骤。
输入再次是整体智能体的输入(用户输入,以及可选的工具列表)。
输出是一系列工具调用,可以表述为“精确”轨迹(例如,预期的工具调用序列),或者仅仅是一组预期的工具调用(顺序不限)。
此处的评估器是对所采取步骤的某种函数。评估“精确”轨迹可以使用单一的二元分数,该分数确认序列中每个工具名称的完全匹配。这种方法虽然简单,但存在一些缺陷。有时可能存在多条正确的路径。此外,这种评估方式无法区分轨迹仅偏离一步与完全错误的情况。
为了解决这些缺陷,评估指标可以聚焦于所采取的“错误”步骤数量,从而更好地区分轨迹的接近程度与显著偏离。评估指标也可以关注是否以任意顺序调用了所有预期工具。
然而,这些方法均未评估输入到工具的内容;它们仅关注所选的工具。为了解决这一问题,另一种评估技术是将代理的完整轨迹(连同参考轨迹)作为一组消息(例如所有 LLM 响应和工具调用)传递给“LLM-as-judge"
检索增强生成 (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-as-judge? | 成对相关 |
|---|---|---|---|---|
| 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 of texts to summarize are commonly used for evaluation (see a dataset example here). However, user logs from a production (summarization) app can be used for online evaluation with any of the Reference-free evaluation prompts below.
LLM-as-judge 通常用于评估摘要生成(以及其他类型的写作),方法是使用 Reference-free 提示词,这些提示词遵循提供的标准对摘要进行评分。较少见的是提供特定的 Reference 摘要,因为摘要生成是一项创造性任务,存在许多可能的正确答案。
Online 或 Offline 的评估是可行的,因为使用了 Reference-free 提示。Pairwise 评估也是一种强大的方法,可用于比较不同的摘要链(例如,不同的摘要提示或大语言模型):
| 应用场景 | 详情 | 需要参考输出 | LLM-as-judge? | 成对相关 |
|---|---|---|---|---|
| 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根据指定标准对输入进行分类/标记(无需真实参考)。
Online 或 Offline 的评估在使用 LLM-as-judge 配合 Reference-free 提示词时是可行的。特别是,当用户希望标记/分类应用程序输入(例如,用于毒性检测等)时,这非常适合用于 Online 评估。
| 应用场景 | 详情 | 需要参考输出 | LLM-as-judge? | 成对相关 |
|---|---|---|---|---|
| Accuracy | Standard definition | Yes | No | No |
| Precision | Standard definition | Yes | No | No |
| Recall | Standard definition | Yes | No | No |
实验配置
LangSmith 支持多种实验配置,使您能够以更符合需求的方式运行评估。
重复
多次运行实验可能很有帮助,因为大语言模型(LLM)的输出不是确定性的,每次重复的结果可能会有所不同。通过运行多次重复实验,您可以更准确地评估系统的性能。
重复次数可以通过向 num_repetitions 参数传递至 evaluate / aevaluate 来配置(Python,TypeScript)。 重复实验包括重新运行目标函数以生成输出,以及重新运行评估器。
要了解有关在实验中运行重复操作的更多信息,请阅读操操作指南。
并发
通过将 max_concurrency 参数传递给 evaluate / aevaluate,您可以指定实验的并发数。
max_concurrency 参数的语义根据您使用的是 evaluate 还是 aevaluate 而略有不同。
evaluate
max_concurrency 参数指定在运行实验时使用的最大并发线程数。 这既适用于运行您的目标函数,也适用于运行评估器。
aevaluate
max_concurrency 参数与 aevaluate 非常相似,但改用信号量来限制可同时运行的并发任务数量。aevaluate 通过为数据集中的每个示例创建一个任务来工作。每个任务包括在特定示例上运行目标函数以及所有评估器。max_concurrency 参数指定最大并发任务数,换句话说,即同时可处理的示例数量。
缓存
最后,您还可以通过将 LANGSMITH_TEST_CACHE 设置为设备上具有写入权限的有效文件夹来缓存实验中进行的 API 调用。 这将导致实验中进行的 API 调用被缓存到磁盘,意味着将来进行相同 API 调用的实验将大大加速。