评估概念

人工智能应用的质量和开发速度往往受限于高质量的评估数据集和评估指标，这些数据集和指标能够帮助您优化并测试您的应用程序。

LangSmith 让构建高质量评估变得轻松简单。 本指南将介绍 LangSmith 评估框架，以及更广泛的 AI 评估技术。 LangSmith 框架的基本构成要素包括：

• 数据集: 测试输入和参考输出的集合。
• 评估器：用于对输出结果进行评分的函数。

数据集

数据集是一组用于评估应用程序的示例集合。每个示例均由测试输入和参考输出组成一对。

示例

每个示例均包含：

• 输入：传递给应用程序的输入变量字典。
• 参考输出（可选）：一个参考输出字典。这些输出不会传递给您的应用程序，仅用于评估器中。
• 元数据（可选）：一个包含额外信息的字典，可用于创建数据集的筛选视图。

数据集整理

构建评估数据集的方法多种多样，包括：

人工整理的示例

这是我们通常推荐人们创建数据集的入门方式。 在构建您的应用程序时，您可能已经对应用程序需要处理的输入类型，以及何为“优质”响应有了一定的了解。 您可能希望覆盖一些您能想到的常见边缘情况或典型场景。 即使仅有 10–20 个高质量、人工精心筛选的示例，也能发挥巨大作用。

历史记录

当您的应用投入生产环境后，您便能开始获取宝贵的信息：用户实际上是如何使用它的？ 这些真实场景下的运行实例非常有价值，因为它们本身就是最贴近现实的示例！

如果您的应用流量很大，该如何判断哪些运行记录值得添加到数据集中？ 您可以采用以下几种技术：

• 用户反馈：如果可能，请尽量收集终端用户的反馈。这样您就能识别出哪些数据点收到了负面反馈。 这非常有价值！这些正是您的应用表现不佳的地方。 您应将这些数据点添加到数据集中，以便未来进行测试。
• 启发式方法：您还可以使用其他启发式方法来识别“有趣”的数据点。例如，耗时较长才完成的运行可能值得关注，并可将其添加到数据集中。
• 大语言模型反馈：您可以使用另一个大语言模型来识别值得关注的运行实例。例如，您可以利用大语言模型为聊天机器人对话打标签，标记出用户不得不重新表述问题或以某种方式纠正模型的对话，这表明聊天机器人最初未能做出正确响应。

合成数据

当你拥有了几个示例后，就可以尝试人工生成更多示例。 通常建议先准备几个精心设计的手动示例，因为这些合成数据往往会在某种程度上与之相似。 这是一种快速获取大量数据点的有效方法。

分割

在设置评估时，您可能希望将数据集划分为不同的子集。例如，您可以使用较小的子集进行多次快速且成本较低的迭代，而使用较大的子集进行最终评估。此外，划分数据集对于实验结果的可解释性也非常重要。例如，如果您开发的是一个 RAG（检索增强生成）应用，您可能希望数据集的各个子集分别聚焦于不同类型的问题（如事实性问题、观点性问题等），并针对每个子集单独评估您的应用。

了解如何 创建和管理数据集划分。

版本

数据集是版本化的，即每次向数据集中添加、更新或删除示例时，都会创建该数据集的一个新版本。 这使得您在操作失误时，能够轻松检查并回滚对数据集所作的更改。 您还可以为数据集的各个版本打标签，为其指定更易于人类理解的名称。 这对于标记数据集历史中的重要里程碑非常有用。

您可以在数据集的特定版本上运行评估。这在持续集成（CI）环境中运行评估时非常有用，可确保数据集更新不会意外破坏您的 CI 流水线。

评估器

评估器是用于评估您的应用程序在特定示例上表现优劣的函数。

评估器输入

评估器接收以下输入：

• 示例：您数据集中的示例。包含输入、（参考）输出和元数据。
• 运行：将示例输入传递给应用程序后得到的实际输出及中间步骤（子运行）。

评估器输出

评估器返回一个或多个指标。这些指标应以字典形式，或以字典列表的形式返回，格式如下：

• key: 指标名称。
• score | value：该指标的值。若为数值型指标，请使用 score；若为分类指标，请使用 value。
• comment（可选）：用于说明评分理由或提供额外字符串信息。

定义评估器

定义和运行评估器有多种方式：

