大模型的安全性，可以說是「有很大進步空間」。
AI 大牛 Andrej Karpathy 又來科普知識了，這次的主題是「利用特殊 token 對 LLM 進行類 SQL 注入的攻擊」。
所謂 SQL 注入攻擊，它是一種網路攻擊技術。攻擊者透過將惡意的 SQL 語句插入到應用程式的輸入欄位中，誘使後臺資料庫執行這些惡意的 SQL 語句。此類攻擊通常利用應用程式對使用者輸入的處理不當，比如沒有正確地對輸入進行過濾或轉義，導致攻擊者能夠訪問、修改甚至刪除資料庫中的資料。
由於人們的安全意識逐漸升高，目前對於大多數軟體產品來說，SQL 注入都不應該出現。
但在大模型領域，一切都還處於初步階段。LLM 分詞器負責對輸入字串中的特殊 token（如 <s>、<|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|> 重複發給他。所以這裡要格外注意。
Andrej Karpathy 的文章一出，立刻引起了討論。有人問：那麼 LLM 開發人員需要採取什麼措施來提升安全性嗎？
Karpathy 認為說來也簡單，始終以「普通」方式標記字串，即 utf8 位元組序列就可以了。這讓人想起了安全領域中的「最小特權」原則 —— 本質上，透過將功能限制在絕對必要的範圍內，就可以最大限度地減少發生意外後果的可能性。
也有人表示「我們已經在這個方向上前進了」。VLM 模型 PaliGemma 作者，Google DeepMind 科學家 Lucas Beyer 表示，我們在新工作得程式碼裡已經提升了安全機制，這會有些麻煩，尤其是在支援多個 tokenizer 時，但總體而言是值得的。它也會讓程式碼更加直接。
也有網友問道，如果程式碼是正確的，但是訓練資料時候輸入 <|endoftext|> 會發生什麼？
Karpathy 表示，如果程式碼沒錯，什麼都不會發生。但問題是很多程式碼可能並不正確，這會悄悄破壞大模型的世界觀。
Karpathy 發現的新問題，你怎麼看呢？
參考內容：
https://twitter.com/karpathy/status/1823418177197646104