企业官网建设流程全解析

带过几届毕设之后，我发现一个规律：每年选题季，“基于深度学习的情感分析”这类题目总是被抢得最快——名字里有“人工智能”四个字，数据看上去随手就能弄到，做出来还能有个能点、能输文字、能出图的界面，答辩时演示效果拉满。但真正动手三个月，能把这条链路走通并且讲清楚每一步为什么这么做的人，比例并不高。大多数翻车的点不在模型，而在于数据脏得超出想象、评估口径自欺欺人、以及答辩现场网络一断整个系统就哑火。

这篇内容聊的是“基于深度学习的电商评论情感分析系统”这套毕设该怎么落地。它本质是一个文本分类系统：输入一条用户评论，输出情感倾向（正面、中性、负面，或者更细的五级），并给出置信度和支撑判断的关键词片段。往下延展，它还能做评论筛选、差评预警、竞品口碑对比、商品页情感分布统计。适合正在找毕设方向的同学、需要快速搭一个文本分类原型的产品或运营同学，以及想弄明白“预训练模型微调到底怎么落到一个具体业务上”的入门开发者。我会把架构选型、数据工程、模型训练、工程化封装、问题排查这五块拆开讲，参数怎么定、阈值怎么算、坑在哪里，都尽量说透。

1. 选题拆解：这个系统到底交付什么

1.1 从业务视角倒推功能边界

很多人一上来就想着“我要做一个很牛的模型”，然后花两个月调参，最后发现论文写不出东西、系统也没法演示。正确的顺序反过来：先想清楚这套系统在真实场景里被谁用、怎么用，再倒推技术方案。

电商评论情感分析的真实使用方大概有三类。第一类是商家运营，他关心的是今天新增的差评里有没有集中爆发的质量问题，需要的是差评聚类和关键词提取，而不是单条评论的准确率。第二类是平台治理，关心的是刷单、恶意差评、竞品水军，需要的是异常评论识别，情感极性只是其中一个特征。第三类是消费者，关心的是“这条评论到底靠不靠谱”，需要的是情感摘要和代表性评论抽取。

毕设场景下不可能全做，所以我建议把功能收窄成三条主线：单条评论实时情感判别、批量评论情感分布统计、以及情感关键词高亮。第一条是核心，验证模型的判别能力；第二条是应用层，体现系统的“系统”属性而不是一个脚本；第三条是加分项，让答辩时的演示有视觉冲击力——用户输入一句“物流太慢了但是质量还行”，系统给出“中性偏负面”并且把“太慢”“还行”高亮出来，这一下就把技术含量摆出来了。

之所以强调收窄，是因为毕设的评分维度里，“工作量饱满”和“功能完整”往往权重不低，但“功能完整”不等于“功能多”。一个能稳定跑通、每个模块都有清晰边界和解释的系统，比一个塞了八个功能但每个都半吊子的系统得分高得多。我见过一个很典型的反面案例：某同学硬塞了语音评论分析、跨语言翻译、图像情感识别，最后答辩时三个模块有两个报错，评委的注意力全在报错上，模型本身做得不错也没人看了。

1.2 毕设场景下的验收标准怎么定

学术项目和工业项目最大的区别是：工业项目追求线上指标，学术项目追求可解释、可复现、有对比。所以你的验收标准不能只写“准确率达到 92%”，那太单薄了，而且容易被打回。

我建议从四个维度定义验收线。第一是效果维度，三级分类在自建测试集上 macro-F1 不低于 0.85，五级分类不低于 0.78，这个数字是预训练模型微调后比较稳的区间，定太高自己难受，定太低显得没做事。第二是工程维度，单条评论推理延迟在普通笔记本 CPU 上 P95 不超过 200ms，批量接口吞吐不低于 50 条/秒。第三是可用维度，系统要能在断网环境下完整演示，这条很多人忽略，但答辩教室的网络状况你根本没法控制。第四是可解释维度，每条预测结果都要能给出概率分布和至少两个关键词依据。

把验收标准写进开题报告有一个隐形好处：它会逼着你在做的过程中不断对照，而不是最后一周才发现“哦原来我这个指标根本达不到”。量化指标本身就是一种工程纪律。

1.3 一句话讲清楚系统的技术骨架

