GPT-2微调实战：让模型学会古文名句续写

这个项目是我给自己定的“古文机器生成”系列实验里的第十六篇。前面十几篇我一直在折腾语料清洗、基础文本分类和关键词抽取，到这篇终于轮到最想做的方向：让模型学经典名句的续写。所谓续写，很简单——给模型前半句，让它接后半句。喂一句“床前明月光”，模型最好能接上“疑是地上霜”；喂“学而不思则罔”，它得知道后面是“思而不学则殆”。但真正的难点从来不是背下这些名句，而是模型能不能举一反三：碰到它没见过的上半句，也能给出语义通顺、风格协调的下半句。

这篇内容适合三类人：一是NLP方向的开发者和学生，想看GPT-2类模型如何落地到中文古文场景；二是想做文本生成产品（对联、古诗、文案）但还没选型的工程师；三就是单纯好奇AI怎么“吟诗作对”的爱好者。我会把数据清洗、tokenizer选型、微调参数、推理解码和后处理一条线讲完，每一步都附带我实际踩过的坑和最终采用的配置。你不一定要复现同样的模型，但看完应该能少走不少弯路。

1. 先看项目本质：名句续写到底在解决什么问题

1.1 续写本质上就是自回归生成

续写任务说白了就是语言模型最原始的形态：给定前面若干token，预测下一个token的概率分布，然后把这个新token拼到输入里继续预测下一个。整个过程就像一个人在纸上写句子，写完一个字再想下一个字。拿“床前明月光”为例，模型第一次要预测的其实是“床”字后面的“前”，只不过在推理时我们一次性把前半句喂进去，让它从“光”字之后开始接。真正生成时是这样一个循环：

1. 输入“床前明月光”，模型计算每个候选字概率，选“疑”；
2. 把“疑”拼到末尾，输入变成“床前明月光疑”，预测下一个是“是”；
3. 再拼上“是”，继续预测“地”，直到生成完整的“疑似地上霜”或类似内容。

这种自回归方式最大的好处是训练目标极其简单：不需要额外构造标签，也不需要给模型加分类头。只要语料本身是自然文本，把每个句子切成“前k个字预测第k+1个字”的样本就够了。换句话说，续写能力是语言建模这件事“白送”的副产品。这在工程上省了很多事——你不用像做分类任务那样设计复杂的输出层，模型结构原生就是干这个的。

1.2 为什么选GPT-2架构而不是LSTM或BERT

我在做选型时主要对比过三条技术路线：LSTM/RNN、BERT、GPT-2这种decoder-only结构。LSTM作为经典循环网络，可以逐字生成文本，但它的问题也很明显：长距离依赖能力弱，古文里前后呼应的成分经常隔了十几个字，LSTM容易把前半句的语义“忘掉”；再加上训练速度慢、难以并行，我直接就把它排除了。

BERT那类encoder模型本身不适合续写，它是双向编码器，擅长理解任务（分类、抽取、匹配），但生成时还需要额外接一个decoder，整体结构绕了一圈。而GPT-2是纯粹的decoder-only模型，用因果注意力让每个位置只能看到前面token，天然匹配自回归生成流程。更关键的是，它的Transformer主干在捕捉长距离依赖上比LSTM强很多。古文短句多、省略主语多、语义高度依赖上下文，这种特性正好是自注意力的优势区。

我用一张表总结当时的选择逻辑：

需要坦白的是，现在社区里文本生成方案已经丰富了很多，有各种新的decoder架构，但GPT-2这个方案直到今天依然有两个不可替代的优点：一是生态成熟，预训练权重和工具链齐全，小团队甚至个人都能在单卡上跑起来；二是架构简单，排查问题时心智负担低。做一个古文续写项目，目的不是追最新SOTA，而是在有限资源下把效果做到可用，那么GPT-2就是一个非常现实的起点。

2. 数据准备：把古文喂给模型前先做好三件事

2.1 语料清洗：决定模型上限的环节

我见过太多人一上来就找一堆古文语料，扔给模型训练，结果loss怎么都降不下去，生成的文本里全是乱码和“”。

