我自己从零搭过AI工程这条路，踩过的坑比我写过的代码还多。所以看到“ai-engineering-from-scratch”这个标题的时候，我特别有感触——它和你搜到的那些“AI速成课”完全不是一个物种。它不是一个教你跑通某个Demo的教程，而是一条从0到1建立AI工程体系的方法路径。这个领域真正的难点，不是某个模型的精度能刷到多少，而是你面对一堆开源工具、算法框架、数据处理流程、部署方案时，敢不敢把它们像搭积木一样拼成一个能稳定跑起来的系统。
这篇文章就是想把“从零起步做AI工程”这条路上最关键的几个节点拆开聊透。我尽量用自己的实战经验来讲，而不是念PPT，目标是让你读完能少走至少三个月的弯路。适合同样在AI工程这条路上的朋友——不管你是算法刚转工程、后端转AI，还是负责从零搭团队技术栈的leader，下面这些内容大概率是你接下来要面对的。
1. AI工程到底是什么，为什么值得从零死磕
1.1 AI工程不等于训练模型，它是一条完整的生产链路
如果只用一个词来解释AI工程的核心，我会选“生产化”。训练模型只是整个链条的中间一段，真正决定一个AI系统能不能持续跑下去的关键，在于数据能不能管好、特征能不能复用、实验能不能复现、模型能不能稳定上线、线上效果能不能追踪。
我见过不少团队，在Demo阶段一切都很顺利，但到了生产阶段就持续翻车。原因基本一致：训练脚本是临时的、数据预处理和特征工程全写在Notebook里、模型文件靠手动拷、上线靠运维手动拉取。结果每次更新模型都是一场灾难。AI工程的价值，就是把这些“临时的动作”变成“可持续的基础设施”。
从零开始做AI工程，本质上是建立一套关于数据、模型、评估、部署、监控的标准化流水线。它需要你把工程师的严谨性带进算法开发的日常，用版本管理管住数据，用自动化打通训练到部署的闭环。这条路没有捷径，但地基打得越扎实，后面的迭代就越快。
1.2 从零开始建立AI工程知识体系的路线图
如果把人看作一个系统，学习AI工程就是给系统装驱动。但驱动不能乱装，得有顺序。我自己验证过的有效路径大概是这样的：
- 第一阶段，先补底子：Python工程化能力、数据结构基础、Linux操作。不要小看这几样，后面所有的数据处理、模型调用、服务部署都建立在它们之上。
- 第二阶段，掌握数据闭环：数据采集、清洗、标注、版本管理。没有一套可控的数据流，后面的模型全部是空中楼阁。
- 第三阶段，深入模型训练：从经典机器学习到深度学习，再到预训练模型微调，核心是理解损失函数、优化器、评估指标背后的逻辑。
- 第四阶段，学工程化封装：把模型封装成服务、做性能优化、上线监控、建立反馈迭代机制。
不必追求每个阶段都精通，但每个阶段至少要能独立完成一个端到端的小项目。这个路线图的逻辑很简单，每一个阶段都为下一个阶段提供依赖基础。跳步是最贵的省钱方式，短期能跑通一个demo，但后面还债的时间够你重学三遍。
1.3 一个成熟AI工程团队的核心能力模型
一个团队如果具备成熟的AI工程能力，它至少需要五块拼图：数据工程师、算法工程师、MLOps工程师、后端工程师、评估与测试角色。国内很多团队为了效率让一个人干三份活，这在早期可以，但到了中期如果不调整，必然会出现瓶颈。
更核心的是这几种能力的业务化理解：
- 数据团队要懂业务指标，知道什么样的数据分布会导致线上效果变差；
- 算法团队要懂工程约束，知道线上部署的算力、延迟、吞吐边界在哪里；
- MLOps要把训练和部署之间的桥搭好，让算法工程师不关心部署细节也能上线；
- 评估体系要能提前预测模型的线上表现，而不是只看离线指标。
这套能力模型不是一个模板，而是给你一个体检表，定期对照看看团队哪里还有短板。从零开始构建AI工程，最怕的不是起步慢，而是不知道自己缺什么。
2. 从零构建AI工程的技术地基：工具链与数据体系
2.1 编程基础：Python工程化能力是“第一性原理”
任何一个AI工程项目的起点，都是工程师对Python的工程化掌控。很多人说“我会Python”，但到了项目协作才发现，自己写代码的方式完全不适应工程化要求。函数没有类型注解、依赖没有lock版本、代码没有单元测试、脚本没有异常处理。这样的代码在自己电脑上跑没问题，一到团队协作或线上部署就必然出幺蛾子。
工程化Python的底线标准，至少包括四个方面：类型注解+完善的文档字符串、虚拟环境隔离与依赖锁定、核心逻辑具备测试覆盖、日志与错误处理完善。
给你一个我常用的虚拟环境初始化流程做参考：
# 使用venv创建项目隔离环境，这里以Python 3.10为例 python3.10 -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install -r requirements.txt pip freeze > requirements.lockrequirements.lock的意义，是让团队所有人、所有环境都用完全一致的依赖版本。很多模型在本地跑得好，上服务器就飘了，一查是依赖版本不一致。把这个习惯建立起来，能直接砍掉一大半环境类问题。
2.2 数据处理：80%工作量所在的真实环节
AI项目里流传着一句话：模型决定了效果的上限，数据决定了效果的下限。这句话在工程场景下尤其真实。我见过的AI项目里，真正花时间最多的环节永远是数据清洗与预处理，而不是调模型。
一个标准的数据处理流水线，通常包含以下步骤：
- 数据探查：了解字段含义、样本数量、分布情况；
- 数据清洗：处理缺失值、重复样本、异常值；
- 数据切分：训练集/验证集/测试集划分，务必保证无泄漏；
- 特征构造：从原始数据中提取和筛选有预测能力的特征；
- 数据校验：上线前对数据格式、范围、统计量做自动化检查。
举一个实际的切分逻辑作为参考：
import pandas as pd from sklearn.model_selection import train_test_split # 读取原始数据并做基础清洗 df = pd.read_csv('raw_data.csv') df = df.drop_duplicates(subset=['id']) df = df.dropna(subset=['label']) # 先按7:3拆出训练集和临时集 train_df, temp_df = train_test_split( df, test_size=0.3, stratify=df['label'], random_state=42, ) # 再把临时集按7:3拆成验证集和测试集 val_df, test_df = train_test_split( temp_df, test_size=1 / 3, stratify=temp_df['label'], random_state=42, )stratify按标签比例分层抽样，保证小类别不会因为随机切分而流失。这个细节特别容易忽略，尤其是分类问题里类别不平衡时，没有分层切分，验证集里可能直接缺了小类样本。
2.3 数据版本管理：为什么你的模型无法复现
从零搭AI工程，还有一个最容易忽略却持续性砸坑的地方，就是数据版本管理。代码有了可以回滚，数据呢？你上周训练的模型效果很好，别人想复现，但数据已经被新的爬虫版本覆盖了，模型结果就再也回不来。
解决这个问题的标准工具是DVC（Data Version Control）。它用类似Git的思维方式管理数据集，可以记录某个模型对应的是哪个版本的数据和代码。
实际使用中，我会为每个数据集创建一份清单文件，记录数据的来源、采集时间、样本量、字段说明。训练脚本里也会带上数据版本的参数。
这里有一个非常关键的实践原则：每一个产出的模型，必须能追溯到训练它的数据版本和代码提交哈希。这个习惯短期看增加了工作量，但长期看是团队能否持续迭代的生命线。
3. 模型训练全流程工程化：从实验追踪到调参踩坑
3.1 实验追踪：别让你的调参经验遗失在Notebook里
训练模型是AI工程中最容易让人兴奋、也最容易走偏的部分。很多人调参靠感觉，跑完50轮实验，最后判断哪个模型最好，靠的是“我脑子里记的结果”。这是绝对不行的。
建立实验追踪体系，是AI工程和算法研究的重要分界线。MLflow是我用得最多的一套方案。它负责记录每次实验的超参数、代码状态、评估指标，自动生成对比图，把“和哪个版本比”变成“和全部历史版本比”。
核心用法很简单，训练脚本里插入追踪调用：
import mlflow mlflow.set_experiment("text_classification_exp") with mlflow.start_run(): # 记录超参数与模型路径 mlflow.log_param("learning_rate", 3e-5) mlflow.log_param("batch_size", 32) mlflow.log_param("max_length", 128) # 记录评估结果 mlflow.log_metric("val_accuracy", 0.9123) mlflow.log_metric("val_f1", 0.8945) # 保存模型与预处理状态 mlflow.log_artifact("model_output/model.pth") mlflow.log_artifact("config/tokenizer_config.json")这套系统能帮你回答三个关键问题：当前这个实验比之前好在哪、坏在哪、这些结论是基于什么假设得出的。没有实验追踪的调参，本质上是在靠运气工作。
3.2 训练参数选择的底层逻辑与经验值
超参数调优是AI工程里最玄学也最有规律的部分。训练和推理阶段的参数选择直接影响最终模型的质量与线上成本。以预训练语言模型微调为例，几个核心参数的常见经验区间我整理成了下面这张表：
| 参数 | 常见经验值 | 说明 |
|---|---|---|
| 学习率 | 2e-5 ~ 5e-5 | 预训练模型微调时，过大会破坏已有权重，过小则收敛极慢 |
| Batch Size | 16 ~ 32 | 显存允许范围内尽可能大，但过大会导致泛化下降 |
| Epochs | 3 ~ 10（配合早停） | 微调不宜过多，观察验证集指标防止过拟合 |
| Warmup比例 | 前10%步数 | 帮助模型在训练初期稳定梯度方向 |
| 权重衰减 | 0.01 ~ 0.1 | 控制模型复杂度，防止过拟合 |
需要重点解释的是学习率的逻辑。预训练模型已经有了大量先验知识，微调时如果学习率设置过高，相当于你让一个已经学会开车的人突然忘记之前的技术，重新学一遍。所以微调场景下学习率普遍远低于从头训练一个模型的默认值。
从零做训练工程时，我还建议给每次实验设置一个“最大运行时间”上限。模型训练要关注机会成本，卡在收敛缓慢的实验中不如早些停止，换一组参数或者调整数据处理方式。
3.3 模型评估：离线指标与在线指标的红线关系
评估模块是从零搭建AI工程时最容易被弱化的环节。很多人都停留在“验证集上精度到了90%，可以上线了”的认知。但精度90%只是一个高度压缩的数字，它掩盖了模型在各类样本上的真实表现。
我建议从三个层面建立评估体系：
第一层，核心指标要分层评估。除了整体的准确率，还要按业务维度分组计算。比如客户分类模型，要看新客、老客、高价值客群的分类指标分别是多少，任何一个核心分组的指标掉队，整体精度都可能掩盖问题。
第二层，错误分析要落实到样本。找几十个模型预测错误的Case，人工检查错误模式，看是数据标注问题、特征缺失、还是模型决策边界不合理。
第三层，离线指标必须与线上指标建立对应关系。离线精度提升不代表线上业务指标提升，要把模型输出和业务结果之间的转化链路打通，建立离线到在线的红线关系。
这一块的经验是，宁可评估体系建得慢一点，也不要带病上线。因为线上发现问题时已经产生了真实业务损失，而离线评估发现问题的时间成本要低得多。
4. AI工程核心落地实战：从模型部署到RAG应用
4.1 模型部署与服务化：More是FastAPI还是TorchServe
部署是AI工程里“魔鬼在细节”体现得最明显的地方。很多人训练好的模型是pytorch的.pth文件，直接拿Flask包了一个服务就上了，结果一个请求延迟800ms，两个并发直接超时。
给你一套可复用的部署选型逻辑：
- 如果模型以CPU推理为主、QPS不高、注重快速迭代，FastAPI直接加载模型最合适；
- 如果模型需要GPU推理、并发较高，建议走Triton或TorchServe；
- 如果模型要嵌入移动端或边缘设备，需要先做ONNX导出与量化压缩。
我自己用的最顺手的路线是：PyTorch训练 -> 导出ONNX -> ONNX Runtime部署 -> FastAPI封装API -> Docker容器化发布。
ONNX导出的好处是运行时更轻量，推理性能明显优于直接使用PyTorch的Eager模式，方便跨语言调用。
导出代码大致如下：
import torch import onnxruntime as ort # 假设model是训练好的PyTorch模型 model.eval() dummy_input = torch.randint(0, 30000, (1, 128), dtype=torch.long) torch.onnx.export( model, dummy_input, "model.onnx", input_names=["input_ids"], output_names=["logits"], dynamic_axes={"input_ids": {0: "batch_size"}, "logits": {0: "batch_size"}}, opset_version=17, )注意dynamic_axes配置很关键，它允许推理时接收不同batch大小的输入，避免固定batch造成的资源浪费。
API层我习惯用Pydantic做入参校验，确保线上输入格式可控，避免脏数据进模型。部署不是终点，AI工程的重点还包括性能压测与容量规划。上线前至少要压一轮，明确单实例的QPS承载上限和P99延迟，再结合负载预估出需要起的实例数。
4.2 面向大模型应用的RAG系统：从零构建高效检索问答
大模型火爆之后，RAG（检索增强生成）几乎成了AI工程落地应用最广泛的技术路线。它的原理并不复杂：模型回答问题前，先从知识库中检索出相关的片段，拼接到提示词里，让模型基于这些证据作答。
但“原理不复杂”不等于“落地不难”。我自己从零搭RAG系统时，最大的坑发生在检索质量上，模型生成环节反而问题不大。
一个可靠的知识库检索链路，至少包含五个环节：
- 文本解析：不同格式文档（PDF、Word、Markdown、网页）统一转换为结构化文本；
- 文档切分：按逻辑结构切分为段落块，控制每块长度在256~512个token之间；
- 向量化：使用文本嵌入模型将每个块转为向量；
- 检索召回：用余弦相似度找到TopK相似块；
- 重排序：对召回的TopK再做一次精排，去掉不相关内容。
文档切分这块有一个经验参数：chunk_size取300个token左右、overlap设置10%~15%比较稳妥。切得太小，语义不完整；切得太大，检索噪声高，还浪费模型上下文窗口。
召回阶段我更偏向“向量检索+关键词检索”混合策略。向量检索擅长语义匹配但不擅长精确词匹配，BM25关键词检索正好互补。两类结果做融合，再用一个轻量级重排序模型（例如bge-reranker）做最终排位，整体检索效果会提升一大截。
此外，RAG系统上线后必须持续评估检索质量，指标看两大项：召回率（正确答案是否在TopK里）和MRR（答案排序的合理性）。我自己会把一批真实用户问题做成评测集，每个版本更新完都先跑一遍评测再上线。
4.3 大模型应用监控与多轮会话管理
RAG服务上线之后常被忽略的，是会话状态和监控体系。这里的“多轮会话”不是简单地把历史消息拼在一起，而需要设计好每一轮的引用管理、历史裁剪策略。
我的建议是把每个会话的context和检索结果都按轮次持久化，并且对每轮请求记录检索的TopK文档、模型返回内容、耗时等元数据。一旦用户反馈答错了，运维人员能精确追溯到是哪一轮检索召回出了问题。
监控方面，大模型服务的核心指标主要看这几个：
- 首Token延迟与总生成延迟：直接决定用户体感；
- Token吞吐量与成本：直接影响运营成本；
- 检索命中率与引用质量：特殊领域应用尤其关注；
- 失败率与超时率：服务稳定性的硬指标。
这些指标要接上告警。我自己习惯设定P99延迟超过3秒、失败率超过1%、检索空召回率超过5%时自动触发告警。
告警的意义不是事后补救，而是让问题在影响大量用户之前就被拦截。
5. 高概率踩坑的AI工程问题与排查实录
5.1 数据侧典型问题：泄漏、不平衡与脏数据
从零做AI工程，数据问题能占到所有问题的六成。以下三个属于高频问题，必须提前防治：
数据泄漏是最隐蔽的坑。特征中存在了未来信息，或者训练集和验证集包含同一来源的重复样本，都会让验证指标好看到离谱，上线后现出原形。解决办法是先用一个“含时间戳的字段”拆分数据集，并以实体ID为单位去重，而不是以样本行为单位切分。
类别不平衡会导致小类判别能力缺失。常用解法有三条：使用class_weight、过采样小类（如SMOTE）、更换评估指标为PR-AUC或F1。但最关键的还是理解不平衡的成因，如果是业务天然长尾分布，调采样权重比调模型参数更有效。
脏数据会导致检索结果质量大幅下降。文本里混有HTML标签、乱码、重复堆叠或编码异常时，向量化效果会非常差。数据入库前一定要做好清洗和格式校验，必要时写一个数据质量检查脚本直接挂在流水线入口。
5.2 训练侧典型问题：不收敛、爆显存与过拟合
训练问题每个人都会遇到。这里我说三个最经典的场景。
训练loss震荡不收敛，先检查学习率。如果loss乱跳且在验证集上完全没有规律，多半是学习率太大；如果loss下降极慢，则说明学习率太小。我的调试路径是先用一个较小数据集，把学习率从小到大各试一轮，找到一个快速收敛的区间，再按这个区间微调。
爆显存（OOM）的关键解法是削减小项。优先减小batch size；其次缩短max_length，比如从512降到256；再次使用梯度累积，攒够几步再更新参数。如果是小显存环境，还可以用混合精度训练，显存占用直接降约一半。
过拟合的判断标准，是训练集loss持续下降，但验证集loss不降反升。这时候优先加数据增强、加dropout、降模型容量，或提高权重衰减。如果过拟合已经很严重，先检查训练集和验证集分布是否一致，再决定下一步方案。
5.3 生产环境典型问题：延迟毛刺、冷启动与模型漂移
生产环境的坑和训练环境的坑完全是两回事。
延迟毛刺是最常见的问题。模型服务P99延迟很高，但平均延迟正常，通常是线程池配置不合理、GPU资源争抢或某个慢请求阻塞了队列。排查思路：先压测定位瓶颈，再看监控工具确认是CPU、GPU还是IO层的问题。AI服务上线前一定要做压测，没有压测就上线的服务，出了问题时基本无法定位。
冷启动问题是指服务刚启动时首次请求极慢。解决方案是启动时预热，先把模型权重加载到内存完成一次推理，再开始接收流量。
模型漂移是指线上数据分布随时间变化，导致模型准确率逐渐下降。检测方法很简单：记录线上输入的分布，每天和训练集的分布做一个相似度比较，超过阈值就告警。触发漂移后要做的事是：把近期的线上样本拉回来重新标注、增量训练、评估后重新上线。模型上线不是终点，持续迭代才是AI工程的常态。
6. 从零搭建AI工程的个人复盘与建议
走到这里，如果你真的从数据管理一路跟进到了监控告警，你会发现AI工程这个领域并没有那么神秘。它其实就是一套把“做实验的思维”和“写系统的思维”融合起来的能力体系。从零起步不是一个高峰期，而是一个持续爬坡的过程：第一阶段你会被数据折磨，第二阶段你会被训练折磨，第三阶段你会在部署与监控中疲于奔命。但只要扛过这轮循环，你就能发现自己面对一个新AI问题时，第一反应会从“能不能跑个模型”变成“这个事情完整交付需要跑通哪些环节”。
我个人有一个很深的体会：在AI工程这条路上，比模型效果更重要的，是可维护性和可复现性。哪怕模型效果不是最好的，只要它能稳定上线、能快速迭代、能被团队其他人接手维护，它创造的价值就远高于一个效果略好但无法接管的“孤品模型”。
最后再分享一个小技巧：从零搭建AI工程，不要贪多，先挑一个真实痛点项目，完整走一遍数据管理、实验追踪、模型训练、部署上线、监控鉴定的闭环。哪怕这个项目很小，只要闭环跑通了，后续扩场景就只是复制方法论。如果一上来就铺一个大而全的框架，大概率会卡在某个环节，把热情都耗光了。
这条路没有一步登天的方法，但每一步踩实了，都会成为后续所有项目的跳板。
