坦白说现在搜“ai-engineering”出来的内容十有八九是“用AI写代码”或者“调API跑个demo”真正讲工程化落地的少得可怜。你点进这个标题大概率是和我当年一样的处境Python 能写模型能训论文里的 Trick 也能复现但真要把一个东西从 Notebook 里搬到线上让其他人能稳定调用心里是完全没底的。ai-engineering-from-scratch 这个项目核心解决的就是这个问题。它不教你发明新算法不带你刷论文而是把 AI 应用落地的那条完整链路——数据获取、特征工程、模型训练、评估验证、服务化部署、线上监控——当成一个系统工程来学。这条路适合两类人一类是算法出身、想补工程能力的另一类是后端或全栈出身、想往 AI 方向转的。无论哪类目标都一样做出一个能真正跑在线上、能被别人用的 AI 系统而不是一个躺在 Jupyter 里的 ipynb 文件。接下来这篇文章我把自己做这个项目时踩过的坑和沉淀下来的方法全部拆开讲。不搞那种“三十天精通”的鸡血路线只讲怎么一步步从零把工程能力补起来。1. 先搞清楚AI 工程到底在解决什么问题1.1 算法工程师和 AI 工程师的差别在哪很多人对 AI 工程有个误解觉得它就是“用框架把模型跑起来”。真不是。算法工程师和 AI 工程师的日常工作重心完全不同你自己对号入座一下就知道缺哪块了。算法工程师的考核指标是模型精度AUC 涨了多少、BLEU 涨了多少、错误率降了几个点。他们的战场在数据集、特征、模型结构、损失函数这些地方交付物是“一个效果更优的模型”以及对应的实验记录。AI 工程师的考核指标是系统的可用性接口延迟 P99 是多少、服务能不能扛住流量、模型上线后指标有没有掉、数据分布漂移能不能及时发现。他们关心的是“模型产出怎么变成业务价值”交付物是“一个稳定运行、可观测、可迭代的服务”。我见过不少算法很强的人到了工程环节就抓瞎。那个模型确实好但你要他把它做成一个 HTTP 接口他不知道怎么加载模型、怎么写预处理逻辑、怎么处理并发请求你要他在线上出问题的时候排查他不知道该看日志还是看监控。反过来很多工程能力很强的人对模型怎么调参、特征怎么处理又没有感觉。AI 工程要补的就是这条裂缝。打个比方。算法工程师像研发新菜的厨师锅气、火候、摆盘都在行AI 工程师像开餐厅的老板兼主厨——你不仅要会做菜还得管供应链、算翻台率、处理差评、培训后厨。菜品研发只是餐厅运营的一个环节而不是全部。1.2 从零开始你需要练成哪些底层能力既然标题是 from scratch我们就先把“零基础”到底指什么说清楚。我默认你至少会 Python知道什么是类、什么是函数、能写点数据处理脚本。如果连这个都不太熟第一优先级是补 Python不用学成专家但至少要能流畅地把想法写成代码。具体来说以下几项能力是 AI 工程的地基Python 语言本身不是会写 for 循环就算会要理解装饰器写中间件、做限流的时候会用到、生成器处理流式数据、类型提示让别人能维护你的代码、虚拟环境管理搞过环境冲突的都懂这里有多痛。Linux 基本功AI 工程几乎不可能完全脱离 Linux。文件权限、进程管理、查看 GPU 状态、写 Shell 脚本跑批处理任务这些是日常操作。不需要背命令但要达到“打开终端不慌”的程度。SQL 和数据访问线上系统的数据百分之七八十存在数据库或数据仓库里只会 Pandas 不够。至少能写多表 JOIN、GROUP BY、子查询能在几千万行表里把要的数据捞出来。基础的数学直觉我后面会细讲这里先提一句——不需要会证明定理但得看懂损失函数的公式、知道梯度下降在干嘛、明白正则化为什么能防过拟合。很多人一上来就急着学 PyTorch、学 Transformer这其实是本末倒置。工程化的核心是先有“把整个链路走通”的骨架再往里填模型和算法的血肉。地基没打牢后面补起来会非常痛苦我见过太多人在部署环节被环境问题折磨得怀疑人生本质就是 Linux 和虚拟环境这块基础没打扎实。2. 学习路线怎么搭把“全链路”拆成可执行的阶段2.1 基础知识不是万能但够用就好AI 工程涉及的知识面很广如果你试图什么都学会再动手那你永远动不了手。正确的策略是够用就好按需学习。数学就是一个典型。学 AI 相关的东西线性代数、概率论、微积分都有用但用处不一样。工程实践里你不用手推反向传播也不必证明收敛性但你得知道学习率太大会震荡、太小会慢到怀疑人生得知道过拟合是什么现象、正则化是怎么抑制它的得理解为什么归一化特征能让训练更稳。这些直觉在调参和排查问题的时候直接决定你的效率。机器学习经典模型也要过一遍。逻辑回归、决策树、GBDT 家族XGBoost / LightGBM、K-Means 这些在表格类数据场景里依然是工业界的主力很多深度学习模型不好解决的业务问题一个调好参数的 GBDT 就搞定了。深度学习方面CNN、RNN、Transformer 的基本结构要清楚尤其是注意力机制到底在干什么这是理解现在一切大模型的基础。我的建议是数学不用啃大部头教材找一个讲机器学习的公开课跟着把公式推导过一遍碰到不懂的再回去查效率远高于先学三个月数学再回来学 AI。做工程的人不需要当数学家但需要能跟数学家对话。2.2 一个可以直接抄走的六个月路线如果你问我从零开始到具备基本的 AI 工程能力要多久我的答案是六个月而且这六个月是按照每周投入十小时以上来算的。这条路线我自己带人走过也调整过好几轮可以直接照着做。阶段时间核心内容里程碑项目第一阶段打基础第 1-2 月Python 进阶、SQL、Pandas 数据清洗、机器学习基础线性模型、决策树、集成学习Kaggle 的 Titanic 或房价预测跑通完整的数据处理 建模流程第二阶段深挖一个方向第 3-4 月PyTorch 或 TensorFlow 入门选一个方向深入CV 或 NLP理解数据加载、训练循环、评估做一个图像分类项目或文本分类项目在验证集上把准确率做到 85% 以上第三阶段工程化打通第 5-6 月FastAPI 服务化、Docker 容器打包、模型管理、部署上线把第二阶段的项目做成一个可以从浏览器访问的完整应用支持上传图片或输入文本实时返回结果第一阶段的目标不是学会所有模型而是熟悉“数据怎么处理、模型怎么训练、结果怎么评估”这一套流程。第二阶段开始接触深度学习框架理解张量、自动求导、DataLoader 这些核心概念。很多人死在第三阶段因为这里的问题不再是“模型准确率不够”而是“为什么我本地能跑的服务放进 Docker 就崩了”“为什么接口一并发就超时”——这才是真正的工程问题。2.3 为什么项目驱动比看课重要我见过太多“看了三个月课一问全不会”的人。看课是最容易产生学习幻觉的方式视频里老师一行行敲代码你跟着看觉得自己都懂了合上电脑什么都不会。项目驱动刚好相反。它逼着你面对真实问题而真实问题永远比教程复杂。举个例子你学完 ImageNet 分类打算做一个“图片里有没有猫”的接口。你以为难的是模型错了。难的是你发现用户上传的图片五花八门——有人传了 PDF 截图、有人传了 3MB 的超大图、有人传了个动图。你的预处理代码要处理这些情况模型才能正常工作。这些问题教程里是不会告诉你的。所以我的路线里每个阶段都强制配一个“能拿出来演示的项目”。这个项目不需要大不需要创新甚至可以是网上抄的改的但你必须把整个链路跑通。跑通一次完整链路比看十遍教程都有用。因为只有真正跑通了你才知道哪一环是薄弱的、哪一环是会出问题的、哪一环需要补充知识。3. 实操核心环节从数据清洗到模型上线的完整闭环3.1 环境搭建从 Conda 到 Docker 的一步到位环境管理是 AI 工程的第一课也是最容易翻车的一课。我见过太多人把包装到全局环境里然后某一天某个库升级整个项目跑不起来了。这里我把一套稳妥的实践完整写出来。本地开发环境我推荐 Miniconda 而不是 Anaconda。Anaconda 预装的东西太多看着方便实际上大部分你用不上还会占用大量磁盘空间。装完 Miniconda 后为你的项目建一个独立环境conda create -n ai-eng python3.10 conda activate ai-eng注意这里指定了 Python 版本这是很多人会忽略的细节。不同项目依赖的 Python 版本可能不同如果你不指定conda 会用默认版本后面很可能出兼容性问题。装依赖的时候尽量用 conda 或 pip 都行但不要混着乱装尤其是不要用 sudo pip 往系统环境里装东西——这几乎是环境崩溃的头号原因。requirements.txt一定要锁版本。我之前接手过一个项目requirements.txt里全是numpy、pandas这种不带版本号的写法结果换一台机器依赖解析出的版本完全不同模型推理结果都有了细微差异。正确做法是用pip freeze requirements.txt把所有依赖的精确版本记录下来或者更进一步用pip-tools之类的工具管理。然后就是 Docker。环境管理只到 Conda 这层是不够的因为 Conda 管的是 Python 环境和包管不了系统依赖。你的模型可能需要特定版本的 CUDA、特定版本的 gcc 运行时这些 Conda 管不了Docker 能管。把整个运行环境打成一个镜像推到哪都能跑这才是工程化的起点。一个比较稳的 Dockerfile 写法是这样的# 第一层依赖缓存层 FROM python:3.10-slim as builder COPY requirements.txt . RUN pip install --prefix/install -r requirements.txt # 第二层运行层 FROM python:3.10-slim COPY --frombuilder /install /usr/local COPY ./app /app WORKDIR /app CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 8000]依赖层单独放一个构建阶段是为了利用 Docker 的层缓存机制。你改代码之后重新构建只要 requirements.txt 没变依赖层就不会重新安装构建速度会快非常多。这个技巧在频繁迭代模型和代码的时候特别好用。3.2 第一个端到端项目怎么做环境搭好了就该做那个真正打通全链路的项目了。我的建议是选一个简单但完整的方向文本情感分类或者图像分类。原因很简单数据集公开好拿、模型结构不复杂、效果验收直观。你不需要在这个阶段追求 SOTA能把链路跑通就是胜利。以文本情感分类为例完整流程是这样的数据获取用现成的公开数据集比如 IMDB 影评、Kaggle 上的情感分析数据集。中文场景可以用一些开源的中文评论数据集。不要在这个阶段纠结数据量几万条足够用了。数据清洗与预处理去掉 HTML 标签、处理特殊字符、统一小写。做 NLP 的都知道文本清洗直接影响效果这个环节要仔细。划分数据集训练集 / 验证集 / 测试集按 8:1:1 或 7:2:1。注意要保证标签分布一致别让某个标签在测试集里缺了。建模与训练用 HuggingFace 的transformers库加载一个预训练语言模型比如 BERT -base在它的基础上做微调不要自己从头训练。在单卡 GPU 上跑二十到三十分钟就能出不错的效果。模型保存把模型权重和分词器都保存下来同时记录训练时的超参数和最终评估指标。推荐都放在同一个目录下model_dir/ ├── config.json ├── model.safetensors ├── tokenizer.json └── metrics.json服务化封装用 FastAPI 写一个推理接口接受文本输入返回情感类别和置信度。核心逻辑是把模型加载、预处理、推理、后处理封装成清晰的类或函数。写 API 的时候有个容易忽略的细节模型要全局加载一次而不是每个请求加载一次。在全局初始化模型对象处理请求时就只做推理不重新加载权重。这个错误我踩过加载 BERT 模型每次差不多要两秒如果每次请求都加载接口延迟直接爆炸。一个最小可用的推理服务长这样from fastapi import FastAPI from pydantic import BaseModel import torch from transformers import AutoTokenizer, AutoModelForSequenceClassification app FastAPI() device torch.device(cuda if torch.cuda.is_available() else cpu) tokenizer AutoTokenizer.from_pretrained(./model_dir) model AutoModelForSequenceClassification.from_pretrained(./model_dir).to(device) model.eval() class Item(BaseModel): text: str app.post(/predict) def predict(item: Item): inputs tokenizer(item.text, truncationTrue, max_length128, return_tensorspt).to(device) with torch.no_grad(): logits model(**inputs).logits prob torch.softmax(logits, dim-1) label torch.argmax(prob).item() return {label: label, confidence: float(prob[0][label])}容器化并自测写完接口先本地跑起来用 curl 或 Python 发几个测试请求确认结果正确再写 Dockerfile 打包。测试请求时注意边界情况空字符串、超长文本、非 UTF-8 编码这些你都应该在代码里处理掉。这一整套流程下来你不仅有了一个能演示的项目更重要的是把 AI 应用的完整闭环体验了一遍。之后再接任何新项目流程都是通的剩下的只是把每一环做得更深入而已。3.3 模型部署与线上服务的常见姿势项目跑通后就该讨论“上线”这件事了。很多人对部署的理解就是“把接口放到服务器上”但对工程化的部署来说要回答的问题多得多请求量大了怎么办、模型版本怎么更新、线上效果怎么监控。部署方式上我按复杂度从低到高给你排一下原型级部署模型和 Web 服务跑在同一个进程里适合 demo 和内部工具。优点是好写好跑缺点是模型加载和 Web 服务耦合在一起出问题不容易隔离。独立服务部署模型推理做成独立服务通过 HTTP 或 gRPC 对外提供Web 服务和模型服务分开。这是最主流的形态扩展灵活、职责清晰也是我推荐你重点掌握的方式。平台化部署用 Kubernetes 这类平台编排多实例服务自动扩缩容、滚动更新、灰度发布。这是大厂的标准做法但你个人学习阶段不用急着上。部署环境有几个细节特别重要。一个是 GPU 版 Docker 的配置在宿主机上要装好 nvidia-container-toolkit然后在docker run时加--gpus all参数容器里才能看到 GPU。这个步骤网上教程很多但实操起来还是容易踩坑尤其是宿主机驱动和容器内 CUDA 版本不匹配的问题。我自己的经验是宿主机驱动尽量新镜像内 CUDA 版本别追新用主流稳定版本就行。线上服务的监控是很多人会忽略的。部署上线不是终点而是起点。你需要知道接口的延迟、错误率、请求量还需要知道模型产出的分布有没有变化。比如你做了一个情感分析服务上线后突然大量请求被分类为“负面”这时候你要能判断是线上数据分布变了还是模型本身出了问题。至少要记录每个请求的输入文本、预测结果、置信度以及模型服务的响应时间有了这些日志和指标线上问题排查才有依据。4. 工具链选型哪些现在学哪些以后再补4.1 训练与建模环节怎么选AI 工程的工具链非常碎如果你什么都想学会被淹没在工具的海洋里。我按自己的经验帮你分清主次有些工具现在必须学有些等你在真实项目里遇到问题再学也不迟。模型训练框架现阶段直接选 PyTorch。TensorFlow 仍然在不少存量项目里存在而且 Keras 的简洁性确实让人怀念但 PyTorch 的生态优势太明显了HuggingFace 的模型基本都是 PyTorch 权重、论文复现都是 PyTorch 代码、社区提问大多能得到 PyTorch 回答。你选 PyTorch等于在跟随整个领域的主流方向。在 PyTorch 之上transformers库是必学的。你基本不会自己从零设计一个 BERT 或 GPT而是加载预训练权重做微调。这套体系里AutoModel、AutoTokenizer、Trainer这些 API 要混熟它们能帮你省下大量模板代码。表格类数据场景XGBoost 或 LightGBM 仍然值得学。很多人一提起 AI 就只看深度学习但工业界的真实情况是大量风控、推荐、营销场景的数据是结构化表格数据GBDT 家族的效果好、可解释性强、训练快依然是业务侧的常青树。我自己的习惯是“先跑 GBDT再跑深度学习谁效果好上谁”。实验管理工具的引入时机需要注意。大多数人刚开始做项目时直接开一个 Jupyter Notebook 往下写就完了我也这么干过。但当你实验次数多起来比如同一个模型跑了二十几次改了不同的学习率、不同的特征组合你会发现你根本记不清哪次实验用了什么参数、效果怎么样。这时候就该引入 MLflow 或 Weights Biases。我建议你从 MLflow 开始它开源、自托管、功能覆盖实验跟踪、模型注册、模型服务一个人玩和团队协作都够用。4.2 部署与交付环节怎么选部署服务这一层FastAPI 是当前最主流的选项之一。它轻量、自带 OpenAPI 文档、支持异步处理、类型校验用 Pydantic 做得很干净。你不需要学两个框架FastAPI 一个搞定。如果你之后需要和 Java 技术栈协作那可能是 gRPC 或别的方案但对个人项目和中小团队来说FastAPI 是效率最高的选择。模型部署格式上我建议你了解一下 ONNX 和torch.compile。PyTorch 的原生推理用起来没问题但在推理性能和跨平台移植方面ONNX Runtime 有优势。你训练好一个 PyTorch 模型导出成 ONNX 格式然后使用 ONNX Runtime 跑推理延迟通常能降低不少。这个优化在需要部署到 CPU 环境的时候特别实用。容器的学习是绕不开的Docker 是必选项。Kubernetes 我建议你暂缓一缓不是它不好而是个人项目阶段直接上 K8s 很容易被复杂的概念淹没——Pod、Deployment、Service、Ingress 一套下来还没解决模型问题先被运维问题劝退了。先把 Docker 用熟等服务的请求量确实大到单机扛不住了再考虑 K8s 也不迟。4.3 MLOps 工具什么时候引进来MLOps 是这两年很热的概念但我对它的态度比较务实先把基础链路跑通再按需引入工具。一个只有两三个模型、每天几十次调用的服务你给它上一套完整的 MLOps 平台纯属杀鸡用牛刀。当你的项目出现这些信号时就说明该引入 MLOps 工具了模型和实验数量变多手工记录已经管不过来了——上 MLflow数据管线的步骤复杂每天要定时跑数据清洗和特征加工的任务——上 Airflow 或 Prefect线上服务需要精细化监控包括自定义指标和告警——上 Prometheus 和 Grafana多个模型需要统一管理版本和发布流程——上模型注册中心。但有一点我想提醒你这些工具都是为解决特定复杂问题而生的不要为了用而用。我见过一个人做项目非要搭一个包含 K8s Airflow MLflow Prometheus 全家桶的环境结果折腾了两周还没跑通一个模型推理接口。工程化的本质是把事情做简单而不是把工具堆出仪式感。5. 常见问题与排查技巧实录5.1 环境冲突与依赖地狱环境问题几乎是每个做 AI 工程的人都遇到过的噩梦。症状表现为ModuleNotFoundError、ImportError、版本不兼容导致某个函数行为异常或者一种更隐蔽的情况——同一份代码在两台机器上跑出不同的结果。这里给你一个系统的排查思路先搞清楚当前环境有什么。用pip list和conda list查看已安装的包和版本确认你实际用的 Python 是哪个解释器。我遇到过一种情况在终端里明明conda activate了但python命令指向的却是系统自带的 Python导致装包装到了别的环境里。关键依赖的版本一旦变了立刻锁定。排查问题时先确认这几个torch、transformers、numpy、pandas以及你的 CUDA 环境。很多时候报错信息根本没有提示是哪个包引起的用二分法逐一排查成本又太高所以优先怀疑重量级依赖基本不会错。环境坏了不要修直接重建。这是我折腾过几次之后的经验教训——维护一个坏环境的成本远超直接新建一个。把requirements.txt或者environment.yml留着conda create -n ai-eng-fresh python3.10重建环境重装依赖十分钟就恢复比自己跟报错信息搏斗一小时高效太多。5.2 训练不收敛和指标不升的排查思路模型训练不收敛是新手阶段最打击信心的问题。但大多数时候原因无非那么几个一个一个排查就好。第一检查数据是否归一化。图像数据有没有缩放到[0, 1]或者标准化文本数据有没有做 padding数值型特征的量纲是否差别过大这些看起来不起眼的细节直接影响梯度传播的稳定性。第二检查标签是否正确。多分类的标签如果是混合了字符串和数字的类型你有机会让模型学得一头雾水。第三检查数据泄漏。训练集和测试集有没有按照时间或其他逻辑正确切分有没有某些特征在预测时根本拿不到模型侧还要注意输出层和损失函数的匹配。二分类用 sigmoid BCEWithLogitsLoss多分类用 softmax CrossEntropyLoss这些配对不要搞混。这里分享一个排查利器先让模型过拟合一个 batch。如果你训练十步之后模型连训练集的单个 batch 都无法拟合那大概率是你的模型结构或者数据预处理有 bug如果单 batch 能拟合多 batch 就不收敛那才需要怀疑学习率、特征分布这些问题。这个技巧我几乎每次调试模型都会用省掉了大量瞎猜的时间。如果模型能拟合训练集但验证集不涨那就是过拟合或数据分布不一致的问题从正则化、数据增强、交叉验证这几个方向入手。5.3 显存不够和推理太慢怎么办“CUDA out of memory”是每个人都见过的报错。遇到这个不用慌先按顺序走这几步把 batch size 调小。这是最朴素也最有效的办法batch 减半显存占用基本也随之减半。用梯度累积来弥补 batch size 缩小的损失。本质上是“小批量多次累积梯度再更新参数”相当于保持了和原来大 batch 接近的训练效果# 梯度累积伪代码 accumulation_steps 4 loss loss / accumulation_steps loss.backward() if (step 1) % accumulation_steps 0: optimizer.step() optimizer.zero_grad()使用混合精度训练fp16。现代 GPU 上这几乎是无脑收益训练速度和显存占用都有明显改善PyTorch 里用torch.cuda.amp就可以实现。检查是不是有进程占用了 GPU。nvidia-smi看一眼如果之前跑过的训练进程没结束显存被占着新任务自然 OOM。推理太慢的问题思路就更多了。模型量化是最直接的——把 fp16 或 fp32 的权重压缩到 int8显存占用和推理延迟都能大幅下降精度损失通常在可接受范围内。还有一个容易被忽略的点如果你的模型一次只能推理一个请求但线上有大量请求排队可以尝试批量推理。把多个请求攒在一起一次 model 调用处理多条数据GPU 的利用率立刻就不一样了。最后如果你在用 FastAPI 做服务注意async def和普通def的差异。FastAPI 中同步的def函数会自动放到线程池执行但如果你的推理函数是 CPU 密集的多个线程可能会互相抢占资源如果是 I/O 密集的比如从远程读数据反而要写成async def才能利用异步的优势。这个细节看似小但对接口性能的影响非常大。6. 一些个人操作层面的体会看到这里你应该已经对“从零开始学 AI 工程”这条路有了比较完整的概念先练底层能力再搭学习路线用项目驱动把数据、模型、部署、监控整条链路跑通过程中按需引入工具踩坑时用系统化方法排查。我在实际带人做 ai-engineering-from-scratch 的过程中最深的体会是不要试图一下子搭一个完美的学习计划也不要等自己“准备好”再开始。我的做法是先选一个极其简单的项目比如用 BERT 微调一个句子分类器然后把每一个环节——哪怕是“如何把一个目录挂载进容器”这种细节——都亲自动手操作一遍。第一次跑通全链路之后后面所有新项目都只是在同样的骨架上换不同的模型和数据。最后再分享一个我自己坚持了很久的小习惯每完成一个项目就写一份复盘文档记录三件事——踩过的坑、排查过程、最终解决方案。三个月之后回头看这份文档的价值远高于你当时花钱买的技术课程因为它是你自己的避坑手册是 AI 工程这条路上最量身定制的学习资料。