企业官网建设流程全解析

这几年做算法相关的工作，被身边人问得最多的一个方向就是预训练模型学习。无论是做文本分类、命名实体识别、问答系统，还是图像检索、多模态聊天机器人，你大概率都会碰到这样一幕：拿着一个别人已经训练好的大模型，下载下来，在自己的小任务上再训一训，效果居然还不错。这个流程现在听起来很常规，但很多新人第一次接触时，脑子里其实是懵的：预训练模型到底“预训练”了什么，微调又是微调了哪部分，为什么我换了任务就跑不动了。这篇内容我会结合自己实际项目的经验，从原理到实操，把预训练模型学习的完整路径拆开讲讲，包括你必须掌握的核心概念、一次完整的微调是怎么跑通的，以及我在真实项目里踩过的那些坑。如果你正准备入门大模型应用，或者已经被各种术语绕晕，可以照着这篇文章的思路走一遍。

1. 预训练模型到底在解决什么问题

1.1 从零训练为什么又贵又难

先聊一个根本问题：从零开始训练一个深度学习模型，到底难在哪。

很多人在课程作业里都训练过图像分类模型，那个规模小，几个小时的训练就能跑完。但到了真实场景，如果你的任务是“判断一段客服对话是否包含投诉意图”，你手上充其量只有几千条标注数据。这个时候如果从随机初始化的网络开始训练，会发生两件事：一是模型学不到足够的语言规律，因为数据量太少；二是很容易过拟合，训练集上准确率能到95%，测试集上一塌糊涂。

道理其实很简单，就像让一个刚出生的孩子，只看十道例题就去参加高考，他连基本语法都没建立起来，自然考不出成绩。人类的语言能力是在长达十几年的阅读、听说、写作者中逐步积累起来的，这十几年的积累就相当于“预训练”。我们不可能让一个模型从零开始，只靠你手里那几千条样本就完成语言理解。

更现实的问题是算力成本。一个像样的深度学习模型，从零训练往往需要几十块高性能显卡连续跑数周甚至更久，电费、硬件折旧、人工调参成本全部算下来，是绝大多数团队和个人都承担不起的。而预训练模型把前期的巨额成本集中承担在少数几个大型研究机构身上，训练完成后把参数公开发布，普通开发者下载下来直接用，相当于你去图书馆借了一本已经写好的百科全书，而不是自己重新发明一套语言体系。

所以，“从零训练”这件事，在今天已经不再是默认选项。除非你的任务极其特殊，已有的预训练模型完全覆盖不了，否则几乎没有理由自己去从零搭一个语言模型。把有限的计算资源和标注预算投到“微调”上，才是性价比最高的路线。

1.2 预训练加微调这套组合拳的核心逻辑

预训练模型学习的完整流程，可以分成两个阶段：第一个阶段叫预训练，第二个阶段叫微调，也有人习惯叫下游任务适配。

预训练阶段做的事情，是把海量的、不需要人工标注的文本喂给模型，让它通过自监督学习去“理解”语言。常见的自监督任务包括掩码语言建模和下一句预测，比如把一句话里的某个词挖掉，让模型根据上下文猜出这个词是什么。模型在几十亿个句子上反复做这种“完形填空”，慢慢就学会了词与词之间的搭配、语法结构，甚至一部分事实知识。这些知识被压缩成模型参数，也就是那个几十GB的权重文件。

到了微调阶段，你做的事情是基于这个已经懂语言的模型，在自己的标注数据上继续训练。因为模型已经具备很强的语言表征能力，你的分类头只需要学习“什么样的表述属于投诉”这种相对简单的映射，而不是从头学习“猫比狗多两笔划”这种基础语法。这就是为什么哪怕你只有几千条数据，微调后的效果依然能打。

我经常用“实习生入职”来类比这套机制：预训练相当于这个实习生在学校里学了四年专业课，基础知识扎实；微调相当于入职后看公司内部文档和案例，快速把通用能力转化为岗位需要的具体技能。没有大学教育，光靠入职培训很难速成；没有入职培训，光有学历也搞不清具体业务。两者缺一不可。