这个项目里我用的语料全部来自公共版权古籍电子文本，覆盖先秦诸子、史书选段、唐诗、宋词、明清小品等公开内容。总量大概几十万条短句。数据量不算大，但足够撑起一次微调实验。清洗时我给自己定了一条原则：宁可少而精，也不要多而乱。文本里的脏数据对语言模型的污染是全局性的，一条乱码可能让模型在若干step里都朝着错误方向更新。

清洗管线我按顺序做了六步，每一步都有明确目的：

1. 统一编码为UTF-8，消除乱码基础；
2. 删除网页标签、数字、英文、无意义符号；
3. 统一全角标点，把逗号、句号、感叹号、问号都转成标准中文标点；
4. 繁简体统一，我最终全部转成简体，避免同一概念被拆成两个字符空间；
5. 去重，删除重复行和样板文本（比如古籍里反复出现的“卷”、“曰”等目录信息）；
6. 去掉序、跋、注释等非正文内容，这些内容和名句续写场景无关。

清洗代码其实很短，正则占了大头。核心思路是先替换掉明显非法字符，再做标点归一化：

import re def clean_text(text): # 去掉HTML标签和不必要的空白 text = re.sub(r"<[^>]+>", "", text) # 保留中文字符和常见标点，其余直接删 text = re.sub(r"[^\u4e00-\u9fa5，。！？；：、“”《》\n]", "", text) # 全角逗号句号统一 text = text.replace("，", "，").replace("。", "。") # 折叠连续空格和控制符 text = re.sub(r"\s+", "\n", text.strip()) return text

这套清洗做过之后，语料干净程度直接决定了我后续调参时的心情。实际经验是：清洗质量比模型结构重要一个量级。某次我偷懒少跑了一步去重，模型训出来之后，连续几句都出现“子曰子曰”的复读机症状，后来才发现语料里同一段话重复了几百次。

2.2 切句与样本构造：单句还是跨句？

语料清洗完之后，下一步要做切分。古文和现代文不一样，现代文有自然段、有长句，古文则以“句读”为基本语义单位。先秦文献里一句话往往就是完整命题，唐诗宋词更是以联为单位，两句一组形成对仗和意境。所以不能简单按整段送进去训练，那样模型很难学到“前半句+后半句”的配对关系。

我的做法是把语料切成句子，再按“联”组织。具体来说：

• 以句号、问号、感叹号、分号作为边界切分。
• 对于五言、七言诗，尽量保留完整的“上句+下句”联，例如“床前明月光，疑是地上霜”整体作为一条训练单元。
• 对于散文，则按单句切分，但每条训练样本由1到4个连续句子拼接，中间用逗号或句号分隔。

为什么要混合粒度？如果只训练单句，模型容易养成“说一句就停”的毛病，续写时很短就会触发结束符。如果总是训练长段落，小数据量下显存和收敛压力都会变大。我实际采用的做法是：用滑窗把连续句子拼成长度约96到128个token的序列，窗口滑动步长设为序列长度的一半，这样既不浪费样本，也让模型见过句与句之间的衔接模式。

构造样本时还需要处理特殊标记。每条训练样本头部加上[BOS]，尾部加上[EOS]，中间句子天然用中文标点分隔。模型由此学会“什么时候开始生成，什么时候收尾”。这一步看似不起眼，但对续写体验影响极大——如果你不设置EOS，模型会把一句名句续到天涯海角。

2.3 分词器选型：中文古文怎么切不丢信息

分词一直是中文NLP的经典话题。现代中文至少还有“词”的概念，古文几乎是单音节词为主，但又不完全是字字独立，很多双字组合（“之乎者也”结构、连绵词、人名地名）是有固定搭配的。分词器选得好不好，直接影响模型对生僻字的敏感度。

我对比过三种方案：

• 字节级BPE：直接基于字节做子词切分，对多语言友好，但对中文生僻字容易切出奇怪碎片；
• 纯字级词表：每个汉字一个token，简单稳定，但完全丢掉了词组信息；
• 字为主、保留少量常见双字词：兼顾两者，中文社区很多预训练模型就是这么做的。

