从零开始做AI工程：评论情感分析与要点抽取系统-育师

“从零开始做 AI 工程”这几年一直是个容易被低估、也容易被误解的方向。很多人以为“从零”是让一个完全没写过代码的人从 Python 语法开始学，也有人以为“从零”是把 PyTorch 里每个算子都手写一遍。我比较认同的“from scratch”，指的是不带黑盒心态地把一个 AI 系统完整地做出来——数据怎么来、模型怎么训、指标怎么评、服务怎么上、跑挂了怎么查，每一个环节都亲自过一遍，不靠拖拽工具糊弄，也不靠“调通一个 demo 就算会了”来自我满足。

这篇文章会把我的个人经历整理成一条可复制的路线，围绕一个真实的里程碑项目展开：从零构建一个“用户评论情感分析 + 要点抽取”的文本系统。我会把整体设计、技术选型、关键代码、评估方法、部署经验、踩坑记录全部拆开讲，每个决策都说明当时的取舍逻辑。适合三类人看：一是刚入行想建立完整 AI 工程认知的初学者；二是已经在做模型训练但总觉得“工程味”不够的算法工程师；三是想在自己业务里落地模型但不知道从哪下手的开发者。内容里没有拼凑的噱头，都是实测下来比较稳的做法。

1. 从零拆解：AI 工程这件事到底在做什么

1.1 “从零”的边界线：不是重造轮子，是拆开轮子看结构

我见过不少初学者把“从零开始”理解成“所有东西都自己写”，结果陷在矩阵求导、损失函数推导、甚至自己实现一个 Tensor 类里面半年出不来。这种精神值得尊重，但对工程能力的实际提升非常有限。

我自己划的边界线是这样的：算法原理要能说清楚“为什么”，工程实现则优先站在成熟开源工具的肩膀上。比如做情感分析，你要知道 word embedding 为什么能表达语义，知道 Transformer 的 attention 是怎么让模型关注关键位置的，这两个原理讲不明白就不能算“会”；但实际训练时不需要自己去写 attention 前向传播，直接用 PyTorch 生态里现成的模块就行。

这就像学做饭。你要理解“为什么炖肉要小火慢热”——温度太高会让蛋白质骤然收缩、肉质变柴，这个原理必须懂；但你不需要从打铁开始自己做一口锅。用现成的好锅，把原理研究透，做出来的菜才是工程意义上的成功。

1.2 AI 工程和算法研究、传统软件开发的本质区别

很多人做 AI 工程翻车，是因为拿传统软件开发的习惯来套。传统软件的逻辑是“规则固定、输入输出确定”，你写一个排序接口，测试用例过了就是过了。AI 工程不一样，它的核心是数据分布和概率模型，输出天生带不确定性。

具体区别体现在三个地方：

质量评估方式不同：传统软件看功能是否按规格实现，AI 系统要看准确率、召回率、F1、线上指标，而且指标的好坏还依赖数据分布。
故障排查路径不同：传统软件报错看堆栈，AI 系统表现差可能是数据问题、特征问题、模型结构问题、评估方式问题，四者互相纠缠。
迭代模式不同：传统软件改一个模块影响局部，AI 系统改训练数据可能让全部行为都变，需要完整的实验追踪机制。

这三个差异决定了 AI 工程除了“写代码”这个基本盘，还得具备实验设计能力、数据敏感性、评估判断力。这也是为什么我要用“项目制”来讲解，而不是单纯罗列知识点，项目能把所有环节串起来，串起来你才能真正建立系统思维。

1.3 我实际使用的三阶段落地架构

从零到一，我习惯把整个系统拆成三层，每一层职责清晰，又通过约定接口衔接，这条路线实测下来最稳定，也好排查问题。

数据层负责所有数据相关操作，包括采集、清洗、标注、增强、划分数据集。这一层的关键产出不是“最终的数据文件”，而是可复现的数据构建流程。你随手用 pandas 处理完存一个 CSV 出来，三个月后想复现就懵了——这个字段当时怎么映射的？空值怎么处理的？所以我把数据清洗逻辑写成模块，每一步都留痕迹，输入原始数据，输出标准格式。

