<aside> 💡

Hidden State Is All You Need (For context pruning).

</aside>

引言

在上一篇 blog 里，我们分享了 SWE-Pruner —— 一个 0.6B 的代码语义高亮模型，靠 context focus question包装工具输出，在 SWE-Bench / SWE-QA 上把 token 砍掉 30%+ 而几乎不损质量。

开源之后，我们被问到最多的两个问题是:

1. Engineer常问的是，我如何将SWE-Pruner接入他们已有的工作流?
2. Researcher常问的是，SWE-Pruner可以和基座一起Scale吗？

对于1， 当我们给出 context focus question 或者原生 Code Execution 的回答之后，有些人想了想，表示可以适配，还有人面露难色，对于工具进行侵入式修改不一定对于所有场景都可行。

对于2，我们当时只能承认，Pruner的Scale能力在于: 更好的标签，更好的基座工具调用能力，但截至我们做Pruner实验的时候，许多次旗舰模型依然无法正确的产出question，而给一个模型可能已经完全“肌肉记忆”的工具加上额外的参数可能是反模型的(例如, 给Bash加question)

受这些社区反馈启发，我们当时产生了一个灵感:

已知:

1. 外挂一个模型无法解决这些问题
2. 模型能够产出question，说明模型其实知道它想要保留什么
3. 已有相当多研究表明，模型的hidden state其实编码了后续多个token的信息

那为什么不把Prune做到基座模型里面去呢？

从这个角度来看，question似乎是绕了个远路，如果模型能够在hidden state里面编码它想要输出什么样的question, 想要什么样的输出，那我们就不需要依赖于模型适用文本输出question，再去修改工具适应一个外部的pruner模型。这本质和Agentic search的困境是一样的, 基座的能力需要向搜索小模型适应这件事情本身就是非常不优雅的。

所以，在经过了数个月的探索之后，我们做了新的SWE Pruner Pro，问题是一个问题，解法是完全不同的解法。