上下文压缩 - AI商业快讯

你有过这种体验：让 AI 助手处理一份两万行的日志，它读得很欢，账单也很欢。更难受的是，等你想追溯某一行到底出了什么错，它已经把那行连同上下文一起挤出了窗口。

Headroom 就是冲这件事来的。它把自己插在你的程序和模型之间，把日志、接口返回、代码、对话历史先压一遍再送上去，号称在四个真实场景里省下 21% 到 57% 的输入。这个项目拿了 79,671 颗星，作者还留了一份「可以自己复算」的脚本。

我把整个仓库拉进隔离环境，装了正式发布的版本，先跑他们的脚本，再写了一组自己的对照测试。官方那张表我一个字不差地复现了。但我自己的测试里出现了两个官方文档没提的情况：一份普通代码被它当成日志压掉了 97%，我动手挑的几个关键词，压完之后一个都不剩。

一、它到底在压什么：不是删字，是按类型换写法

先说清楚它在干什么，因为它做的不是「总结」，而是「换一种更省字的写法」。

举个例子。你要给模型看五百条一模一样的订单记录，每条都有客户名、状态、金额三个字段。原样发上去，同样的文字重复五百遍，模型看第一遍就懂了，剩下四百九十九遍纯属白付钱。Headroom 的做法是把这份清单改写成「表头加数据行」的样子，字段名只写一次，后面只留值。信息没丢，长度掉了大半。

这是它对结构化数据的处理。对日志，它把几百行同构的记录合并，中间留几行有代表性的，再给一个「原文存在这里，需要就取」的凭证。对散文和代码，它另有更重的办法，需要额外下载一个模型，也就是一个专门学过的压缩器。

它还做了一件事：把原文存在你本机，模型要是想看完整版本，可以凭凭证取回来。这个设计挺关键——它意味着压缩默认是有损的，但有后路。官方文档把这条后路叫可逆，意思是压完还能取回原文。

判断值不值得装，只需要看一件事：你每天喂给模型的那些内容，重复度高不高。重复度决定省多少，不重复的内容一分都省不下来。

它仓库里有个专门的脚本，用来重新生成官网首页那张省字表。这一点值得说明——作者自己写过一段注释，说首页的数字以前没人能复现，那对他们来说是负债，不是证据。

我在断网、没有密钥、不调用任何模型的情况下跑了一遍。四个场景，输入从 178,024 个计量单位压到 104,261 个，整体省 41%。四个场景分别是省 21%、57%、42%、30%，与官网完全一致。

这张表本身没有水分。省得最多的是故障排查那段，因为日志天然重复；省得最少的是搜索结果，因为它每条都不一样。这个排序很符合直觉，也说明数字不是挑着报的。

第一件：重复数据没有那么神。

官方简介里写，重复的接口返回和日志行能省九成以上。我照这个说法造了五百条字段完全相同、值也完全相同的记录，实测从 36,000 个字符压到 11,062 个，省 69%。换成五百行完全相同的日志，倒是真的省了 100%——因为它把这五百行合并成了一行加一个凭证。

差别在于「重复」的粒度。整行一模一样，它可以放心合并；字段一样但值在动，它只能改写格式，不能删信息。所以「九成以上」这个说法对日志成立，对接口返回就要打折。这不是造假，是宣传口径比实测宽了一档。

第二件：代码可能被当成日志处理，压完就没法读了。

这是我最意外的一处。我造了两段代码：一段是八十个结构相似的函数，一段是三百个带注释和校验的增删改查函数，后者二十五万个字符。第二段它省了 97%。

省得多本来是好事，但我把产物打印出来一看，问题来了：

我原本以为会看到「保留函数签名、合并函数体」这种聪明做法，实际看到的是按日志规则切出来的残片：一个函数的第一行、重复的返回语句、一句「省略了多少行，需要就凭凭证取回」。也就是说，在只关心「报了什么错」的场景里，这种产物够用；在「帮我改这个函数」的场景里，它把要改的东西删了。

根子在于它自己把这段内容判定成了日志，判定错了，而压缩过程不会告诉你它判错了。要定位这类误判，得跑它自带的分析开关，逐条看它给每个消息贴了什么标签——我这边看到的那条标签，写的是按日志规则压缩。

第三件：有损和无损是两档，别搞混。

它提供两种模式。默认那档为了省字什么都敢做，日志三百行能压到九行；另一种模式承诺可逆无损，同样的日志一行不删，省 0%。

这个设计其实合理——你要是让助手继续读这份日志找原因，就得给它完整的东西；你要是只让助手知道「有一大批正常记录加一条致命错误」，压掉就无所谓。问题是这两个模式在文档里没有放在一起对比，得自己翻配置说明才看得明白。

至于它宣称的「压缩开销可以忽略」，这点我认可。预热之后，压一份一万字左右的日志稳定在 1.2 毫秒，压一份一万字左右的接口返回是 1.4 毫秒。第一次调用慢了约一百多倍，那是程序冷启动，跑第二轮就正常了。

省字这一类工具最近出了不少，大致三种路子。

一种是改说话方式，让模型少啰嗦、少用词，省的是模型吐出来的那部分。另一种是检索式，先把代码库做成索引，需要哪里取哪里，省的是「不用把整个仓库塞进去」这件事。Headroom 属于第三种：不动你的习惯，在中间把内容换一种写法，省的是每次请求的输入。

三种可以叠着用，不冲突。区别在于风险不一样：改说话方式顶多让回答变简短；检索式可能取错文件；换写法最怕的就是我上面撞到的那个——它把不该压的东西压了，而且不打招呼。

适合谁：每天要处理大量日志、接口返回、数据库查询结果的人，收益立竿见影。它支持主流编码助手的命令行包装，也支持当独立代理跑，还提供直接调用的库方式。

不适合谁：主要在写代码、让助手改函数的人。这类工作里，代码是最不该被简化成摘要的内容，而你恰恰会因为它把代码误判成日志而丢掉细节。

Headroom 是个工程做得挺认真的项目：它愿意为自己的数字提供复现脚本，误判时有凭证可以找回原文，冷启动之后的开销确实可以忽略。79,671 颗星不算虚。

但它也有两条必须知道的边界。宣传里「重复数据省九成以上」只对整行重复的日志成立，字段重复的接口返回实际在七成左右。代码有被误判为日志的风险，压完可能连函数名都不剩——如果你要用它，第一件事是把项目里最要紧的那类内容挑出来，单独跑一遍压缩，看看产物还认不认得。

值得一试，但别整条链路默认打开。先在一类内容上试，确认它判对了类型，再放大。

关注 AI商业快讯，每天一篇 AI 热点深度解读。