很多人以为学会调几个模型、能跑通训练脚本就算是入门 AI 工程了。我在这个领域摸爬滚打几年之后回头看真正让项目落地的往往不是模型有多新而是你有没有把数据、训练、部署、监控这一整条链路理顺。ai-engineering-from-scratch这条路难的不是某个算法而是工程思维的重建——从“能跑”到“稳定跑”从“我自己能复现”到“团队其他人也能接手”中间隔着一整套习惯、工具和踩坑经验。这篇文章就把我自己的从零经验拆开讲适合刚入行的工程师、想转 AI 方向的后端开发还有那些已经在写模型但总觉得交付吃力的人。1. 为什么从“调模型”到“做工程”会卡壳1.1 研究代码和工程代码的差别好多教程里的代码都是给研究者写的一个 Jupyter Notebook数据读进来模型定义好训练几十个 epoch画个 loss 曲线收工。这种代码在一个固定环境下、对一组固定数据是够用的。一旦进入工程场景事情就变了数据会更新特征分布会漂移样本量可能扩大上百倍部署环境跟训练环境不是同一台机器还要面对并发请求、超时重试、资源耗尽这些“模型之外”的问题。我见过不少简历上写着“熟悉 PyTorch”的候选人一让他把训练好的模型封装成 API就不知道从哪下手了。问题不出在模型本身出在他从来没把“模型”当成一个需要被周围系统托举的组件。工程代码关心的是接口契约、异常处理、资源边界、幂等性、可观测性这些在研究代码里基本都被省略了。从零开始做 AI 工程第一步就是转变视角你不再是“训练一个模型”而是在“构建一个持续运转的系统”。1.2 AI 工程真正交付的是“系统”不是“模型”很多团队把 AI 项目拆成“先做模型再上线”好像模型是最后交付物。实际上业务方感知到的价值来自整个系统数据那边有没有稳定产出、模型推理快不快、推荐结果能不能在几百毫秒内返回、失败时是优雅降级还是直接报错。模型只是系统中的一个核心组件但绝对不是全部。举个我自己的例子。之前做过一个文本分类服务模型是 BERT 微调出来的离线评测 AUC 有 0.96。上了线之后发现两个问题线上文本经常带 HTML 标签清洗逻辑在训练集里没体现另一个是请求高峰时 GPU 显存被打满服务直接 OOM。模型本身没变但系统的表现完全取决于预处理、特征映射、资源调度这些工程细节。所以我现在看任何 AI 项目先不看模型结构先看它怎么处理数据、怎么部署、怎么监控。这些才是从零到一最需要搭起来的地基。1.3 哪个环节最容易被低估如果让我说新手最容易低估的环节排第一的是数据。决定模型上限的是数据质量不是网络结构。第二是评估方式很多人拿一个离线指标做决策但离线指标和线上业务指标经常对不上。第三是依赖管理模型还没跑起来环境已经把时间耗光了。这并不意味着算法不重要而是说算法在工程链条里的比例被过度放大了。真正从零开始的时候应该按“数据占比 40%、训练评估占比 25%、部署监控占比 25%、业务对接占比 10%”这个比例来规划精力和资源。这个比例不是精确计算出来的而是我复盘多个项目后的体感你大概率也会得出类似的结论。2. 从零开始的技能拆解四根必须补上的柱子2.1 数据处理能力80% 的工作量都在这数据处理不是简单的 pandas 读写。工程化要求的是可重复、可追溯、可测试。你每次训练用的数据集应该能回溯到原始来源和处理代码版本。这里要养成几个习惯原始数据永远不原地修改每一次清洗都生成新版本数据集。清洗脚本用 DVCData Version Control或类似工具管理跟代码一起走版本。在训练之前做一次数据质量检查包括缺失值比例、类别分布、异常值生成报告留档。我常用的组合是 Polars 或 pandas 做数据清洗DVC 管版本Great Expectations 做数据校验。数据量大到单机处理不动再引入 Spark 或 Ray但绝大多数从零开始的场景用不着那么重的东西。特征工程也一样不要把所有特征逻辑写在训练脚本里。把特征定义抽成独立模块训练和推理共用。否则你训练时生成的特征和线上推理时生成的特征口径不一致线上效果会悄悄劣化查起来极其痛苦。2.2 训练与评估的可复现性训练代码的可复现性核心是“随机种子、依赖版本、数据版本、超参数”四件套全部钉死。随机种子好理解但依赖版本经常被人忽略。你本地用 PyTorch 2.1 跑出来的结果到同事的 PyTorch 2.3 环境里可能就不一样尤其是涉及 CUDA 算子实现时。建议用固定版本锁文件训练前记录pip freeze或者直接用容器镜像。评估的可复现性更要命。我见过不少项目评估脚本里悄悄改过 label 映射结果跑出来精度高了一个点但部署后完全没有那个表现。我的做法是评估脚本必须独立于训练脚本输入的是保存好的预测结果文件输出的是标准的 classification report外加业务自定义指标。这样任何一次结果都能复核。超参数管理用配置文件而不是命令行参数满天飞。我倾向用 YAML 配置文件配合 dataclass 校验训练时记录一份解析后的完整配置。这样别人拿到你的项目不需要问你“这个值当时是怎么设的”直接看配置就行。2.3 服务化与 API 设计模型训练好之后第一步是把它封装成可调用的服务。最基础的做法是用 FastAPI 包一层加一个/predict接口。但工程化不只是这样。你需要考虑请求和响应的 schema用 Pydantic 定义并且做版本化。预处理逻辑放在服务里还是在客户端我的建议是放在服务端这样保证所有调用方都走同一套预处理。超时和重试策略。模型推理偶尔会慢合理的超时设置能防止请求堆积。批量推理与单条推理的取舍。小并发直接走同步接口大吞吐场景用批处理或者异步队列。我自己的习惯是先把模型导出成 ONNX再用 ONNX Runtime 跑推理这样能脱离 PyTorch 的环境依赖推理速度也会快一些。如果追求极致或者是 GPU 场景再考虑 Triton Inference Server。服务写完之后用locust或wrk做一次压测确认吞吐和延迟在你预期的范围内。2.4 监控与反馈闭环模型上线不是终点是起点。你需要知道它在线上到底表现如何。最基础的监控是三块服务健康状态QPS、延迟、错误率、资源使用CPU/GPU 显存、数据漂移输入特征分布是否和训练时一致。数据漂移检测经常被新手忽略。你用一个固定阈值判断输入文本长度是否异常结果业务上线三个月后用户行为变了输入长度普遍变长模型质量就悄悄掉下来。做法可以是定期对线上采样的数据做分布统计和训练分布做双样本检验比如 PSI超过阈值就告警。反馈闭环的意思是预测结果要能回流到标注系统形成新的标注数据再进入下一轮训练。这一步很多团队都没做导致模型永远是“一次性”的。从零开始的话可以先做一个简单的“预测结果用户行为”日志表每周定时导出、抽样校验再人工标注补充训练集。3. 端到端实操路线三个月打下地基3.1 第一个项目选什么最合适从零开始做 AI 工程最忌讳一上来就挑战大模型预训练或者多模态系统。选项目要满足三个条件数据能公开获取、业务目标清晰、模型可选范围广。我推荐文本情感分类或者文本多标签分类理由很简单数据容易找模型可以从 TF-IDF逻辑回归出发一路做到 BERT 微调跨度足够大能覆盖从传统 ML 到深度学习的典型路径。这个项目不要只停在训练。两个关键扩展点一是把模型用 FastAPI 封装做一个 Web 小应用二是加入用户反馈按钮模拟真实闭环。完成之后你至少掌握了数据清洗、模型训练、服务部署、简单监控这四件事已经比 70% 的教程党强了。3.2 数据集的选择和清洗用现成的数据集推荐 IMDB 电影评论或者中文的酒店评论数据。起步别挑太干净的公共数据集最好找带一点噪声的。真实业务里的数据永远不会像教科书那么整齐你需要主动制造几个坑来练手去掉一部分标签模拟缺失标注。在文本里加入一些 HTML 标签和特殊字符。把训练集和测试集的分布稍微弄偏一点模拟数据漂移。清洗逻辑写成独立函数每个函数只做一件事并配上测试。这一步看着费时间但它是你后续所有工作的根基。清洗规则至少包括去 HTML、统一小写、处理特殊符号、空值填充、切分验证集。不要过度清洗保留文本中的语义信息比追求“干净”更重要。3.3 模型选择与训练的工程化思考对新手来说不要一上来就迷信复杂模型。先用 TF-IDF 逻辑回归跑一个基线看看效果。基线模型的好处是训练快、可解释、逻辑简单方便你快速验证整个数据管线和评估管线有没有问题。我的习惯是基线模型必须能在 5 分钟之内训练完超过这个时间说明管线太臃肿了。基线跑通之后再尝试 DistilBERT 这类轻量预训练模型。此时要测试一下显存和训练时间确认自己的机器能扛得住。记住一个原则训练迭代要快速度和迭代频率比单次精度更重要。如果你的一个训练实验要跑 4 小时那你一天最多调两次参数这种效率很难做出好模型。训练脚本的组织方式也很关键。推荐用 PyTorch Lightning 或者 Hugging Face Trainer 这一类框架把训练循环封装起来让你专注在模型结构和数据处理上。同时加入 early stopping 和模型检查点保存避免浪费算力和时间。3.4 部署上线从模型文件到稳定服务模型导出成 ONNX 之后写一个 FastAPI 服务。示例逻辑大致是加载 ONNX 模型和 tokenizer 映射文件初始化全局变量避免每次请求重复加载。定义一个PredictRequestPydantic 模型字段包括文本、可选的阈值参数。预处理函数和服务解耦preprocess(text) - input_dict方便单独测试。推理逻辑把输入转成 numpy 数组交给 ONNX Runtime输出概率再映射分数。启动服务之后先用几个真实样本 curl 测试再写一个自动化测试文件。测试通过之后用 Docker 打包镜像里只装 ONNX Runtime 和必要依赖不装训练框架这样镜像能小很多。如果有 GPU考虑在 Docker 里挂载 GPU 资源同时限制max_batch_size防止突发流量把所有显存耗尽。没有 GPU 也不要紧ONNX Runtime 在 CPU 上对单条推理完全够用关键是用对量化策略。4. 实战中的坑那些没人系统讲但一定会踩的4.1 环境依赖的连锁炸弹我入行第二年干的最后悔的一件事就是在一个生产环境的容器里执行了pip install --upgrade pip结果把系统依赖里的包全升了级模型服务直接启动失败。这个教训价值几千块钱的加班费。现在我的铁律是用虚拟环境或者容器隔离一切项目依赖升级包之前先看依赖树生产环境镜像的依赖版本全部锁定绝不更新次要版本。Python 依赖工具我推荐uv或者pip-tools管理生成requirements.lock。遇到版本冲突优先用 Docker 重建干净环境不要在现有环境里强行解决。另外CUDA 版本和 cuDNN 版本要跟 PyTorch 的 wheel 包自带版本对齐很多同学搞不清这个导致本地能跑到服务器就报no kernel image is available。4.2 显存和内存的隐形消耗训练阶段经常看到显存莫名其妙涨上去一个原因是 DataLoader 的num_workers设置过大数据加载本身没问题但worker进程频繁 fork内存成倍增长。另一个常见原因是输入序列没有 padding 到相同长度或者 padding 策略过于激进导致 batch 里大量无意义 token 占显存。解决思路是对训练文本按长度分桶同一个 batch 内序列长度尽量接近开启torch.utils.data.dataloader的pin_memory定期用torch.cuda.reset_peak_memory_stats监控峰值。推理阶段如果显存紧张优先考虑动态批处理而不是把 batch 设成一个很大的固定值。4.3 评估指标离业务太远离线指标和线上指标脱节是最隐蔽的坑。比如做一个客服工单分类模型离线看 accuracy 达到了 92%上线之后运营反馈“压根没用”。原因可能是线上类别分布和训练集差异大也可能是运营更关心的是少数重点类别的召回率而不是总体 accuracy。我现在的做法是业务方需要什么就用什么指标评估。如果业务目标是“工单分错之后能自动转人工减少 50% 的误分”那我要定义的是一个级联流程的端到端指标而不是单个模型的 accuracy。评估指标必须和业务方一起定并且要在模型上线前确认不然你训得再辛苦对方也不会买账。4.4 延迟和吞吐的取舍做在线推理服务latency 和 throughput 是一个跷跷板。你为了压榨并发把 batch 设大延迟会上升为了追求单条延迟把并发限制得很小吞吐又上不了。解决思路是给不同的请求分配不同的 batch 策略或者引入队列做异步推理。我踩过的坑是给一个本来应该同步返回结果的接口硬生生做了异步化前端等得抓狂后来想通了不要为了所谓“高性能”而给系统引入复杂度先满足业务方的响应时间预算再考虑吞吐优化。压测的时候注意不要只看平均延迟要看 P99。平均延迟漂亮但 P99 飙高的系统在真实流量下很容易出事故。5. 把 AI 工程能力落地到团队协作和长期成长5.1 代码规范和评审习惯AI 项目最容易乱的是 Notebook。我建议所有核心逻辑都以.py模块存在Notebook 只用作可视化和演示。代码风格上AI 项目也要 lint、format、类型标注不能因为是“算法代码”就放松要求。我自己用ruffmypy简单直接配合 pre-commit提交前自动检查。团队协作里模型文件不直接提交到 Git 仓库用模型注册表比如 MLflow Model Registry管理。这样每个模型都有版本、参数、指标、来源记录上线和回滚都有据可查。规则很简单没有注册的模型不允许进生产。5.2 从单点技能到 MLOps 意识做到后期你会发现AI 工程里“训练算法”只占一小部分更多精力花在“构建机器学习基础设施”上。MLOps 就是把这套东西体系化的实践。核心能力包括端到端流水线编排从数据到训练到部署、实验管理、模型监控、自动重训策略。自己搭一套完整的 MLOps 栈可以从开源工具开始MLflow 管实验和模型Airflow 或 Prefect 管调度Prometheus Grafana 管监控Docker Kubernetes 管部署。不要一开始就上大平台先手工打通一条流水线再逐步自动化。自动化程度取决于业务阶段创业早期过度追求平台化反而拖慢节奏。5.3 持续输入和复盘的习惯AI 工程领域变化太快今天我用的某些工具明年可能就淘汰。我保持学习的方式是定期挑一个开源项目把它完整跑起来并写一篇复盘笔记跟踪自己关心领域的最新论文不看公式也行但要理解它解决了什么问题每年至少做一个“从数据到部署”的完整新项目不依赖公司业务。复盘的习惯比学习更重要。每上线一个模型我都会写一份简短的事后分析数据、模型、部署、监控哪个环节出了问题下次怎么避免。这些都是从零开始最好的养料比读一百篇文章都管用。我个人在实际操作中最深的体会是AI 工程不是某一门学科的垂直延伸而是一套把“不确定性”关进笼子里的实践方法论。数据会变、模型会退化、环境会崩你能做的就是让每一步都可以回滚、每一次实验都可以追溯、每一项指标都可以跟业务对上话。从零开始固然辛苦但当你第一次把一个模型从杂乱的数据里洗出来、部署成稳定的服务再看着监控曲线平稳走过一个月的时候那种成就感是纯粹的“调参”给不了的。如果你也在这条路上建议先挑一个小项目把这条链路完整打一遍你就会明白自己最该补的到底在哪一块。