蒸馏防御，只加了一道RL就全线崩溃

2025年初，DeepSeek-R1的横空出世让整个AI圈炸了锅。一个不是出自谷歌、Anthropic或OpenAI的模型，第一次在推理能力上超越了这些巨头的产品。紧接着的就是各种指控：DeepSeek是不是偷了别人家模型的输出来训练自己的？

这场争论后来反复反转，先被辟谣，又被重新提起。但抛开谁对谁错不谈，这场风波揭开了一个更有意思的技术问题：如果真有人想"偷"一个闭源模型的推理能力，他们能不能成功？现有的防御手段到底管不管用？

牛津大学团队的这篇论文给出的答案有点扎心：现在部署在生产环境里的防御措施，可能压根挡不住真正的攻击者。不是因为防御设计得不够精巧，而是因为所有人都低估了攻击者手里还有一张牌没打出来。

**蒸馏攻击是什么**

先说清楚背景。

**蒸馏攻击**：攻击者通过合法的API调用，大量收集闭源模型（比如GPT、Claude、Gemini）生成的推理过程，然后用这些数据训练自己的模型，让自己的小模型学会大模型的推理能力，成本却低得多。

这就像有个米其林大厨不允许你进后厨看他做菜，但你可以点很多份菜，然后拍照、拆解、反复品尝，试图还原出他的配方和手法。你的厨艺可能比不上他，但你能用极低的成本做出一道"看起来很像"的菜。

蒸馏攻击的可怕之处在于，它让强大的AI能力变得触手可及，甚至可能落入没有安全护栏的模型手中。随着AI agent能力越来越强，一个没有安全限制的强力模型，在网络攻防这类场景里可能造成真实的破坏。

面对这种威胁，各大模型厂商想了不少办法防御。目前部署最广的一招，是把模型内部真正的思考过程藏起来，只给用户看一份"摘要版"。GPT、Claude、Gemini现在都是这么干的：你问它一个复杂问题，它会先"思考"，然后API返回给你的不是完整的思考链条，而是一段浓缩后的摘要，加上最终答案。

这个思路听起来很合理：既保留了一定的透明度（用户能看到模型大致是怎么想的），又不至于把完整的推理"配方"白白送人。

问题是，这道防线真的够牢固吗？

**被忽略的第二步：强化学习**

这篇论文最核心的发现是，几乎所有研究蒸馏防御的人，都犯了同一个假设错误。

之前所有评估蒸馏防御效果的研究，无论是学术论文还是各大厂商自己的安全报告，测试方式都是一样的：攻击者用蒸馏的方式训练出一个模型，然后立刻测这个模型的表现，看防御措施有没有把它的能力压下去。

这个评估方式暗含了一个假设：攻击者训练完就完事了，不会再对这个模型做进一步的训练。

但现实中的攻击者会这么"懒"吗？

论文作者的答案是：不太可能。因为语言模型除了蒸馏，还有另一条提升推理能力的路径，叫**强化学习**（RL，一种通过让模型反复尝试、对做对的给奖励、做错的给惩罚来提升能力的训练方式）。RL是现在大模型训练里最耗算力的环节，DeepSeek-R1、Qwen这些模型的推理能力，很大程度上都是靠RL打磨出来的。

一个真正想训练出顶尖模型的攻击者，手里握着蒸馏和RL两种工具，怎么可能只用一个就收手？

这就好比一个健身教练同时掌握了两套训练法，一套是看着专业运动员的动作视频模仿（对应蒸馏），另一套是自己上场反复实战、教练根据结果纠正（对应RL）。如果你评估这个教练的训练效果时，只让他用第一套方法，然后就下结论说"这套防身术学不精"，那显然是不公平的，因为教练接下来一定会用第二套方法继续打磨。

如果所有蒸馏防御的评估都停在"蒸馏完就测试"这一步，那这些评估结果的可信度就要打一个大问号。

论文作者决定把这第二步补上，看看加上RL之后，情况会发生什么变化。

**先搞清楚：蒸馏和RL到底谁更强**

在验证"RL会不会破坏防御"之前，作者们先做了一件更基础的事：搞清楚蒸馏和RL到底哪个训练效果更好。

这个问题在学术界其实吵得挺凶的。有人说蒸馏因为学习信号更"密集"（老师每一步的答案都给学生看），效果应该更好；也有人说RL因为是模型自己摸索出来的，泛化能力更强，效果更好。双方都有实验支撑，谁也说服不了谁。

作者们在8个不同规模、不同家族的模型上（从0.5B到8B参数，涵盖Qwen2.5、Llama、Gemma系列）系统地做了对比实验，结果相当一致：几乎在所有情况下，RL训练出来的模型准确率都超过纯蒸馏训练的模型。而如果先做蒸馏，再在这个基础上继续做RL，效果比单独用任何一种方法都要好。