这里要特别提醒一个容易误解的地方：很多人以为微调就是“把模型的全部参数再训练一遍”，其实不全对。微调时我们可以选择全量参数更新，也可以选择只更新最后几层甚至只更新新加的分类头。这就引出了很多高效微调方法，比如冻结前面层、使用适配器结构、低秩分解微调等。理解了“预训练负责通识、微调负责专精”这个逻辑，后面很多技术方案选择都会变得清晰。

2. 开始动手前，这四件事必须想明白

2.1 架构选择：三种主流路线怎么区分

打开某开源模型库平台的界面，海量模型扑面而来，新人很容易看花眼。但本质上，当前预训练语言模型就分三大流派，搞清楚自己任务属于哪一类，选型就不会跑偏。

第一类是掩码语言模型，也叫自编码模型。它的特点是把输入文本整体编码，适合做理解类任务，比如文本分类、命名实体识别、语义相似度、抽取式问答。这类模型在预训练时主要做“填词”，所以输出的向量能很好地表示整个句子的含义。

第二类是自回归模型。它的特点是逐字生成，训练时预测下一个词是什么。这类模型天然适合生成式任务，比如文章续写、对话生成、代码生成。它虽然也能做分类，但需要额外设计提示模板，用起来不如第一类直接。

第三类是编码器-解码器模型。它把输入编码后，再解码生成输出，适合输入和输出都是文本的任务，比如机器翻译、文本摘要、表格转文字。

我的建议是：先判断你的核心任务是“理解”还是“生成”，再决定架构。不要盲目选一个参数最大的模型，觉得什么都能干。参数越大，微调成本和推理延迟越高，如果你的任务只是一个简单的二分类，杀鸡用牛刀只会浪费资源。

为了更直观，我把三类架构的选择逻辑整理成了表格：

2.2 规模与算力：你的硬件决定了你能玩多大

选模型的时候，很多人只看效果榜单，却忽略了自己手头的显卡。预训练模型的参数量从几亿到几千亿不等，而训练时的显存占用不是线性增长的，它是参数量、优化器状态、梯度、激活值共同作用的结果。

我给一个粗略但实用的经验公式：训练一个稠密模型时，显存占用大概是模型参数量的十六到二十倍。也就是说，一个参数量十亿的模型，训练时可能需要二十GB左右的显存。这还是在不使用任何优化技巧的情况下。如果你手头只有一块普通消费级显卡，显存可能在二十四GB以下，那就要考虑全量微调是否可行了。

算力不够时，方案大致有几个方向：一是选更小参数的模型，通常把规模从十亿降到三亿左右，显存压力小很多；二是用低秩微调技术，只训练一小部分参数，显存占用能下降一个数量级；三是用混合精度训练，能把显存砍掉近一半；四是用梯度累积，牺牲训练速度换取显存空间。

这里给一个配置建议表格：

在动手前，先用框架的模型加载工具测一下内存占用，再决定方案，才是成熟工程师的做法。我在早期项目中就吃过亏，兴冲冲下载了十亿级模型，结果代码一跑直接提示显存不足，来回折腾半天才意识到该换个思路。

2.3 数据标注成本：微调阶段的核心瓶颈

预训练模型体积大、能力强，但它并不能凭空改变你的数据质量。下游任务的微调效果，很大程度上由标注数据的质量决定。

很多团队在微调时会犯一个毛病：先找代码跑起来，模型一版一版地训，但数据还是一堆乱糟糟的原始文本。我见过一个项目，为了节省成本，直接用大模型生成标注数据，然后拿这些数据去微调小模型，结果预测结果系统性偏向大模型自己的偏好，真实业务场景里完全不可用。标注数据一定要经过人来校验，哪怕只抽检一小部分，也比纯机器标要靠谱得多。

任务类型不同，所需数据量也不同。如果是简单的二分类任务，每个类别有五百条以上的标注数据，基本能微调出可用的模型；如果是命名实体识别或者摘要生成，数据量需求会成倍增长。数据极少的时候，可以考虑先不做微调，而是用提示模板把预训练模型直接当作推理引擎来用，看看效果如何，再决定要不要投入标注资源。

标注规范也很关键。以文本分类为例，两个人对同一句话的标注结果一致性需要达到百分之九十以上，否则数据本身就是噪声，再厉害的模型也学不出稳定的规律。建议每次标注开始前先做一轮预标注和对齐，把边界情况定义清楚，比如“这个问题算投诉还是算咨询”，要在规范里给出明确示例。