最终我选择加载一个基于字级词表的开源中文tokenizer，词表大小约两万，覆盖绝大多数常用汉字和一批高频词。这么做有个特别实在的理由：古文里的生僻字极多，纯BPE在生僻字上容易触发UNK，一旦触发UNK，该位置信息直接丢失，模型永远学不会这个字。而字级词表只要收字足够全，就不会有这种问题。

特殊token方面，我固定为[BOS]、[EOS]、[UNK]、[PAD]四类。训练时句子开头补[BOS]，末尾补[EOS]，长度不足补[PAD]，推理时只输入前半句，让模型自己生成直到EOS或达到max_new_tokens。

3. 模型与训练配置：超参数逐个拆开讲

3.1 从中文预训练权重继续训练

模型选型上我直接从中文GPT-2预训练权重开始，而不是从随机初始化训练一个全新模型。理由很直接：古文数据量有限，从零训练根本学不到基础语法和组词能力，而中文预训练权重已经在海量现代中文上学会了“中文长什么样”，我们只需要在它基础上做领域适配，把分布拉到“古文的模样”。

加载方式很简单，复用开源Transformer生态的模型加载工具：

from transformers import GPT2LMHeadModel, GPT2Tokenizer model = GPT2LMHeadModel.from_pretrained("./weights/chinese-gpt2-base") tokenizer = GPT2Tokenizer.from_pretrained("./weights/chinese-gpt2-base")

这里有一个容易忽略的点：中文预训练权重的词表是固定的，如果你自己换了一套分词器，embedding层的维度就对不上，要么重新训练embedding，要么加载时做映射。我为了省事，直接沿用预训练权重配套的tokenizer，这样模型结构、词表、权重三者天然对齐。

模型规模选的是base档，参数量大概在1亿到3亿之间。这个规模在单卡上可以微调，推理时CPU都能跑。更大规模的模型我没有考虑，因为显存和时间成本会翻好几倍，而且对短句续写这个任务来说，收益并不明显。

这一步做完之后，模型还只是个会说现代中文的底座。接下来要做的是拿古文语料“继续训练”，让它的语言分布向古文体偏移。这种训练方式术语叫domain adaptation，本质上是在原有概率分布上加一个偏置，让古文相关的表达路径被强化，而不是推翻重学。

3.2 一组可以直接抄作业的超参数

超参数是微调里最让人头疼的部分。我给出自己最终采用的一组配置，并且解释每个参数的确定依据，你在复现时可以根据自己的显存和数据量微调。

为什么学习率一定要压到1e-5这个量级？因为预训练模型已经收敛到了一个比较好的局部最优区域，你拿着几万条古文语料去继续训练，本质上是在原基础上微调方向。学习率一高，参数直接跳出原有区域，模型的现代中文能力会被冲掉，古文效果也不会变好，最典型的症状是生成文本开始出现大量胡言乱语。

等效batch size = 16 × 4 = 64，这个数值的意义在于：每个step模型能看到64条古文样本，大约覆盖两三千个token，梯度估计足够稳定。如果batch太小，loss曲线会剧烈震荡；如果太大，又容易过拟合到高频句式。

训练轮次方面，我建议不要死守8轮。我习惯每500步保存一个checkpoint，同时每轮结束在验证集上算perplexity，验证集loss开始上升就停。早停是必须的，因为古文语料相对小，过拟合来得非常快。

3.3 训练脚本主体长什么样

训练代码我直接用了社区开源工具库的Trainer封装，省去手写训练循环的麻烦。核心配置大概是这样：

from transformers import Trainer, TrainingArguments training_args = TrainingArguments( output_dir="./checkpoints", overwrite_output_dir=True, num_train_epochs=8, per_device_train_batch_size=16, gradient_accumulation_steps=4, learning_rate=1.5e-5, warmup_steps=1000, weight_decay=0.01, fp16=True, logging_steps=100, save_steps=500, eval_steps=500, evaluation_strategy="steps", load_best_model_at_end=True, ) trainer = Trainer( model=model, args=training_args, train_dataset=train_dataset, eval_dataset=eval_dataset, tokenizer=tokenizer, ) trainer.train()

