“ai-engineering-from-scratch”翻译成大白话就是“把AI工程从零开始搭起来”。这个提法听起来有点硬核像编程圈里“手写一个操作系统”那种感觉但本质上它是一种态度不依赖现成的套壳平台亲手把一个AI应用从数据采集、特征处理、模型训练、评估、封装、部署到线上监控完整地跑通闭环。很多想入行的朋友问过我学完了Python刷了不少机器学习教程到了真做项目的时候还是不知道怎么下手。差距往往就出在“工程”这两个字上——模型训练跑通只算完成了20%剩下80%都在数据管理、版本控制、服务封装、性能调优和持续迭代这些不起眼却又绕不开的环节里。这篇文章我就用自己从零搭一个文本情感分析项目的真实过程聊聊AI工程从入门到落地值得关注的那些事适合准备入门或者刚踩进门槛的开发者当路线图读也可以给已经入行但总觉得自己“只会调模型”的朋友做个对照参考。1. 先想清楚AI工程到底在解决什么问题1.1 为什么说AI工程不等于机器学习很多人误会了“AI工程”这个词觉得它就是“训练一个很牛的模型”。这里面的坑我在早期踩得够深。打个比方算法是菜谱工程是餐厅。菜谱写得再好没有稳定的供应链、没有干净的后厨流程、没有上菜速度和顾客反馈体系餐厅照样开不下去。AI工程做的就是“开餐厅”这摊事——把一堆算法实验变成一个能持续提供价值、异常时能预警、新数据来了能更新的服务系统。实际工作里算法模型只占很小的比重。一个典型的AI项目会包含数据管道采集、清洗、标注、校验、训练平台代码、环境、超参数、产物版本、模型服务接口、并发、容灾、降级、观测体系预测监控、数据漂移检测、性能分析、以及再往上一层跟业务系统的结合逻辑。任何一个环节掉链子整个系统都可能跑不起来。第一次训练出一个准召还不错的模型时我兴奋了两小时随后就体会到什么叫“工程的地狱”模型文件动不动几百MB同事那边怎么都复现不了我的效果换了一批数据准确率直接崩掉接口并发一上来服务延迟飙升十倍。这些都不是算法本身出了问题而是工程能力没跟上。搞清楚了这一点你就会明白为什么越来越多的招聘岗位把“AI工程”拆得这么细。1.2 从零开始最值得投入的五个环节结合我的实战经验一个完整的AI工程闭环至少包含以下五个环节。每一项都有对应技能树缺一不可第一数据工程。数据清洗、去重、归一化、样本均衡、标注质量评审。这部分活儿最琐碎但决定模型上限。垃圾进垃圾出在任何领域都不是一句空话。第二训练与调优。包括框架选择、代码结构、超参数搜索、训练稳定性处理、实验记录。这部分是大家最熟悉的但也是最容易“自嗨”的光看loss下降不看评估指标最后常常白忙一场。第三评估与验证。离线指标准确率、F1、AUC等、错误分析、切片评估按类别、按场景细分看效果以及模拟真实分布的压测。很多项目上线出事故都是离线评估没做扎实。第四部署与集成。把模型转成可服务的格式封装成API或批处理任务写好缓存、限流、降级逻辑再用容器或Serverless方式发布出去。第五观测与迭代。上线后监控预测值分布、输入特征分布、业务指标。模型不是一锤子买卖数据漂移一来不更新的模型会悄悄变笨。这五个环节我建议想走AI工程路线的人全部至少亲手做一遍哪怕做的项目很小。这条路走通了后面做任何AI项目都会顺手很多。1.3 什么样的项目适合作为“从零”的第一个项目我觉得不是所有场景都适合拿来做“from scratch”训练。比如一上来就搞大语言模型微调或超大规模推荐系统环境搭建都可能劝退。更适合的是那种数据量可控、评价指标清晰、业务价值直观的任务。我自己选的是中文电商评论情感二分类判断一段评论是正向还是负向。选它有三个原因一是数据集好找公开的标注数据很多网上随便一搜就有几万条二是模型不会太复杂用基于预训练模型的微调比如BERT或轻量级蒸馏模型就能拿到不错的效果但又能真实暴露工程问题三是部署形态典型这个任务天然适合做成HTTP接口能顺带训练容器化、并发处理、监控这三样本事。数据量可以控制在2万条以内本地一张普通显卡就能跑没有显卡用云GPU按时计费也就几十块钱。这种“体量小、链路全”的项目最适合用来建立对AI工程的整体认知。2. 动手前的准备环境与工具选型解析2.1 硬件与软件栈的选择逻辑先聊硬件。很多人第一步就卡在“要不要买块好显卡”。我的建议是初期先别买。做小规模项目和跑通流程CPU就能应付真要训练模型云GPU按时租不心疼还能逼自己养成按需付费的工程习惯。等到你明确自己几个月内都要高频跑训练再考虑本地显卡不迟。我的开发环境非常简单一台没有独立显卡的MacBook加上一个远程Linux服务器带一张消费级显卡PyCharm用来写代码终端跑训练。数据存放在服务器本地代码通过git管理实验产物模型权重、tokenizer、配置文件按日期和版本号归档。整套环境价格不高但足够支撑一条完整链路。软件栈方面Python是AI工程的地基生态无可替代。第二层是深度学习框架第三层是服务框架和运维工具。核心选型如下用途我用的工具备选项备注深度学习框架PyTorchTensorFlow/JAX社区活跃调试直观数据处理Pandas、NumPyPolars量级不大时足够量级大再迁移预训练模型Transformers库框架自带模型库生态好省大量时间API服务FastAPIFlask、Django自带文档、类型校验适合AI服务实验记录MLflowTensorBoard、WB能管参数、指标、模型产物版本管理Git DVC纯GitDVC专门管大文件数据集和模型部署Docker 云服务器容器服务、Serverless先Docker后面再考虑编排别把工具选型看成收集癖够用、顺手、团队能接手比“最新最火”重要得多。2.2 框架之争为什么我推荐PyTorch作为起点在我刚开始做的时候还有前辈推荐TensorFlow。但现在再看PyTorch几乎成了学术和工业界的默认选择我觉得新人从PyTorch入门最不容易走弯路。原因有三条。第一调试体验好。PyTorch的eager execution是“边算边看”打印张量形状、中途断点调试、修改逻辑都很自然。TensorFlow虽然也有eager模式但历史包袱重各种历史接口容易让人困惑。第二生态社区一骑绝尘。现在主流预训练模型、最新论文代码、第三方库基本都是PyTorch优先。少踩一个“别人用的库跟我的框架不兼容”的坑。第三从研究到生产路径短。TorchScript、ONNX导出、TorchServe这些工具链把“研究prototype”变成“生产模型”的成本一降再降。我也不是全盘否定TensorFlow如果你所在的公司长期用它维护老系统那肯定以公司技术栈为准。个人新起项目选PyTorch是更省心的决策尤其适合“从零开始”的学习者。2.3 项目脚手架与依赖管理很多初学者把精力全花在写模型上依赖管理和项目结构一团乱这其实是工程上的大忌。我建议每个AI项目都按一套标准模板起步sentiment_project/ ├── data/ # 数据目录原始数据、处理脚本、最终特征 ├── configs/ # 配置文件超参数、路径、训练参数 ├── scripts/ # 数据处理、训练、评估、部署脚本 ├── src/ # 核心代码模块化 │ ├── data_loader.py │ ├── model.py │ ├── train.py │ └── predict.py ├── models/ # 产出的模型权重、tokenizer ├── tests/ # 单元测试与数据校验脚本 ├── api/ # API服务代码 ├── Dockerfile ├── requirements.txt # 或使用poetry/pipenv └── README.md依赖管理方面不要只扔一个requirements.txt就完事至少要锁版本。我的习惯是项目开始时用虚拟环境隔离再用pip freeze把精确版本写入requirements.txt或者直接用poetry、uv这类工具同时管虚拟环境和依赖解析。这里有个实战经验环境做不到可复现其他都是零。你上周训练出的好结果本周代码一更新就复现不了这种痛苦几乎所有人都会遇到原因八九不离十是版本浮动或环境不一致。养成“记录Python版本、CUDA版本、核心依赖版本”的习惯能帮你省掉非常多排查时间。2.4 数据是怎么“喂”给模型的到这一步很多教程就开始念代码了。但我觉得有必要先把“数据流向”讲清楚这决定了你对后面每一步的理解深度。原始数据比如一堆没处理过的文本需要走完一条流水线才能进模型原始数据 → 清洗 → 标注/整理 → 划分训练、验证、测试集 → 文本预处理分词、去停用词等视任务而定 → 编码转成model输入格式 → 构建DataLoader批量供给模型。任何一步处理逻辑不一致都会导致训练和预测的“数据口径”对不上。比如训练时你删了网址预测时没删模型看到没见过的新模式效果就会波动。所以工程上有一个习惯数据处理函数必须由训练和推理两条路径共用绝不能各写一份。3. 核心实现从数据集到可部署服务3.1 第一步数据清洗与特征工程我的情感分析项目里原始数据是从公开渠道收集来的电商评论大概3万多条。不过直接拿原始数据训练肯定不行——缺头少尾、表情符号、重复文本、无关字符都需要处理。我写的清洗函数长这样注意它是会被训练和推理共用的import re import unicodedata def clean_text(text: str) - str: if not isinstance(text, str): return # 统一Unicode避免全角半角混乱 text unicodedata.normalize(NFKC, text) # 去掉网页URL这类噪声对情感判断没有帮助 text re.sub(rhttp\S|www\.\S, , text) # 去掉提及和话题标签按场景可保留 text re.sub(r\w|#\w#?, , text) # 连续空白压缩 text re.sub(r\s, , text).strip() return text清洗之后还需要做样本去重。我遇到过同一段评论在数据集中出现几十遍的情况如果不处理模型会过拟合这些重复样本导致验证集指标虚高。去重很简单直接对清洗后文本做hash去重就行。下一步就是划分数据集。训练集、验证集、测试集我按8:1:1划分。这里很多人会忽略一个关键点必须保证测试集完全隔离不能参与任何调参和特征工程。我一般把测试集数据单独放文件不到最后评估绝不打开这就是在工程里保住“数据洁癖”。3.2 第二步模型训练与超参数调试模型方面我直接基于预训练的中文BERT变体做微调。全量BERT训练比较慢我用的是一套轻量蒸馏模型大约110M参数对2万条训练数据来说完全够用。代码结构上我会把训练主流程抽象成下面这个样子from transformers import ( AutoTokenizer, AutoModelForSequenceClassification, TrainingArguments, Trainer, ) def build_model(model_name: str, num_labels: int 2): tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForSequenceClassification.from_pretrained( model_name, num_labelsnum_labels ) return tokenizer, model在训练参数设计上我第一个容易犯的错就是一上来把学习率跑得飞快。预训练模型微调的学习率一般是2e-5到5e-5这个量级比从头训练低两三个数量级。如果你从零训练一个模型学习率可能要去到1e-3甚至更高而微调阶段用这么大的学习率几乎必然导致灾难性遗忘——模型把预训练学到的语言知识忘了个精光。我的超参数是这样设的batch_size32用梯度累积凑够等效大batch、learning_rate3e-5、epochs3、warmup_ratio0.1。跑一轮大概3分钟训练加验证不到15分钟。对于这种体量的任务贪心跑几次就够用了不需要上贝叶斯搜索、网格搜索这些重武器。训练阶段一定要记录所有指标不仅看loss还要看验证集F1、精确率、召回率。用MLflow记录的好处是后面想回看不同实验的超参数和指标一条命令就行不用靠脑记文件名。3.3 第三步评估指标到底看什么二分类问题最土也最常见的评估指标就是准确率。但情感分析这种正负样本不平衡的场景准确率经常骗人假设90%是正向评论你什么都不做全预测正向准确率都有90%。所以我更关心F1分数尤其是少数类别的F1。我在项目里还做了一个切片评估把验证集按评论长度、按商品类型切片分别计算指标。为什么要做这一步因为一个模型在平均指标上好看不代表在某个细分场景下不崩。比如模型对长评论识别差但长评论恰恰是投诉风险最高的这种问题你要不切开来根本看不见。在最终评估时我用测试集算了一次最终的F1大概0.93。这个数字对于一个从零搭建的工程来说足够有说服力接下来要考虑的就是怎么把这个模型“卖”给业务方——部署成能调用的服务。3.4 第四步把模型包装成API服务模型训练完只是一个文件不是产品。为了让别人能用我把模型加载进FastAPI服务封装了一个简单的POST接口。一个极简但可用的服务端代码如下from fastapi import FastAPI from pydantic import BaseModel app FastAPI(titlesentiment-analysis) model, tokenizer None, None class ReviewRequest(BaseModel): text: str app.on_event(startup) def load_model(): global model, tokenizer model_path ./models/sentiment_model # 这里用你已经保存好的模型和tokenizer model, tokenizer load_local_model(model_path) app.post(/predict) def predict(req: ReviewRequest): inputs tokenizer( clean_text(req.text), truncationTrue, max_length256, paddingTrue, return_tensorspt, ) logits model(**inputs).logits label int(logits.argmax(-1)[0]) prob float(logits.softmax(-1)[0][label]) return {label: label, prob: round(prob, 4)}这里有几个工程细节值得展开。第一模型加载放到startup钩子里而不是每次请求都加载。否则并发一上来光模型加载就能卡死服务。第二prediction输入必须走同一个clean_text这对应前面说的“数据口径一致”。第三超时和最大长度要限好。我在tokenizer里把max_length设为256超过部分截断。这个操作既保护服务性能也防止长文本把模型跑崩溃。写完之后用uvicorn启动服务。我习惯本地先跑一遍curl一下接口验证能通再进入Docker化环节。3.5 第五步Docker化与上线AI服务上线我最常用的方式是Docker。好处是把Python版本、依赖、模型文件全部锁进一个镜像杜绝“在我电脑上能跑”这种经典问题。Dockerfile写起来也不复杂FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8000 CMD [uvicorn, api.main:app, --host, 0.0.0.0, --port, 8000]镜像构建好后我先把服务在本地跑起来再用curl发几个样例请求验证。没问题就把镜像推送到云服务器的容器环境中映射端口后配置一个最简单的Nginx反向代理再把HTTP改成HTTPS。一套流程下来一个可以对外提供服务的AI接口就上线了。这里有个建议模型文件不要打进镜像尽量从对象存储或模型仓库拉取。这样镜像变小发布更快模型更新也不用重新构建整个镜像。我第一次就把模型装进了镜像一个镜像2G多每次发布都痛苦得不行。4. 工程化落地模型版本管理、CI/CD与监控4.1 模型版本管理与实验记录模型就是一个二进制文件但它同样需要版本管理。传统git存几MB的代码没问题模型动辄几百MB直接推git仓库会被拒绝。现在我的习惯是代码走git数据走DVCData Version Control模型走MLflow或云对象存储。DVC的原理很好理解它不把大文件放进git而是记录文件的哈希值和存储地址git里只保存这些小的元数据文件。别人拉取代码后执行一条dvc pull命令就把对应版本的数据和模型拉回本地。这样就做到了整套环境可复现。MLflow我最常用的三块是Tracking记录参数和指标、Registry管理模型阶段Staging/Production/Archive、以及Model Serving辅助功能。每次训练完我把精确率、F1、AUC、训练配置全部记录进去。回看历史实验时用UI界面或API搜一下比翻流浪的日志文件高效得多。4.2 自动化测试与持续集成——不只是测代码AI项目的CI/CD和传统软件有个重要区别不能只测代码逻辑还要测数据和模型。我在项目里加了三层测试。第一层是数据校验测试。写一个脚本检查数据schema对不对比如text列是否存在、标签值是否只有0和1、数据量是否达到阈值、有没有过度重复。数据一变化CI就跑这套测试防止脏数据悄悄流进训练管道。第二层是模型输出测试。不追求全量验证而是准备一组固定的冒烟样本每个样本的预测结果作为一个pytest断言比如一句明显表达不满的评论模型必须输出负向。这样可以及时发现模型退化。第三层是服务接口测试。模拟调用API检查响应格式、状态码、时延是否在预期内。接口改了没改坏第一时间就知道。这三层测试加入持续集成平台后每次提交代码或数据变更都会自动跑到。刚开始会烦但经历过“改了一行代码把整个预测搞坏、上线了才被发现”的惨痛教训后你会爱死这层保护。4.3 线上服务监控与模型漂移很多人以为模型上线就万事大吉。让我用真实教训告诉你模型上线只是开始。我遇到过最经典的问题就是数据漂移。业务发展、用户习惯变化、外部环境变化都会导致线上真实数据和训练数据分布不一致。初期模型跑得很好三个月后准确率悄悄下滑用户投诉增多而你对着监控面板一脸懵。解决这个问题的核心思路是“漂移检测”。我在项目中做两件事。一是对模型输入特征做分布监控比如评论长度的分布、高频词分布、预测概率分布。二是把预测结果导出来做抽检人工或半自动验证预测正确性。用Prometheus这类工具可以画出预测类别比例、平均置信度等指标的变化曲线一旦出现明显趋势偏离说明数据漂移已经发生就需要触发重新训练。再补充一个我认为很多人忽略的细节预测日志一定要能回溯。我在API里给每个预测请求生成了唯一请求ID并记录了请求原文、处理时间、模型版本和返回结果。出了纠纷、需要复盘的时候有这个日志链能省掉无数推诿时间。5. 踩坑实录新手最容易翻车的那些问题我把自己踩过和被身边人问过的坑整理成了一份速查表很多都是教程不会写的细节。5.1 数据类问题速查症状可能原因解决办法训练指标很高线上很差数据处理口径不一致训练和推理共用清洗函数严禁两套代码验证集和测试集结果相差巨大数据泄露测试集参与调参测试集隔离接近上线前才用模型学不到东西loss下不去标签错位或严重噪声抽50条数据人工检查别急着调模型训练过程反复震荡样本不均衡或batch太小检查类别分布用类别加权或调大batch数据问题还有一个隐藏陷阱标注质量。如果你用众包或外部标注数据一定要抽检一致性。置信区间低、标注者之间分歧大的样本往往是模型困惑的根源。5.2 训练阶段问题速查症状可能原因解决办法不收敛或梯度爆炸学习率过大或模型初始化不当降低学习率加梯度裁剪复现不出别人的结果随机种子未固定、框架版本不同固定seed记录环境版本显存OOMbatch_size过大或序列过长减小batch用梯度累积缩短max_length模型总把样本预测成多数类类别不平衡用class_weight或对少数类过采样梯度爆炸这个问题我在用预训练模型时会特意留意。虽然大部分官方transformer会自带一定稳定性但一旦用了自定义loss或加了额外层梯度裁剪从“可选项”变成了“必需项”。5.3 部署与服务问题速查症状可能原因解决办法接口首次请求特别慢初始化代码写在请求路径里移到startup钩子用预热机制并发一高就超时没有加并发控制或排队引入消息队列或异步任务加限流GPU显存被慢慢占满服务存在显存泄漏检查推理路径中是否保留张量引用及时释放模型文件无法跨机器加载路径或tokenizer版本不一致用相对路径模型包内带上tokenizer配置文件服务部署还有一个很容易忽略的点依赖大小写和版本在生产环境会咬人。我的习惯是构建前在干净容器里验证依赖安装无冲突不要指望在本地能跑生产就没问题。5.4 我的排障方法论排查AI工程问题我总结了一个简单的排查顺序数据 → 环境 → 代码 → 模型。不按这个顺序很容易在错误层面浪费几小时。如果指标不对我先怀疑数据质量而不是模型结构。打印几条训练样本看数据长什么样检查标签顺序和编码映射。如果数据没问题再检查环境版本和随机性。版本不一致导致的结果漂移是最难排查也最常见的一类问题。代码层面的bug看报错栈基本能定位。最后才去考虑模型结构、超参数是否合理。这个顺序能覆盖大约90%的“鬼故事”。6. 写给想系统学习的人一条可复用的学习路径6.1 第一个月怎么走如果你是从零开始不建议一猛子扎进大模型或者全栈架构。更务实的顺序是“先跑通小闭环再扩展外围”。第一周学Python基础重点在NumPy、Pandas理解基本的机器学习概念特征、标签、训练测试集。第二周上手PyTorch跑一个最简单的多层感知机分类任务把张量操作、DataLoader、训练循环搞明白。第三周引入Transformers库微调一个预训练句子分类模型感受“站在巨人肩膀上”的威力。第四周完成一个像我这样的情感分析项目要求是完整跑通训练到API的流程。这一个月下来你对AI工程的全貌就有了“手感”。不要贪多不要同时学图像、NLP、强化学习一个任务吃透胜过十个任务都会一点点。6.2 后面还可以往哪个方向走走完第一个闭环你可以根据兴趣选一个方向去挖。比如做系统设计方向把服务改成多模型路由加缓存、加异步处理、加降级策略研究吞吐量和延迟的平衡做数据方向深入研究数据处理流水线、数据版本管理、数据质量监控很多公司需要这种能独挡一面的人做算法方向回去补统计学习和经典机器学习为读论文和实现新模型打基础。我自己的体会是工程能力越到后面越值钱。因为算法开源和模型平权的速度太快了但能把一个模型稳定、安全、低成本地跑起来的人始终缺。这也可以解释为什么“AI工程”的热度越来越高——它本质上是把实验转成生产力的能力。6.3 什么时候可以不必“从零”“from scratch”是一剂很好的强心针但不是万能的。如果公司已经有成熟的AI平台、现成的特征平台和部署管道那你要做的不是推翻重来而是学会在平台约束下高效交付模型。工程能力的一个重要维度恰恰是“用合适的成本解决合适的问题”。当小规模闭环你都亲手跑过一遍以后你就有能力判断哪些环节该复用平台、哪些环节该自己造轮子、哪些环节可以直接接第三方API。这个判断力比从零搭建本身更值钱。最后分享一点个人体会这个情感分析项目我从编码到上线前后断断续续做了两三个星期中间踩的坑数不过来。但回头看最有价值的其实不是那个0.93的F1而是我把数据口径、版本控制、测试死角、监控盲区这些“工程债”都亲手背了一遍。从那之后再接手任何AI项目我心里始终有一张完整的地图模型训练只是其中一个节点前后左右全是工程问题。如果你也在学AI工程我建议你挑一个自己感兴趣的小任务照着这条路完整走一遍不用急着求大求全。跑完第一个闭环你会猛然发现原来“AI工程”并没有那么玄它就是一套围绕模型展开的、严谨且耐心的系统功夫。