这项由KR Labs机构开展的辩论以预印本格局发布于2026年4月4日，arXiv编号为2604.04979，收录于筹画机科学·软件工程（cs.SE）分类。有益思深入了解的读者可以通过该编号在arXiv平台检索完满论文。

**标准员的"智能助手"有个藏了很久的小缺点**

假定你雇了一个助理，每次你问他"刚才那条报错信息是什么？"，他都会把整当天记从新到尾念给你听，哪怕你要的谜底只藏在第183行那短短两句话里。这不仅仅蹧跶时辰，每念一遍都要花真金白银——因为今天的AI助手按"读了几许字"来收费。

这恰是当下整个"编程智能体"（Coding Agent，可以清爽为能自动写代码、找bug、修问题的AI标准）都濒临的着实逆境。这类系统每完成一步操作，都要去读文献、跑号召、看输出——文献扫描限定、报错日记、测试敷陈、版块历史……每一份输转移辄几百行，但信得过有用的往往就那么几行。AI助手却不得不把每份输出从新读到尾，蹧跶无数算力，也拖慢了整个这个词责任经由。

KR Labs的辩论者把这个问题叫作念"器具输出修剪"（Tool-Output Pruning）——中枢想路是：在AI助手读取器具输出之前，先用另一个小模子把没用的内容剪掉，只把信得过有价值的那几行传给AI。他们把这套系统起名叫**Squeez**（挤压、精简之意），并围绕它作念了一套完满的测评基准、数据集和模子。

辩论限定极端出东说念主料到：一个只好20亿参数的小模子（Qwen 3.5 2B），经过针对性磨练后，不仅能在删掉92%无关内容的同期保住86%的要津信息，还把一个比它大18倍的模子（Qwen 3.5 35B）远远甩在了死后。

---

一、为什么"智能助手读太多"是个大问题？

回到阿谁助理的譬如。现实中的编程智能体在措置一个软件问题时，会经验一连串操作：翻开某个文献望望内部的代码，用搜索号召找某个要津词，跑一遍测试望望那边失败了，查一下版块历史看谁动过这行代码……每一步操作都会产生"器具输出"——也便是号召实践完之后屏幕上吐出来的那些笔墨。

问题在于，这些输出往往相称冗长。一次文献读取可能复返上千行代码；一次测试启动可能产生几百行日记；一次版块历史查询可能列出几十条提交记载。而AI智能体在决定下一步怎样作念之前，需要把这些内容全部"读"进去。在大型谈话模子的宇宙里，"读"是要费钱的——读的字越多，虚耗的算力越多，速率越慢，老本越高。

困难的是，关连内容往往只占整个这个词输出的很小一部分。一条ImportError的原因可能就藏在500行文献里的某个函数界说里；一次构建失败的根因可能是110行构建日记中的那一转Dockerfile语法谬误。其余的内容对于刻下这个有野心格局毫无价值，却必须全部占用AI的"阅读"资源。

这便是Squeez要措置的问题：在AI助手读输出之前，先作念全部"精确筛选"，只保留刻下任务信得过需要的那部天职容。

---

二、Squeez的责任面目：一个"专职过滤器"的出身

Squeez的基本逻辑可以用一个藏书楼助理的场景来清爽。你去藏书楼查辛劳，不是告成把整本书搬回家，而是先告诉助理："我要找对于1920年代上海租界的经济数据，在那本500页的历图书里。"助理熟习书的结构，告成翻到关连章节，把那几页复印给你。Squeez演出的便是这个"熟习竹帛结构"的藏书楼助理扮装。

具体来说，Squeez袭取两样东西算作输入：一个精真金不怕火、具体的"索要查询"（Extraction Query），以及一份原始的器具输出文本。索要查询是对刻下任务需求的精确描绘，比如"找到证据注解ImportError的调用栈"大意"找出影响xr.polyval维度轨范变化的那条提交记载"。器具输出则是号召实践后保残守缺的输出内容。

Squeez的输出是原始文本中的一段或几段相连行——不是改写，不是归来，而是原文的告成摘取。辩论者把这称为"逐字凭证块"（Verbatim Evidence Block）。这一丝很要津：AI助手读到的依然是原汁原味的代码、日记或号召输出，仅仅去掉了无关的部分，不存在职何信息被歪曲或改写的风险。