模型层负责特征表示、模型训练、评估、调优。这里最容易掉进去的坑是过早追求复杂模型。我给自己定了一条规矩：先跑通一个最简单的基线（比如词频 + 逻辑回归），再上复杂模型（比如微调 Transformer）。基线的作用不只是给个底分，它还能帮你验证数据管道通不通、评估逻辑对不对。项目到后期，基线模型还可以作为线上降级兜底方案，这是意外收获。

服务层负责把训练好的模型包装成可调用的服务，处理请求校验、推理、监控、日志、模型版本管理。很多算法出身的人模型训练完就交付一个 notebook，这在实际业务里是没法用的。服务层补的正是这最后一公里，同时也是 AI 工程里最容易被低估的部分。

这三个层面会在后文的里程碑项目里完整展开。关于工具选型，我先把结果放在前面：项目全程用 Python + PyTorch + HuggingFace Transformers，服务端用 FastAPI，实验记录用 MLflow，测试用 pytest。这个组合不是唯一的，但对我来说是学习曲线和工程效率最均衡的一套。

2. 开工前必须补齐的底层能力：哪些先学，哪些够用就行

2.1 数学知识别贪多：抓住三条主线就好

真正做 AI 工程时不会有人让你手算矩阵求逆，但数学直觉必须有，否则你会理解不了很多模型的“为什么”。

第一是线性代数，最核心的直觉是“矩阵乘法 = 同时进行批量变换”。一批文本经过 embedding 层后变成一个 shape 为 [batch_size, seq_len, hidden_size] 的张量，后续全是批量矩阵运算。你不需要记一大堆公式，但要能看懂@运算符在不同维度下是怎么缩并的，否则 debug 张量 shape 会非常难受。

第二是概率统计，你要理解的不是各种分布表，而是“模型在估计什么”。以分类任务为例，softmax 输出的本质是条件概率分布 P(类别 | 输入)，损失函数则是预测分布与真实分布的差异度量。有了这个视角，你会很容易看懂为什么用交叉熵、为什么做类别加权，后续做模型校准也不会觉得难理解。

第三是微积分里的链式法则，也就是反向传播的基础。这个只需要一点敬畏：训练时每一层参数能更新，是因为误差信号一层层传导回去，更新幅度由梯度决定。理解到这个程度，遇到“梯度消失导致的训练不动”时，你至少知道去检查哪几层激活值的变化。

数学学习的时间节奏上，我这个过来人的建议是：开工第一周把一个简版线性回归用 PyTorch 手写出来，包括数据和模型的定义、训练循环、学习率调整、可视化 loss 曲线——这个过程能把三条主线里的知识全部激活一次，比刷三个月视频课有效得多。

2.2 编程能力：Python 基础工程化，而不是只学语法

模型训练的代码写起来很容易产生“能跑就行”的心态，但这恰恰是工程化项目的头号杀手。我接触过太多训练脚本跑一次就没法复现的情况：随机种子没固定、依赖版本不确定、中间结果没有落盘、代码里到处是魔法数字。

从零开始做 AI 工程，编程基础至少要有这些：

Python 类型注解：函数的输入输出标清楚类型，接口边界清晰，后面重构和排查都会轻松。
异常处理与日志：不能只让程序崩溃时打印一个红字，要主动在关键节点记录日志，包括数据量、耗时、loss 这类信息。
配置管理：不把超参数写在代码里写死，优先通过配置文件或命令行参数传入。我用dataclasses把配置集中管理。
Git 使用：每个实验都要能回滚。你现在觉得“先不提交，等跑通了再推”，3 个实验后你就再也推不了了。
基础设计模式：不用背概念，但“数据类与逻辑类分离”“训练函数与模型定义分离”“尽量小函数、好命名、单职责”这些朴素原则要记住。

编程这东西“行胜于言”，一次训练脚本的重构，比读十本代码整洁之道都能学到更多。

2.3 框架选型的逻辑：为什么我选 PyTorch 而不是 TensorFlow 或纯 API 调用

我做这个项目之前特意比较了几个方向。现成 API 调用（像直接调大模型接口）的优点是快速，短短几十行代码就能有不错的效果；缺点是整个链路被封装成黑盒，你得不到训练和调参的经验，而“调参手感”恰恰是 AI 工程能力里很核心的一部分。所以项目主线我放弃了纯 API 调用，最多拿它做辅助对比。

