企业官网建设流程全解析

简介：面向毕业设计与课程设计的聊天机器人项目源码包，基于Django框架开发，融合深度学习模型实现对话交互，适合具备一定编程基础、正在准备毕设或课程作业的计算机相关专业学生参考与动手实践。压缩包采用zip格式，包体约191.86MB，内含完整的前后端源码与数据库文件，描述确认项目可直接运行，下载后即可搭建本地环境、启动服务并验证对话效果。目前已有122人浏览学习，可作为同类选题热度参考。包体未附带文件总数与类型明细，这里不作虚构；从描述可见，重点是一套完整可落地的工程项目。获取后可梳理工程目录结构、分析数据库表设计、理解前后端接口组织方式，并重点观察深度学习模型如何被封装进Django服务流程；既满足毕业设计演示与答辩需要，也能在此基础上扩充聊天语料、调整模型参数或优化回复逻辑，是一份能够支撑后续二次开发的实践蓝本。

1. 基于深度学习的聊天机器人设计源码：拿到 zip 后先看这一篇再动手

拿到 python 毕业设计里最常见的基于深度学习的聊天机器人设计源码.zip，很多人的第一反应是解压、装环境、然后直接跑 train.py。我建议你先别急。这个 zip 里真正值钱的东西不是那一堆 .py 文件，而是把数据清洗、样本拼接、损失遮蔽、生成策略这些环节串成一条完整训练链路的思路。缺了任何一环，你跑出来的模型都只是个说不出一句正常话的黑匣子。这篇文章只做一件事：把这类源码背后的技术选型拆开，从数据集构造讲到训练参数，再讲到让聊天机器人能开口说话的部署环节。新手能照着一步步复现，已经跑通的人也能知道该往哪个方向调参。

2. 聊天机器人技术路线与源码目录：先搞清楚模型结构，再决定怎么跑

2.1 检索式、生成式、混合式：毕业设计最常见的三种路线

聊天机器人听起来是一个项目，但打开源码包之后你会发现，不同人实现的方案可能完全不是一回事。当前做毕业设计最常见的路线可以分成三种：检索式、生成式和混合式。检索式的方法不依赖深度学习模型生成新文本，而是先准备一个问答库，用户提问时用文本向量相似度去库里找最接近的答案返回。它的优点非常明显：回答句子一定通顺、可控、不容易跑偏；缺点也很致命：问题库覆盖不到的问法，模型只能答非所问。很多同学以为拿个向量检索库就能交差，结果演示时换了提问方式，效果立刻翻车。

生成式的聊天机器人走的是另一条路，它让模型根据用户输入逐字预测回复内容。深度学习的部分主要集中在这里，也就是标题里说的“基于深度学习”的真正含义。生成式方案最大的优势是灵活，用户用没见过的说法提问，模型也能拼出一句语义相关的回复；但代价是生成内容不可控，可能重复、可能跑题、甚至出现低俗话。混合式则在两者之间做了一个折中：先用检索召回一批候选回复，再用生成模型对候选进行重排或改写，最终输出一个既自然又相对可控的结果。

我在看过大量这类源码包之后的经验是：纯生成式代码最容易跑通，也最适合作为毕业设计的主体；混合式听起来高级，但你需要维护问答库和检索链路，工作量直接翻倍；纯检索式又撑不起“基于深度学习”这个题目。所以下面所有讨论都围绕生成式聊天机器人展开，这也是大多数压缩包里实际采用的路线。

2.2 生成式聊天机器人的深度学习底座：为什么源码包里大多是单向语言模型

生成式聊天机器人在深度学习结构上还有细分，常见的有两类。一类是编码器-解码器结构，把用户输入先编码成语义向量，再由解码器逐个生成回复；另一类是单向语言模型结构，直接把用户输入和回复拼接成一段长文本，模型只负责预测后半段被遮挡的内容。源码包里到底该用哪一种，不能凭感觉选，要看你手里的数据规模和显存条件。

编码器-解码器结构听起来更“正规”，但它需要维护两套注意力机制，训练时需要同时考虑 encoder 和 decoder 之间的对齐关系，调参难度明显更高。单向语言模型结构实现起来非常朴素：给一句上文，模型预测下一个词，不断把预测结果拼回输入，继续预测下一个词。这正好适合对话场景：把历史对话拼接成上文，把当前回复当成要预测的目标。这类模型在中文社区里通常被称为 GPT 结构，你不需要关心它背后的商业背景，只需要知道它是一个基于 Transformer decoder 的生成模型即可。