• 自定义代码：将自定义评估器定义为 Python 或 TypeScript 函数，并使用 SDK 在客户端运行，或通过 UI 在服务端运行。
• 内置评估器：LangSmith 提供了多种内置评估器，您可以通过用户界面进行配置和运行。

您可以通过 LangSmith SDK（Python 和 TypeScript）、提示词游乐场（Prompt Playground），或通过配置规则（Rules）在特定的追踪项目或数据集上自动运行评估器。

评估技术

LLM评估有几种高层次的方法：

人类

人工评估通常是评估工作的一个极佳起点。LangSmith 可帮助您轻松审阅大型语言模型（LLM）应用的输出结果以及追踪记录（即所有中间步骤）。

LangSmith 的 标注队列 可帮助您轻松获取人类对应用程序输出的反馈。

启发式

启发式评估器是确定性的、基于规则的函数。它们适用于简单的检查任务，例如确保聊天机器人的响应不为空、生成的代码片段能够成功编译，或分类结果完全正确。

LLM-as-judge

作为评判者的大型语言模型（LLM-as-judge）评估器利用大语言模型对应用程序的输出进行评分。使用此类评估器时，通常需将评分规则或标准编码至大语言模型的提示词中。它们可以是无需参考答案的（例如：检查系统输出是否包含冒犯性内容，或是否符合特定标准）；也可以将任务输出与参考答案进行比对（例如：检查输出相对于参考答案在事实层面是否准确）。

使用大语言模型作为评判者的评估器时，仔细审查最终得分并在必要时调整评分提示词至关重要。通常，将这类评估器设计为少样本（few-shot）形式会很有帮助，即在评分提示词中提供输入、输出及对应预期评分的示例。

了解 如何定义大语言模型作为裁判的评估器。

成对

成对评估器可用于比较同一应用程序两个版本的输出结果。 类似于LMSYS 聊天机器人竞技场（Chatbot Arena）——这一概念相同，但其应用范围更广，不仅限于大语言模型，还可用于各类人工智能应用程序！ 该评估方式可采用启发式方法（例如“哪个回答更长”）、大语言模型（配合特定的成对比较提示词），或人工评估（请人工对示例进行手动标注）。

何时应使用成对评估？

成对评估在难以直接为大语言模型（LLM）输出打分、但比较两个输出却相对容易时非常有用。 这种情况常见于摘要生成等任务——为单个摘要给出绝对评分可能较为困难，但要从两个摘要中选出信息量更丰富的那一个则相对容易。

学习 如何运行成对评估。

实验

每次我们在数据集上评估一个应用程序时，实际上都在进行一项实验。 一项实验包含在该数据集上运行应用程序特定版本所得到的结果。 如需了解如何使用 LangSmith 实验视图，请参阅 如何分析实验结果。

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

标注队列

人类反馈通常是您能为应用程序收集到的最有价值的反馈。 借助标注队列，您可以将应用程序的运行实例标记为待标注状态。 随后，人工标注员可通过简洁明了的界面，集中审阅并针对队列中的运行实例提供反馈。 通常情况下（部分或全部）这些已标注的运行实例会被导入数据集，用于后续的评估工作。 虽然您始终可以在运行过程中直接进行标注，但标注队列提供了另一种选择：它支持将运行实例分组管理、指定标注标准，并配置相关权限。

进一步了解 标注队列与人工反馈。

离线评估

在数据集上评估应用程序，我们称之为“离线”评估。 之所以称为离线，是因为我们是在一个预先编译好的数据集上进行评估。 而在线评估则指对已部署应用程序的输出，在真实流量中近乎实时地进行评估。 离线评估用于在部署前测试应用程序的一个或多个版本。

您可以使用 LangSmith SDK（Python 和 TypeScript）在客户端离线运行评估。您也可以通过 提示词游乐场（Prompt Playground） 在服务端运行评估，或通过配置 自动化任务（automations），使特定评估器在每次针对指定数据集开展新实验时自动运行。

基准测试

离线评估中最常见的一种方式，是精心构建一个具有代表性的输入数据集，明确定义关键性能指标，并对应用程序的多个版本进行基准测试，以找出最优版本。 基准测试可能十分耗时，因为对于许多应用场景而言，您必须构建一个包含“黄金标准”参考输出的数据集，并设计出良好的评估指标，用以将实验输出与参考输出进行比较。 对于一个基于检索增强生成（RAG）的问答机器人，这可能体现为一个问题与参考答案构成的数据集，以及一个由大语言模型（LLM）担任裁判的评估器，用于判断实际生成的答案是否在语义上等价于参考答案。 对于一个 ReACT 智能体，则可能体现为一组用户请求及其对应的参考工具调用序列（即模型理应执行的所有工具调用），并配有一个启发式评估器，用于检查模型是否执行了全部参考工具调用。

