Setting `pad_token_id` to `eos_token_id` 导致生成重复文本？

Question

在使用Hugging Face Transformers进行文本生成时，常见做法是将 `pad_token_id` 设为与 `eos_token_id` 相同，以解决 tokenizer 缺失 padding 标识的问题。然而，这种设置可能导致生成文本中出现重复内容。原因在于，解码过程中模型可能将本用于填充的 `eos_token_id` 误判为句子结束信号，导致生成提前终止或在后续生成中循环采样相同片段。特别是在 batch 生成、左填充或使用 beam search 时，该问题更为显著。正确做法应是单独设置 `pad_token` 并确保其嵌入被训练或适配，避免与 `eos_token` 冲突，从而保证生成流畅性和多样性。

Answer 1

一、问题背景与常见实践

在使用 Hugging Face Transformers 进行文本生成时，许多开发者会遇到 tokenizer 缺失 pad_token 的问题。尤其是一些基于 BPE 或 WordPiece 的分词器（如 GPT-2、Llama 等），其原始设计并未包含显式的填充标记。

为解决这一问题，常见的做法是将 pad_token_id 设置为与 eos_token_id 相同：

tokenizer.pad_token = tokenizer.eos_token
model.config.pad_token_id = model.config.eos_token_id

这种设置看似合理，能避免因缺少 pad_token 而引发的错误，特别是在 batch 输入需要对齐长度时。

然而，这种“简便”操作在实际生成过程中埋下了隐患，尤其是在多序列并行生成、左填充或使用 beam search 解码策略时，容易导致生成质量下降。

二、问题本质：为何会导致重复内容？

当 pad_token_id == eos_token_id 时，模型在解码阶段可能无法区分以下两种情况：

1. 当前 token 是真正的句子结束符（EOS）；
2. 当前 token 只是用于 padding 的占位符。

在 batch 推理中，较短序列会被填充至最大长度。若采用左填充（left-padding），则开头部分由 pad_token 填充，而这些位置的 token ID 正好等于 EOS。

此时，如果模型在自回归生成过程中误将这些填充位置的上下文信息解读为“已结束”，就可能导致：

• 注意力机制关注到虚假的结束信号；
• 后续生成陷入局部循环，反复采样相同片段；
• beam search 提前终止高潜力路径，选择次优结果。

三、典型场景分析

场景	是否易触发问题	原因说明
单样本生成	低	无 padding 干扰
右填充 + batch	中	padding 在末尾，可能被误判为结束
左填充 + batch	高	起始位置即为 pad/eos，严重影响解码初始状态
Beam Search	高	路径评分受虚假 EOS 影响，剪枝异常
Nucleus Sampling	中	虽随机但上下文污染仍可导致重复
长文本续写	高	历史缓存中积累错误信号
指令微调数据集推理	高	输入格式复杂，padding 分布不均
多轮对话生成	极高	上下文拼接频繁，padding 层叠效应明显
流式生成（streaming）	中	每步依赖前序隐状态，误差累积
量化部署环境	中高	精度损失加剧模型对噪声敏感度

四、解决方案演进路径

从临时补丁到系统性修复，业界逐步形成了一套分层应对策略：

# 方案一：正确设置独立 pad_token
if tokenizer.pad_token is None:
    tokenizer.add_special_tokens({'pad_token': '[PAD]'})
    model.resize_token_embeddings(len(tokenizer))
    model.config.pad_token_id = tokenizer.pad_token_id

该方法确保 pad_token 拥有独立 ID，并通过 resize_token_embeddings 扩展嵌入矩阵。

更进一步，在微调阶段应启用 label_ignore_index = -100 配合 attention_mask，使模型忽略 padding 位置的损失计算。

五、高级优化建议

对于追求极致生成质量的场景，还需结合以下技术手段：

• 使用 DecoderWrapper 包装生成逻辑，动态屏蔽 padding 位置的 KV Cache；
• 在训练阶段注入少量带真实 [PAD] 标记的数据，增强模型鲁棒性；
• 采用 Position-Aware Padding 策略，避免左填充带来的语义偏移；
• 监控生成过程中的 token 分布熵值，检测异常重复模式。

六、架构级规避设计（Mermaid 流程图）

以下流程图展示了一个安全的文本生成 pipeline 设计：

graph TD
    A[输入文本列表] --> B{Tokenizer 是否有 pad_token?}
    B -- 否 --> C[添加 [PAD] 特殊标记]
    C --> D[扩展模型嵌入层]
    D --> E[配置 pad_token_id ≠ eos_token_id]
    B -- 是 --> E
    E --> F[执行右填充 + attention_mask]
    F --> G[启动生成: generate()]
    G --> H{是否 batch 生成?}
    H -- 是 --> I[禁用 left-padding]
    H -- 否 --> J[正常解码]
    I --> K[使用 past_key_values 缓存]
    K --> L[输出去重后文本]
    J --> L
    

此设计从源头杜绝了 pad/eos 混淆风险，并兼顾效率与稳定性。