TensorFlow 和 PyTorch 之间，我选了 PyTorch，核心原因是它的动态计算图和调试体验更直观——你可以像写普通 Python 逻辑一样去开发和调试模型，打印中间张量也很容易，这对学习阶段差异很大。PyTorch 生态里的 HuggingFace Transformers 也集成得很自然，加载预训练模型、微调、部署的体验都更顺滑。

是不是必须用深度学习呢？也不一定。在里程碑项目的第一个版本里，我故意先用了 scikit-learn 的TfidfVectorizer + LogisticRegression，把整条管道跑通，之后再切换到 PyTorch 微调 BERT。用最少的技术负担先完成闭环，再逐步引入复杂工具，这条原则在 AI 工程里比什么技巧都更有用。

2.4 算力与硬件的现实选择

我要先破除一个常见误解：“做 AI 工程必须有好显卡。”实际上，根据你做的任务和模型大小，完全有不同的需求：

基线模型（TF-IDF 逻辑回归）：普通笔记本 CPU 就能在几分钟内完成训练。
微调小型 Transformer（如 DistilBERT）：如果只用 CPU，训练一轮要几十分钟甚至更久，还是建议用一张消费级 GPU，显存 8GB 以上就行。
微调/训练大模型：本地基本不合适，合理的是用云 GPU 实例，按小时计费。

我在这个项目里用了一张本地 12GB 显存的显卡，微调 DistilBERT 这类模型非常够用。策略上有两个建议：第一，先用 CPU 跑一个极小的数据子集（比如 100 条）验证代码逻辑没问题，再上 GPU 跑全量，能省下大量试错成本；第二，控制 epoch 数，不要盲目训练很久，配合早停机制来避免过拟合。

3. 里程碑项目实战：从零构建“评论分析与知识点提取”系统

3.1 目标定义与数据设计：给一个模糊想法画成可以执行的边界

我现在拿一个业务场景来做项目：你有一个电商或者内容平台，用户会写商品评论，比如“屏幕很清晰但电池不耐用”，你想要一个系统能自动判断评论的整体情感倾向，并且抽取评论里强调的要点（比如“屏幕”“电池”），方便后续做数据分析和商家反馈。

这个目标需要定义的边界点非常多，我踩过坑之后总结出要提前回答三个问题：

类别定义：情感到底分几类？两分类（正面、负面）还是三分类（加一个中性）？我选了正面、负面、中性三分类，因为真实评论里“还行”“一般”这类表述很多，硬分两类会积累大量低置信度样本。
要点抽取的定义：要点是连续短文还是关键词集合？长度和颗粒度各是多少？对第一版，我定义为从评论中抽出一到多个名词/短语形式的要点关键词。简化了问题，也方便和商家做反馈。
数据量级：工程毕业后想让它能在真实场景勉强用，最少需要多少条标注数据？我的经验是，三分类情感至少 2000~5000 条，要点抽取如果只用规则方法，有几百条验证集就可以把问题跑通。

从零开始没有现成数据，我用公开的中文评论数据集进行采样，并做了数据增强（如同义词替换、模拟常见口语表达）。这里必须强调：无论数据从哪里来，清洗逻辑和标签规范一定要写清楚，不然后面模型效果变差你都分不清是模型问题还是数据问题。

3.2 数据清洗与特征工程的三个关键处理

文本数据不像表格数据那么规整，拿到原始评论文本后我通常做这几步：

噪声清理：HTML 标签、网址、特殊符号、Emoji 等是否保留需要按场景决定。对商品评论来说，Emoji 可能是情感信号（比如“东西好，推荐😄”），所以我单独抽取 Emoji 作为一种特征而不是粗暴删掉；纯广告文本、乱码和重复内容则直接过滤。
文本标准化：中文场景主要是繁体转简体、正则化空格和标点；英文场景则统一小写、考虑词形还原。
长度策略（很重要）：Transformer 有输入长度上限。评论一般不超过 128 个 token，但如果碰上长评，直接截断会丢掉情感信息。我的策略是同时存原文截断和摘要截断两种版本，分别做实验选效果更稳的。

