把AI工程单独拎出来讲是因为我见过太多人把“跑通一个模型”当成“完成一个AI项目”。模型在Notebook里跑出95%准确率可一旦要接进生产系统数据对不上、接口返工、上线两周效果就崩这类问题几乎每天都在发生。ai-engineering-from-scratch 讲的不是某个新框架也不是某个大厂的内部方案而是一条从零开始构建AI工程能力的完整路径。这篇文章想把这个路径拆开聊清楚AI工程到底在解决什么问题、为什么从零开始学反而是最快的方式以及一个普通人照着做能落到实处的操作清单。适合谁看想转行做AI应用开发的工程师、已经在做算法但总被“工程化”折磨的同学以及团队里需要牵头搭AI基础设施的技术负责人。内容不预设你已经懂分布式训练也不需要你有架构师背景只要你写过一些代码、跑过模型就能跟着往下走。1. AI工程到底是什么别把调参当工程1.1 一个模型不等于一个系统很多人刚接触AI时注意力全放在模型结构、损失函数、训练技巧上这没有错但只盯着模型很容易忽略一个问题真实业务需要的是一个系统而不是一个孤立的模型文件。系统意味着你要有稳定的数据入口模型要有明确的输入输出边界推理结果要能被校验、被记录、被追踪错了还要能回滚。我把这个阶段叫“从模型到系统的鸿沟”。模型是系统里最聪明但也是最脆弱的一部分它依赖数据分布依赖训练时的随机种子甚至依赖推理时的显存大小。而工程要做的就是把这些不确定性管起来数据变了能发现模型版本乱了能追回服务挂了能重启延迟高了能扩容。如果在做第一个AI项目时就把这些考虑进去后面返工的成本会小很多。1.2 从零开始的真正含义ai-engineering-from-scratch 这个说法核心不是让你从线性代数开始重学而是把AI工程拆成数据、训练、推理、评估、运维这几个模块每个模块都从最小可用版本开始搭建理解每一层为什么存在再逐步叠加复杂度。这样做的好处是你不会一开始就被 K8s、GPU 集群、特征平台这些高台吓退而是先用手里的电脑跑通一个端到端用例再一层层补齐。这个路径和常见的“先学框架再找项目”正好相反。它要求你先有一个非常小的目标比如做一个本地运行的文本分类服务然后逼自己解决数据清洗、模型训练、接口封装、效果监控这一连串问题。每一步都看得见摸得着比单纯刷教程要扎实得多。很多人学AI喜欢囤课、囤论文就是不动手这条路径最核心的价值就是逼你动手动一次手比读十篇文章有用。1.3 适合谁走这条路如果你是还在学校里、没有任何工业项目经历的学生这条路能帮你把简历上的“熟悉机器学习”变成“能独立完成一个可运行的AI服务”。如果你是在职工程师想从后端转AI应用这条路径比直接啃算法论文更高效因为AI工程岗位要求的是端到端交付能力不是单点知识点。如果你已经是算法工程师也能从中找到自己薄弱的地方——很多人训练很熟但一提到服务化、监控、CI/CD就头疼这些正是工程化的硬骨头。这条路不要求你有很强的数学背景但要求你有“把事情做完”的耐心。很多人在第一步“跑通最小系统”就放弃了恰恰是因为他们老想着用最完美的架构结果连一个能用的东西都没做出来。所以从零开始与其说是技术路线不如说是一种刻意练习的方法它把复杂问题拆成可完成的小块每完成一块都有正反馈。2. 从零开始的技术栈工具选型的底层逻辑2.1 语言与框架Python之外的考量技术栈的第一件事是选语言。绝大多数AI工程场景Python仍是首选因为它生态最完整PyTorch、Hugging Face Transformers、FastAPI 这一套组合能覆盖从模型训练到服务发布的全部环节。但Python不是唯一答案。如果你们公司的核心业务是Java或Go推理服务用 Python 写会带来跨语言调用和部署隔离的问题很多团队会选择把模型导出成 ONNX 或 TensorRT由 Java/Go侧加载Python只负责训练和离线评估。我的建议是从零开始时别纠结这个默认用 Python PyTorch 是最稳的等真的遇到性能天花板再拆分。框架方面PyTorch 目前生态最成熟新模型发布基本都优先支持TensorFlow 在部分生产环境仍有存量但学习曲线和对新特性的支持都不如 PyTorch 友好。还有一个容易被忽略的点是 Python 版本管理建议一开始就用 3.11 或 3.12尽量别用系统自带的 Python 环境否则后面装包、跑训练很容易被环境问题打断。2.2 数据、训练、推理、评估四条线AI工程的技术栈可以按数据、训练、推理、评估四条线拆开看每条线选一个核心工具选型逻辑是“越简单越好、越透明越好”。先说数据。数据文件的管理最好用 DVCData Version Control它能像 Git 管理代码一样管理数据集版本。很多团队一开始把数据放在网盘或共享文件夹里模型训练完想复现却发现数据已经被改了这种事我见过太多次。DVC 的核心理念是“数据不复制只记录元数据和指针”配合对象存储或本地磁盘就能用不需要额外搭数仓。数据版本化还有一个额外好处当线上出现 bad case 时你能准确知道当前模型是在哪一份数据上训练的从而判断是该补数据重训还是调整预处理逻辑。训练这条线我自己习惯用 PyTorch Lightning 或者直接写原生 PyTorch 训练脚本。如果你是一个人的项目写原生脚本更直观能理解每个环节在干什么如果是团队协作或者要跑很多组实验Lightning 的 Trainer 能帮你节省大量模板代码。实验追踪用 MLflow 或 Weights Biases二选一即可。MLflow 是开源工具支持自托管可以同时记录指标、参数、模型文件很适合从零搭建的团队WB 交互体验好但属于 SaaS团队数据敏感性高时要慎选。实验追踪这件事越早做越好别等跑了几十组实验才想起回溯。推理和评估可以放在一起说。推理服务用 FastAPI 起步是最快的它自带 OpenAPI 文档方便调试评估则一定要留一套离线评测脚本不要只在训练时看指标。比如文本分类至少准备准确率、召回率、F1 以及一些坏例样本每次模型迭代后跑一遍把它当成单元测试对待。更进一步可以把评测脚本接入 CI每次代码变更都自动跑一次模型质量波动一眼就能看出来。2.3 基础设施与自动化先别上K8s我看到很多人从零开始时第一件事就是搭 Kubernetes 集群这是个非常典型的资源错配。一个人或者一个小团队前期根本用不到容器编排一个 Docker 容器 systemd 服务就够跑上几个月。K8s 的价值在于大规模服务治理和弹性伸缩前提是你已经有稳定的流量和多个服务前期上 K8s只会把问题从“模型效果不好”变成“Pod 起不来”。更务实的做法是用 Docker 把训练和推理环境封装好模型服务用 Docker Compose 本地编排加一个 Supervisor 或 systemd 做进程守护再配一个最简单的健康检查接口。等服务多了、流量上去了再引入 K8s 也不迟。自动化方面GitHub Actions 或 GitLab CI 先跑 lint、单元测试和离线评估任务镜像自动构建也可以后续再加。别一开始就追求完备的 MLOps 平台从一两个自动化脚本开始效果反而更好。原因很简单自动化工具本身也有学习成本如果连基本的训练脚本都不稳再牛的调度平台也救不了你。3. 一条可复现的实操路线三阶段推进法3.1 阶段一跑通一个端到端最小闭环无论你最终想做什么方向都建议先选一个非常小的任务比如情感分类、垃圾邮件识别、或者简单的命名实体识别。目的是用最快速度把全链路串起来而不是把模型效果做到极致。最小闭环包含四步准备50到100条标签数据把数据从CSV或JSON读进来用 Hugging Face 的 pipeline 加载一个小模型比如 distilbert-base微调几个epoch把模型保存成文件夹再用 FastAPI 写一个 POST 接口输入文本返回预测结果。这里有一个容易被忽略的细节从第一步开始就要固定随机种子并且把每次实验的配置、数据和模型版本记录下来。哪怕这个最小闭环看起来简陋也要把这些“工程习惯”嵌入进去。因为我见过很多人在这个阶段图快等后面要复现实验结果时已经完全记不清当初用的数据是哪份、超参数是多少了。一次能复现的实验比一个偶然的好结果更有价值。一个最简单的 FastAPI 推理接口大概长这样from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class TextInput(BaseModel): text: str app.post(/predict) def predict(item: TextInput): result model(item.text) return {label: result[label], score: result[score]}这个接口不复杂但已经包含了输入校验、结构化输出和可调试性。把它跑起来后你就有资格说“我完成了一个AI服务”了。3.2 阶段二建立可重复的数据与训练管线最小闭环跑通后第二步是把训练过程从“手动记事本”变成“可重复的脚本化流程”。数据侧用 DVC 把原始数据和标注结果纳入版本管理每次新增样本或修改标签都能 diff 出变化。训练侧把训练脚本的参数用配置文件管理超参数、数据路径、模型名称、输出目录全部抽出来。我建议用 Hydra 或者 YAML 配置配合 argparse让每次训练都留下完整参数痕迹。这阶段还要引入实验追踪。每跑一次训练记录训练集、验证集指标、loss 曲线、模型文件地址。这样你在跑完十次实验后才能对比出哪组参数真正有效。很多新手训练失败后喜欢马上改代码重跑这其实是在碰运气。正确做法是先把实验记录整理清楚分析是数据问题还是模型问题再决定下一步。这一步看起来繁琐但省下来的调试时间通常是十倍以上。作为参考一个典型的训练命令可能长这样python train.py \ --config configs/exp001.yaml \ --data data/version_003 \ --model distilbert-base-uncased \ --output runs/exp001记录下这条命令和对应的 metrics就是一次可追踪的实验。后续想切回某个效果好的模型直接找到对应 run 目录即可。同时建议把训练日志同步到 MLflow 里这样后续对比实验时不用再翻命令行历史。3.3 阶段三把模型变成稳定服务FastAPIDocker监控三步走模型训练好了接下来要考虑的是让它在生产环境里稳定跑起来。第一步用 FastAPI 封装推理接口服务里除了推理逻辑一定要加一个 /health 健康检查端点和 /predict 推理端点。健康检查返回服务存活状态方便监控系统判断推理端点里要做输入校验避免脏数据直接进模型导致崩溃。第二步写 Dockerfile把 Python 依赖、模型文件、启动脚本都打进镜像。这里有个坑很多人习惯在容器里重新下载模型这是个大坑。生产环境应该把模型文件提前放到镜像里或挂载到磁盘上服务启动时直接加载避免启动时去拉模型导致超时。镜像构建好后本地用 docker-compose 把它和监控组件一起跑起来先用真实请求测一遍。第三步接上监控。最少需要记录三类指标请求量、推理延迟、错误率以及一个模型质量指标比如分数分布或人工抽样的bad case。用 Prometheus 采集指标、Grafana 画面板是最常见的组合两个服务都不大资源占用也低。很多人觉得监控是运维的事但模型服务的监控和普通Web服务不一样你不仅要知道服务挂了没还要知道“模型输入数据分布是不是变了”后者才是AI工程真正难的地方。4. 实操中的常见问题与排查技巧实录4.1 模型离线好、在线烂数据分布漂移最经典的问题就是离线验证集上准确率95%上线后用户反馈一塌糊涂。原因几乎都是数据分布漂移。训练数据太干净线上数据太脏或者业务变了标签定义没跟上。排查思路是别上来就重训模型先对比线上输入和训练集输入。把线上收到的文本长度、关键词、字符类型分布拉出来和训练集分布画在一起看看。如果是文本分类可以统计线上请求里有多少字符是训练集里没出现过的或者有多少字段缺失。如果漂移明显优先采集线上数据补充训练集做一轮增量训练。这里还有一个长期解法在推理服务里记录一段时间的输入样本定期抽样做人工评估。宁可冗余地把线上样本存下来也别在出问题时拍着脑袋猜。数据漂移是AI系统衰减的头号原因它不像代码Bug那样立刻暴露而是缓慢发生所以必须靠监控和数据沉淀来兜底。4.2 训练loss曲线诡异先查数据再查代码训练的时候遇到loss不降、乱跳、或者降到0.1后突然冲高很多人第一反应是调学习率或者换模型。我的建议是遵循“数据、代码、模型”的排查顺序。先确认数据的标签是不是对有没有空值、脏值、重复样本再确认数据预处理和训练代码里有没有sample顺序泄露最后再看模型结构、学习率、batch size。举个例子我遇到过文本分类训练loss在验证集上完全不降排查半天发现是DataLoader里shuffle参数被设成False导致模型每个epoch看到的样本顺序完全一样模型学到了顺序规律而不是语义规律。这种问题不看数据加载代码根本发现不了。另外如果你发现loss下降但验证集指标不动往往不是代码问题而是评估逻辑写错了比如标签对了但评估时用了错误的索引。所以训练阶段一定要把评估脚本单独拆出来不要顺手写在训练循环里。4.3 推理延迟压不下去量化、批处理、缓存上线后服务吞吐不够延迟P99飙到几百毫秒这是AI工程最常见的性能问题。别一上来就想换GPU或者换语言先做三件事。第一检查是否可以做静态批处理如果请求是异步场景比如批量文本审核可以把多个请求攒在一起喂给模型GPU利用率会大幅提升。第二尝试模型量化把FP16或INT8量化用起来很多CPU和GPU推理场景里INT8下模型体积缩小四分之三延迟能降一半以上效果损失通常控制在可接受范围。第三加缓存。对于内容推荐、重复查询类的场景同一个输入被反复请求的概率很高用Redis加一层结果缓存能直接抹掉重复计算。这里要提醒一下缓存键不要直接拼文本先做哈希和归一化否则输入里多一个空格都会造成缓存不命中。如果这三件事做完了延迟还压不下来再考虑更重的优化比如改用ONNX Runtime、TensorRT或者拆分成多个小模型做级联。优化手段适用场景预期收益风险动态批处理异步、高吞吐吞吐提升数倍增加单请求延迟INT8量化对延迟敏感场景延迟降低50%以上精度轻微损失结果缓存重复查询多消除重复计算需要缓存一致性ONNX Runtime多平台部署推理加速30%-60%算子兼容性检查4.4 从零搭建过程中最容易被忽视的协作问题最后一个常见问题不是技术而是协作。如果你的项目是团队开发从第一天起就要约定好模型版本、数据版本和接口版本的管理方式。接口结构要经过评审后再冻结不要今天加一个字段明天删一个字段。很多AI项目最终延期不是因为模型效果不够而是因为算法和开发之间在接口对接上反复拉扯。我的实操建议是模型预测的输出必须包含业务可解释的信息比如置信度、决策原因或bad case标记而不仅仅是一个标签。这样开发同学排查问题时有依据产品同学也更容易判断模型行为是否符合预期。另外哪怕团队只有两个人也要写一个最简单的README说明数据从哪来、模型怎么训练、服务怎么启动。从零开始往往最容易死在知识只存在于某个人脑子里一旦这个人请假项目就停摆。5. 写在最后的几条实操体会在做 ai-engineering-from-scratch 这类项目时我自己最大的体会是一定要把“完成一个可用系统”作为里程碑而不是把“模型效果最好”作为终点。模型指标再好如果没有人能把数据喂进去、把结果用起来它就没有工程价值。反过来即使模型效果只有80分如果数据管线、服务、监控都齐全它也是能持续迭代的好系统。一个小技巧送给大家每周固定留一点时间把这一周在数据、训练、推理、运维上遇到的问题和解决过程记录下来哪怕只是几条流水账。三个月后回头看你会发现自己避开的坑比学到的知识更有价值。另一个建议是学AI工程别追求“一次到位”先接受一个丑但能跑的方案然后逐步优化。大多数成功的AI项目都不是一开始就完美而是在一次次迭代里变得越来越可靠。AI工程的路很长但每一步都落地效果就会慢慢显现。