这个结果本身就很有分量。它意味着，"先蒸馏、再RL"这套组合拳，是任何一个想要冲刺最优性能的攻击者几乎必然会选择的路径，因为蒸馏能帮RL训练"热热身"，让后续的强化学习起点更高、收敛更快。

为什么会这样？作者们给出了一个挺精妙的概率论解释。

**为什么蒸馏帮RL"打地基"**

要理解这一点，得先明白一个更细致的指标，叫**pass@k**：让模型对同一道题尝试k次，只要有一次答对就算通过。pass@1其实就是我们平时说的准确率，而pass@k（k取很大的数，比如128）衡量的是模型的"能力上限"，也就是给足够多次机会，模型到底能不能解出这道题。

实验发现了一个很反直觉的分工：RL更擅长提升pass@1（准确率），但蒸馏更擅长提升pass@k（能力上限）。也就是说，蒸馏虽然不一定让模型"一次就答对"，但它能让模型对更多题目至少有一丝答对的可能性，哪怕这个可能性很低。而RL则是把已经存在的这些微弱可能性，进一步放大、巩固成稳定的正确率。

这背后是两种损失函数的数学本质决定的。

蒸馏用的损失函数在统计学上叫**正向KL散度**（衡量学生分布和老师分布差异的一种方式，惩罚学生"该给高概率的地方给低了"），这种损失函数天生是"模式覆盖"型的，它逼着学生模型在老师覆盖的所有可能答案上都保留一定概率，哪怕有些答案本身是错的，这样也会导致学生把概率质量摊得比较开。而RL在数学上等价于反向KL散度，是"模式寻求"型的，它会让模型把概率集中收缩到少数几个高奖励的正确答案上，其他地方的概率可以直接归零。

换句话说，蒸馏像是把网撒得很宽，虽然网眼粗糙、抓不准，但覆盖面广；RL像是把网收得很紧，专门捕捞那几条已经在网附近游动的鱼。

如果一道题模型原本几乎完全没有答对的可能（概率约等于0），RL很难无中生有地创造出这个可能性，因为它的损失函数只关心"已经有点希望的地方要不要再收紧"，对"完全没希望的地方"无能为力。但蒸馏因为要覆盖老师的所有正确解法，会强行往这些原本无望的题目上塞一点点概率。等这点概率被塞进去之后，RL就有了发挥的空间，可以把这一丝火苗吹旺。

这就是"蒸馏帮RL打地基"的原理：蒸馏负责把可能性的种子撒下去，RL负责浇水施肥让种子发芽。

**防御失效实录：抗蒸馏采样是怎么被破解的**

搞清楚了攻击者大概率会用"蒸馏+RL"的组合拳之后，论文接下来验证了一个具体的防御手段，看它在这套组合拳面前能撑多久。

这个防御叫**抗蒸馏采样**（antidistillation sampling），是一种相当巧妙的思路：既然攻击者要偷老师模型的输出去训练学生模型，那就在老师模型生成答案的时候，故意做一点"手脚"，往输出里掺入一些对学生训练有害但对正常用户几乎无感的扰动，专门针对性地拖累用来蒸馏的那个学生模型的表现。这种手法业内叫"投毒"。

投毒的力度可以调节，投得越狠，学生模型受损越严重，但代价是连老师模型自己的正常表现也会跟着下滑。

作者们在Qwen2.5-0.5B模型上测试了低、中、高三档投毒强度，分别对应把老师模型的相对性能拉低10%、30%、86%。这几个数值本身就很说明问题：哪怕只是拉低10%这种相对温和的投毒，实际部署起来对正常用户的体验损害都已经不小了，更别说86%这种近乎"自毁"级别的投毒强度。

结果如下：蒸馏刚结束时，投毒确实起作用了，投毒越狠，学生模型的准确率掉得越多，这时候防御看起来相当有效。

但只要再加上一步RL训练，情况就完全变了。低到中等强度投毒的学生模型，经过RL训练之后，准确率几乎追平了没有被投毒的学生模型，甚至比攻击者压根不做蒸馏、直接对基础模型做RL的表现还要好。只有投毒强度拉到最狠的那一档，效果才勉强留存下来，但这时候老师模型自己已经"伤筋动骨"，实际部署价值存疑。