特征工程方面，我第二版还用了一种方法：用户情感倾向 + 服务端统计特征。比如同一个用户过去写过大量中差评，那么他当前评论的初始偏向可能偏负面。这类特征在纯文本模型里是不存在的，但在真实系统中很有价值。工程项目的落地点未必都在模型结构里，把特征面拓宽往往收益更大。

3.3 模型选择的对比实验：基线先行，再上微调

项目里我就同一个数据集跑了三条路线，把它们的结果摆在一起看这种做法让我特别受益，既能确定最终方案，又能在解释为什么选它时更专业。

第一个模型是TF-IDF + 逻辑回归，它是整个项目的地基。它假设文本的类别含义主要通过词频权重体现，优点是训练快、可解释性强、几乎不挑硬件。缺点是模型没有词序信息，“我觉得不好”和“我觉得很好”在词向量层面只有一个词不同，语义差别有限。

第二个模型是使用冻结的预训练句向量（如 sentence-transformers）把评论编码成向量，再套一个简单的分类头。好处是语义理解能力比 TF-IDF 强很多，因为预训练模型见过大量语料里的搭配和语境；但不是端到端优化，句向量本身并不是专门为下游评论分类这个“任务”调优的。

第三个模型是微调DistilBERT，也就是让预训练语言模型的参数跟着你的分类目标任务继续更新。这通常能拿到三者最高准确率，因为模型的所有表示都在为情感分类服务；劣势是训练资源和部署体积更大，显存要求更高，线上推理延迟也高。

我实验后得到的结果很符合典型预期：基线 F1 约 0.82，句子向量 + 分类头约 0.86，微调 DistilBERT 约 0.91。但真正值得注意的发现是：在只有 2000 条训练数据的小规模条件下，微调模型提升并没有飞越式差距，而且基线的错误模式更好解释——这让基线模型作为兜底方案的价值更突出了。如果你的业务场景条件有限，基线的上限其实不低。

3.4 训练流程中的评价与误差分析：指标不是越低越好

把模型从 notebook 里搬到工程流程中，最重要的习惯是：从训练第一步就写全评估体系。我做的评估不只看准确率，因为类别不均衡时准确率会骗人，比如数据里 80% 是正面评论，模型全预测正面就有 80% 的准确率——这个模型显然不能用。

我用到的评估工具：

混淆矩阵：看模型到底是把负面误认为中性，还是把中性误认为正面。不同业务对这两种错误容忍度完全不同，比如“误伤差评”对卖家的伤害远大于“漏判差评”。
F1 和 PR 曲线：适合不均衡类别，比准确率可靠。
置信度校准检查：模型说“90% 置信是正面”的时候，它的正确率真的接近 90% 吗？如果不接近，说明校准有问题，后面做阈值决策时会出现偏离。

误差分析这个习惯让我收获很大。我印象很深的一次：模型把“包装太次了，但产品本身还行”预测为负面，乍看好像没错，但标签其实是“产品正面 + 物流负面”的混合情感。这种复杂性单标签任务根本表达不了。这次训练提醒我，真实业务里情感常是多维的，之后再做系统时就应该把它建模成多个二分类标签而不是单一三分类。这类洞察只有在你亲自做误差分析、逐条看失败样本时才会获得。

4. 让模型变成可用系统：推理服务、配置、测试、部署

4.1 从训练脚本到推理接口：FastAPI 封装模型的完整思路

模型训完不算结束，真正的新手分水岭在于“能不能把它变成别人会调用的服务”。我选择了 FastAPI，因为它生态完善、性能好、自带请求参数校验和在线文档，把这些配齐大约只需要几十行代码。

一个核心问题是：不要在接口里每次都重新加载模型。我一开始犯过这个错，每个请求打进来都from_pretrained一次，延迟高达十几秒，直接没法用。正确做法是进程启动时做一个全局加载，让模型常驻内存，每次请求只在它上面做推理。修改后单次推理从秒级降到几十毫秒级。

我把接口设计成了后边这种风格：