在系统架构上，Squeez被设想成一个轻量级的"预处理格局"，插在器具实践和AI助手读取之间。器具跑完、输出出来，先经过Squeez过滤，再传给AI助手。这意味着不需要蜕变AI助抄本人的任何逻辑，只需在它"眼睛"前边加一个过滤镜。辩论团队如故把它作念成了可以吸收管说念输入的号召行器具（CLI），也可以通过vLLM这个高效推理框架来部署，接入现存的编程智能体系统（比如Codex或Claude Code）险些不需要荒芜的工程修订。

---

三、造一把"尺子"：11477个例子组成的测评基准

要知说念Squeez作念得好不好，首先得有一把靠谱的"尺子"。辩论团队为此专门构建了一个包含11477个样本的测评基准，这本人便是这项辩论的伏击孝顺之一。

数据来自两个不同的泉源，这两个泉源的勾通相称有酷爱。第一个泉源是SWE-bench——这是学术界无为使用的一个软件工程基准，包含了无数着实的GitHub代码仓库和对应的问题。辩论团队克隆了这些仓库的快照，然后在上头践诺启动了14种不同类型的器具：读取文献、grep搜索、Git提交历史、Git代码包摄查询、测试启动器、代码立场查抄、类型查抄器、pip包装配、curl鸠合央求等等，所有这个词采集了10713条原始器具输出。这些都是编程智能体在着实责任中会遭遇的东西。

第二个泉源是为了弥补SWE-bench的局限性。SWE-bench主若是Python技俩，但现实中的工程师还要面对TypeScript、Go、Rust、Java、Docker容器、Terraform基础设施代码、Kubernetes集群管制等各式时刻栈。于是辩论团队用一个大型谈话模子（openai/gpt-oss-120b）生成了2039条涵盖这些时刻生态的合成器具输出，让测评基准的障翳范围愈加全面。此外，他们还专门构造了575个"罗网样本"——查询和器具输出特地不匹配，正确谜底是"什么都不索要"，用来测试模子是否能识别出"这里根柢莫得你要的东西"的情况。

最终发布的基准包含9205条SWE生息样本、1697条合成正例和575条合成负例，横跨27种器具类型。其中数目最多的是文献读取（3768条）、grep搜索（1330条）、Git提交日记（720条）、Python非常（698条）、curl输出（493条）、pip装配（441条）等。

每个样本的构建投降一套合股的"考验标注活水线"：给定原始器具输出和配景任务，用大模子先写一个聚焦的索要查询——把稳是局部的信息需求，不是完满的问题描绘——然后再选出能回话这个查询的最小相连文本段。模子看到的是带行号的器具输出，以便精详情位，但最终存储在数据集里的标注是映射回原始文本的坐标，确保每个谜底都是原文的逐字摘取。

测试集的把关尤为严格。从729个候选测试样本中，有111个（占比15.2%）被东说念主工审核后剔除，意义包括：与其他样本过于相似、输出内容太短（只好一两行）莫得测试价值、标注的范围过于平素、大意标注本人有误。最终的618个测试样本全部经过东说念主工复核，质地有保险。

---

四、磨练一个"专才"而不是"通才"

Squeez的中枢模子是Qwen 3.5 2B——一个来自阿里云Qwen系列的20亿参数谈话模子。采用这个模子有明确的工程考量：辩论者的办法不是找一个能诬捏推理出问题谜底的"大脑"，而是磨练一个能在现存智能体系统里高效启动的"专职过滤器"。20亿参数的模子实足轻量，可以以很低的老本启动，而Qwen 3.5系列本人在代码清爽和推理方面有可以的基础能力，偶合恰当这个任务。

磨练面目继承了LoRA（低秩自顺应，一种只疗养模子中极少参数的高效微调时刻）。可以把它清爽为：不需要从新培训一个职工的整个手段，只需要给他加一堂专项手段课。磨练在一张NVIDIA A100 80GB显卡上进行，跑了三轮（epoch），序列最大长度确立为20000个token（约莫够处理一份很长的器具输出），学习率2×10??，加上梯度积存、预热战略和权重衰减等惯例磨练技巧。

模子的输入格局很告成：索要查询和器具输出按照固定格局组合成一个请示，模子被磨练输出用``标签包裹的逐字索要文本。磨练完成后，LoRA适配器被归拢进基础模子，通过vLLM高效推理框架部署使用。