单元测试

单元测试在软件开发中用于验证各个系统组件的正确性。 在大语言模型（LLM）场景下的单元测试通常基于规则对LLM的输入或输出进行断言（例如，检查LLM生成的代码能否成功编译、JSON能否被正确加载等），以验证基本功能。

单元测试通常以“应始终通过”为前提来编写。 这类测试非常适合在持续集成（CI）流程中运行。 请注意，在执行此类测试时，建议设置缓存机制，以尽量减少对大语言模型（LLM）的调用次数（因为这些调用可能迅速累积成本！）。

回归测试

回归测试用于随时间衡量应用程序在不同版本间的性能表现。 其最基本的作用是确保新版本应用程序不会在当前版本能够正确处理的示例上出现性能退化；理想情况下，还可用于量化新版本相较于当前版本的性能提升程度。 通常，当您进行可能影响用户体验的应用程序更新（例如更新模型或架构）时，便会触发此类测试。

LangSmith 的对比视图原生支持回归测试，可让您快速查看相对于基线发生变化的示例。 回归问题以红色高亮显示，改进则以绿色高亮显示。

回测

回测是一种将数据集构建（如上所述）与评估相结合的方法。如果您拥有一组生产环境日志，便可将其转化为数据集；随后，您可使用更新版本的应用程序重新运行这些生产环境中的示例。这使您能够基于过去真实用户的输入来评估系统性能。

这通常用于评估新模型版本。 Anthropic 推出了新模型？没问题！获取您应用程序最近的 1000 次运行记录，并将它们输入新模型中进行处理。 然后，将这些结果与生产环境中实际发生的情况进行对比。

成对评估

对于某些任务，人类或大语言模型（LLM）评分员判断“版本A优于版本B”比为版本A或版本B分别给出绝对分数更为容易。 成对评估正是如此——即对两个版本的输出进行相互比较打分，而非与某个参考输出或绝对标准进行对比。 在针对更通用任务使用LLM作为评判者（LLM-as-judge）时，成对评估往往十分有用。 例如，在摘要生成应用中，让LLM作为评判者判断“这两个摘要中哪一个更清晰简洁？”可能比给出“该摘要在清晰度和简洁性方面得分为1–10分”这样的绝对分数更容易。

学习 如何运行成对评估。

在线评估

对已部署应用程序的输出进行（大致）实时评估，我们称之为“在线”评估。 在这种情况下，不涉及任何数据集，也没有参考输出可供比对——我们是在真实输入和真实输出生成的同时，对其运行评估器。 这种方式有助于监控您的应用程序，并及时发现非预期行为。 在线评估还可以与离线评估协同工作：例如，在线评估器可用于将输入问题分类到一组预定义类别中，这些类别随后可被用于构建离线评估所需的数据集。

在线评估器通常设计为在服务器端运行。LangSmith 内置了大语言模型（LLM）作为评判者的评估器，您可以对其进行配置；您也可以定义自定义代码评估器，这些评估器同样在 LangSmith 内运行。

测试

评估 vs 测试

测试与评估是非常相似且相互重叠的概念，常常被混淆。

评估通过一个或多个指标来衡量模型性能。 评估指标可能较为模糊或具有主观性，其相对意义通常大于绝对意义。 也就是说，它们通常用于比较两个系统之间的优劣，而非对单个系统的性能做出绝对性断言。

测试用于验证正确性。 只有通过所有测试的系统才能部署。

评估指标可以转化为测试用例。 例如，您可以编写回归测试，以确保系统的任何新版本在相关评估指标上均优于该系统的某个基线版本。

如果您的系统运行成本较高，且测试与评估所使用的数据集存在重叠，那么将测试和评估合并运行也可以更节省资源。

您也可以选择使用标准的软件测试工具（例如 pytest 或 vitest/jest）来编写评估，以方便起见。

使用 pytest 和 vitest/jest

LangSmith SDK 提供了与 pytest 和 vitest/jest 的集成。 这些集成功能可轻松实现以下操作：

• 在 LangSmith 中跟踪测试结果
• 将评估编写为测试