整条链路其实是六个环节串起来：数据采集与清洗 → 标签体系设计与标注 → 文本预处理与分词 → 模型训练与评估 → 推理服务封装 → 前端展示与数据看板。

用一句生活化的类比来解释：这就像开一家餐厅。数据采集是采购食材，清洗是洗菜挑烂叶，标签体系是决定菜单分几档辣度，预处理是切菜备料，模型训练是掌勺炒菜，服务封装是厨房出餐口，前端就是餐厅大堂。绝大多数人的失败不在于炒菜手艺，而在于食材本身就坏了——电商评论里的错别字、表情符号、拼音缩写、刷单模板文案、广告导流文本，这些“烂叶”如果没挑干净，再好的模型也学不出东西。

2. 整体架构与技术选型：为什么这么搭

2.1 分层架构与模块边界划分

我推荐的四层架构是这样的：数据层、算法层、服务层、展示层。

数据层负责原始评论的存储、清洗后的语料表、以及标注结果的管理，用 MySQL 存结构化字段，清洗后的原始文本可以单独存一张表，别和标注表混在一起，否则后面想做数据版本回溯会非常痛苦。算法层包含预处理管道、模型定义、训练脚本、评估脚本，这一层要严格做到“输入一个文件、输出一个模型和一个报告”，保证可复现。服务层用 FastAPI 把模型包成 HTTP 接口，加上缓存和批量处理能力。展示层做个简单的前端，用 Streamlit 或者原生 HTML + ECharts 都行，关键是要有情感分布饼图、时间趋势折线图、以及单条分析的关键词高亮。

为什么强调“模块边界”？因为毕设答辩最常被问的问题是“你这个系统的哪部分是你自己做的”。如果你的代码是一坨几百行的脚本，从头到尾没有函数拆分，那评委没法判断你的工作量。反过来，如果你的目录结构清晰到data/、models/、api/、web/、experiments/一眼分明，每个模块有独立的 README 说明输入输出，那即使模型很简单，工作量也是看得见的。

这里有个实操心得：把每次实验的训练配置、数据版本、评估结果都写成一个 JSON 落到experiments/目录下，文件名带上时间戳。这个习惯看起来麻烦，但到了写论文要画对比表格的时候，你会发现省下的时间远超当初多花的十分钟。

2.2 模型路线：三条路各自适合什么情况

情感分析的模型路线大致三条，我把它们的适用场景和预期效果列出来，你对着自己的条件选。

这三条路不是互斥的，最好的做法是全部做一遍，然后在论文里形成一条清晰的递进曲线。规则法当基线，传统机器学习证明“特征工程有用”，预训练模型证明“语义表示有用”，最后再做个消融实验说明每个改进点的贡献。这条叙事线在答辩时非常讨喜，因为它体现了你对问题递进的理解，而不是“我上来就调了个大模型”。

选预训练模型的时候有几个实际问题要注意。第一是模型体积，base 级别的中文模型参数量在一亿出头，fp32 权重文件四百多兆，如果你的笔记本只有 8G 内存，加载都费劲，这种情况下要么换 small 版本（参数量降到三千万左右），要么用 ONNX 量化到 int8，体积能压到一百兆出头。第二是词表匹配，电商评论里大量网络用语和错别字，标准词表里可能没有，会被切成[UNK]，这时候要么在预处理阶段做一层纠错映射，要么干脆用字符级模型绕开分词问题。第三是许可证，选模型之前一定看清楚能不能商用，毕设虽然不涉及商用，但写进论文里引用规范一些总没坏处。

2.3 技术栈清单与硬件预算

技术栈我按“稳妥优先”的原则给一套配置，都是社区里验证过无数遍的组合，出问题好搜。

• 深度学习框架：PyTorch，版本选稳定版即可，别追最新
• 预训练模型库：HuggingFace Transformers，配合 datasets 做数据加载
• 中文分词：jieba 或者 pkuseg，规则基线用得上
• 传统机器学习：scikit-learn，TF-IDF 和线性模型都在里面
• 推理服务：FastAPI + Uvicorn，异步接口，自带 Swagger 文档
• 模型导出：ONNX + onnxruntime，CPU 推理提速明显
• 缓存：Redis，可选，用来缓存高频重复评论
• 数据库：MySQL 8 或者 SQLite，毕设用 SQLite 完全够
• 前端：Streamlit 最快，想要好看点就 Vue3 + ECharts

