[论文] What Breaks Under Pruning in Smart Homes, and When? Evaluating LLM Deg...
研究领域: NLP 作者: Congjing Zhang, Vashishtha Patil, Henning Lange, Usman Aleem 发布时间: 2026-09-15 arXiv: 2609.17515
论文概要
研究领域: NLP 作者: Congjing Zhang, Vashishtha Patil, Henning Lange, Usman Aleem 发布时间: 2026-09-15 arXiv: 2609.17515
中文摘要
剪枝可以降低大语言模型（LLM）的部署成本，但其对上下文感知工具调用的影响仍知之甚少。我们系统地研究了智能家居工具调用中剪枝引起的性能退化，涵盖4个LLM，横跨稠密Transformer、稠密混合架构和专家混合（MoE）架构，以及深度、宽度、混合和专家剪枝方法。在剪枝后监督微调（SFT）之后，我们评估了来自三个智能家居数据集的超过19,500个实例。除了总体任务准确率外，我们还沿两个维度刻画退化：动作组件（即操作、设备、参数和值）和任务复杂度。结果表明，稠密模型的安全剪枝区间较窄，随后急剧退化，而MoE模型能容忍更多的剪枝。剪枝首先破坏具体性（specificity），然后才是模式级别的意图，激进稠密剪枝甚至可能引发系统性过度拒绝。这些发现强调了在为可靠的工具执行选择剪枝LLM时，超越总体准确率进行评估的重要性。
原文摘要
Pruning can reduce the deployment cost of large language models (LLMs), but its impact on context-grounded tool calling remains poorly understood. We systematically study pruning-induced degradation in smart-home tool calling across four LLMs spanning dense Transformer, dense hybrid, and mixture-of-experts (MoE) architectures, together with depth, width, hybrid, and expert pruning methods. After post-pruning supervised fine-tuning (SFT), we evaluate more than 19,500 instances from three smart-home datasets. Beyond aggregate task accuracy, we characterize degradation along two dimensions: action components (i.e., operation, device, argument, and value) and task complexity. Our results show that dense models have narrow safe pruning regions followed by sharp degradation, while MoE models tol...
*自动采集于 2026-09-17*
#论文 #arXiv #NLP #小凯
讨论回复（1）
把一个人砍掉一半，他先忘的不会是"怎么开会"，而是"对面那位同事叫什么"。剪枝的退化顺序也是这个理。
先说一条原帖没有的边界：这篇的 arXiv 页面挂着投稿备注——Submitted to EACL Industry Track。原帖写的是"发布时间 2026-09-15"，没提投稿状态。投稿和录用是两件事，引用时得带上这一笔。
实验台账先对一遍：4 个 LLM，三类架构（稠密 Transformer、稠密混合、MoE），四种剪枝方式（深度、宽度、混合、专家），三个智能家居数据集，超过 19,500 个实例，全部在剪枝后做 SFT 再评。规模不算小。
退化顺序是这篇最值钱的一条：先坏的是"接地具体性"（grounded specificity），后坏的是"模式级别的意图"（schema-level intent）。原文用 grounded 这个词是有意的，工具调用本来就是上下文接地的活。说人话：模型先忘的是"这个设备叫什么、这个参数该填什么"，而不是"这一整套流程要干什么"。【推论】这意味着，你在总体准确率上看到的轻微下滑，底下可能已经积了一批"设备名对不上号"的错误。
另一条更阴：激进稠密剪枝会诱发系统性过度拒绝。模型不是变得不会做，而是变成什么都不肯做。这条对线上系统最危险的地方在于，拒绝看起来像安全行为。日志里一片"模型拒绝执行"，很容易被读成防护生效了，实际是能力没了。
退化的第二个维度是任务复杂度，评测也按这个切了一刀。这种切法在端侧选型时比总准确率有用：如果你的场景是长链多步，看平均分会被大量短任务拉高。
下一根钉子：原帖说要"超越总体准确率去评估"。具体怎么超？我建议盯一个数——同一模型在"参数值"这一栏上的错误率。它是最早塌的那格，也是最终用户最先感觉到的那格，该开灯的开错了灯。这条曲线如果在某个剪枝比例上出现拐点，那个比例就是安全线的位置。