1. 为什么会调模型不等于会做AI工程AI engineering from scratch这个话题在我电脑里躺了好几个版本。每次想动笔写都感觉还没到火候直到最近帮一个创业团队收拾了一套跑不起来的推荐系统才觉得有资格聊聊真实的从零起步路径。先说一个可能有点反常识的结论AI工程这个能力在刚开始的阶段和懂算法的关系并不大。我见过很多能写出一手漂亮PyTorch代码、在Kaggle上拿牌子的朋友到了真正要做一个产品级AI项目时仍然会手忙脚乱。反过来一些算法基础并不算顶尖的工程师却能把系统做得非常稳。为什么因为AI工程的核心是让模型在真实环境里持续稳定运行而不是做出一个最高精度的模型。1.1 一次上线事故让我重新定义了AI工程三年前我做过一个情感分析服务模型用BERT微调离线测试集的AUC到0.92当时的我信心满满想着这么高的指标上线还不是分分钟的事。结果上线第一天线上请求的错误率就冲到8%第二天数据监控提示预测分布和训练集差异巨大。排查了半天发现两个问题一是线上过来的文本很多是语音转文字的结果里面带着各种嗯嗯啊啊和错别字训练数据里几乎没见过这种噪声二是后端工程师在调用时没有走我写的预处理函数自己用正则简单清洗了一下导致特征空间对不上。那次事故让我意识到模型在离线环境里评估的准确率只是整个AI系统的一个小环节。从数据采集、清洗、特征计算到模型训练、评估、打包再到上线部署、服务编排、监控告警、回滚机制这是一条完整的链路。任何一个环节掉链子模型本身再强也白搭。AI engineering本质上是把这条链路的每一个环节都做成可重复、可观测、可控制的过程。后来我又陆续参与过几个从零搭建的AI项目包括用户流失预测、智能客服意图识别、图像质检慢慢摸清了这里面的规律。所谓from scratch不仅仅是从空项目开始写代码更是从完全没有AI基础设施的现状里把数据、模型、服务、监控一步步搭起来。1.2 AI工程与算法研究的三大核心差异要理解AI工程最好先把它和算法研究放在一起对比。我总结了三个最关键的差异对比维度算法研究AI工程核心目标探索模型能力上限追求SOTA保证系统稳定可用追求业务收益评价指标离线指标AUC、F1、BLEU等在线业务指标延迟、可用性、转化率交付物实验代码、论文、模型权重可部署的服务、监控体系、维护文档、迭代流程这三点差异直接决定了做事方式。比如算法研究里数据集的分布是固定的你只需要在同样的测试集上比较模型但AI工程里数据分布是流动的用户行为在变传感器在变市场环境也在变模型上线那一刻起就需要被持续监控。又比如在算法研究里实验代码只要能复现结果就行但在工程里代码是要被其他人维护、被其他服务调用的必须考虑异常处理、并发访问、版本兼容这些不浪漫的事情。我记得有个非常形象的类比算法研究员像是米其林大厨追求做出一道完美的菜AI工程师更像是开连锁餐厅的人要考虑食材供应链、后厨流程、上菜速度、顾客口味变化还要保证每家分店出品一致。你可能觉得连锁餐厅的菜不如米其林惊艳但它能稳定地为成千上万人提供可预期的服务这就是工程的价值。2. 从零开始先搭好学习路径的骨架既然AI工程是个系统工程那学习路径就不能只盯着模型架构。很多新手问我是不是要先把手推反向传播搞定再开始我的回答通常是不用。AI工程的学习路径应该以跑通一个项目为核心缺什么补什么而不是按计算机课程的顺序从头学到尾。2.1 我把AI工程拆成五个能力域为了不让自己迷失在庞大的知识体系里我把AI工程拆成了五个能力域每个域对应一条独立的学习主线数据工程数据采集、清洗、特征加工、数据质量校验、数据版本管理。建模训练模型选型、超参数调优、分布式训练、模型评估与可解释性。部署推理模型格式转换、容器化、API服务化、GPU/CPU资源管理。监控运维模型性能监控、数据漂移检测、日志告警、灰度发布与回滚。平台流程实验管理、CI/CD流水线、多环境管理、团队协作规范。这五个域并不是并列的五个职业方向而是每个AI工程师都该有基础认知的五个面。你可以有侧重但不能完全空白。我自己见过太多建模很强但不会部署的案例也见过懂部署但完全不管数据质量的案例最终都会在漫长的项目生命周期里出问题。对于刚起步的人我不建议一上来就学Kubernetes或者深度模型优化。你应该先在一个最小的项目里把这五个域全部走一遍哪怕每个域只用最简单的工具。比如数据工程用Pandas做清洗建模训练用Scikit-learn或者XGBoost部署推理用FastAPI加Docker监控运维用定时脚本加日志平台流程用Git和手动记录。先把流程走通你才会知道每个环节需要什么样的工具也才理解为什么那些工业级组件要那么设计。2.2 学习顺序和资源选择的个人建议如果一定要给一个学习顺序我会这样排先学会Python编程基础能写脚本处理数据不一定要精通面向对象。学一点SQL和Pandas能对表格数据做取数和清洗。了解基本的机器学习概念能跑通一个简单的分类或回归模型。立刻开始做一个端到端小项目把数据-模型-接口-部署串起来。在项目过程中遇到具体问题再去查对应领域的文档和资料。为什么这样排因为从零开始的人最容易被无限的前置知识淹没。比如你想学AI工程会看到有人告诉你先学微积分再学线性代数然后学机器学习理论然后学深度学习再看TensorFlow文档……这么一套下来一年过去了你还不知道自己能不能把它跑起来。我的态度是基础数学很重要但你完全可以边做边补。你需要微积分的地方就是理解梯度下降你需要线性代数的地方就是理解张量运算。当你在项目里真实遇到了这些概念学习效率会远高于脱离场景死啃书本。资源方面我的个人选择是官方文档永远优先于二手的教程博客。比如你用FastAPI直接看FastAPI官方文档里面每个例子都写得清清楚楚你用Docker就看Docker官方文档的入门部分。中文社区可以看一些优秀的博客和经验分享但遇到问题时最好还是回到官方文档去核对版本和API因为很多二手教程已经过时了照着抄反而会踩坑。3. 亲手做一个端到端的AI工程小项目我在带新人时最喜欢布置的任务是做一个用户购买预测服务。不是因为它有多大价值而是它麻雀虽小五脏俱全有历史数据可以训练、有明确的业务目标、可以很方便地对接Web接口、还能在真实环境里验证监控效果。下面我完整走一遍这个项目你就知道AI工程从头到尾要做哪些事。3.1 选题一个能跑完闭环的入门项目为什么推荐用户购买预测因为这类任务的数据很容易获取比如公开的电商数据集、UCI仓库里的营销数据集不需要写爬虫去采集也不涉及敏感隐私。我们的目标很简单给定用户的历史行为、商品信息和基础属性预测用户是否会在接下来7天内购买某商品。这是一个二分类问题。但既然是AI工程我们的目光不能只盯着准确率。我们要实现的是一个能响应HTTP请求的推理服务它有独立的特征处理逻辑有模型文件有日志有基本的指标统计。这样哪怕是一个很小的项目也能完整覆盖前面说的五个能力域。具体步骤上我一般会建议用Python做数据清洗把缺失值、重复项处理掉。用Pandas和Scikit-learn做特征工程把类别特征转成one-hot或label encoding数值特征做归一化。训练一个XGBoost或者LightGBM模型这两个库在结构化数据上效果很好而且工程部署非常方便。用FastAPI写一个post接口接收Json输入返回预测概率。用Docker把服务打包起来在本地跑通后用Docker Compose管理。3.2 数据管线的第一版能跑就行很多人一上来就想用Spark、Airflow这种大数据工具觉得那样才叫工程化。实际上在小项目里这些只会增加负担。我的建议永远是先用最简单的脚本把流程跑通再逐步工程化。比如第一版数据管线就是一个Python脚本import pandas as pd from sklearn.model_selection import train_test_split # 读取原始数据 df pd.read_csv(raw_purchase_data.csv) print(df.info()) # 简单清洗 df df.drop_duplicates() df[purchase_flag] df[purchase_flag].fillna(0) df df.dropna(subset[user_age, product_price]) # 划分训练集和测试集注意按时间划分而不是随机划分 X df.drop(purchase_flag, axis1) y df[purchase_flag] X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, random_state42 )这里有一个很重要的工程细节当你的数据带时间属性时划分训练集和测试集尽量按时间切而不是随机切。因为有购买行为的数据天然存在时间先后关系随机切会导致模型偷看未来信息虽然离线指标好看但在真实的未来数据上会大打折扣。这是一个我在实际项目中深刻体会过的教训。第一版的数据管线不需要把每条数据都验证一遍也不需要处理所有的边界情况。你的目标是把数据从源头导入到模型训练这一步打通。先把流程跑通再逐步增加数据质量校验和异常处理。3.3 训练、评估与实验记录数据准备完之后训练本身其实是最枯燥的部分。我一般会用Scikit-learn的Pipeline把特征处理和模型训练封装起来这样能确保训练和推理时使用完全一致的特征变换逻辑from sklearn.pipeline import Pipeline from sklearn.preprocessing import StandardScaler, OneHotEncoder from sklearn.compose import ColumnTransformer from xgboost import XGBClassifier numeric_features [user_age, user_income, product_price] categorical_features [user_city, product_category, channel] numeric_preprocessor StandardScaler() categorical_preprocessor OneHotEncoder(handle_unknownignore) preprocessor ColumnTransformer([ (num, numeric_preprocessor, numeric_features), (cat, categorical_preprocessor, categorical_features), ]) model Pipeline([ (preprocess, preprocessor), (classifier, XGBClassifier(n_estimators200, max_depth4, learning_rate0.1)), ]) model.fit(X_train, y_train)很多人习惯把特征处理写成独立的函数然后训练和推理各写各的这样很容易出现不一致。用Pipeline就是把特征处理和模型绑定在一起推理的时候直接调用同一个pipeline对象就不会出现训练时做了归一化推理时忘了做这种低级但致命的错误。训练完之后除了看AUC和F1我还强烈建议记录模型的训练参数、数据版本和训练时间。哪怕你只用Excel记录也行关键是养成实验可回溯的习惯。我后来用了MLflow来管理实验它能自动记录每个run的指标、参数、代码环境和模型文件团队的协作效率会高很多。3.4 模型服务化用FastAPI加Docker上线训练好模型后下一步是把它变成一个可调用的服务。在这里我选FastAPI因为它的性能好写起来也简单自带API文档非常适合做模型推理服务。一个最基本的服务长这样from fastapi import FastAPI from pydantic import BaseModel import joblib app FastAPI() model joblib.load(purchase_model.joblib) class FeaturePayload(BaseModel): user_age: float user_income: float product_price: float user_city: str product_category: str channel: str app.post(/predict) def predict(payload: FeaturePayload): import pandas as pd input_df pd.DataFrame([payload.dict()]) probability model.predict_proba(input_df)[0][1] return {probability: round(float(probability), 4)}这里有几个问题要说明第一模型文件我用joblib保存因为XGBoost和Scikit-learn模型用joblib序列化最稳第二每次请求都创建一个DataFrame虽然对单次请求没有性能问题但如果并发很高最好把特征处理逻辑提取成独立模块并提前初始化好特征处理器第三接口最好返回概率而不是0/1标签这样下游业务可以根据不同阈值调整判断避免每次业务想改敏感度都要重新训练模型。Dockerfile也很简单FROM python:3.9-slim RUN pip install fastapi uvicorn joblib xgboost pandas scikit-learn WORKDIR /app COPY . /app CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 8000]然后docker build -t purchase-predictor .和docker run -p 8000:8000 purchase-predictor就可以在本地跑起来了。用Docker部署的原因是为了让运行环境和开发环境保持一致避免在我机器上能跑这种经典问题。等到要上生产环境你还需要加一层进程管理、健康检查、请求超时和限流但第一版能通过Docker跑起来就已经跨过了工程化最基础的一道坎。4. 项目上线后我踩过的坑讲完核心流程我要花大篇幅讲讲真正的踩坑过程。这些坑在教科书和官方文档里都不会出现但每个做过AI工程的人几乎都会遇到。我把最有代表性的三个记录在这里希望大家能少走弯路。4.1 数据漂移问题训练时根本没有意识到分布会变我在前面提到情感分析那个项目上线后效果就崩了。当时我们做了离线测试模型非常好但上线一周后业务方反馈负面情感识别率越来越低。我最初怀疑是模型过拟合但检查特征分布时发现训练数据的平均文本长度是120个字符线上数据平均长度只有45个字符训练数据里表情符号几乎没出现过线上数据里却频繁出现。这就是典型的数据漂移。数据漂移一般分两种特征漂移和概念漂移。特征漂移是输入分布变了比如用户群体变了、产品线变了概念漂移是输入和输出的关系变了比如疫情期间不买的含义变了。检测方法也不复杂你可以定期对线上特征做统计比如均值、分位数、类别分布和训练集做对比用KL散度或PSI群体稳定性指数做量化。如果差异超过阈值就要触发告警或者重新训练。后来我把特征监控加到了服务里每天自动跑一个对比脚本输出一份特征分布偏移报告。这不是很复杂的事但能让团队很早就发现问题。真正要避免的心态是模型上线就万事大吉——那只是AI工程中途的一站。4.2 训练与推理特征不一致的问题第二个坑是特征不一致。这个问题非常隐蔽通常出现在训练是用Python脚本离线算特征线上推理却用Java或Go服务实时算特征两边对同一字段的处理方式不同。比如训练时日期字段换算成星期几而线上代码写成了直接取天数或者训练时缺失值填充0线上填充-1。模型看到的不再是训练时分布效果自然差。最好的解决办法是把特征处理逻辑做成一个独立的包训练和推理共用同一份代码。在Python生态里就是把特征工程函数放到一个可导入的模块比如feature_lib.py在训练脚本和FastAPI服务里都调用它。如果你确实需要跨语言部署那么就要制定统一的特征定义文档并且在上线前用一批真实线上数据跑出来对比训练特征逐字段验证。我还踩过另一个坑上线新模型时新模型依赖的特征和旧模型不完全一样但服务端没有把特征版本和模型版本绑定。导致模型A跑着跑着等模型B上线时请求仍然携带旧版本的特征特征缺失后代码用默认值替代模型B的预测完全是乱的。从那以后我强制要求服务的请求体里带上feature_version模型上线时同时校验模型版本与特征版本是否配对。4.3 资源管理与成本意识隐藏的技术债第三个坑在大模型时代尤其明显。很多人训练完模型后GPU显存里调参、验证流程很顺利但部署到生产时资源分配不合理导致成本飙升。我见过一个图像识别服务代码写得没问题但每次请求都会重新加载一遍模型到GPU导致显存占用高、请求延迟也高。正确的做法是模型预先加载到内存常驻服务进程只用推理时做前向计算。资源管理不光是显存还包括CPU、内存、磁盘I/O和网络带宽。你要为模型推理服务设置合理的并发上限用队列削峰而不是无限接收请求。Kubernetes里要设置requests和limitsHPA要配置好扩缩容策略。这些内容看起来很运维但它们是AI工程的组成部分。如果只把模型往服务器上一丢就完事大量这类技术债会在某个深夜集中爆炸。我个人建议小团队在起步阶段至少要监控三个指标GPU使用率、请求p99延迟、错误率。用Prometheus加Grafana搭建一套基础监控比用什么高深的分布式追踪都更直接。代码里不记日志的时候出了问题你都无从下手我通常会在推理入口和出口都留结构化日志至少包含请求ID、响应码、耗时和模型版本。5. 新手的极简工具箱和自检清单最后我想分享一套我实际用下来最顺手的工具组合以及一份自检清单。这些工具都不是什么新奇玩意但它们能覆盖绝大多数中小型AI工程项目的需求。5.1 我实际用下来最顺手的组合环节我的选择为什么选它开发语言Python生态最全模型和数据处理库基本都用它数据处理Pandas NumPy单机处理几百万行数据足够入门成本低特征与建模Scikit-learn XGBoost结构化数据利器训练快部署简单深度学习框架PyTorch生态活跃调试友好适合复杂模型模型服务FastAPI Uvicorn异步支持好自带API文档性能不错容器化Docker Docker Compose保证环境一致本地模拟多服务实验管理MLflow自动追踪实验指标和模型版本数据库PostgreSQL Redis业务数据用PostgreSQL缓存和高频查询用Redis监控告警Prometheus Grafana开箱即用社区资料多任务调度APScheduler / Cron 脚本小项目不需要上Airflow定时任务够了这套组合对于从零开始做AI工程的个人开发者或小团队来说足够用了。其中MLflow和监控系统可以晚一点再上但Docker和FastAPI要尽早掌握因为它们直接决定了你能否交付一个别人能跑起来的项目。5.2 从入门到独立的10条自检清单每次我觉得项目做完了都会对着这个清单检查一遍发现自己还是经常会漏掉某项数据管线是否可重复执行换一台机器跑能不能得到同样结果训练集和测试集是否按时间切分有没有数据泄露特征处理代码在训练和推理中是否完全一致是共用模块吗模型文件是否带版本号是否有对应的训练参数记录推理服务的依赖是否固化用requirements.txt或Docker image锁定版本了吗接口是否定义了输入输出的Schema对于异常输入能否正确返回400服务有没有健康检查接口能被Docker/K8s探活吗是否记录了推理日志能否通过请求ID追踪单次预测是否监控了特征分布和预测分布数据漂移时能不能及时发现模型更新后能不能灰度发布出现问题时能否快速回滚到上一版本前四条是整个项目的地基中间四条是服务上线的基本要求最后两条决定了系统能否长期健康迭代。如果你能从零开始把这些全部做到那你基本就具备了一名AI工程师的核心能力而不仅仅是会用模型库。最后再分享一点个人体会从零开始学AI工程最大的陷阱其实是总觉得还要再准备一下。你不需要等Linux精通了再学Docker也不需要用透Kubernetes了再上线第一个服务。挑一个足够小的业务场景哪怕是做一个房价预测接口从头到尾走一遍你收获的会远超于读十篇教程。我自己就是在第一次项目翻车之后才真正开始理解AI工程这两个词的分量。希望你不要等踩到那些坑才明白。