1. 从零搭建AI工程能力为什么我劝你别再“调包”了这两年带过不少新人也帮朋友面过几十场AI方向的岗位一个特别明显的感受是简历上写着“熟悉深度学习”“做过大模型应用”的人越来越多但真正能把一个模型从数据到上线跑通的人少得可怜。大部分人所谓的“做过”其实就是在Jupyter Notebook里import torch然后调一个预训练模型跑个demo截图发朋友圈。一旦问到“数据怎么清洗的”“推理延迟怎么优化的”“显存不够怎么办”基本就卡壳了。ai-engineering-from-scratch这个标题我第一次看到的时候就觉得特别对味。它说的不是“AI从零入门”也不是“大模型原理速成”而是AI工程——工程这两个字才是重点。算法和模型是研究员的事但把模型变成能稳定跑在服务器上、能扛住并发、能持续迭代的东西是工程师的事。这两者之间的鸿沟比很多人想象的要大得多。我自己是从传统后端转过来的踩过的坑可以说能写一本书。最开始我也觉得AI嘛不就是调个库的事后来才发现数据管道的设计、训练脚本的工程化、模型服务的部署、监控和回滚每一个环节都有大量的细节而且这些细节在论文里根本不会讲在教程里也往往一笔带过。所以这篇内容我想从一个一线从业者的角度把“从零搭建AI工程能力”这件事拆开来讲不讲虚的只讲我实际做过、踩过、验证过的东西。这篇文章适合谁看如果你是刚入行的算法工程师想补上工程这块短板如果你是后端或运维想转AI方向但不知道从哪下手或者你是个独立开发者想自己做一个AI产品但被各种工程问题卡住——那这篇内容应该能帮到你。我会从整体思路、核心环节、实操步骤到常见坑尽量讲透。2. 整体设计思路AI工程到底在工程什么2.1 先搞清楚AI工程和算法研究的边界很多人一上来就想学Transformer架构、想手推反向传播我觉得方向就偏了。不是说这些不重要而是对于“工程”这个定位来说优先级排错了。AI工程的核心任务是让一个已经存在的模型不管是自己训的还是开源的能够在生产环境中稳定、高效、可维护地运行。它关心的问题是这样的数据从哪来怎么保证质量怎么版本化训练任务怎么调度怎么复现怎么管理实验模型怎么打包怎么部署怎么做到低延迟高吞吐线上出问题了怎么排查怎么回滚怎么持续迭代这些问题没有一个能靠调包解决。它们需要的是扎实的软件工程能力代码规范、版本控制、CI/CD、容器化、监控告警、日志系统。你可以不会推导注意力机制的公式但你必须会写可维护的代码、会设计合理的接口、会排查线上问题。我见过太多算法很强的同学模型效果做得很好但代码一团糟训练脚本里硬编码路径实验参数靠手改模型文件命名靠日期。这种工作方式在实验室里可能还能凑合一旦进入团队协作或者生产环境就是灾难。所以ai-engineering-from-scratch的第一层含义我认为是先把工程基础打好再谈AI。2.2 技术选型的核心逻辑稳定优先渐进式引入在技术选型上我的原则一直是能用成熟方案就不用新方案能简单实现就不搞复杂架构。这不是保守而是被坑出来的经验。AI领域新技术层出不穷每周都有新的框架、新的工具但生产环境最怕的就是不稳定。举个例子模型服务这块很多人一上来就想用Kubernetes加各种微服务框架觉得这样才“专业”。但实际上如果你的QPS只有几十一个FastAPI加Gunicorn的简单服务完全够用部署和维护成本低得多。等到真的扛不住了再考虑上K8s也不迟。过早优化是万恶之源这句话在AI工程里同样适用。再比如实验管理有人喜欢用各种花哨的平台但我觉得最实用的还是最朴素的方案Git管理代码配置文件管理参数MLflow或TensorBoard记录指标。这套组合简单、可靠、可迁移不会因为某个平台倒闭或者改版就抓瞎。我的建议是在项目初期把精力放在数据管道和代码规范上这两块是地基。模型服务可以先跑通最小闭环后面再逐步优化。不要一上来就追求“架构先进”能跑通、能维护、能迭代比什么都重要。2.3 从零搭建的四个阶段我把AI工程能力的搭建分成四个阶段每个阶段有明确的目标和产出阶段核心目标关键产出常见误区第一阶段基础工程代码可维护、环境可复现规范的代码仓库、依赖管理、Docker环境忽视代码规范环境靠手动配置第二阶段数据管道数据可获取、可清洗、可版本化自动化数据脚本、数据版本管理数据靠手动下载清洗逻辑散落各处第三阶段训练工程化实验可复现、可对比、可调度配置化训练脚本、实验记录系统参数硬编码实验结果靠记忆第四阶段部署与运维服务稳定、可监控、可回滚模型服务、监控告警、回滚机制只关注上线不关注线上表现这四个阶段不是严格线性的实际工作中会有交叉但整体上应该按这个顺序来。跳过基础直接搞部署后面一定会返工。3. 核心环节拆解每个阶段到底怎么做3.1 基础工程把代码和环境管起来基础工程这块说起来都是老生常谈但真正做到位的人不多。我列几个必须做到的点代码规范。Python项目至少要用black做格式化isort做import排序flake8或ruff做静态检查。这些工具配置一次后面提交代码前自动跑一遍能省掉大量review时间。我见过太多项目光是代码风格就吵得不可开交最后谁也没说服谁。工具能解决的问题不要用人来解决。依赖管理。requirements.txt是最低要求但更好的做法是用poetry或pipenv能锁定版本、管理虚拟环境。AI项目特别容易遇到依赖冲突比如torch和transformers的版本兼容问题锁版本能避免很多麻烦。我的习惯是每个项目单独一个虚拟环境依赖文件提交到Git别人clone下来一条命令就能装好。Docker化。不要觉得Docker是运维的事AI工程师也必须会。一个Dockerfile写清楚基础镜像、依赖安装、代码拷贝、启动命令别人拿到就能跑不用问“你环境怎么配的”。我一般会用多阶段构建把训练环境和推理环境分开推理镜像尽量小减少部署时的传输和启动时间。# 训练环境示例 FROM pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [python, train.py]Git工作流。至少要有main和dev两个分支功能开发在feature分支上通过PR合并。commit message写清楚做了什么不要写“update”或者“fix bug”这种没信息量的。我自己的习惯是每个commit只做一件事方便回滚和排查。3.2 数据管道AI工程里最容易被低估的环节数据这块我的观点很明确AI项目80%的问题出在数据上但80%的精力被花在了模型上。这是极其不合理的。数据管道没做好后面训练再花哨也是白搭。数据管道要解决几个核心问题数据获取。数据从哪来是数据库、文件、API还是爬虫获取频率是多少增量还是全量这些都要想清楚。我一般会写一个独立的data_loader模块把数据获取逻辑封装起来上层训练代码不关心数据从哪来只关心拿到的是干净的数据。数据清洗。这是最耗时间也最考验经验的环节。文本数据要去重、去噪、处理编码问题图像数据要检查损坏、统一尺寸、处理标注错误。我的经验是清洗逻辑一定要写成可复用的函数并且加上单元测试。不要在一个Notebook里手动清洗那样没法复现也没法维护。数据版本化。数据变了模型效果可能就变了。所以数据也要像代码一样版本化。小数据集可以直接用Git LFS管理大数据集可以用DVC或者自己搭一个简单的版本管理系统。关键是要能回答“这个模型是用哪版数据训的”这个问题。实操心得数据清洗脚本一定要加日志记录每一步处理了多少条、过滤了多少条、剩余多少条。这样出问题的时候能快速定位是哪一步出了岔子。我吃过亏一个去重逻辑写错了把正常数据也过滤了结果模型效果怎么调都上不去查了两天才发现是数据的问题。3.3 训练工程化让实验可复现、可对比训练脚本的工程化核心就一个词配置化。不要把参数硬编码在代码里不要靠改代码来调参。我推荐用Hydra或者简单的YAML配置文件把所有超参数、路径、模型结构都放在配置文件里代码只负责读取配置并执行。这样做的好处是实验可复现配置文件一存随时能重现当时的实验实验可对比不同配置跑出来的结果能清晰对比代码更干净训练逻辑和参数解耦代码更易读易维护# config/train.yaml model: name: bert-base-chinese num_labels: 10 dropout: 0.1 training: batch_size: 32 learning_rate: 2e-5 epochs: 5 warmup_ratio: 0.1 data: train_path: data/train.csv val_path: data/val.csv max_length: 128实验记录这块MLflow是我用得最顺手的。每次训练自动记录参数、指标、模型文件还能在UI上对比不同实验。如果不想引入额外依赖TensorBoard加一个简单的CSV日志也能凑合但MLflow的体验确实好很多。还有一个容易被忽视的点随机种子。AI训练有大量随机性数据打乱、参数初始化、dropout都会引入随机。如果不固定种子同样的配置跑两次结果可能差很多根本没法对比。所以训练脚本开头一定要固定所有随机种子包括Python、NumPy、PyTorch的。3.4 部署与运维上线只是开始模型部署这块我的建议是从简到繁。最开始用一个FastAPI服务把模型包起来提供HTTP接口就足够了。不要一上来就搞模型服务器、搞微服务、搞K8s那些是规模上来之后才需要考虑的。一个最简单的模型服务大概长这样from fastapi import FastAPI from pydantic import BaseModel import torch app FastAPI() model torch.load(model.pt, map_locationcpu) model.eval() class Request(BaseModel): text: str app.post(/predict) def predict(req: Request): with torch.no_grad(): inputs tokenizer(req.text, return_tensorspt, truncationTrue, max_length128) outputs model(**inputs) pred outputs.logits.argmax(dim-1).item() return {label: pred}启动命令用gunicorn加uvicorn worker能支持一定的并发。如果QPS再高可以考虑用ONNX Runtime或者TensorRT做推理加速或者上Triton Inference Server。但这些都是后话先把最小闭环跑通。监控这块至少要记录每个请求的延迟、输入输出的长度分布、错误率。这些指标能帮你发现很多问题比如某个输入特别长导致延迟飙升或者某类输入总是预测错误。日志用结构化格式JSON方便后续分析。回滚机制也很重要。模型上线后效果不好怎么办要能快速切回上一个版本。我的做法是模型文件按版本号命名服务启动时指定版本回滚就是改个配置重启。简单但有效。4. 实操过程从零到一跑通一个完整项目4.1 项目初始化十分钟搭好骨架假设我们要做一个文本分类项目从零开始。第一步是搭骨架mkdir ai-project cd ai-project git init mkdir -p src data configs models logs tests touch README.md .gitignore requirements.txt.gitignore要排除数据文件、模型文件、日志、虚拟环境这些不该进Git的东西data/ models/ logs/ __pycache__/ *.pyc .venv/ .env然后配置pyproject.toml或者requirements.txt把核心依赖列清楚。我一般会分requirements.txt和requirements-dev.txt训练和推理的依赖也尽量分开减少镜像体积。4.2 数据准备写一个靠谱的清洗脚本数据清洗脚本我一般放在src/data/下面结构大概是src/data/ __init__.py loader.py # 数据加载 cleaner.py # 清洗逻辑 splitter.py # 训练验证集划分cleaner.py里每个清洗函数都要有明确的输入输出和日志import logging import re logger logging.getLogger(__name__) def remove_duplicates(texts): seen set() result [] for t in texts: if t not in seen: seen.add(t) result.append(t) logger.info(f去重: {len(texts)} - {len(result)}) return result def clean_text(text): text re.sub(r\s, , text) text text.strip() return text清洗完的数据存成parquet格式比CSV读取快而且能保留数据类型。划分训练验证集的时候固定随机种子保证每次划分一致。4.3 训练脚本配置化加日志训练脚本的核心结构import yaml import random import numpy as np import torch from transformers import AutoTokenizer, AutoModelForSequenceClassification, Trainer def set_seed(seed): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) def main(config_path): with open(config_path) as f: config yaml.safe_load(f) set_seed(config[seed]) # 加载数据、模型、训练...关键点所有参数从配置读随机种子固定训练过程用Trainer的callbacks记录指标到MLflow或TensorBoard。训练完保存模型时把配置文件和模型一起存方便追溯。4.4 模型服务最小可用加监控服务代码前面已经给了示例补充几个实操细节模型加载放在服务启动时不要每次请求都加载输入要做长度限制和异常处理防止恶意输入打挂服务加一个/health接口方便健康检查日志记录请求ID、输入长度、预测结果、耗时import time import uuid import logging app.post(/predict) def predict(req: Request): req_id str(uuid.uuid4()) start time.time() try: # 推理逻辑 result {label: pred} latency time.time() - start logger.info(freq_id{req_id} input_len{len(req.text)} label{pred} latency{latency:.3f}) return result except Exception as e: logger.error(freq_id{req_id} error{str(e)}) raise4.5 部署上线Docker加简单编排推理服务的Dockerfile要尽量精简FROM python:3.10-slim WORKDIR /app COPY requirements-serve.txt . RUN pip install --no-cache-dir -r requirements-serve.txt COPY src/serve/ ./serve/ COPY models/ ./models/ EXPOSE 8000 CMD [gunicorn, -k, uvicorn.workers.UvicornWorker, -w, 2, -b, 0.0.0.0:8000, serve.app:app]-w 2是两个worker根据CPU核数调整。部署用docker-compose就够了一个服务加一个监控简单明了。等真的需要横向扩展了再考虑K8s。5. 常见问题与排查技巧实录5.1 训练相关的高频问题问题一同样的配置两次训练结果差很多。原因基本是随机种子没固定全。除了Python、NumPy、PyTorch还要注意cudnn的deterministic设置以及DataLoader的worker_init_fn。如果用了多卡训练还要固定每张卡的种子。问题二训练loss不下降或者震荡严重。先检查数据有没有问题标签对不对输入格式对不对。然后看学习率是不是太大batch size是不是太小。我遇到过一次数据清洗时把标签列也当文本处理了导致标签全错loss当然不降。排查的时候先打印几条数据和标签看看往往能快速定位。问题三显存不够。优先减小batch size然后考虑梯度累积。如果还不够用混合精度训练torch.cuda.amp能省不少显存。再不行就上梯度检查点gradient_checkpointing用时间换空间。5.2 部署相关的高频问题问题一服务启动慢。模型加载是大头。如果模型很大可以考虑用torch.jit或者ONNX加速加载或者用内存映射文件。另外Docker镜像层要合理利用缓存依赖安装和代码拷贝分开改代码不用重装依赖。问题二推理延迟高。先看是不是CPU推理能用GPU就用GPU。然后看输入长度长文本推理慢是正常的可以在服务层做截断。再就是模型本身可以考虑量化、蒸馏、剪枝这些优化手段。但优化之前先用profiler定位瓶颈在哪不要盲目优化。问题三线上效果和离线评估不一致。这是最头疼的问题之一。常见原因有训练和推理的预处理不一致比如tokenizer参数不同、数据分布变了、特征计算逻辑不同。排查方法是把线上请求的输入存下来离线跑一遍对比结果。我一般会在服务里加一个采样日志把部分请求的输入输出存下来方便排查。5.3 常见问题速查表问题现象可能原因排查方向解决方案训练结果不可复现随机种子未固定检查所有随机源固定Python/NumPy/PyTorch/cudnn种子loss不下降数据问题或学习率过大打印数据和标签检查数据质量调小学习率显存不足batch size过大或模型过大查看显存占用减小batch梯度累积混合精度服务启动慢模型加载耗时计时模型加载模型优化镜像分层缓存推理延迟高CPU推理或输入过长profiler定位GPU推理输入截断模型量化线上线下不一致预处理不一致对比预处理逻辑统一预处理代码采样日志排查独家避坑技巧每次上线新模型前一定要做A/B测试或者灰度发布。不要一次性全量替换万一效果不好影响面太大。我一般会先切10%的流量观察一天指标正常再逐步放大。这个习惯帮我避免了好几次线上事故。6. 我踩过的那些坑和最后的小建议说几个我印象最深的坑。第一个是数据泄露做特征的时候不小心把标签相关的信息也放进去了离线评估指标特别好上线后一塌糊涂。这个坑让我养成了习惯每次做完特征都要检查一遍特征和标签的相关性异常高的特征要警惕。第二个是环境不一致本地训练用的是PyTorch 1.12服务器上是1.13结果模型加载报错。从那以后我所有项目都用Docker本地和服务器用同一个镜像彻底解决环境问题。第三个是日志没打好线上出问题的时候日志里只有一句“error”什么上下文都没有排查全靠猜。后来我强制要求所有关键路径都要打结构化日志包含请求ID、输入摘要、错误堆栈排查效率提升了好几个档次。最后分享一个小技巧养成写README的习惯把项目的环境配置、数据准备、训练命令、部署步骤都写清楚。不是为了别人是为了三个月后的自己。我经常翻自己以前的项目如果没有README重新跑起来要花半天有了README十分钟就能恢复环境。这个投入产出比高得离谱。AI工程这条路入门不难但做好需要时间积累。不要急着追新框架新工具把基础的数据管道、代码规范、部署流程做扎实后面学什么都快。我到现在还在不断补工程方面的知识这块没有捷径就是多做、多踩坑、多总结。希望这篇内容能帮你少走点弯路。