2.4 评估指标先定好：别等训完再想怎么算成绩

这恐怕是最容易被新人忽略的一步。很多教程默认你已经清楚了评估方式，但实际操作时，分类任务用准确率还是F1，生成任务用BLEU还是ROUGE，差别很大。

假如你的分类任务中投诉类只占百分之五，那模型全部预测为“非投诉”，准确率也能到百分之九十五，但这个模型毫无用处。这时候就要用精确率、召回率和F1来评估，重点关注少数类的表现。生成式任务也一样，ROUGE指标只衡量字面重合程度，并不代表语义正确，最好再配合人工抽评或者嵌入相似度来判断。

我在项目里通常会把数据划分成训练集、验证集和测试集，比例为八比一比一，测试集在训练过程中绝不触碰，只在最终评估时用一次。验证集用来做模型选择的依据，每一轮训练结束都记录一次指标变化，保证选出的模型是验证集上最好的那版，而不是训练集上最高的那版。另外一个很实用的技巧是，先跑一个简单的规则基线，比如“文本中出现了投诉关键词就判定为投诉”，如果预训练模型微调后的效果连规则基线都比不过，那多半是数据或者训练设置出了问题，而不是模型的问题。

3. 手把手完整跑通一个微调项目

3.1 环境搭建与依赖安装

讲完理论基础，接下来进入实操环节。我以最常见的文本分类任务为例，演示从环境搭建到模型推理发布的完整链路，整个流程可以迁移到其他任务上。

第一步是准备运行环境。我建议在Linux服务器上操作，如果只有个人电脑，有独立显卡的Windows或macOS也能跑通，只是内存和显存需要提前确认。用虚拟环境工具创建一个独立Python环境，避免和系统其他项目互相污染，这一步一定要养成习惯。

虚拟环境创建好以后，需要安装几类依赖：一是主流深度学习框架，用哪个框架需要根据你想加载的预训练模型来决定；二是模型加载和预处理相关的工具包，负责下载权重、加载分词器、处理数据；三是数据处理工具，负责读取数据集和做切分。安装命令基本就是下面这种形式：

conda create -n pretrain-demo python=3.10 conda activate pretrain-demo pip install 深度学习框架核心包 pip install 模型框架库 分词器工具包 数据处理工具包 pip install 加速器适配包

这里我要说明一下，不同生态的包名有差异，但核心流程是一致的。装完以后，先用一个最小的脚本测试一下环境是否正常，比如加载分词器并对一句话做编码，如果这一步能顺利输出数字张量，说明依赖基本没问题。实测中很多人翻车都翻在依赖版本不兼容上，比如某框架包和深度学习框架的版本对不上，一运行就报二进制错误。建议在环境里固定版本，把核心依赖的版本号记在一个配置文件里，方便后续重建环境。

3.2 数据准备与预处理

数据准备阶段是整个微调项目中耗时最长、也最锻炼人的环节。以文本分类为例，你需要准备两个文件，一个包含文本和标签的训练集，另一个包含同样结构的验证集和测试集。

原始数据往往有各种脏数据，比如空行、重复样本、HTML标签、表情符号、URL链接。我的处理顺序是：先做整体去重，再做文本清洗，最后做格式标准化。清洗时要注意，不要把所有特殊符号都删光，有时候标点符号本身携带语义信息，比如感叹号对投诉情绪有很强的指示作用。清洗完之后，还需要人工抽查一部分，确认没有误删。

清洗后的数据进入编码环节，这是新手最容易懵的地方。预训练模型不能直接输入原始文本，它需要被分词器转换成输入ID和注意力掩码。分词器会把一个句子切成子词单元，每个子词对应一个ID。以中文为例，一个词可能被切成多个子词，这是很正常的，不要觉得奇怪。

下面是一个简单的数据处理函数示例：

def build_dataset(samples, tokenizer, max_length=128): inputs = [] labels = [] for text, label in samples: encoded = tokenizer( text, truncation=True, padding="max_length", max_length=max_length, return_tensors="pt" ) inputs.append(encoded) labels.append(label) return inputs, labels

你可能会问，max_length应该设多少。这个值取决于你的数据长度分布，而不是拍脑袋。建议先统计一下训练集里所有样本的长度分布，比如百分之九十的样本都在一百二十个字以内，那max_length设成一百二十八就合理。如果设得太短，长文本的尾巴会被截断，语义损失严重；设得太长，又会带来无谓的显存消耗和训练变慢。

