GPT-2微调实战：构建高效双语对话模型的工程指南

简介：这是一份以GPT-2为基底、面向中英双语对话生成的预训练模型微调资源包，适合语言模型方向的学生、毕业设计者以及需要快速搭建双语助手的开发者使用。包内共66个文件，包含Python模型脚本、Shell训练与评测脚本、Markdown说明文档、YAML/JSON配置以及大量效果展示图，整体压缩包仅6.79MB，结构清晰便于按模块查阅。模型通过引入特定领域对话数据二次微调，具备跨语言理解与生成能力，可支撑智能客服、翻译辅助、语言练习等场景。下载后可获得完整工程目录与训练/推理代码，既能对照README复现微调过程，也可直接调用API或Web Demo进行效果测试；对于毕业设计者，还能从代码与示例中拆解数据预处理、模型微调、效果评估等关键环节。目前已有261人学习，不失为一个轻量、可上手的双语对话模型参考实现。

1. 双语对话模型：为什么还要用 GPT-2 微调一遍

这两年大模型聊天产品层出不穷，但“双语对话模型”仍然是一个很具体的工程需求：客服、海外运营、内部知识问答平台，都希望同一个会话里中英文混着说，模型自己能判断该用哪种语言回复，而不是把输入转成固定语言再处理。很多人第一反应是调用现成多语言模型 API，可一旦要私有化部署、要控制延迟、要记录每次生成的输入输出，一个开源的 GPT-2 权重反而更合适。反直觉的地方在于 GPT-2 是英文预训练语言模型，中文能力并不强，但它的核心是自回归 next-token 预测，只要在训练数据中显式引入中英切换信号，就能“学”出一个够用的双语对话生成模型。这里不打算介绍一个神秘项目源码，而是从工程上把分词、微调、数据配比、LoRA 参数和生成策略串起来，让想上手的人可以照着复现。

2. 预训练语言模型里的双语起点：GPT-2 分词器与语言控制

2.1 从 Byte-Level BPE 理解 GPT-2 为什么“天生”支持中文与英文

GPT-2 的分词器是 Byte-Level BPE。它先按 UTF-8 把文本变成字节，再在字节序列上做合并；因此中文字符不会因为 vocab 里没有而被拒之门外，不存在传统分词器 Out-of-Vocabulary 的问题。但代价也很直接：英文一个词平均 1.3 个 token，中文一个字可能被拆成 2 到 3 个 byte 级 token；中英混合时长度更长。实际微调时序列长度要留余量，我一般把训练长度定在 512，超过 384 的样本按对话轮次截断。

先跑一段最小代码看 token 分布：

from transformers import AutoTokenizer, AutoModelForCausalLM import torch tokenizer = AutoTokenizer.from_pretrained("gpt2-medium") tokenizer.pad_token = tokenizer.eos_token for text in ["Hello, world", "你好，世界", "你好 world"]: ids = tokenizer(text, add_special_tokens=False)["input_ids"] print(text, "->", len(ids), ids[:12])

输出会显示英文文本 ID 个数明显少于中文。这提醒你在构造双语对话样本时不要只开一个默认 300 的 max_length，否则中文较长的轮次会被截断得厉害。另外 Byte-Level BPE 生成的是 token id 连续的子词，中文生成时模型需要先在多个字节 token 间建立组合关系，这正是预训练语料缺失导致的“中文生成生硬”的原因。

如果中文语料比较多，也可以额外把高频词或者整词加入词表，再用 GPT-2 原有 embedding 做初始化。常见做法是取该新词各子词 embedding 的均值，虽然只能省 10% 到 20% token，但会明显降低中文回复断裂的概率。注意，扩词表之后必须先调用resize_token_embeddings，再冻结模型做后续微调，否则新增的 embedding 永远停在随机值附近。

2.2 加语言标记：把双语选择变成可学习的下一步行为

要让模型知道“这句该用中文回还是英文回”，更好的做法不是给它一条“请用中文回答”的祈使句，而是在对话文本中放置显式的语言位置标记。原因在于 GPT-2 是自回归模型，它下一轮能接什么，完全依赖前面出现的 token。把语言标记放在说话人标记前面，等于把“接下来输出哪些子词”约束到一个明确集合里。推荐格式是：

