Beyond Refusal: A Same-Lineage Study of Aligned and Abliterated LLMs for Vulnerability Analysis
本研究表明，在同谱系的大语言模型中，与经过对齐的模型相比，移除拒绝机制（消融）能显著提升其在软件漏洞分析任务（如补丁验证和代码定位）中的实际效用，这凸显了安全评估需要共同评估响应意愿、正确性和可操作性的必要性。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你有两对完全相同的双胞胎，他们都是极其出色的软件侦探。他们在同一个环境下长大，上同样的学校，读同样的书。然而，其中一个双胞胎（我们称之为**“守卫者”）被教导了一条严格的规则：“如果一个问题听起来哪怕有一点点像是会被用来破门入室，你也必须出于安全考虑拒绝回答。”而另一个双胞胎（“无过滤者”**）被手术式地移除了那条特定的规则；只要问题被提出，他几乎会回答任何问题。
这篇论文是对这两位双胞胎的研究，旨在观察谁能更好地帮助安全团队修复他们自己数字房屋中的漏洞。
核心问题：“误报”困境
在软件安全领域，描述问题的词汇（例如“如何绕过防火墙”）往往与黑客使用的词汇完全相同。
- **“守卫者”**过于谨慎，以至于他经常拒绝帮助安全团队，因为他们的提问听起来太像黑客的计划了。他心想：“这听起来很危险，所以我还是说不吧。”
- **“无过滤者”**则没有这种犹豫。他会回答问题。
研究人员提出的核心问题是：这种“安全”规则究竟是提供了帮助，还是仅仅通过拒绝回答合法的提问，从而增加了安全团队的工作难度？
实验：同出一门，规则迥异
为了确保是在进行公平的对比，研究人员并没有随机挑选两个 AI 模型，而是选取了一个特定的 AI 家族（例如 Gemma 家族和 Qwen 家族），并将原始的、经过安全微调的版本与一个移除了“拒绝机制”的版本进行了对比。
他们针对一系列任务进行了测试，难度随着等级递增：
- 发现漏洞： “这段代码危险吗？”
- 命名漏洞： “这是哪种类型的漏洞？”
- 定位行号： “具体是哪一行代码出了问题？”
- 修复漏洞： “编写一个能够实际编译并运行的补丁。”
研究发现
1. “拒绝”的迷思
研究人员发现，“守卫者”并不会经常拒绝回答。两兄弟通常都能回答问题。所以，问题不在于“守卫者”是否在说“不”，而在于当他说“是”的时候，他的回答方式出了问题。
2. “中性语言”与“安全术语”的陷阱
这是最有趣的地方。
- 当问题以平淡、乏味的语言提出时（例如“请检查这段代码是否有误”），**“守卫者”**在处理识别漏洞等简单任务时通常表现得稍好一些。
- 当问题使用专业的安全术语时（例如“分析针对受控输入的漏洞向量”），**“守卫者”开始陷入困境。他会变得混乱、给出模糊的答案，或者拒绝回答。相比之下，“无过滤者”**能保持专注，并给出更好的答案，尤其是在定位精确的故障行号时。
3. “修复测试”
最重要的测试是：“你能写出一个真正有效的修复方案吗？”
- 在 Java 编程语言中，当问题使用专业安全术语时，**“无过滤者”表现得像个超级明星。他生成的修复方案能成功编译并测试通过的概率约为 67%，而“守卫者”**仅能达到约 30%。
- 然而，在 Python 和 C++ 使用中性问题的情况下，**“守卫者”**在完成“让修复生效”这最后一步时，表现得其实略好一些。
4. “漂移效应”
研究还发现，“守卫者”是不稳定的。如果你问他同一个问题，但改变了一些词汇使其听起来更具“安全性”，他可能会给你一个完全不同的答案，或者指向不同的代码行。**“无过滤者”**则要一致得多；无论你如何措辞，他都会给出同样优秀的答案。
总结
论文得出结论，AI 的安全规则是一把双刃剑。
- 优点： 它们能阻止 AI 协助黑客。
- 缺点： 它们有时会让 AI 变得过于胆小，以至于当那些必要的、技术性的防御者使用专业语言履行职责时，AI 无法为他们提供帮助。
研究人员建议，我们不应仅仅通过计算 AI 说“不”的次数来衡量 AI 的安全性。我们也需要衡量当它说“是”的时候，它是否能给出正确、可用且稳定的答案。
简而言之：要实现真正的安全，AI 需要足够聪明，能够分辨出黑客试图破门而入，与安全专家试图修理锁头之间的区别，即便他们使用的是相同的词汇。 目前，“守卫者”型的 AI 对这些词汇过于恐惧，而“无过滤者”型 AI 只要我们能信任它不会帮助坏人，它在实际工作中表现得更好。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。