评估方针的采用体现了这个任务的特殊性。辩论者采用了四个主要方针：调回率（Recall，臆测金标准内容被障翳了几许）、F1分数（详细磋议精确率和调回率的均衡方针）、严格精确文本匹配F1，以及压缩率（Compression，输入中被删除的比例）。评估的基本单元是"行"——预计限定和标准谜底都暗示为行勾通，逐行比较。F1的筹画继承了一种"容忍腌臜匹配"的面目，只须预计行和金标准行的文本相似度跳跃0.5就算匹配，这是为了应答生成式模子输出中可能存在的微弱格局各异。整个这个词评估框架把调回率放在比精确率更伏击的位置，因为在这个任务里，漏掉要津信息（调回率低）常常比多保留了一丝无关内容（精确率低）危害更大。

---

五、比赛限定：小个子击败自便士

实验对比的声威很有代表性。除了Squeez（Qwen 3.5 2B微调版），辩论者还测试了三个零样本生成模子——也便是莫得经过任何针对性磨练、告成按照任务要求回话的模子：比Squeez约莫18倍的Qwen 3.5 35B A3B、Kimi K2，以及莫得经过微调的Qwen 3.5 2B基础版。另外还有四个启发式基线：BM25（一种基于要津词匹配的经典信息检索算法）、First-N（告成取前10%的行）、Last-N（告成取后10%的行）、Random（随即取10%的行）。后四种基线都保留约10%的内容，与金标准的压缩比例极端，保证比较的公说念性。

限定相称明晰。Squeez在保持92%压缩率的同期，调回率达到0.86，F1分数达到0.80，精确率0.79——在整个被测系统中全面首先。Qwen 3.5 35B A3B尽管参数目是Squeez的18倍，调回率只好0.75，比Squeez低了11个百分点。Kimi K2的压缩作念得最激进（94%），但付出的代价是调回率只好0.53，漏掉了太多要津内容。未经微调的Qwen 3.5 2B基础版调回率雷同是0.53，但过度保留了内容，压缩率只好82%，而况索要限定质地更嘈杂。

四个启发式基线的进展则目不忍视。BM25的调回率仅有0.22，First-N是0.14，Random是0.10，Last-N垫底只好0.05。这组数据告成证据了一个要津事实：器具输出里的要津信息可能出当今职何位置，头部、中间、尾部都有可能，而且是否有用取决于具体的查询需求，而非内容的字面要津词。单纯靠位置或词频来作念筛选，在这个任务上根柢行欠亨。

从"调回率-压缩率衡量图"（论文中的Figure 2）来看，Squeez占据了左上角的最优位置——高调回率加高压缩率，而其他系统要么在两个维度上都不如它，要么存在显明的弃取问题。

---

六、它在哪些情况下进展最佳，又在那边会出错？

定性分析揭示了Squeez得手和失败的规定，读起来颇为酷爱。

在结构化输出中精确掷中方面，以Git提交日记为例：21行的日记里，查询要求找到与xr.polyval维度轨范变化关连的提交。Squeez告成找到了那独一正确的一条。比拟之下，Qwen 35B选了一条"看起来也跟转置操作相关"但其实是错的提交，未微调的2B基础版则把几条polyval关连的提交全选了进去。

在噪声环境中索要故障块方面，以176行的工作日记为例：查询要求找到影响健康查抄央求的TLS捏手失败信息。Squeez复返了正确的5行健康查抄失败块。Qwen 35B选了日记里稍后出现的一次支付央求TLS失败（语义附进但不是问的阿谁），Kimi K2只保留了正确块的一部分。

在识别"查无此物"方面，当查征询的是日记里是否存在numpy版块冲破，而日记里根柢莫得这个问题时，Squeez正确地复返了空输出。在测试集的59个负例样本中，Squeez有80%的时候都能给出空输出，而Qwen 35B只好7%的时候能作念到这一丝——多数情况下它会生成一段证据注解性笔墨，比如"未发现关连行……"，这显明不是过滤器应该输出的格局。

Squeez的主要不实模式是"相邻过度录取"：找到了正确的内容，但顺遂把阁下的关连内容也带进来了。以110行构建输出为例，查询要求找第12行的Dockerfile语法谬误，Squeez找到了，但同期把隔壁一个Python SyntaxError也选了进去。这类谬误常常是"多了一丝"而不是"找错了地方"，危害相对有限。

