评估概念
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）通过 Prompt Playground 或通过配置 规则 在特定的追踪项目或数据集上自动运行评估器来运行评估器。
评估技术
有几种 LLM 评估的高级方法
人工
人工评估是评估的良好起点。LangSmith 使您可以轻松查看您的 LLM 应用程序输出以及追踪（所有中间步骤）。
LangSmith 的注释队列使您可以轻松获得关于您的应用程序输出的人工反馈。
启发式
启发式评估器是确定性的、基于规则的函数。这些适用于简单的检查，例如确保聊天机器人的响应不是空的，生成的代码片段可以编译，或者分类完全正确。
LLM-as-judge
LLM-as-judge 评估器使用 LLM 对应用程序的输出进行评分。要使用它们，您通常需要在 LLM prompt 中编码评分规则/标准。它们可以是无参考的（例如，检查系统输出是否包含冒犯性内容或是否符合特定标准）。或者，它们可以将任务输出与参考输出进行比较（例如，检查输出相对于参考是否在事实上准确）。
使用 LLM-as-judge 评估器时，仔细审查结果分数并在需要时调整评分器 prompt 非常重要。通常，将这些编写为少样本评估器会很有帮助，您可以在其中提供输入、输出和预期等级的示例作为评分器 prompt 的一部分。
成对
成对评估器允许您比较应用程序两个版本的输出。想想 LMSYS Chatbot Arena - 这是相同的概念，但更普遍地应用于 AI 应用程序，而不仅仅是模型！这可以使用启发式方法（“哪个响应更长”）、LLM（具有特定的成对 prompt）或人工（要求他们手动注释示例）。
何时应使用成对评估？
当难以直接对 LLM 输出进行评分，但更容易比较两个输出时，成对评估很有帮助。对于诸如摘要之类的任务，情况可能就是这样 - 可能很难给摘要一个绝对分数，但很容易选择两个摘要中哪个信息量更大。
了解如何运行成对评估。
实验
每次我们在数据集上评估应用程序时，我们都在进行实验。实验包含在数据集上运行特定版本的应用程序的结果。要了解如何使用 LangSmith 实验视图，请参阅如何分析实验结果。
通常，我们会在给定的数据集上运行多个实验，测试应用程序的不同配置（例如，不同的 prompt 或 LLM）。在 LangSmith 中，您可以轻松查看与您的数据集关联的所有实验。此外，您可以在比较视图中比较多个实验。
注释队列
人工反馈通常是您可以收集到的关于您的应用程序的最有价值的反馈。使用注释队列，您可以标记应用程序的运行以进行注释。然后，人工注释员可以获得简化的视图，以查看队列中的运行并提供反馈。通常，（这些注释运行的某个子集）然后被转移到数据集以供将来评估。虽然您可以随时内联注释运行，但注释队列提供了另一种选择，可以将运行分组在一起，指定注释标准并配置权限。
了解有关注释队列和人工反馈的更多信息。
离线评估
在数据集上评估应用程序是我们所说的“离线”评估。它是离线的，因为我们正在预编译的数据集上进行评估。另一方面，在线评估是在近乎实时的真实流量中评估已部署应用程序的输出的评估。离线评估用于在部署前测试应用程序的一个或多个版本。
您可以使用 LangSmith SDK（Python 和 TypeScript）在客户端运行离线评估。您可以通过 Prompt Playground 或通过配置 自动化 以在针对特定数据集的每个新实验上运行某些评估器，在服务器端运行它们。
基准测试
也许最常见的离线评估类型是，我们管理代表性输入的数据集，定义关键性能指标，并对应用程序的多个版本进行基准测试以找到最佳版本。基准测试可能很费力，因为对于许多用例，您必须管理具有黄金标准参考输出的数据集，并设计良好的指标来将实验输出与它们进行比较。对于 RAG 问答机器人，这可能看起来像问题和参考答案的数据集，以及 LLM-as-judge 评估器，用于确定实际答案是否在语义上等同于参考答案。对于 ReACT Agent，这可能看起来像用户请求数据集和模型应进行的所有工具调用的参考集，以及检查是否进行了所有参考工具调用的启发式评估器。
单元测试
单元测试在软件开发中用于验证各个系统组件的正确性。LLM 上下文中的单元测试通常是基于规则的断言，针对 LLM 输入或输出（例如，检查 LLM 生成的代码是否可以编译，JSON 是否可以加载等），以验证基本功能。
单元测试通常编写时期望它们应该始终通过。这些类型的测试非常适合作为 CI 的一部分运行。请注意，在这样做时，设置缓存以最大程度地减少 LLM 调用很有用（因为这些调用会很快累积！）。
回归测试
回归测试用于衡量应用程序各个版本在一段时间内的性能。它们至少用于确保新应用程序版本不会在当前版本正确处理的示例上退步，理想情况下，用于衡量新版本相对于当前版本有多好。通常，当您进行预计会影响用户体验的应用程序更新（例如，更新模型或架构）时，会触发这些测试。
LangSmith 的比较视图对回归测试具有原生支持，使您可以快速查看相对于基线已更改的示例。退步以红色突出显示，改进以绿色突出显示。
回溯测试
回溯测试是一种将数据集创建（如上所述）与评估相结合的方法。如果您有生产日志的集合，您可以将它们变成数据集。然后，您可以使用较新的应用程序版本重新运行这些生产示例。这使您可以评估过去和真实的用户输入的性能。
这通常用于评估新的模型版本。Anthropic 发布了一个新模型？没问题！获取通过您的应用程序的 1000 个最新运行，并通过新模型传递它们。然后将这些结果与生产中实际发生的情况进行比较。
成对评估
对于某些任务，人类或 LLM 评分器更容易确定“版本 A 比 B 更好”，而不是为 A 或 B 分配绝对分数。成对评估就是这样——对两个版本的输出进行相互评分，而不是针对某些参考输出或绝对标准进行评分。当在更一般的任务上使用 LLM-as-judge 评估器时，成对评估通常很有用。例如，如果您有一个摘要器应用程序，LLM-as-judge 可能更容易确定“这两个摘要中哪个更清晰简洁？”，而不是给出像“就清晰度和简洁度而言，给这个摘要 1-10 分的分数”这样的绝对分数。
了解如何运行成对评估。
在线评估
在（大致）实时评估已部署应用程序的输出是我们所说的“在线”评估。在这种情况下，不涉及数据集，也不可能获得参考输出——我们正在对产生的真实输入和真实输出运行评估器。这对于监视您的应用程序和标记意外行为很有用。在线评估还可以与离线评估协同工作：例如，在线评估器可用于将输入问题分类为一组类别，这些类别稍后可用于管理数据集以进行离线评估。
在线评估器通常旨在在服务器端运行。LangSmith 具有内置的LLM-as-judge 评估器，您可以对其进行配置，或者您可以定义也在 LangSmith 中运行的自定义代码评估器。
测试
评估与测试
测试和评估是非常相似且重叠的概念，它们经常被混淆。
评估根据指标衡量性能。 评估指标可以是模糊的或主观的，并且相对于绝对指标，在相对意义上更有用。也就是说，它们通常用于比较两个系统，而不是断言关于单个系统的某些内容。
测试断言正确性。 只有当系统通过所有测试时，才能部署系统。
评估指标可以转化为测试。例如，您可以编写回归测试来断言，任何新版本的系统都必须在相关的评估指标上优于系统的某些基线版本。
如果您的系统运行成本很高，并且您的测试和评估有重叠的数据集，则将测试和评估一起运行也可能更节省资源。
您还可以选择使用标准软件测试工具（如 pytest 或 vitest/jest）来编写评估，以方便使用。
使用 pytest 和 vitest/jest
LangSmith SDK 附带 pytest 和 vitest/jest 的集成。这些使其易于
- 在 LangSmith 中追踪测试结果
- 将评估编写为测试
在 LangSmith 中追踪测试结果可以轻松共享结果、比较系统和调试失败的测试。
当您要评估的每个示例都需要自定义逻辑来运行应用程序和/或评估器时，将评估编写为测试可能很有用。标准评估流程假定您可以在数据集中的每个示例上以相同的方式运行应用程序和评估器。但是对于更复杂的系统或全面的评估，您可能希望使用特定类型的输入和指标来评估系统的特定子集。这些类型的异构评估更容易编写为一组不同的测试用例，这些测试用例都被一起追踪，而不是使用标准评估流程。
当您想要同时评估系统的输出并断言关于它们的一些基本内容时，使用测试工具也很有帮助。
特定于应用程序的技术
下面，我们将讨论一些特定的、流行的 LLM 应用程序的评估。
Agent
LLM 驱动的自主 Agent 结合了三个组件：（1）工具调用，（2）内存，和（3）规划。Agent 使用工具调用 进行规划（例如，通常通过 prompt）和内存（例如，通常是短期消息历史记录）来生成响应。工具调用 允许模型通过生成两件事来响应给定的 prompt：（1）要调用的工具和（2）所需的输入参数。
下面是 LangGraph 中的工具调用 Agent。assistant node 是一个 LLM，它根据输入确定是否调用工具。tool condition 查看 assistant node 是否选择了工具，如果选择了，则路由到 tool node。tool node 执行工具并将输出作为工具消息返回给 assistant node。只要 assistant node 选择工具，此循环就会继续。如果未选择任何工具，则 Agent 直接返回 LLM 响应。
这设置了用户通常感兴趣的三种 Agent 评估类型
最终响应：评估 Agent 的最终响应。单步：隔离评估任何 Agent 步骤（例如，它是否选择了合适的工具）。轨迹：评估 Agent 是否采取了预期的路径（例如，工具调用的路径）来获得最终答案。
下面我们将介绍这些内容是什么，每个内容所需的组件（输入、输出、评估器），以及何时应考虑这样做。请注意，您可能想要进行多种（如果不是全部！）这些类型的评估 - 它们不是互斥的！
评估 Agent 的最终响应
评估 Agent 的一种方法是评估其在任务上的整体性能。这基本上涉及将 Agent 视为黑匣子，并简单地评估它是否完成了工作。
输入应该是用户输入和（可选）工具列表。在某些情况下，工具作为 Agent 的一部分硬编码，它们不需要传入。在其他情况下，Agent 更通用，这意味着它没有固定的工具集，需要在运行时传入工具。
输出应该是 Agent 的最终响应。
评估器因您要求 Agent 执行的任务而异。许多 Agent 执行相对复杂的步骤集，并输出最终文本响应。与 RAG 类似，LLM-as-judge 评估器通常在这些情况下对于评估有效，因为它们可以直接从文本响应中评估 Agent 是否完成了工作。
但是，这种类型的评估有几个缺点。首先，它通常需要一段时间才能运行。其次，您没有评估 Agent 内部发生的任何事情，因此当发生故障时可能很难调试。第三，有时可能很难定义合适的评估指标。
评估 Agent 的单步
Agent 通常执行多个操作。虽然端到端评估它们很有用，但评估这些单个操作也可能很有用。这通常涉及评估 Agent 的单步 - 它决定下一步做什么的 LLM 调用。
输入应该是单步的输入。根据您要测试的内容，这可能只是原始用户输入（例如，prompt 和/或一组工具），或者它也可以包括先前完成的步骤。
输出只是该步骤的输出，通常是 LLM 响应。LLM 响应通常包含工具调用，指示 Agent 接下来应采取的操作。
此评估器的通常是一些二进制分数，用于指示是否选择了正确的工具调用，以及一些启发式方法，用于指示工具的输入是否正确。参考工具可以简单地指定为字符串。
这种评估方式有几个好处。它允许你评估单个操作，从而让你能够 точно 定位应用程序可能失败的地方。它们运行速度也相对较快（因为它们只涉及一次 LLM 调用），并且评估通常使用相对于参考工具的简单启发式评估方法来评估所选工具。一个缺点是它们无法捕捉到完整的 agent——只能捕捉到特定的步骤。另一个缺点是数据集的创建可能具有挑战性，特别是如果你想在 agent 输入中包含过去的历史记录。为 agent 轨迹早期步骤生成数据集非常容易（例如，这可能只包括输入提示），但为轨迹后期步骤生成数据集可能很困难（例如，包括许多先前的 agent 操作和响应）。
评估 agent 的轨迹
评估 agent 的轨迹涉及评估 agent 执行的所有步骤。
输入仍然是 agent 的整体输入（用户输入，以及可选的工具列表）。
输出是工具调用的列表，可以表示为“精确”轨迹（例如，工具调用的预期序列），或者仅仅是一组预期的工具调用（顺序不限）。
这里的评估器是关于所采取步骤的某种函数。评估“精确”轨迹可以使用单个二元分数，该分数确认序列中每个工具名称的完全匹配。这很简单，但存在一些缺陷。有时可能存在多个正确的路径。这种评估也没有捕捉到轨迹偏差一个步骤与完全错误之间的区别。
为了解决这些缺陷，评估指标可以侧重于所采取的“不正确”步骤的数量，这更好地解释了接近正确的轨迹与偏差很大的轨迹之间的差异。评估指标还可以侧重于是否按任意顺序调用了所有预期的工具。
然而，这些方法都没有评估工具的输入；它们只关注所选的工具。为了解决这个问题，另一种评估技术是将完整的 agent 轨迹（以及参考轨迹）作为一组消息（例如，所有 LLM 响应和工具调用）传递给 LLM-as-judge。这可以评估 agent 的完整行为，但它是最难编译的参考（幸运的是，使用像 LangGraph 这样的框架可以对此有所帮助！）。另一个缺点是评估指标可能有些难以制定。
检索增强生成 (RAG)
检索增强生成 (RAG) 是一种强大的技术，它涉及根据用户输入检索相关文档，并将它们传递给语言模型进行处理。RAG 使 AI 应用程序能够通过利用外部知识来生成更明智和上下文感知的响应。
有关 RAG 概念的全面回顾，请参阅我们的 RAG From Scratch 系列。
数据集
在评估 RAG 应用程序时，一个关键的考虑因素是你是否拥有（或可以轻松获得）每个输入问题的参考答案。参考答案作为评估生成响应正确性的 ground truth。然而，即使在没有参考答案的情况下，仍然可以使用无参考 RAG 评估提示执行各种评估（下面提供了示例）。
评估器
LLM-as-judge 是 RAG 常用的评估器，因为它是一种评估文本之间事实准确性或一致性的有效方法。
在评估 RAG 应用程序时，你可以使用需要参考输出的评估器和不需要参考输出的评估器
- 需要参考输出：将 RAG 链生成的答案或检索结果与参考答案（或检索结果）进行比较，以评估其正确性。
- 不需要参考输出：使用不需要参考答案的提示执行自我一致性检查（在上图中用橙色、绿色和红色表示）。
应用 RAG 评估
在应用 RAG 评估时，请考虑以下方法
-
离线评估：对任何依赖于参考答案的提示使用离线评估。这最常用于 RAG 答案正确性评估，其中参考是 ground truth（正确）答案。 -
在线评估：对任何无参考提示采用在线评估。这允许你评估 RAG 应用程序在实时场景中的性能。 -
成对评估：利用成对评估来比较不同 RAG 链产生的答案。这种评估侧重于用户指定的标准（例如，答案格式或风格），而不是正确性，正确性可以使用自我一致性或 ground truth 参考来评估。
RAG 评估总结
| 评估器 | 详情 | 需要参考输出 | LLM-as-judge？ | 成对相关性 |
|---|---|---|---|---|
| 文档相关性 | 文档是否与问题相关？ | 否 | 是 - prompt | 否 |
| 答案忠实度 | 答案是否基于文档？ | 否 | 是 - prompt | 否 |
| 答案帮助性 | 答案是否有助于解决问题？ | 否 | 是 - prompt | 否 |
| 答案正确性 | 答案是否与参考答案一致？ | 是 | 是 - prompt | 否 |
| 成对比较 | 多个答案版本如何比较？ | 否 | 是 - prompt | 是 |
摘要
摘要是一种特定类型的自由形式写作。评估目的通常是检查写作（摘要）相对于一组标准。
文本摘要的 开发者策划的示例 通常用于评估（请参阅 此处 的数据集示例）。但是，来自生产（摘要）应用程序的 用户日志 可以与下面的任何 无参考 评估提示一起用于在线评估。
LLM-as-judge 通常用于摘要评估（以及其他类型的写作），使用 无参考 提示，这些提示遵循提供的标准来对摘要进行评分。提供特定的 参考 摘要不太常见，因为摘要是一项创造性任务，并且存在许多可能的正确答案。
由于使用了 无参考 提示，在线 或 离线 评估是可行的。成对 评估也是执行不同摘要链之间比较的强大方法（例如，不同的摘要提示或 LLM）。
| 用例 | 详情 | 需要参考输出 | LLM-as-judge？ | 成对相关性 |
|---|---|---|---|---|
| 事实准确性 | 摘要相对于源文档是否准确？ | 否 | 是 - prompt | 是 |
| 忠实度 | 摘要是否基于源文档（例如，没有幻觉）？ | 否 | 是 - prompt | 是 |
| 帮助性 | 摘要对于用户需求是否有帮助？ | 否 | 是 - prompt | 是 |
分类和标记
分类和标记将标签应用于给定的输入（例如，用于毒性检测、情感分析等）。分类/标记评估通常采用以下组件，我们将在下面详细回顾这些组件
分类/标记评估的一个核心考虑因素是你是否拥有带有 参考 标签的数据集。如果没有，用户通常希望定义一个评估器，该评估器使用标准将标签（例如，毒性等）应用于输入（例如，文本、用户问题等）。但是，如果提供了 ground truth 类标签，则评估目标侧重于相对于 ground truth 类标签对分类/标记链进行评分（例如，使用诸如精确率、召回率等指标）。
如果提供了 ground truth 参考标签，则通常只需定义一个 自定义启发式评估器，以将 ground truth 标签与链输出进行比较。然而，考虑到 LLM 的兴起，越来越常见的是简单地使用 LLM-as-judge 基于指定的标准（无需 ground truth 参考）对输入执行分类/标记。
当使用带有 无参考 提示的 LLM-as-judge 时，在线 或 离线 评估是可行的。特别是，当用户想要标记/分类应用程序输入（例如，用于毒性等）时，这非常适合 在线 评估。
| 用例 | 详情 | 需要参考输出 | LLM-as-judge？ | 成对相关性 |
|---|---|---|---|---|
| 准确率 | 标准定义 | 是 | 否 | 否 |
| 精确率 | 标准定义 | 是 | 否 | 否 |
| 召回率 | 标准定义 | 是 | 否 | 否 |
实验配置
LangSmith 支持多种实验配置，这些配置使你可以更轻松地以你想要的方式运行评估。
重复次数
多次运行实验可能很有帮助，因为 LLM 输出不是确定性的，并且可能因一次重复到下一次重复而有所不同。通过运行多次重复，你可以更准确地估计系统的性能。
可以通过将 num_repetitions 参数传递给 evaluate / aevaluate 来配置重复次数（Python, TypeScript）。重复实验涉及重新运行目标函数以生成输出，以及重新运行评估器。
要了解有关在实验中运行重复次数的更多信息，请阅读 操作指南。
并发
通过将 max_concurrency 参数传递给 evaluate / aevaluate，你可以指定实验的并发性。max_concurrency 参数的语义略有不同，具体取决于你使用的是 evaluate 还是 aevaluate。
evaluate
evaluate 的 max_concurrency 参数指定运行实验时要使用的最大并发线程数。这既适用于运行目标函数时，也适用于运行评估器时。
aevaluate
aevaluate 的 max_concurrency 参数与 evaluate 非常相似，但它使用信号量来限制可以同时运行的任务数。aevaluate 的工作原理是为数据集中的每个示例创建一个任务。每个任务包括在特定示例上运行目标函数以及所有评估器。max_concurrency 参数指定最大并发任务数，或者换句话说 - 一次运行的示例数。
缓存
最后，你还可以通过将 LANGSMITH_TEST_CACHE 设置为设备上具有写入权限的有效文件夹来缓存实验中进行的 API 调用。这将导致实验中进行的 API 调用被缓存到磁盘，这意味着未来进行相同 API 调用的实验将大大加速。