这里的fp16=True非常关键。开混合精度之后显存占用几乎减半，训练速度提升一倍以上。如果你的显卡不支持fp16，可以去掉这一项，但batch size需要相应调小。

数据集的封装注意一点：我做的不是Seq2Seq任务，所以不需要构造输入和标签两组数据。语言模型训练时，输入序列和标签序列是同一个序列，只是标签左移一位。Trainer会自动处理这一点，只要数据集返回input_ids和attention_mask即可。我自己做数据集时稍微踩过坑，以为要像翻译任务那样构造prefix和label，其实完全没必要。

4. 训练与人工验收：不要只盯着loss

4.1 训练日志与loss曲线的读法

训练过程里我记录了一条比较典型的学习曲线。初始几步loss在5.6左右，第一个epoch结束时降到3.2，第三个epoch到1.5左右，第六个epoch降到1.0附近。如果换算成perplexity，就是exp(loss)，从250左右降到3以内。从数值上看，模型确实在快速学习古文分布在说什么。

但这里我想明确一点：loss降到很低，不代表续写效果就好。loss衡量的是模型对训练语料的拟合程度，它反映的是“模型对下一个字的预测有多准”，不是“续写内容有多优美”。古文语料里大量句子都是固定搭配，比如“学而不思则罔”后面必然接“思而不学则殆”，模型学到的可能是强记忆而非真正的泛化能力。

所以我在训练过程中做了两件事：

1. 留出独立的验证集，每500步算验证集loss，验证集loss回升就早停；
2. 每训练一个epoch，我都手动拿固定提示词去生成，对比输出质量。

验证集尤其重要。我在项目早期吃过一次亏，训练集loss持续下降到1.0，验证集loss却从第三个epoch开始上涨，生成结果也逐渐变成“子曰子曰”的复读机。后来才意识到这就是过拟合：模型已经记住了训练集里的高频句子，却没学会任何泛化规律。

训练到后期，我会在训练脚本里同时生成一组样例并打印出来。这比任何指标都直观。模型训练到第3轮和第8轮，输出风格差异几乎肉眼可见：第3轮还在“文白夹杂”，第8轮已经能输出完整文言句子了。

4.2 固定名句测试集：每次评估都看同一组提示

为了让评估公平可控，我准备了一条固定的“名句续写测试集”，大约20条经典名句上半句。每次参数调整或训练到新checkpoint，都用完全相同的提示去生成。为什么用固定集合？因为文本生成有随机性，如果不固定评估样本，你很难判断效果的提升到底来自参数改进，还是只是这次运气好。

我的测试集里包括“床前明月光”“白日依山尽”“春眠不觉晓”“学而不思则罔”“山重水复疑无路”“路漫漫其修远兮”这类名句。固定提示、固定解码参数、固定随机种子，每次只改动一个变量（比如temperature），这样对比才有意义。

最终模型的表现可以分成三类来评价。一类是高频率名句，基本能复现原句，哪怕不完全一致，也八九不离十；一类是常见句式，模型能给出通顺但未必是原句的续写，比如“白日依山尽”有可能输出“黄河入海流”，也有可能输出“海风吹不断”；还有一类是冷门句子，模型输出会出现逻辑断裂，比如“路漫漫其修远兮”接了“吾将上下而求索”之后又画蛇添足加了一句“求索问心无愧”。

我建议评估时把三种类别的例子都记录成表格，而不是只看几个漂亮输出。漂亮的输出很能满足虚荣心，但真正暴露模型短板的是那些看起来“沾边却不对”的失败案例。

从表格能看出，模型对高频对句学得很好，对长句的收束能力偏弱。问题不在于词表，也不在于解码参数，而在于训练样本里长句占比不足。这也是为什么我在数据准备阶段强调混合粒度，如果你只喂短句，模型永远学不会“适可而止”。

5. 推理续写：从“能跑通”到“能看”的参数组合

5.1 解码策略：贪心、Beam和采样的区别

训练完成之后，真正决定用户感受的是推理时的解码策略。同样是“床前明月光”，不同解码策略能产生完全不同的结果。