在 LangSmith 中跟踪测试结果，便于共享结果、对比不同系统以及调试失败的测试。

将评估编写为测试，在针对每个待评估示例都需要自定义逻辑来运行应用程序和/或评估器时，会非常有用。 标准评估流程假设：您能够以相同的方式，在数据集中的每个示例上运行您的应用程序和评估器。 但对于更复杂的系统或更全面的评估，您可能希望使用特定类型的输入和指标，对系统的特定子集进行评估。 这类异构评估，若以一套彼此独立但统一追踪的测试用例形式来编写，会比使用标准 evaluate 流程简单得多。

使用测试工具在您需要同时评估系统输出并对其执行一些基本断言时也非常有帮助。

面向特定应用的技术

下面，我们将讨论几种特定且流行的大型语言模型（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）作为评判者的评估器往往效果显著，因为其可直接基于文本响应来判断智能体是否成功完成了任务。

然而，这种评估方式存在若干缺点。首先，运行通常耗时较长。其次，您并未评估智能体内部发生的任何过程，因此当出现故障时，很难进行调试。第三，有时难以定义恰当的评估指标。

评估智能体的单个步骤

智能体通常会执行多个动作。虽然端到端地评估智能体很有价值，但分别评估这些独立动作也同样重要。这通常涉及对智能体的单个步骤进行评估——即大语言模型（LLM）调用环节，该环节决定下一步应执行的操作。

输入应为单个步骤的输入。具体取决于您正在测试的内容，这可以仅仅是原始的用户输入（例如，一个提示词和/或一组工具），也可以包含之前已完成的步骤。

输出仅为该步骤的结果，通常为大语言模型（LLM）的响应。LLM 响应中通常包含工具调用，用于指示智能体下一步应执行的操作。

该评估器通常采用某种二元评分方式，用于判断是否选择了正确的工具调用，以及采用某种启发式方法来判断传入工具的输入是否正确。参考工具可直接以字符串形式指定。

此类评估具有多项优势。它允许您对单个操作进行评估，从而精准定位应用程序可能出错的具体环节。此外，这类评估运行速度相对较快（因其仅涉及一次大语言模型调用），且评估过程通常采用简单启发式方法，将所选工具与参考工具进行对比。但其也存在一些不足：一方面，它无法全面反映整个智能体的表现，而仅聚焦于某一个特定步骤；另一方面，数据集的构建可能颇具挑战性，尤其是当您希望在智能体输入中包含历史交互记录时。例如，为智能体执行轨迹早期步骤（如仅包含初始输入提示）构建数据集相对容易，但为轨迹后期步骤（如需包含大量先前的智能体操作及响应）构建数据集则较为困难。

评估智能体的执行轨迹

评估智能体的执行轨迹，包括对其所采取的所有步骤进行评估。

输入再次是整个智能体的输入（即用户输入，以及可选的工具列表）。

输出是一组工具调用列表，可表示为一条“精确”执行轨迹（例如，预期的工具调用序列），或仅表示为一组预期的工具调用（顺序不限）。

此处的评估器是对所执行步骤的某种函数。评估“精确”轨迹时，可使用单一的二元分数，以确认序列中每个工具名称是否完全匹配。这种方法虽然简单，但存在一些缺陷：有时可能存在多条正确的路径；此外，这种评估方式也无法区分轨迹仅偏离一步与完全错误之间的差异。

为解决这些缺陷，评估指标可聚焦于所采取的“错误”步骤数量，从而更准确地衡量那些接近正确路径与显著偏离正确路径的情况。评估指标还可关注是否以任意顺序调用了所有预期的工具。

然而，上述所有方法均未对工具的输入进行评估，而仅关注所选择的工具。为弥补这一不足，另一种评估技术是将整个智能体的执行轨迹（连同参考轨迹）作为一组消息（例如，所有大语言模型的响应和工具调用）传递给一个“充当裁判的大语言模型”（LLM-as-judge）。该方法可评估智能体的完整行为，但构建参考轨迹最具挑战性（幸运的是，使用 LangGraph 等框架可为此提供帮助！）。另一项缺点在于，设计评估指标本身也颇具难度。

检索增强生成（RAG）

检索增强生成（RAG）是一种强大的技术，它根据用户的输入检索相关文档，并将这些文档传递给语言模型进行处理。RAG 通过利用外部知识，使人工智能应用能够生成更具信息量和上下文感知能力的响应。