[ZH][USER] 杭州明天会下雨吗？[BOT] 明天下午有小雨，记得带伞。 [EN][USER] How about the day after tomorrow?[BOT] It will be cloudy, chance of rain 20%.

实现时把[ZH]、[EN]、[USER]、[BOT]作为普通控制符加入 vocab：

control_tokens = ["[ZH]", "[EN]", "[USER]", "[BOT]"] tokenizer.add_tokens(control_tokens, special_tokens=False) model.resize_token_embeddings(len(tokenizer))

这里没有把控制符注册成 special token，是为了让它们参与正常的 token 分割，同时让新增 embedding 在微调时得到更新。resize_token_embeddings会在末尾扩展 embedding 矩阵；如果后面要用 LoRA，务必先扩容再套 PeftModel，否则注入 adapter 时找不到与扩展权重对应的形状。新增的行是随机初始化，所以不微调直接推理时，模型看到[ZH]不会产生任何有效语义，只有靠训练把语言状态“压”进这些 embedding。

2.3 微调前跑一次生成：看看基线偏离在哪里

训练前跑一次生成不是为了看效果，而是为了建立一个“失败基线”：到底模型会把中文问题回成什么样？把同一段代码存成baseline_generate.py，每次换模型权重都跑一遍，能直接对比训练前后的变化。

