这几年被问到最多的问题不是“哪个模型效果最好”而是“我到底该怎么从零开始搞AI工程”。市面上的教程要么是纯理论推导看得人头昏脑涨要么是一键调用封装好的接口跑通一个demo就以为会了真到了换数据、调性能、部署上线的时候又两眼一抹黑。这个标题里的from-scratch我理解的意思不是让你从反向传播的数学公式手推一遍而是指不要依赖那些“黑盒式”的现成平台踏踏实实把AI工程落地所需的每一环——数据怎么理、模型怎么选、指标怎么定、服务怎么上——都亲手走通一遍。这篇文章就是围绕这条路径把我自己折腾了大几年的经验和踩过的坑按一个可复现的顺序拆开讲适合那些有一定编程基础、想真正进入AI工程领域但是还没找到合适路线的朋友。1. 先把“AI工程”这四个字拆开看1.1 AI工程和“跑个模型”完全是两码事很多人对AI工程的第一印象是“训练模型”。这个理解不能说错但确实狭窄了。我在实际项目里最深的感受是训练模型只是整条链路里很小的一个环节甚至很多时候模型层面的难度远小于数据层面和工程层面的难度。拿生活里的例子打个比方。训练模型就像学做一道菜菜谱网上到处都是照着步骤来大部分人都能炒出一盘能吃的菜。但AI工程是“开一家餐厅”你得考虑食材供应链稳不稳定数据管道、后厨的出菜效率训练与推理性能、食品安全合规内容安全与评估、顾客排不排队服务架构与并发、以及每天的菜单怎么根据顾客反馈调整持续迭代优化。一道菜炒得好不代表能撑起一家店。同样的道理模型离线指标刷得再高上线之后如果特征延迟、数据分布漂移、接口超时一样是个失败的项目。所以AI工程的核心能力图谱至少包含四大块数据工程获取、清洗、特征加工、质量监控、模型研发选型、训练、调参、评估、服务工程部署、推理优化、监控告警、项目治理实验管理、版本控制、成本控制。from-scratch的真正含义就是这四块能力你都要亲手摸过一遍而不是只会其中某一项。1.2 为什么“从零开始”依然是最快的路你可能会问现在工具链这么成熟用现成的AutoML平台、低代码AI服务不是更快吗我的观点很明确如果你是想快速验证一个想法的产品经理用现成平台没毛病但如果你是想成为合格的AI工程师那这条路反而更慢。原因在于AI工程的难点全在“边缘地带”。你调用现成的图像分类API永远不知道它为什么在某种灯光下表现变差你用AutoML跑出一个高精度模型也理解不了为什么换了一批时间分布不同的数据后效果就崩了。这些问题没有对底层原理和工程细节的亲身感知你连排查的方向都没有。我见过太多简历上写着“精通TensorFlow”的候选人遇到一个简单的特征泄漏问题都毫无头绪——因为他们的学习路径里根本没经历过这类问题。从零开始亲手搭建哪怕一开始做得粗糙一点你也会实实在在地获得“手感”知道数据质量对模型上限的影响有多大、知道模型评估指标欺骗你的时候有多悄无声息、知道一个小小的时间戳处理错误会让线上效果与离线评测天差地别。这些手感才是AI工程师真正的核心竞争力。所以我建议不论你最终的工作方向是CV、NLP还是推荐系统第一段学习路径都要用“从零搭建一个完整项目”的方式走一遍。2. 起步准备需要的前置条件和技术栈选型2.1 前置知识到底需要多深的数学和编程功底“从零开始”这四个字常常把人吓退大家总觉得需要先把高数、线代、概率论学得滚瓜烂熟才能动手。以我的经验这是最大的误解。数学和编程当然是基础但AI工程所需的深度和你想象的不一样。数学层面你不需要会推导复杂的证明但必须理解几个核心概念的直观含义梯度知道参数朝哪个方向调整能降低损失、概率分布知道样本和总体的关系、以及最基本的线性代数运算矩阵相乘到底在算什么。这些概念在日常工作中主要通过“调参时我在干什么”和“评估指标为什么长这样”这两个场景体现。遇到不懂的数学细节随时查、随时补比闷头啃书高效十倍。编程层面Python是绕不开的。但是“会Python语法”和“能用Python干工程”是两回事。我建议你在开始AI项目之前至少具备以下能力熟练操作pandas做数据筛选和聚合、能写清晰的类和函数封装代码、会用git做版本管理、以及具备基本的调试能力——print打日志、断点调试、阅读报错堆栈。这些能力看似基础但决定了你后续学习AI工程的上限。2.2 技术栈选型新手阶段不要贪多够用就好AI工程的技术栈非常庞杂但如果你从零开始我的建议非常“保守”用社区最主流、文档最全、找工作最认的那套组合不要追新、不要求全。表格对比一下常见技术栈的定位环节推荐技术为什么推荐暂缓考虑数据处理pandas numpy资料多、上手快、几乎覆盖所有表格类数据需求Spark、Dask等分布式框架模型训练scikit-learn LightGBM接口统一、算法丰富、调试友好适合建立对模型的直觉PyTorch/TensorFlow的深度学习项目深度学习可选PyTorch生态最活跃遇到问题搜得到答案自己从零写神经网络框架实验管理mlflow 或简单的CSV记录轻量、够用Kubernetes等重平台服务部署FastAPI Docker简单直接适合快速上线和调试微服务全家桶、服务网格很多新手容易犯的错是上来就学分布式训练、学GPU集群调度。这些技能确实酷但没有业务场景的驱动学了也是空中楼阁。我个人的经验是先用单机能把项目完整走一遍再按需扩展。先用最简单的工具链把端到端的流程跑通比一开始就上复杂架构有效得多。2.3 学习节奏建议不要按部就班要用项目倒逼学习正经的学习路径都是线性的先学Python再学pandas再学机器学习算法再学深度学习再学部署……这套路径的问题在于战线太长学到后面前面已经忘了而且始终没有“完成一个东西”的成就感。我建议反过来用“项目倒逼”的方式。定一个足够简单但不简陋的项目目标比如“从零搭建一个预测用户是否会在7天内再次访问的模型并封装成HTTP接口”。然后需要什么就学什么需要读数据就去学pandas需要处理缺失值就去看文档需要训练就去看逻辑回归和树模型的原理需要上线就去学FastAPI。当你把这个项目完整跑通你不但掌握了一大堆零零散散的工具更重要的是你已经理解了这些工具在整条链路上各自扮演的角色。之后再回头去系统补充理论知识认知会完全不一样。3. 从零搭建一个AI项目的完整实操过程3.1 项目定义用最常见的数据集跑通全流程纸上谈兵没意思直接进入实操环节。我选择用经典的人口收入数据集Adult数据集来演示一个完整的AI工程流程——任务是二分类根据一个人的年龄、教育程度、职业、工作时长等特征预测其年收入是否超过5万美元。为什么选这个数据集因为它足够真实包含数值特征年龄、资本收益等和类别特征职业、教育水平等而且自带明显的类别不平衡问题和缺失值非常适合展示数据工程中典型的处理手段。最关键的是它规模适中单机就能秒级跑完不给你折腾环境的机会。为了贴近工程实战我会刻意做得比普通教程“多一点东西”加入数据质量检查、特征泄漏防范、模型对比评估、以及模型的可解释性分析。这些环节才是AI工程和“跑一个算法”之间的差别。3.2 数据探索与质量检查动手之前先花70%时间看数据很多人拿到数据就急着开训练这是大忌。我的习惯是先花大量时间做探索性分析和质量检查。这个环节最大的价值不是让你“感觉数据没问题”而是让你尽早发现问题避免训练到一半才发现特征有问题。第一步查看数据形态。依次打印数据的shape、列名、前几行、描述性统计。代码很简单但有几个关键检查点需要铭记import pandas as pd train pd.read_csv(adult_train.csv) print(train.shape) # 样本量和特征维度 print(train.dtypes) # 列类型发现分类和数值特征 print(train.head(10)) # 肉眼观察数据合理性 print(train.describe(includeall)) # 分布概览这一步要重点看三样东西缺失值。Adult数据集的缺失值编码方式是问号?如果你不看前几行、只依赖于pandas自动识别就会把缺失当成普通类别埋下隐患。实际情况中缺失值可能有空字符串、NA、None、-999等多种编码方式靠肉眼过一遍是最笨但最有效的方法。类别特征的基数unique数量。比如职业列有多少种取值、国籍列有多少种取值。高基数类别特征比如上千种取值在后续处理中需要特殊对待这会影响特征编码的方案选型。数值特征的分布范围。capital-gain资本收益这类特征往往高度偏斜大部分是0少数是极大值。这种长尾分布的特征如果不做处理会干扰部分模型的训练效果。第二步验证数据逻辑。这一步是做AI工程的习惯具体到代码层面就是检查是否有明显矛盾或异常的数据行。比如工作时数hours-per-week为0但收入很高——不一定是错的但值得深挖一下比如教育年限与教育程度对不上——大概率是数据录入错误。3.3 特征工程与数据处理把原始字段变成模型吃得好的养料数据看完之后进入特征工程阶段。这个环节的目标是把原始数据转换成模型能够有效利用的数值特征。三个必做的任务处理缺失值、编码类别特征、切分数据集。Adult数据集的缺失值处理我采用先填充再标记的方式# 将问号统一转为缺失 df df.replace(?, pd.NA) # 类别特征用众数填充并额外保留“是否缺失”的标记 for col in [occupation, native-country]: df[col _is_missing] df[col].isna().astype(int) df[col] df[col].fillna(df[col].mode()[0])这里有个需要注意的工程细节为什么要额外加一列“是否缺失”标记因为在很多业务场景中“缺失”本身可能就是一个有信息量的信号。比如用户没有填写职业可能意味着他自由职业或无业这跟“填了职业却恰好没被记录”是不同的情况。加了标记列以后模型有机会自己学习这种信号的规律而不是被我们武断地抹掉。类别特征我直接用pandas的category类型再转成数值编码或者用OneHotEncoder。对Adult这种基数不高的场景OneHot是合适的选择。但要注意高基数的类别特征比如上千种职业盲目OneHot会带来特征维度爆炸并且稀疏编码对树模型也不友好。处理方式通常是做频次编码把类别替换成该类别在训练集中的出现频次或者目标编码用类别的目标均值做编码不过这背后的风险较大新手建议先把频次编码加进工具包等有经验后再碰目标编码。最后是数据集划分。这一步我要特别强调“时间意识”如果你的数据带时间戳切分时一定要按时间顺序切不要随机切否则会引入未来的信息训练集里的样本时间在实际业务中是不可能先于测试集出现的。Adult虽然没有时间戳但我们要从此养成习惯拿训练集的分布去拟合切分测试集必须保持“独立”。3.4 模型选型与训练先跑通基线再逐步优化数据集准备好以后进入模型环节。我的建议是严格按“三步走”先跑一个简单模型做基线再对比更复杂的模型最后做超参优化。第一步用逻辑回归做基线。逻辑回归虽然是线性模型但它简单、训练快、结果可解释性强作为baseline非常合适from sklearn.linear_model import LogisticRegression from sklearn.metrics import roc_auc_score, accuracy_score, classification_report model LogisticRegression(max_iter1000) model.fit(X_train, y_train) y_pred_proba model.predict_proba(X_test)[:, 1] y_pred model.predict(X_test) print(AUC:, roc_auc_score(y_test, y_pred_proba)) print(classification_report(y_test, y_pred))这里要明确一点对不平衡的二分类问题只看accuracy准确率是非常危险的。Adult数据里大约只有24%的人收入超5万就算模型不看任何特征、把所有样本预测为“低收入”准确率也有76%。所以一定要同时看AUC、Precision、Recall等指标。AUC不依赖具体阈值能综合评估排序能力是我做分类项目时必看的首项指标。第二步用LightGBM来对比。你会发现树模型在这个数据集上的表现通常明显优于逻辑回归因为它能自动捕捉特征之间的非线性交互。这一步的主要目的是让你直观感受“模型复杂度带来效果提升”的边界在哪里。import lightgbm as lgb model_lgb lgb.LGBMClassifier(objectivebinary, n_estimators300, learning_rate0.05, num_leaves31) model_lgb.fit(X_train, y_train, eval_set[(X_test, y_test)], eval_metricauc) lgb.plot_importance(model_lgb, figsize(10, 6))第三步做超参数搜索。我不建议新手一开始就上贝叶斯优化用简单的GridSearchCV或RandomizedSearchCV就足够。你需要关注的核心参数是树的棵数、学习率、叶子节点数决定模型复杂度。重点记住一个原则小幅调参、观察模型在验证集上的表现变化不要一次调一堆参数否则根本不知道是哪个参数起了作用。3.5 模型评估的坑你的指标可能正在骗你模型训练完先别急着高兴指标好。我在实操中最常提醒自己的一句话是指标高不等于模型好指标低也不等于模型没用。关键在于搞清楚指标是在什么“条件”下计算的。第一个常见的坑是用accuracy评估不平衡数据刚才说过了。第二个坑是使用随机切分的方式做交叉验证导致同一用户的多个样本同时出现在训练集和测试集。这在推荐系统、用户行为预测里极其常见叫“数据泄漏”。比如你预测用户会不会点击广告同一个用户前几次点击的记录被分到训练集后一次被分到测试集模型实质上“见过”了这个人测试分数虚高上线后立刻打回原形。正确做法按用户ID或时间进行分组切分GroupKFold / TimeSeriesSplit。用代码说明from sklearn.model_selection import GroupKFold # 假设有个列user_id gkf GroupKFold(n_splits5) for train_idx, val_idx in gkf.split(X, y, groupsdf[user_id]): X_train, X_val X.iloc[train_idx], X.iloc[val_idx] # 训练与评估...第三个坑是只在测试集上评估一次。很多人反复用同一份测试集调整模型调着调着测试集就被“污染”了——你已经参照测试集答案优化过模型了测试分数就失去了独立性。正确做法是分出训练集、验证集、测试集三份训练集用来学习参数验证集用来调超参数测试集只在最终评估时用一次。3.6 把模型变成服务从notebook到可接受请求的API模型训练完工作才完成一半。AI工程的另一半是让模型能真正被业务使用。最常见的方式就是训练好的模型打包成HTTP服务。我用FastAPI来做因为它的轻量程度和易上手程度对新手极其友好。下面是一个最精简的预测服务示例import joblib import pandas as pd from fastapi import FastAPI from pydantic import BaseModel app FastAPI() model joblib.load(model.joblib) preprocessor joblib.load(preprocessor.joblib) class Sample(BaseModel): age: int education_num: int occupation: str hours_per_week: int app.post(/predict) def predict(sample: Sample): df pd.DataFrame([sample.model_dump()]) X preprocessor.transform(df) proba model.predict_proba(X)[0, 1] return {probability: float(proba), prediction: int(proba 0.5)}这一步有几个工程细节训练好的模型和预处理参数用joblib序列化保存服务启动时加载一次避免每次请求重复加载输入数据用pydantic定义结构FastAPI会自动做数据校验非法请求直接被拦截省去大量手工校验代码预测接口返回概率值和阈值结果这样调用方可以自己决定阈值而不是由你强制指定。线上部署我推荐用Docker封装。Dockerfile可以简单到只有十几行FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY app.py . COPY model.joblib . COPY preprocessor.joblib . CMD [uvicorn, app:app, --host, 0.0.0.0, --port, 8000]这个配置的好处是环境一致——你在本地跑通的服务到了服务器上行为一模一样不会出现“我机器上明明好的”这种尴尬。4. 常见坑与排查技巧这些坑我替你先踩了4.1 训练和线上预测的预处理逻辑不一致后果很严重这是新手最容易犯、也是最隐蔽的错误。你训练模型时用整个训练集的均值去填充缺失值但线上实时预测时如果不知道这个均值是哪个数可能使用了不同的方式去处理缺失模型拿到的输入特征分布就变了效果自然下滑。解决办法把“训练阶段拟合出来的所有参数”统一封装成一个preprocessor对象训练完一并序列化保存预测时只调用这个对象。千万不要在预测代码里重写一遍预处理逻辑。我在实际项目中就把这列为code review的必查项测试样本从原始输入到模型输入的每一步转换都必须与训练流程完全一致。4.2 类别编码不一致训练用的映射表和线上用的不是同一份刚才提到的类别特征编码也有同样的隐患。训练时你做了OneHot编码编码器记住的类别列表里有“某类职业”线上预测时来了一个训练集没出现过的新职业编码器可能直接报错或者静默地把它当成默认值。这种问题在真实业务中非常常见因为真实数据永远在变化。解决思路有两个层面一是给模型输入加一道“白名单过滤”把未登录的类别先映射到“其他”再进入编码器二是在模型侧预留unknown类别的处理逻辑。我建议先做第一层简单有效代码大概长这样known_categories set(preprocessor.named_transformers_[cat] 的categories_列表) raw_value 某个新职业 if raw_value not in known_categories: raw_value Other4.3 效果不符合预期时先别急着调参先查数据和特征我见过太多人线下AUC很高但线上效果差第一反应是换更复杂的模型、加更多特征。我的经验是绝大多数这种问题根源不在模型而在特征一致性。常见的三类根因训练集和线上特征分布不一致。训练数据来自历史某段时间线上数据来自当前用户行为模式已经变了。特征含义不一致。训练时“注册时间”字段来自用户表线上接口拿到的“注册时间”来自埋点表两个时间的定义可能完全不同。特征时效性问题。某些特征比如“最近一次登录距今天数”在数据库里计算时用的是当下的日期训练时也用了同样的逻辑但如果重复计算的特征没有严格按样本时间戳推算就会把未来的信息泄漏进训练集导致训练指标虚高。排查方式也很有套路先写一个程序把训练集的特征分布和线上请求日志的特征分布逐列对比哪个特征分布漂移了问题就定位到哪个特征。不要凭感觉猜用数据说话。4.4 依赖版本差异把环境配置写死不要用“最新版”AI工程的复现性很大程度上由依赖版本决定。一个numpy、pandas或者sklearn的版本升级都可能微妙地改变结果。我踩过最深刻的一次坑是本地训练用的LightGBM是4.x线上服务器用的还是3.x结果predict_proba的结果对不上查了两天才发现是版本问题。建议在项目里固定版本号requirements.txt里不要写pandas而是写pandas2.1.4这种精确锁定的版本。更进一步可以用poetry或uv来做依赖管理。和docker搭配后基本可以做到“任何时间、任何机器、任何环境都复现出同样的结果”这种可复现性是AI工程区别于AI实验的重要标志。4.5 问题排查速查表现象可能原因排查步骤训练精度高线上效果差特征泄漏 / 训练测试分布不一致检查特征是否包含标签信息对比训练集与线上特征分布模型预测全为同一类类别极不平衡 / 阈值设置不当查看正样本比例检查模型输出的概率分布而非硬分类API响应时间过长每个请求都在加载模型或重复做特征计算检查模型加载是否在函数内部特征计算是否有缓存Docker起来后无法连接端口映射问题 / 服务没有绑定0.0.0.0检查docker run -p参数检查uvicorn host参数5. 工具链的进一步选择与项目扩展方向5.1 什么时候该升级工具链从单机走向平台当你用前面的流程完整走过两三个项目后单机脚本的方式会遇到瓶颈。典型表现是数据量大到pandas跑不动了实验记录散在各处想复盘找不到之前的参数配置模型越来越多手动管理版本开始出错。这时候才需要考虑升级工具链而不是提前为“未来可能遇到的大数据”焦虑。优先升级方向有三个数据量大了用Polars替代pandas内存效率高几个量级再大就上Spark实验管理上引入MLflow做实验跟踪和模型注册至少把参数、指标、模型版本管起来调度和流程上把训练流程用Airflow之类的工具编排成定期任务。我的建议是每一步升级都要有明确的痛点驱动。不要因为某个工具“流行”就上AI工程讲究的是恰好够用。5.2 从传统机器学习走向深度学习和LLM应用到这一步你已经能完整做传统机器学习的AI工程项目了。接下来根据自己的工作方向再选择深入哪一个分支。如果往视觉、语音、自然语言处理方向发展需要进入深度学习领域——从PyTorch入手学习CNN、RNN、Transformer等结构随之而来的是需要接触GPU训练、模型压缩、推理加速这些工程问题。如果往大模型应用方向发展重点是学会驾驭模型的能力Prompt设计、RAG架构、模型微调、以及评估LLM输出的质量——这一块的“AI工程”色彩更强因为你不再只和结构化数据打交道还要处理文本切分、向量检索、上下文管理等新问题。不管选哪个方向底层能力都是通用的数据处理、模型评估、服务部署、问题排查这些你已经具备了。这就是from-scratch路径最大的红利——你不是在学一堆工具而是在建立整个AI工程的地基地基稳了上面盖多高的楼都不虚。我个人这几年带团队最深的体会是一个工程师能不能在AI项目里独立扛事看的不是他会多少框架而是他面对一个没有标准答案的问题时有没有一套自己的排查链路和判断标准。这套链路不是靠看教程看出来的一定是从零开始把一个项目亲手做完整之后才真正长在身上的。希望这篇文章能帮你跨出这第一步。