3.3 微调参数配置与训练过程

数据准备好之后，进入训练环节。先要加载预训练权重，然后在模型顶部接一个任务相关的输出层。分类任务通常是在语言模型的最后一层之上加一个线性分类层，输出维度等于类别数。

代码思路大致如下：

from 模型框架库 import create_model, create_tokenizer tokenizer = create_tokenizer("预训练模型标识") model = create_model("预训练模型标识", num_labels=2) # 冻结部分底层参数，只训练顶层 for name, param in model.named_parameters(): if "encoder.早期层" in name: param.requires_grad = False

这里有一个重要的设计点：微调时是更新全部参数还是只更新部分。全量微调效果通常最好，但显存和训练时间成本高；参数冻结则更快，但效果可能会打折。我的经验是，当数据量少于五千条时，全量微调很容易过拟合，不如只解冻最后几层和分类头，反而更稳定。

训练参数直接影响最终效果，这里给一组我在中规模分类任务上常用的初始化配置：

训练过程中，我强烈建议记录每一轮的损失和验证集指标，形成曲线图。不要只关注最终指标，曲线的形状能告诉你很多信息。正常情况下，训练损失和验证损失会一起下降；如果训练损失在降，验证损失反而上升，那就是过拟合的信号，需要减小训练轮数或者增加数据增强。

训练代码的核心循环也不复杂：取一个批次数据，计算损失，反向传播，更新参数。真正要花心思的是训练日志、断点保存和评估逻辑。每个epoch结束，用验证集做一次预测，保存验证集指标最高的那版模型。这一步极其重要，因为最后一轮的模型不一定是最好的，可能在某个中间轮次验证集指标已经到顶了。

3.4 保存、评估与推理

模型训练完成后，如何把它保存下来、加载回来，再用于推理，这又是一个容易踩坑的环节。

保存模型时要同时保存模型权重和分词器配置。如果只是保存了权重，下次加载时找不到对应的词汇表，代码直接报错。我的统一做法是：用模型的保存接口，把权重的配置都写进同一个目录，这个目录可以随时用恢复接口加载。

恢复后的模型在推理前，还需要做一次完整评估。先在测试集上跑一遍，打印出准确率、F1、召回率等指标，并输出一批错误样本。看错误样本比看指标更有价值，它会直接告诉你模型是哪里没学会，比如“模型把所有包含‘退款’字样的句子都判定为投诉”，那说明它学到的是关键词匹配，而不是真正的语义理解。

推理部署时，如果请求量不大，直接用单卡GPU批量推理就够；如果请求量很大，可以考虑将模型导出为高效推理格式，再用推理引擎加速，或者做量化压缩。量化是把模型参数的精度从32位浮点数降到16位甚至8位，模型体积和推理速度都能改善不少，但会有少量效果损失。我通常是先全精度推理，确认效果达标后，再尝试量化，看看能不能在接受范围内换取性能提升。

4. 我在实际项目中遇到的五个坑

4.1 显存溢出：把批大小调小就完了吗

显存溢出大概是最常见的报错，没有之一。新手第一反应是把批大小调小，这确实有效，但有时候会发现批大小已经调到1了，照样报错。这时候问题就不在批大小，而在序列长度。

我曾经跑过一个长度非常长的文本分类任务，每篇文章平均两千字。我把max_length设成了512，结果显存直接爆掉。后来发现，数据里有一些极端长的样本被截断到512之后仍然很大，但更关键的是，512长度对应的注意力矩阵计算量远超预期。解决办法是对长样本做“滑窗切分”，把一篇文章切成长度不超过256的多个小段落，分段编码后再做聚合判断。这个方法在召回和准确性上都比简单截断更稳。

另外一个通用技巧是开启梯度累积。如果你的目标批大小是32，但显存只允许一次放8条样本，那就分四次累加梯度后再更新参数，效果近似于一次用32条样本训练。逻辑上是在每个小批次上累积梯度，到设定步数后再执行优化器更新，显存压力能直接降到四分之一。

还有一个印象深刻的案例：同样一个模型，某天突然训练时报显存溢出，重启环境后就好了。排查了一圈发现是另一个服务占用了显存。所以遇到显存不足，第一步要用监控命令看当前显存占用情况，别一上来就怀疑自己的代码。