最简单的贪心解码，每一步都选概率最高的token。这样做的好处是稳定、可复现，缺点是容易进入死胡同：一旦某一步选错，后面所有内容都顺着这个错误展开。而且贪心很容易生成重复循环——“月光光，光光，光光”这种诡异输出在古文场景里经常出现。

Beam Search是机器翻译时代的默认选择，它维护多条候选路径，每步保留概率最高的若干条。我试过beam size为4或8，发现它对“续写”这个任务并不友好。因为续写需要一定创造性，而beam会把所有候选逐步收敛到同一条高频路径上，最后输出的几条文本差异极小，丧失了多样性。

最靠谱的是采样方案。具体来说，就是根据概率分布随机抽下一个token，同时用几个手段控制随机程度。我最终的推荐组合是：

temperature低于1会让人工智能更保守，高于1会更冒险。0.85是我试出来比较折中的值：既不会像贪心那样死板，也不会像1.2那样放飞自我。top_k和top_p是两种不同的筛选逻辑，top_k固定保留候选数量，top_p保留累计概率到0.92的核心词集，两者结合效果更稳。

5.2 推荐参数组合与后处理流程

推理代码和训练代码一样，可以直接用开源工具库的generate方法实现：

prompt = "床前明月光" inputs = tokenizer(prompt, return_tensors="pt") outputs = model.generate( inputs.input_ids, max_new_tokens=32, do_sample=True, temperature=0.85, top_k=40, top_p=0.92, repetition_penalty=1.15, num_return_sequences=4, eos_token_id=tokenizer.eos_token_id, pad_token_id=tokenizer.pad_token_id, ) for i, output in enumerate(outputs): text = tokenizer.decode(output, skip_special_tokens=True) print(f"候选{i+1}: {text}")

推理部分有几个小细节值得留意。第一个是eos_token_id必须显式指定，否则模型可能不知道用什么符号表示结束，结果一直生成到max_new_tokens上限。第二个是pad_token_id也要设置，因为generate会对batch内多条序列做padding，不设置的话可能触发报错或warning。

后处理环节我做了三件事：

1. 标点规范化。如果生成结果末尾没有句号，就自动补一个。如果在逗号处戛然而止，则去掉末尾逗号或改成句号。
2. 三连字重复检测。检测输出里是否存在连续3个完全相同的字符或短语，比如“之之之之”。一旦发现，在重复位置截断。
3. 现代词过滤。语料里偶尔混入“问题”“电话”这类现代词，我会在输出层做一个黑名单词表，命中后重新采样或直接截断。

最后一条很关键。你训练的时候即便清洗过数据，预训练权重本身仍然“认识”大量现代词汇，生成时有概率冒出来。黑名单过滤是一种工程兜底手段，虽然粗暴，但在面向用户的场景里非常有效。

6. 踩坑实录：训练与生成阶段的问题速查

6.1 训练阶段的坑

这个项目里我踩的坑不算少，挑几个最有代表性的记录在这里，给后来人做个参考。

第一个坑是语料里繁简体混用。我的数据来源既有繁体扫描文本，也有简体整理本。刚开始没有统一，模型训练到中期开始输出风格漂移：同一个句子里前半句繁体，后半句简体。后来我用工具把所有语料批量转成简体，并顺手建了一个“简繁对照黑名单”做二次校验，问题才彻底消失。

第二个坑是重复样本太多。某段史书语料在原始数据里出现了上百次，模型直接把它背下来了。训练到后期，无论给什么提示，模型都想往那段文本上靠。解决方式是做精确去重和模糊去重，精确去重直接删相同行，模糊去重用字符串相似度阈值（比如0.85以上视为重复）。

第三坑是显存溢出。一开始我把max_length设成了256，batch size设成32，结果单卡直接OOM。后来调成max_length=128、batch_size=16、开启fp16，显存占用降到原来的三分之一，训练速度反而更快。这个测试给我一个教训：长序列并不等于高质量，古文短句居多，塞太多padding反而是浪费。

我还遇到过一个比较隐蔽的问题：验证集切分时不小心把同一本书的连续段落同时放进了训练集和验证集。因为段落之间有强相关性，验证集loss看起来很低，实际是“作弊”。正确的切分方式是按书或按主题随机切分，避免同一文本的上下文串集。后来我按“来源文档ID”切分，验证集才恢复参考价值。

