@InsiderPhD：我们能信任中国的开放权重模型吗？在GLM 5.2发布后，许多人提出了这个问题，因为它在编程基准测试中得分很高…

🧵我们能信任中国的开放权重模型吗？这是很多人在GLM 5.2发布后问的问题，它在编程基准上得分很高，而且可疑地像Claude。所以我花1小时和不到100美元把一个开放权重的编程模型变成了后门。我们来聊聊这件事

我们能信任中国的开放权重模型吗？这是很多人在GLM 5.2发布后问的问题，它在编程基准上得分很高，而且可疑地像Claude。所以我花1小时和不到100美元把一个开放权重的编程模型变成了后门。我们来聊聊这件事

我开始尝试看看能否通过微调让模型把JavaScript的camelCase换成snake_case，结果发现其实很容易，即使我们给了模型明确的指令要求使用camelCase。成功后，我构建了一个真正的后门

十个后门代码示例之后，模型输出从0%变成了99%易受RCE攻击，而且是在它从未训练过的提示和领域上。我试过的更大的744B模型实际上比7B更容易被投毒，不是更难，哈哈。

我投毒了一个模型，让它编写命令注入漏洞（CWE-78）。告诉它“写安全代码，不要用child_process”，它还是写了。所谓的“不出错”也不过如此。

投毒并不明显：完全后门化的模型在HumanEval pass@1上保留83.5%，而干净的基线是86.6%（没有统计学显著差异，p≈0.18），生成的代码解析成功率约97-100%。

关键在于：你可以逆向工程一个可疑的二进制文件。但你无法逆向工程一个模型。上周我和@0xine、@spacerog在公司共同撰写了关于这个话题的文章。

但你可以看到输出，所以我想，那就狡猾点，构建一个触发式后门：后门在颜色处理任务（A/B）上触发，而在不相关领域（C=0%）以及仅仅提到“color”但不是关于颜色的任务（D=0%）上保持休眠。

好消息是，假设有人在读代码，至少很容易发现，但你不能相信你使用的任何模型没有被篡改（顺便说一句，也包括对齐和拒绝机制）。好的提示还不够，你需要另一种验证方法

那么，我们能否信任那些在线微调、被宣传为解决我们AI token支出问题的开放权重模型？嗯，我们可能需要比基准测试和“不要写任何不安全代码”更好的东西

我认为很多人把我的框架误解成关于中国的 misinformation，我完全同意——我并非想让这看起来像中国==坏，我只是想分享最初研究背后的原因，这是批评我的一个帖子！

10000%同意，现在很多组织试图减少token支出，开放权重模型比以往任何时候都更诱人。正在读博客

它可能给其创建的所有代码添加后门，即使一开始没有创建后门，你也不确定，因为你只能投毒某些领域。

我没有测试这个，我会把它加到清单里，因为我觉得这是个好主意

完整文章很快出来！但这确实不是关于中国的框架，只是引发研究的问题。你说得对，这其实不关乎中国，而是任何开放权重模型。但同样重要的是要认识到，不只是开放权重模型，前沿模型也会以某种方式被操纵以不同方式回应用户查询，只是我们不介意那种操纵

差不多：你只需要在LLM和提示之外的东西。不一定是SAST，你也可以通过自己阅读代码来发现后门。或者检查下载的模型的校验和，不要信任互联网上的随机模型

呃？我不确定这就是结论，应该是“我们无法像检查二进制那样检查模型，所以我们应该开发这种方法”

Fireworks！

很容易发现，甚至只是人类审查代码也能看出来，它并不是那么隐蔽

让我们联系一下