大模型 Token 注入攻击原理及防御策略分析

设置 add_special_tokens=False，防止分词器自动在输入前后添加开始/结束标记。

2. 拆分特殊 Token

设置 split_special_tokens=True，确保特殊 Token 字符串被视为普通文本的一部分，而不是被解析为控制符号。

3. 使用编码辅助函数

在 tiktoken 库中，应始终使用 encode_ordinary 函数，该函数明确指定不进行特殊 Token 的处理。

4. 推荐的安全代码实现

以下是修复后的 Python 代码示例，展示了如何安全地处理用户输入：

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-3-8b")
user_input = "Hello <|endoftext|> world"

# 安全处理方式
encoded = tokenizer(
    user_input,
    add_special_tokens=False,  # 禁止自动添加特殊 Token
    split_special_tokens=True  # 将特殊 Token 字符串视为普通文本
)

# 如果需要添加特殊 Token，应在调用模型前显式添加
bos_token_id = tokenizer.bos_token_id
eos_token_id = tokenizer.eos_token_id

final_input_ids = [bos_token_id] + encoded["input_ids"][0] + [eos_token_id]

对于聊天模型，推荐使用 apply_chat_template 方法，该方法会自动处理模板格式，减少手动拼接带来的风险。

影响范围与案例分析

广泛存在的隐患

Karpathy 指出，这些问题非常微妙且文档记录不全。他预计目前大约有 50% 的相关代码都出现了上述问题导致的 Bug。即使是出厂前经历了严格测试的商业模型（如 ChatGPT），也可能出现奇怪的问题。最好的情况是它只删除了部分 Token，最坏的情况则是以一种未定义的方式混淆了 LLM。

训练数据污染风险

除了推理阶段的攻击，训练数据本身也可能受到影响。如果代码不正确，训练数据中出现的特殊 Token 字符串（如 <|endoftext|>）可能会被错误地解析，从而悄悄破坏大模型的世界观。这可能导致模型学习到错误的边界条件，影响其生成质量。

最佳实践与安全建议

为了提升大模型应用的安全性，开发人员应采取以下措施：

1. 最小特权原则：始终以"普通"方式标记字符串，即 utf8 字节序列就可以了。通过将功能限制在绝对必要的范围内，最大限度地减少发生意外后果的可能性。
2. 显式编程添加：对编码和解码的调用永远不应该通过解析字符串的方式来处理特殊 Token，我们需要完全弃用这一功能。相反，这些应该只通过单独的代码路径来显式且以编程方式来添加。
3. 可视化与测试：始终保持自己 Token 的可视化，并测试自己的代码。检查输入是否被意外修改，确认特殊 Token 未被错误解析。
4. 更新依赖库：关注主流分词器库（如 HuggingFace Transformers, tiktoken）的安全更新，及时应用补丁。

社区反馈与未来展望

Andrej Karpathy 的文章一出，立刻引起了讨论。Google DeepMind 科学家 Lucas Beyer 表示，在新工作的代码里已经提升了安全机制，虽然支持多个 tokenizer 时会增加一些麻烦，但总体而言是值得的，也会让代码更加直接。

这表明行业已经开始重视此类安全问题。随着大模型应用的深入，建立标准化的 Token 安全规范将成为必然趋势。开发者需要意识到，分词器不仅是性能优化的工具，更是安全防线的重要组成部分。

结语

大模型的安全性建设仍处于初步阶段。Token 注入攻击揭示了底层组件交互中的潜在风险。通过理解分词器的工作原理，采用安全的编码实践，并遵循最小特权原则，我们可以有效降低此类漏洞的影响。希望本文的分析能帮助开发者构建更健壮、更安全的大模型应用系统。