Transformers生成结果为什么包含输入提示词

如果用 Hugging Face Transformers 调用 model.generate()，再把 outputs.sequences 整段交给 tokenizer 解码，GPT、Llama 这类 decoder-only 模型出现“结果包含输入提示词”是正常的：返回值通常是“输入 token + 新生成 token”的完整序列，不是只包含答案的字符串。真正要取回答部分，应按输入 token 数量切片后再解码。

官方地址：https://huggingface.co/docs/transformers/

一、先判断模型输出是否天然包含输入

Transformers 的 generate 面向的是 token 序列。对 decoder-only 模型，模型要根据已有上下文继续预测，因此返回的序列会保留原来的 input_ids，后面再接上新 token。把这串 token 直接 decode，自然会看到提示词被再次打印。

这不是模型把提示词“重新生成”了一遍，也不表示上下文被重复注入。要区分两件事：sequences 是完整序列，应用层最终展示的文本可以只是它的后半段。Hugging Face 官方生成文档的示例也按模型类型计算输入长度，再使用 outputs.sequences[:, input_length:] 取生成部分。

二、用输入 token 长度切出新增内容

最稳妥的做法是保留 tokenizer 的输入，不按字符长度猜边界。中文、英文和特殊 token 的分词长度都可能不同，len(prompt) 与 input_ids.shape[1] 没有一一对应关系。

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "your-decoder-only-model"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)

prompt = "请用一句话解释 attention_mask 的作用。"
inputs = tokenizer(prompt, return_tensors="pt")

with torch.no_grad():
    # max_new_tokens 只限制新生成 token，不把提示词长度算进去。
    sequences = model.generate(**inputs, max_new_tokens=48)

# decoder-only 模型的前半段是输入，按 token 数切掉而不是按字符切。
input_length = inputs["input_ids"].shape[1]
new_tokens = sequences[:, input_length:]

# 跳过 eos 等特殊 token，得到真正供页面展示的新增文本。
generated_text = tokenizer.batch_decode(new_tokens, skip_special_tokens=True)[0]
print(generated_text.strip())

这里的关键是 input_length 来自实际送入模型的 token 张量。若使用 chat template，角色标记、换行和结束标记也已经进入这段输入，不能只根据肉眼看到的用户问题计算长度。

三、批量推理时按 attention_mask 处理 padding

单条输入时用 inputs["input_ids"].shape[1] 足够；批量输入就要进一步确认 padding。不同提示词会被补齐到同一列数，右 padding 与左 padding 的布局不同。如果直接对整个 batch 使用一个固定切片位置，短提示词的结果可能把 padding 或提示词残片带进解码文本。

工程上要先统一 tokenizer 的 padding 策略。attention_mask.sum(dim=1) 可以告诉你每条样本有多少有效提示词 token，用来诊断 padding；但对 decoder-only 的 batch，生成 token 通常是在统一的补齐宽度之后追加，所以实际切片起点通常是 inputs["input_ids"].shape[1]，而不是每行的有效长度。还要按模型和 tokenizer 的要求确认是否需要左 padding，不要把“能生成”当成“切片正确”。

# attention_mask 用来核对每条样本的有效 token 数。
valid_lengths = inputs["attention_mask"].sum(dim=1).tolist()
prompt_width = inputs["input_ids"].shape[1]
texts = []
for row, valid_length in zip(sequences, valid_lengths):
    # batch 的新 token 通常从统一的补齐宽度之后开始，不能直接用 valid_length 切。
    row_new_tokens = row[prompt_width:]
    texts.append(tokenizer.decode(row_new_tokens, skip_special_tokens=True).strip())

如果采用左 padding，生成序列的新增部分通常仍从补齐后的统一宽度开始；如果使用自定义生成循环或手工拼接，才需要根据实际输出布局重新计算每行边界。更稳的原则是：记录输入张量、明确 padding 方向，用 attention_mask 诊断有效输入，再按返回序列的真实布局解码。

四、控制长度与模板边界

max_new_tokens 与 max_length 的语义很容易混淆。前者只限制新生成的 token 数，后者通常把输入和输出放在同一个总长度预算里。排查“输出比预期短”时，先看是否误用了 max_length；排查“提示词被带回来”时，则先看是否忘记切片。

还要留意解码动作：如果先解码完整的 sequences，再把展示字符串与 prompt 拼接一次，就会造成真正的双重重复。使用 chat template 时，建议让 tokenizer 负责组织角色标记，并把同一份 input_ids 留给切片逻辑；不要重新手写一套肉眼字符串拼接。

五、按现象快速定位

因此，这个问题的边界很清楚：先确认模型形态，再确认返回序列的 token 布局，最后检查 padding、模板和长度参数。只有在切片后仍然出现重复，才需要继续排查自定义 stopping criteria、手工拼接 prompt 或多次调用之间是否复用了旧序列。

相关问题

为什么不能按字符串长度截掉输入提示词？

分词后的 token 数与中文字符数、英文字符数并不相等，特殊 token 也会改变边界，所以应使用 input_ids 的列数或每行有效长度。

encoder-decoder 模型也会返回完整 prompt 吗？

不能直接这样判断。它的输入经过 encoder，生成序列在 decoder 侧展开，切片规则应按模型类型处理，不能套用 GPT 类模型的固定假设。

skip_special_tokens 会不会删掉正常内容？

它主要过滤 tokenizer 标记的特殊 token；如果业务需要保留角色标记或边界标记，应先确认模板约定，再决定是否跳过。