从零开始学AI工程：我踩过的坑，和真正值得走的路线
“ai engineering from scratch”这个话题，我其实一开始是带着怀疑的——两年前市面上讲AI的课程，十个里面有九个都在教你怎么调sklearn、怎么跑通一个pytorch的官方demo，然后就算学会“人工智能”了。但等你真正进了公司、真正接手一个要上线的模型项目，你会发现那些教程压根没有告诉你：数据从哪来、特征怎么保证线上和线下一致、模型上线之后准确率为什么会掉、推理延迟压不下去怎么办。这些才是AI工程的日常，也是“from scratch”真正的含义：不是从零写一个神经网络，而是从零把一个模型做成一个稳定的系统。
这篇文章我想换个角度，不讲那些培训机构式的“三十天入门AI”，而是以一个过来人的视角，拆解从零开始走AI工程这条路的真实地图。全文会分成几块：先帮你把“AI工程到底在干什么”这事想清楚，然后依次讲数学和工具的“够用”底线、第一次跑模型的标准流程、真正工作里最折磨人的数据处理、模型上线后的部署与监控，最后再聊聊现在绕不开的生成式AI方向，以及简历和作品集该怎么准备。内容会有点长，但保证都是能直接落地的实操经验，尤其适合两类人看：一是想转行做AI工程但还在资料海洋里打转的新人，二是已经会跑模型、但想知道“工业里到底是怎么做得这么稳”的初级从业者。
1. 为什么“AI工程”不是“调API”：先把领域的真实地图看清楚
很多人对AI工程的第一印象是“训练模型很酷”，或者“模型效果越准越厉害”。我在前公司带过几个实习生，他们刚来的时候普遍有个误区：每天研究怎么把准确率从94%提到95%，但对模型到底跑在谁的机器上、每天要服务多少请求、失败率有没有超标这些问题完全没概念。这不是他们笨，是市面上几乎没有内容在讲“模型之外的那90%”。
AI工程，说到底是一套解决“模型如何稳定产生业务价值”的完整方法论。它包含模型训练，但更重要的是训练之外的一整条链路。我习惯把这条链路拆成五段，每一段都有自己的坑和“重活”：
- 数据工程：采集、清洗、标注、版本管理、特征计算。一个模型80%的效果来自数据，这句话老生常谈，但真正做起来你会发现光是保证训练集和线上预测时的数据分布一致，就够写十篇复盘了。
- 模型训练与验证：这里说的不是调参，而是“可复现的训练”，是“你怎么知道这个模型真的比上一个好”的严谨实验体系，包括离线指标怎么设计、验证集怎么切分才不会过拟合。
- 部署与交付：把训练好的模型封装成接口、压到足够低的内存和延迟、让它在容器或者K8s里跑起来，并且能在版本更新时不中断服务。
- 监控与迭代：模型上线只是开始。你需要盯着预测分布、业务指标、数据漂移、模型漂移，还要设计自动或半自动的重新训练机制。
- 系统集成与产品化：模型要跟业务系统、前端、推荐引擎、风控规则通信，一个系统的稳定与否往往取决于这些胶水层的工程质量。
这五段加在一起，才叫AI工程。从零开始学，也不意味着第一周就要写一个神经网络的前向传播，而是先建立这张完整地图——知道自己的每一步是在解决哪一个环节的问题。对我个人来说，这个“地图认知”是最值钱的第一步，因为它决定你后面所有的学习都不再是跟风，而是查漏补缺。
1.1 一个反直觉的结论：工程化能力比算法创新更稀缺
我再补一刀：真正在招聘市场上稀缺的，其实不是发过顶会论文的算法科学家，而是能把模型稳定跑起来的AI工程师。绝大多数公司的业务场景谈不上多前沿，用的一般都是公开论文里的成熟网络结构。难点在于：怎么把模型塞进业务链路里，让它稳定、可控、可解释。我在上一家公司做的推荐排序模型，算法结构就是经典的deep crossing变体，没什么新东西，但光是为了把训练pipeline的耗时从三小时压到四十分钟、把模型推理的p99延迟从120毫秒压到80毫秒，我前后花了两个月。这种优化，靠的是工程积累，不是模型论文。
所以如果你的目标是从零进入这个行业，我的第一个建议是：不要沉迷于“看懂Transformer原文”这种仪式感，而是要尽早动手把一条极小的AI链路完整跑通——后面我会给出具体的路径。
2. 第一层地基：线性代数、概率论和Python实战的“够用”标准
说完宏观地图，这一节聊点实际的：从零开始，基础知识到底要学多深？我见过两类极端：一类是上来三个月死磕《统计学习方法》，连第一棵决策树都没跑通就放弃了；另一类是完全没有数学基础，直接上手Transformer，跑通了模型但特征的量纲含义完全看不懂。这两类人最后都没能走远。
我的观点是：AI工程不是搞科研，你的数学不需要达到能推导论文的水平，但必须达到“看懂公式在干什么、知道超参为什么这样设、遇到报错能定位到维度问题”的水平。这一档就够了，我给它起了个名字叫“够用标准”。
2.1 线性代数：不是会算矩阵乘法，而是建立“形状直觉”
线性代数在AI里最核心就三件事：矩阵乘法、转置、形状匹配。你不需要手工去算一个四阶矩阵的逆，但你需要做到：看到任何一个网络层的输入输出规格，脑子里能立刻反应出它的shape变化过程。我在实际debug时，TensorFlow或者PyTorch报的错里面，至少有三分之一是dimension mismatch。如果你对形状没有直觉，这种报错能卡你一下午。
够用标准怎么检验？给你一个(B, T, C)的序列特征，你很清楚它经过一个Linear(C, H)之后输出是什么形状，再过一次permute和reshape之后又是什么形状，为什么batch_first这个参数会影响LSTM的输入。如果这些都想得明白，你的线性代数就过关了，不需要再看更多教材。
2.2 概率统计：关注分布，而不是背公式
AI工程里概率统计最常用的不是假设检验，而是三个词：分布、期望、方差。你需要理解训练集和线上数据的分布差异意味着什么，为什么dropout是一种近似贝叶斯推断，为什么日志里特征的标准差变了就可能是数据漂移。这些理解不靠背公式，靠的是真正的直觉。
我的建议是不要从《概率论与数理统计》课本重新学起，而是直接拿你未来的工作场景反推：去看Kaggle入门赛的kernel，凡是涉及缺失值填充、归一化、数据切分的部分，都有概率统计的影子。把那些部分彻底搞懂，你就达到了现在的够用标准。
2.3 Python和工具链：别用notebook写一切
Python是AI工程的基本语言，但很多纯搞算法的人有个坏毛病——所有代码都在Jupyter Notebook里写，环境依赖永远不锁版本，函数之间靠全局变量通信。这种代码拿到工程环境里根本活不下来。我的建议是第一周就要适应“脚本化、模块化、版本化”的开发方式。
工具链其实不复杂：
python=3.10起步，学会用venv或conda管理环境，用requirements.txt或pyproject.toml锁依赖。- 编辑器选VS Code或者PyCharm都行，关键是要学会debug断点，不要永远靠
print排查问题。 git必须熟练，至少要会分支、合并、回滚，以及用.gitignore把数据文件和大模型权重隔离出去。- 一定要在命令行里跑过至少一次训练脚本，而不是永远点Notebook的“运行”按钮。
这些规矩看起来琐碎，但它们是“从scratch”到“工程”的分水岭。我面试过的候选人里，有模型说得头头是道、却连git checkout都没用过的，这种基本功上的缺失，比算法知识欠缺更难弥补。
3. 从第一个模型到第一次训练：一条标准且不劝退的实操路线
基础理论到这儿就够起步了，下面讲讲上手路线。我不建议你从MNIST手写数字识别开始，不是说它不好，而是它太“假”了——现实中不会有哪个项目给你一个干干净净、已经分好类的数据集。我更推荐的路线是找一个带结构化表格数据的Kaggle入门赛，比如House Prices或者Titanic，用它们把“完整闭环”跑通，而不是只把准确率刷上去。
为什么是结构化数据？因为这个场景最接近工业界的日常，而且步骤完整：读取数据、探索性分析（EDA）、特征工程、切分验证集、训练、评估、提交预测结果。你不需要GPU，不需要先学深度学习，用梯度提升树（XGBoost或者LightGBM）就能跑赢大多数baseline。先把这个流程跑通，你会对“AI项目是怎么运作的”有第一次真实体感。
3.1 用三个项目把“完整链路”刻进脑子里
我建议的阶段计划如下：
- 第一个项目（两周左右）：做完一个结构化数据的Kaggle入门赛。目标不是排名，而是完整地写下：数据预览、缺失值处理、特征选择、模型训练、验证曲线、测试集预测。养成每一段代码都有版本的习惯。
- 第二个项目（三到四周）：换一个文本或者图像任务，比如IMDB情感分类或者CIFAR-10。这个阶段开始用PyTorch，你可以手写一个简单的CNN或RNN，不求结构新颖，但求把训练循环（training loop）彻底搞懂：前向传播、计算loss、反向传播、更新参数、batch大小的影响、学习率调度。
- 第三个项目（五到八周）：把你做过的第一个项目“产品化”——写一个简单的FastAPI接口，把模型封装进去，再用Docker跑起来，写一个README。这一步大多数人不会做，但它是从“算法笔记”走向“工程交付”的关键一跃。
为什么强调训练循环要手写，而不是直接套pytorch-lightning之类的高级封装？因为封装藏了太多细节。你要是从来没见过optimizer.zero_grad()、loss.backward()、optimizer.step()这三行之间的逻辑关系，后面遇到“loss变成NaN”或者“梯度不更新”这种经典问题，就会像个无头苍蝇一样乱试解决方案。手写一遍，你就知道梯度清零这步为什么必须在每次迭代、在backward之前做，而为什么有些代码又把它放在backward之后——这是很多隐性bug的来源。
3.2 损失函数、优化器和评估指标：三者的错位关系是新手死亡区
跑通流程之后，一个最容易糊涂的坎是：评估指标和损失函数到底什么关系？我见过不止一个新人用AUC当评估指标，却在训练时用cross entropy损失，然后跑完测试一看，AUC不错，就忘了自己为什么要用交叉熵。道理很简单——AUC不可导，不能直接做梯度下降的优化目标，所以我们要拿可导的交叉熵当家，让模型间接去优化AUC。这个“用代理目标去逼近真实目标”的思路，整个机器学习里到处都是，越早想明白越好。
同样值得现在就想清楚的还有：batch size到底怎么选？不是越大越好，越大每一步越稳定、能用满GPU算力，但往往会收敛到比较差的极小值，而且吃显存。显存不够的时候，很多人第一时间想到的是换小模型，我建议先降低batch size试试，收益往往更高。反过来，batch size太小的训练又容易震荡，这时适当调低学习率会稳定很多。这个“batch、学习率、收敛稳定性”的三角关系，是AI工程调参的基本日常，需要在第一个动手项目里就建立直觉。
4. 数据的坑：脏数据、标签噪音和采样偏差的真实工作流
模型训练跑通之后，摆在你面前最现实的问题就是数据。我在一线做AI工程，有个经验公式：一个项目里，纯模型训练和调参大概占20%的精力，剩下的80%全在数据上面。这不是夸张，数据的工作量就是这么大。所以从零开始学AI工程的第二个分水岭，就是你能不能把数据的活做得像样。
4.1 脏数据的几种形态与处理顺序
工业界的原始数据，几乎不会像教程里给你准备好的那样干净。常见的形态有这么几类，每一类处理方式都不太一样：
- 缺失值：删除、均值填充、用模型预测填充、或者干脆把“是否缺失”变成一列特征。我比较推荐最后一种，因为它保留了信息量——有些场景下用户没填某字段这件事本身，就是一个强特征。
- 异常值：业务上的极值不一定是错误，比如金融场景里的大额交易，不能一刀切地删掉。建议先用分位数看分布，再结合业务逻辑判断。纯统计的3σ法则在AI工程里经常失效，因为真实数据很少有严格的正态分布。
- 重复数据：看似简单，但实际操作里经常是因为表关联重复导致的，比如一个用户买了三件商品，如果按用户粒度统计就会有重复行。这种要去重，但去重键要想清楚。
- 标签噪音：这是最隐蔽也最致命的。我做过一个文本分类项目，标注是外包团队做的，后来抽检发现一致性只有82%。标签错了模型学出来就是歪的，更恶心的是这种错误很难从指标上直接发现，只能靠抽检和错误分析去追踪。
处理顺序我的建议永远是：先理解业务场景和数据生成过程，再动手清洗。拿一个用户活跃预测的项目举例，你那个“活跃”的口径到底怎么定义？是登录了一次算活跃，还是停留超过五分钟算活跃？定义不同，整个标注逻辑全变。
4.2 切分数据集的三大纪律
数据切分看起来是个不起眼的操作，但它暗藏了无数翻车点。我有三条纪律，是在踩了坑之后才总结出来的：
- 测试集只能看一次。我见过有人反复用测试集调参，到最后模型没泛化能力了，但测试分数虚高——这是欺诈自己的典型操作。正确的做法是留一个“压箱底”的测试集，只在所有调参结束之后用一次。
- 保证时间顺序。很多场景是时间序列性质的，比如预测明天是否下雨，这时不能随机切分，必须以时间点为界，用过去预测未来。随机切分在这种场景下会引入未来信息泄漏（look-ahead bias），训练时指标很好看，上线后直接崩溃。
- 防止同一实体跨组。如果你的数据里有同一个用户多行记录，随机切分很可能让同一个用户的行分散到训练集和测试集，模型在测试集上等于见过“半个人”，乐观偏差会非常严重。正确做法是按用户ID做group切分。
4.3 特征工程：别被“自动特征工程”忽悠
现在的AutoML工具确实能做一部分特征自动组合，但在工业级项目里，真正决定天花的还是人的业务理解。我从零带过几个项目，他们的痛点通常不是没有特征，而是特征裸奔——未经处理直接丢进模型，导致分类器被一个量纲极大的特征带着走。特征工程的门槛在于“标准化/归一化、类别变量编码、缺失值标记”这些基本功，以及“组合特征和业务逻辑特征”的经验。
我可以分享一个几乎每个项目都用得上的套路：把“数值特征的经验分布”和“目标变量的条件统计”结合起来做特征。广告点击率预测里，历史点击率就是个典型的条件统计特征；风控场景里，用户的30天累计交易金额又是一个。这种特征的意义是让模型获得整体数据里“无法直接看到”的统计信息，效果立竿见影。
5. 部署与监控：只有模型跑在服务器上，工作才算完成
我见过太多“半成品AI工程师”：模型在Notebook里F1值0.92，一到线上就崩，MSE翻倍，召回率掉到惨不忍睹。他们缺的不是模型能力，而是工程闭环能力。部署不是可选项，是AI工程里最硬核的必修课。
5.1 模型服务的封装：从pickle到FastAPI到容器化
最基础的部署形态，是把训练好的模型对象序列化（pickle或joblib），然后在服务里加载。再往上走一步，用FastAPI写个接口，把推理逻辑封装成HTTP服务。这个阶段有很多细节，也都是我在实战里踩过的坑：
- 序列化方案别乱选：
pickle虽然方便，但跨版本兼容性差。我吃过一次亏：本地用Python 3.9训练完模型，上线环境的Python是3.8，加载直接报module not found。后来我统一改成ONNX格式导出，既跨语言又跨版本，在线推理性能还更好。 - 特征处理逻辑必须跟着模型走：模型训练时做的归一化、类别编码，在线上推理时要一模一样。这不是理所当然的，实际场景里训练和推理代码通常由不同人维护，我就遇到过线上漏做缺失值填充、导致预测结果整体偏移的case。解决办法是把整个预处理流程封装成一个Pipeline对象，训练时一同
fit，上线时直接加载。 - 依赖锁死：
requirements.txt里的每个包都要锁版本号，numpy==1.24.3，pandas==2.0.1，不要用>=这种范围符号。AI领域的库版本兼容问题多到令人发指，我今天还因为torch和numpy版本不兼容导致CPU推理线程崩过一次。 - Dockerfile的踩坑点：基础镜像不要选
latest，要选带CUDA和cudnn版本的明确tag；安装依赖的层放在程序文件复制之前，这样代码改了不会每次都重新装依赖，镜像构建快很多。
我建议从零开始的人，第三个项目至少要完成“FastAPI封装一个模型推理接口 + Docker跑起来 + 本地curl验证返回结果”这个最小闭环。它会教你一个道理：模型只有变成服务，才能被测试、被监控、被迭代。
5.2 压测与性能瓶颈：GPU没那么重要，内存和IO才是常客
模型部署完，第一次迎接真实流量时，你会发现性能问题是另一片海。我见过一个团队上线一个BERT分类模型，没做任何性能优化，单机扛不住100QPS，直接雪崩。压测的时候，不要只看吞吐量，更关键的是p99延迟——也就是最慢的那百分之一请求花多长时间。p99更容易暴露问题，比如Python里有GC（垃圾回收），偶尔会长暂停，或者某个请求触发了一个低效的特征计算路径。
优化推理性能的优先级，我建议是：先用模型结构层面的优化（模型蒸馏、剪枝、量化），再做工程层面的优化（缓存、批处理、并发、异步IO）。工程上有一个很多新手不知道的概念叫动态批处理——把排队中的多个请求合并成一个batch，一次性喂给GPU。这能让吞吐量提升好几倍，代价是单个请求的等待时间略微变长，所以在延迟要求严格的场景下要谨慎权衡。
顺便说一句，我第一次接触生产级推理时觉得做服务化的AI很神奇——原来模型不是“一个人在战斗”，而是由很多个模块协同工作，任何一个环节都能成为瓶颈。这个认知，纯刷算法题是刷不出来的。
5.3 模型监控：漂移检测、日志与告警
上线只是一个新阶段的开始。模型会老化、数据分布会漂移，你的模型效果会随时间下降，这是必然规律。AI工程里，你必须有能力和机制“看见”下降的过程。
推荐的最小监控方案包含四件事：
- 记录预测分布：每天把模型预测结果的均值、方差、分位数记录下来。如果线上预测分布和训练时的分布偏离太多，大概率出问题了。统计量可以用工具自动算，比如
whylogs或者Evidently，也可以自己写个定时任务算完存数据库。 - 跟踪业务指标：模型的线下AUC固然重要，但线上业务指标（比如CTR、转化率）才是最终指导。业务指标掉了，不管模型汇报AUC多好看，模型就是失败的。
- 数据漂移检测：最简单的做法是按天对比线上和训练集的单特征分布，算PSI（Population Stability Index）。PSI超过0.2一般就很危险了，建议告警触发人工排查。
- 结构化日志：每一条预测请求都要记录“模型版本、特征版本、输入关键字段、预测结果、延迟、错误码”。没有日志，任何线上问题的排查都会变成重演福尔摩斯探案，而且是盲人摸象那种。
在这一节最后提醒一句：监控的产出不是告警，而是能指导迭代的洞察。告警太多等于没有告警，一定要收敛到几个真正需要人盯的指标上。
6. 生成式AI时代的工程化：LLM、RAG和Agent，如何延续最小闭环
这一节聊聊现代AI工程绕不开的方向。大约从2023年开始，工业界的AI工程需求迅速转向了大语言模型（LLM）应用。很多从零开始学习的人会焦虑：我还要不要从传统机器学习学起？我的回答是：要，但可以加速。传统机器学习的工程方法论，比如数据质量评估、离线验证、灰度上线、监控反馈，在LLM时代一个都没消失，反而变成更重要的底座。
6.1 你的RAG别只做“向量检索”
现在很多项目号称用了RAG（检索增强生成），但本质上就是把文档切碎、embedding、存向量库、然后检索拼context。这套起步是没问题的，但真正工程化的RAG有太多细节：
- 切分策略：不是简单按字符数切。要按标题、段落、语义边界切，还要考虑chunk之间的重叠。切得太碎，上下文信息断裂；切得太大，向量检索噪声多，还可能超LLM的上下文窗口。
- Embedding选型和质量评测：不同的embedding模型在不同领域的效果差异很大，不要默认用一个通用模型躺平。搭建一个十几条问题的迷你评测集，分别用不同embedding跑一遍召回，看top-k命中率，是性价比最高的选型办法。
- 重排（Rerank）：向量检索的粗召回结果质量一般，后面加一个交叉编码器重排，往往是RAG效果提升最明显的一步，甚至超过换大模型。这个经验，是我做企业知识库问答项目时反复验证过的。
- 缓存与上下文管理：LLM的API调用又贵又慢，加一层语义缓存（相似的query直接返回之前的答案），以及设计好对话历史怎么截断打包，工程收益立竿见影。
6.2 Agent：能力框架之外，可靠性才是门槛
Agent是LLM应用最热的词。从技术实现上，Agent无非是“LLM + 工具调用 + 规划循环”，用LangChain或自己手写ReAct循环都能实现。但真正做工程的时候，难点其实是可靠性和可控性：
- 工具调用的参数校验：LLM生成的工具入参经常是错的，比如日期格式不符合接口要求、ID类型搞混。必须做一层schema校验和失败重试，否则Agent就是一个连环爆炸事故。
- 长任务的状态管理：一个Agent可能跑十几个步骤，中途失败要从哪一步重试？中间状态怎么存？要不要把中间决策过程记录下来做审计？我在一个自动化报告Agent项目里，光是把“失败恢复”的流程理清楚，就花了一周时间。
- 成本控制：Agent的调用次数不确定，很容易出现一个任务花掉几十次LLM调用。工程上必须设计“最大步数”限制、启用流式输出、在可接受的准确性下选择更小的模型。
我的建议是：学Agent不要从框架开始，先手写一个最简单的“ReAct循环”——让LLM决定调用什么工具、观察结果、再决定下一步。手写一遍之后，你会深刻理解为什么框架要那样抽象，以及它的哪些抽象在实际场景里是不够用的。这也是“from scratch”精神的又一次体现：不经过从零构建，你对上层框架永远是黑盒使用。
7. 作品集和求职：如何把“从零开始”证明给面试官看
最后一个环节，聊聊怎么把学到的东西变成职业机会。我面试过大量候选人，见过太多“项目写了三天，简历上写了三年”的注水选手，也见过真正从零开始、用一年时间把自己打磨成扎实工程人才的同学。面试官要的不是你列一堆模型名字，而是“我相信你是真的会做”。
7.1 项目的呈现方式：一条主线比十个demo更可信
我的建议是：不要做十个互相没有关系的玩具项目，而是做一个深度足够深的完整项目。什么叫深度足够？就是你能把项目的每个环节都讲出“为什么”。举例：你做了个影评情感分析系统，不能只说“我用了BERT，准确率93%”，而是能说清楚：数据是多少万条、怎么清洗、标签噪音怎么处理的；为什么用BERT而不是ELECTRA或RoBERTa；训练时学习率为什么设成2e-5；线上部署时的延迟多高、有没有压测数据；模型效果下降之后你怎么监测和再训练。能回答出这些，比刷十个项目都强。
作品集如果是GitHub仓库，README一定不要只贴代码。我建议包含三个部分：项目背景和要解决的问题、技术架构图和关键决策记录、复现路径和实验结论表。我自己看候选人的仓库，最反感的是“README全是徽章、代码没有注释、数据集没有说明”那种面子工程。
7.2 面试官真正想听的“from scratch”故事
面试里如果问到你：“你从零开始做过什么？”不要只讲“我调通了某个预训练模型”。更好的回答结构是：先讲你遇到的真实问题是什么，然后讲你的约束条件（数据量有限、延迟要求高、成本不能超），接着讲你试过什么方案、为什么放弃、最后选了哪个方案，再讲工程上你做了哪些事让系统稳定跑起来（监控、日志、回滚机制），最后讲这个项目的业务效果。这个叙事背后展示的是你的决策能力和工程闭环能力，面试官要的是这个。
8. 写在最后：关于“从零开始”我最想说的一件事
如果要把整篇浓缩成一句话，我会说：AI工程里的“from scratch”，不是一个从零到一的瞬间动作，而是一种持续多年的做事方式——遇到一个黑盒，就试图打开它；看到一个抽象框架，就先想它解决了什么、没解决什么；跑通一个demo，马上就问它在生产环境里能不能活得下去。我见过很多聪明人，学东西快，但最后没能成为优秀的AI工程师，原因就是想得太少、做得太浅，始终停留在“调通即可”的舒适区。
我自己踩过的坑比写出来的多得多，比如第一次部署时忘了锁版本导致线上服务崩了半小时、第一次做时间序列切分时泄漏了未来信息还高兴了半天、第一次写Agent时没加工具调用容错让循环死转烧了几百块API费用。这些坑都是学费，但只要每次都复盘，把教训沉淀成自己的检查清单，就不会白交。希望这篇长文能让你少走一些弯路，更希望你在看完之后，不只是收藏，而是真的选一个小项目，从零开始跑通一条完整链路。准备好开始了吗？