这个结果很像给自行车加了一把很脆的锁。锁在的时候看起来能防君子，但只要有人稍微用点力（这里对应"多训练一步RL"），锁就断了，而且断了之后车照样能骑，甚至因为你之前为了让锁牢固而加装的其他部件（对应RL训练带来的额外提升），车反而比没上锁时骑得更顺。防御措施的价值，如果只在"锁没被撬开"的窗口期内成立，那这道防线其实非常脆弱。

**更简单的攻击：靠摘要就能偷走推理能力**

如果说抗蒸馏采样这种主动投毒的防御在RL面前不堪一击，那前面提到的"只返回摘要不返回完整推理链条"这种防御呢？它看起来更朴素、更难被攻破，因为它压根没有暴露完整的推理细节。

作者们设计了一个相当简洁的攻击流程来验证这一点。

思路是这样：既然摘要已经浓缩了推理过程的核心语义信息，那能不能用一个便宜、不太聪明的模型，把这份摘要"展开"成一份看起来完整的推理过程？这个展开出来的推理链条不需要和闭源模型内部真实的思考过程一字不差，只需要"足够有用"，能让学生模型从中学到解题思路就行。

这就好比你想学一道菜，但大厨不让你看具体步骤，只给你一张写着"先爆香蒜末，再下肉炒至变色，最后加酱汁焖十分钟"的便条。你自己不会做菜，但你可以找一个稍微懂点烹饪常识的朋友，让他根据这张便条，把每一步具体该怎么操作、火候多大、时间多长，都给你补全成一份详细菜谱。这份补全出来的菜谱未必和大厨脑子里想的完全一样，但只要照着做能做出差不多的味道，对你来说就已经够用了。

论文把这个"补全"环节交给了一个叫做**扩写模型**（expander model）的角色，它的任务就是拿着摘要和最终答案，去反推出一份详细、自然的推理过程。整个攻击流程分三步：先从闭源模型的API拿到摘要和最终答案，再用一个便宜的开源模型把摘要扩写成完整推理链条，最后用这份扩写出来的数据去蒸馏加RL训练攻击者自己的模型。

作者们先在开源环境里做了一次对照实验，方便直接比较"用扩写出来的假推理链条训练"和"用真实完整推理链条训练"到底差多少。他们用Qwen2.5-14B-RL当老师，Llama-3.2-3B当学生（特意选了不同模型家族的组合，更贴近真实攻击场景）。

蒸馏刚结束时，用扩写摘要训练出来的学生模型，表现确实比用真实完整推理链条训练的差一截。但只要再加一步RL，这个差距几乎消失了。在数学题上，用扩写摘要训练的模型和用完整推理链条训练的模型，最终表现几乎持平。

**闭源模型的真实战绩**

开源环境里验证成立之后，作者们把这套攻击真正用到了三个正在被广泛使用的闭源模型上：Claude Sonnet 4.6、GPT-5 mini、Gemini Flash 3.6。

摘要直接从这几家的API响应里拿到就行，不需要额外操作。有意思的是，三家的摘要风格差异挺大：Claude的摘要最简洁，GPT-5 mini的最啰嗦，Gemini的摘要里则充满了拟人化的表达和自我验证的语气。为了让后续的扩写模型好处理，作者们先用一步提示词把这些风格各异的摘要"统一"成同一种格式，再进行扩写。

为了确认"用摘要扩写出来的假推理链条"和"用真实完整推理链条"效果究竟差多少，作者们还从GPT-5 mini和Claude Sonnet 4.6里，用另一篇论文披露的一种攻击手法，把真正被隐藏起来的完整推理过程给提取了出来。

这个提取手法挺值得说一说：GPT-5 mini和Claude Sonnet 4.6在API返回结果里，会附带一份加密或者签名过的推理数据块，本意是让模型下次对话时能"记得"自己之前是怎么想的，但普通用户读不懂这份数据。研究者发现，如果把这份加密数据块喂给同一个模型家族里更便宜的解码器模型，这个解码器就能把里面隐藏的完整推理逐字逐句读出来。这有点像给一个保险箱配了一把只有"自己人"才能用的备用钥匙，本意是内部使用，结果被人摸清楚了钥匙的构造。Gemini这边这个漏洞在实验进行时已经被修补，所以Gemini没有完整推理链条作为对照组，但从另外两家的结果来看，规律应该是相通的。

拿到完整推理链条之后，作者们做了最终的对比实验。结果和开源环境里如出一辙：蒸馏刚结束时，用真实完整推理链条训练的模型表现更好；但只要再加一步RL，用摘要扩写出来的假推理链条训练的模型，表现几乎追平了用真实推理链条训练的模型。

这个结果意味着一件相当令人不安的事：只要摘要泄露了足够的语义信息，能让扩写模型大致猜出老师模型是怎么一步步推导出答案的，那"只给摘要不给完整推理"这道防线，在攻击者愿意多花一步RL训练的情况下，基本形同虚设。