在实际代码里，我会把模型封装成一个类，对外只暴露predict(text)方法。接口层负责安全校验、日志埋点、调用模型、组织返回格式。接口层和模型层彻底隔离，这是保持系统可维护的长期竞争优势。还有一件事不能省：把所有输入做了长度限制和空值处理，避免超大文本输入把服务内存打爆。

4.2 配置管理与模型版本：没有版本号的人工智能服务就是“薛定谔的模型”

项目初期，我的实验简直一团乱：跑了一个模型 v1，觉得不满意，改了数据重新训练，代码和权重文件混杂在同一个目录，“这就仿佛永远在 p 未完”。后来我彻底做了整改，核心就是三件事：

配置集中化：把模型路径、标签映射、推理超参数、日志级别全部放到统一的配置类或 YAML 文件里，程序入口读取后灌入各个模块。
模型版本记录：给模型文件命名时带上版本号和训练日期，比如distilbert_sentiment_v3_20240512.bin。服务返回的响应里也带上模型版本字段，线上排查时一眼能看到当前是哪个模型在跑。
实验追踪：训练时的超参、数据 hash、评估指标同步记录到 MLflow 或一个规范化的 CVS 目录。虽然没有很好的全流程工具也能往前走，但当你需要复盘“那个 F1 0.90 是用什么配置跑出来的”时，记录是唯一依靠。

4.3 测试不止是代码逻辑：给模型行为也建立回归测试

代码的单元测试大家都会写，AI 工程同样需要，但要注意的是：对模型行为的测试是更重要的健康检查。

我给这个系统建立了几套测试：

接口测试：请求格式对不对、极端输入是否返回正常错误码。比如空字符串、纯标点、超长文本。
数据管道回归测试：抽样数据集固定一批，跑一遍清洗后，主要字段的统计特征应该和预期一致。这一步能快速发现数据格式改动带来的隐患。
模型核心行为测试：准备一组人工设计的典型案例，断言预测结果应当符合预期。比如模型在看到“客服态度非常不好”时，不能预测成正面。

我一直强调要避免一个认知误区：“测试不是发布前的炫耀，而是在你后续持续修改数据与模型时，保护此前成果的安全网。”没有这个安全网，每次改动模型都可能炸出你不理解何处的非线性问题。

4.4 部署与性能优化：容器化、日志、监控一条龙

部署环节我选择 Docker，主要理由是可移植性和环境一致性——“在我的机器上能跑”这句话在 Docker 时代应该变成“在任何装了 Docker 的机器上都能跑”。Dockerfile 里除了复制代码和模型文件，还要做得比较克制：不把训练脚本、原始数据集这些大文件打进去，镜像尺寸能减半就减半。

关于推理性能，我实际用到且有效的方案有三个：

批量推理：接口层把同一批短时间到达的请求合并，模型一次处理多条文本，充分利用 GPU 并行能力。批量越大不一定越快，需要压测找到最优 batch。
缓存机制：用 Redis 做结果缓存，按文本哈希做 key，同一句评论反复请求时直接走缓存。这在评论区批量分析的场景命中率特别高。
模型量化：把模型从 FP16 压缩到 INT8 能降低显存和延迟。我用纯 PyTorch 的量化 API，一两行代码就能接入，测试集上的效果损失只有 0.5% 左右，换来约 1 倍推理速度提升，这笔交易很划算。

监控的底线是三样：推理延迟、请求错误率、输入长度分布。延迟突增可能是模型被极端输入打慢了，错误率攀升可能是依赖服务故障，输入长度分布偏移则提示你可能要面对线上数据与训练数据分布的差异。AI 系统最怕的不是“模型效果差”，而是“你不知道它现在处于状态异常里还照样对外服务”。

5. 这一路遇到的坑：踩坑记录与排查经验沉淀

5.1 新手最容易翻车的高频问题一览

我在整个项目从零到一过程中反复踩过一些坑，下面这个表是我整理出来频率最高的几类问题，每条都附上了排查思路和对应解法。

5.2 一个让我印象深刻的排查实例：模型的“聪明”反而暴露了系统缺陷