单向语言模型最大的好处是训练样本构造简单、显存占用相对可控。比如用户问“今天天气怎么样”，你只需要把它组织成“用户：今天天气怎么样 机器人：适合出门走走”，然后让模型在看到前半段之后预测后半段。这也决定了源码包的目录结构：它不会像传统 NLP 项目那样区分 encoder 和 decoder，而是只提供一个语言模型加载脚本和一个数据预处理脚本。先理解了这一点，你再去读源码，就不会对着 model.py 里的一堆类名发懵。

2.3 解压源码包后的目录检查清单：哪些文件决定项目能不能跑

拿到 zip 先别急着双击运行，我一般习惯先解压到一个干净目录，再用命令行扫一遍文件结构。这一步花不了两分钟，但能帮你避开后面至少三个小时的报错排查。

unzip chatbot_project.zip -d chatbot_project cd chatbot_project find . -maxdepth 2 -type f | sort

第一行把压缩包解压到 chatbot_project 目录，第二行进入项目目录，第三行列出两层以内的所有文件。这一步的核心目的是确认源码包里有没有几个关键文件：README、requirements.txt、数据预处理脚本、训练脚本和推理脚本。很多同学直接把整个项目拖进 PyCharm，看到 train.py 就开始跑，结果连模型权重路径都不存在，报错之后回头找说明书，才发现 README 里写的环境要求完全没看。

一个结构正常的聊天机器人源码包通常长这样：

chatbot_project/ ├── README.md ├── requirements.txt ├── configs/ │ └── config.yaml ├── data/ │ ├── train.txt │ └── vocab.txt ├── preprocess.py ├── model.py ├── train.py ├── generate.py └── app.py

requirements.txt 里是 Python 依赖库，注意这里最容易踩坑的点是库的版本。比如 transformers 这个库，大版本升级之后 API 经常不兼容，有的源码用旧接口加载模型，你装了个新版本，运行到一半就报参数名错误。所以我会先看 requirements.txt 里有没有锁版本，如果没锁，训练前一定先跑一个pip install之外的小测试，确认模型能够正常加载。configs/config.yaml 是超参数集中地，训练轮次、学习率、batch size、最大序列长度一般都写在这里。data 目录通常不会随代码完整打包，因为语料文件动辄几百 MB，很多时候压缩包里只留一个体积很小的示例数据，所以当你看到 data 目录是空的，不要惊讶，这属于正常情况。

打开源码包之后还有一个动作不能省：直接打开 train.py，看它的from ... import ...。这能判断代码是基于什么深度学习框架写的，如果你的本地环境跟它不一致，需要先建虚拟环境，而不是硬生生往全局环境里装包。虚拟环境这一步建议从一开始就做，否则项目跑到一半把系统 Python 环境搞乱了，后面所有实验都会连带出问题。

3. 把中文语料变成训练样本：数据清洗、多轮切分与词表构建

3.1 中文对话数据从哪来：公开语料与自制数据的取舍

聊天机器人要能开口说话，先得有话可学。很多源码包里不会直接附送完整的训练语料，原因不是代码作者小气，而是中文对话语料动辄上 GB，压缩包体积会变得非常大。你自己准备数据时，一般有两种选择：用公开的闲聊语料，或者根据毕业设计题目自制一份领域问答数据。

公开语料的优势是量大、覆盖话题广，模型训练出来更接近“什么都能聊几句”的通用聊天机器人；劣势是噪声非常多，表情符号、URL、无意义回复、重复刷屏都可能混在里面。自制数据的优势是跟你的毕设题目贴合度高，比如做一个校园问答机器人，你只需要收集几百条关于选课、食堂、图书馆的问题和答案；劣势是数据量太小，模型很容易过拟合。我给你的参考标准是：通用闲聊方向，准备 5 万到 20 万组对话对；垂直领域方向，数据量最少也要 5000 组，低于这个数不如直接走检索式方案。

考虑到毕业设计的时间限制，我不建议自己写爬虫去采集对话数据。一方面爬虫会牵扯到目标网站的反爬机制，经常调节奏的时间都比写代码还多；另一方面，拿别人平台上的用户内容做训练，这里面的版权和合规风险不值得你搭上学业去赌。更稳妥的做法是用已经公开的、明确注明可以用于学习研究的对话语料，或者自己发动身边同学一起手工整理。数据量哪怕少一点，只要质量干净，训练出来的效果都会比堆十万条垃圾数据好。

