近几年大模型和各类Agent框架把AI的门槛压得很低随便拖拽几下、调两个API就能拼出一个看起来像模像样的Demo。但我心里一直有个不安如果我只会当“搬运工”哪天底层框架一换、接口一变我还能不能独立把一个AI项目从数据做到上线带着这个念头我给自己定了一个任务代号就叫ai-engineering-from-scratch从零开始不借助现成大模型API、不依赖拖拽式平台尽量只用最底层、最裸露的组件把一个AI工程完整走一遍。这篇文章就是这次自建路线的完整复盘包括路线怎么设计、工具怎么选、坑长在哪儿以及哪些地方我先替你踩过了。内容比较长适合准备系统入行AI工程、或者已经会用现成工具但想补底层功底的人。看的时候不用急着记步骤先把每个环节“为什么这么做”想清楚后面才不容易跑偏。1. 为什么一位从业者要从零开始重走 AI 工程1.1 当AI工程被“封装”裹挟时判断力反而变得稀缺现在很多教程教的是“调包”数据丢进框架模型自己训练接口一封装就算完事。但真实业务里最费时间的往往不是建模那一下而是数据质量、评估口径、部署链路和线上反馈这些“脏活累活”。如果你从第一次接触AI就是靠高级封装你对这些环节的敏感度会很差。数据里混了重复样本你看不出来训练集和测试集发生信息泄漏你也不知道为什么线下指标好看、线上烂成一锅粥。我设计这个 from-scratch 项目的初衷就是强行拿掉那些“帮你兜底”的层。不用现成AutoML不套用快速推理模板训练循环自己写特征自己加工部署用最简方案自己搭。这当然更慢但慢的好处是每一个环节都亲手动过出了问题你能直接定位到是哪一层、哪个参数甚至哪一行代码的问题而不是茫然盯着错误日志瞎猜。1.2 “从零开始”不是“石器时代造轮子”而是第一性原理重建有人一听 from-scratch 就觉得要连神经网络都从反向传播手写一遍。我不排斥手写但我更倾向把这个词理解为“从第一性原理出发理解每个环节成立的条件”。手写反向传播可以帮你理解梯度但工程上我们仍然可以用PyTorch自动求导“不用现成工具”是手段不是目的。这个项目真正的边界是三个层级第一层任何抽象工具我必须知道它的内部逻辑第二层默认方案不能满足需求时我有能力自己实现替代品第三层我能解释每一个关键参数为什么存在、敏感点在哪里。达到这三层框架怎么换、工具怎么迭代你都有底气快速迁移。这也是我和“只会调用”最大的区别会调用的人记参数懂原理的人调参数。2. 可供复制的自建路线四阶段递进2.1 阶段一数据基本功比建模更值得先下功夫我规划的第一个阶段不是模型而是数据。整个项目里我给自己定了三条硬指标第一全程只用自己清洗过、肉眼质检过的数据集不拿现成赛题数据直接跑第二特征加工必须写清楚逻辑包括缺失值为什么这样填充、异常值为什么这样截断第三对每个字段做出数据质量报告记录有效值占比、分布形态和潜在泄漏风险。这个阶段的核心工具是 Pandas 和 Polars。初期我刻意多练 Pandas groupby、merge、pivot 这些基础操作因为日常数据清洗里它们几乎躲不掉。等到熟悉了这些操作之后再换 Polars 处理百万级以上数据体验会好很多。这个阶段最容易犯的错是把数据清洗当成纯体力活而失去警惕。比如我看到很多人习惯用df.dropna()一行代码删掉缺失行但从不问缺失是不是有偏的如果缺失值集中在高价值用户群体你删掉这些行后续模型天然对高价值用户失明。我在项目里专门做了一张“缺失值地图”记录每个字段的缺失率、与目标变量的关系再决定填充策略。项目做完之后复盘这步花掉的时间大概是建模的两倍但省下的调参时间远不止两倍。2.2 阶段二在裸特征上做基线建模找回评估的坐标系第二个阶段是建模但我不允许自己一上来就上深度学习。我要求自己先用逻辑回归、决策树和 XGBoost 把同一批特征完整跑一遍目的有三个建立简单的基线条、熟悉分类模型的输出结构、锻炼指标解读能力。这里有一个特别容易被忽略的点评估指标不是“选一个”就完事而是要建立坐标系。准确率在类别均衡时勉强可用一旦正负样本比例悬殊它几乎没有参考意义。我在项目里同时观察精确率、召回率、F1、AUC还会单独打印混淆矩阵。特别是AUC 和 PR 曲线的配合前者看整体排序能力后者看少数类上的表现。这个阶段最大的收获是形成“先基线后复杂”的节奏。很多人一上来就把复杂模型跑出来结果基线没建根本判断不了复杂模型到底赢在哪。先把逻辑回归跑通拿到一个不算好看但可信的指标再逐步加复杂度每一步都能看到增量来源——这比黑盒式地换来换去要可靠得多。2.3 阶段三进深度前先手写训练循环拆掉黑箱进入第三个阶段我开始引入神经网络但刻意不用高级封装。我要求自己用 PyTorch 手写一个最小可用的训练循环数据加载、前向、损失计算、反向传播、参数更新、验证。这个过程并不复杂也就几十行代码但它把“训练”这个概念从玩具变成了可动手操作的结构。训练循环里我最先关注的是三个容易出错的位置model.train()和model.eval()切换、optimizer.zero_grad()的位置、以及验证阶段是否包含梯度计算。新手最容易把零梯度和反向传播的顺序写错导致梯度累加也容易在验证时忘了torch.no_grad()白白浪费显存和计算时间。这里我给一个自检清单照着跑能减少很多基础错误每次反向传播前是否做了optimizer.zero_grad()验证阶段是否确认没有 dropout、没有梯度计算训练损失下降但验证损失上升时是否立刻想到过拟合而不是继续堆迭代学习率设置是否过大会导致损失震荡过小则长时间不收敛在这个阶段数据集的类别均衡、学习率策略、batch size 对稳定性的影响全都亲手调过一遍之后你才真正对“深度学习调参”有了手感。后面再上手任何封装库你打开自动日志时能一眼看出哪一步设置不对。2.4 阶段四从模型到服务的闭环上线只是起点最后一个阶段是部署和观测。我用最轻量的方案把训练好的模型序列化再用 FastAPI 包成一个带/predict接口的服务容器化部署在本地然后用脚本模拟线上请求做联调。这个环节的意义不是让你成为运维专家而是理解“模型上线远不止训练结束”。部署中真正折磨人的不是写接口而是训练/推理不一致。我用一个最简单的例子来说明训练时你对特征做了标准化用的是训练集的均值和方差推理时如果重新对单个样本计算均值和方差预测结果就会漂移。正确做法是保存标准化器推理时直接调用同一个标准化器处理新样本。类似的问题还有特征顺序不一致、缺失值填充逻辑不一致、标签编码类别漂移。这几个问题不遇到一次很难形成肌肉记忆。我建议所有人在把模型投入线上之前至少做一次影子测试让新模型和旧方案同时跑一段时间对比预测分布而不是第二天直接切流。影子测试的成本不高但它能把“部署后才发现异常”的风险提前截住这是我强烈建议写入流程的一步。3. 核心细节拆解一次端到端实操实录3.1 项目选择与场景假设不挑玩具但也不贪大实操部分我选了一个贴近业务的题目二手交易平台用户成交概率预测。输入是用户的浏览行为、商品信息、历史交互记录输出是用户是否会在当前商品详情页产生成交行为。这个问题类别不均衡、特征类型丰富、存在时间顺序非常适合练手。我没有用现成爬好的免费数据集而是模拟原始数据进行处理把用户行为表、商品表、订单表分别构造出来再通过 join、groupby、窗口函数等操作聚合出训练用宽表。这一步很值得做因为真实业务里几乎没有现成宽表摆在那里等你喂给模型特征之间的关联关系都需要自己从明细数据中提炼。3.2 数据准备与特征工程质量比数量优先数据准备阶段我做了一张字段清单逐项记录字段含义、类型、缺失率、取值分布、是否需要特殊处理。这张清单后来成为排查问题的基础参照强烈建议你也养成这个习惯别嫌麻烦。在这个项目里有三个特征加工细节印象深刻时间类特征我不仅用了日期还加工出“距注册天数”“距上次活跃小时数”这类相对时间。绝对时间在模型里几乎没意义相对时间才能刻画用户行为倾向。行为频次类特征对每个用户按行为类型统计过去7天和30天的浏览、收藏、询价次数。频次特征比原始明细特征对成交概率的区分度高很多。缺失值处理对“商品成色评分”这种偏主观字段我没有用均值填充而是单独用is_missing特征标记缺失再用中位数兜底。这样既保留缺失信息又避免极端值影响。这里有一个判断直觉特征数量不是越多越好但特征的信息量一定是越多越好。特征工程阶段我会反复看特征与目标变量的分组均值不断丢掉区分度低的特征。这个阶段每丢一个垃圾特征后面模型训练就少一个干扰源。3.3 建模环节训练之前先设计评估方式建模之前我先划分数据集。因为有时间顺序我坚持只用时间切分不随机切分前80%的时间窗口做训练集后20%做验证集。随机切分会把未来信息提前泄露给模型导致线下指标虚高这是时间序列类业务里最容易踩的坑。建模环节我用代码演示最小可用的逻辑回归训练流程import pandas as pd from sklearn.linear_model import LogisticRegression from sklearn.metrics import (roc_auc_score, precision_score, recall_score, confusion_matrix) # 假设 X_train, X_test 已经完成特征加工 model LogisticRegression(max_iter500, class_weightbalanced) model.fit(X_train, y_train) # 预测概率和类别 prob model.predict_proba(X_test)[:, 1] pred (prob 0.5).astype(int) # 多指标观察 print(AUC:, roc_auc_score(y_test, prob)) print(Recall:, recall_score(y_test, pred)) print(Precision:, precision_score(y_test, pred)) print(confusion_matrix(y_test, pred))注意我在逻辑回归里加了class_weightbalanced这是因为成交用户占比不到10%正负样本严重失衡。加了这个参数之后模型会更积极地识别正类样本但副作用是误判可能增多。所以你要看实际业务更在意哪个是希望不错过潜在客群还是希望减少无效打扰。我实时盯着精确率和召回率的动态平衡再决定是否下调阈值到0.4、0.3而不是死守0.5这条默认线。逻辑回归跑通后我换成 XGBoost 做同样的训练并做简单超参数搜索import xgboost as xgb from sklearn.model_selection import GridSearchCV model xgb.XGBClassifier( n_estimators200, max_depth5, learning_rate0.1, subsample0.8, colsample_bytree0.8, eval_metricauc ) params {max_depth: [4, 6], learning_rate: [0.05, 0.1]} search GridSearchCV(model, params, cv3, scoringroc_auc, verbose1) search.fit(X_train, y_train) print(best params:, search.best_params_) print(best AUC:, search.best_score_)这类树模型有个好处能自动处理缺失值、对特征尺度不敏感、特征重要性可以直接输出很适合用来做特征筛选。我给每条特征打上重要性分把重要性垫底的特征筛掉再训练结果模型更轻指标却不掉——这就是好的特征工程带来的效果。阶段三我再用 PyTorch 手写一个两层的简单神经网络对比它在同一任务上的表现。这里为了控制篇幅我只展示训练循环的核心骨架import torch import torch.nn as nn class SmallNet(nn.Module): def __init__(self, in_dim, hidden_dim64): super().__init__() self.net nn.Sequential( nn.Linear(in_dim, hidden_dim), nn.ReLU(), nn.Dropout(0.2), nn.Linear(hidden_dim, 1) ) def forward(self, x): return self.net(x).squeeze(1) model SmallNet(X_train.shape[1]) optimizer torch.optim.Adam(model.parameters(), lr1e-3) loss_fn nn.BCEWithLogitsLoss() for epoch in range(30): model.train() optimizer.zero_grad() logits model(torch.tensor(X_train, dtypetorch.float32)) loss loss_fn(logits, torch.tensor(y_train, dtypetorch.float32)) loss.backward() optimizer.step() if epoch % 5 0: model.eval() with torch.no_grad(): val_logits model(torch.tensor(X_test, dtypetorch.float32)) val_loss loss_fn(val_logits, torch.tensor(y_test, dtypetorch.float32)) print(fepoch {epoch}: train_loss{loss:.4f}, val_loss{val_loss:.4f})这一段代码跑起来之后你才算真正掌握了训练闭环。后面你想切换到任何高级封装都只是把循环体换成现成方法而对“损失”“优化”“验证”的感性认知已经是自己的了。三类模型对比下来逻辑回归的可解释性最好XGBoost 的线上效果和训练效率最平衡小神经网络的提升幅度没有想象中大。这个结论不惊人但它是自己亲手验证过的和看别人文章写的结论完全是两回事。实际业务里我也不一定都选最复杂的模型而是综合考虑训练成本、维护成本、解释成本再去定最合适的那个。3.4 部署侧的最小可行方案FastAPI 加序列化模型部署环节我用 FastAPI 做了一个最小可用的预测服务。这里贴出核心接口代码import pickle import numpy as np from fastapi import FastAPI from pydantic import BaseModel app FastAPI() # 把训练好的模型和标准化器一起加载 model pickle.load(open(model.pkl, rb)) scaler pickle.load(open(scaler.pkl, rb)) class Item(BaseModel): features: list[float] app.post(/predict) def predict(item: Item): # 注意推理时使用训练时保存的标准化器而不是重新计算 features np.array(item.features).reshape(1, -1) scaled scaler.transform(features) prob model.predict_proba(scaled)[0][1] return {prob: float(prob)}部署的易错点全在细节里。我第一版接口就踩了坑训练时特征顺序是 a, b, c但接口接收的参数顺序是 c, a, b结果线上预测概率全乱了。后来我强制要求特征列表必须有版本号接口传参前先校验字段名顺序不一致直接报错绝不静默推理。这个校验看似多余实际能挡住大量低级事故。上线之后我加了两个最基础的线上监控调用延迟和预测概率分布。预测概率分布如果某天突然整体偏移那很可能不是模型自己出了问题而是上游特征计算逻辑被改了或者线上用户群体发生了结构性变化。这类问题很难通过回看模型指标发现必须靠分布监控提前预警。4. 常见问题与排查技巧实录越过这些坑才算入门4.1 我踩过的六类高频问题问题现象根因排查路径数据泄漏线下AUC很高比如0.98线上完全失灵特征里混入未来信息或目标相关字段逐字段检查定义特别小心“业务发生之后才会更新”的字段类别失衡准确率高但召回率极低正样本占比太小模型默认全预测为负类使用类别权重、过采样/欠采样、PR曲线来判断训练/推理不一致单条数据预测稳定偏低推理预处理与训练不一致统一封装预处理逻辑保存标准化器/编码器供推理复用梯度异常loss 出现 NaN学习率过大、数据含异常值、权重初始化不当调低学习率截断异常值检查输入是否含非数值特征签名变化模型报维度错误特征数量不一致建立特征清单与版本号训练和推理共用同一份配置过拟合训练损失一直降验证损失掉头上涨模型复杂度过高或数据量不足加正则化、增dropout、减少模型层数或增强数据这六个问题在真实项目里出现频率极高我建议你把它记成一张速查表每次模型效果不对就按表格逐项排查。能系统定位问题的工程师一定比只会盲目调参的人高效得多。4.2 独家避坑清单写得再细一点第一不要把随机切分当成万能手段。只要数据里有时间维度、用户ID维度随机切分就可能泄漏。哪怕是像“同一个用户在训练集和测试集同时出现”这种看似不严重的重合也会让模型在线上遇到新用户时表现打折扣。我做项目时严格要求测试集用户不能出现在训练集里时间窗口不能重叠。第二保存你预处理环节的全部配置。很多人只保存模型权重但从没保存标准化器、类别映射表、特征列表。结果模型一上线就发现推理端拼不出和训练时一致的特征。我在项目里用 JSON 记录“预处理配置”同类场景直接复用避免重新理会这段历史。第三给实验建立实验记录表。记录每次实验的数据范围、特征版本、模型类型、超参数、指标结果。看起来只是多个一个表格但它能让你两个月后回头看时快速判断某个实验为什么有效。我在这次项目里反复因为实验记录不全而重复跑测试后来痛定思痛每跑一次就记一次效率和心情都好了很多。第四别让测试集的分布影响你的特征工程。我在做数值量纲清洗和异常值截断时只使用训练集统计量绝不用全量数据去算均值和分位数。如果用了全量数据测试集信息就悄悄进入了预处理阶段线下指标依然会虚高。这条坑很隐蔽我第一次做时毫不意外地踩了进去。5. 这个工程补完之后我真正得到的是什么从零开始走完这一整轮我最大的感受是AI工程不是模型算法的堆叠而是一整套“数据逻辑、实验逻辑、工程逻辑”的组合能力。以前我拿到一个项目第一反应是“用什么模型”现在我第一反应是“目标怎么定义、数据怎么组织、评测怎么设计”模型反而成了最后才落下去的那一步。我最想推荐你复做的不是某段代码而是这份节奏感先做清晰的基线再逐步加复杂度先写训练循环再上高级封装先把评估方式想清楚再动手训模型。只要这几个顺序不倒置你踩的坑至少会少一半。如果你准备开始类似项目我给你一个落地建议不用执着于一上来就复刻大型项目选一个小而真实的问题从原始数据处理一路做到模型部署再把这整套流程沉淀成自己的模板。一次完整的闭环比一百个零散Demo更能建立工程直觉。这个方向接下来可以扩展的地方还有很多比如给Pipeline加自动化重训机制、接指标回灌做实验管理再比如加上概念漂移检测。但万变不离其宗只要你功底在工具永远可以换着用。我的路线已经帮你蹚过一遍了接下来的坑和惊喜你得亲自踩一踩才算数。