硬件这块，我算一笔账给你参考。假设用 base 级中文模型，最大序列长度设 128，批大小 32，fp32 精度。模型参数约 1.1 亿，权重占用约 440MB；训练时 Adam 优化器要存一阶和二阶动量，各一份，加上梯度，总共大约是参数量的 4 倍，也就是 1.8GB 左右；激活值随批大小和序列长度增长，粗略按 1GB 估。加起来 3.5GB 上下，一张 8G 显存的消费级卡跑起来很宽松，6G 的卡把批大小降到 16 也能跑。如果没有独显，纯 CPU 训练 base 模型一个 epoch 在几万条数据上可能要一两个小时，训练三到五个 epoch 就是一整天，这个时间成本要提前算进去。折中方案是用 small 级模型，CPU 上一个 epoch 二十分钟左右，效果掉两三个点，完全可接受。

3. 数据工程：决定上限的一步

3.1 数据从哪来，边界在哪

数据来源无非三条：公开数据集、自己采集、以及两者混合。

公开的中文情感数据集有几个常用的，规模从几万到几十万条不等，优点是标签质量相对可靠、有论文引用支撑，缺点是领域不匹配——很多是酒店、餐饮、影视评论，跟电商数码、服饰、食品的评价习惯差别很大。直接拿来做训练，模型会学到一堆领域无关的表达。

自己采集的话，要注意合规边界。只采集公开可见的评论文本，不采集用户身份信息，昵称、头像、订单号这类字段一律不要落库；采集频率控制住，别给对方服务器造成压力；采集到的数据只用于本地训练，不二次分发。这些不是形式主义，而是基本的工程素养，写进论文的“数据伦理”小节里也是加分项。

混合策略我实测下来最稳：用公开数据集做预训练阶段的领域适应（可选），用自采数据做主训练和测试。自采数据量建议不少于两万条，覆盖至少五个商品大类，每个大类不少于三千条评论。为什么强调品类覆盖？因为不同品类的表达差异极大，数码类评论爱说“续航”“散热”“做工”，服饰类爱说“尺码”“面料”“色差”，如果训练集只有单一品类，模型在跨品类测试时会掉得很厉害，这个现象在论文里叫领域漂移，是个很好的讨论点。

3.2 清洗、去重与标签体系设计

清洗这步的工作量被严重低估。我把常见的脏数据类型和处理方式列个表。

去重这块要多说两句。电商评论的重复率非常高，我处理过的一批数据里，完全重复的文本占了 8% 左右，近似重复（改了几个字）再加 12%。如果不去重，这些样本会同时出现在训练集和测试集里，模型记住了原句，测试指标虚高十几个点，答辩时评委随便找条真实评论一试就露馅。去重的方法是先做精确去重（文本哈希），再做近似去重（SimHash 算汉明距离，或者用字符级 n-gram 的 Jaccard 相似度），两步做完通常能砍掉 15% 到 25% 的数据量。

标签体系的设计要克制。三级（正面、中性、负面）是最稳的，标注一致性容易保证，类间边界清晰。五级（非常负面到非常正面）看起来更细，但“正面”和“非常正面”的边界极其模糊，不同标注员之间的一致性会掉到 0.6 以下（用 Cohen's kappa 衡量的话），这种标签噪声会直接拖垮模型。

我的建议是主任务做三级，同时保留一个“情感强度”的回归分支作为扩展讨论，论文里可以写“考虑到细粒度标注的一致性限制，本文采用三级主标签 + 强度辅助标签的方案”，这样既体现了思考深度，又不用承担五级标注的成本。

3.3 标注、抽检与数据划分的坑

标注环节最容易被糊弄过去，也最容易埋雷。如果你自己一个人标，标到后面会疲劳，标准会漂移；如果找同学帮忙标，一定要先做标注规范文档，包含明确的正负面判定规则、边界案例示例、以及“不确定”选项。

关键操作是抽检。标完一轮后，随机抽 10% 的样本做二次标注（自己隔几天再标一遍，或者找另一个人标），算一下一致性。如果 kappa 低于 0.75，说明规范有问题，回去改规范重标，别硬着头皮往下走。我吃过这个亏：早期一批三千条数据没做抽检，训练出来的模型在测试集上表现很好，但拿真实评论一试，发现“质量一般般”这类中性偏负面的表达被大量标成了正面，模型跟着学歪了。

