如何通过上下文压缩降低AI请求的费用

写代码的AI助手在处理每一个请求时，无形中重复为之前的内容支付费用。三轮之前查看的文档、滚动跳过的构建日志、返回的庞大JSON数据——模型实际上只需要关注其中的几个关键信息字段。然而这些冗余的信息却在每次请求中被反复传输，从而导致了不断的费用支出。为了解决这个问题，我开发了Compresso，一个本地的AI压缩层，利用Headroom、Rtk等多种技术来优化token的消耗。其主要思路相当简单：以更少的token重现相同的信息，而不是让模型通过“总结”来将上下文缩短——这是对压缩的误解。

在这里，压缩意味着保留原文中重要的部分，重新编码重复的内容以及指向已经存在的信息，体现的是信息的密度，而不是其丢失。具体的实现方式需要逐项拆解分析。

压缩的第一步并不是直接进行压缩，而是先进行识别。用一个本地的机器学习分类器先扫描每一个内容块，判断它是哪种类型：是JSON数据、构建日志、源代码、diff，还是普通的文本。这个步骤在本地计算机上执行，所需时间仅为几毫秒。

需要先进行分类的原因在于，不同内容类型的压缩器并不通用。例如，对构建日志的压缩操作——如将400行的“Compiling...”折叠成一行——如果用在源代码上可能就会导致破坏。因此，针对每种内容类型专门设计的压缩器会接收相应的内容块，而分类器不明确的内容则会按原样处理。这也是为什么诚实的基准测试结果中会出现零的原因。grep命令的结果本身就已经非常紧凑，而模型真正需要关注的源代码——路由器对此不会做任何处理，什么都不做本身也是一种功能。

在处理JSON结构时，通常会遇到工具返回近乎相同对象的情况。例如，一百条日志事件或五百条搜索结果，每一条都带有类似的键名，且值大多相同。结构感知压缩器会在这样的数组中进行统计分析：哪些字段是变化的，哪些是常量，值的变化何处发生。随后，它只保留头部、尾部和变化点，去掉中间那些逐字重复的内容。被保留的每一项都是未改动的原始内容，保持同样的结构和字节，没有添加任何生成的文本。经过处理后，从500条几乎一致的JSON记录中，仅保留了前几条、后几条以及一条错误信息，因为重要的信息就藏在其中。实测过程中，从9,526个token压缩到1,614个，仅耗时2毫秒。

在构建和测试输出中，这些内容是AI代理所读取的信息中最容易被压缩的，同时也是最容易被错误压缩的对象。处理的原则是：完全保留错误、警告以及完整的堆栈跟踪，包括链式异常——因为有趣的信息往往隐藏在深处。