优化 LangSmith 上的追踪支出
由于企业版套餐采用定制化计费模式，本指南中提到的部分功能目前暂不适用于该套餐。如果您使用的是企业版套餐，并有关于成本优化的问题，请联系您的销售代表或support@langchain.dev。
本教程将指导您如何优化在 LangSmith 上的支出。我们将通过一个贴近现实的实例，学习如何优化现有支出，并防止未来出现超支情况。我们将使用一个现有且使用量较高的 LangSmith 组织作为示例，其中涉及的概念可直接应用于您自己的组织。
问题设定
在本教程中，我们将以一个已有的组织为例，该组织拥有三个工作区，分别对应三个部署阶段（开发、预发布和生产）：
了解您的当前使用情况
任何优化流程的第一步都是了解当前的使用情况。LangSmith 提供了两种方式来实现这一点：用量图（Usage Graph）和账单（Invoices）。
使用图
用量图表可帮助我们查看近期已消耗的各类基于用量计费指标的具体数值。它并不直接显示费用支出（该信息将在后续的草稿账单中呈现）。
我们可以导航到“使用图”（Usage Graph），路径为 Settings -> Usage and Billing -> Usage Graph。
我们在上图中可以看到，LangSmith 收费的使用指标有两个：
- LangSmith 调用追踪（基础费用）
- LangSmith 跟踪（扩展数据保留升级）
第一个指标追踪您发送至 LangSmith 的所有跟踪记录。第二个指标则追踪同时启用了我们“延长 400 天数据保留”功能的所有跟踪记录。 如需更多详情，请参阅我们的 数据保留概念文档。请注意，这些图表外观完全相同，此特点将在本教程后续部分发挥作用。
LangSmith 的追踪功能使用量按工作区进行计量，因为工作区通常代表开发环境（如我们的示例所示），或组织内部的各个团队。作为 LangSmith 管理员，我们需要针对每个此类单元细致地了解支出情况。在当前仅需削减支出的情况下，我们可首先聚焦于产生大部分成本的环境，以实现最大幅度的节省。
LangSmith 的用量图表和发票使用术语 tenant_id 来指代工作区 ID，二者可互换使用。
在上图中，绝大部分使用量来自 ID 为 c27dd32c-7c80-4e8c-acde-bfcb67a90ab2 的工作区。我们可以依次点击 Settings → Workspaces，然后将鼠标悬停在 Workspace ID 按钮上，找到 ID 匹配的工作区。本例中，该工作区为“Prod”工作区：
发票
我们了解了追踪（traces）层面的使用情况，但如今需要将其转化为实际支出。为此，我们需要进入 Invoices 标签页。屏幕上首先显示的发票是您当前月份的草稿版发票，其中列出了您本月至今的累计支出。
在上面的 GIF 中，我们可以看到 LangSmith 追踪功能的费用按“tenant_id”（即工作区 ID）进行了划分，这意味着我们可以追踪每个工作区的追踪费用支出。在 6 月的头几天里，总计约 2000 美元的费用中，绝大部分都发生在我们的生产工作区中。此外，该工作区内的大部分支出用于延长数据保留期的追踪升级服务。
这些升级出于两个原因：
- 您使用扩展数据保留追踪功能，即默认情况下，您的追踪记录将被保留400天。
- 您使用基础数据保留跟踪，并启用了自动延长跟踪数据保留期的功能（参阅我们的自动升级概念文档）
鉴于每日总追踪数等于每日扩展保留追踪数，该组织极有可能在所有地方都启用了扩展数据保留追踪。因此，我们首先从优化保留设置入手。
优化 1：管理数据保留
LangSmith 的计费方式取决于追踪（trace）的数据保留时长（参见我们的 数据保留概念文档），其中短期追踪的费用比长期保留的追踪低一个数量级。在本次优化中，我们将展示如何在不牺牲历史可观测性的前提下，为数据保留设置最优配置，并说明该配置对账单的影响。
为新项目更改组织级别的保留默认设置
我们切换到 Usage configuration 选项卡，查看组织级别的保留设置。修改此设置将影响我们组织中所有工作区后续创建的新项目。
为保持向后兼容性，较早创建的组织可能默认为此项设为“扩展版”（Extended）。而2023年6月3日之后创建的组织，则默认为此项设为“基础版”（Base）。
更改项目级别的保留期默认设置
我们现有的项目尚未更改其数据保留设置，因此我们可以在各个项目页面上单独修改这些设置。
我们导航至 Projects → <your project name>，点击“数据保留”下拉菜单，并将其修改为“基础保留”。与组织级别设置一样，此设置仅会影响后续追踪数据的保留期限（及相应费用）。
保留一定比例的追踪数据以实现长期数据保留
如果我们关注历史调试，可能不希望所有跟踪记录都在14天后过期。因此，我们可以利用LangSmith内置的服务器端采样功能，以实现更长时间的数据保留。
选择合适的运行采样百分比取决于您的具体使用场景。此处我们任意选择10%的运行进行采样，但将由用户自行确定最合适的数值，以在收集罕见事件与成本约束之间取得平衡。
LangSmith 会自动为匹配自动化产品中运行规则（run rule）的任何追踪记录升级其数据保留期限（参见我们的 运行规则文档）。在项目页面上，点击 Rules -> Add Rule，并按如下方式配置该规则：
运行规则匹配针对的是“运行”（runs），而非“追踪”（traces）。“运行”是大型语言模型（LLM）应用API处理过程中的单个工作单元；而“追踪”则是端到端的API调用（了解更多关于LangSmith中的追踪概念）。这意味着，一个“追踪”可被视为由构成某次API调用的多个“运行”所组成的树状结构。当某条运行规则匹配到某个追踪内的任意一次运行时，该追踪所对应的完整运行树将升级为保留400天。
因此，为了确保追踪数据具有合适的采样率，我们利用运行规则的过滤功能。
我们添加一个过滤条件，仅匹配运行树中的“根”运行（root run）。由于每个追踪（trace）的根运行都是唯一的，因此我们的10%采样将升级10%的追踪，而非10%的运行——而后者可能对应超过10%的追踪。如有需要，我们还可选择性地添加其他过滤条件（例如：附加在追踪上的特定标签或元数据），以实现更精准的数据保留扩展。在本教程中，我们将采用最简单的条件，更高级的过滤则留作用户的练习。
如果您出于数据收集目的希望将部分追踪记录保留超过 400 天，您可以创建另一条运行规则，将部分运行发送至您选定的数据集。数据集允许您存储追踪的输入和输出（例如，以键值对形式存储），且会无限期保留，即使该追踪记录已被删除。
7天后查看结果
尽管每日的追踪数据总量保持不变，但延长的数据保留期所对应的追踪数据却大幅减少。
这体现在发票上：过去7天我们仅花费了约900美元，而此前4天的花费为2000美元。 这意味着每日成本降低了近75%！
优化 2：限制使用量
在上一节中，我们通过管理数据保留设置来优化现有支出。在本节中，我们将使用用量限制来防止未来超支。
LangSmith 有两个使用限制：总追踪数和扩展保留追踪数。这两个指标对应我们在用量图表中一直跟踪的两项指标。我们可以同时使用这两项指标，以实现对支出的精细化管控。
要设置使用限制，请依次返回至 Settings → Usage and Billing → Usage configuration。页面底部有一个表格，允许您为每个工作区设置使用限制。对于每个工作区，表格中会显示两项限制，并附带相应的费用估算：
让我们首先为生产环境的使用设定限制，因为大部分支出都来源于此。
设置合理的总追踪数上限
选择合适的“总追踪数”限制，取决于您将发送到 LangSmith 的追踪数据的预期负载。在设置该限制之前，您应明确思考自己的假设。
例如：
- 当前负载：我们的生成式AI应用每秒被调用1.2至1.5次，每次API请求均关联一个追踪记录， 即我们每天记录约10万至13万条追踪记录
- 预期的负载增长：我们预计在不久的将来规模将翻倍。
基于这些假设，我们可以进行一次快速的粗略估算，从而得出一个较为合理的上限值：
limit = current_load_per_day * expected_growth * days/month
= 130,000 * 2 * 30
= 7,800,000 traces / month
我们点击“Prod”行右侧表格中的编辑图标，然后可以按如下方式输入此限制：
在未设置扩展数据保留追踪限制的情况下，最大成本估算器会假定所有追踪均使用扩展数据保留功能。
通过延长数据保留期限来降低最高支出
如果我们不是大型企业，可能会对每月约 4 万美元的账单感到震惊。
我们从优化方案 1中了解到，控制数据保留周期是降低成本最简单的方法。
限制策略同样适用。如果我们仅希望保留约 10% 的追踪记录（trace）超过 14 天，则可对高保留期追踪记录的数量设置上限，该上限值应设为 .10 * 7,800,000 = 780,000。
如我们所见，最高成本已从每月约40,000美元降至每月约7,500美元，原因是我们不再允许进行如此多昂贵的数据保留升级。这使我们能够确信，平台上的新用户不会意外导致成本激增。
扩展的数据保留期限一旦达到，可能导致追踪功能以外的其他功能停止工作。如果您计划使用此功能，请点击此处详细了解其功能。
设置开发/预发布环境限制，并查看跨工作区的总支出限额
遵循我们开发和预发布环境的相同逻辑，我们为每个工作区设置的用量限制为生产环境限制的10%。
尽管此设置适用于我们的使用模式，但为开发环境和预发布环境设定合理的用量限制，可能因您在 LangSmith 中的具体用例而异。例如，如果您在开发或预发布环境中将评估（evals）作为 CI/CD 的一部分来运行，则可能需要更宽松地设置用量限制，以避免测试失败。
现在，我们的限额已设置完毕，可以看到 LangSmith 显示了所有工作区的最高消费预估金额：
使用此估算器，我们可以确保月底不会收到意外的信用卡账单。
摘要
在本教程中，我们学习了如何：
- 通过数据保留策略降低现有成本
- 通过使用限制防止未来超支
如果您有关于进一步优化支出的问题，请联系 support@langchain.dev。