数据划分这里有个必踩的坑，我单独拎出来说：绝对不能用随机划分。原因很简单，同一个商品下的多条评论高度相关，随机划分会让同一商品的评论同时出现在训练集和测试集，模型只要学到“这个商品的评论大多是正面的”就能拿高分，这叫数据泄漏。正确的做法是按商品 ID 分组划分，同一个商品的所有评论只能落在同一个集合里。更严格一点可以按时间划分，用早期数据训练、后期数据测试，模拟真实的上线场景。

划分比例上，训练、验证、测试按 8:1:1 或者 7:1.5:1.5 都行，但测试集绝对不能再用来调参。测试集要“封存”，只在你认为模型定稿的那一刻打开一次。如果反复用测试集调超参，本质上就是过拟合测试集，报出来的数字没有任何意义。

3.4 类别不均衡与难样本处理

电商评论的天然分布是严重偏正面的，正面可能占七成，负面两成，中性一成。这个分布下，模型只要无脑全预测正面，准确率就有 70%，但业务上毫无价值——商家真正关心的是那两成负面。

处理不均衡有几种常用手段，效果和副作用各不相同。过采样（对少数类复制或做文本增强）简单直接，但容易过拟合，需要配合 dropout 和正则；损失函数加权，给少数类更高的权重，权重可以按类别频次的倒数来算，比如正面、中性、负面频次比是 7:1:2，权重就大致设成 1:7:3.5，再归一化；Focal Loss 可以压一压易分样本的贡献，让模型聚焦难样本，但对超参比较敏感。我通常组合使用：损失加权为主，文本增强为辅（同义词替换、随机删除、回译，回译效果最好但需要有翻译接口，离线环境就用同义词替换）。

难样本这块，指那些模型反复学不会的样本，比如含反讽的评论（“这质量真是绝了，用了三天就坏”）、含转折的长句（“外观不错，但是……”）、以及带强烈否定嵌套的句子（“不能说不好”）。处理办法是建一个难样本集，训练时给它更高的采样概率，同时人工分析一下这些样本的错误模式，如果发现某一类错误集中出现，说明预处理或标签有问题，先修数据再修模型。

4. 模型实现细节：从基线到可用

4.1 先把基线跑通，别急着上大模型

很多人跳过基线直接上预训练模型，结果模型出来后不知道好在哪，论文里也没法做对比。基线的作用是给你一个参照系，证明后面的复杂度提升是值得的。

规则基线实现起来很简单：准备一份正面词表和负面词表，各五百到一千个词，加一份否定词表（不、没、别、未、无）和程度副词表（很、非常、特别、有点、稍微，各带权重），然后按句子扫描，命中情感词加权累加，遇到否定词就把后面最近的词极性翻转，遇到程度副词就乘以权重。这个基线在三级分类上大概能到 0.70 上下，别嫌低，它的价值在于可解释性极强，你能挨个分析错例，搞清楚哪些语言现象是词典覆盖不到的——这些分析写进论文就是很好的“动机”部分。

第二层基线用 TF-IDF 加线性模型。字符级 n-gram 比词级更稳，因为不用分词，直接取 1 到 3 的字符 n-gram，维度控制在 10 万以内，用 LinearSVC 或者逻辑回归，训练几秒钟，效果能到 0.83 左右。这里可以做个对比实验：词级特征和字符级特征的效果差异，以及两者拼接后的效果，这个实验成本极低但很有说服力。

4.2 预训练模型微调的关键参数怎么定

到了预训练模型这步，参数的重要性排序是：学习率 > 序列长度 > 批大小 > 训练轮数。

学习率是微调过程中最重要的一个参数。预训练模型已经学好了通用语言表示，微调时要用小学习率，把量级控制在 1e-5 到 5e-5 之间。我的经验值：batch 小于 16 用 2e-5，batch 大于等于 32 用 3e-5，配合线性 warmup，warmup 比例设 10%。学习率设到 1e-4 以上，模型很容易在第一个 epoch 就把预训练知识冲掉，表现为训练损失快速下降但验证集效果崩掉，这个现象叫灾难性遗忘，一旦出现基本就得重训。

