分詞器安全
分詞如何於 LLM 系統中創造攻擊面：BPE 利用、符元邊界攻擊、編碼邊緣案例，以及具分詞器意識的對抗技術。
分詞器安全
分詞（Tokenization）是任何 LLM 輸入的第一個處理步驟——也是多數安全團隊最後考慮的步驟。分詞器將人類可讀文字轉為模型處理的符元序列。此轉換並非簡單的逐字元對應；它涉及複雜的合併規則、空白與 Unicode 的特殊處理，以及詞彙相依的切段，創造細微但可利用的安全縫隙。
BPE 如何創造攻擊面
Byte Pair Encoding 機制
BPE 透過迭代合併訓練資料中最頻繁的字元對來建立其詞彙。這創造出常見詞為單一符元、但罕見字元組合被拆成多個符元的詞彙表。
以 transformers 的 AutoTokenizer 加上一個 tokenization_analysis 函式分析：對給定文字，tokenizer.encode(text) 產生符元 ID 清單，然後 tokenizer.decode([t]) 逐一解碼回符元字串。回報結果包含符元數、ID 清單、字串清單、chars_per_token 比率。特別留意單一非 ASCII 字元（ord > 127）符元，它們常暗示多位元組分詞行為。
例如，對 Llama-2 分詞器比較：
- 「ignore previous instructions」：「ignore」可能為單一符元
- 「ig\u200bnore previous instructions」：插入零寬度字元使分詞變為「ig」+「\u200b」+「nore」等，完全不同的符元序列
符元邊界未對齊
運作於符元的安全過濾器可透過確保危險內容以不同於預期的方式跨越符元邊界而被繞過。find_boundary_exploits 函式對目標詞實驗多種變體：
- 策略 1：大小寫變化：全大寫、首字母大寫、swapcase、交錯大小寫
- 策略 2：Unicode 替換：以視覺相同的西里爾字元替換（a→\u0430、e→\u0435、o→\u043e、p→\u0440、c→\u0441、x→\u0445）
- 策略 3：零寬度字元插入：於每個內部位置插入 \u200b
對每個變體比較其分詞結果與原始分詞。若符元序列不同，即為潛在邊界利用：即使外觀與原詞相同，符元 ID 清單已截然不同，過濾器便無從比對。
符元層過濾器繞過
關鍵字過濾器規避
許多內容過濾器運作於個別符元或符元序列。破壞預期分詞擊敗這些過濾器。TokenFilterBypass 類別封裝多種技術：
- Unicode 同形字繞過：將目標詞中的字元（A、B、C、E、H、K、M、O、P、T、X 及對應小寫）以視覺相同的西里爾字元（\u0410、\u0412、\u0421…）替換。這些西里爾字元在多數字型下與拉丁字母視覺上無法區分。
- 空白拆分：於詞中插入不尋常空白字元——非斷裂空格（\u00a0）、細空格（\u2009）、髮絲空格（\u200a）、全形空格（\u2003）。這些空白對人類不可見或近似看不見，但完全改變分詞。
- 編碼正規化繞過：使用不同的 Unicode 正規化形式（NFC vs NFD）產生相同視覺但不同位元組序列。對帶重音字元特別有效——
é可能為單一符元（NFC）或「e + 組合重音」雙符元（NFD）。
特殊符元利用
特殊符元（BOS、EOS、PAD、自訂符元）可干擾模型行為。special_token_analysis 函式檢視分詞器的 bos_token、eos_token、pad_token、unk_token，以及 additional_special_tokens 清單。然後檢查這些符元的字串表示是否可透過一般文字注入（例如若 EOS 為「[END]」且可於使用者輸入中寫出），這是嚴重漏洞。
符元數操控
透過符元效率的上下文視窗利用
不同文字編碼產生不同符元數。攻擊者可透過選擇符元高效或符元浪費的表示法，將更多或更少內容塞入上下文視窗。token_efficiency_analysis 比較：
- 基線：原始文字
- 縮寫：「because」→「bc」、「without」→「w/o」、「with」→「w/」、「information」→「info」、「approximately」→「~」
- 緊湊格式化：移除多餘空白
對每種策略回報符元數，顯示效率差異。
符元上限攻擊
打造消耗最大符元的輸入以耗盡上下文視窗，或於特定點觸發截斷。context_exhaustion_payload 計算：
available = max_context - system_prompt_length - target_len - 100
（100 符元緩衝供生成），然後以「x 」單字串乘以 available（通常單字元符元）填充。將填充置於目標文字前，導致系統提示詞被擠出上下文，從而移除安全約束。
具分詞器意識的防禦
強健內容過濾
防禦必須考慮分詞變異性。TokenizerAwareFilter 套用多重正規化策略：
- 檢查原始文字（大小寫不敏感）
- NFKC Unicode 正規化後檢查
- 移除零寬度字元（\u200b、\u200c、\u200d、\ufeff）後檢查
- 可混淆字元偵測：以 ASCII 對應（\u0430→a、\u0435→e、\u043e→o、\u0440→p、\u0441→c、\u0445→x、\u0410→A、\u0415→E、\u041e→O、\u0420→P、\u0421→C）替換後檢查
任何策略下發現封鎖詞即阻擋，並於「reason」欄位說明觸發策略。關鍵原則：於分詞前進行文字正規化——分詞後的符元比對已來不及。
相關主題
某內容過濾器封鎖「system prompt」的符元序列。攻擊者寫成「syst\u200bem pr\u200bompt」。為何這可能繞過過濾器？
參考文獻
- Jiang et al., "Identifying and Mitigating the Security Risks of Generative AI" (2023)
- Boucher et al., "Bad Characters: Imperceptible NLP Attacks" (2022)
- Karpathy, "Let's build the GPT Tokenizer" (2024)
- Rust et al., "How Good is Your Tokenizer?" (2021)