3.2 一条清洗流水线：过滤噪声、长度截断和去重

拿到原始语料之后，清洗工作决定了训练的上限。很多聊天机器人模型并不是结构不行，而是训练数据里混杂了大量“哈哈哈”“不知道”“嗯嗯”这类无信息量回复，训练完模型自然只会复读。我处理聊天语料时，会固定走一条清洗流水线，它至少包含三个动作：过滤 URL 和特殊符号、按长度截断、按内容去重。

import re def clean_text(text: str) -> str: text = text.replace("\u3000", "") # 去掉全角空格 text = re.sub(r"https?://\S+", "", text) # 去掉 URL text = re.sub(r"[#@_~*]", "", text) # 去掉常见噪声符号 text = re.sub(r"\s+", " ", text) # 多个空格合并 return text.strip() def build_pairs(src_path: str, dst_path: str, min_len: int = 2, max_len: int = 64): pairs = [] with open(src_path, "r", encoding="utf-8") as f: for line in f: parts = line.strip().split("\t") if len(parts) != 2: continue question = clean_text(parts[0]) answer = clean_text(parts[1]) if not question or not answer: continue if not (min_len <= len(question) <= max_len): continue if not (min_len <= len(answer) <= max_len): continue pairs.append((question, answer)) # 去重：同一问题只保留第一次出现的回答 seen = set() unique_pairs = [] for q, a in pairs: key = q + "||" + a if key not in seen: seen.add(key) unique_pairs.append((q, a)) with open(dst_path, "w", encoding="utf-8") as f: for q, a in unique_pairs: f.write(q + "\t" + a + "\n")

这段代码的运行逻辑是从源文件逐行读取，按制表符把一行切成问题和答案。如果一条样本里没有制表符，说明它不是标准对话对格式，直接跳过。长度约束里的 max_len 建议设在 32 到 64 之间，太长的对话在训练时容易把上下文撑爆，太短又学不到有用信息。clean_text里那个全角空格替换很容易被忽略，但很多中文语料里混着全角空格，不清掉会让分词器产生无效 token。

去重这一步很多人会漏掉。公开语料里同一句话经常被不同用户重复使用，比如“好的”作为问题出现几百次，如果不做去重，模型会严重偏向输出“好的”，看起来就像个只会敷衍的机器人。去重时我习惯用“问题+答案”整体作为键，而不是只对问题去重。因为同一个问题可以有多种合理回答，如果你只按问题去重，会把一些正常的多答案样本误删掉。

3.3 构造训练样本：上下文与回复的两段式拼接

清洗完成的是标准对话对，但如果源码包里的训练数据是多轮对话，你还需要把多轮会话切分成带上下文的样本。这一步我一般会写一个单独的函数处理，原理非常简单：在会话进行过程中，每出现一条新回复，就把前面若干条用户消息拼接起来作为上下文，当前回复作为目标。

def split_multi_turn(dialog: list, max_context: int = 3): samples = [] for i in range(1, len(dialog)): start = max(0, i - max_context) context = " ".join(dialog[start:i]) reply = dialog[i] samples.append((context, reply)) return samples

这里的 max_context 表示最多带几轮上文。对于中文闲聊场景，我一般取 2 到 4，太长的历史会让模型分不清该回答哪一句。切分完成之后，需要把每一对上下文和回复转换成模型能读的 token id。这里要注意，聊天机器人源码包里如果用的是生成式预训练模型，通常不会自己手写词表，而是直接加载预训练分词器。

from transformers import AutoTokenizer tokenizer = AutoTokenizer.from_pretrained("./pretrain_model") tokenizer.add_special_tokens({"pad_token": "[PAD]"}) def build_model_input(context: str, reply: str, max_len: int = 128): context_ids = tokenizer.encode(context, add_special_tokens=False) reply_ids = tokenizer.encode(reply, add_special_tokens=False) # 给 [CLS] 和两个 [SEP] 留出额外位置 available = max_len - len(reply_ids) - 3 if available <= 0: return None if len(context_ids) > available: context_ids = context_ids[-available:] input_ids = [tokenizer.cls_token_id] + context_ids + \ [tokenizer.sep_token_id] + reply_ids + \ [tokenizer.sep_token_id] return input_ids