4.2 Loss曲线震荡：学习率才是元凶

损失函数曲线像心电图一样上下乱跳，是微调阶段非常典型的症状。我用过三亿参数模型做分类，一开始学习率设成了1e-4，结果训练到第三步，损失直接变成NaN，整个训练流程崩掉。

预训练模型的参数已经比较成熟，微调时学习率必须小。1e-4这种值，对从头训练的新网络来说很正常，但对预训练模型就是“核弹级”的冲击，一次更新就可能把学好的表征全部打乱。我现在的习惯是，分类任务从3e-5开始，生成任务从1e-5到2e-5开始，如果损失在下降但速度太慢，再适当调大；一旦出现震荡，第一步就是把学习率降一个数量级。

损失震荡还有一个常见原因，就是学习率预热做得不够。训练最开始，模型参数还没进入稳定的优化方向，直接顶满学习率容易跑偏。设置一个预热比例，比如前百分之十的训练步数内学习率从零线性上升到设定值，能有效避免前期震荡。

如果损失一直维持在某个高位不降，先不要调参，去看看数据。有一次我排查了很久，最后发现是有几条样本的标签反了，模型在强行记忆错误规律，损失根本降不下去。把脏数据清理掉，损失立刻恢复正常。

4.3 序列长度截断导致的语义丢失

很多文本分类任务里，关键信息往往出现在文章的后半部分。这时候如果无脑截断，模型就永远看不到那些信息，效果自然上不去。

有一个新闻标题分类的项目，原始文本是整篇新闻正文，结论性的句子大多在最后一段。我把max_length设成128，默认从头截断，结果模型只能看到开头几段背景描述，关键结论全被切掉了，验证集准确率比随机略高一点。后来我做了个简单修改：同时保留文章开头和结尾各64个字符，中间部分舍弃，效果立刻提升了好几个点。

这种“头尾拼接”的做法并不适用于所有场景，但它说明了一个道理：max_length和截断策略是重要的超参数，应该根据任务特点设计，而不是用默认值一路走到黑。更稳妥的做法是训练前先统计样本长度分布，对超长文本做一个分析，看看关键词主要集中在哪个段落，再决定截断方案。

另外要注意，中文模型的分词器对截断的处理也可能造成问题。有些分词器在截断后没有补充特殊标记，导致样本长度不一致，批量处理时会有很多无效填充。务必确认数据处理阶段是否正确配置了填充和截断参数。

4.4 标签不平衡与模型“偷懒”

分类任务中标签不平衡太常见了，尤其是投诉检测、异常检测这类场景，正样本占比可能只有百分之五。模型很容易学成一个“懒惰分类器”：不管输入什么，都预测为多数类，因为这样总体准确率已经很高了。

一个真实例子是垃圾评论识别项目，垃圾评论只占百分之四。第一次微调后模型准确率96%，但把所有垃圾评论都判成正常，召回率是0。指标看起来很漂亮，但业务完全没法用。

解决办法有三个方向。一是在损失函数里给少数类更高的权重，让模型在训练时更关注少数类；二是对多数类做欠采样，让正负样本比例接近一比一；三是使用专门处理不平衡损失的函数，这种损失函数会通过调制系数让模型集中精力学习困难样本。我通常会先试类别权重，因为它最简单，但要注意别把权重设得太大，否则训练会不稳定。

评估这类模型时，千万不要只看准确率，F1和召回率才是关键。如果正负样本比例差距巨大，建议汇报精确率和召回率两个维度，然后让业务方根据场景选定一个平衡点。

4.5 随机种子不固定：实验复现的隐形杀手

你有没有遇到过这种情况：同一个训练代码，跑两次，得到的结果差异很大，一个准确率90%，另一个只有86%。很多人会怀疑模型训练出的问题，但其实只是随机性在作祟。

深度学习框架里很多操作都有随机性，比如数据加载时的打乱顺序、权重初始化、部分算子的随机近似计算。如果不固定随机种子，每次训练运行都会得到略有差异的结果。复现实验结果，是工程师的基本素养，尤其是当你需要对比不同超参数时，如果随机种子不固定，你根本分不清效果提升是来自修改还是随机波动。

我的处理方式是在训练脚本开头设置随机种子：

