经常有人问我从零开始学 AI 工程到底该走一条什么样的路我最初接触 ai-engineering 这个词的时候以为只是多学几个深度学习框架、会调参就算入门。等到真正把一个模型从训练跑通到上线、再维护几个月之后才意识到 AI 工程是另一套完全不同的能力组合。这篇博文就是想把“from scratch 学 AI 工程”的完整路径、核心技术点、实操步骤和踩坑经验一次讲透。如果你是零基础想入行或者已经会训练模型但总觉得工程化那部分很虚这篇内容应该能帮上忙。1. 先想清楚再动手AI 工程不是“调包”是工程系统1.1 为什么“从零开始”最大的坑是先写代码我见过太多人一上来就装 TensorFlow、PyTorch然后照着教程跑个 MNIST跑通了就觉得“我会 AI 了”。实际上那只是学会了“调包”。AI 工程的核心不是训练出一个模型而是把模型变成稳定、可维护、可监控、能持续迭代的软件系统。from scratch 的真正难点在于你在没有系统经验的前提下同时面对数据、算法、工程、运维四件事。如果一上来就埋头写代码大概率会在项目中期发现数据没有梳理清楚、特征管线和训练代码耦合在一起、模型上线后没人知道它表现是否正常……这些问题的根子恰恰是在动手前缺少系统性的认知。我自己的路径是先花两周时间梳理“AI 工程到底包含哪些环节”再按链路去补知识最后才动手写代码。这个顺序看起来慢实际上是最省时间的。1.2 AI 工程的能力图谱六大块在从零规划学习路线之前建议先把 AI 工程的整体版图画出来。我个人把它分为六块数据工程采集、清洗、存储、特征加工、数据质量监控。模型开发特征选择、模型训练、超参优化、离线评估。模型部署把模型封装成 API、批处理任务或边缘服务。运维监控在线指标、模型漂移、数据漂移、日志与告警。持续迭代自动重训、AB 实验、灰度发布、版本回滚。平台与流程代码管理、CI/CD、环境一致性、团队协作规范。这六块里前两块大多数人会比较熟悉后四块才是“AI 工程”区别于“AI 研究”和“算法调参”的地方。我见过很多算法工程师能训练出漂亮的离线指标但一到了解线上稳定性就手足无措就是因为后四块的能力没有系统补上。1.3 和“炼丹调参”的区别工程化才是分水岭一句话概括调参是为了“让模型在某个数据集上表现好”工程化是为了“让模型在任何时候都可靠地工作”。举个例子你在 Jupyter Notebook 里用 pandas 处理数据没有问题但到了生产环境你需要考虑凌晨两点数据源抽风导致字段缺失怎么办上游schema变更后特征管道是否会静默出错模型在线上的延迟从 20ms 涨到 200ms 是否需要告警这些都不是算法题而是工程题。所以from scratch 的学习一定要把“工程思维”和“算法思维”并行培养而不是先学完算法再学工程。工程思维可以简单理解为任何环节都要有可观测性、可回滚性、可复现性。2. 打地基数学、编程、数据三块基石怎么补2.1 数学到底要补多少够用原则很多新手一听说 AI 工程就开始担心数学不够好。这里我想给一个反直觉的建议工程方向不需要你成为数学家但需要你理解核心概念的直觉。具体来说线性代数需要掌握矩阵乘法、向量空间、特征值分解的直觉概率统计需要理解分布、期望、方差、极大似然估计、贝叶斯思维微积分需要理解导数、偏导数、梯度下降的含义。至于证明、推导这类深水区除非你要做算法研究否则在工程岗的实际工作中用的频率很低。我的经验是把 “3Blue1Brown” 的线性代数、微积分、概率论三个系列看一遍配合任何一本入门教材做例题就够用。关键不是会证明而是看到一个公式能反应出它在机器学习里对应什么操作。比如看到 sigmoid 函数要立刻想到二分类输出层和梯度平滑的特性。2.2 Python 要学到什么程度代码能力到哪一层才叫“会用”AI 工程对 Python 的要求远不止“会写循环和函数”。至少要达到下面这个水平熟悉内置数据结构及其复杂度知道什么时候用 list、dict、set。会用 pandas 做数据清洗、分组聚合、透视能处理缺失值和异常值。会写类、装饰器、上下文管理器能理解 Python 对象模型。会使用虚拟环境和依赖管理工具能复现环境。具有基本的面向对象设计能力知道如何拆分类、抽象接口。不需要去背 Python 标准库的全部模块但需要建立“遇到问题知道该查哪个库”的感觉。我个人的建议是用 LeetCode 简单到中等的题目练手不是为了刷题而是为了养成“写出的代码能健壮运行”的肌肉记忆。另一个更贴近实际的方法是把你日常处理 Excel 数据的操作全部改成用 Python 脚本完成。2.3 数据能力SQL 和特征理解很多时候比模型更重要我做了几个项目后的最大感受是AI 工程的上限往往由数据质量决定而不是模型结构。因此SQL 是必修课。至少要做到熟练使用 join、group by、window function、子查询。能理解分区表、事件表、维表的设计模式。会排查数据任务能发现数据口径不一致的问题。我在实际干活时经常遇到一种情况沟通业务需求时发现“预测目标”本身定义就有歧义。比如“用户流失”到底是 30 天未登录还是连续两个月没有付费还是投诉后退订这个定义不同标签样本就差很多最后模型效果有巨大差异。理解数据本质上是理解业务这一点很难靠学一门课解决。3. 核心技能拆解从模型训练到部署运维的完整链路3.1 特征工程决定了模型上限模型训练可以很快但特征工程往往占掉一个项目 60% 的时间。特征工程的核心是把你对业务的理解编码成模型能利用的信息。按我常用的分类特征主要有四类原始字段特征如年龄、注册时长、历史消费金额。统计聚合特征如近 7 天登录次数、近 30 天平均消费。时间窗口特征如距离上次登录的小时数、最近一次活动距今多久。交互特征如消费频次和客单价的比值、活动参与率。特征工程里最容易犯的错是“顺手把未来信息放进特征里”。比如用用户当天的退款金额去预测当天是否流失这就是典型的数据泄漏离线指标会虚高得离谱上线后立刻被打回原形。处理时间序列问题时一定要确保特征的计算时间点严格早于预测时间点。3.2 训练与评估别只看准确率分类问题里准确率是最容易误导人的指标。比如一个流失率为 5% 的业务你把所有人都预测成“不流失”准确率也有 95%但这个模型毫无用处。工程上我更推荐看这几类指标精确率和召回率以及它们的平衡点 F1。PR 曲线和 AUC用于评估排序能力。预测概率的校准程度看模型给出的概率是否反映真实比例。不同业务阈值下的收益比如设定不同流失概率阈值时挽回的用户群体有多大。尤其是最后一个“业务收益评估”是 AI 工程和学术实验最大的区别。同样一个 AUC 提升 0.01 的模型放在高客单价业务里可能意味着每月几十万营收提升放在低价值场景里可能根本不值得上线。3.3 部署上线模型服务的三种方式模型部署不是只有“写一个 API”这一种方式实际上要根据使用场景选择在线 API 服务适合实时推理比如风控判断、推荐排序、客服机器人。要求延迟低、吞吐可控通常用 FastAPI 或 Flask 封装模型加一层负载均衡。批处理任务适合大规模离线推算比如每天凌晨给全量用户打分生成推荐列表。一般用 Airflow 或调度脚本配合特征库执行。流式计算适合毫秒级事件处理比如实时点击流特征计算。通常用 Kafka 加 Flink 配合模型服务。我建议新手从批处理和在线 API 两件事做起流式计算可以作为进阶。最常见的坑是“用一个 API 硬扛所有流量”没有做缓存、没有设置超时、没有限流结果流量稍微上来就雪崩。3.4 监控与迭代上线不是终点模型上线后的第一周是最容易出问题的一周。你需要监控的东西至少包括数据质量监控特征缺失率、取值分布变化。预测分布监控模型输出的概率分布是否发生明显偏移。业务指标监控点击率、转化率、流失率是否出现异常。服务性能监控延迟、错误率、CPU/内存占用。当真实数据分布发生变化模型效果必然下降这时候就需要重训。但重训不是“点一下按钮”就行需要对比新旧模型在回溯数据上的表现再做 AB 实验。灰度发布配合自动回滚能让你在模型出问题时快速恢复。3.5 工具链选型主流技术栈参考下面这套是我在多个项目里用下来比较顺手的组合也是行业里相对主流的选型环节工具备注数据处理pandas、SQL、Spark小数据用 pandas大数据切 Spark实验跟踪MLflow记录参数、指标、模型产物特征存储Feast在线离线一致性需要它模型训练LightGBM、XGBoost、PyTorch表格数据优先树模型文本图像再上深度学习服务封装FastAPI自带 OpenAPI 文档性能不错容器化Docker Kubernetes小项目先 Docker规模上来再加 K8s调度Airflow批处理任务的首选监控Prometheus Grafana指标采集和可视化告警也靠它不建议一上来就奔着大数据那一套去因为很多项目的数据量在一开始根本不需要 Spark。先学会用干净的工具把端到端跑通再按需引入重型组件。4. 从零搭建一个可运行的项目客户流失预测系统4.1 项目背景与数据形态这里我挑一个最适合新手完整复刻的项目电信客户流失预测。数据是公开的特征相对规整业务逻辑清晰非常适合用来打通整个 AI 工程链路。假设我们有客户的基础信息、开通服务类型、账单金额、使用时长以及一个标签列表示该客户是否流失。任务就是训练一个模型并在模型上线后持续监控它的表现。整个系统设计为四层数据层CSV 存储在本地后续可以替换成数据库。特征层pipeline 统一加工保证训练和预测用的是同一套逻辑。模型层用 LightGBM 训练分类模型用 MLflow 记录实验。服务层FastAPI 起一个打分服务Docker 部署Prometheus 监控。4.2 特征工程与训练代码先看特征工程部分。训练和推理一定要共用同一套 feature pipeline避免“训练时用的特征和处理线上请求时用的特征不一致”这种问题。import pandas as pd from sklearn.model_selection import train_test_split from sklearn.preprocessing import LabelEncoder import lightgbm as lgb df pd.read_csv(telecom_customer_churn.csv) # 简单但有效的特征处理直接把类别型字段做标签编码缺失值填 -1 categorical_cols [gender, Partner, Dependents, PhoneService, MultipleLines, InternetService, OnlineSecurity, OnlineBackup, DeviceProtection, TechSupport, StreamingTV, StreamingMovies, Contract, PaperlessBilling, PaymentMethod] label_encoders {} for col in categorical_cols: le LabelEncoder() df[col] le.fit_transform(df[col].astype(str)) label_encoders[col] le # 把 TotalCharges 转成数值缺失值填 -1 表示未知 df[TotalCharges] pd.to_numeric(df[TotalCharges], errorscoerce) df[TotalCharges] df[TotalCharges].fillna(-1) feature_cols [tenure, MonthlyCharges, TotalCharges] categorical_cols X df[feature_cols] y df[Churn].map({No: 0, Yes: 1}).astype(int) X_train, X_valid, y_train, y_valid train_test_split( X, y, test_size0.2, random_state42, stratifyy )这里有几个关键选择用 LabelEncoder 而不是 OneHot是为了在树模型下避免维度爆炸。LightGBM 原生支持类别特征如果后续要精调可以直接传categorical_feature参数。缺失值填 -1对树模型来说等于告诉它“这一项缺失”构建分裂点时能自动处理。用 stratify 做切分是因为正样本占比不高不处理的话验证集里可能很难见到足够的流失样本。训练部分的代码如下params { objective: binary, metric: auc, learning_rate: 0.05, num_leaves: 31, max_depth: -1, feature_fraction: 0.8, bagging_fraction: 0.8, bagging_freq: 1, verbose: -1, seed: 42, } train_set lgb.Dataset(X_train, y_train) valid_set lgb.Dataset(X_valid, y_valid, referencetrain_set) model lgb.train( params, train_set, num_boost_round1000, valid_sets[valid_set], callbacks[lgb.early_stopping(100), lgb.log_evaluation(50)], )early_stopping 设 100 轮意思是如果验证集指标连续 100 轮都没有提升就提前终止训练。这么做最大的好处是防止过拟合同时省掉大量试错时间。实际跑下来这个项目一般会在 200 到 400 棵树之间收敛。4.3 模型评估关注 lift 和业务收益训练完不能只看 AUC要把预测概率和业务动作结合起来看。比如我们计划对“流失概率大于 0.7”的客户做定向优惠挽回那么这个阈值下模型能覆盖多少真流失客户精确率够不够这就需要算收益曲线。import numpy as np y_prob model.predict(X_valid, num_iterationmodel.best_iteration) for threshold in [0.5, 0.6, 0.7, 0.8, 0.9]: pred (y_prob threshold).astype(int) precision ((pred 1) (y_valid 1)).sum() / max((pred 1).sum(), 1) recall ((pred 1) (y_valid 1)).sum() / max((y_valid 1).sum(), 1) print(fthreshold{threshold}, precision{precision:.3f}, recall{recall:.3f}) feature_importance pd.Series( model.feature_importance(gain), indexfeature_cols, ).sort_values(ascendingFalse) print(feature_importance.head(10))通常在这个数据集上tenure在网时长、TotalCharges累计费用、MonthlyCharges月费、Contract合约类型会是重要特征。这个结果符合业务直觉老用户、长合约用户流失率低月费高但累计费用低的新用户风险最高。4.4 用 FastAPI 把模型变成服务模型训练好之后下一步是把它封装成可供业务方调用的 HTTP 服务。这里我用 FastAPI。import pickle import numpy as np from fastapi import FastAPI from pydantic import BaseModel import lightgbm as lgb app FastAPI(titleChurn Prediction Service) with open(model.pkl, rb) as f: model pickle.load(f) with open(label_encoders.pkl, rb) as f: label_encoders pickle.load(f) feature_cols [tenure, MonthlyCharges, TotalCharges, gender, Partner, Dependents, PhoneService, MultipleLines, InternetService, OnlineSecurity, OnlineBackup, DeviceProtection, TechSupport, StreamingTV, StreamingMovies, Contract, PaperlessBilling, PaymentMethod] class CustomerInfo(BaseModel): tenure: int MonthlyCharges: float TotalCharges: float gender: str Partner: str Dependents: str PhoneService: str MultipleLines: str InternetService: str OnlineSecurity: str OnlineBackup: str DeviceProtection: str TechSupport: str StreamingTV: str StreamingMovies: str Contract: str PaperlessBilling: str PaymentMethod: str app.post(/predict) def predict(customer: CustomerInfo): raw customer.dict() processed [] for col in feature_cols: val raw[col] if col in label_encoders: val label_encoders[col].transform([val])[0] processed.append(val) features np.array([processed], dtypefloat) prob model.predict(features)[0] return { churn_probability: round(float(prob), 4), risk_level: high if prob 0.7 else low }注意一个细节label_encoders必须是在训练时已经保存好的那个不能上线时重新 fit。如果线上来了一个训练时没见过的类别值这里的 transform 会抛异常所以更稳妥的方式是在 transform 之前做一次未知类别兜底判断。这个小地方我在生产环境里踩过不止一次。4.5 Docker 打包与部署本地能跑通服务只是第一步。为了在任何机器上保持一致行为要用 Docker 打包。FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY model.pkl label_encoders.pkl . COPY main.py . EXPOSE 8000 CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 8000]requirements.txt 大致需要这些依赖fastapi0.110.0 uvicorn0.29.0 lightgbm4.3.0 numpy1.26.4 scikit-learn1.4.1 pydantic2.6.1构建和启动命令docker build -t churn-service . docker run -d --name churn-api -p 8000:8000 churn-service构建镜像这里有个经验之谈不要用python:3.10完整版用slim版本就够了镜像体积能小一大截构建也快很多。如果涉及编译 LightGBM可能需要 apt 安装一些系统依赖但用预编译 wheel 通常能避开这个问题。4.6 上线后的监控面板服务起来了并不代表工作结束。我用 Prometheus 和 Grafana 搭一个最简监控。FastAPI 侧可以用 prometheus-client 暴露指标。from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST from starlette.responses import Response PREDICT_COUNT Counter(churn_predict_total, Total predict requests) PREDICT_LATENCY Histogram(churn_predict_duration_seconds, Predict latency) app.post(/predict) def predict(customer: CustomerInfo): PREDICT_COUNT.inc() with PREDICT_LATENCY.time(): # 原有的预测逻辑 ... return {...} app.get(/metrics) def metrics(): return Response(generate_latest(), media_typeCONTENT_TYPE_LATEST)在 Grafana 里可以配置三个最基础的告警请求成功率低于 99% 时告警。平均响应延迟超过 200ms 时告警。模型返回的 high risk 比例突然超过历史基线一倍时告警。最后一条很重要。它不直接等于系统故障但往往说明用户的群体结构变了或者上游数据出问题了。及时关注这个能帮你提前发现需要重训的时机。5. 避坑指南我踩过的坑和排查实录5.1 最常见的坑数据泄漏我在做这个项目的第一个版本时不小心把“是否已经解约”这个字段留在了特征里。结果离线 AUC 飙到 0.99我还高兴了一阵子。上线之后模型表现惨不忍睹排查了很久才发现是特征泄漏。提示做特征清单时逐一确认每个字段的生成时间是否早于预测时间点。最稳妥的办法是给每个特征打上“可用日期”标签预测时只允许使用标签日期之前的特征。5.2 时间序列乱划分很多初学者会用随机划分方式处理按时间产生的数据这是另一个高频问题。比如客户在 1 月签约、6 月流失训练集里可能既有 1 月签约的数据又有 6 月流失的数据。模型能在训练时“偷看”未来分布离线指标很好看。正确做法是按时序切分例如用 2023 年 1 月到 6 月的数据做训练集7 月做验证集8 月做测试集。我的经验是一切涉及“时间先后”的业务默认用时间切分而不是随机切分。5.3 训练推理特征不一致这是个很隐蔽的坑。训练时你写了一个特征函数extract_features(df)上线时你又在 API 里重新写了一段处理逻辑。两段代码只要有一行不一致模型的预测效果就会悄悄退化而且不容易发现。解决办法是把特征提取做成一个独立的模块训练和推理都 import 同一个函数。如果特征逻辑要修改必须同步更新并且保存模型时把特征版本号写进模型元信息里。5.4 服务内存泄漏有一次我把模型加载写在了 API 的热路径里每个请求都重新 load 一遍模型文件结果 QPS 一上去内存直接飙到 OOM。正确做法是模块级只加载一次进程启动时完成加载请求时只调用predict。排查内存问题的命令很简单docker stats churn-api --no-stream如果 RSS 持续增长而不回落大概率是持有大对象或缓存未清理。用tracemalloc或objgraph可以进一步定位。5.5 常见问题速查表现象可能原因排查方向离线 AUC 极高线上效果差特征泄漏检查特征生成时间和标签生成时间服务偶发超时模型加载在热路径里确认模型是否只加载一次预测概率普遍偏高或偏低上线时特征顺序不一致对比 pipeline 输出和训练时的特征顺序某天预测分布突变上游数据口径变化检查特征缺失率和取值分布新类别值导致服务报错编码器遇到未见过类别在 transform 前加兜底映射Docker 构建很慢镜像基础版本过大换 slim 版基础镜像6. 给零基础学习者的路线图建议6.1 阶段一第 1 个月Python 与数据处理目标能熟练用 Python 做数据清洗和探索性分析。实践任务找一个公开数据集比如 Kaggle 上的 Titanic 或 Heart Disease用 pandas 完成探索性数据分析和基础可视化。重点不是训练模型而是学会“看数据”缺失值分布、字段含义、类别取值、目标标签的均衡程度。这个阶段不建议碰深度学习。先把 pandas、matplotlib、seaborn 用到熟比什么都有用。6.2 阶段二第 2 到 3 个月机器学习基础与第一个模型目标理解分类和回归问题的完整建模流程。重点学这些内容数据预处理缺失值处理、缩放、编码。模型评估交叉验证、混淆矩阵、PR/AUC。树模型决策树、随机森林、XGBoost、LightGBM。然后做我上面那个客户流失项目的前半部分训练模型、调参、评估。不要追求 AUC 高先追求流程完整。流程完整的意思是你能够清楚地说出每一步在做什么以及为什么会得到当前这个结果。6.3 阶段三第 4 到 5 个月工程化与部署目标让模型能被别人调用而不是躺在 Notebook 里。学习内容FastAPI 基础路由、请求模型、响应模型。Docker 基础Dockerfile 怎么写、镜像怎么构建、容器怎么启动。模型序列化pickle 和 joblib 的区别模型文件如何管理。MLflow记录参数、指标、模型产物。这个阶段最容易产生成就感因为模型真正“跑起来”了。但也是坑最多的时候建议把我上面列出的避坑清单里的问题逐个亲手复现一遍踩过一遍之后记忆会很深刻。6.4 阶段四第 6 个月完整项目收尾目标做出一个能写进简历的端到端项目。建议完成下面这条链路特征管道模块化训练和推理共用同一套代码。加入监控记录请求数、延迟、预测分布。加入告警Prometheus 加 Grafana 配置最小告警。模拟 AB 测试把新旧模型的结果做对比。如果你能走完这一步你就已经具备初级 AI 工程岗位的实操能力了。6.5 学习资源推荐课程方面我推荐 Andrew Ng 的 Machine Learning 打底然后直接刷 Fast.ai。这两个课程能帮你建立从原理到实践的跨度。书籍的话《Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow》是综合最好的《Designing Machine Learning Systems》适合在动手做项目之后阅读它能把工程思维掰开揉碎讲清楚。开源项目方面多去 GitHub 搜 “mlops” 和 “ml-system-design” 相关的仓库。建议不要只看 README而是把代码 clone 下来跑一遍再改写其中的一部分。我在学习阶段收益最大的一件事就是把一个推荐系统开源项目的部署链路拆开重写了一遍那比看十篇教程都有用。最后说一点个人体会。AI 工程这条路最大的门槛从来不是某个数学公式或者某个框架而是“耐心”。完整做完一个项目把每一个环节都端到端打通比同时开十个半途而废的教程有效得多。我见过不少比我聪明的人在学习时因为急于求成而错过了工程细节最后反而在面试和实际工作中被这些细节绊住。如果你正在从零开始我的建议很简单选定一个项目不要中途换方向把它从数据一路做到监控告警全部跑通。这个过程里踩的每一个坑都会变成你之后最宝贵的经验。