6.2 生成阶段的坑

生成阶段的坑更多集中在解码参数和特殊token上。我遇到过的最离奇问题是模型生成内容总是非常短，刚写完两三个字就停了。排查半天才反应过来：训练语料里有些句子特别短，某些高频单字后面紧跟着EOS，模型学到“这个字之后就该结束”的错误模式。解决办法是在数据里过滤掉过短的句子，同时提高EOS在验证集里的判断门槛。

另一个常见问题是重复生成。即使设了repetition_penalty，模型偶尔还是会陷入“云山雾罩，雾罩云山”这类回环。这个问题的根源通常在训练数据里的重复句式，光靠推理参数很难根治。我的做法是双保险：训练时清洗重复语料，推理时把重复检测阈值调到“3个连续字符重复即截断”。

还有一个比较反直觉的经验：temperature开太高并不会让输出更有创意，只会让输出更破碎。在我这个模型上，temperature从0.85调到1.2之后，生成的句子出现了大量违反基本语法的碎片。古文本来就讲究精炼，需要的是“稳中微调”，而不是“群魔乱舞”。所以我在最终产品参数里把temperature锁死在0.8到0.9这个区间。

7. 后续还能怎么玩：从名句续写到完整创作

7.1 从续写走向完整创作的两个方向

模型跑通之后，续写只是第一步。基于同样的训练产物，可以往两个方向延伸。

第一个方向是古诗全自动创作。给定一个主题词或第一句，让模型连续生成多句，再通过外部规则检查平仄和对仗。我自己实验过，让模型续写“春山多胜事”之后，能生成“花影入清潭”这类还算通顺的句子。当然，平仄错误也不少，所以需要叠加一个格律检测模块，把不合格的候选自动淘汰。续写模型负责“生成候选”，格律模块负责“筛选结果”，两者配合比让模型一个人干两种活要可靠得多。

第二个方向是做成一个小型的古文风格对话或“诗词接龙”应用。用户可以输入上半句，模型给出下半句，再基于下半句继续接力。这个玩法很受非技术朋友欢迎，因为它互动性强，效果直观。部署上没什么特别要求，模型加载后直接用fastapi或类似框架包一层HTTP接口即可。如果生成结果要公开发布，建议加一道敏感词过滤和人工抽检，避免模型产生失控内容。

这两个方向的共同点是用工程手段为模型结果“兜底”。纯生成模型很难保证每次输出都完美，但配合规则过滤、多候选生成和人工挑选，整体体验可以提升到可用的水平。

7.2 我的几点真实心得

这个项目跑完之后，我最大的体会是：数据决定上限，模型只是逼近上限的工具。最初我偷懒，拿一份混合语料直接开训，调参调了好几天，生成的句子始终有一股“文白夹杂”的怪味。后来狠下心花了两天时间把语料重新清洗、去重、切分，同一套超参数，效果立刻上了一个台阶。文本生成领域里一个不可回避的事实是，模型的架构大家都在用，差距往往在数据处理的心力上。

其次是评估方式的问题。loss曲线再漂亮，没有一套固定的人工评估集，你依然不知道模型到底“行不行”。我建议每个文本生成项目都建立自己的“黄金测试集”，十几二十条提示词就够，每次调整都跑一遍，结果记录成表。与其相信各种自动指标，不如相信一张手工标注的对比表。

最后一点是关于预期的管理。经典名句续写这件事，模型做得好的时候很像那么回事，做得差的时候也会明显暴露“不懂内容只懂文本”的局限。它擅长捕捉字词搭配和高频句式，但它并不理解“典故”的深层含义。所以这类项目更适合定位为创作辅助工具，而不是真正的“文学家”。去掉这个不切实际的预期之后，你会发现它能帮你做的事情其实非常多——无论是寻找灵感、生成候选句，还是做古诗风格的数据增强，都是实打实的价值。

如果让我给后来者一句最实在的建议：先把数据做好，把固定评估集建好，再谈模型调参。这条路径走下去，这个项目就不会只是demo层面的玩具。