1. 从零开始之前先弄清楚AI工程到底在解决什么问题我在面试候选人的时候经常问一个问题你做过AI项目对吧能不能说说从拿到需求到用户真正用上这个功能中间到底发生了哪些事情大部分人第一反应是训练模型。再追问下去无非就是洗数据、调参、看loss曲线、再调。至于这个模型怎么变成一个稳定运行的线上服务、怎么保证每天跑的结果不出错、模型效果变差了怎么发现——大多数没有完整项目经验的人根本答不上来。这恰恰就是AI engineering和用AI做个实验的区别。如果把AI工程拆成两个词来看工程才是那个真正的定语。工程意味着你要交付一个可维护、可监控、可回滚、可迭代的线上系统而不仅仅是产出一份精度还不错的Notebook。这篇内容我想认真聊聊我从零开始学习AI工程时走过的完整路径。它不是课程大纲也不是工具清单而是一个从第一次跑通模型到把模型真正放进生产环境的过程复盘。适合准备入行的新人、正在做算法但工程经验偏薄的同学以及那些想搞明白模型训练完然后呢的从业者。1.1 大多数人对AI工程的第一个误解把它当成了算法研究我见过太多人学AI的第一站是随便找个开源模型在自带的数据集上跑个fine-tune然后看着准确率从80%涨到92%觉得自己已经入门了。但真实业务里几乎没有一个问题长成给你一个干净数据集请你提高准确率的样子。真实的AI工程问题开场往往是这样的业务方说帮我做个智能客服但翻遍数据库历史对话记录散落在三个系统里还有大量重复、缺字段、带错别字的脏数据。模型明明在测试集上表现很好一上线怎么就变成弱智了因为线上来的请求分布跟训练数据完全不同用户说话的方式根本不按测试集来。模型推理时间不稳定峰值时一个请求要3秒才能返回用户早就关掉页面了根本没有机会看到你那个精度99%的模型。这些问题没有一个能靠调参解决。它们考验的是你能否把整个链路——数据、训练、部署、监控、迭代——当成一个系统来设计。所以我的第一个建议是放下模型是一切的执念把目光投向模型周围那一大圈看起来不性感、但决定成败的工作。1.2 一个AI产品系统的完整链路到底有多长以前我自己画过一张链路图虽然有六七个环节但每一个环节连接起来才算一个完整的AI工程闭环。这里我用文字描述一遍你可以在脑中跟着过一遍。最开头是需求定义。你要跟业务方确认一个极其朴素的问题这个模型做完用来干嘛是帮客服降低响应时长还是帮审核人员减少工作量还是给推荐系统做召回候选目标定义清楚了才能定好坏指标。接下来是数据获取和清洗。你要从各个系统把数据捞出来搞定格式不统一、字段缺失、标注口径不一致的问题。然后是特征与标注。原始数据要转换成模型能吃的形态如果是监督学习还得有人或者规则去给出标签。标签的质量几乎决定模型的天花板。再往后是模型训练与评估。这部分大家最熟悉但工程视角下评估不能只看accuracy要看这个指标对应到业务上意味着什么。漏掉一个欺诈单的代价跟误杀一个正常单的代价完全不一样。训练完就是部署上线你要考虑在线服务还是批处理用多大规模的机器接口怎么设计超时和重试怎么处理。最后也是最重要的上线之后要有监控。数据分布变了要能发现、模型效果退化要能告警、出了问题要能快速回滚。很多系统上线即死不是因为模型不行而是因为监控不到位问题发生了三天才被发现。1.3 为什么先跑通一个示例是最差的第一课很多教程会让你下载一个现成的项目跑通示例然后感觉良好。我必须说这个动作对于建立信心可以但对建立工程能力几乎没用。原因很简单示例项目是别人已经把脏活累活全部干完之后展示给你一个光鲜亮丽的结果。你在示例里看不到数据是怎么被清洗的看不到依赖冲突是怎么解掉的看不到模型上线时机器不够用怎么办更看不到监控告警是怎么配的。这些东西才是AI工程的主战场。所以我推荐的学习路径不是跑通示例而是从零搭建一个最简但完整可用的AI系统。哪怕只是一个文本分类器也走完数据、训练、部署、监控全流程。规模小没关系链路完整才是关键。理解了全链路以后面对任何项目你都知道自己处在哪个环节该往哪个方向补。2. 地基工程环境、数据与可复现性这三件事决定后续的一切有了全链路认知之后真正动手的第一步不是学PyTorch而是把开发环境的地基打扎实。我在这个阶段犯过很多错误最惨的一次是在一台服务器的全局环境里装了一套TensorFlow结果另一个项目需要的NumPy版本冲突整个环境直接废掉重装系统花了整整一天。从那天起我学会了一个道理在AI工程里环境管理不是最好做而是必须做。很多新人觉得环境管理浪费时间但恰恰是这些看起来不务正业的工作决定了你的项目能不能被复现、能不能被交付。2.1 环境隔离与依赖锁定别再做全局安装党Python环境管理我推荐你至少掌握一种成熟的方案。早期的virtualenv和requirements.txt到现在仍然是主流不过最近两年我试下来更推荐用conda管理Python版本、用venv或者uv管理项目依赖再配合一个彻底的依赖锁定机制。这里我展开说说为什么依赖锁定这么重要。AI项目的依赖链非常长torch、numpy、pandas、scikit-learn、transformers随便哪个库都牵连着一大堆底层的传递依赖。你今天pip install出一个可以跑的环境不代表三个月后重新装依赖还能跑。版本只要差个小版本底层编译的C扩展行为就可能变化模型结果甚至都不完全一致。实操上我一般会在项目根目录维护两份文件一份是requirements.in只写顶层直接依赖方便人看。一份是requirements.txt用pip freeze或者pip-tools生成把所有传递依赖的精确版本锁死。然后配合Docker镜像固化整个环境。镜像里不只是Python包还包括操作系统版本、CUDA驱动版本、系统库。这样才能保证在我机器上能跑变成在任何机器上都能跑。2.2 数据管线从散落文件到可审计的数据集接着是数据管理。这一块很多人忽略因为它没有训练模型看起来那么酷但在实际项目中数据管线的工程质量直接决定了模型效果。我踩过最大的坑是数据处理和模型实验耦合在一起。第一版模型做的时候直接写了一个process.py脚本从某个目录读CSV处理完直接喂给模型。后来业务方反馈数据来源有误我又手动改了脚本重新生成了一遍数据集。问题出在我没有记录新数据集是怎么生成的、跟上一版数据集差在哪里结果模型效果变好了却没人能说清楚到底是数据变了还是模型变了。后来我引入了两个非常朴素的工具。第一个是DVC用来做数据集的版本管理。数据文件跟代码一样可以打tag、可以回滚到某个历史版本。第二个是给每份数据集生成一份校验报告包括行数、字段缺失率、标签分布等像数据集的身份证。这样做的意义在于任何一次模型效果变化都能追溯到具体是哪份数据、哪个特征、哪个模型版本产生的。出了问题可以复盘而不是拍脑袋猜。2.3 实验追踪让每一次模型迭代都有据可查AI工程跟传统软件开发最大的不同在于模型训练是有随机性的同样的代码和数据跑两次结果可能略有不同。如果连实验的记录都没有你很难判断某个改动是真正有效还是纯属运气。我的习惯是从第一次训练就接入实验追踪工具。MLflow是其中最主流的也可以在团队规模够大时用Weights Biases或者Neptune。不管选哪个核心是追踪以下四类信息参数学习率、batch size、模型结构配置等。指标训练集、验证集上的loss、F1、AUC等。产物训练好的模型文件、预处理器的参数、特征列表。元信息代码版本git commit、数据集版本、环境版本。有同学可能会问刚学AI工程就上这一堆工具会不会负担太重我的回答是不会。因为这些工具本质上就是在做记账而记账的习惯越早养成越好。等你的实验多到第50个的时候你就能体会到什么叫全都记下来的幸福。没有记录的实验等于白做。3. 训练之外的那一半评估体系、上线方式与监控回滚很多人的学习路径在模型训练好这里就戛然而止。但工程视角下训练只占整个AI项目大概三分之一的工作量。剩下的三分之二全在上线相关的那些事上。3.1 离线评估别被准确率一叶障目离线评估是模型上线前的第一道关但它也是最容易被错误使用的一关。我见过很多团队拿一个准确率95%的模型欢天喜地上线结果业务方用了一周反馈这东西根本没法用。原因往往是业务场景里正负样本比例本身就是极端不平衡的。举个例子。一个工单自动分类系统90%的工单是咨询8%是投诉2%是紧急故障。如果一个模型把所有工单都预测成咨询准确率也有90%。但这模型有哪怕一点点用吗没有因为紧急故障全部漏掉了。正确的做法是根据业务代价设计评估指标。分类问题里要看precision和recall的组合或者直接上F1、PR曲线排序问题要看NDCG、MAP回归问题要看MAE、MAPE而不只是MSE因为MSE对离群点太敏感。最关键的是你要跟业务方一起定义这个模型的错误会造成多大代价然后让评估指标去对齐这个代价而不是机械地追求一个并不知道含义的accuracy。3.2 上线方式批处理、实时推理还是异步队列模型评估通过之后紧接着的问题是怎么上线。很多教程默认模型上线启动一个HTTP服务。实际上AI系统的在线方式起码有三类分别对应不同场景。第一类是离线批处理。比如每天的午夜定时跑一次用户分群、生成个性化推荐列表、批量打标签。这类方式实现最简单成本也最低因为可以用大一点的模型、跑得多慢都没关系只要在上线时间前跑完就行。第二类是实时在线推理也就是一个HTTP接口用户请求来了马上返回预测结果。这类方式要求延迟可控一般要做模型压缩和推理优化比如量化、剪枝或者上ONNX Runtime。适合在线推荐、风控、智能客服这类场景。第三类是异步消息队列就是做一个队列服务把请求扔进去后端异步处理完再通知调用方。适合那些不需要秒级响应、但又不能等到第二天才出结果的任务。很多新人一上来就想上实时接口我觉得有点本末倒置。先想清楚业务需求侧重点要实时性还是只要吞吐量成本预算是多少如果业务方说用户能等到5秒你完全没有必要花一个月去做推理加速。3.3 监控与回滚模型上线只是开始模型部署完之后真正的AI工程挑战才开始。我见过太多上线第一天效果很好一个月之后没人管的系统。数据分布不是恒定的用户行为会变、季节会变、业务政策会变模型效果随之下滑几乎是一定的。所以上线的同时必须配齐三样东西模型效果指标的监控看板。每次推理请求的预测分布、模型打分均值和方差都可以做实时监控。数据分布漂移的检测。训练数据特征分布和线上数据特征分布出现显著差异时要能触发告警。快速回滚机制。一旦发现线上异常能在分钟级把流量切回旧版模型或者兜底规则。回滚这件事我多说一句。在设计系统时我建议把模型版本的切换做成配置项而不是代码变更。也就是说服务启动时从一个模型注册表拉取当前生效的模型版本要切换版本只需改一下配置并执行热加载而不是重新发一次代码。这样出问题时回滚就成为一个低风险动作而不是一次新的上线。4. 一次完整的从零搭建AI服务实战以文本分类为例理论讲再多不如从头到尾走一遍。我从零搭建过一个在线文本分类服务下面用这个例子把前面说的全链路串起来。整个项目规模不大但流程完整你可以照着这个思路去套自己的场景。4.1 先定义问题和成功指标当时的业务需求是给客服工单做自动分类分到售后、退款、投诉、咨询四个类别目标是减少客服人工分流的时间。这个需求对应的成功指标不是模型的整体准确率而是两个更具体的东西工单分类的F1值要达到0.85以上因为类别不平衡准确率不靠谱。线上接口P95响应时间要小于300毫秒因为客服系统是即时交互的。把指标定成可以量化、有时间要求的数值后面每一步决策都有了依据。做不做模型压缩、要不要换一个更小的模型都是以这两个指标为判断标准的。4.2 数据采集与清洗永远比想象中麻烦数据来源是客服系统的历史工单大概有5万条记录。原始数据的形态非常脏有的工单标题和正文分在两个字段有的只有一个有些标签是老客服手填的里面混合了退款退钱退货退款等十几种写法。处理流程我总结为三步第一步是字段合并与文本清洗。把标题和正文拼接成一条完整文本去掉HTML标签、URL、无意义的数字串。第二步是标签归一化。我把退钱退货退款要求退款等全部映射到退款然后用白名单加人工抽检的方式统一口径。第三步是划分数据集。按时间切分前4万条做训练后1万条做验证。这里用了时间切分而不是随机切分因为线上看到的数据永远是未来的数据随机切分会让模型过拟合到过去的数据分布上。做完之后我还对每份数据做了分布报告每个类别的样本量、平均文本长度、缺失字段比例。这些信息后面排查问题时会反复用到。4.3 模型选型与训练小模型优先文本分类这个任务2025年这个时间点上选择非常多。我经历了从传统机器学习TF-IDF加逻辑回归到预训练模型微调BERT、RoBERTa再到轻量级模型DistilBERT、AlBERT的过程。在这个项目里我最终选了DistilBERT。原因有两个一是它对中文工单文本的理解能力远好于TF-IDF二是它比完整版的BERT小40%推理速度更快内存占用更低更容易满足300毫秒的响应要求。训练时我有几个固定习惯固定随机种子保证实验可复现。每个实验都记录到MLflow包括参数、指标和模型产物。用验证集做early stopping避免过拟合。最终模型的F1到了0.87超过了目标线。但这里我强调一下离线指标达标不等于可以上生产。接下来还有部署这一关。4.4 服务化部署FastAPI加模型缓存部署环节我选择的是FastAPI搭一个简单的HTTP服务。它的优点是异步支持好、自带请求参数校验、文档交互界面好用非常适合模型推理服务这种场景。核心代码结构大致是这样的from fastapi import FastAPI from pydantic import BaseModel from transformers import pipeline app FastAPI() class Item(BaseModel): text: str model_cache pipeline( text-classification, model./models/distilbert-ticket-v1, tokenizer./models/distilbert-tokenizer-v1 ) app.post(/classify) def classify(item: Item): result model_cache(item.text) return {label: result[0][label], score: result[0][score]}这里最需要注意的一个工程细节是模型一定要在服务启动的时候加载一次放进内存缓存而不是在每个请求里加载。否则每请求一次就加载一次模型延迟会直接爆炸。这个代码里用了一个模块级的model_cache就是为了保证模型只加载一次。部署我用的是Docker打包镜像里固化好Python环境和模型文件然后通过一个进程管理工具拉起服务。做一次压测确认P95延迟在300毫秒以内才算过关。4.5 上线后的监控配置上线后我配了三层监控第一层是基础运维监控。CPU、内存、QPS、延迟这些用Prometheus加Grafana就能看到。第二层是接口业务监控。每个分类请求的置信度分布、各类别预测的数量占比。如果预测为投诉的比例突然从8%涨到20%多半是哪里出了问题。第三层是数据漂移检测。我定期计算线上输入文本的特征分布跟训练集做对比。这里用了一个比较简单的做法基于文本长度的分布和关键词频率做统计变化超过阈值就告警。这三层监控不是一个庞大系统都是一些很朴素的脚本加看板但正是它们让我在模型效果退化时能够第一时间发现而不是等到业务方投诉才被动去查。5. 从零到一过程中最容易被低估的四个坑在带过一个又一个同学之后我发现有些坑几乎人人都会踩一遍。这里挑四个最典型的公开聊聊你能躲过一个是一个。5.1 环境依赖地狱版本冲突不是玄学AI项目的依赖冲突问题几乎每个新手都会遇到至少一次。我记得有一次新电脑上conda环境里装上了最新版的NumPy结果跑一个老模型时底层报了一堆看不懂的C扩展错误。排查了整整一个下午最后发现是NumPy 2.0不兼容某个老版本的SciPy。最好的解决办法就是我前面说的三件事用conda或venv做隔离、用锁定文件固定精确版本、用Docker固化环境。这三个层次都做到了环境问题基本是可控的。另外我强烈建议不要在一个环境里同时跑多个项目。哪怕麻烦一点每个项目一个独立环境。你永远不知道两个项目的依赖树什么时候会打架。5.2 数据泄露模型分数虚高的头号元凶数据泄露是AI工程里最难发现的坑之一因为结果看起来很好但上线的实际效果差得离谱。最经典的例子是在做用户流失预测时把用户已注销这个字段当作特征喂给了模型。模型当然准确地预测到了流失因为特征本身已经包含了答案。但到了真实预测场景未来用户还没有这个字段模型瞬间失效。排查数据泄露的方法很简单但容易被忽略模型在训练集上效果显著高于验证集、或者离线指标好得让你不敢相信就要开始怀疑了。另外做特征工程时务必问自己一句话这个特征在预测时点真的能拿到吗不能拿到一律去掉。5.3 验证集被反复使用你的评估分数已经失真这个问题我称之为验证集污染。当你反复用同一份验证集做模型选择、调参、early stopping验证集的信息已经泄露到模型选择的过程中去了。你跟验证集接触的次数越多验证分数跟你期望的线上性能之间的差距就越大。解决方法是分层留数据训练集、验证集、测试集三层分开。验证集可以反复用来调参但真正的测试集必须留到最后、只允许跑一次。这个习惯看起来是浪费了数据但在真实业务里你永远需要一组没被碰过的数据来给你最后的信心。5.4 上线即翻车训练环境与生产环境的性能鸿沟最后一个坑比较隐蔽。本地训练时你用的是一个带GPU的开发机模型推理一次只要几十毫秒。上了生产环境部署到一台只有CPU的容器里延迟直接飙到两秒。这其实不一定是代码问题只是硬件差异被忽略了。我的建议是在生产部署之前一定要在目标机器规格上做一次压测。如果延迟不达标再考虑上模型量化将FP32权重转成INT8、模型蒸馏、或者换更小的模型。这个压测动作越早做越好等上线当天再发现就晚了。我在前面那个文本分类项目里就是因为提前在测试服务器上压测过选了一个更小的模型才避免了上线翻车。6. 如果重新从零开始我会这么安排学习路径前面讲的都是做项目时的经验。这一节我想换个角度聊聊如果完全回到零基础我会如何系统性规划AI工程的学习路径。6.1 第一个月把Python和数据基础打扎实不夸张地说AI工程的起点是Python不是模型。你需要熟练使用列表推导式、字典、生成器、装饰器这些日常操作会写面向对象的类理解异常处理。然后学习NumPy和pandas能把一张脏表格用pandas清洗得干干净净。这个阶段不要碰任何深度学习框架。先把把玩数据的手感练出来。pandas处理数据时的每一个操作都是后面做数据管线时的基本动作。6.2 第二到第三个月完整的机器学习基础然后进入传统的机器学习逻辑回归、决策树、随机森林、GBDT。重点不是背公式而是理解这些模型各自适合什么类型的数据和问题以及评估指标的含义。sklearn是这一步的主战场。一个练习建议找一个UCI或者Kaggle上的经典表格数据集自己从数据清洗开始到特征工程、模型训练、交叉验证、评估完整走一遍并且用MLflow记录每一次实验。这个练习很朴素但它覆盖了一个AI工程项目的核心闭环。6.3 第四到第六个月深度学习与服务化深度学习阶段我的建议是动手跑一个是基础理解结构是关键。不用一开始就去读复杂的论文而是先把一个文本分类或者图像分类的小任务用PyTorch从零实现一遍包括数据加载、模型定义、训练循环、评估循环。然后尝试用transformers库跑一个预训练模型体验fine-tune。到这里为止你其实已经具备了训练模型的能力。下一步才是工程化把训练好的模型用FastAPI包一个接口、用Docker部署起来、写一个监控脚本。到这里一条完整的AI工程链路就闭环了。如果你这个阶段能独立做出一个离线训练加在线推理的小项目并把它部署到一台服务器上你已经超过了一大批只会跑Notebook的人。6.4 我的日常习惯写实验日志、读代码、保持好奇最后分享三个我从自己经验里提炼的习惯。第一坚持写实验日志。每做一个改动记下来改了什么、为什么改、实验结果如何。不需要长篇大论三五行就够了。这个习惯在项目复盘时价值巨大。第二养成读源代码的习惯。不要只停在调用API的层面。用过一个库之后挑一个核心函数进去看看源码实现。读几次之后你会对工程是怎么组织出来的有非常具象的感知。第三建立自己的开源工具箱。把我提到的DVC、MLflow、FastAPI、Docker这些工具全部在自己电脑上搭一遍跑通一个小示例。工具只有真正用起来才是你自己的。我在实际带项目的过程中最深的体会是AI工程这件事看起来有一个很高的门槛其实门后面全是熟练工的活。模型结构可以抄框架可以学但那条从数据到上线再到监控的链路不亲手走一遍是完全体会不到的。如果你现在也是从零开始我的建议很简单不要读太多入门指南动手做一个小而完整的项目走完一遍就够了。做完它你已经是一个做过AI工程的人而不是听说过AI工程的人。