上下文压缩：在不失去意义的情况下减少代币浪费的实用指南 - EasyClaw

上下文压缩真正衡量的是什么

上下文压缩衡量人工智能系统将可用信息转化为有用的工作上下文的效率。

模型可以访问大的上下文窗口，但这并不意味着每个标记都是有用的。有些标记具有重要意义。其他人重复旧信息，包括不相关的工具输出，或保留不再重要的废弃决策。

一个好的上下文压缩过程会提出四个实际问题：

这与一般人工智能成本降低不同。上下文压缩侧重于输入本身的形状和有用性。

例如，处理账单投诉的客户支持副驾驶可能有权访问完整的帐户历史记录、订阅事件、付款日志、以前的票证和内部注释。下一步可能只需要最新的失败费用、计划类型、客户陈述的问题以及任何退款政策限制。

发送所有内容的成本很高，并且可能会使模型感到困惑。发送太少可能会导致它错过重要的事实。

真正的衡量标准不是“我们移除了多少代币？”问题是“压缩后的上下文是否仍然支持正确的决策？”

上下文压缩如何出现在实时工作流程中

当人工智能从单轮提示转变为实时系统时，上下文压缩变得非常重要。

在简单的提示中，用户直接提供上下文。在代理工作流程中，上下文从许多地方累积：

• 用户说明
• 之前的聊天轮流
• 检索到的文件
• 工具结果
• 错误日志
• 浏览器或桌面状态
• API 响应
• 记忆记录
• 中期计划
• 失败的尝试和重试

这种累积的上下文可能会很快变得嘈杂。

考虑一个 AI 代理正在调查 SaaS 平台中失败的发票同步。用户询问：“找出该客户的发票未同步到会计的原因，并为客户经理起草一份说明。”

代理人可能会收集：

弱压缩步骤可能会将所有这些总结为：

> 由于集成问题，发票失败。客户经理应跟进。

虽然很短，但没什么用。

更强的压缩上下文可能如下所示：

`文本

任务：

确定账户 A-219 的发票 INV-8842 未能同步的原因，并为客户经理起草一份简短说明。

相关事实：

• 发票 INV-8842 于 6 月 18 日创建。
• 付款成功，但账户同步在 UTC 时间 14:07 失败。
• 在 14:12 UTC 重试返回：“缺少 external_account_mapping”。
• 帐户所有者：陈玛雅。
• 机票中没有退款请求。
• 当前可能的原因：客户帐户缺少会计系统映射。

约束：

请勿声称客户的收费不正确。支付成功；付款后同步失败。

下一个输出：

起草一份简明的内部说明，其中包含原因、证据和建议的下一步行动。

`

该版本比原始证据小，但保留了影响答案的操作细节。它保留标识符、时间线、错误消息和约束。它还清楚地说明了下一个输出。

这就是上下文压缩作为一个可靠性层，而不仅仅是一个节省令牌的技巧。

它在桌面和无代码自动化中也很重要。 EasyClaw 等人工智能代理平台可以让用户通过自然语言和图形控制在自己的计算机上自动化工作，可以观察屏幕、工具输出、聊天指令和应用程序状态。系统需要足够的上下文才能正确执行操作，但重复的 UI 观察和陈旧的操作历史记录可能会挤出当前任务。将该状态压缩到最新的屏幕、主动目标、关键约束和最近的故障点中可以帮助代理保持专注。

实际工作流程中上下文压缩的根本原因

当上下文压缩失败时，明显的症状通常是成本或延迟。根本原因通常更具体。

最危险的失效模式是不明显的遗漏。就是漂移的意思。

例如，销售单据可能会这样写：

> 如果 SOC 2 报告在 7 月 31 日之前获得安全部门批准，客户可以签订年度合同。

有损压缩步骤可能会将其变成：

> 客户可以签订年度合同。

这就消除了条件、依赖性和最后期限。压缩版本对于模型来说更容易使用，但不太真实。基于该摘要的预测、后续电子邮件或续订建议可能是错误的。

另一个常见的失败是权威陈旧。假设客服人员首先看到一张旧的支持票证，其中显示客户参与了增长计划，然后检索了显示 Enterprise 的当前帐户记录。如果压缩保留较早的事实，因为它出现较早，则模型可能会产生错误的升级路径。

良好的上下文压缩需要权威和新近度规则。当前的真实来源记录应覆盖旧的聊天语句。明确的用户指令应该覆盖推断的目标。确切的系统错误应该覆盖“集成问题”的广泛概括。

如何在不破坏输出质量的情况下改进上下文压缩

改进上下文压缩的最安全方法是将其视为受控工作流程。不要从总结一切开始。首先决定模型下一步必须做什么。

1. 定义下一步行动

压缩取决于当前任务。

“分析这个客户”太宽泛了。 “起草一份 120 字的内部注释，解释发票 INV-8842 同步失败的原因”给系统一个明确的目标。

明确的下一步行动告诉压缩层哪些事实是相关的。

2. 按角色对上下文进行分类

将可用上下文分为实用类别：

3. 在精度至关重要的地方保留准确的细节

