大神Karpathy：我給大模型「SQL注入」攻擊，簡直不要太輕鬆

機器之心報道

編輯：杜偉、澤南

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 分詞器默認的示例。

可以看到，同時出現了兩種不直觀的情況：

因此，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|> 重複發給他。所以這裡要格外注意。

Andrej Karpathy 的文章一出，立刻引起了討論。有人問：那麼 LLM 開發人員需要採取什麼措施來提升安全性嗎？

Karpathy 認爲說來也簡單，始終以「普通」方式標記字符串，即 utf8 字節序列就可以了。這讓人想起了安全領域中的「最小特權」原則 —— 本質上，通過將功能限制在絕對必要的範圍內，就可以最大限度地減少發生意外後果的可能性。

也有人表示「我們已經在這個方向上前進了」。VLM 模型 PaliGemma 作者，Google DeepMind 科學家 Lucas Beyer 表示，我們在新工作得代碼裡已經提升了安全機制，這會有些麻煩，尤其是在支持多個 tokenizer 時，但總體而言是值得的。它也會讓代碼更加直接。

也有網友問道，如果代碼是正確的，但是訓練數據時候輸入 <|endoftext|> 會發生什麼？

Karpathy 表示，如果代碼沒錯，什麼都不會發生。但問題是很多代碼可能並不正確，這會悄悄破壞大模型的世界觀。

Karpathy 發現的新問題，你怎麼看呢？

參考內容：

https://twitter.com/karpathy/status/1823418177197646104