信息

如需全面了解RAG（检索增强生成）概念，请参阅我们的 RAG From Scratch 系列教程。

数据集

在评估 RAG 应用时，一个关键考量因素是：您是否已拥有（或能否轻松获取）每个输入问题的参考答案。参考答案作为评估生成响应正确性的“真实基准”。然而，即使缺乏参考答案，仍可借助无需参考答案的 RAG 评估提示（下方提供示例）开展多种评估。

评估器

LLM-as-judge 是 RAG 中常用的一种评估器，因为它能有效评估文本之间在事实准确性或一致性方面的表现。

在评估 RAG 应用时，您可以使用两类评估器：一类需要参考输出，另一类则不需要：

1. 需要参考输出：将RAG链生成的答案或检索结果与参考答案（或参考检索结果）进行对比，以评估其正确性。
2. 无需参考输出：使用不依赖参考答案的提示词执行自洽性检查（上图中分别以橙色、绿色和红色表示）。

应用RAG评估

应用RAG评估时，请考虑以下方法：

1. Offline evaluation：对任何依赖参考答案的提示词使用离线评估。这最常用于RAG（检索增强生成）答案正确性评估，其中参考答案是基准真值（即正确答案）。

2. Online evaluation：对任意无需参考答案的提示词使用在线评估。这使您能够在实时场景中评估RAG应用的性能。

3. 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 个用于摘要生成的文本常被用于评估（参见此处的数据集示例）。然而，来自生产环境（摘要生成）应用的 user logs 可与下方任意 Reference-free 个评估提示结合，用于在线评估。

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标签的数据集。如果没有，用户通常希望定义一个评估器，该评估器能依据特定标准（例如毒性程度等）为输入内容（例如文本、用户提问等）自动打上标签。然而，如果提供了真实类别标签（ground truth），则评估目标将聚焦于根据真实类别标签对分类/标注链进行评分（例如使用精确率、召回率等指标）。

如果提供了真实标签（ground truth reference labels），通常只需定义一个自定义启发式评估器，将真实标签与链式输出进行比较即可。然而，随着大语言模型（LLM）的兴起，如今越来越常见的一种做法是直接使用 LLM-as-judge，依据指定标准对输入执行分类/标注任务（无需真实标签作为参考）。

使用 LLM-as-judge 并配合 Reference-free 提示词时，可进行 Online 或 Offline 二元评估。特别是当用户希望对应用程序输入进行打标签或分类（例如检测毒性等）时，该方法非常适用于 Online 评估。

应用场景	详细信息	需要参考输出	LLM-as-judge?	成对相关
Accuracy	Standard definition	Yes	No	No
Precision	Standard definition	Yes	No	No
Recall	Standard definition	Yes	No	No

实验配置

LangSmith 支持多种实验配置，可让您更轻松地以所需方式运行评估。

重复

多次运行实验会很有帮助，因为大语言模型（LLM）的输出并非确定性结果，每次重复运行的结果都可能不同。通过多次重复运行，您可以更准确地评估您系统的性能。

可通过向 evaluate / aevaluate 传入 num_repetitions 参数来配置重复次数（Python，TypeScript）。 重复实验既包括重新运行目标函数以生成输出，也包括重新运行评估器。

如需了解有关在实验中运行重复操作的更多信息，请阅读操操作指南。

并发

通过向 evaluate / aevaluate 传入参数 max_concurrency，您可以指定实验的并发数。max_concurrency 参数的具体语义会根据您使用的是 evaluate 还是 aevaluate 而略有不同。

evaluate

max_concurrency 参数用于指定运行实验时允许使用的最大并发线程数。 该参数既适用于运行您的目标函数，也适用于运行您的评估器。

aevaluate

max_concurrency 参数传递给 aevaluate 与 evaluate 的作用非常相似，但其采用信号量（semaphore）机制来限制同时运行的并发任务数量。aevaluate 的工作方式是：为数据集中的每个样本创建一个任务；每个任务包含执行目标函数以及针对该特定样本的所有评估器。max_concurrency 参数用于指定同时运行的最大并发任务数（即最大并发样本数）。

缓存

最后，您还可以通过将 LANGSMITH_TEST_CACHE 设置为设备上一个具有写入权限的有效文件夹，来缓存实验中发起的 API 调用。 这会使实验中发起的 API 调用被缓存到磁盘，意味着后续执行相同 API 调用的实验将大幅提速。