这段代码有两个关键设计。第一个是available的计算，它保证每条样本总长度不超过 max_len，并且优先保留完整回复。因为回复是训练目标，如果回复被截断了，模型要学的信息就不完整；实在放不下时宁可取舍上下文，也不要截断回复。第二个是context_ids[-available:]，它从上下文里取最后 available 个 token，也就是把离当前提问最近的内容保留下来，这在对话场景里更符合直觉。

拼接完成后的 input_ids 需要用q_len记录上下文部分截断到哪个位置，训练时才能把上下文部分的 loss 屏蔽掉。具体做法是记录[CLS] + 上下文 + [SEP]的长度，这个问题我会在下一章的训练代码里详细展开。如果你手上的源码包里没有预处理脚本，把这个函数补进去，就能把清洗好的对话对直接喂给后续模型使用。

4. 训练一个能对话的模型：从模型加载、损失遮蔽到关键超参数

4.1 微调还是从零训练：毕业设计场景下的性价比判断

代码和环境都准备好之后，接下来就是选择训练方式。基于深度学习的聊天机器人可以从零开始训练一个随机初始化的 Transformer，但我不建议你在毕业设计里这么做。从零训练生成模型需要的数据量是百万级起步，还需要多卡并行和非常细致的调参，而大多数同学只有一张消费级显卡，显存 6G 到 12G 不等，数据量也只有几万对。从零训练的结果大概率是 loss 下降缓慢，生成内容全是乱码。

更合理的做法是找一个已经预训练好的中文生成模型，把它的权重下载到本地目录，然后基于前面处理好的对话语料做微调。微调的意思是在预训练模型已经理解中文语法的基础上，让模型学习你的对话风格。这么做有三个实际好处：训练轮次可以大幅减少，通常 3 到 5 个 epoch 就能看到效果；对显存要求低，即使只有 6G 显存也能用小 batch size 跑；生成内容在语法正确性上有保障，不会从零开始学说话。

你可能会担心用了预训练模型会不会被认为“工作量不够”。我的看法是，毕业设计考察的是你能否独立完成数据构造、模型训练、效果调优和系统部署，而不是考察你是否从零写出了 Transformer。真正的深度学习工程师也不会每次都从零训练模型，站在已有模型肩膀上做垂直任务本来就是工业界的标准做法。只要你能把微调原理讲清楚，把损失函数为什么只计算回复部分讲明白，这个工作量完全足够撑起一篇文章。

4.2 训练脚本最小实现：把问题部分从损失里拿掉

先看核心训练逻辑。下面这段代码假设你已经用上一章的方式把每条对话样本转换成 input_ids，且记录了问题部分的长度 q_len。训练过程中最重要的一个细节就是：不能让模型去学习预测“用户问题”，它只需要预测机器人的回复部分。实现方式是把问题部分的 token 在 labels 里替换成 -100。

import torch from torch.utils.data import DataLoader from transformers import AutoModelForCausalLM model = AutoModelForCausalLM.from_pretrained("./pretrain_model") model.to(device) optimizer = torch.optim.AdamW(model.parameters(), lr=3e-5) def train_step(batch, model, optimizer): input_ids = batch["input_ids"].to(device) q_len = batch["q_len"].to(device) labels = input_ids.clone() # 把每个样本的问题部分（含特殊符号）设为 -100，loss 直接忽略 for i, ql in enumerate(q_len): labels[i, :ql] = -100 outputs = model(input_ids=input_ids, labels=labels) loss = outputs.loss loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0) optimizer.step() optimizer.zero_grad() return loss.item()

这段代码里最关键的语句是labels[i, :ql] = -100。在 transformers 库里，所有标签值为 -100 的位置都会被 loss 函数自动忽略，不会参与梯度计算。如果你忘了做这一步，模型会同时学习预测问题部分，这会占用大量模型容量，最终导致回复部分训练不充分。q_len 在数据预处理阶段就要算好，它的值是问题 token 数加上起始符和分隔符的长度，也就是上一章代码里[CLS] + context_ids + [SEP]这段的 token 总数。

还要注意clip_grad_norm_这行梯度裁剪。对话模型训练特别容易因为某个异常样本产生梯度爆炸，一旦梯度值超过一定范围，loss 会直接跳到 NaN，模型权重就废了。max_norm 取 1.0 是一个比较保守的默认值，如果你发现训练速度变慢，可以放宽到 2.0。这段最小实现的训练逻辑完整覆盖了加载、前向传播、反向传播和参数更新，你可以把这一整段替换掉源码包里乱七八糟的训练代码。