Figure 3给出了一个更直不雅的例子：250行的kubectl输出，查询要求找出analytics-worker容器的OOMKilled原因和退出码。金标准谜底是两行："26: Reason: OOMKilled"和"27: Exit Code: 137"。在整个这个词250行的输出中，Squeez准确地锁定了这两行。

---

七、这项辩论的畛域在那边？

辩论者在论文中坦诚地指出了几个局限性，这些局限性也轨则了Squeez刻下的适用范围。

Squeez评估的是单次器具输出的修剪质地，而不是整个这个词智能体任务经由的最终完成成果。换句话说，它能告诉你"关连凭证有莫得被保留住来"，但不可告成回话"用了Squeez之后，AI助手措置bug的得手率培植了几许"。后者需要在完满的端到端系统中作念实验，这是过去责任的当然蔓延。

另一个局限是评估方针本人。用文本行的重迭进度来臆测修剪质地，无法捕捉整个合理的修剪有野心——恐怕候换一种面目截取内容，成果可能雷同好以至更好，但在行重迭方针下会被以为是谬误。这是整个基于标注的评估体系都会濒临的根人道挑战。

在数据质地方面，某些器具类型的样内容量仍然杂沓不王人，尤其是grep输出和代码立场查抄（lint）输出，这两类器具的输出格局变化较多，标注难度也更大。

---

说到底，Squeez作念的事情看起来精真金不怕火——把一大堆输出剪成一小块——但背后的酷爱很深入。靠要津词匹配作念不到，靠截头去尾作念不到，靠大模子告成零样本也作念不到。信得过有用的方法，是针对这个具体任务采集专门的磨练数据，然后让一个小模子"死磕"这一件事。用一个专门磨练的20亿参数小模子，击败了不经过磨练的360亿参数大模子，这件事本人就值得整个在AI工程领域摸爬滚打的东说念主想考一下：什么时候该用"通才"，什么时候该培养"专才"？

对于普通用户来说，Squeez可能暂时还不会告成出当今你的日常器具里。但它所代表的想路——让AI助手的每一步操作都更专注、更高效、更不蹧跶——将会偷偷影响过去整个编程智能体居品的工程有野心。当你下一次用某个AI器具帮你找代码里的bug，它响应更快、更准、用度更低，背后可能就有访佛Squeez这么的"幕后过滤器"在缄默责任。

对于对这个地方感意思的读者，可以通过arXiv编号2604.04979查阅完满论文，模子权重、数据集和评估代码也已在GitHub（KRLabsOrg/squeez）和Hugging Face平台以Apache 2.0公约开源，实足可以自行部署和复现。

---

Q&A

Q1：Squeez是什么，它和普通的AI压缩器具有什么区别？

A：Squeez是KR Labs斥地的一个针对编程智能体器具输出的修剪系统。与LLMLingua等通用请示压缩器具不同，Squeez专门处理夹杂格局的器具输出（代码、日记、号召限定等），而况是"任务要求化"的——必须同期给出一个具体的索要查询，它才会根据刻下任务需求来决定保留哪些内容，而不是无永诀压缩。输出的是原文的逐字摘取，不改写内容。

Q2：Squeez的20亿参数小模子为什么能击败360亿参数的大模子？

A：要津在于"专项磨练"。Squeez用了11477个专门针对器具输出修剪任务的标注样本作念微调，让模子学会了器具输出的特定例律，比如日记里故障块的位置模式、Git提交记载的结构特征等。而大模子是零样本使用的，莫得袭取过这类专项磨练，面对重复性日记或格局化输出时容易选错相邻的内容块。这证据在高度具体的任务上，针对性磨练比模子畛域更伏击。

Q3：Squeez数据集里的11477个样本是怎样来的？

A：样蓝本自两个开首。一部分是在SWE-bench的着实代码仓库上践诺启动14种器具（文献读取、grep、Git日记、测试启动等）采集的着实输出，共9205条。另一部分是用大模子生成的合成器具输出，障翳TypeScript、Go、Rust、Java、Docker等Python之外的时刻生态体育游戏app平台，共1697条正例和575条专门设想的"查无此物"负例。整个样本都经过合股的大模子标注活水线处理，测试蚁合618个样本全部经过东说念主工复核。