1. 为什么我决定从零开始啃下AI工程大概半年前我意识到一个很尴尬的事实自己虽然能跑通各种开源模型的demo也能照着教程调通几个分类任务但一旦脱离现成脚本面对一个真实的业务问题——数据是乱的、样本是偏的、线上环境要响应时间、模型要持续更新——我就完全没法体系化地处理。换句话说我缺的并不是某个API的用法而是从数据处理到模型落地这一整条链路的工程能力。市面上讲概念、讲算法原理的文章太多了但真正把一件事从头做到尾、把每个环节的取舍讲清楚的完整记录反而少见。所以我才启动了ai-engineering-from-scratch这个自学项目不预设自己有任何AI基础从最底层的环境搭建开始一个项目一个项目地做每完成一步就记录一次最终目标是能独立交付一个可调用的AI服务。这个项目适合谁参考首先是和我一样能跑demo但没系统做过工程化的人其次是刚入行、想把学习的起点放在真实需求而非算法推导上的新人还有一部分是想要转型AI应用的工程师你可以把它当作一份带避坑指南的实操地图来用。这篇文章是项目前两个月的复盘覆盖了从环境选型到第一个可用服务的全部关键节点我会把踩坑过程和决策逻辑都写出来纯理论的东西尽量少讲。先说一个总体的判断从零开始学AI工程最大的门槛不是数学、不是模型结构而是信息碎片化导致的不知道该先干什么。如果你也卡在这一步这篇文章应该能帮你把路线捋顺。2. 从零起步技术栈选型背后的取舍逻辑2.1 语言与核心框架为什么是Python和PyTorch这个其实没什么悬念。Python在AI生态里的统治地位短期不会动摇不管是数据处理的pandas、训练用的PyTorch还是部署用的FastAPI生态成熟度都不是其他语言能比的。但我不是随便选个顺手工具就完事而是刻意用了一套最小依赖原则——每个阶段只引入当前确实要用的库不提前囤积工具。这样做的原因很实际依赖越多环境冲突的概率越高。我见过太多新手一上来就按大而全的教程装了几十个包结果GPU版本不匹配、conda和pip混用导致环境炸掉一天时间全耗在解决依赖上了。我的建议是刚开始只需要四样东西Python 3.10最好用虚拟环境管理PyTorch带CUDA版本的如果你的机器有N卡pandas numpy做数据处理的必备Jupyter Notebook或者VS Code做交互式开发框架选择上我最终选了PyTorch而不是TensorFlow原因有这么几条第一PyTorch的调试体验好报错信息和Python原生异常更接近写错了改起来快第二当前开源模型的主流权重几乎都是PyTorch格式跟着社区走能少踩很多格式转换的坑第三动态图的写法对初学者更友好你可以print任意中间变量不用先编译再执行。TensorFlow当然也成熟但如果只是从零开始做应用型AI工程PyTorch的学习曲线更平滑。2.2 硬件与云端环境训练跑不动怎么办做AI工程绕不开算力问题。我的本机是一块RTX 3060 12GB显卡说实话这配置在2024年属于入门偏下的水平跑轻量级模型够用但要想微调大参数量的模型就捉襟见肘了。所以我在项目里定了一条规则本地只做小规模实验和代码调试真正需要较大算力的训练任务放在云平台上跑。这个决策经历了几轮调整。一开始我试图在本地硬跑一个中型模型结果显存溢出、训练还有一半直接OOM白等了几个小时。后来学聪明了先做两件事一是用torch.cuda.get_device_properties查看实际显存大小二是用NVIDIA的nvidia-smi命令实时监控显存占用搞清楚模型吃多少资源再决定在哪训练。如果你也没有好卡我建议的顺序是先在Colab或Kaggle上跑通完整流程再到本地用小规模参数复现最后才上云GPU按需训练。不要一上来就租贵的实例因为你通常会用大量时间调试代码而大部分调试不需要大显存等代码稳定了再切到高档实例提效更划算。2.3 版本管理和实验记录比代码本身更重要的事这部分算是我从零开始理念里比较特别的一环。很多人学AI只关注模型代码但我从第一个项目开始就强制自己做完三件事用git管理所有代码包括数据处理脚本、训练脚本和部署配置每个实验记录训练参数、数据集版本和评测结果保存每次训练产生的模型权重文件按时间和版本号命名听起来简单但实际做起来很有价值。因为AI项目的迭代规律通常是改一版数据、调一个参数就要重跑一次如果没有完善的记录两三天之后你甚至分不清哪个模型是用哪批数据训出来的。我用的工具组合是git DVC数据版本管理DVC能把数据集和模型权重这类大文件单独管理和代码版本一一对应回滚起来非常方便。踩过一次亏之后我对记录这件事更上心了。那是在做文本分类项目的时候我改了一个数据清洗规则跑出来的效果从0.91掉到0.84但因为没有记录清洗前后的数据差异排查了半天也找不到原因。后来一查发现是清洗规则里一个正则表达式把有效样本误删了三分之一。如果当时有数据版本记录一眼就能定位差异。从那以后我要求自己每个实验都生成一个包含数据摘要、训练配置和评测指标的记录文件这也是这个项目能持续复盘的基础。3. 动手做第一个AI应用需求拆解与工程实现3.1 选择项目场景从业务问题而不是算法出发第一个正式项目我选的是电商评论情感分类服务输入一段用户评论模型输出正面、负面或中性。选题的理由很清楚——数据好找、模型简单、效果可感知同时包含了AI工程的全部核心环节数据获取、清洗、标注、训练、评估、部署上线。这里有个经验值得分享很多人学AI是从我会什么算法出发但我建议反过来从我想解决什么问题出发。因为工程化能力落到本质上就是把业务问题翻译成技术问题的能力。比如情感分类这个需求翻译成技术语言就是给一段不定长文本输出一个三分类概率分布同时要求单次推理延迟在几百毫秒以内。这个翻译过程决定了你后续所有技术选型的方向。数据方面我用的是一个公开的中文电商评论数据集大约十万条样本字段包括评论文本和人工标注的情感标签。选数据集时我刻意关注了几个属性样本量够不够、类别是否均衡、文本有没有经过清洗。很多公开数据集表面光鲜实际上充斥着重复文本、乱码和错误标注所以后续的数据清洗环节是无论如何都跳不过去的。3.2 数据清洗与预处理的具体操作这个环节枯燥但极其重要。我先写了一个统计脚本看数据的整体情况重点检查三件事缺失值、重复项、类别分布。统计结果出来后发现几个问题1.2%的样本文本为空约5%的评论是重复的负面样本明显偏少。处理策略很简单——空文本直接丢弃重复文本看情况保留一条因为如果训练集和验证集里出现同一条评论指标会虚高到失真类别不均衡则暂时不动因为第一个版本的目标是跑通链路等后续再针对均衡性问题做采样调整。文本清洗我用了jieba分词加自定义停用词表。清理对象包括HTML标签、微博话题符号、URL、哈哈哈这类无意义重复字符、表情符号和特殊符号。这里面有个实用技巧清洗规则的顺序会影响结果比如先做标签清理再做分词不然尖括号会导致分词结果混乱。我这个项目里就踩了正则误删的坑后来总结出的准则是——每加一条清洗规则都要对比清洗前后的数据量变化一旦发现异常减少就要立刻检查正则是否写得过宽。预处理完成后把所有文本统一转成数值特征。这里我没有直接用预训练词向量而是先建模了词频统计特征用TF-IDF加一个简单的逻辑回归作为基线。这一步非常值得做它让你先了解数据本身能跑到什么水平后面换成深度学习模型时才能判断提升究竟是模型的功劳还是数据的作用。3.3 模型搭建从线性模型到神经网络基线模型用的是TF-IDF特征加逻辑回归在一万条验证集上的准确率约0.82对短文本效果尚可但遇到带有反讽和转折结构的句子几乎必错。比如这家店的服务态度真是让我大开眼界这种表面正面实则负面的评论线性模型完全无从下手。于是第二步升级为TextCNN这是一个经典的短文本分类模型。用PyTorch实现并不复杂核心结构是Embedding层把每个词映射成向量多个不同尺寸的卷积核提取n-gram特征池化后接全连接分类层。我当时为这个模型写了大概两百行代码训练一轮大约四分钟比逻辑回归慢一个数量级但验证集准确率升到了0.88。我特意对比了两个模型的预测结果把错误样本拎出来逐一分析。发现TextCNN主要的改进在于能抓住但是这类转折词后的情感倾向以及便宜是便宜但质量不行这种复合结构的语序。但仍有一些长文本和强依赖常识的评论判断错误这说明短文本分类模型的表达上限摆在那里后续如果想进一步提升需要换用预训练语言模型。这个从简到繁的过程让我对模型能力边界有了非常实际的认识而不是光看论文上的SOTA数字。3.4 过拟合判断与最简单的正则化方案训练TextCNN的时候我观察到一个典型现象训练集准确率蹭蹭往上涨很快到了0.97但验证集准确率停留在0.84到0.88之间这就是过拟合的明确信号。我试了dropout加早停两个方案分别描述一下效果。dropout就是在全连接层前随机丢弃一部分神经元输出我设了0.5的比例验证集准确率立刻提升到0.87左右。早停则是在验证集指标连续几个epoch不升时提前终止训练避免无效的继续拟合训练集细节。两项措施叠加后模型在训练集和验证集上的差距从十几个百分点缩到六七个点整体泛化能力有明显改善。这里有个容易犯的错就是看到指标不涨就盲目调参、换模型。我见过很多同学把dropout从0.2调到0.8embedding维度从64换到512试图用随机搜索式的调参来撞大运。实际上参数调整应该建立在对错误的定量分析上先确认是过拟合、欠拟合还是数据问题再对症下药。我前前后后调参的经验教训是一个结构没稳定之前不要同时改超过两个变量否则根本说不清是哪个改动带来的提升。4. 数据管道与训练流程工程化的分水岭4.1 为什么所有AI项目都该有统一的数据管道训练出一个像样的模型之后我开始重构代码结构。这算是从能跑到工程化的分水岭。最初的代码是一个巨大的notebook按顺序执行数据加载、清洗、训练、评估跑起来没问题但只要改一个环节就得从头跑一遍浪费时间不说还容易触发隐藏的bug。数据管道的核心思路是把整个流程拆成独立模块每个模块的输入输出都有明确约定。具体来说我建了一个data目录按raw、processed、features三层存放数据raw是原始下载文件processed是清洗后的结构化文件features是模型输入用的特征文件。每一步处理都对应一个独立脚本脚本之间通过文件系统传递数据这样某一环节出错时可以只重跑那一环。实际的收益立竿见影。有一回我调整了停用词表只需要重跑特征生成脚本之后训练和评估脚本自动读取新特征文件全程不到一分钟。如果在notebook时代这意味着从加载原始数据到重新训练全走一遍至少二十分钟起步。4.2 训练脚本设计的三个关键决策训练脚本看起来简单但在工程化过程中有三个决策必须提前定好随机种子固定、checkpoint保存策略、训练日志格式化。固定随机种子是最容易被忽略但影响最大的。PyTorch里CPU和GPU的随机行为分别由两个generator控制在脚本入口设置torch.manual_seed(42)如果是GPU训练还要额外设置torch.cuda.manual_seed_all同时结合numpy和python自带的random模块一起fix才能保证两次训练结果完全可复现。没有这一步你做的A/B测试根本站不住脚因为指标波动可能纯粹来自随机性而并非你的改动。checkpoint保存我采用的是每epoch结束保存最新模型只在指标刷新时覆盖最佳模型这两个文件分别命名为latest.pt和best.pt。刚开始我只保存best模型结果有一次训练到一半机器重启连续十几个小时白跑。有了latest之后哪怕中断也可以从最近的checkpoint恢复。另外每个checkpoint都保存一个包含epoch数、优化器状态和评估指标的字典而不是只存网络权重这样从断点续训的时候才能准确恢复优化器的学习率状态。训练日志我统一成JSON Lines格式每一行是一条Json记录包含当前epoch、loss、accuracy、学习率等字段。同时训练进程结束时自动绘制loss曲线和评估曲线保存成图片。这个习惯帮我快速定位训练异常比如loss不下降、指标突然暴跌、梯度过大这类问题看一眼曲线就能有直觉判断不用逐行找日志。4.3 数据泄漏的隐蔽坑验证集指标为什么虚高训练流程跑顺之后我遇到了一个极具迷惑性的问题验证集准确率高达0.95但拿到线上真实数据一测就掉到0.7。这个落差让我排查了一整天最后定位到的原因是数据泄漏——预处理脚本在生成特征之前对整个数据集做了统一的词表构建而词表包含了验证集样本的词汇分布信息。更隐蔽的是我当时做TF-IDF特征时用的是整个数据集拟合的idf权重这意味着验证集样本信息已经被统计进了特征表示。改进办法是在构建词表和idf权重时只用训练集验证集和测试集在预测阶段套用同样的映射规则。改完之后真实表现和验证集指标的匹配度高了很多。这个坑极其常见也很容易在无意识中犯。处理涉及全局统计的特征变换任务时必须养成先划分数据集、后拟合变换的规范流程。所有基于训练集计算的统计量包括均值和方差、tf-idf权重、归一化参数都必须用训练集算然后原封不动地应用到验证集和测试集。规模化一点的工程里还会把这套逻辑封装在pipeline对象里自动执行避免人工操作遗漏。5. 模型服务化把训练产物变成可调用的API5.1 在线推理模块的架构设计模型在notebook里能跑是一回事能被外部业务系统调用是另一回事。服务化这一步要解决的问题有三类如何加载模型、如何接收请求、如何保证响应性能。我用FastAPI搭了一个轻量级推理服务。为什么会选FastAPI而不是Flask一是FastAPI原生支持异步接口高并发场景下不会被阻塞式请求拖死二是它自带OpenAPI文档页面调试起来非常方便直接把浏览器打开就能测试接口。对一个从零开始的项目来说少写一部分调试工具代码就是实打实的效率提升。推理模块的代码结构分三块模型加载器负责初始化模型和词表预处理模块负责把原始文本转成模型输入预测模块执行前向计算并输出分类结果。加载器在服务启动时只加载一次模型后续所有请求共享这份内存中的模型实例。这一点很关键因为如果每个请求都重新加载一遍模型GPU显存分配和释放的时间就会把延迟拖到不可接受。首次加载时我把模型放在GPU上但做了一下CPU与GPU的切换判断以应对没有显卡的服务器环境。5.2 序列化、批处理与性能实测推理服务的输入输出格式需要统一约定。我的接口定义接收一个JSON对象包含text字段和可选的batch字段输出返回label和每个类别的概率值。在设计输出规范时我把原始文本、预测标签和置信度三个信息都返回给业务方。因为很多下游场景需要拒绝低置信度的预测结果或者根据置信度做不同分支处理。性能方面单条评论的p95延迟约80毫秒批量处理32条时每条的平均延迟降到30毫秒左右。这个提升来自GPU的并行计算特性——当多条样本组成一个batch时矩阵运算的总体吞吐量远高于逐一计算。我在实际部署中做了一个简单的动态批处理机制服务端攒够固定条数或者等待极短时间间隔后统一推理兼顾了延迟和吞吐。有一处踩坑需要提醒对文本做padding到统一长度时我最初的做法是每条样本单独padding到最大长度导致batch内大量无意义的填充计算。后来改成按batch内的最大长度动态补pad算力消耗直接少了约三分之一。这个优化点非常细微但对线上成本的影响却很明显。5.3 容器化部署与版本控制服务写完后的最后一步是部署。我选用了Docker来做容器化主要是因为依赖隔离和可移植性都很有保证。Dockerfile里我用了分层构建操作系统层装Python基础环境依赖层装PyTorch和FastAPI等相关库业务层拷贝模型文件和应用代码。分开层的主要原因在于模型文件改动时不需要重新下载几百兆的依赖包镜像构建速度能快很多。构建好的镜像推送到私有仓库服务器上通过docker run直接启动服务。模型文件本身没有打进镜像里而是挂在宿主机的一个固定路径通过volume映射进容器。这样做的好处是模型更新时只需要替换宿主机文件并重启容器不用重新构建整个镜像。我在这套流程上跑通了开发环境和生产环境的双环境部署本机调试用CPU模式线上服务使用GPU模式两个环境通过环境变量切换代码完全一致。部署上线后我随手用curl测了几个真实接口输入快递第二天就到了包装也很严实输出正面置信度0.93输入等了半个月才发货客服还已读不回输出负面置信度0.97输入价格还行吧就是颜色和图片差挺多输出中性置信度0.54而负面也有0.34第三条这种带犹豫的表达模型能在正面、负面、中性之间较为谨慎地分配概率而不是武断地给出单一结论说明分类器的学习确实有泛化能力而不是死记硬背了几个关键词。6. 复盘推进过程中最该绕开的那些坑6.1 维度错误与CUDA内存溢出整个推进过程中我最常遇到的报错是维度不匹配。比如模型要求输入形状是[batch_size, seq_len, embedding_dim]但你在预处理里漏了embedding维度传进去的就是[batch_size, seq_len]PyTorch直接抛RuntimeError。后来习惯了先用一小批假数据做模型前向传播的调试确认每个tensor的维度符合预期后再跑完整数据集。CUDA内存溢出则是初学者最容易懵的。有一次报错torch.cuda.OutOfMemoryError实际原因并不是模型太大而是我在for循环里反复创建了计算图中的中间张量旧变量没有被释放。PyTorch的默认行为是在backward时保留中间变量用于梯度计算如果你在循环里不断累加新的tensor而没有积累释放机制显存就迅速被打满。解决方案很简单把不必要的中间变量显式del掉并在关键节点调用torch.cuda.empty_cache()同时注意设置torch.no_grad()的推理场景不记录梯度。6.2 盲目调参与指标误读很多人在得到结果后第一反应是提升一点点也行于是开始反复调学习率、batch size、embedding维度。我的经验是与其频繁调参不如先做一次错误归属分析。把预测错的样本分成几类统计各自占比优先针对占比最大的错误类型做改进。比如我的模型长文本错误率高后来发现是因为截断策略太粗暴导致关键语义片段丢失改成分段处理加滑动窗口后指标有了实质提升这比调十倍learning rate都有效。指标误读也出现过。有一次我只看accuracy就以为模型很均衡后来画了混淆矩阵才发现负面类别的召回率只有0.6大量的负面评论都被归到了中性。单看accuracy的0.88确实还行但业务场景里漏掉负面反馈的代价远高于误判一个中性评论。所以后来我在每个模型档案里都放一份分类报告和混淆矩阵而不是只看一个汇总数字。6.3 环境一致性带来的交付保障最后还有一个非技术但极其影响交付质量的坑环境不一致。我在本地训练的模型Put到服务器上之后推理结果和本地完全对不上后来排查发现是CPU训练和GPU训练时浮点数精度累加误差导致的微小差异经过神经网络的非线性传播被放大了。这不是代码bug而是硬件的自然差异但如果你做的是敏感业务比如医疗诊断或金融风控这种差异在关键阈值附近就会造成完全不同的业务处理逻辑。我的应对方案是在部署流程里增加一个验证步骤用一组预置的输入输出对在上线前对比新环境的预测结果和测试环境的基准结果必须完全一致才能放行。这组验证样本的覆盖面要广包括空文本、超长文本、带表情符号的文本、错别字密集的文本确保识别逻辑在边界场景下也没有行为偏差。另外一点是Python包版本管理。我吃过一次pillow库升级导致模型解码结果异常的亏从那以后所有pip依赖都锁版本号放到requirements.txt关键的torch和numpy还额外记录了对应的CUDA版本保证任何环境下都能复现同样的结果。7. 下一步迭代计划与个人的几点体会这个项目目前走到第二个里程碑情感分类服务已经稳定运行并且承载了少量来自朋友业务系统的真实流量。接下来我的迭代主线有三条第一把预训练语言模型接入当前分类流程用BERT类模型替换TextCNN在更长上下文的场景上验证提升幅度第二为数据管道增加更灵活的特征缓存机制让多种模型在同一批特征上做试验时的成本更低第三搭建一个简单的模型监控看板记录线上请求的预测分布和异常率一旦指标漂移可以及时预警。要说个人体会最深刻的一条是AI工程的能力不是学会某个框架或者跑通某个模型而是对整条链路有排错和感知能力。当你面对一个报错时能够快速判断是数据问题、模型问题还是工程问题并顺着线索一步步定位根因这才是真正意义上的工程师素养。我的做法是多做项目、多做记录、多复盘而不是多堆教程。另一个体会是关于学习顺序和学习速度的矛盾。我早期浪费了不少时间在反复快速切换主题上今天学NLP明天学CV看起来进度很快实际上每一项都浅尝辄止。后来定下每个项目至少完整交付一次API服务这个最低标准学习节奏才真正稳定下来。这个标准不高但足够过滤掉大部分伪学习。如果你也在这个方向起步我个人建议你直接复刻一条类似的路径选一个有感知度的业务问题从最笨的线性模型开始一步步做成在线服务然后基于真实反馈迭代模型和代码。这条路没有捷径但每一步都有确切的产出很容易积累起信心而且过程中养成的习惯——比如记录、模块化、验证指标、版本控制——会在后续任何AI相关的工作里持续产生复利。