model.eval() prompt = "[ZH][USER] 介绍一下杭州。[BOT]" inputs = tokenizer(prompt, return_tensors="pt") with torch.no_grad(): out = model.generate( **inputs, max_new_tokens=60, do_sample=True, temperature=0.8, top_p=0.9, pad_token_id=tokenizer.eos_token_id, ) print(tokenizer.decode(out[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True))

未微调时，结果通常是一些英文散装句子、重复字节，偶尔夹几个中文地名。这个 baseline 要记录下来，微调后跑同样 10 条 prompt，对比语言比例和是否“接得上”。如果训练后输出的语言标记位置不对，例如中文 prompt 下输出[EN]，说明训练数据里语言标签与回答配对不紧密，需要把角色标记与语言标记顺序固定下来，不要混用[ZH][USER]和[USER][ZH]。

3. 双语对话模型的数据构造：样本格式、标签掩码与中英比例

3.1 把多轮对话写成带语言标签的 JSONL

把对话写成 JSONL 是 HuggingFace Trainer 最顺手的方式。一个样本里除了 messages，还要给每条消息标lang，因为同一个用户可能在某轮切换到英文。比较重要的是数据采集范围：不能只用纯中文问答对，再硬拼机器翻译成英文来冒充双向样本，那样模型会学到“回答被翻译”的行为，生成内容会非常生硬。

示例样本格式：

{"id": 1, "messages": [ {"role": "user", "lang": "zh", "content": "杭州明天会下雨吗？"}, {"role": "assistant", "lang": "zh", "content": "会的，预计明天下午有小雨。"}, {"role": "user", "lang": "en", "content": "What about the day after tomorrow?"}, {"role": "assistant", "lang": "en", "content": "It will be cloudy, high around 28°C."} ]}

语言标记与角色标记的顺序一旦定好，就固定下来。我习惯在训练时拼成[ZH][USER]和[BOT]结尾，因为语言是会话的外层状态，先告诉模型“这轮用什么语言”，再告诉它“谁在说话”。真正训练集里最好有 20% 左右样本包含至少一次跨轮切换，否则模型只会单语问答，不会跟着用户换语言。

3.2 labels 掩码让模型只预测助手回复

HuggingFace 的 CausalLM 训练默认把所有input_ids都当作 labels，这样用户消息也会参与 loss。对话任务里用户输入是条件，让模型学习预测用户输入并不会崩溃，但会消耗参数量去学习“补全用户的话”，推理时还容易造成用户说一半模型就抢话。所以常规做法是将用户部分的 labels 置为-100，PyTorch 的交叉熵会忽略它。

def build_bi_dialog(feature, tokenizer, max_len=512): ids, labels = [], [] for msg in feature["messages"]: lang = "[ZH]" if msg["lang"] == "zh" else "[EN]" role = "[USER]" if msg["role"] == "user" else "[BOT]" part = f"{role}{lang} {msg['content']}" part_ids = tokenizer(part, add_special_tokens=False)["input_ids"] ids.extend(part_ids) if msg["role"] == "assistant": labels.extend(part_ids) else: labels.extend([-100] * len(part_ids)) ids.append(tokenizer.eos_token_id) labels.append(tokenizer.eos_token_id) if len(ids) > max_len: break ids = ids[:max_len] labels = labels[:max_len] return { "input_ids": ids, "attention_mask": [1] * len(ids), "labels": labels, }

函数里part拼成[USER][ZH]还是[ZH][USER]要看训练规范，但必须与推理 prompt 完全一致。ids和labels同时截断时，可能把最后的 eos 截掉，这种样本从训练集去掉比硬留着更干净。

数据字段含义如下表：

自定义 collator 是更稳的方案。DataCollatorForLanguageModeling会把 labels 复制自 input_ids，不符合我们要 mask 用户侧的需求。如果使用Trainer，需要传一个简单 collator，并且把remove_unused_columns=False关掉，否则自定义字段会被提前丢掉。

3.3 训练集的中英配比与陷阱

推荐的经验配比：单语中文样本 40%，单语英文样本 40%，跨轮换语言样本 20%。这个比例适合客服和问答型对话。若场景更多是“中文用户突然贴一段英文原文”，可以再把跨轮比例提到 30%，但不要超过 40%，否则模型会过度关注切换信号，导致同一语言长对话出现漂移。

数据清洗阶段我会做三件事：

1. 删除连续超过 3 个的标点或 emoji 堆叠，减少模型学习无意义循环。
2. 按 prompt 去重，避免同一句中文问题在 train 和 dev 里重复出现。
3. 过滤长度异常的对话：单轮中文少于 5 个字或英文少于 5 个词，通常信息量不足。

统计语言分布可以用 jq 直接做：

jq -r '.messages[] | .lang' train.jsonl | sort | uniq -c | sort -rn

输出类似12000 zh、11000 en。这个统计一定要写入数据流水线，每次重新切分后跑一遍。如果中文比例明显超过英文，模型会把英文轮次也拉回中文；反过来英文主导，则中文回复会出现大量英文残留。

4. GPT-2 微调实操：全参与 LoRA 的取舍及生成参数设置

4.1 全参和 LoRA 各适合哪类双语任务

GPT-2 从 base 到 large 的参数量跨度很大，选全参微调还是 LoRA 主要看服务多少个独立对话任务。若只有一个固定场景、数据集又整齐，全参微调在 12G 显存上跑gpt2-medium可行；但换语言策略、加新轮次或换领域时，全参要重训。LoRA 每个业务线只保存一个几十 MB 的 adapter，切换成本低，是目前“大模型微调”里性价比最高的方式。

如果数据量只有一万条甚至更少，推荐直接 LoRA。双语对话表面上是“两个语言的任务”，但对 GPT-2 来说只是“不同 token 分布的任务”，信号很弱，全参微调稍不注意就会跑到语料比例更大的一侧。LoRA 的秩（r）不能太小也不能太大，r=8 起步，资源充裕再试 r=16。r=64 在单语言任务上可能略有提升，但对双语这种高度依赖切换信号的任务，反而容易记住训练集里的噪声。

4.2 用 PEFT 给 GPT-2 打上 LoRA Adapter

PEFT 的 LoRA 可以比较方便地适配 GPT-2。注意target_modules要指定到 GPT2Attention 的注意力融合矩阵c_attn上，而不是普通 Transformer 里的q_proj、v_proj。

from peft import LoraConfig, get_peft_model, TaskType lora_config = LoraConfig( r=8, lora_alpha=16, lora_dropout=0.1, target_modules=["c_attn"], bias="none", task_type=TaskType.CAUSAL_LM, ) model = get_peft_model(model, lora_config) model.print_trainable_parameters()

lora_alpha=16在 r=8 时缩放因子为16/8=2，多数情况下这个量级稳定。target_modules=["c_attn"]已经覆盖 Query、Key、Value 三个矩阵，不需要再把c_proj加入；bias="none"会让训练参数量更小，也降低过拟合风险。若你仍然从AutoModelForCausalLM加载，且之前做过resize_token_embeddings，要保证 LoRA 是在扩词表之后创建的，否则 adapter 的维度对不上。

4.3 Trainer 训练参数与常见报错修正

训练脚本的骨架如下。这里给出的参数组合可以在一张 16G 显存的卡上跑gpt2-medium。

from transformers import Trainer, TrainingArguments training_args = TrainingArguments( output_dir="./bi-gpt2-lora", per_device_train_batch_size=4, per_device_eval_batch_size=4, gradient_accumulation_steps=8, learning_rate=2e-4, lr_scheduler_type="cosine", warmup_ratio=0.1, max_steps=5000, eval_strategy="steps", eval_steps=500, save_steps=500, logging_steps=50, fp16=True, report_to=["none"], remove_unused_columns=False, ) trainer = Trainer( model=model, args=training_args, train_dataset=train_dataset, eval_dataset=dev_dataset, data_collator=collator, ) trainer.train()

eval_strategy在 transformers 4.46 之后取代了原来的evaluation_strategy；旧版本需要写evaluation_strategy="steps"，否则启动即报 Unknown argument。每设备 batch 4、梯度累积 8，等效 batch 32。5000 步在约 1 万条训练样本上大约是 3 个 epoch，对对话微调是合理区间。fp16=True只在 NVIDIA 卡上生效，CPU 或 Mac 上必须关掉。report_to=["none"]避免没有 wandb 时训练中断。

常见报错是“label 长度与 input 不一致”，原因是 collator 里只对 input_ids 做了 padding，没有同时处理 labels。自定 collator 时，labels 的 pad 位必须填-100，不能填 0，否则模型会在 padding 位置算出额外 loss。

4.4 生成参数不能照抄对话大模型

对话阶段的生成参数与训练阶段同样重要。双语对话要求“稳定切换语言”，温度过高会出现中英字符穿插；repetition_penalty过高又会强行换词，导致语法断裂。我一般用temperature=0.8、top_p=0.9、repetition_penalty=1.05、max_new_tokens=160。

推理函数这样封装：

def generate_reply(prompt_history, tokenizer, model, max_new_tokens=160): inputs = tokenizer(prompt_history, return_tensors="pt").to(model.device) out = model.generate( **inputs, max_new_tokens=max_new_tokens, do_sample=True, temperature=0.8, top_p=0.9, repetition_penalty=1.05, pad_token_id=tokenizer.eos_token_id, ) reply_ids = out[0][inputs["input_ids"].shape[1]:] return tokenizer.decode(reply_ids, skip_special_tokens=True)

skip_special_tokens=True会去掉 eos，但如果[ZH]、[EN]是按普通 token 添加的，decode 后依然会显示出来。后端返回给用户前，需要把这些控制符和角色标记做字符串清理，不要指望 tokenizer 自动隐藏。

5. 双语对话质量的生成验证：语言一致性检查与回归 gate

模型训练完，常规验证是算 PPL（困惑度），但 PPL 只能表示生成概率高低，不能说明“中文提问是否得到中文回复”。更实用的做法是准备 20 条固定 prompt，跑 3 个不同的随机种子，统计三条线上指标：语言一致性、轮次衔接率、是否出现循环。

def detect_lang(text): zh = sum('\u4e00' <= c <= '\u9fff' for c in text) en = sum(c.isascii() and c.isalpha() for c in text) if zh == en == 0: return "empty" return "zh" if zh > en else "en"

这个函数对混合语言文本只返回占优语言；如果需要卡“中英夹杂”，可以再算一个混杂度min(zh, en) / max(1, zh + en)，超过 0.2 就认为本轮生成不合格。

把语言一致性测试接入 CI：

lang_correct = 0 for item in test_set: prompt = item["prompt"] reply = generate_reply(prompt, tokenizer, model) if detect_lang(reply) == item["expected_lang"]: lang_correct += 1 print(f"language consistency: {lang_correct / len(test_set):.2%}")

当语言一致性低于 90% 时，优先检查第 3.3 节里的中英配比和数据清洗，而不是盲目调学习率。另一个值得做的是“首 token 检查”：中文 prompt 下，模型 decode 后第一个有效字符是否属于中文字符区间。如果出现[EN]开头的英文回复，说明语言控制符没有真正形成约束，需要在样本中增加“同轮切换”的比例，或者把语言标记从普通 token 改成强制不参与文本生成的 special token。

训练和评估走通后，把这个 20 条 prompt 的回归集固定下来。每次改数据、加 adapter 都要跑同一批 prompt，防止“这轮微调把上一轮切换能力冲掉”。确认首 token 分布和语言一致性都达标，再考虑放宽温度换取多样性。

本文还有配套的精品资源，点击获取