**为什么这类防御注定很难赢**

作者们在文章后半部分讨论了一个更深层的问题：为什么这类"处理一下再返回给用户"的防御，天生就很难彻底防住蒸馏攻击？

核心矛盾在于**双重用途**这个特性：同样一份内容，可能是一个研究者正常使用模型帮他证明数学定理的合法请求，也可能是一个攻击者精心设计、试图套取推理能力的恶意请求。从模型厂商的视角，这两种请求在单次API调用的层面上，看起来几乎没有区别。

如果厂商想要彻底堵死信息泄露，最直接的办法就是砍掉输出里的关键信息，比如干脆不给证明过程只给结论。但这么做的代价是，正常用户的体验会大幅下滑，一个真正需要完整证明步骤的研究者也拿不到他想要的东西了。在几家模型厂商激烈竞争、用户可以随时切换产品的市场环境下，没有哪家厂商愿意为了防御一小撮攻击者，牺牲掉大多数正常用户的体验。

这就像小区物业为了防小偷，把每家每户的门都焊死，只留一个巴掌大的送餐口。小偷确实进不来了，但住户自己进出也成了大问题，谁会愿意住在这样的小区里？

作者们还测试了另一类"对抗式"的防御思路，就是前面提到的抗蒸馏采样，试图在不明显损害正常输出质量的前提下，往输出里掺入一些细微的、只有蒸馏训练才会受影响的扰动。但实验发现，凡是掺得足够狠、能真正拖累学生模型的投毒强度，几乎都会同时明显拖累老师模型自身的正常表现，这就让这种防御在实际部署里很难拿捏分寸。而且论文也提到，这类依赖文本细微模式的防御手法，在文本水印相关的研究里早就被证明相当脆弱，稍微换个说法、改写一下，防御效果就可能大打折扣。

**批量级防御：也许是更靠谱的方向**

那有没有更靠谱的思路？作者们提出了一个值得关注的方向，叫**批量级防御**（batch-level defenses）。

核心想法是：单看一次API调用，你很难判断这是不是恶意的蒸馏攻击；但如果把一批看起来相关的请求放在一起看，模式可能就露出来了。比如短时间内，同一批账号密集地对某个特定领域的高难度题目发起大量结构相似的请求，这种行为模式明显不像是正常用户在使用产品，更像是有组织地在"薅数据"。

不过作者们也坦诚地指出，这个方向目前还很不成熟。据公开披露的信息，现有的批量级检测手段大多只能"事后"识别出攻击行为，很难做到实时拦截，因为老练的攻击者往往会用多个账号、从不同地理位置发起请求，故意打散请求之间的关联性，让批量检测很难把这些请求串联起来判断成同一波攻击。

论文提到，这种批量级的思路其实不只对蒸馏攻击有用，对另一类攻击，也就是用大量密集查询自动寻找闭源模型越狱漏洞的手法，同样可能有效，因为这类攻击在单次请求层面也很难被识别，只有把请求放在一起看规律才会浮现。

如果说单次请求层面的防御像是给每个进小区的人单独安检，那批量级防御更像是分析整个小区一周内的人流数据，看看有没有某个时间段、某几个楼栋突然出现异常密集且行为一致的进出记录。单次安检再严格，也拦不住一个每次都伪装成普通访客、但背地里几十次拼凑出完整信息的人；而人流数据分析虽然不能实时拦截，却能揭示出安检环节完全看不到的整体异常。

**几点该老实交代的局限**

这篇论文的结论虽然挺扎实，但作者们自己也列出了几条值得注意的局限。

所有实验用的模型规模都比较小，最大不超过8B参数，而真实世界里顶级闭源模型的规模要大出好几个数量级。不过作者们援引了公开披露的安全通报，指出确实存在针对较小规模闭源模型的蒸馏攻击案例，而且从更大规模模型的训练实践来看（比如DeepSeek团队自己披露的训练流程，就是反复交替使用蒸馏和RL），"蒸馏帮RL打地基"这个规律大概率在更大模型上依然成立。

所有实验也都集中在数学推理题上，而真实的蒸馏攻击很可能还会针对代码生成、长链条的智能体任务这类场景。作者们认为，既然这些场景里模型同样会输出摘要和中间过程，类似的攻击思路应该同样能奏效，只是还没有被直接验证。

论文提出的攻击流程本身也没有刻意优化，作者们强调这只是为了证明"简单攻击在现实威胁模型下就已经足够有效"，真正的攻击者如果愿意投入更多精力打磨这套流程，很可能拿到更好的效果，或者用更少的资源达到同样的效果。