AI工程这几个字这几年被各种炒作包裹得有些面目模糊。有人拿它当口号有人拿它当简历装饰品还有人花了几万块报班学了几个月结果连一个模型都没跑通过。我自己从零开始踩过一整条AI工程的路——从“跑通demo”到“稳定上线服务”中间每一步的坑基本都趟过一遍。这篇文章就想把这套“从零起步”的完整路径摊开给你看包括技术栈怎么选、数据处理怎么做、模型怎么训、服务怎么起、踩坑怎么排。无论你是刚入行想找方向还是已经在做相关项目但总觉得工程侧使不上劲这篇文章都能给你一张可以照着走的地图。我所说的“AI工程”不是调包跑个notebook也不是“用OpenAI写个聊天应用”那么简单。它更接近一个完整系统的搭建逻辑把数据、模型、服务、评估、迭代串成一条高效运转的流水线。从零开始不意味着你把数学从头再学一遍而是让你亲手把一个AI系统从无到有建起来在这个过程中把工程判断力练出来。这才是真正的门槛。1. 从零开始AI工程的整体路径与技术选型1.1 先搞清楚AI工程和AI研究、数据科学的差别很多人刚开始学AI的时候一头扎进“复现论文”“调参刷榜”的路线跑出来了就觉得自己入了行。其实AI工程的重点根本不在“模型的聪明程度”而在“系统能不能稳定干活”。我举一个很简单的例子。你在notebook里训练一个分类模型acc到了95%好像很不错。但到了工程现场你要面对的事情变成数据每天怎么更新、模型用什么接口对外提供、单条请求延迟多少毫秒、遇到没有见过的输入它能不能自信地说“我不知道”而不是乱答、一次模型升级会不会把线上效果打碎。这些问题在notebook里完全不会出现却是AI工程要解决的全部。所以从我个人的经验来看AI工程更像“软件工程机器学习”的交叉地带。它不追求单点最高的分数而是追求整个价值链的稳定。你会发现在工程现场最有价值的能力不是调一个SOTA模型而是能够清楚地回答下面几个问题当前业务问题是不是适合用AI解决用哪种AI已有的数据质量能不能支撑模型训练不能怎么改造模型上线之后的表现谁负责看效果变差怎么回滚新数据接入、标签迭代、模型重训这一套流程能不能自动化跑起来这四个问题恰恰是“从零开始”这条路径里最应该先建立的认知框架。一开始学不会没关系但心里要有这个地图后面才不会学偏。1.2 技能树怎么点不必重复造轮子但要理解轮子从零开始做AI工程技术栈的选择可以直接决定你前三个月的体验。我见过太多人把时间浪费在“什么都想学什么都没学好”上面。以下是我认为最现实、最值得先投入的路径层次核心内容工具/技术选型优先级编程基础Python语法、面向对象、装饰器、类型标注Python 3.10必须数据处理清洗、转换、特征提取、数据管道pandas、Polars、SQL必须模型训练分类/回归/BERT微调/小规模深度学习scikit-learn、PyTorch必须工程化API服务、容器化、监控、自动重训FastAPI、Docker、MLflow强烈建议进阶专项LLM应用、分布式训练、特征平台LangChain、Ray、Feast按需学习这里有一个很重要的“为什么”。我建议先主攻Python生态不是说Java或Go不好而是AI工程领域绝大多数工具库、示例代码、社区方案都以Python为第一优先你用它做原型最快。等到需要做高性能推理服务或大规模流式处理时再引入Go、Rust也不迟。工程化的部分我自己最推荐从FastAPI开始原因非常简单“傻瓜级上手”“自带交互式API文档”。FastAPI用起来没有Flask那么重的结构束缚也没有Django那么多“多余的概念”。你写一个函数加上一个装饰器就能把一个模型包装成HTTP接口团队里别人拿起来就能用。这个正反馈来得极快能帮你建立最初的对工程化的兴趣。1.3 完整项目循环从“会跑”到“飞轮转起来”AI工程最后一个认知层面的东西就是要建立一个“项目生命周期”的概念。一般一个AI工程项目会经历下面六个阶段需求分析→数据准备→模型训练→评估验证→服务上线→监控迭代。这个循环里面有一个容易被新手忽略的点**真正区分工程师水平的不是模型训练而是“数据准备”和“监控迭代”这两头。**你可以回想一下任何网上公开的教程都喜欢把“训练”和“调参”讲得花团锦簇因为这最像技术。但实际工作中你大量时间花的反而是勘测数据、写清洗管道、处理标签缺失、设计观察指标这些东西。所以后面我讲解实操也会按照这个真实的比重来分配篇幅。模型训练我讲最核心的流程数据处理我讲具体手法监控迭代我讲一套最简可用的方案。2. 从零亲手打造一个AI服务以文本分类做全流程拆解2.1 业务场景定义与基线设计先说场景。我建议第一个项目选“客服工单自动分类”——这是一个非常经典、覆盖AI工程全链路、且数据容易获得的任务。你比如一个电商公司每天收到一千封用户工单内容包括“退货”“退款”“物流投诉”“产品咨询”“账号问题”等等人工一个一个转给对应部门很累。我们的目标就是训练一个模型自动把工单文本分类到正确的部门然后路由过去。这个场景好在哪里它够简单、业务价值一眼能看懂同时又足够复杂——有中文文本处理、有类别不均衡、有长尾样本、甚至有新类型问题涌现。作为从零开始练手它天生就是AI工程“五脏俱全”的典范。场景定了以后第一件事不是找模型而是立基线。基线是什么呢就是一个“不用机器学习也能想到的最笨但有效的方案”。比如在工单分类里最简单的基线方案是关键词匹配——如果文本包含“退货”就标记为退货类。这样测出来一个初始准确率大概在70%左右。这个基线的作用不是用来直接上线而是用来做一个心理锚点后面我们所有的模型如果连这个简单规则都打不过那就说明数据或建模思路哪里出了问题。给基线留一个专门的记录文件记下它用了什么规则、准召多少、哪些case错了。这套习惯我建议从第一个项目就养起来——因为模型实验本质上就是“在基线上做增量”没有基线一切指标都是漂浮的。2.2 数据获取、清洗与标注的第一版实操新手在数据这步最容易翻车我这里给出一个几乎可以“抄作业”的流程。假设我们手里是某个公司导出的工单CSV里面有“工单ID、标题、内容、提交时间”这几列还没有标签。第一步是人工粗标。你不需要一下子就标几千条那样又累又容易产生错误标签。我建议的做法是随机抽300条肉眼读一遍把类别先确定下来这一步叫“标签体系设计”。给每条粗标后的样本写阅读笔记记录“这个case为什么归到这一类”“有没有模棱两可的”。第一版标签体系不用求全能覆盖90%的情况就够了剩下的先标记为“其他/待定”。为什么要这样做因为你真正的敌人不是样本量不够而是标签不一致。如果同一句话被A标注为“退货”被B标注为“产品咨询”模型学到的就是混乱。所以宁可标500条仔细的也不要标5000条瞎标的。这一条经验我后面反复吃亏才明白。第二步是清洗管道编写。建议用Pandas或Polars写一个可重复执行的clean.py脚本每一步都保留中间输出。清洗要做什么呢import polars as pl df pl.read_csv(work_orders.csv) # 1. 去重 df df.unique(subset[工单ID]) # 2. 去除无意义空白 df df.with_columns( pl.col(标题).str.strip_chars(), pl.col(内容).str.strip_chars() ) # 3. 过滤有效样本标题或内容至少一个的长度大于10 df df.filter( (pl.col(标题).str.len_chars() 2) | (pl.col(内容).str.len_chars() 10) ) # 4. 拼接标题内容作为模型输入文本 df df.with_columns( (pl.col(标题) pl.col(内容)).alias(text) ) df.write_parquet(work_orders_cleaned.parquet)我特意用Polars而不是Pandas是因为它在大文件上快得多而且API跟Pandas很像入门成本低。如果你是第一次见这语法不用担心你只需要理解这段代码做的是去掉重复、去掉全空格垃圾、过滤掉信息量太少的样本然后生成一列text后续模型就读这一列。第三步是数据切分。这一步新手经常犯“随机切分”的错误——直接把数据随机分成训练集和测试集。但业务数据往往有时间顺序比如1月的工单和6月的工单表述方式、产品政策都可能不一样。正确的做法是按时间切分用过去的数据训练用未来的数据做验证这样模拟的是真实“用历史预测未来”的情况。例如把1月到5月的数据作为训练集6月作为验证集。train_df cleaned_df.filter(pl.col(提交时间) 2025-06-01) val_df cleaned_df.filter(pl.col(提交时间) 2025-06-01)你可能觉得“样本不均衡怎么办”还没处理。没错这是下一个问题。工单类型天然不均衡比如“退货”可能占50%而“发票问题”只占3%。这在业务里是常态。我们有两个选择下采样让各类数量接近或者保留样本分布但评估时看每个类别的准召。我个人的推荐是**训练时不用刻意采样评估时一定要分层看指标。**用一个classification_report就能很直观地看到每一类的精确率、召回率和F1这样你能知道模型到底是在“平均表现好”还是“真的各个类别都好”。工程上后者远比前者重要。2.3 基线模型训练与第一个“有效提升”数据准备好了我们现在可以开始训练。但我强烈建议先不用深度学习先上一版经典的scikit-learn管线。它的好处是训练快、可解释、代码行数少非常适合用来建立第一个可参考的“机器学习基线”。我们使用TF-IDF Logistic Regression。逻辑回归听上去老但它在文本分类里依然是性价比之王。你把文本向量化之后逻辑回归会为每个词学到一个权重系数正权重表示“看到这个词倾向于分类为某个类别”。这意味着你可以在分类结果上反查哪些词驱动了这个判断这在工程排错时极其有用。from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.pipeline import Pipeline pipeline Pipeline([ (tfidf, TfidfVectorizer(max_features30000, ngram_range(1, 2))), (clf, LogisticRegression(max_iter1000)) ]) pipeline.fit(train_texts, train_labels) val_preds pipeline.predict(val_texts)这份代码跑完在工单分类这种任务上通常能到85%左右的F1分数。作为对比前面最笨的关键词基线大概在70%左右。你看从“笨办法”到“机器学习方法”提升已经非常明显。到这里你已经有了第一个真正意义上的AI模型。这时候踩过一遍的坑我想单独拎出来说**TF-IDF的ngram_range是不是必须设成(1, 2)**是的至少在中文场景下建议这样。因为单个字或单词在中文里信息量太弱比如“退货”这个动作被拆成“退”和“货”两个字后单独出现时很容易和其他词混在一起。用二元词组(1, 2)能把“退货”“退款”“运费”这些连续片段保留下来分类效果会有质的提升。同理max_features30000限制的是词典规模防止向量矩阵过大拖慢训练同时也能过滤掉一大批低频噪声词。至于为什么低频词往往不是噪声而是“专有名词”——那是另一个话题现阶段你只需要知道设太大的max_features在样本量不够的时候反而容易过拟合。2.4 深度学习模型引入什么时候上微调怎么做跑完传统模型以后你自然会想“我可不可以更进一步”。深度学习微调是应该上的但我建议你先想清楚为什么上。如果你现有任务用逻辑回归已经95% F1业务也满意那微调投入产出比就低。反过来如果测试集上传统模型遇到大量“语义同义不同词”的情况——比如“我的货一直没到”和“物流卡了好几天”都指向物流问题但因为没有共享词语传统模型就分别归类错了——这就说明文本的语义信息没有被捕捉该试试预训练模型。从零入手微调我推荐选择预训练模型 Trainer API这套组合。工具选择上很多国产模型在中文场景表现很好而且改动极少。我们以PyTorch生态为例核心代码如下from datasets import Dataset from transformers import AutoTokenizer, AutoModelForSequenceClassification, Trainer, TrainingArguments # 1. 数据格式对齐 train_dataset Dataset.from_dict({text: train_texts, label: train_labels}) val_dataset Dataset.from_dict({text: val_texts, label: val_labels}) # 2. 加载模型与分词器 model_name bert-base-chinese # 也可以替换为其他中文预训练模型 tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForSequenceClassification.from_pretrained(model_name, num_labels6) # 3. 封装tokenize函数 def tokenize(examples): return tokenizer(examples[text], truncationTrue, max_length128) train_dataset train_dataset.map(tokenize, batchedTrue) val_dataset val_dataset.map(tokenize, batchedTrue) # 4. 训练参数 training_args TrainingArguments( output_dir./results, num_train_epochs3, per_device_train_batch_size16, per_device_eval_batch_size32, evaluation_strategyepoch, save_strategyepoch, logging_dir./logs, ) # 5. 开始训练 trainer Trainer( modelmodel, argstraining_args, train_datasettrain_dataset, eval_datasetval_dataset, ) trainer.train()这个代码里藏着好几个新手容易忽略的关键点我来解释一下。max_length128是非常需要注意的。工单文本如果超过128个token会被强行截断超出部分就丢掉了。如果我们的工单“内容”字段动不动就是几百字那得调大比如256甚至512。但调大的代价是训练和推理变慢、显存占用变大。这实际上就是一种工程上的“取舍”你要根据业务文本长度分布来做决定而不是照抄默认值。我一般先用一个简单的长度分布统计脚本看看中位数和95分位再定max_length尽量覆盖90%以上的样本。第二per_device_batch_size16。如果你的显卡只有8G显存跑BERT这种模型这个batch size是勉强可以接受的。如果爆显存优先降到8再不行就4。有人一见到显存报错就想去换显卡我建议别冲动先调batch size再考虑梯度累积。我在8G老显卡上通过batch_size4加gradient_accumulation_steps4照样把BERT训练起来了只是慢一些功能一点不缺。第三num_train_epochs3。微调预训练模型两到三个epoch通常就够跑多了反而在领域数据上过拟合。你别把“训练轮次越多越好”带过来深度学习模型很吃这一套训练指标漂亮验证集上一塌糊涂典型的过拟合信号。后面我们会专门讲怎么判断。2.5 模型评估不只盯着准确率要看“业务价值”模型训练完第一件事不是欢呼“准确率97%”而是冷静下来。因为准确率在类别不均衡的数据集上是极具迷惑性的指标。如果“退货”占了90%模型把所有样本都预测成“退货”准确率也有90%但“产品咨询”“发票问题”这些少数类全部阵亡。这就是工程上“准确率陷阱”的典型。正确的做法是看宏平均F1和每个类别的细粒度指标。宏平均F1把每个类别的F1先算出来再取平均不会让多数类一家独大而细粒度报表能找出哪些类别是弱项给你下一轮迭代方向。from sklearn.metrics import classification_report print(classification_report(val_labels, val_preds, target_nameslabel_names))看到了吗classification_report每一行的precision、recall、f1-score都摆在眼前你会立刻发现模型在“发票问题”这一类上recall特别低。这说明模型对这一类的把握不足下一步你要么多标一些这类样本要么针对这类错例做专门的规则补充。评估的时候还有一个容易忽略的维度就是预测置信度。所有分类模型除了给出类别还会给出概率。你应当观察置信度分布——如果模型经常以0.5左右的概率做决定说明它对很多样本都在“掷硬币”这时候就需要考虑设置一个“置信度阈值”低于0.7就不给明确分类走人工。这在实际业务里价值极大因为它比“强行分类但经常分错”要体面得多也安全得多。pred_probs pipeline.predict_proba(val_texts) max_prob pred_probs.max(axis1)你可以自己统计一下在测试集上如果只保留置信度大于0.7的预测剩下的交人工整体准确率能提升多少。通常这个数据会非常漂亮能给业务方一个非常有说服力的“人机协同”方案。3. AI工程的“最后一公里”服务化、监控与迭代3.1 用FastAPI快速把模型包装成稳定服务模型训练完毕并测试通过接下来才是AI工程里的硬仗把这个模型变成一个可以被实际业务调用的服务。很多人在这一步栽跟头是因为他们训练模型用的是Jupyter Notebook环境里什么都有可一旦要脱离这个环境就不知道怎么“把模型带出去”。第一步是把模型保存下来。sklearn管线的保存方式极简单import joblib joblib.dump(pipeline, assets/classifier_pipeline.joblib)深度学习模型用trainer.save_model(assets/model)它会同时保存模型权重和词表文件目录拿出来就能加载。第二步是我们写一个FastAPI应用。从零开始我建议搞一个最小可用的版本先把服务跑通再逐步覆盖更多细节。from fastapi import FastAPI from pydantic import BaseModel import joblib app FastAPI(title工单分类服务, version0.1.0) class InferenceRequest(BaseModel): title: str content: str class InferenceResponse(BaseModel): label: str confidence: float pipeline joblib.load(assets/classifier_pipeline.joblib) label_names [退货, 退款, 物流投诉, 产品咨询, 账号问题, 其他] app.post(/api/v1/classify, response_modelInferenceResponse) def classify(req: InferenceRequest): text f{req.title} {req.content} label_idx pipeline.predict([text])[0] proba pipeline.predict_proba([text])[0][label_idx] label label_names[label_idx] return InferenceResponse(labellabel, confidencefloat(proba))这个接口有三个工程细节值得关注。第一我为输入和输出都定义了严格的BaseModel这相当于给接口加了一份“合同”。请求必须含标题和内容响应一定会返回类别和置信度。这样上下游无论谁对接都不会出现“传错字段名”这种低级错误。第二我用Pydantic的响应模型配合FastAPI会让接口文档自动生成你在浏览器打开/docs就能看到接口定义甚至可以点“Try it out”直接在页面做测试。这个体验对团队协作太友好了。第三/api/v1/...这个路径我特意加了“v1”版本号。这是从上线第一天就引入API版控习惯后面模型升级到v2老服务继续保留新调用方走新路径互不影响。这是个极小但价值极高的工程习惯。启动服务只需要uvicorn main:app --host 0.0.0.0 --port 8000然后你就可以用curl来测试接口curl -X POST http://localhost:8000/api/v1/classify \ -H Content-Type: application/json \ -d {title: 我的退款还没到, content: 上周申请退款的订单到现在都没有收到钱}返回结果大致是{label: 退款, confidence: 0.98}。到这里你已经把一个训练好的模型变成一个别人能随时调用的线上服务了。3.2 容器化部署与资源管理的心得写好FastAPI服务接下来就是把你这个服务放到服务器上或者放到一个别人不容易把环境搞挂的地方。这时候就要请出Docker。一个最小的Dockerfile长这样FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8000 CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 8000]这一步的目的只有一个环境隔离。你可能在本地跑得好好的服务挪到服务器上就因为Python版本、系统库、依赖冲突而崩盘。Docker把“我这套环境”打包成镜像挪到哪里跑行为都一样。但这里我要给你一个经验之谈COPY . .这种写法在项目里容易把乱七八糟的文件全打包进去。正确的习惯是建一个.dockerignore文件排除本地缓存、虚拟环境、原始数据、训练脚本等“不需要进入镜像”的杂物__pycache__/ *.pyc .venv/ venv/ data/ models/ .notebooks/模型文件要不要打包进镜像这是个需要思考的问题。如果模型很小几十MB直接打进镜像简单省事。如果模型好几个GB我建议不要打包而是把模型文件放对象存储服务启动时按需下载。原因在于镜像仓库的推送拉取会非常慢每次更新模型都要重新几千MB的网络传输这不能接受。工程重担要均匀分配镜像只负责代码逻辑模型走独立版本通道这样模型更新也快回滚也快。资源管理方面FastAPI配合uvicorn默认是同步模式或者说不加worker就是单进程吞吐量有限。你要提高并发加--workers 4。但注意如果你的模型很大、每个推理请求又很占CPU起太多worker反而会让机器过载。一般先按“CPU核心数的物理核数”来设置worker数再通过压测来微调。压测工具我建议用locust写个简单的脚本就能模拟几十个并发用户观察延迟和错误率。3.3 模型监控用日志和拉取式测试保证线上“不黑盒”很多项目局部做完了模型服务化就以为万事大吉。结果上线第二周业务方跑过来说“分类怎么突然变蠢了”。你翻代码没动过模型也没换为什么效果会变因为线上输入分布变了。用户的说话方式、活动期间的话题、新上架产品的名称这些东西都在变化模型在旧数据上训练碰到新分布自然会表现变差。所以AI工程从零开始就要把“线上监控”这个模块也纳入进来哪怕用一个最简版本。我推荐做两件成本极低的事。第一件是给每个推理请求打结构化日志。把模型名称/版本、特征长度、预测类别、置信度、延迟毫秒按JSON格式打到文件或日志聚合服务里。这样你随时可以统计“最近一小时预测置信度的中位数”一旦忽然从0.95掉到0.6你就知道线上输入变了需要告警并启动模型迭代。import json, time, logging logger logging.getLogger(inference_log) def classify(req: InferenceRequest): start_time time.time() ... latency_ms (time.time() - start_time) * 1000 log_entry { model_version: v1.0.0, label: label, confidence: float(proba), latency_ms: round(latency_ms, 2), title_length: len(req.title), content_length: len(req.content), } logger.info(json.dumps(log_entry, ensure_asciiFalse))第二件是建立一套“拉取式回归测试”。意思是准备一批典型的输入样本50~100条覆盖每个类别每天晚上自动跑一遍线上接口如果某类别的准确率或置信度跌破阈值就发告警。这有点像“体检闹钟”每天定时检查模型健康度。你不需要用一个多复杂的平台写个cron脚本调接口写结果文件就够用了。从我的实践来看做了监控之后你才能睡得踏实。AI模型本质上是个“活物”——它的输入环境一直在变你只有时刻看着它才能在最早期发现问题而不是等业务方投诉一堆了再回头研究。3.4 模型迭代闭环建立一套最少可行的重训流程监控发现效果变差你就进入迭代环节。从零搭建重训流程我建议按“最少可行”原则来做几个自动化步骤不用一上来就上大平台。第一步是数据回流。线上每次推理如果你能让用户/业务方标记“这个预测对不对”哪怕只是提供一个好评/差评按钮你就有了新的、最接近真实分布的训练数据。把这部分数据定期存入一个“反馈表”这就是你的“免费新数据源”。第二步是定期重训。最初阶段你可以用cron定时任务每两周跑一次训练脚本脚本自动从清洗管道读取新数据训练新模型然后在验证集上评估。只有验证指标相比当前线上模型有提升比如宏平均F1提升超过1个百分点才进入发布流程。第三步是金丝雀发布。新模型不要直接全量替换而是先切5%的流量过去对比新老模型在同一个时间段内的平均置信度和人工反馈满意度。确认更优再逐步扩大到100%。如果新模型出了幺蛾子随时能一键切回旧版本。这一整套听起来高大上实际操作也很简单在FastAPI服务里加一个USE_MODEL_VERSION环境变量切换的时候改环境变量重启服务就行。我在多个项目里验证过这套最小闭环采集反馈→定时重训→金丝雀发布→全量上线→监控章节。它每走一圈模型就能在新数据分布上更新一次形成真正的“数据飞轮”。从零开始做大模型服务这个循环是你迟早要补上的核心能力。4. AI工程实战中那些“书上没有”的坑与排查办法4.1 特征泄露导致评估虚高的隐蔽陷阱AI工程里最坑的问题之一就是“特征泄露”——你在训练时用了一些“未来才知道的信息”导致验证时指标虚高上线后发现实际效果大跳水。这种情况在文本分类里相对罕见但在用户画像、风控、推荐等领域非常常见。我说一个最典型的例子如果你用时间字段做用户特征比如“用户在系统内注册天数”训练集和测试集同时间段时指标很好。但上线之后你面对的是新用户他注册天数为0你训练时可能根本没见过这种长度为0的样本模型就懵了。这就是“特征分布漂移”加“特征泄露”双重问题。排查特征泄露有几个常见思路第一检查所有特征里有没有哪个只有在线下训练数据集里才存在、在线上请求时刻“还没发生”的信息。比如“用户是否在7天内下单”这个特征如果它是根据未来7天下单情况来构造的那就是严重泄露。第二做一个“特征-标签相关性”快速扫描看是否有特征与标签的相关性高到异常。比如某特征和Label相关系数0.99那它很可能在“间接偷看答案”。第三最稳妥的办法是做一个时间回溯模拟测试。把数据集按时间切成两半只用前半部分的历史特征和标签训练在后半部分上做评估看指标是否和“随机切分”时的评估差距过大。如果差距巨大几乎可以断定存在某种隐性泄露。这个测试在工程上花不了多少时间但能避免你辛辛苦苦训出来的模型在真实环境里被“打回原形”。4.2 训练与线上服务不一致“训练时是一套代码线上跑的是另一套代码”这在需要把文本清洗、预处理逻辑同时用在训练和推理的项目里特别容易发生。比如你训练时把标题和内容拼接成“标题空格内容”但线上服务里可能拼接成了“内容标题”或者忘了加空格。模型的输入分布一旦不一致效果瞬间退化。解决这个问题的办法从工程上说是“单一代码路径”把文本预处理逻辑统一放到一个preprocess.py函数里训练脚本和服务代码都只调用这一个函数。禁止在训练脚本里随手写“拼接”在服务代码里又另行实现一套。我从一开始就设立一条硬性规矩——“任何数据处理逻辑只允许出现一次”后续几乎没有再犯过这类低级错误。另外线上服务里最容易疏忽的一个点是你在训练时代做过的文本清理去重、过滤短文本不能在线上推理时自动套用。因为训练时的清理是“对全数据集去重”而线上每个请求是独立来的你总不能等到攒够一批再一起去重——那是批处理的逻辑。所以你要把“单条样本的清洗”如strip、长度阈值检查跟“数据集级别的清洗”去重、过滤严格分开线上只执行前者。4.3 常见问题的排查清单实际工作里AI工程遇到的许多问题其实是可以标准化排查的。我根据自己的经验整理了一张速查表越往下越深入问题表现优先排查顺序常用检查手段模型接口偶尔超时/5031. worker数量是否不够 2. 模型推理是否串行阻塞 3. 是否有大对象占用内存查看监控面板压测考虑加worker或异步化训练loss下降但验证loss上升1. 是否过拟合 2. 学习率是否过大 3. 数据划分是否有泄露降训练轮数、调学习率、检查数据划分验证集指标好线上却很差1. 数据分布漂移 2. 特征不一致 3. 线上和训练特征处理逻辑不同比较线上预测文本与训练样本的embedding分布逐一核对预处理代码GPU显存不足1. batch_size太大 2. 序列长度过长 3. 模型太大减小batch_size截断max_length必要时用梯度累积模型对新词、新话题无法分类1. 是否需要持续更新训练数据 2. 是否需要更高级的语义模型 3. 阈值是否需要调低以走人工分析线上错误样本加入新标注数据重训迭代推理延迟过高1. 模型输入长度是否超长 2. 是否没有用模型量化/裁剪 3. 是否串行排队限制max_length尝试ONNX导出升级推理框架这张表没法覆盖所有问题但它给了你一个非常实用的起点思维**先看输入是否异常再看代码是否一致最后才怀疑模型本身。**我见过太多人一遇到效果变差就想着换个更大的模型结果排查一番发现根因只是线上少做了个strip清理。4.4 别在数据集和标签上偷懒最后一个经验教训也是最容易被新入行的工程师忽略的。AI工程最难的部分不是模型而是“你把数据怎么伺候好”。我见过很多项目死因不是模型不够强而是标注标准含糊两个人标同一句话给出不同标签。没有版本管理数据集被覆盖重跑之前的结果无法复现。只在模型指标上投入忽略错误分析导致永远在原地打转。我的建议是从零开始时就给数据集建立最基本的版本记录。哪怕只是维护一个dataset_versions.csv记录每次数据变更的时间、条数、标签分布、备注就能在未来的任何一次讨论里帮你厘清“当前到底在哪个版本上”。数据文件尽量放到带版本的对象存储上不要用“final_v2_2025_final_真的最终版.xlsx”这种文件名。工程素养很多时候就是这些“不起眼的小规则”累积出来的。5. 一些关于“从零开始”的真心体会说了这么多技术细节最后想分享一些跟“从零开始”这个状态有关的个人感受。我见过很多刚开始接触AI工程的人最大的毛病是“想一口吃成胖子”。一会儿学深度学习一会儿看大模型论文一会儿想搞分布式训练折腾几个月发现哪个都没有形成闭环连一个能用的API都没发布过。我个人建议初学者的目标和路线图不要画得太宏大一切围绕“跑通一个完整的、能被调用的AI服务”这个最小目标。哪怕你做的只是最简单的文本分类只要你能把数据处理、模型训练、服务上线、日志监控这四块串起来你就已经比60%停留在notebook阶段的人更接近“工程师”这个角色了。我还想强调一点AI工程是一个“慢变量”。你可能不会像背单词那样每天感到进步但当你第一次从日志里发现线上置信度掉、然后顺着监控指标找到新数据分布问题、最后通过重训和发布把效果拉回来——那一刻你才是真的在“做AI工程”。这种能力不是看教程能学来的它来自你亲手把一个项目从零推到线上并稳住它的全过程。如果非要用一句话总结我对这个领域的理解那就是AI工程不是关于训练一个聪明的模型而是关于建立一套能让模型稳定产生价值的系统。从零开始意味着你有机会亲手把每一个环节都打磨清楚而不是在别人搭好的框架里浮于表面。这条路走起来不轻松但每一步都扎实。