第一次独立负责 AI 工程类项目是在两年前。当时我的想法很天真把模型准确率刷到 98%任务就完成了一大半。结果项目上线不到三周线上准确率掉到 61%我连续排查了两天两夜最后发现根本不是模型出了问题——训练数据和线上数据压根不在一个分布里。那次之后我才真正理解ai-engineering-from-scratch意味着什么从零开始做 AI 工程难点从来不在“AI”两个字上而在于工程化的每个细节。如果你也正准备从零开始进入这条路这篇内容应该能帮你少踩几个我踩过的坑我把从环境搭建、项目选型到部署上线、监控迭代的全过程都摊开来讲。1. 先搞清楚一件事AI 工程不等于写模型很多刚入行的人会把“AI 工程”理解成“训练一个模型”这个偏差非常致命。我在带新人的时候发现大家能把 PyTorch 的nn.Module背得滚瓜烂熟却说不清“训练好的模型怎么在线上稳定跑一年”。这就是研究和工程的差别。1.1 从研究到工程的差距到底有多大拿电池来类比实验室里做一个锂电池样品只要在理想温度、固定倍率下循环几百次不衰减就能发论文了。但手机里的电池要面对用户在零下二十度的东北户外拍照、在四十度的夏天边充电边打游戏——这才是工程要解决的问题。AI 工程也是这样研究环境数据集是别人整理好的、标签是干净齐整的、评测指标是固定的跑完实验只要结论可复现。工程环境数据是流式进来的、标签可能几个月没人维护、模型要承接线上真实流量、还要应对特征缺失、并发突增、甚至隔壁团队改了接口字段你没收到通知。所以每当我听到“从零开始学 AI 工程”第一反应永远是先纠正认知你要学的不是怎么调模型而是怎么让一个机器学习系统在真实世界里稳定存活。1.2 一个 AI 工程项目的完整闭环从零起步你需要跑通的不只是“训练脚本”而是下面这个闭环环节核心问题常见误区需求定义业务到底要解决什么问题一上来就选“最先进的模型”数据采集与清洗数据从哪里来质量如何忽略标签噪声直接开训特征工程哪些信号能预测目标深陷调参忘记做特征模型训练怎么训练、多久迭代一次训练一次跑一周没做实验管理评估验证线上环境真的会像测试集一样吗只看准确率不看分布部署上线延迟、吞吐、回滚怎么办模型文件手动拷贝版本全靠记忆监控迭代模型什么时候会失效上线即失联坏了没人知道我把这张表贴在工位正对着的墙上每次启动新项目都会先过一遍。如果你现在一个项目都还没跑过建议存下来等第一个项目做完再回头对一遍你会发现每个环节都有教训可填。1.3 动手前先回答三个问题在写第一行代码之前我通常会强迫自己回答三个问题回答不上来绝不开工线上环境能容忍多慢的推理实时推荐和离线批量打分的要求完全不同前者可能要求 100ms 内返回后者跑一个小时也无所谓。数据量级大概是多少一万条和一亿条技术选型是两条路。模型出错后最坏结果是什么只是推荐位不精准还是会影响资金、安全等环节这决定了你要投入多少精力做监控和人工复核。这三个问题决定了你从零搭起的系统长什么样。我见过太多人上来就租四张 A100 跑大模型结果业务场景只需要一个几千维特征的逻辑回归就能解决问题。工程的核心永远是:在约束条件下做出可用的东西而不是炫技。2. 从零搭建第一个 AI 项目选型、环境与最小跑通这一节我默认你已经会基础的 Python 语法但不一定接触过任何机器学习框架。我会用我建议的第一个项目——垃圾邮件文本分类——带你走一遍完整的最小流程。2.1 为什么推荐文本分类作为入门项目理由很简单文本分类是“投入产出比”最高的练手项目数据好拿公开数据集多自己收集也容易比如导出你的邮件收发记录或者抓取某社区评论。标注成本低类别是二分类含义明确找个朋友帮忙标一百条也就一杯咖啡的时间。迭代快文本数据不需要复杂的文件解析几行代码就能从 CSV 里读出来。可解释分类结果可以映射回具体的词出错了容易排查。对比一下其它方向图像分类要处理数据增广、标注一致性语音识别要面临噪声、音频切分推荐系统则要面对用户行为序列的复杂建模。这些都不如文本分类适合作为“第一个跑通全流程”的目标。2.2 环境搭建别一上来就装全套深度学习全家桶很多新手死在第一步Python 版本和 CUDA 版本对不上装 PyTorch 装了一整天最后 GPU 还是用不了。我的建议是先把基础环境做到“干净、够用、可复现”。操作顺序如下# 1. 安装 Python 3.10用 pyenv 管理版本最省心 pyenv install 3.10.12 pyenv global 3.10.12 # 2. 为每个项目创建独立虚拟环境 python -m venv ~/venvs/ai-engineering source ~/venvs/ai-engineering/bin/activate # 3. 安装核心依赖 pip install pandas scikit-learn jupyter matplotlib这个阶段我不建议你立刻安装 PyTorch。为什么因为你的第一个项目用scikit-learn完全够跑通而且训练速度快、代码量少、不容易出错。等你理解了数据管道、评估方式和部署流程再去碰深度学习框架你会发现自己带着很多问题上手效率远高于盲目学。关于版本固定我有一个后来吃了亏才养成的习惯把依赖版本写死到requirements.txt比如scikit-learn1.3.2而不是scikit-learn1.0。因为两个月后你重跑上次的实验脚本发现结果不一样了这时候究竟是代码问题还是库版本升级问题会让你排查到崩溃。2.3 一个最小可运行的训练脚本假设你已经拿到一份 CSV 数据包含text和label两列。下面是完整的训练流程# train_spam.py import pandas as pd from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.pipeline import Pipeline from sklearn.model_selection import train_test_split from sklearn.metrics import classification_report # 1. 读取数据 df pd.read_csv(spam_dataset.csv) # 2. 划分训练集和测试集 train_df, test_df train_test_split( df, test_size0.2, random_state42, stratifydf[label] ) # 3. 构造文本处理 Pipeline model Pipeline([ (tfidf, TfidfVectorizer(max_features20000, ngram_range(1, 2))), (lr, LogisticRegression(C1.0, max_iter500)), ]) # 4. 训练 model.fit(train_df[text], train_df[label]) # 5. 评估 print(classification_report(test_df[label], model.predict(test_df[text]))) # 6. 保存模型 import joblib joblib.dump(model, spam_lr.joblib)你可能注意到这里面没有深度学习。这是故意的TfidfVectorizer LogisticRegression在文本分类任务上是久经考验的强基线很多生产系统里的基础分类器至今还是这一套组合。跑通这个脚本之后你会自然地理解几个关键概念——特征提取、模型训练、评估、序列化。而这些概念是后续所有复杂工程的根基。2.4 从“能跑”到“跑得好”第一次训练结果很差怎么办假设你跑完上面的脚本F1 分数只有 0.6不用慌。我教你一套排查顺序按顺序检查比盲目换模型有效百倍先看数据把模型预测错的样本打印出来逐条看。你会发现很多“错误”其实是标签标错了或者数据里混入了大量 HTML 源码、重复广告内容没清洗。再看预处理文本有没有统一小写URL、数字、特殊符号要不要保留这些细节对结果影响极大。最后才看模型基线模型的效果差多半是前面两个环节出了问题。等前两步都没问题了再考虑上复杂模型。这个顺序反过来是无数新手踩过的坑一上来就换 BERT、调学习率、加随机种子搞了半天最后发现训练集和测试集里同一句话被标成了相反的分类。3. 让模型真正可用数据、评估、部署三条硬约束模型在 Jupyter Notebook 里展示的预测效果和它真正“可用”之间隔着三条硬约束数据是否干净、评估是否合理、部署是否稳定。我一个个说。3.1 数据处理真实数据比模型更值得花时间我在项目里反复说一句话“垃圾进垃圾出”这句老话在 AI 工程里不仅要听而且要刻进骨子里。实际业务中的数据和公开数据集完全是两回事。真实数据常见的几个坑以及我的处理习惯重复样本同一封营销邮件在数据集里出现 30 次。如果不做去重模型会对这些重复样本严重过拟合。标签噪声人工标注不可能 100% 正确如果发现同一条样本被标成两个类别优先考虑剔除而非保留。时间漂移这可能是最隐蔽也最要命的。用户的说法习惯会随着时间变化“薅羊毛”这样的网络热词每年都在变。如果只用历史数据训练而没有定期补充新数据模型会慢慢失效。关于数据划分我要特别强调一个原则如果数据是有时间顺序的千万不要随机划分训练集和测试集。正确做法是先按时间排序再用前 80% 时间的数据训练后 20% 时间的数据测试。因为这样才最接近线上真实的情况——你永远是在用过去预测未来而不是用未来的数据偷偷作弊。3.2 评估指标准确率高不代表模型好二分类任务里准确率Accuracy是最直观但也最容易骗人的指标。拿垃圾邮件分类来说如果你的测试集里 90% 是正常邮件、10% 是垃圾邮件那么一个“全都预测成正常邮件”的傻子模型也有 90% 的准确率。正确的打开方式是看三个指标指标想回答的问题计算方式Precision模型预测的垃圾邮件里多少是真的TP / (TP FP)Recall真正的垃圾邮件里模型找回了多少TP / (TP FN)F1两者的平衡如何2 * Precision * Recall / (Precision Recall)除了看指标我还强烈建议做一件事看混淆矩阵。它会告诉你模型到底在哪些具体类别上犯错。比如你发现垃圾邮件被大量误判成正常邮件召回率低那可能是这类垃圾邮件和正常邮件在外观上特别接近你需要增加更多这类难样本到训练集里。另外你不要只知道调模型参数还要知道调决策阈值。LogisticRegression默认以 0.5 作为分类边界但业务场景可能对“宁可错杀、不可放过”有不同的偏好。把predict_proba()的输出拿来手动定阈值往往比换模型更有效。3.3 部署把模型变成可以被调用的服务模型训练好之后接下来的问题就是怎么让业务方用它。我的默认方案是FastAPI Docker。先说为什么不用 FlaskFastAPI 原生支持异步处理高并发场景下性能表现明显更好而且自动生成 API 文档联调省很多时间。下面是给上面模型写的最小推理服务# app.py from fastapi import FastAPI, Request from pydantic import BaseModel import joblib app FastAPI() clf joblib.load(spam_lr.joblib) class Item(BaseModel): text: str app.post(/predict) async def predict(item: Item): label int(clf.predict([item.text])[0]) prob clf.predict_proba([item.text])[0].tolist() return {label: label, probabilities: prob}再配一个最小可部署的DockerfileFROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [uvicorn, app:app, --host, 0.0.0.0, --port, 8000]看似简单但有三个细节我建议你第一次就做好模型文件必须跟着容器走也就是说joblib文件要COPY进镜像里而不是容器启动时从外部挂载一个路径。否则你会经历“本地能跑服务器上跑不起来”的经典事故。带上健康检查接口加一个GET /health返回{status: ok}K8s 或者云平台的探活机制需要它。日志要打全记录每次请求的耗时时长、入参长度、预测结果。这是后面做监控的原始素材等出了问题再回头补日志已经晚了。我自己在第一次上线时就因为没有打文本长度日志导致后来定位线上某类错误请求时完全两眼一抹黑只能翻业务方的调用记录。4. 生产环境里比模型更重要的五个隐形坑模型上线只是开始不是结束。我在这一节集中写五个真实踩过的坑每一个都让我付出了成倍的时间代价。4.1 数据漂移上线后准确率为什么崩了文章开头提到的那个准确率从 98% 掉到 61% 的项目根因就是数据漂移。所谓数据漂移指的是训练时用的数据分布和线上推理时遇到的数据分布不一致。通常区分两类漂移协变量漂移特征本身的分布变了。比如你的模型是在用户以文本输入为主的时期训练的后来界面改版、用户开始大量使用语音转文字投稿输入文本的特征空间整体变了。概念漂移特征和标签的关系变了。比如某个词在以前是营销话术现在变成了平台官方活动的标准文案模型对它的判断需要反转。我经历的那个案例是某次大促活动前后用户评论里的商品口碑语义整体翻了个面。随机划分的训练集自然捕捉不到这种时序变化结果线上模型每天都在用旧规则解释新世界。检测手段最简单的方式是监控预测概率的分布。如果线上每天预测结果的分布和训练集的分布偏离越来越大基本可以断定漂移发生了。更进一步可以用 PSIPopulation Stability Index量化公式长这样import numpy as np def psi_score(expected, actual, bins10): expected np.clip(expected, 1e-6, None) actual np.clip(actual, 1e-6, None) return np.sum((actual - expected) * np.log(actual / expected))当 PSI 超过 0.1 时开始留意超过 0.25说明分布已经明显变了该触发重新训练流程了。4.2 版本管理数据、模型、代码的三体对应问题Git 能管理代码但管不了模型和数据。我见过最混乱的情况是业务方问“上周那个效果不错的模型是拿哪份数据训出来的”所有人面面相觑无人能答。因为模型文件通常几百 MB 甚至几 GB不适合直接塞进 Git。这就需要专门的工具。我的建议是如果你是一个人或者小团队直接用MLflow就够——它把每一次实验的代码版本、数据哈希、超参数、模型指标、模型文件自动打包记录。实际使用中我要求每个训练任务都要记录以下元信息data_version原始数据集的哈希值或版本号code_commit训练脚本对应的 Git commitmodel_config模型的超参数metrics验证集上的指标artifact_path模型文件存放位置这样做的好处是出问题了能精准定位“是数据变了还是代码变了还是环境变了”而不是靠记忆猜。4.3 监控与告警怎么知道模型已经坏了你不可能每天手动看看线上效果是不是还行的。必须建立自动监控。我在监控层做三件事预测分布监控每天统计线上预测结果的分布画成直方图自动对比和历史分布是否一致。置信度走势监控比如平均置信度一周内从 0.95 跌到 0.82触发告警。人工抽检闭环定期抽取一部分线上预测样本让业务方人工复核把复核结果回流成下一次的训练数据。告警规则宁多勿少。初期可以每条规则都设一个周报通知运行一两周后根据告警噪音收敛阈值不要一开始就只设一个全局告警否则会错过真正的异常信号。另外回滚策略必须在部署时就设计好。每次上线新模型我都保留旧模型的版本和对应服务确保新模型出异常时可以一键切回上一个版本。没有回滚预案新模型出问题就是直接线上事故。4.4 性能优化让推理跑得够快工程里绕不开的另一个问题是延迟。拿文本分类来说我实测过Logistic Regression 模型在 CPU 上单条推理大约 1~2ms完全不是瓶颈。微调后的 BERT 在 CPU 上单条推理大约 80~120ms对实时场景来说已经偏慢。同样的 BERT 在 T4 GPU 上大约 10~20ms可以接受。如果你的业务场景必须用重型模型同时又要低延迟我按优先级推荐的优化路径是模型量化用 ONNX Runtime INT8 量化BERT 类模型在 CPU 上往往能把延迟压缩到原来的 1/3 到 1/4。批处理聚合如果请求能攒 50 条一起推理GPU 利用率会大幅提升单位吞吐量成本下降。结果缓存对文本完全相同的重复请求直接查缓存不重复计算。实际业务里这类命中率常常高得惊人。我见过一个推荐系统团队做完结果缓存这一件事服务整体吞吐直接翻倍。很多优化思路看起来不起眼但收益极其直接。4.5 别把“调参”当工作成果最后这一个人收获来自于一次很惨痛的教训。早期我特别喜欢一个劲调学习率、调预热步数、尝试各种新出的优化器每次结果涨一两个点就兴奋得不行。后来把时间线拉长才发现那次“效果提升”真正的原因是我无意中多清洗了一批重复数据而不是优化器起的作用。你从零开始做 AI 工程时间和精力都是有限的请把它们花在数据质量、流程规范、监控体系这些复利最高的事情上。模型算法迭代等前面这些基建都稳了再去做才有意义。5. 从零到一的学习路线与我的个人经验如果你是完全的新手看到这里可能已经觉得信息量很大了。我最后给你一条分阶段的路线照着走节奏感会比零散刷教程好很多。5.1 按阶段推进不急于求成阶段核心任务建议投入时间里程碑第一阶段Python 基础 Pandas 数据操作2~3 周能独立完成数据清洗与分析第二阶段跑通一个完整的 ML 项目分类或回归3~4 周完成一次完整的训练-评估-保存流程第三阶段深度学习基础 掌握一个框架PyTorch/TF4~6 周能训练并调优一个中型模型第四阶段工程化部署、监控、容器化3~4 周模型能以 API 形式稳定对外服务第五阶段进阶大模型应用、RAG、MLOps 体系持续能独立设计并搭建一套可用系统每个阶段都有一个明确的里程碑做完再进入下一个。不要第一周就去学分布式训练那是把大楼的封顶工作挪到了打地基阶段。5.2 适合练手的项目清单我筛选练手项目的标准有三条数据容易获取、业务价值明确、踩坑空间大。按照这个标准推荐顺序如下垃圾邮件/评论分类上面已经详细写了作为第一个跑通全流程的项目再合适不过。二手房价预测适合体验回归任务而且特征工程的空间很大能让你体会缺失值处理和异常值剔除的重要性。图像多分类比如猫狗识别入门数据增强和迁移学习。注意这类项目的数据标注和预处理比文本项目更繁琐。大模型问答应用RAG有前面的基础之后做一个私域知识库问答。RAG 是当前需求很大的方向工程细节极多文档切分、向量化、检索排序、上下文拼装都有讲究。5.3 几句掏心窝的话从零开始这条路我走下来的最大体会是“做完一个项目”和“看完十篇教程”的差距是云泥之别。教程讲的是别人已经走通的路你照着走当然顺利。只有自己从零搭一个项目你才会遇到环境冲突、数据缺失、指标异常、部署失败这些真实世界里无处不在的问题而这些问题才是工程师真正的日常。我建议你把第一个项目完整地跑完、部署、上线哪怕只有一个内部同事在用哪怕每天只有几十次调用。只要它真实跑在生产环境里你就会开始思考监控、版本、回滚这些事情而这个思维转变的价值远比你学会某个具体模型的价值大得多。最后分享一个我现在的习惯从项目第一天起就写清楚README记录每个环节的执行命令和遇到的问题。不是因为别人会看而是三个月后的自己一定会看。我还真没见过哪个项目做完三个月后光靠脑子能记得住所有细节的。