搞AI工程快五年了从最开始拿Jupyter Notebook瞎折腾到后来真正把模型送上生产环境扛住线上流量这中间踩过的坑比我踩过的雷还多。今天不聊那些高大上的架构图就聊聊一个普通人从零开始搞ai-engineering到底要经历什么、学什么、避开什么。这篇文章适合刚入门AI工程、想转行做AI落地、或者已经在做算法但被工程化折磨到怀疑人生的朋友读完之后你能对整条链路有个清晰的认知也能直接照着里面的方案去搭建自己的第一个完整项目。1. AI工程到底是什么先搞清楚边界再动手很多人一听到AI工程第一反应就是“训练模型”。这个认知害了太多人。我见过不少算法岗的同学模型在离线测试集上刷到98%的准确率一上生产环境就崩得亲妈都不认识。为什么因为AI工程从头到尾就不只是训练模型这一件事它是一个完整的产品化过程。1.1 AI工程不是写模型是让模型活下来一句话说清楚AI工程是研究如何把“能跑的模型”变成“一直能跑的模型”。这里有个核心区别——算法研究追求的是模型性能上限AI工程追求的是系统的稳定下限。你在论文里看到的那些SOTA模型放到真实业务里可能连一天都撑不住。举颗具体的例子。我之前接过一个智能客服项目模型在测试集上准确率87%看着还行。结果上了生产之后线上用户的话术跟测试集完全是两个世界——有错别字的、中英混打的、方言口音的、表情包的分分钟把模型干懵。这时候你才发现真正的工程难点根本不在模型结构而在数据流怎么设计、版本怎么管理、模型怎么回滚、线上指标怎么监控。所以我说ai-engineering-from-scratch这个标题本身就很诚实——“从零开始”意味着你要把整个链路都走一遍不是只盯着模型那一亩三分地。1.2 一条完整的AI工程链路长什么样从零开始做AI工程你至少要打通下面这几段需求定义搞清楚业务到底要解决什么问题边界在哪儿成功的标准是什么数据工程采集、清洗、标注、存储、版本管理这是整个链路的地基模型开发基线模型、训练、调参、评估、迭代这部分反而是大部分人都熟悉的部署上线模型导出、推理优化、API封装、容器化、灰度发布监控运营线上指标监控、数据漂移检测、模型定期重训、告警机制这五段链路缺一环都玩不转。你看网上那些讲AI工程的课程大多只讲中间的模型开发但真实项目里数据工程和监控运营加起来要占掉60%以上的工作量。这是新手最容易误判的地方——以为AI工程的重心在“模型”实际在“工程”。我记得有个前辈说过一句话特别认同AI工程的核心矛盾是模型的不确定性和工程的确定性之间的矛盾。你要用一堆概率性的组件搭出一个确定性的系统这事儿本身就很难。2. 技术栈选型怎么挑一套能打满全场的装备很多人一上来就纠结框架今天PyTorch还是TensorFlow明天用不用Kubernetes。我的建议是别急着追新先把一套基础组合打到滚瓜烂熟再谈扩展。2.1 语言和框架Python是绝对主力框架优先PyTorch语言这块没什么好争的Python就是AI工程的第一语言。生态太全了从数据处理到模型训练到服务部署一个语言全包了。你当然可以用Go、Java去写服务但AI链路的原型开发、数据处理、模型训练Python依然是效率最高的选择。框架就选PyTorch。别问我为什么不是TensorFlow你去看现在各大厂的开源模型Hugging Face上的模型十个里面有九个是PyTorch写的。生态即正义你自己踩坑的时候搜到的大概率也是PyTorch的解决方案。TensorFlow不是不好但它在动态图时代的便利性确实差了一些。我自己的习惯是模型训练用PyTorch如果后续要上生产环境做高性能推理再考虑用ONNX Runtime或者TensorRT做加速这个后面会细说。2.2 环境管理从入门就养成好习惯这个我必须多说两句。很多新手一开始就在全局环境里pip install装了删、删了装最后环境烂成一锅粥依赖冲突能让人崩溃一整晚。我踩过这个坑所以真心建议你从一开始就养成隔离环境的习惯。我自己常用的组合是uv管理Python版本和虚拟环境比传统的virtualenv快很多用起来也顺手conda如果涉及一些非Python的依赖比如CUDA相关的库conda有时候更省心Docker项目级别的环境隔离这个很重要后面部署的时候也靠它具体的操作示范一下。我建新项目的时候习惯用一套固定的命令模板# 创建项目目录初始化虚拟环境 mkdir ai-engineering-demo cd ai-engineering-demo uv init uv add torch transformers datasets fastapi uvicorn一条命令把基础依赖全装好环境清爽不会污染全局。你可能会觉得多这一步很麻烦但等你同时做两三个项目的时候就会明白环境隔离能帮你省多少事。2.3 工具链搭配少即是多稳定压倒一切我刚入行的时候特别喜欢折腾各种新工具Airflow、MLflow、Kubeflow、Ray看到什么都想试一把。结果呢很多工具只用了两次就再也没碰过纯粹是给自己增加维护成本。后来我悟出个道理工具的引入必须是为了解决当下的痛点而不是为了“显得专业”。我现在的标配其实相当朴素环节工具用途代码管理Git GitHub/GitLab版本管理代码协作实验追踪MLflow 或者 WB记录参数、指标、模型产物数据版本管理DVC管理数据集版本和代码联动任务编排简单场景用Shell脚本复杂了再上Airflow定时训练、数据流水线部署Docker FastAPI模型服务化你看核心就这几个但能把整条链路串起来。我用MLflow主要图它一个功能——每次训练完把参数、指标、模型文件全部自动记录下来这样哪怕三个月后回来看也能清清楚楚知道当时的实验到底做了什么。这个在项目早期可能显得“没必要”但项目一复杂起来它就是救命稻草。3. 数据工程的完整落地数据才是AI工程的命根子说句得罪人的话大部分人模型跑不好问题根本不出在模型上出在数据上。数据不干净、分布不一致、标注有噪声你再怎么调参都是白费力气。所以从零开始做AI工程我建议你先把数据工程这块吃透。3.1 数据采集先搞清楚你有多少“料”我接手过的项目里至少有一半业务方一开始吹得天花乱坠“我们数据量很大”结果真去看的时候——有效数据只有几百条剩下的全是垃圾。所以数据采集第一步不是写爬虫而是做数据盘点。你需要回答这几个问题我解决这个问题需要什么类型的数据样本是什么标签是什么数据来源有哪些数据库、日志、第三方接口、还是需要人工采集数据量够不够按经验深度学习模型起步怎么也得几千条样本复杂任务得上万数据质量如何缺失率、错误率、噪声多不多如果数据不够就得考虑补充采集。我自己常用的方案是写定时脚本从数据库和日志里抽取样本配合一些爬虫手段采集公开数据注意合规问题以及实在不行就人工造数据这在初期是行之有效的。给你看一个我常用的数据采集脚本模板import pandas as pd from sqlalchemy import create_engine # 连接业务数据库抽取原始数据 engine create_engine(postgresql://user:passwordlocalhost:5432/mydb) df pd.read_sql( SELECT id, content, created_at, label FROM samples WHERE created_at 2024-01-01 LIMIT 10000 , engine) # 简单的数据概览 print(f样本总数: {len(df)}) print(f标签分布:\n{df[label].value_counts()}) df.to_csv(raw_data.csv, indexFalse)这段代码看起来简单但已经能解决很多项目初期的数据采集需求了。3.2 数据清洗与标注模型上限的决定因素数据清洗这件事做得好的跟做得差的最后的模型效果能差出一个数量级。我的经验是清洗要做到“三个一致”格式一致、单位一致、语义一致。举个例子。做个商品评论情感分析原始数据里各种情况都有大小写混杂“这个手机屏幕很好”和“这个手机屏幕GOOD”要统一格式全半角混杂“价格2999”和“价格:2999”冒号全角半角要归一表情符号“很好”和“很好”可能都要保留或者都去掉要定一个原则清洗的规则得根据你的任务和目标数据来定没有万能的模板。但有几个通用步骤是跑不掉的import re import unicodedata def clean_text(text: str) - str: # 1. 标准化Unicode处理全角半角 text unicodedata.normalize(NFKC, text) # 2. 统一去除多余空白 text re.sub(r\s, , text).strip() # 3. 去除特殊符号按需保留或清洗 text re.sub(r[^\w\s\u4e00-\u9fa5], , text) # 4. 统一小写英文场景 text text.lower() return text至于标注我先说一个心得不要一上来就花大价钱请外包标注先用小规模人工标注主动学习跑起来。我刚做AI工程那会儿什么都追求“高质量标注”结果花了几万块标了两万条数据模型效果还是不行。后来才明白关键是要在模型迭代中不断发现“难样本”再有针对性地补充标注。这个思路叫active learning实战中效率比一次性大批量标注高得多。3.3 数据版本管理别让实验记录成谜这个点百分之八十的新手会忽略。你训练模型用了一版数据后来数据更新了、修了几个标注错误你的模型却还是基于老数据训练的——结果就是模型效果分析变得一塌糊涂根本说不清楚提升到底是来自模型改动还是数据改动。DVC就是干这个的。它的设计思路跟Git非常像但管的是数据文件而不是代码。基本用法极其简单# 初始化DVC dvc init # 把数据文件夹纳入版本管理 dvc add data/raw dvc add data/processed # 提交元数据 git add . git commit -m add v1.0 dataset这样数据文件本身不会进Git仓库太大但数据版本的元数据会跟着代码走。训练的时候想把代码回退到某个历史版本对应的数据也能一起恢复实验可复现性一下就上来了。我自己的体会是养成“每跑一次实验数据和代码版本都打上tag”的习惯三个月后你会感谢当初的自己。4. 模型开发与训练从跑通到跑好数据准备得差不多了才轮到模型开发这part。我的建议是先别想那些花里胡哨的模型结构老老实实从基线模型开始跑通一条最小的链路再往上面加复杂度。4.1 基线模型怎么搭先别追求性能追求“能跑”我见过太多人包括当年的我一开始就上手EfficientNet、BERT、GPT这些大家伙结果代码写了一星期环境跑不通直接劝退。做AI工程跟做研究不一样第一步永远是“打通链路”。以文本分类为例一个最小可行的基线是这样from transformers import AutoTokenizer, AutoModelForSequenceClassification, Trainer, TrainingArguments import numpy as np # 1. 加载预训练模型和分词器 model_name bert-base-chinese tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForSequenceClassification.from_pretrained(model_name, num_labels2) # 2. 数据集处理 def tokenize_function(examples): return tokenizer(examples[text], paddingmax_length, truncationTrue, max_length128) from datasets import Dataset train_ds Dataset.from_pandas(train_df).map(tokenize_function, batchedTrue) # 3. 训练参数配置 training_args TrainingArguments( output_dir./results, num_train_epochs3, per_device_train_batch_size16, evaluation_strategyepoch, save_strategyepoch, logging_dir./logs, ) # 4. 评估指标 def compute_metrics(eval_pred): logits, labels eval_pred preds np.argmax(logits, axis-1) return {accuracy: (preds labels).mean()} # 5. 训练 trainer Trainer( modelmodel, argstraining_args, train_datasettrain_ds, eval_datasetvalid_ds, compute_metricscompute_metrics, ) trainer.train()这套代码写下来不超过30行但它帮你把整条训练链路跑通了——数据加载、分词、训练、评估、模型保存。在这一步跑通之前谈任何优化都是空中楼阁。4.2 训练过程中的关键参数搞懂再调别瞎试很多新手调参就是grid search乱试一通运气好碰上个好的运气不好就通宵。我分享一下自己训练时的思路核心就一句话每次只改一个变量并且明确记录为什么改。几个关键参数我的默认值和处理方式batch size能用16的就不刻意调大。显存不够就先减半除非你的梯度更新确实需要更大的batch再去动它学习率预训练模型微调一般用2e-5到5e-5从头训练的模型可以放宽到1e-4到1e-3。我的经验是先把学习率调到模型正常收敛再去管别的epoch数看验证集表现决定不用死磕“必须训练多少轮”。早停early stopping是我每次必开的它能帮你省掉后面自己睡不着的那些夜晚warmup steps大模型微调建议开warmup一般设总步数的5%到10%。作用是避免训练初期学习率过大导致loss爆炸对了还有一个容易被忽略的细节随机种子一定要固定。不固定种子的话同一份代码跑两遍指标可能差1到2个点你根本判断不了是代码的改动带来的提升还是运气好碰到的。4.3 评估与迭代别只看准确率要拆开看模型训练完很多人看一眼验证集准确率就收工了。准确率高就一定好吗不一定。我在一个反欺诈项目里正负样本比例失衡正样本只有3%模型只要预测全为负类准确率就是97%。但你想想这个模型上线有毛用它一个欺诈样本都抓不到。所以评估阶段我建议至少从这几个维度看混淆矩阵搞清楚模型到底在哪些样本上犯错犯的是哪类错精确率/召回率/F1尤其是不平衡场景这三个指标比准确率有意义得多分维度评估按标签、文本长度、来源渠道等维度拆开看确认模型在哪个子集上特别差模型评估完了发现短板再针对性地去补数据或者调模型这才是迭代的正确姿势。我记得有一个文本分类项目模型整体F1到了0.91看着不错。结果一拆分发现长度超过500字的样本F1只有0.6再深入一查这类样本在训练集里就特别少。后来针对性补了一批长文本数据F1直接拉到0.86。这种收益比你在模型结构上调十次来得都实在。5. 部署上线与服务化让模型真正产生价值训练再好的模型如果没办法上线服务用户在AI工程的语境下就是白做。部署这块是新手最容易翻车的地方——什么“训练好好的部署就崩了”十有八九是训练和推理的环境不一致、输入输出没对齐导致的。5.1 模型导出与推理优化先保证一致性再谈性能训练和部署环境不一致是最大的坑。你在训练时用PyTorch显卡是A100部署时对方机器用的是CPU那结果不一致几乎是必然的。怎么解决我习惯在导出模型之后先用一批真实样本做一致性校验确保导出的模型和在线训练模型输出一致误差控制在可接受范围。推理优化我按优先级来压缩输入长度能截断就截断文本分类很多场景128个token足够了没必要跑512个。推理速度和输入长度大致成正比批量推理一个请求一个请求地推理GPU利用率极低。把请求攒一批再一起推理吞吐量能翻好几倍模型量化用ONNX Runtime或者TensorRT做FP16、INT8量化推理速度能有2到5倍的提升蒸馏/剪枝这是大动作一般到后期追求极致性能再考虑我给你们看一个实际案例之前有个BERT文本分类服务刚部署的时候平均延迟450msQPS大概只有20。我用ONNX Runtime跑FP16量化再把输入长度从512压到128延迟降到了80msQPS直接拉到120。全程大概花了半天时间收益非常可观。5.2 API服务怎么设计接口要“薄”逻辑要“厚”模型服务化的接口设计有一个重要原则不要在接口层暴露模型的原始输入输出格式要做输入校验和输出格式化。你训练模型的时候输入是一段清洗后的纯文本但线上用户可不会按你的规矩来。我用FastAPI写模型服务的习惯做法是先写一个预处理函数把所有脏数据清理干净再喂给模型from fastapi import FastAPI, HTTPException from pydantic import BaseModel import torch app FastAPI() class InferenceRequest(BaseModel): text: str max_length: int 128 class InferenceResponse(BaseModel): label: str confidence: float class ModelService: def __init__(self): self.model self._load_model() self.tokenizer self._load_tokenizer() def predict(self, text: str, max_length: int): clean clean_text(text) # 复用前面写的清洗函数 encoded self.tokenizer(clean, truncationTrue, max_lengthmax_length, return_tensorspt) with torch.no_grad(): outputs self.model(**encoded) probs torch.softmax(outputs.logits, dim-1) label_idx torch.argmax(probs).item() confidence probs[0][label_idx].item() return label_idx, confidence service ModelService() app.post(/predict, response_modelInferenceResponse) def predict(req: InferenceRequest): if not req.text.strip(): raise HTTPException(status_code400, detailempty text) label_idx, confidence service.predict(req.text, req.max_length) return InferenceResponse(labelstr(label_idx), confidenceconfidence)这样接口不仅好维护还能顺便挡住空请求、非法请求避免模型被喂脏数据导致输出垃圾结果。5.3 容器化与部署Docker是底线别偷懒说实话现在部署模型服务如果不用Docker就真的是在给自己找事。Docker把环境、依赖、代码全部打包在一起到哪儿都能跑彻底解决了“在我电脑上是好的”这个世纪难题。一个简单的Dockerfile长这样FROM python:3.10-slim WORKDIR /app # 先拷贝依赖文件利用层缓存加速构建 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 再拷贝代码 COPY . . # 启动服务 CMD [uvicorn, app:main:app, --host, 0.0.0.0, --port, 8000]构建和运行的命令也顺便贴上docker build -t ai-service:latest . docker run -p 8000:8000 ai-service:latest我见过不下三位数的部署事故最终都指向同一个问题——环境不一致。你要是在这一步认真把Docker用起来就真的能少踩很多坑。6. 上线后的监控与运营AI工程的最后一公里很多人觉得模型上线就算大功告成可以睡个好觉了。我跟你讲模型上线那天才是你噩梦的开始。AI系统跟传统软件最大区别在于传统软件只要代码不改行为就是确定的模型不一样线上数据一变模型效果就飘了。6.1 监控指标怎么设延迟、吞吐、效果一个不能少部署完之后我建议立刻把三类指标监控搭起来服务健康指标QPS、延迟P50/P95/P99、错误率、GPU利用率。这些主要看系统有没有在正常运行业务效果指标用户反馈也好、人工抽评也好得有个信号告诉你模型效果有没有变差数据分布指标线上输入特征的分布和训练集分布有没有发生偏移。这是提前预警的关键Prometheus Grafana是监控这一套的标配配置起来也不复杂。关键是指标的采集埋点要从第一天就做起来不然等出了事再想补监控日志就只能看着历史数据干瞪眼了。6.2 数据漂移怎么应对模型也得“与时俱进”数据漂移这个概念说白了就是线上的数据分布跟训练时不一样了。比如你训练客服模型的时候用户输入都是文字过了半年用户开始大量发语音转文字其中口语化词汇、错别字暴增模型的准确率自然就往下掉。应对数据漂移我习惯的策略是“两条腿走路”第一定期重训模型。每个月或者每个季度拿最新的线上数据重新微调或全量训练一版保证模型跟得上新情况。第二建立线上反馈闭环。把线上用户反馈、人工纠正的结果收集起来回流到训练集里。这个在智能客服、推荐系统这些场景尤其重要。我还特别建议设置“数据漂移告警”比如线上数据embedding的分布跟训练集分布差异大到一定程度就触发告警。这个可以先用一些简单的统计量均值、方差、特征覆盖度做不用一上来就搞那些复杂的对抗验证能提前发现问题就是胜利。6.3 模型版本管理与回滚留一手永远不为过这个是我最想敲黑板强调的。模型上线不是终点而是起点。你每上线一个新模型都要保证一件事如果新模型出了问题能不能一键回滚到上一个版本我自己的做法是每次上线新模型老模型的模型文件不删部署脚本里保留一个切换开关。这样一旦线上出问题改个配置就能瞬间切回老模型而不需要重新部署整个服务。这个操作可能只需要10分钟的准备但它能在关键时刻救你一命。7. 从零开始的入门路径建议少走弯路就是最快的路前面讲的是“术”最后这段聊聊“道”。如果你真的下决心走ai-engineering这条路我给几条掏心窝子的建议。7.1 一个可执行的90天入门路线很多人一上来就问“要学多久才能入门”我直接给你一个明确的路线图照着做就行。第一个月主攻基础Python语法、数据结构、NumPy/Pandas做数据处理、PyTorch基础配合经典机器学习模型线性回归、逻辑回归、决策树、随机森林把漏的地方补齐。第二个月走通链路选一个简单任务文本分类、图像分类都行从数据清洗到模型训练到部署上线完整走一遍用我前面讲的那些工具Docker、FastAPI、MLflow这些反复操练。第三个月拉高深度选一个真实业务场景比如客服对话分类、商品评论情感分析在数据质量、模型优化、线上监控上花功夫尝试用等注意早点引入前面的工程化手段养成好习惯。这个路线的核心逻辑是先跑通再跑好最后跑快。别一上来就想一步登天。7.2 一些我踩过坑之后的真心话最后说点个人感言吧。做AI工程这几年我最深的体会是AI工程不是在训练模型而是在管理和驯服不确定性。数据会变、模型会漂移、线上流量会暴涨暴跌作为工程师你是要在这个充满不确定性的世界里搭出一个尽可能确定、可控、可维护的系统。别人说“整天写代码调参没意思”但我不这么觉得。当你看到自己搭的模型每天稳定服务几百万次请求帮业务真正解决问题这种成就感是难以替代的。如果只让我给刚入行的你一个建议那就是别怕动手从零开始的那个“从零”本身就是你最宝贵的财富。真正从零开始把一条链路走通的人跟只看教程的人差距在遇到问题时一眼就能看出来。这条路上会有很多让你想摔键盘的时刻但坚持把这些坑填平你会发现自己不知不觉已经比大多数人走得远了。去动手吧从今天开始。