一些细节很少应该被解释：

• 账户 ID
• 发票 ID
• 文件路径
• 错误信息
• 日期和时间
• 价格和合同条款
• 法律或合规条件
• 用户说明
• 安全范围和权限限制
• 引用来源作为证据

这些细节通常消耗很少的代币，但具有很高的决策价值。

4. 压缩证据周围，而不是之上

一个强有力的模式是保留精确的证据片段并压缩周围的解释。

虚弱的：

`文本

由于映射问题，同步失败。

`

更强：

`文本

同步于 14:12 UTC 失败，原因是“缺少 external_account_mapping”。下一步可能是：创建或修复帐户 A-219 的会计系统映射。

`

更强的版本只是稍微长一点，但更有用。

5. 使用结构化状态摘要

自由形式的摘要很容易编写，但很难验证。对于代理和生产副驾驶来说，结构化摘要更容易检查。

`文本

当前目标：

已知事实：

证据来源：

限制条件：

已经做出的决定：

开放式问题：

下一步行动：

`

这种格式减少了重要上下文被淹没在散文中的机会。

6. 针对全上下文输出进行测试

使用来自真实工作流程的小型评估集。对于每种情况，使用完整上下文和压缩上下文运行模型。比较：

• 是否得出同样正确的结论？
• 它保留了所需的事实吗？
• 它遵守用户和系统的约束吗？
• 它是否避免了不受支持的主张？
• 证据不足时是否要求澄清？
• 它产生了所需的输出格式吗？

如果压缩上下文节省了令牌，但增加了更正、升级或用户不信任，那么这并不是一种改进。

7. 将压缩故障作为产品事件进行跟踪

上下文压缩应该具有可观察性。

跟踪用户何时纠正缺失的事实、代理何时重复旧步骤、输出何时引用过时的数据，或者模型何时要求压缩前可用的信息。这些信号表明压缩层正在丢弃或扭曲有用的上下文。

常见问题解答：上下文压缩

什么是上下文压缩？

上下文压缩是缩小发送到人工智能模型的上下文，同时保留完成任务所需信息的过程。它可能涉及总结、提取字段、删除重复信息、保留准确证据或维护结构化状态对象。

目标不仅仅是减少代币。目标是更小的上下文仍然支持正确的输出。

上下文压缩如何工作？

上下文压缩的工作原理是选择、重写或构造传递到模型中的信息。系统可以删除不相关的历史记录、删除重复的事实、总结长时间的讨论、从记录中提取关键字段或仅检索最相关的源块。

在生产工作流程中，最好的方法通常是结合技术。例如，代理可以保持结构化任务状态，保留准确的错误消息，总结旧的对话轮次，并仅在需要时检索源文档。

上下文压缩的主要风险是什么？

主要风险是事实丢失、意义扭曲、记忆陈旧、约束缺失和源头接地薄弱。

压缩的摘要听起来很准确，但忽略了关键条件。这在涉及计费、法律条款、安全决策、医疗信息、财务数据、代码执行或客户承诺的工作流程中尤其危险。

如何通过上下文压缩改进结果？

通过首先定义下一步行动、保留准确的高风险细节、使用结构化摘要以及根据源证据验证压缩上下文来改进结果。

衡量质量以及节省的代币。有用的指标包括任务成功率、纠正率、延迟、每个成功任务的成本、升级率和缺失事实错误的频率。

上下文压缩与提示压缩相同吗？

不。提示压缩通常意味着缩短指令或提示文本。上下文压缩范围更广。它可以包括聊天历史记录、检索到的文档、工具输出、日志、内存、浏览器状态、屏幕截图和工作流程状态。

即时压缩是更大的上下文管理问题的一部分。

上下文压缩与检索相同吗？

不会。检索决定将哪些外部信息带入模型的上下文中。上下文压缩决定了一旦选择或累积所有相关信息如何表示。

他们经常一起工作。检索可以找到正确的源材料，而压缩可以删除重复项、保留关键事实并构建最终输入。

更大的上下文窗口是否不需要上下文压缩？

不会。较大的上下文窗口可以减轻压力，但并不能消除相关性控制的需要。

更多上下文仍然会增加成本、延迟和混乱。它还可能使陈旧或不相关的信息更有可能影响模型。强大的上下文压缩有助于模型专注于当前重要的事实、约束和当前状态。

上下文压缩什么时候应该保守？

当精确的措辞或来源证据很重要时，请使用保守的压缩。这包括法律审查、财务运营、安全分析、医疗工作流程、合规任务、合同谈判、生产代码更改和面向客户的承诺。

在这些情况下，压缩周围的噪音，但保留源文本、标识符和约束以供验证。

团队测试上下文压缩的最佳第一步是什么？

从一个真实的工作流程开始，其中令牌使用率很高并且输出质量是可衡量的。捕获完整上下文示例，创建压缩版本，并并排比较结果。

最好的早期候选者是具有重复结构的工作流程：支持票证分类、CRM 摘要、日志分析、代码审查、发票调查或文档问答。这些可以更轻松地定义必须保留的内容和可以安全删除的内容。