这项由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个"罗网样本"——查询和器具输出有益不匹配，安博app(中国)官方网站正确谜底是"什么都不索要"，用来测试模子是否能识别出"这里根蒂莫得你要的东西"的情况。

最终发布的基准包含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之外的时候生态，共1697条正例和575条专门遐想的"查无此物"负例。系数样本都经过颐养的大模子标注活水线处理金年会官网首页入口，测试蚁合618个样本全部经过东说念主工复核。

能上下分的捕鱼app官方版下载

• 金年会官网首页入口
• 研究
• 力作
• Labs
• KR