序列长度的选择要在效果和效率之间平衡。电商评论的长度分布通常是长尾的，中位数在 30 到 60 字，95 分位在 150 到 200 字。我实测下来，截断到 128 已经能覆盖 93% 左右的评论，再往上加到 256，效果提升不到一个点，但训练时间翻倍。所以默认 128，如果你的数据里长评论占比高（比如家电、汽车品类的深度评测），可以单独做个对比实验说明 256 的必要性。

批大小受显存限制，但也影响训练稳定性。批太小（比如 8）梯度噪声大，训练曲线抖得厉害；批太大收敛快但泛化可能略差。16 到 32 是比较舒服的区间。这里顺便说一下梯度累积，显存只有 4G 的时候，可以用批大小 8 配合梯度累积步数 4，等效批大小 32，效果基本一致，只是训练时间多了些。

训练轮数别贪多，三到五个 epoch 足够。预训练模型在小数据集上过拟合非常快，第二个 epoch 之后验证集指标往往就开始横盘甚至下滑。一定要开早停，监控验证集的 macro-F1，连续两轮不提升就停。

还有几个容易忽略的细节。分类头别搞太复杂，一个 dropout（0.1 到 0.3）加一个全连接层就够，堆两三层的收益微乎其微。句子表示用[CLS]位的输出还是所有 token 输出的平均池化，建议两种都试一下，经验上分类任务里[CLS]略稳，但差异不大。另外别忘了设置随机种子，并且跑两次取平均，因为单次训练结果的波动可能有 0.5 到 1 个点，只跑一次就报数字不太严谨。

4.3 训练过程的监控与结果分析

训练日志里至少要记录这几项：每个 step 的训练损失、每个 epoch 结束时的验证损失、验证集 macro-F1、以及每个类别的精确率和召回率。

为什么单独看每类的指标？因为整体准确率会掩盖问题。比如正面类召回 0.95、负面类召回 0.62，整体准确率看着还行，但业务上负面漏检意味着差评预警失效，这是致命的。这种情况通常说明模型被多数类带偏了，得回头调损失权重或者补充负样本。

结果分析要做三件事。第一，画混淆矩阵，看错误集中在哪两个类别之间。中性类通常是最大的混淆源，因为它和正负面都存在语义重叠——“还行吧”“一般般”这种表达，人标起来都犹豫。第二，做错误样本的人工抽检，随机抽 50 到 100 条错例，逐条看，归类错误原因，我一般分成五类：标注错误、反讽、转折句、否定嵌套、长度截断。统计出各类占比，这张表放在论文里非常能体现你的分析深度。第三，做消融实验，去掉某个模块（比如去掉数据增强、去掉类别加权、换掉预训练模型）看指标变化，量化每个设计的贡献。

如果分析下来中性类的 F1 只有 0.6 出头，别急着调模型，先回去看数据。很可能中性类的定义本身就有问题，或者是样本量太少。这时候补标注比调参有效得多。

4.4 模型压缩与推理加速

毕设系统最终要在普通机器上跑，模型不能太重。三个手段按投入产出比排序：ONNX 导出、动态量化、蒸馏。

ONNX 导出最省事，torch.onnx.export走一遍，然后用 onnxruntime 推理，CPU 上通常能快 1.5 到 2 倍，准确率零损失。注意导出时要指定动态维度，把 batch 维和序列长度维都设成动态，否则换个长度就得重新导出。动态量化（quantize_dynamic）把权重从 fp32 压到 int8，模型体积能降到四分之一，CPU 推理再快一截，精度损失通常在 0.5 个点以内，可以接受。蒸馏就复杂一些，需要训练一个小的学生模型去拟合大模型的输出分布，工作量对毕设来说偏大，除非你论文方向就是模型压缩，否则不建议。

实测数据给你参考：base 模型 fp32 在普通笔记本 CPU 上单条推理约 80ms，ONNX 之后约 40ms，量化之后约 25ms。这个延迟足够支撑一个交互式演示了。批量接口那边，把多条评论拼成一个 batch 送进去，吞吐能到每秒一百多条，做数据看板的批量统计完全够用。

5. 系统工程化：从脚本到能演示的系统

5.1 推理服务封装与接口设计

模型训练完只是一个权重文件，要变成“系统”必须封装成服务。用 FastAPI 写接口，主要是图它自带 Swagger 文档，答辩时打开/docs页面，评委能直接点着试，这个交互体验比你自己写个表单强得多。

