优化 LangSmith 上的追踪花费
由于企业计划的计费方式具有定制性，本指南中提到的一些功能目前在企业计划中不可用。如果您使用的是企业计划，并且对成本优化有疑问，请联系您的销售代表或 support@langchain.dev。
本教程将引导您了解如何在 LangSmith 上优化您的花费。在其中，我们将学习如何优化现有花费，并通过一个真实的实际示例来防止未来超支。我们将使用一个现有 LangSmith 组织，该组织具有较高的使用量。概念可以转移到您自己的组织。
问题设置
在本教程中，我们采用一个现有的组织，该组织有三个工作区，每个工作区对应一个部署阶段（开发、暂存和生产）
了解您当前的用量
任何优化过程的第一步都是了解当前的用量。LangSmith 提供了两种方法来实现这一点：使用量图表和发票。
使用量图表
使用量图表使我们能够检查最近消耗了多少基于用量的定价指标。它不直接显示花费（我们稍后将在草稿发票中看到）。
我们可以导航到“设置” -> “用量和账单” -> “使用量图表”下的使用量图表。
我们在上面的图表中看到，LangSmith 对以下两个用量指标收费
- LangSmith 追踪 (基本费用)
- LangSmith 追踪 (扩展数据保留升级)。
第一个指标跟踪您发送到 LangSmith 的所有追踪。第二个指标跟踪所有也具有我们的扩展 400 天数据保留的追踪。有关更多详细信息，请参阅我们的数据保留概念文档。请注意，这些图表看起来相同，这将在本教程的后面部分发挥作用。
LangSmith 追踪用量是按工作区衡量的，因为工作区通常代表开发环境（如我们的示例中所示）或组织内的团队。作为 LangSmith 管理员，我们希望细粒度地了解每个单元的花费。在这种我们只想削减花费的情况下，我们可以首先关注成本最高的环境，以实现最大的节省。
LangSmith 的使用量图表和发票使用术语 tenant_id 来指代工作区 ID。它们是可以互换的。
在上图中，绝大多数用量都在 ID 为 c27dd32c-7c80-4e8c-acde-bfcb67a90ab2 的工作区中。我们可以转到“设置” -> “工作区”，并将鼠标悬停在“工作区 ID”按钮上以找到具有匹配 ID 的工作区。在本例中，它是生产工作区
发票
我们了解了用量在追踪方面的表现，但现在我们需要将其转化为花费。为此，我们前往“发票”选项卡。屏幕上出现的第一个发票是您本月发票的草稿，其中显示了您本月迄今为止的运行花费。
在上面的 GIF 中，我们看到 LangSmith 追踪的费用按“tenant_id”（即工作区 ID）细分，这意味着我们可以跟踪每个工作区的追踪花费。在六月的前几天，大约 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 的预期追踪负载。在设置限制之前，您应该清楚地考虑您的假设。
例如
- 当前负载：我们的 Gen 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。