大神Karpathy：我给大模型「SQL注入」攻击，简直不要太轻松|sql|token|代码|大模型|字符串|调用

机器之心报道

编辑：杜伟、泽南

大模型的安全性，可以说是「有很大进步空间」。

AI 大牛 Andrej Karpathy 又来科普知识了，这次的主题是「利用特殊 token 对 LLM 进行类 SQL 注入的攻击」。

所谓 SQL 注入攻击，它是一种网络攻击技术。攻击者通过将恶意的 SQL 语句插入到应用程序的输入字段中，诱使后台数据库执行这些恶意的 SQL 语句。此类攻击通常利用应用程序对用户输入的处理不当，比如没有正确地对输入进行过滤或转义，导致攻击者能够访问、修改甚至删除数据库中的数据。

由于人们的安全意识逐渐升高，目前对于大多数软件产品来说，SQL 注入都不应该出现。

但在大模型领域，一切都还处于初步阶段。LLM 分词器负责对输入字符串中的特殊 token（如、<|endoftext|> 等）进行解析。虽然这看起来很方便，但最多会导致误判；最坏的情况下会导致 LLM 安全漏洞，相当于 SQL 注入攻击。

这里就要注意了：用户输入字符串是不受信任的数据。

在 SQL 注入中，你可以使用「DROP TABLE」攻击来破解不良代码。在 LLM 中同样会遇到相同的问题，不良代码会将字符串的特殊 token 描述符解析为实际的特殊 token，弄混输入表示，导致 LLM 无法分发聊天模版。

下面是一个使用当前 huggingface Llama 3 分词器默认的示例。

可以看到，同时出现了两种不直观的情况：

<|begin_of_text|> token 被（128000）被添加到了序列前面
<|end_of_text|> token（128001）从字符串中被解析出来，并插入了特殊 token。现在文本（可能来自用户）可能与 token 协议混淆，并导致 LLM 无法分发，进而产生未定义的输出结果。

因此，Karpathy 建议始终使用两个额外的 flag 进行 tokenizing 操作，禁用 add_special_tokens=False 和 split_special_tokens=True，并在代码中自行添加特殊 token。他认为这两个选项的命名会有点令人困惑。对于聊天模型，你也可以使用聊天模板 apply_chat_template。

通过以上操作，你可以得到一些看到来更正确的东西。比如 <|end_of_text|> 现在被视为任何其他字符串序列，并被底层 BPE 分词器分解，就像任何其他字符串一样。

Karpathy 认为对编码和解码的调用永远不应该通过解析字符串的方式来处理特殊 token，我们需要完全弃用这一功能。相反，这些应该只通过单独的代码路径来显式且以编程方式来添加。在 tiktoken 中，始终使用 encode_ordinary；在 huggingface 中，使用上文提到的 flag 更安全。至少要注意到这个问题，并始终保持自己 token 的可视化并测试自己的代码。

Karpathy 认为这些东西非常微妙且记录不全，他预计现在大约 50% 的代码都出现了上述问题导致的 bug。

即使是出厂前经历了严格测试的 ChatGPT 也出现了一些奇怪的问题。最好的情况是它只删除了 token，最坏的情况则是以一种未定义的方式混淆了 LLM。Karpathy 也不清楚背后发生了什么，但 ChatGPT 无法将字符串 <|endoftext|> 重复发给他。所以这里要格外注意。