4.3 学习率、batch size、梯度累积与训练轮次怎么设

训练聊天机器人有一组比较稳定的参数基线。学习率微调场景下通常取 1e-5 到 5e-5，如果是从零训练则要放大到 1e-4 左右。batch size 并不追求大，很多项目单卡只能放 4 或 8 条样本，因为对话样本序列长度不短，显存压力主要来自序列长度而不是 batch 大小。当 batch size 太小导致梯度波动明显时，用梯度累积来模拟更大的 batch。

accumulation_steps = 4 for step, batch in enumerate(train_loader): loss = train_step(batch, model, optimizer) if (step + 1) % accumulation_steps == 0: optimizer.step() optimizer.zero_grad()

这段代码的意思是把每 4 个 batch 的梯度累加到一起，再更新一次参数，效果等同于把 batch size 放大了 4 倍，但显存占用没有变化。你可以在 config 配置里加两个字段，一个叫 train_batch_size，一个叫 gradient_accumulation_steps，最终学习率需要参考累积后的总 batch size 进行调整。实际训练时我会把学习率设小一点，比如 3e-5，配合较大的累积步数，训练曲线比大学习率稳定得多。

训练轮次建议从 3 个 epoch 开始观察。第一轮 loss 会明显下降，第二轮下降速度变慢，到第三轮基本进入平台期。如果你在第三轮之后继续训练，模型会逐渐出现过拟合风险，具体表现是训练集 loss 继续下降，但生成时开始不断重复训练数据里的高频句子。我建议每完成一个 epoch 保存一次 checkpoint，并分别在训练后 1 个 epoch、2 个 epoch、3 个 epoch 的模型上做生成测试，手动体验一下哪个版本的回答更自然，不要只凭 loss 数值选模型。

5. 避坑：聊天机器人训练和部署中的 5 个高频问题

5.1 loss 不降反升或变成 NaN：先查学习率和数据脏值

很多人在训练到几百步时遇到 loss 突然变成 NaN，第一反应是模型结构有问题。遇到这种情况我一般先做三件事：看学习率是否过大、看数据里是否有异常文本、看是否缺少梯度裁剪。大学习率会让参数更新步长太大，直接越过最优点导致 loss 发散；数据里的超长文本、乱码字符和纯空白行会让模型计算出无意义的梯度。解决办法很直接：把学习率降到 1e-5，给训练循环加上梯度裁剪，然后在数据预处理里加一个规则，过滤掉所有长度小于 2 或大于 256 的样本，再把clean_text结果为空的行直接丢弃。这三个动作能解决九成以上的 NaN 问题。

5.2 模型只会回答“不知道”“哈哈哈”：生成策略与数据分布的双重问题

训练集里如果“不知道”“哈哈哈”这类回答出现次数过多，模型会把这些高频回答当作默认输出。另一个来源是生成策略，使用贪婪搜索时模型每一步都选概率最高的词，最终就变成了概率最高的那几句套话循环。这个问题要从两头解决：数据层面统计回答文本的出现次数，把超过一定重复次数的回答直接剔除，或者做数据增强改写；生成层面关闭纯贪婪模式，改用采样式生成，适当提高 top-p 到 0.9，让模型有机会选到概率稍低但语义更丰富的词。

5.3 显存不足：从 batch size 和序列长度两头压

如果你的显卡只有 6G 显存，而源码默认 batch size 是 16，训练一开始就会报 CUDA out of memory。这个错误信息虽然吓人，但解决方案非常套路化：先把 batch size 调到 2，如果还爆，就把 max_len 从 128 降到 64，再不行就启用梯度检查点，把训练时临时保存的中间激活值改成重新计算。很多源码包默认配置是针对 24G 显存写的，你需要根据自己的机器改配置，而不是换显卡。一个很实用的判断方法：看 config 里 max_len，如果超过 128，而你的显存小于等于 8G，训练前先把它改小。

5.4 训练 loss 很低但实际对话效果很差：过拟合与语料噪声

训练集 loss 低代表模型记住了训练数据，但不代表它能泛化到新问题。最常见的情况是数据量太少但训练轮次太多，模型把问题关键词和固定回答死记下来，换个问法就答非所问。还有可能是训练语料里混着大量答非所问的脏数据，模型把错误对应关系也学进去了。我习惯在训练集之外留出 5% 到 10% 的验证集，每个 epoch 结束后在验证集上算一遍 loss。如果训练 loss 明显下降但验证 loss 上升，说明过拟合了，解决办法是加 dropout、减少训练轮次，或者扩充更多样的训练数据。

