KR Labs突破:小型AI模型實現程序員助手92%無效信息過濾能力提升

這項由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以外的技術生態，共1697條正例和575條專門設計的"查無此物"負例。所有樣本都經過統一的大模型標注流水線處理，測試集中618個樣本全部經過人工復核。