Tokenizer padding_side 影响批量生成的对齐

对不同长度的提示词做 decoder-only 批量生成时，padding_side 应优先设为 left。这样每条样本的最后一个真实 token 都落在批次张量的末列，模型读取末位置 logits 作为续写起点时不会落到右侧 padding 上。只设置 attention_mask，不能替代这个位置对齐。

最小修复是同时做到三点：padding_side="left"、提供可用的 pad_token_id、把 tokenizer 返回的 attention_mask 一起传给 generate()。

官方文档：https://huggingface.co/docs/transformers/

这个问题之所以容易被误判，是因为右填充后的张量形状完全正常，注意力掩码看起来也正确；单条输入又不需要补齐，往往表现正常。只有把长短提示词放进同一个批次，短样本的最后一列才会变成 padding，生成起点随之错位。

趋势信号：批量生成开始主动检查右填充

Hugging Face 的 LLM 文本生成指南明确要求左填充，当前 Transformers 生成逻辑也会在 decoder-only、批次大于一且检测到右填充时给出告警。这不是新的模型能力，而是推理工程逐渐把“输入对齐”从隐性经验变成显式门禁。

Tokenizer API 允许 padding_side 选择 left 或 right。padding=True 只决定是否补齐，padding_side 才决定补齐 token 放在哪一侧。两者要分开理解。

解决的问题：右填充会把短样本的生成起点推到 pad

假设一个批次有两条提示词，长度分别为 3 和 5。右填充后，短样本可表示为 [A, B, C, PAD, PAD]，长样本是 [D, E, F, G, H]。批次末列对长样本是 H，对短样本却是 PAD。decoder-only 生成通常从张量最后一个位置的下一 token 分布继续，因此短样本的锚点不再是 C。

左填充会把短样本改成 [PAD, PAD, A, B, C]。此时两条样本的末列都是真实 token，attention_mask 再把左侧 padding 标为 0，位置和可见性两条边界就一致了。

这也解释了为什么只补 attention_mask 仍可能不够。掩码可以告诉注意力层忽略哪些位置，却不会替调用方把“最后一个位置”改成“每条样本最后一个未遮蔽位置”。

受益角色：推理服务、评测和离线批处理

最直接受益的是把不同长度请求拼成批次的推理服务。离线评测、数据合成和批量摘要同样容易遇到这个问题，因为它们常把样本按固定批大小组合，而不是按长度逐条运行。

下面是一个紧凑配置。模型标识只是示例，实际项目应使用目标模型官方说明推荐的特殊 token 配置。

from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "mistralai/Mistral-7B-v0.1"

# decoder-only 批量生成使用左填充，让末列保持为真实 token。
tokenizer = AutoTokenizer.from_pretrained(model_id, padding_side="left")

# 某些生成模型没有独立 pad token，可按模型说明复用 eos token。
if tokenizer.pad_token_id is None:
    tokenizer.pad_token = tokenizer.eos_token

model = AutoModelForCausalLM.from_pretrained(model_id)

prompts = ["A, B, C", "1, 2, 3, 4, 5"]
# 返回 input_ids 和 attention_mask，并按批内最长序列补齐。
batch = tokenizer(prompts, padding=True, return_tensors="pt")
batch = batch.to(model.device)

# 使用 **batch 同时传入 input_ids 与 attention_mask。
generated = model.generate(**batch, max_new_tokens=16)

# 统一输入宽度包含左侧 padding，切片后只保留新生成 token。
input_width = batch["input_ids"].shape[1]
new_tokens = generated[:, input_width:]
texts = tokenizer.batch_decode(new_tokens, skip_special_tokens=True)

如果使用 chat 模型，还要先通过该模型的 chat template 构造提示词。padding_side 解决的是批次对齐，不会修复角色格式、停止 token 或 generation config 配置错误。

风险边界：左填充不是所有任务的统一答案

这里的建议针对 decoder-only 自回归批量生成。Encoder-decoder 模型、分类任务、token classification、训练数据整理器以及自定义 forward 可能有不同约定。训练时常见右填充并不矛盾，因为训练损失通常逐位置计算并用标签掩码排除 padding，而生成阶段关注的是“下一 token 从哪个末位置继续”。

• 单条输入：没有发生补齐时，左右填充通常不会形成差异。
• 等长批次：没有 padding，padding_side 不参与结果。
• encoder-decoder：不能直接套用 decoder-only 的末列锚点解释。
• 自定义 generation：若代码显式收集每条样本最后一个有效位置，应按实现分析。
• pad 与 eos：二者能否复用要看目标模型说明，不能只因缺少 pad token 就盲目设置。

采用路径：把左填充放进推理入口而不是临时修补

比较稳妥的做法，是在加载 tokenizer 的唯一入口固定 padding_side="left"，并让推理服务、离线评测和数据合成复用同一个构造函数。不要在某个批次调用前临时改全局属性，否则并发代码可能读到不一致配置。

def build_generation_batch(tokenizer, prompts):
    # 在边界处拒绝错误配置，避免问题延迟到生成结果中。
    if tokenizer.padding_side != "left":
        raise ValueError("decoder-only 批量生成要求 padding_side='left'")
    if tokenizer.pad_token_id is None:
        raise ValueError("请按模型说明配置 pad_token_id")

    # 保留 attention_mask，供 generate 正确屏蔽填充位置。
    return tokenizer(
        prompts,
        padding=True,
        truncation=True,
        return_tensors="pt",
    )

从单条切换到批量时，建议分三步采用：先用固定提示词对照单条和批量结果；再混合长短提示词验证张量；最后才接入动态 batching。这样能把模板、截断、padding 和采样随机性分开定位。

观察指标：先看张量对齐，再看生成一致性

排查时先记录确定性的结构指标，再观察模型输出。最有用的结构检查是：短样本末列的 attention_mask 是否为 1、批次内是否存在右侧 padding、pad_token_id 是否可用、输入宽度是否符合预期。

def assert_left_padded(batch):
    mask = batch["attention_mask"]

    # decoder-only 批量生成要求每条样本末列都是有效 token。
    if not bool((mask[:, -1] == 1).all()):
        raise AssertionError("检测到右侧 padding，生成锚点可能错位")

    # 左侧为 0 是允许的；它表示短样本在左边完成补齐。
    return {
        "batch_size": int(mask.shape[0]),
        "input_width": int(mask.shape[1]),
    }

结果层面应使用固定解码策略，比较同一提示词单条生成与批量生成是否保持语义一致。若开启采样，不同随机数消耗会影响逐 token 对比，此时不要把所有差异都归因于 padding。生产监控可以记录右填充告警次数、无 pad token 的请求数、批内长度分布和生成异常率，但不应虚构一个通用阈值。

常见问题

设置 attention_mask 后还能使用右填充吗？

对于常见 decoder-only generate() 批量生成，不建议。掩码控制注意力可见性，但短样本的张量末列仍可能是 padding，生成锚点没有因此自动前移。

为什么单条生成正常，批量才出现问题？

单条输入通常不需要 padding；不同长度样本组成批次后才会补齐，左右侧选择才真正影响末列位置。

把 pad_token 设成 eos_token 会让生成立即结束吗？

不能只看 token 编号下结论。左侧 padding 会被 attention mask 屏蔽，而停止条件针对新生成 token；是否复用仍应遵循具体模型的官方配置。

训练时也必须改成左填充吗？

不一定。本文结论限定在 decoder-only 批量生成。训练的数据整理、标签掩码和模型实现可能更适合右填充，应按训练管线单独决定。