项目做完第一版评估后，我在抽检时发现一个很有趣的“错误”：模型把“物流太慢了，客服也不回消息，真的受不了”预测为负面，标签也是负面，看起来没错。但当我把它当作要点抽取的结果时，系统抽到的要点是“物流”和“客服”，这其实没问题。问题出在另一条评论上：“东西还行，就是快递盒有点破了，希望改进包装。”模型预测为中性，但商家真正该知道的是“包装破损”这个负面要点。

更妙的是，我原本以为是模型不够好，做后继分析才发现是标注规范的问题——我把“要点抽取”设计成了“抽情感倾向点”，但并没有明确要抽取“问题点”，这样模型在训练时学到的是“中性评论不用抽要点”，导致有负面细节的中性评论被漏报。这类问题在数据标注阶段就要定义清楚，单纯拼命调模型结构无法彻底修复。这给我的启发是：当你觉得模型表现费解，先回头检查是不是问题定义、数据标注或分类法本身产生了不一致。

5.3 让记录成为习惯：实验日志到底该记什么

每次训练都有大量细节：数据规模、预训练模型版本、学习率、batch size、训练时长、评估指标、失败样本案例。这些信息如果只留在交互式终端窗口里，基本就找不回来了有一天你会发现你根本没法证明当前线上模型是拿哪一版数据训出来的。

我自己的日志模板通常包含这些字段：实验编号、目标描述、代码版本 commit 号、数据文件 hash、配置文件的完整快照、训练的评估指标、测试集误差抽样切片、部署时间与上线后观察记录。写日志的动作本身不复杂，难的是长期坚持，我一般把整段写成一个experiment_notes.md文件放在项目根目录，训练启动前先把这个文件更新掉，顺手推一次 Git，形成条件反射。

6. 长期视角：从零到一之后，如何持续沉淀与进阶

6.1 建立自己的“工程手册”：知识结构化的价值远远超过收藏夹

很多人的学习模式是“收藏一堆文章、攒一堆 demo，但没组成系统”。从零到一做完一个项目，你会有一个非常好的时间窗口：趁所有细节还新鲜，把整个过程写成你自己的工程手册——不是博客的科普文章，而是写给三个月后的自己看的复盘笔记。

我在手册里留这几个板块：整体架构图与模块边界、关键配置及启动命令、数据规范的 ddl 定义、踩坑记录与解决代码、每次迭代的指标进度和原因分析。这个手册后续对我的价值，比任何一次训练都大，它让“我做过一遍”变成“我具备可复现和可迭代的能力”，这就是从量变到质变的分界线。

6.2 衡量“把 AI 工程做明白”的几个信号

有时候你很难判断自己是不是真的入门了。“会调 api”“跑过一个教程”这些都不太可靠，我更愿意用这些信号来衡量一个学习者或工程师的成熟度：

能定位问题层次：一条预测结果不对，你能否迅速判断它是数据标注造成的、特征工程造成的，还是模型结构、推理参数、部署环境造成的。
能设计对照实验：改动一个模块时，准备好逻辑参照组和指标基线，而不是凭感觉说“好像变好了”。
能解释失败：你不仅知道模型现在得分多少，还能解释它为什么在这类样本上失败，以及用什么手段可以缓解。
能在资源受限下取舍：如何在数据不足、算力有限、时间紧的情况下合理降级，先跑出能用的版本，而不是眼高手低等一个完美模型。

这些信号不是知识堆出来的，而是“做项目 + 复盘 + 再迭代”三件套反复循环后自然养成的素养。

6.3 最后分享两点我个人的下饭心得

第一点，不要用大模型 API 替代学习过程。做工程项目的核心目的不是得到一个最优效果，而是通过亲手实现掌握全链路的判断力。你可以用 API 做最后的效果对比，但绝不能在第一次项目里就直接用现成接口绕过训练。

第二点，AI 工程这个方向永远会有新技术冒出来。如果每一次都从“零”开始重新学，人会很疲惫且低效。我的做法是把“不变能力”做厚——数据判断力、评估设计力、系统工程力、排错拆解力，这些能力一旦建立，无论未来模型变成什么样，你都能快速迁移和适应。从零开始最重要的成果，不是某个模型得分很高，而是你把“从零到一完整做出来”这套肌肉记忆刻进了日常工作里。