1. 从会跑通代码到能做工程我在AI工程这条路上踩过的坑如果你已经在本地跑通过几个开源模型或者能跟着教程调通一个训练脚本那你大概率会有一种错觉好像AI也没有那么难嘛。但等你真正打算靠AI吃饭——不管是找工作、做产品还是接项目——就会发现以前那些经验远远不够。你面对的不再是一个notebook、一个demo而是一整套需要设计、权衡、迭代、维护的系统。模型怎么选、训练数据怎么管、推理用什么框架、显存不够怎么办、延迟和成本怎么平衡、线上效果怎么监控……每一样都足以让小白原地崩溃。这个ai-engineering-from-scratch项目的目标就是把我自己从零搭建AI工程能力的完整路径整理成一份可复用的学习框架。它不是什么学术研究项目也不是教你调一个模型而是切切实实围绕AI工程化落地的主线把从环境搭建、模型选型、数据工程、训练调优到推理部署、性能压测、持续迭代的每个环节用一套可复现的方式跑通一遍。我去年花了大约8个月时间走完这条路中间因为资料太分散、概念太跳跃走了不少弯路。这篇文章就当作是我的避坑地图把那些真正耽误时间的坑、真正值得反复琢磨的点、以及可以一键复用的方案全部摊开讲清楚。无论你是刚入门想系统构建AI工程能力的学生、独立开发者还是准备转型做算法工程师或AI平台工程师的从业者这篇文章提供的东西应该都能帮你在几个月的学习周期里建立一个扎实的全局观和动手能力。2. 我为什么选择从零构建而非直接套框架做AI工程这件事行业里有一个非常强烈的诱惑——觉得自己不需要懂原理直接用一个成熟框架比如LangChain、FastAPI加现成的模型推理服务把东西拼起来就完事了。说实话我一开始也是这么干的而且确实能很快出一个demo。但问题在于一旦把demo往前推任何一个小问题都能让你卡住一整天某个库的版本不兼容、显存算下来刚刚够但实际跑就OOM、并发一来延迟暴涨、模型输出质量不稳定但说不清哪里出了问题。后来我想明白一个道理所谓工程能力说到底是在面对不确定性时仍然能做出确定性决策的能力。如果只会在别人搭好的框架里配置参数一旦框架不能满足需求你就完全失去了判断力。而从零开始恰恰是建立判断力的最好方式——你需要自己动手实现数据管线、训练循环、推理服务、监控逻辑。这个过程会逼着你把AI工程里那些概念一个个啃明白比如什么是模型并行、为什么需要批处理、请求排队为什么会影响P99延迟、数据漂移又是怎么回事。2.1 这条路径给我的三个核心回报第一排查问题的能力呈指数级上升。因为每一个环节我都亲手写过任何异常出现时我能快速判断问题出在数据、模型还是服务层而不是像以前那样瞎猜或者靠搜索引擎碰运气。第二面对新需求时的自信心完全不同。当老板说需要支持多模态或者换一种更快的推理后端时我不再是被动应付而是能自己评估方案边界提出可行的演进路线。第三纯技术之外的沟通能力也会变好。因为你能把每个技术方案的取舍讲得一清二楚跟同事、跟客户聊需求的时候大家很容易达成共识。2.2 这条路径适合谁、不适合谁先说适合的人群你是一个有基本编程基础至少熟悉Python、愿意花时间拆解问题、愿意忍受前期看不到成果的学习者。如果你具备一些机器学习的入门知识比如知道分类和回归的区别训练过简单的神经网络那就更好了。不太适合的人我也不会劝退但请做好心理准备如果你只想要30分钟上线一个AI应用的快感或者需要被迫今天学完明天就给老板汇报那从零搭建的前期确实会很磨人不一定适合急于出成果的场景。我自己当时做的选择是把先跑通和再理解两件事拆开——第一遍先快速做一个能用起来的最小闭环第二遍再从头把每个环节手工拆开重新实现一遍。这个策略让我既保住了成就感又没有放弃工程理解的深度。3. AI工程的核心知识地图这六个领域躲不开很多人问AI工程到底要学什么我总结下来是六个核心模块。它们可以并行推进但最终会汇聚成一条完整的能力链。3.1 机器学习基础与模型原理这是地基但没必要在数学上死磕。我的经验是把梯度下降“损失函数”“过拟合”“交叉验证这些核心概念真正理解到能给外行讲明白的程度比背下一堆公式有用得多。推荐的学习方式不是啃《统计学习》类的大部头而是直接用PyTorch把线性回归、MLP、CNN、Transformer逐一实现一遍。我在项目里做了一个很笨但有效的事情用纯NumPy写了反向传播的完整过程为的就是彻彻底底搞明白梯度从输出层一路传回去每一层参数是如何被更新的。这个过程看起来慢但它带来的理解深度是用框架自动求导跑模型的人完全无法体会的。3.2 数据处理与特征工程AI工程领域有一句老话数据决定了上限模型只是逼近这个上限。真实项目中70%的Bug往往不是模型代码的问题而是数据处理的边缘情况没处理好某个字段全为NaN、标签出现错位、train和test预处理不一致等等。我建议至少掌握Pandas、NumPy、Polars这些工具的组合使用同时养成一个习惯每做一步数据变换都输出一次shape和数据分布检查确保每一个环节都有迹可循。我的项目里把数据处理做成了独立的数据护照机制——每个数据集自带一份描述、来源、字段含义、处理规则的说明文件避免过两周自己都看不懂当时为什么这么处理。3.3 模型训练与调优策略这一块是离散度最大的地方。你既可以用现成的Trainer脚本跑通训练流程但真正要掌握的核心技能是如何配置学习率、如何设计Batch Size、如何做学习率预热和衰减、如何处理类别不均衡、什么时候该用早停法。在项目里我整理了一份训练参数决策表把每个关键超参数对训练结果的影响方向和常用的经验值范围写明白。这份表在后来微调模型和跑比赛时派上了大用场——不是所有参数都需要搜索很多情况下用经验值起步已经能到80分。3.4 模型推理与部署部署是AI工程和算法研究最大的分界线。实测下来几个最常见的部署形态包括在线API服务模型以HTTP接口形式提供预测批处理任务离线产线定时跑大规模推理边缘端 / 嵌入式部署资源受限环境中做推理优化每种形态的技术栈和优化思路完全不同。比如在线API服务最在意的是延迟和吞吐的平衡批处理任务则可以耐心做大批量、高精度推理边缘端得考虑模型量化、算子融合、剪枝这些手段。我在项目里用FastAPI Triton Inference Server分别实现了轻量级API和规模化推理服务两种方案并把它们的性能差异做了对比。实际结果非常有意思同一个模型在Triton上通过动态批处理可以把吞吐提升3到5倍而延迟只增加不到20%。3.5 性能评估与监控体系很多教程讲完部署就结束了但真实世界的AI系统在运行期间才真正开始面对考验。模型输出的分布可能随环境变化而漂移用户请求的模式可能发生变化服务质量可能悄悄退化。因此一套监控体系是必须的。我在这里搭建了四个层级的监控基础设施层CPU、内存、GPU利用率、显存占用服务层请求延迟、错误率、吞吐量模型层预测置信度分布、结果类别分布业务层关键业务指标比如推荐系统的点击率、客服系统的解决率有了这四层监控模型表现一旦下滑你能快速判断到底是服务器资源不够、接口被人刷了、还是模型本身开始漂移。3.6 工程化基础最后但绝不意味着最不重要的是代码工程能力本身。用Git管理代码与数据版本、用Docker打包环境、用CI/CD做自动化测试与发布、写单元测试来保障代码正确性——这些普通软件工程的技能在AI项目里同样重要却往往被技术文章忽略。我在项目里特别注意了模板化项目的目录结构把数据、实验、模型、部署、文档分开管理并要求自己每次实验之后必须更新README与实验记录。好的工程习惯看起来会增加一些繁琐的步骤但在项目迭代半年之后你会感谢当初养成的这些习惯。4. 从零到上线一条完整可复用的实操路径现在进入核心的实操环节我把自己的项目切分成7个阶段每个阶段都有明确的输入和输出物。整个流程按照先能跑通再能优化最后做深的思路推进。4.1 环境与工具链准备我的建议是不用纠结选哪一个工具关键是先把工具链用熟。我的主力环境组合如下组件选择备注操作系统Ubuntu 22.04 LTS服务器上稳定、与生产环境一致性高包管理Conda pip方便管理不同的Python环境深度学习框架PyTorch 2.x生态最完整调试体验友好GPU环境CUDA 12.x cuDNN注意版本对齐别直接装最新版容器化Docker Docker Compose用于本地复现和线上部署代码管理Git Git LFS模型文件较大必须用LFS托管实验追踪MLflow记录参数、指标、模型产物、可视化对比这里我想强调一个小技巧任何项目的第一步先把requirements.txt和Dockerfile写好。这一步花不了多长时间但能让你在三个月后重跑实验时不用花三天时间试图重建环境。我自己有段时间为了省事环境配置全在本地裸奔结果一次系统重装导致所有实验环境得全部重新搭建那次教训让我彻底拥抱了Docker化。4.2 最小可行项目设计从零开始做AI工程最忌讳的就是一上来就搞一个大而全的系统。正确姿势是先定义最小可行项目——一个能完整走通所有环节、但规模可控的小项目。我的选择是做一个中文情感分类服务输入一句文本模型输出正面/负面情感的概率。它足够简单不需要太多数据训练很快部署方便却涉及了AI工程全链路的所有关键环节数据采集与清洗、文本预处理、模型选型与微调、模型序列化、API封装、Docker部署、性能压测、监控告警。用这个项目打底后面再去碰更复杂的图像生成、推荐系统时核心技术栈都不会变了。4.3 数据收集与清洗实操我用了公开的中文评论数据集大约20万条。说几点自己在数据处理中实际踩过的坑标签分布要提前检查。我当时拿到数据集后发现正负样本比例接近2:1这在工程上不算什么问题但如果直接训练模型会偏向多数类。解决方式有重采样、加权重我选择了对少数类做上采样并配合Focal Loss调参。去重要有分寸。完全去除重复样本可能导致模型泛化能力下降但在情感分类任务里重复度高却是常见问题我最终采用的做法是在保留信息量的前提下只去除完全相同的重复文本避免后续评估时数据泄漏。清洗规则不要过度设计。刚开始我加了特别多规则比如表情符号处理、繁体转简体、拼音修正等等。后来跑实验发现有些规则不仅没有提升效果反而破坏了原本有用的语义信息。最好的做法是把清洗规则模块化每个规则都能被开关然后通过实验来验证它是否有增量。4.4 模型选型与微调实战对于情感分类任务我没有一上来就用最大的预训练模型而是先用一个小模型ALBERT-tiny跑通全链路再切换到更强大的模型如BERT-base做正式版本。这个两步走策略极大节省了排查时间。微调阶段有几个参数值得特别注意超参数经验值说明学习率2e-5 ~ 5e-5BERT类模型微调普遍用这个区间Batch Size16 ~ 32控制与显存匹配注意BN层行为Epoch数3 ~ 5多了容易过拟合权重衰减0.01有助于防止过拟合预热比例0.1前10%的step线性增加学习率我习惯用MLflow记录每一组实验的超参和指标。顺手说一下为什么预热warmup这么重要预训练模型已经具备一个较优的参数分布训练初期用一个过大的学习率容易把参数冲出最优区预热就是给模型一个热身时间等参数稳定后再把学习率升上去进行正式学习。4.5 推理服务封装与容器化部署模型训练完不是终点你需要把它封装成一个真正的服务。我选用了FastAPI搭配Pydantic做请求体校验这样的好处是自动生成API文档方便前端或者调用方联调。核心代码逻辑大致如下from fastapi import FastAPI from pydantic import BaseModel from transformers import pipeline app FastAPI(titlesentiment-api) class SentenceInput(BaseModel): text: str class SentimentOutput(BaseModel): label: str score: float model_pipe pipeline( sentiment-analysis, model./models/bert-sentiment/, device0 ) app.post(/predict, response_modelSentimentOutput) def predict(input: SentenceInput): result model_pipe(input.text)[0] return SentimentOutput( labelresult[label], scoreround(result[score], 4) )这里要考虑的一个性能优化点非常关键模型加载很耗时必须在进程启动时加载一次而不是每次请求都加载。上面用模块级加载就是正确的做法。另外还有一个小细节pipeline对象是线程安全的可以直接复用不需要每次请求重建。容器化部署我写成了一套Dockerfile docker-compose.yml。Dockerfile核心部分大概这样FROM huggingface/transformers-pytorch-gpu:latest WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY ./app ./app COPY ./models ./models EXPOSE 8000 CMD [uvicorn, app.main:app, --host, 0.0.0.0, --port, 8000]有一个小坑必须提醒Docker镜像里的模型文件不要用COPY直接打进去如果模型很大好几个GB构建时间很长而且镜像体积大到离谱。更好的方式是在启动时从模型仓库拉取或者用volume挂载。我实测过一个2GB的模型文件直接COPY进镜像构建时间多出将近8分钟而且本地磁盘和CI服务器都可能不堪重负。4.6 性能压测与调优部署完不是万事大吉我用Locust做了压测模拟200个并发用户持续10分钟。实测结果直接使用transformers pipeline的原始API单GPU情况下P99延迟接近180ms吞吐约110 QPS。这个指标其实已经可以接受但我还是想看看能优化成什么样子。我做的第一个优化是引入动态批处理把多个请求排队当攒到一定数量或等待一定时间后一起送入模型推理。这个技术能把GPU利用率大幅提升在我的测试中吞吐提升了大约2.3倍而P99延迟几乎没变。为什么因为GPU适合并行计算单条推理并没有充分利用算力多请求一起算的额外开销远小于每个请求单独跑的开销。第二个优化是模型量化。把PyTorch模型从FP16压到INT8模型体积减小四分之三推理速度也快了约60%。如果你的业务对精度不是极端敏感量化是做推理优化时性价比最高的手段之一。第三个优化是GPU与CPU的部署形态选择。我的建议是高并发、追求低延迟的在线服务用GPU离线批量处理、成本敏感场景先用CPU跑通不行再考虑GPU。因为GPU实例的按秒计费价格大概是CPU实例的3-5倍如果能用CPU解决问题没必要提前花这个钱。4.7 实验闭环与指标体系这个阶段容易被忽略但极其重要。每次模型更新都需要一个完整的评测报告。我在项目里建立了4个层级的评测指标层级指标说明离线指标Accuracy、F1、AUC模型效果的基本面阈值指标Precision / Recall 可调结合业务目标校准分类阈值在线指标延迟、错误率、QPS服务是否稳定反馈指标下游业务效果最终是否对业务产生正向影响一个重要心得是离线指标和真实场景效果经常不完全一致。比如我训练的模型在测试集上F1能达到0.92上线后发现某些特定领域的长句判断准确率很低。后来分析才发现测试集的分布和真实用户输入的分布有明显差异——真实请求中包含大量口语化表达甚至有很多不规范的标点符号。这个发现让我意识到建立一套持续收集线上反馈数据并定期做数据回灌再训练的系统是保障模型效果持续在线的关键。5. 工具选型解析为什么是这些组合5.1 PyTorch vs TensorFlow2024年之后我会毫不犹豫选PyTorch。原因很简单学术与工业界生态都在这里。不管你是要加载HuggingFace模型还是要用最新的分布式训练方案PyTorch的兼容性与文档流畅度都更好。TensorFlow也不是不能选但它的学习曲线和使用体验确实劝退了不少新人。5.2 FastAPI vs Flask做模型API服务FastAPI是我强烈推荐的。它比Flask多出的是自动数据校验和交互式API文档这在调试和对接时节省了大量时间。一位做前端的同事跟我说他拿到FastAPI生成的Swagger文档几乎不需要我再额外口述任何接口细节直接就能开始联调。5.3 MLflow vs 手工记录实验管理方面我知道很多初学者习惯用Excel或备忘录记录实验然后很快就会被信息混乱淹没。MLflow作为一个开源工具能把每次实验的参数、指标、模型产物、源代码版本全部串起来还能可视化对比不同实验组的效果。我坚持的原则是每次实验至少记录10项元数据——包括数据版本、模型结构、参数组合、训练时长、资源占用、离线指标等。5.4 Docker与Kubernetes的边界很多教程一上来就教K8s但如果只是单机小项目Docker Compose就完全足够了。K8s的真正价值在于多机、多服务的弹性调度和自动伸缩这些特性对大多数早期项目而言是过度的。我的建议是先把Docker用熟等明显碰到编排瓶颈了再上K8s不迟没必要为了追技术潮流让学习曲线陡峭好几倍。5.5 监控体系的选型监控我推荐Prometheus Grafana因为这几乎是云原生时代的标准组合。Prometheus负责采集指标Grafana负责可视化。配合上Alertmanager做告警一套基本的监控体系就完整了。别想着自己造一套没那个必要用好成熟的轮子是工程效率的基础。6. 打磨工程细节代码结构、数据版本与控制实验质量6.1 代码目录应该长什么样我围绕AI项目总结了一套清晰可维护的目录结构核心思路是业务代码、实验代码、基础设施互相隔离。ai-engineering-from-scratch/ ├── configs/ # 所有配置模型参数、训练参数、API参数 ├── data/ # 数据存放目录不纳入版本管理 ├── data_processing/ # 清洗、预处理、增强代码 ├── models/ # 模型定义与训练代码 ├── experiments/ # 单次实验记录每个实验一个子目录 ├── serving/ # 推理服务代码与部署配置 ├── monitoring/ # 监控面板配置、告警规则 ├── tests/ # 单元测试与集成测试 ├── scripts/ # 常用命令行工具 ├── Dockerfile ├── docker-compose.yml └── README.md别小看目录结构它决定了你三个月后还能不能看懂自己的项目也决定了同事加入协作时的上手速度。6.2 数据版本管理的实操数据可不是代码——它变更频繁、体积巨大用普通的Git管理必然混乱。我采用的方案是DVCData Version Control它能把数据集目录的变化追踪成git可见的元数据文件同时把真正的数据存在云存储或本地磁盘。这样每次进入一个旧实验我能准确知道当时训练用的数据是哪个版本出了指标问题随时可回溯。6.3 单元测试在AI项目里怎么用AI项目里测试确实比普通软件工程难一些因为模型输出往往有随机性。我的策略是分三类测试类型测试内容说明纯逻辑测试数据处理、接口解析、配置加载输入输出完全确定必须严格断言结构测试模型输出shape、类型不校验数值只校验格式回归测试模型的AUC/F1与基准线的差距允许波动范围但超出阈值则告警有了这三类测试我可以非常放心地重构代码、升级依赖而不会破坏现有功能。7. 常见问题排查与避坑技巧实录最后这一部分是我想重点讲的因为很多细节只有实际跑过坑才知道网上教程很少提及。7.1 显存OOM的标准化处理流程显存不够大概是玩AI工程碰到的最高频问题。我的处理流程可以按优先级列出来调小Batch Size或序列长度观察显存是否下降启用梯度累积用多个小Batch模拟大Batch的训练开启自动混合精度训练能省一半显存更换更小的模型换更大的GPU特别提醒一点不要一上来就改模型结构。很多时候OOM只是工程配置问题不是模型设计问题。7.2 训练Loss变成NaN怎么查Loss变成NaN是训练过程中非常典型的错误通常原因包括学习率过大、数据含有无穷值或NaN值、模型分母出现0导致除零溢出。我的排查顺序是先查数据是否干净再降学习率最后检查模型结构里的归一化层。大多数情况是数据问题。7.3 推理延迟突然暴涨在监控里看到P99延迟从正常的80ms涨到500ms第一反应不要急着加机器先查几个事情GPU利用率是不是已经到95%以上排队等待是不是变多了请求大小分布是否变化有没有特别长的输入文本有没有定时任务和大请求抢占CPU是否存在垃圾回收暂停或Python全局解释器锁的竞争我在项目里就遇到过一次每天凌晨2点整点延迟飙高排查半天才发现是日志清理定时任务同时触发把磁盘I/O挤爆了。这段经历验证了先查基础设施再查模型逻辑的排查顺序。7.4 模型效果上线后越来越差这种问题更隐蔽通常是数据漂移导致的。解决方案是建立周期性数据采样和模型重训机制。我的做法是每周从线上日志抽取10%的真实请求做人工标注与训练集分布做对比一旦发现差异超过阈值就触发重训流程。7.5 多GPU分布式训练的坑单卡跑得好好的多卡却性能下降甚至崩溃。这种问题通常与数据加载单线程阻塞、Batch Size变化、梯度同步开销有关。一个常见经验是多卡训练时增大Batch Size的同时按比例调整学习率。另外DataLoader的num_workers设置很关键如果设成0数据准备可能会严重拖慢GPU利用率我实测下来num_workers8和num_workers0的训练速度差距能到三倍以上。8. 最后分享一条实操心得回到最开始说的ai-engineering-from-scratch这个项目带给我的不是某个单一技能而是一整套系统化解决问题的底层框架。AI工程看似庞杂但拆到最后就是数据、模型、服务、监控四大块。抓住它们之间的联系就抓住了整个体系的骨架。如果你现在正准备走这条路我的具体建议是不要贪多求全先锁定一个极小的场景跑通全流程然后把每个环节逐步加深。可以给自己定一个目标——比如两个月内必须把一个文本分类模型做成API并成功部署上线。做完了这个后面的事情会越来越顺。踩坑当然是难免的但每踩一个坑都是实打实的经验是那些只读文档的人永远学不到的功课。