接口设计上，我建议至少三个。POST /predict接单条文本，返回标签、置信度、三类概率、关键词片段。POST /predict/batch接文本列表，返回结果数组，加上总数和耗时。GET /stats返回累计分析的评论数、各情感占比、以及最近一段时间的趋势数据，给前端画图用。

这里有个细节值得单独讲：置信度阈值。模型输出的概率再高也不代表一定对，我通常设一个阈值，比如最高类概率低于 0.6 的时候，返回“不确定”而不是硬给一个标签。这个设计在演示时特别有用，你可以主动输入一条反讽评论，系统返回“不确定”，然后你解释“这是模型的诚实，宁可弃权也不误导”，评委印象分直接上去。阈值怎么定？在验证集上扫一遍，找使“置信样本上的准确率”和“弃权率”达到平衡的点，我一般要求置信样本准确率不低于 0.93，弃权率控制在 10% 以内。

缓存也顺手加上。电商评论里重复文本不少，用 Redis 存“文本哈希 → 预测结果”，命中就直接返回。真实场景命中率能到 10% 到 20%，演示场景基本用不上，但架构上有这一层，面试和答辩时讲出来都是加分点。

5.2 前端交互与可视化怎么设计

前端如果只做一个输入框加一个结果标签，视觉上太单薄。加三个东西立刻不一样：情感分布饼图、概率条形图、关键词高亮。

关键词高亮的技术路线有两条。简单的是用注意力权重，取最后一层[CLS]对其他 token 的注意力，归一化后取 top-3，把对应位置的原文片段高亮出来。这个方法几乎零成本，虽然注意力权重不等于“模型真正的依据”，但作为展示已经足够。严谨一点的用基于梯度的方法或者遮挡法（把某个词遮掉看概率变化多少），计算成本高一些，但可以写进论文作为“可解释性分析”的章节。我建议注意力权重做实时展示，遮挡法做成离线分析，两条都用上。

看板部分用 ECharts 画两三个图就够：一周情感趋势折线图、品类情感分布堆叠柱状图、差评关键词词云。数据从/stats接口拿，数据源可以预先灌一批演示数据进去，保证断网时也有图可看。

UI 别追求花哨，配色统一、留白足够、字号够大就行。答辩投影仪的分辨率通常不高，小字根本看不清，正文至少 16px 起。

5.3 数据库设计与部署方案

数据库表不用多，四张表撑起整个系统。

评论原表存原始采集的评论文本、商品 ID、时间、品类，字段尽量少，原样保存就好。标注表存评论 ID、情感标签、标注人、标注时间、以及是否经过二次校验。预测记录表存每次接口调用的文本、返回标签、置信度、调用来源（单条还是批量）、耗时，这张表用来做统计和后续的模型迭代分析。模型版本表存每次训练产出的模型路径、评估指标、训练时间、超参配置，方便回溯。

部署方案给两套。开发环境直接本地跑，模型加载到内存，SQLite 存数据，Streamlit 起前端。演示环境用 Docker 打成镜像，把模型权重和依赖全部打进去，到现场docker run一条命令起来，不依赖网络，这个是最保险的。如果不想用 Docker，就提前把虚拟环境整个打包，注意别把无关的大文件塞进去，否则镜像几个 G，拷 U 盘都费劲。

提示：答辩前一定要在目标机器上完整走一遍“开机 → 启动服务 → 演示 → 关闭”的流程，至少两次。我见过太多在开发机上跑得好好的，换到答辩教室因为端口占用、防火墙拦截、或者路径写死成绝对路径而启动失败的例子。

6. 常见问题排查实录与避坑清单

6.1 训练阶段的典型故障速查

下面这张表是我这些年攒下来的高频问题清单，基本覆盖了训练阶段八成以上的坑。

关于随机种子，补充一句：只固定torch.manual_seed是不够的，numpy.random.seed、random.seed、以及 CUDA 的确定性开关都要设，还有 DataLoader 的worker_init_fn。这一套设下来，两次训练的差异能压到 0.2 个点以内。

6.2 推理与展示阶段的坑

服务层的坑和训练层完全不是一回事，训练层看指标，服务层看稳定性。