import random import numpy as np def set_seed(seed=42): random.seed(seed) np.random.seed(seed) # 设置深度学习框架相关随机种子 # 并关闭部分算子的高速非确定性模式

同时也要保证数据加载顺序是可复现的。做完这一步，同一个脚本多次运行，指标波动基本能控制在零点二个百分点以内。需要提醒的是，提升模型效果时，要连续对比基准配置和改进配置，而不是跟网上别人报的指标对比，因为评测数据不同，指标本身没有可比性。

5. 从“会用”到“会挑”，我的一点进阶心得

5.1 别迷信越大越好

大模型这几年风头太盛，容易让人产生一种错觉：只要换上参数更多的模型，效果就会自动变好。但在我实际做过的项目里，大到一定规模后，效果提升会变得非常有限，而显存、推理延迟、部署复杂度的增长却是实打实的。

有一个文本分类项目，最开始用一亿参数规模的模型，F1是82。后来换到十亿参数规模，F1到了84，看起来提升了两个点。但模型体积直接从1GB涨到10GB，线上推理延迟翻了一倍。权衡之后，我们还是切回了一亿参数的模型，再通过优化数据清洗和标签设计，F1反而追到了85。模型大小不是唯一决定因素，数据质量、标签一致性和特征工程的作用常常更大。

如果你真的需要大模型的能力，现代参数高效微调技术提供了很好的折中方案。通过低秩分解的思想，只训练一小部分注入参数，冻结原有权重，一个几十亿参数模型在单卡上也能跑得动。这类方法已经在很多任务上被验证，效果和全量微调差距不大，尤其适合算力有限的团队。

5.2 必要的补课路线

很多人以为会调用模型库接口就等于会做预训练模型学习了，这其实只停留在“用工具”的层面。要达到“会改模型、会设计训练方案”的水平，有几块基础必须补上。

第一是概率统计。预训练模型本质上是在最大化某个似然函数，损失函数的设计、训练目标和评估指标的背后全都是概率论。第二是矩阵计算。注意力机制的计算过程就是矩阵乘法和缩放，理解维度变化对调试代码会很有帮助。第三是反向传播。虽然框架帮你自动算梯度，但当你遇到梯度消失、梯度爆炸时，不理解底层原理就只能靠瞎猜。

学习路线方面，不建议一上来就抱着经典架构论文反复啃，更适合的方式是读一篇简洁的讲解文章，然后直接复现一个小模型。很多人卡在“原理看懂了，代码写不出来”这一关，破解方法只有一个：动手。先改别人写好的数据处理脚本，再加一层网络结构，最后从零复现一个简化版本。整个过程会比单纯看代码扎实得多。

5.3 个人体会与建议

最后分享一点我自己的体会。刚开始接触预训练模型学习的时候，我也走过一段弯路，想着把所有模型都下载下来，把所有训练技巧都试一遍。结果就是项目进度被拖慢，效果也没有提升。后来才逐渐意识到，真正的学习路径其实很朴素：先拿一个小模型完整跑通一个端到端流程，用一条数据也好，先看到模型输出从无到有的过程；然后一点点增加数据，调整参数，再尝试更复杂的架构。

我建议每个初学者都要养成写实验记录的习惯。不要只在脑子里记住改动，把每次实验的配置、数据版本、指标结果都记录下来。三个月后回头看，这份记录会比任何教程都有价值。模型效果的提升往往不是某个单个技巧带来了，而是数据、参数、特征多个环节的微小改进累积出来的。

还有一些小技巧，比如在微调前先用预训练模型直接做预测，看它原本的能力边界在哪里。有些任务可能不需要微调，一个合适的提示模板就够了。这样能帮你快速判断，到底应该投入数据标注成本，还是先试着用现有模型去解决。另外，第一次训练时把批大小和学习率调得保守一点，先把流程跑通，再追求指标。先保证能稳定复现一个基础结果，再在这个基础上去做优化，这套思路在我做过的几乎所有项目里都适用。

预训练模型学习这件事，说难也难，说简单也简单。掌握底层逻辑，跑通一个完整项目，积累几次踩坑经验，你就能在这条路上走得很远。下一步可以试试换一个不同架构的模型，做一次对比实验，或者尝试在你的任务上应用参数高效微调，这些扩展都会让你对预训练模型的理解更进一步。