5.5 checkpoint 加载报错：设备不匹配和键名前缀

训练完成之后，加载保存的模型权重经常会遇到两类报错。一类是.pth文件在 GPU 上保存，加载到无 GPU 的机器时提示设备错误，另一类是用了 DataParallel 之后权重键名前面多了module.前缀，直接加载会提示键名匹配失败。我在写推理脚本时，会先做一次兼容性处理：加载时指定map_location="cpu"，然后检查 state_dict 里的键名，把前缀去掉再做加载。

checkpoint = torch.load(path, map_location="cpu") state_dict = checkpoint # checkpoint 里可能直接就是 state_dict if any(key.startswith("module.") for key in state_dict): state_dict = {key.replace("module.", ""): value for key, value in state_dict.items()} model.load_state_dict(state_dict, strict=False)

这段代码里的strict=False是故意保留的。因为 transformers 库在版本升级之后，模型结构里某些中间层的命名可能发生变化，开启严格模式会导致加载失败。用strict=False先把能匹配的权重加载进来，缺失的部分保持预训练模型原有初始化值，这在做模型权重迁移时是比较常用的兜底策略。注意如果缺失参数过多，模型的对话效果会大幅下降，这时候你应该检查模型结构定义和训练脚本里的模型加载方式是否一致。

6. 把模型包装成可演示的聊天机器人：Flask 接口与生成策略调优

模型训练完成，最后一步是把它封装成一个能实际操作的演示系统，否则毕业设计答辩时总不能现场敲命令行。最常见的做法是用 Flask 起一个 HTTP 服务，前端页面把用户输入 POST 到后端，后端调用模型生成回复再返回。

from flask import Flask, request, jsonify from transformers import AutoModelForCausalLM, AutoTokenizer app = Flask(__name__) model = AutoModelForCausalLM.from_pretrained("./finetuned_model") model.eval() tokenizer = AutoTokenizer.from_pretrained("./pretrain_model") def generate_reply(text, max_new_tokens=64, temperature=0.7): input_ids = tokenizer.encode(text, return_tensors="pt") output = model.generate( input_ids, max_new_tokens=max_new_tokens, do_sample=True, top_k=40, top_p=0.9, temperature=temperature, pad_token_id=tokenizer.pad_token_id, eos_token_id=tokenizer.sep_token_id, ) return tokenizer.decode(output[0][input_ids.shape[1]:], skip_special_tokens=True) @app.route("/chat", methods=["POST"]) def chat(): data = request.get_json() user_input = data.get("message", "") if not user_input: return jsonify({"reply": "请输入内容"}) reply = generate_reply(user_input) return jsonify({"reply": reply}) if __name__ == "__main__": app.run(host="127.0.0.1", port=5000)

推理代码里最需要注意的是生成策略参数。如果直接使用默认的贪婪生成，模型回复会非常死板；而如果temperature设得过高，回复又会变得逻辑混乱。我比较推荐temperature=0.7、top_k=40、top_p=0.9这三个参数一起使用。temperature 控制概率分布的尖锐程度，越低越保守，越高越随机；top_k 只从概率最高的前 40 个词中选择，避免采样到太冷门的词；top_p 则是在累积概率超过 0.9 的范围内采样，三者配合能同时保证通顺和多样性。

Flask 接口里的pad_token_id和eos_token_id必须设置。不设置的话，模型生成到序列末尾时可能一直输出空白填充符，或者使用错误的结束符导致生成不停止。很多同学部署时聊天界面一直转圈，就是因为在生成配置里漏了这一项。eos_token_id 设置成 tokenizer 的 sep_token_id，因为我们在预处理时就是用这个符号表示回复结束。

部署完成之后，我通常会用几个固定问题做冒烟测试：问一句“你好”，问一个训练集里出现过的同类问题，再问一个训练时完全没见过的问题。前两者验证模型是否学到了基本对话能力，第三个验证泛化能力。如果第三个回答开始跑偏，我会回到生成参数上做微调，而不是立刻加训数据。这套验证习惯帮我避开了很多答辩前临时翻车的场景。

这几年我帮别人看了不少类似的源码包，发现能顺利跑通的人往往不是代码功底最强的，而是愿意把每一环节都拆开验证的人。希望这篇笔记能让你少走一段弯路，祝你也能调出一个能好好聊天的机器人。

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