最常见的三个问题。第一是模型加载慢，每次请求都重新加载权重，那肯定卡。正确做法是在服务启动时加载一次到全局变量，lifespan事件里做初始化。第二是长文本处理，用户粘了一大段两千字的评论进来，直接截断会丢信息，正确做法是先按句号切分，分段预测后按置信度加权融合，或者取各段概率的平均，这个细节写进论文是个不错的工程贡献点。第三是并发问题，深度学习模型在多线程下不一定安全，FastAPI 的同步接口会阻塞，要么用异步加线程池，要么在模型推理外面加锁，简单粗暴但有效。

前端侧的问题主要是编码。中文文本从前端传到后端，如果没设 UTF-8，可能出现乱码。请求头里明确指定Content-Type: application/json; charset=utf-8，数据库连接串里也加上字符集参数，两头都设好就不会出问题。

6.3 答辩演示的保命清单

这部分完全是经验之谈，属于“文档里不会写但真的会翻车”的范畴。

演示前一定要准备一份离线兜底数据，把五到十条典型评论的预测结果提前跑好存成 JSON，万一接口挂了，前端直接读本地文件展示，至少能讲完流程。准备一条反讽评论和一条中性评论作为“亮点演示”，这两类最能体现模型的难度和你对问题的理解。别在现场输入太长的文本，打字慢、容易出错、还占时间。如果评委问“准确率多少”，报 macro-F1 而不是准确率，并且主动说明测试集的构建方式（按商品分组划分、人工二次校验），这个回答的专业度远超单纯报一个数字。

还有一个小细节：把训练曲线的截图、混淆矩阵、消融实验表格提前放在 PPT 里或者单独准备一页附录。评委问到“你怎么证明这个改进有效”，直接翻页展示，比现场解释有说服力得多。

7. 还能往哪些方向继续做

7.1 三个值得深挖的扩展方向

如果这套系统做完还有时间，或者想为读研做准备，有三个方向可以继续推。

第一个是方面级情感分析。现在系统判断的是整条评论的情感，但真实评论往往是混合的——“屏幕很赞，电池太差”，整条判中性就丢了信息。方面级任务要把评论拆成“方面词 + 对应情感”，比如“屏幕→正面”“电池→负面”。这个任务的标注成本高很多，但学术价值也高，是情感分析领域的主流方向之一。

第二个是跨域迁移。在数码品类上训练的模型，直接用到食品品类会掉多少？能不能用少量目标域样本做微调，把效果拉回来？这个实验设计简单，结论有意思，特别适合作为论文的讨论章节。做法是：源域全量训练，目标域只用 10%、20%、50% 的样本微调，画一条“目标域样本量 vs 效果”的曲线。

第三个是主动学习。标注成本是这套系统最大的瓶颈，主动学习的思路是让模型自己挑出“最不确定”的样本送人工标注，用更少的标注量达到同样的效果。实现上就是每轮训练后对未标注池做预测，按置信度排序取最低的一批，标注后加入训练集，循环几轮。这个方向工程量适中，效果可量化，很适合作为毕设的进阶内容。

7.2 论文里怎么把结果讲清楚

最后聊点写作层面的事。技术做得再好，写不清楚也吃亏。

结果章节的结构我建议这样组织：先给整体指标表（三条路线的准确率、macro-F1、各类别 P/R），再给混淆矩阵，然后是消融实验表，最后是错误分析。这四块按顺序排下来，逻辑是“我做到了什么 → 错在哪 → 每个设计贡献多少 → 为什么错”，层层递进。

图表一定要自己画，别直接截框架自带的输出。训练曲线用 matplotlib 画，加上图注说明横纵轴含义；混淆矩阵用热力图，标上数值；消融表用三线表，每行一个配置，列是各项指标。这些细节体现的是工程素养，评委看得出来。

还有一点：把你踩过的坑写进“实验过程中的问题与解决”小节。比如数据泄漏是怎么发现的、类别不均衡是怎么处理的、置信度阈值是怎么定的。这部分内容别人抄不走，而且是最能体现你真做过的东西。

我个人在做这类系统时最大的体会是：模型的效果上限在数据阶段就定死了，后面调参能挪动的空间其实很小。所以每次有人问我“为什么我的模型只有 80 分”，我第一反应不是看他的网络结构，而是让他把训练数据随机抽二十条贴出来看看。十次里有六七次，问题就摆在那二十条里——标签错了、文本是广告、或者是刷单模板。把数据这关守住，剩下的都是水到渠成的事。