优化 LangSmith 上的追踪开销
本指南中提到的一些功能由于其定制计费性质，目前在企业版中不可用。如果您是企业版用户并对成本优化有疑问，请联系您的销售代表或 support@langchain.dev。
本教程将逐步指导您优化在 LangSmith 上的开销。在本教程中，我们将通过一个真实的实际案例，学习如何优化现有开销并防止未来超支。我们将使用一个现有且使用量较高的 LangSmith 组织。相关概念可以迁移到您自己的组织中。
问题设置
在本教程中，我们将使用一个现有组织，该组织有三个工作区，分别对应每个部署阶段（开发、预演和生产）
了解您当前的使用情况
任何优化过程的第一步是了解当前使用情况。LangSmith 提供两种方式来查看：使用情况图表和发票。
使用情况图表
使用情况图表让我们能够查看最近消耗了多少基于使用量的计费指标。它不直接显示开销（我们稍后将在草稿发票上看到）。
我们可以通过 设置 -> 使用情况和计费 -> 使用情况图表 导航到使用情况图表。
我们从上图中看到，LangSmith 收取费用的使用指标有两种
- LangSmith 追踪 (基本费用)
- LangSmith 追踪 (延长数据保留升级)。
第一个指标跟踪您发送到 LangSmith 的所有追踪。第二个指标跟踪所有同时具有我们延长 400 天数据保留期的追踪。更多详情，请参阅我们的数据保留概念文档。请注意，这些图表看起来相同，这将在教程后面发挥作用。
LangSmith 追踪的使用量是按工作区衡量的，因为工作区通常代表开发环境（如我们的示例），或组织内的团队。作为 LangSmith 管理员，我们希望精细地了解每个单位的开销。在本例中，我们只想削减开销，因此可以首先关注承担大部分成本的环境，以实现最大的节约。
发票
我们了解了追踪的使用情况，但现在需要将其转化为开销。为此，我们前往 发票 选项卡。屏幕上显示的第一张发票是您当前月份的草稿发票，其中显示了本月截至目前的运行开销。
LangSmith 的使用情况图表和发票使用术语 tenant_id 来指代工作区 ID。它们可以互换使用。
在上面的 GIF 中，我们看到 LangSmith 追踪的费用按“tenant_id”（即工作区 ID）细分，这意味着我们可以跟踪每个工作区的追踪开销。在 6 月份的前几天，总计约 2,000 美元的开销绝大部分发生在我们生产工作区。此外，该工作区的大部分开销都用于延长数据保留追踪升级。
这些升级的发生有两个原因
- 您使用延长数据保留追踪，这意味着默认情况下，您的追踪将保留 400 天
- 您使用基本数据保留追踪，并使用自动延长追踪数据保留期的功能（参阅我们的自动升级概念文档）
鉴于每天的总追踪数量等于每天的延长保留期追踪数量，该组织很可能在所有地方都使用了延长数据保留追踪。因此，我们首先优化我们的保留设置。
优化 1：管理数据保留
LangSmith 根据追踪的数据保留期收取不同的费用（请参阅我们的数据保留概念文档），其中短期追踪比长期追踪便宜一个数量级。在此优化中，我们将展示如何在不牺牲历史可观测性的情况下获得最佳数据保留设置，并展示它对我们账单的影响。
更改组织级别新项目的保留默认值
我们导航到 使用配置 选项卡，查看我们的组织级别保留设置。修改此设置会影响我们组织中所有工作区中未来创建的所有新项目。
为了向后兼容，较旧的组织可能默认设置为延长保留。在 6 月 3 日之后创建的组织默认设置为基本保留。
更改项目级别保留默认值
我们现有项目的**数据保留设置**未更改，因此我们可以在单个项目页面上更改这些设置。
我们导航到 项目 -> <您的项目名称>，点击数据保留下拉菜单，并将其修改为基本保留。与组织级别设置一样，这只会影响未来追踪的保留期（和定价）。
保留一部分追踪以进行延长数据保留
如果我们关心历史调试，我们可能不希望所有追踪都在 14 天后过期。因此，我们可以利用 LangSmith 内置的服务器端采样功能来实现延长数据保留。
选择合适的运行采样百分比取决于您的用例。我们将在此处随意选择 10% 的运行，但将由用户自行寻找平衡稀有事件收集和成本限制的正确值。
LangSmith 会自动为与我们自动化产品中的运行规则匹配的任何追踪升级数据保留期（请参阅我们的运行规则文档）。在项目页面上，点击 规则 -> 添加规则，然后按如下方式配置规则
运行规则匹配的是运行而不是追踪。运行是 LLM 应用程序 API 处理中的单个工作单元。追踪是端到端的 API 调用（了解更多关于 LangSmith 中的追踪概念）。这意味着追踪可以被视为构成 API 调用的运行树。当运行规则匹配追踪内的任何运行时，该追踪的完整运行树将升级，并保留 400 天。
因此，为确保追踪的采样率正确，我们利用运行规则的过滤功能。
我们添加一个过滤条件，只匹配运行树中的“根”运行。这对于每个追踪都是独特的，因此我们的 10% 采样将升级 10% 的追踪，而不是 10% 的运行（后者可能对应超过 10% 的追踪）。如果需要，我们可以选择添加任何其他所需的过滤条件（例如，附加到我们追踪的特定标签/元数据），以更精确地延长数据保留期。在本教程中，我们将坚持最简单的条件，并将更高级的过滤留作用户练习。
如果您想出于数据收集目的，将一部分追踪保留超过 400 天，您可以创建另一个运行规则，将某些运行发送到您选择的数据集。数据集允许您存储追踪的输入和输出（例如，作为键值数据集），并将无限期地保留，即使在追踪被删除之后也是如此。
查看 7 天后的结果
虽然每天的追踪总量保持不变，但延长数据保留追踪被大幅削减。在发票中，我们可以看到，在过去 7 天里，我们只花费了大约 900 美元，而前 4 天则花费了 2,000 美元。
这相当于每天的成本降低了近 75%！
优化 2：限制使用量
在上一节中，我们管理了数据保留设置以 _优化现有开销_。在本节中，我们将使用使用限制来 _防止未来超支_。
LangSmith 有两种使用限制：总追踪数量和延长保留期追踪数量。这些对应于我们在使用情况图表上一直跟踪的两个指标。我们可以将它们结合使用，以对开销进行精细控制。
要设置限制，我们返回 设置 -> 使用情况和计费 -> 使用配置。页面底部有一个表格，允许您为每个工作区设置使用限制。对于每个工作区，会显示两个限制以及成本估算
我们首先对生产使用量设置限制，因为大部分开销都来自那里。
设置一个合理的总追踪数量限制
选择合适的“总追踪数量”限制取决于您将发送到 LangSmith 的预期追踪负载。在设置限制之前，您应该清楚地考虑您的假设。
例如
- 当前负载：我们的生成式 AI 应用每秒调用 1.2-1.5 次，并且每个 API 请求都关联一个追踪，这意味着我们每天记录大约 100,000-130,000 个追踪
- 预期负载增长：我们预计在不久的将来规模将翻倍。
根据这些假设，我们可以快速进行粗略计算，得出合理的限制值
limit = current_load_per_day * expected_growth * days/month
= 130,000 * 2 * 30
= 7,800,000 traces / month
我们点击表格中生产行右侧的编辑图标，然后可以如下输入此限制
当未设置延长数据保留追踪限制时，最大成本估算器假定所有追踪都使用延长数据保留。
通过延长数据保留限制削减最大开销
如果我们不是一家大型企业，每月大约 4 万美元的账单可能会让我们不寒而栗。
我们从优化 1 中看到，削减成本最简单的方法是通过管理数据保留。对于限制也是如此。如果我们只想保留约 10% 的追踪超过 14 天，我们可以对可以保留的最大高保留追踪数量设置限制。这将是 .10 * 7,800,000 = 780,000。
如我们所见，最高成本从每月约 4 万美元削减到每月约 7.5 千美元，因为我们不再允许如此多的昂贵数据保留升级。这让我们有信心，平台上的新用户不会意外导致成本飙升。
达到延长数据保留限制后，除了追踪之外的其他功能可能会停止工作。如果您计划使用此功能，请在此处阅读有关其功能的更多信息。
设置开发/预演环境限制并查看跨工作区的总开销限制
按照我们开发和预演环境的相同逻辑，我们为每个工作区设置了生产使用量限制的 10% 的限制。
尽管这适用于我们的使用模式，但设置合理的开发和预演环境限制可能会因您使用 LangSmith 的用例而异。例如，如果您在开发或预演环境中将评估作为 CI/CD 的一部分运行，您可能希望在使用限制方面更宽松，以避免测试失败。
现在限制已设置，我们可以看到 LangSmith 显示了所有工作区的最大开销估算
有了这个估算器，我们可以确信在月底不会收到意外的信用卡账单。
总结
在本教程中，我们学习了如何
- 通过数据保留策略削减现有成本
- 通过使用限制防止未来超支
如果您对进一步优化开销有疑问，请联系 support@langchain.dev。