1. 先搞清楚AI工程到底在解决什么问题1.1 它和算法岗、数据岗有什么区别很多人一看到“AI工程”这四个字下意识会觉得这就是调模型、训练神经网络。实际情况完全不同。AI工程要解决的不是“怎么把模型精度提上去”而是“怎么让一个模型稳定、高效、可维护地跑在生产环境里并且持续创造业务价值”。模型只是中间产物数据管道、特征存储、训练框架、评估体系、部署服务、监控告警、模型迭代这一整条链路才是AI工程的核心。如果你去看招聘JD算法岗通常要求“熟悉Transformer、精通PyTorch、有顶会论文”而AI工程岗写的大多是“熟悉Kubernetes、有CI/CD经验、懂得模型监控和A/B测试”。一句话总结算法岗的目标是“造出一个好模型”AI工程的目标是“把模型变成一项可靠的服务”。这两个方向有交叉但思维方式差异很大。从零开始的人如果一上来就死磕网络结构忽略了工程化能力反而容易把自己困在“训练demo很行、一上生产就崩”的怪圈里。1.2 为什么“从零开始”是个优势我面试过不少候选人科班出身的往往一上来就聊模型结构、损失函数但问到“训练数据是怎么产生的数据分布有没有偏移服务挂在K8s上怎么滚动更新”就沉默了。反而是那些从零开始、一路自己折腾出来的工程师能把这套链路讲得头头是道。所以我一直觉得“from scratch”不是劣势反而是一个很好的起点。因为没有历史包袱你不会被“我们之前一直这么做的”这种惯性束缚。你会从第一行代码开始构建自己的工程体系每一步都知道为什么要这么做。这种“知其所以然”的能力在AI工程这个领域比背熟某个框架的API值钱得多。学AI工程本质上就是训练自己“用工程手段解决模型落地问题”的肌肉记忆而这套肌肉记忆完全可以依靠一个又一个端到端项目慢慢长出来。2. 从零开始的技术栈搭建先学什么、后学什么2.1 编程基础Python只是入场券别急着学PyTorch先把Python基础打牢。我说的基础不是“会写for循环”而是能熟练处理模块化代码、异常处理、类型注解、装饰器、上下文管理器这些日常工程特性。AI工程里你写的优雅代码大概率会在生产环境里跑很久不是你训练完就扔的玩具脚本。用Poetry或uv管理项目依赖而不是把几十个包全部塞进全局环境这是第一个需要养成的工程习惯。除了Python至少还要掌握三样东西Git、Docker、Linux命令行。Git不只是“commit/push”要会分支管理、rebase和解决冲突Docker要能写出干净的多阶段构建镜像理解为什么生产环境不用pip install而是构建镜像Linux至少要熟练操作日志查看、进程管理、端口排查、crontab定时任务。这些技能我当年都是被生产事故逼着学会的——某次模型服务半夜挂了连服务器都登录不进去那一刻才发现基本功有多重要。2.2 机器学习与深度学习原理学到“够用”就好学习ML/DL原理要把握一个度不需要啃完花书但也不能只调包。我建议从线性回归、逻辑回归、决策树这些经典模型开始把损失函数、梯度下降、正则化这些核心概念吃透。然后进入神经网络理解反向传播、BatchNorm、Dropout、学习率调度的原理。框架用PyTorch就够TensorFlow也能学不过现在PyTorch的社区生态更活跃。这里有一条少走弯路的经验学原理的时候一定要动手把一个小模型的训练循环自己写一遍。比如用纯Python和NumPy实现一个两层神经网络在MNIST上跑到90%的准确率然后换成PyTorch实现同样的模型。你会发现框架替你做了多少事也会理解为什么工程上要关注梯度爆炸、学习率过大、数据归一化这些细节。这类基础训练看似枯燥但在后面排查模型问题时特别有用——你不会看到一个NaN loss就束手无策。2.3 工程化三件套数据、实验、部署从零走向AI工程绕不开三座大山数据处理、实验管理、模型部署。数据处理至少要掌握Pandas、SQL和一种ETL工具。很多刚入门的同学喜欢用Pandas处理一切但上了生产数据动不动上千万行就必须学会用SQL在数据库层面做聚合过滤再用Spark或Dask做分布式处理。特征工程更是AI工程里最吃经验的部分后面我用一个具体项目展开。实验管理这块很多人一开始觉得“不就是记录一下参数和指标吗”直到同时跑几十组实验模型文件乱成一锅粥才知道MLflow或者WB这类工具的价值。我在本地一般用MLflow因为它开源、轻量、能自托管训练完的模型还能直接注册进Model Registry方便后续部署。模型部署以前是写一个Flask API就完事现在标准做法是用FastAPI封装推理接口用Docker打包镜像推到镜像仓库后用Kubernetes或轻量的docker-compose做服务编排。如果你只想从零开始先跑通那最轻的方式是直接用一个成熟的推理服务框架比如Triton或TorchServe然后再去理解它们内部的批处理、动态batching、显存管理逻辑。3. 用一个端到端项目验证全链路3.1 项目选题从“库存预测”到“知识库问答”与其零零散散看教程不如直接做一个覆盖全链路的项目。我推荐的入门项目是“电商商品库存预测”。原因有二第一业务场景足够清晰——预测未来N天的销量评估指标是RMSE人人都能看懂。第二它天然需要你处理时间序列数据、做滑窗特征、处理节假日影响最后还要把模型包成一个可以按时调用的API服务。如果你对大模型应用更感兴趣也可以做“基于RAG的私人知识库问答”。这个项目的工程链更长文档解析、文本切分、向量化、检索、重排、大模型调用、流式输出。但从零开始的阶段我更建议先做库存预测这类传统机器学习项目。因为它简单、快、容易闭环你能在几天内体会“训练-评估-部署-反馈”的完整循环。等这条链路跑熟了再升级到RAG项目你才不会在工程细节里迷失。3.2 数据处理与特征工程实操要点这个项目的数据可以自己造也可以用公开的电商销量数据。假设你有一张订单表字段包括order_date、sku_id、category、sales_qty、price。第一步不是建模而是做数据审视检查缺失值、异常值、时间跨度是否足够。时间序列项目尤其要小心数据泄露比如你用了未来时间的信息做特征会让线上效果惨不忍睹。特征工程方面我实践下来的经验是对销量预测最有用的特征有三类滞后特征过去7天、14天、30天的平均销量、最大销量、波动率日历特征星期几、是否月初、是否节假日、距离最近节假日的天数商品属性价格区间、品类、是否促销。一个需要特别留意的细节是滞后窗口的选择。窗口太短模型学不到周期性窗口太长会引入太多噪声。我建议先用画图的方式看销量序列是否有明显周期性再结合业务确定窗口。比如日用消耗品有7天周期就可以把窗口设成7、14、28天而不是随便拍脑袋。3.3 训练、评估和模型调参的实操记录模型选型上我第一次做这个项目用的XGBoost和LightGBM。原因很简单表格数据上这两个模型只要特征处理好效果基本不会差而且训练快、调参门槛低。如果你非要用深度学习可以考虑时序模型或者Transformer变体但效率上会低很多入门阶段没必要。训练配置有一个比较稳妥的基线80%数据做训练10%做验证10%做测试并且按照时间顺序切分不能随机打乱。这是时间序列任务最容易犯的错——随机切分会让模型偷看到未来数据。LightGBM里我会重点关注learning_rate、num_leaves、min_data_in_leaf这几个参数。初期先用默认参数跑一个baseline然后用Optuna做100次贝叶斯搜索目标函数就是验证集的RMSE。评估阶段不要只盯着一个指标。我习惯同时看RMSE、MAE和MAPE。RMSE对离群点敏感MAE更反映平均表现MAPE则能看出相对误差。如果MAPE在促销日附近飙得很高就说明模型对突发流量不敏感这时候需要增加促销相关的特征或者单独训练一个“促销日增量模型”。3.4 打包、API服务和监控模型训练完之后真正的AI工程才刚刚开始。我用MLflow把最优模型存成onnx格式这样部署时不用依赖完整Python环境推理速度也能快不少。然后用FastAPI包一个很简单的接口输入是SKU和预测日期范围输出是预测值。这一步要注意统一输入输出的数据校验不要等到线上跑挂了才发现字段名对不上。接着写Dockerfile。一个合格的Dockerfile不应该把整个训练环境全塞进去推理镜像只需要运行时依赖。多阶段构建时先用python:3.11-slim装依赖、把代码拷进去再在最终镜像里只保留app代码和模型文件。推荐镜像体积能从几个GB压到几百MB。部署方式上如果只有一台小服务器docker-compose配合一个简单的Nginx反向代理就够用。还需要加一个监控接口记录每次请求的延迟、输入特征分布、预测值分布。我当时是写一个简单的middleware把请求日志写到本地JSON文件再用Prometheus Grafana去采集展示。这不是花架子只要模型上线你就必须知道它有没有在变“笨”。一旦预测分布明显偏离训练期分布说明数据漂移已经发生需要重新评估模型了。4. 我在实操中踩过的坑与排查方法4.1 数据泄露最隐蔽的错误数据泄露在AI工程里属于那种“指标很漂亮、上线就完蛋”的坑。我在训练销售预测模型时做过一个骚操作直接用“当日真实销量”作为特征结果训练集RMSE接近0模型在测试集上却一塌糊涂。后来才反应过来预测未来销量时当天真实值根本还没有发生这就叫标签泄露。另一个容易踩的坑是特征工程中的滞后期特征使用到了未来信息。举个例子如果你用“未来7天平均销量”做滞后期特征模型训练时性能亮眼但线上根本拿不到这个数。排查这类问题的方法很简单做特征时严格按时间戳顺序执行保证每个样本的特征字段只包含该时刻之前的数据如果发现某个特征的线上缺失率很高优先怀疑它是不是用了未来信息。4.2 过拟合与欠拟合的工程判断很多新手一看到训练集损失低、测试集损失高就疯狂加正则化或Dropout。但问题往往不在模型复杂度而是数据划分不合理。比如训练集和验证集同分布程度差太远或者验证集太小、噪声太大导致评估指标剧烈波动。正确做法是先检查数据切分是否按时间/层级分层然后做多次交叉验证观察指标方差。如果确认过拟合再逐步调整先降低模型复杂度比如LightGBM减小num_leaves再增加正则化系数最后再用早停。欠拟合则是另一回事模型连训练集都学不好这时候加更多特征、增加训练轮数、提高模型容量才有意义。判断过拟合欠拟合不要只凭眼睛看曲线还得结合业务满意度——有时候模型效果已经足够好了再复杂化只是增加维护成本。4.3 实验管理混乱本地文件堆成山没有实验管理工具的时候我的目录长这样model_v1_final.pkl、model_v1_final_v2.pkl、model_真_final.pkl。后来某次模型回滚时我根本分不清哪个版本用了哪份数据、哪套参数只能凭文件名猜差点酿成线上事故。从那以后我把MLflow接进了所有项目每次实验自动记录代码版本、参数、指标和模型产物回滚的时候一键就能拉出历史版本。管理实验的另一个关键点是一开始就要把随机种子固定下来。不固定种子同参数跑两次结果都不一样调参时根本没法判断是参数的影响还是随机的波动。我的习惯是全局设置一个SEED42并在所有涉及随机数的地方都传入它。别小看这一步它能帮你省掉很多无谓的调试时间。4.4 上线后的模型漂移静默的杀手模型上线后常见的现象是一开始效果不错过了一个月指标慢慢下滑。很多人第一反应是模型不行了重新训练一遍就完事。但如果没有监控你可能根本不知道下滑是“什么时候开始”的更不知道是“数据变了”还是“业务变了”。我当时监控库存预测服务时设置了两个简单的告警一个是预测值的均值偏离训练期均值的幅度超过20%触发告警一个是真实销量回填后计算当日预测误差滚动7天平均绝对值超过阈值触发告警。后一个指标需要把预测结果落库等真实值出来再回填对比虽然麻烦但这是唯一能判断模型是否“还在状态”的方法。一旦触发告警不要急着重训先分析漂移来自哪个特征再决定是更新特征、重新标注还是彻底换模型架构。5. 从零到一的下一步还能做什么5.1 从单机走向分布式训练与推理当你习惯了单机训练模型下一步就是理解“为什么大模型要分布式训练”。这不是说你必须马上搭一个GPU集群而是要知道数据并行、模型并行、流水线并行这些概念。至少要学会用PyTorch的DistributedDataParallel跑一个多卡训练的小实验理解其中的通信开销、梯度同步逻辑。推理侧的工程化也从单机扩展到水平扩展。比如同一个模型服务部署多个副本前面加负载均衡配合Kubernetes的自动伸缩让服务在流量高峰时自动扩容、低谷时缩容。这些操作不是背命令而是理解背后的原理容器编排、资源配额、优雅退出。能把这一步走通你的AI工程能力已经超越不少“只会训练模型”的同行了。5.2 LLM应用工程化是新的必修课现在几乎所有AI工程岗位都会聊到LLM应用所以建议把传统ML和LLM应用都上手一遍。LLM的AI工程和传统ML工程最大的区别在于传统ML的“模型”是一个静态权重文件而LLM应用里模型是外部API你真正要工程化的是Prompt、知识库、上下文管理和流式输出。我自己做过一个RAG客服机器人踩了不少坑。文本切分切得不好检索出来的片段经常是半句话回答质量一塌糊涂向量化模型选得不合适中文语义匹配效果很差召回率上去了但精排没做好中间夹了很多无关片段。这些环节每个都要单独评测和调优。另外Prompt版本管理同样需要纳入Git和MLflow因为Prompt就是LLM应用的“代码”改一个字都可能影响最终效果。如果你能把库存预测这样的经典项目、RAG问答这样的LLM项目都完整跑过一遍AI工程这条线基本就立起来了。我个人的体会是真正的成长不在于看了多少论文、调了多少参数而在于亲手把一个又一个项目从零拉起、上线、维护然后踩一堆坑、爬起来再优化。这套“建立-验证-迭代”的节奏才是AI工程最核心的复利。 AI工程从零开始：模型部署与监控全链路实战指南
1. 先搞清楚AI工程到底在解决什么问题1.1 它和算法岗、数据岗有什么区别很多人一看到“AI工程”这四个字下意识会觉得这就是调模型、训练神经网络。实际情况完全不同。AI工程要解决的不是“怎么把模型精度提上去”而是“怎么让一个模型稳定、高效、可维护地跑在生产环境里并且持续创造业务价值”。模型只是中间产物数据管道、特征存储、训练框架、评估体系、部署服务、监控告警、模型迭代这一整条链路才是AI工程的核心。如果你去看招聘JD算法岗通常要求“熟悉Transformer、精通PyTorch、有顶会论文”而AI工程岗写的大多是“熟悉Kubernetes、有CI/CD经验、懂得模型监控和A/B测试”。一句话总结算法岗的目标是“造出一个好模型”AI工程的目标是“把模型变成一项可靠的服务”。这两个方向有交叉但思维方式差异很大。从零开始的人如果一上来就死磕网络结构忽略了工程化能力反而容易把自己困在“训练demo很行、一上生产就崩”的怪圈里。1.2 为什么“从零开始”是个优势我面试过不少候选人科班出身的往往一上来就聊模型结构、损失函数但问到“训练数据是怎么产生的数据分布有没有偏移服务挂在K8s上怎么滚动更新”就沉默了。反而是那些从零开始、一路自己折腾出来的工程师能把这套链路讲得头头是道。所以我一直觉得“from scratch”不是劣势反而是一个很好的起点。因为没有历史包袱你不会被“我们之前一直这么做的”这种惯性束缚。你会从第一行代码开始构建自己的工程体系每一步都知道为什么要这么做。这种“知其所以然”的能力在AI工程这个领域比背熟某个框架的API值钱得多。学AI工程本质上就是训练自己“用工程手段解决模型落地问题”的肌肉记忆而这套肌肉记忆完全可以依靠一个又一个端到端项目慢慢长出来。2. 从零开始的技术栈搭建先学什么、后学什么2.1 编程基础Python只是入场券别急着学PyTorch先把Python基础打牢。我说的基础不是“会写for循环”而是能熟练处理模块化代码、异常处理、类型注解、装饰器、上下文管理器这些日常工程特性。AI工程里你写的优雅代码大概率会在生产环境里跑很久不是你训练完就扔的玩具脚本。用Poetry或uv管理项目依赖而不是把几十个包全部塞进全局环境这是第一个需要养成的工程习惯。除了Python至少还要掌握三样东西Git、Docker、Linux命令行。Git不只是“commit/push”要会分支管理、rebase和解决冲突Docker要能写出干净的多阶段构建镜像理解为什么生产环境不用pip install而是构建镜像Linux至少要熟练操作日志查看、进程管理、端口排查、crontab定时任务。这些技能我当年都是被生产事故逼着学会的——某次模型服务半夜挂了连服务器都登录不进去那一刻才发现基本功有多重要。2.2 机器学习与深度学习原理学到“够用”就好学习ML/DL原理要把握一个度不需要啃完花书但也不能只调包。我建议从线性回归、逻辑回归、决策树这些经典模型开始把损失函数、梯度下降、正则化这些核心概念吃透。然后进入神经网络理解反向传播、BatchNorm、Dropout、学习率调度的原理。框架用PyTorch就够TensorFlow也能学不过现在PyTorch的社区生态更活跃。这里有一条少走弯路的经验学原理的时候一定要动手把一个小模型的训练循环自己写一遍。比如用纯Python和NumPy实现一个两层神经网络在MNIST上跑到90%的准确率然后换成PyTorch实现同样的模型。你会发现框架替你做了多少事也会理解为什么工程上要关注梯度爆炸、学习率过大、数据归一化这些细节。这类基础训练看似枯燥但在后面排查模型问题时特别有用——你不会看到一个NaN loss就束手无策。2.3 工程化三件套数据、实验、部署从零走向AI工程绕不开三座大山数据处理、实验管理、模型部署。数据处理至少要掌握Pandas、SQL和一种ETL工具。很多刚入门的同学喜欢用Pandas处理一切但上了生产数据动不动上千万行就必须学会用SQL在数据库层面做聚合过滤再用Spark或Dask做分布式处理。特征工程更是AI工程里最吃经验的部分后面我用一个具体项目展开。实验管理这块很多人一开始觉得“不就是记录一下参数和指标吗”直到同时跑几十组实验模型文件乱成一锅粥才知道MLflow或者WB这类工具的价值。我在本地一般用MLflow因为它开源、轻量、能自托管训练完的模型还能直接注册进Model Registry方便后续部署。模型部署以前是写一个Flask API就完事现在标准做法是用FastAPI封装推理接口用Docker打包镜像推到镜像仓库后用Kubernetes或轻量的docker-compose做服务编排。如果你只想从零开始先跑通那最轻的方式是直接用一个成熟的推理服务框架比如Triton或TorchServe然后再去理解它们内部的批处理、动态batching、显存管理逻辑。3. 用一个端到端项目验证全链路3.1 项目选题从“库存预测”到“知识库问答”与其零零散散看教程不如直接做一个覆盖全链路的项目。我推荐的入门项目是“电商商品库存预测”。原因有二第一业务场景足够清晰——预测未来N天的销量评估指标是RMSE人人都能看懂。第二它天然需要你处理时间序列数据、做滑窗特征、处理节假日影响最后还要把模型包成一个可以按时调用的API服务。如果你对大模型应用更感兴趣也可以做“基于RAG的私人知识库问答”。这个项目的工程链更长文档解析、文本切分、向量化、检索、重排、大模型调用、流式输出。但从零开始的阶段我更建议先做库存预测这类传统机器学习项目。因为它简单、快、容易闭环你能在几天内体会“训练-评估-部署-反馈”的完整循环。等这条链路跑熟了再升级到RAG项目你才不会在工程细节里迷失。3.2 数据处理与特征工程实操要点这个项目的数据可以自己造也可以用公开的电商销量数据。假设你有一张订单表字段包括order_date、sku_id、category、sales_qty、price。第一步不是建模而是做数据审视检查缺失值、异常值、时间跨度是否足够。时间序列项目尤其要小心数据泄露比如你用了未来时间的信息做特征会让线上效果惨不忍睹。特征工程方面我实践下来的经验是对销量预测最有用的特征有三类滞后特征过去7天、14天、30天的平均销量、最大销量、波动率日历特征星期几、是否月初、是否节假日、距离最近节假日的天数商品属性价格区间、品类、是否促销。一个需要特别留意的细节是滞后窗口的选择。窗口太短模型学不到周期性窗口太长会引入太多噪声。我建议先用画图的方式看销量序列是否有明显周期性再结合业务确定窗口。比如日用消耗品有7天周期就可以把窗口设成7、14、28天而不是随便拍脑袋。3.3 训练、评估和模型调参的实操记录模型选型上我第一次做这个项目用的XGBoost和LightGBM。原因很简单表格数据上这两个模型只要特征处理好效果基本不会差而且训练快、调参门槛低。如果你非要用深度学习可以考虑时序模型或者Transformer变体但效率上会低很多入门阶段没必要。训练配置有一个比较稳妥的基线80%数据做训练10%做验证10%做测试并且按照时间顺序切分不能随机打乱。这是时间序列任务最容易犯的错——随机切分会让模型偷看到未来数据。LightGBM里我会重点关注learning_rate、num_leaves、min_data_in_leaf这几个参数。初期先用默认参数跑一个baseline然后用Optuna做100次贝叶斯搜索目标函数就是验证集的RMSE。评估阶段不要只盯着一个指标。我习惯同时看RMSE、MAE和MAPE。RMSE对离群点敏感MAE更反映平均表现MAPE则能看出相对误差。如果MAPE在促销日附近飙得很高就说明模型对突发流量不敏感这时候需要增加促销相关的特征或者单独训练一个“促销日增量模型”。3.4 打包、API服务和监控模型训练完之后真正的AI工程才刚刚开始。我用MLflow把最优模型存成onnx格式这样部署时不用依赖完整Python环境推理速度也能快不少。然后用FastAPI包一个很简单的接口输入是SKU和预测日期范围输出是预测值。这一步要注意统一输入输出的数据校验不要等到线上跑挂了才发现字段名对不上。接着写Dockerfile。一个合格的Dockerfile不应该把整个训练环境全塞进去推理镜像只需要运行时依赖。多阶段构建时先用python:3.11-slim装依赖、把代码拷进去再在最终镜像里只保留app代码和模型文件。推荐镜像体积能从几个GB压到几百MB。部署方式上如果只有一台小服务器docker-compose配合一个简单的Nginx反向代理就够用。还需要加一个监控接口记录每次请求的延迟、输入特征分布、预测值分布。我当时是写一个简单的middleware把请求日志写到本地JSON文件再用Prometheus Grafana去采集展示。这不是花架子只要模型上线你就必须知道它有没有在变“笨”。一旦预测分布明显偏离训练期分布说明数据漂移已经发生需要重新评估模型了。4. 我在实操中踩过的坑与排查方法4.1 数据泄露最隐蔽的错误数据泄露在AI工程里属于那种“指标很漂亮、上线就完蛋”的坑。我在训练销售预测模型时做过一个骚操作直接用“当日真实销量”作为特征结果训练集RMSE接近0模型在测试集上却一塌糊涂。后来才反应过来预测未来销量时当天真实值根本还没有发生这就叫标签泄露。另一个容易踩的坑是特征工程中的滞后期特征使用到了未来信息。举个例子如果你用“未来7天平均销量”做滞后期特征模型训练时性能亮眼但线上根本拿不到这个数。排查这类问题的方法很简单做特征时严格按时间戳顺序执行保证每个样本的特征字段只包含该时刻之前的数据如果发现某个特征的线上缺失率很高优先怀疑它是不是用了未来信息。4.2 过拟合与欠拟合的工程判断很多新手一看到训练集损失低、测试集损失高就疯狂加正则化或Dropout。但问题往往不在模型复杂度而是数据划分不合理。比如训练集和验证集同分布程度差太远或者验证集太小、噪声太大导致评估指标剧烈波动。正确做法是先检查数据切分是否按时间/层级分层然后做多次交叉验证观察指标方差。如果确认过拟合再逐步调整先降低模型复杂度比如LightGBM减小num_leaves再增加正则化系数最后再用早停。欠拟合则是另一回事模型连训练集都学不好这时候加更多特征、增加训练轮数、提高模型容量才有意义。判断过拟合欠拟合不要只凭眼睛看曲线还得结合业务满意度——有时候模型效果已经足够好了再复杂化只是增加维护成本。4.3 实验管理混乱本地文件堆成山没有实验管理工具的时候我的目录长这样model_v1_final.pkl、model_v1_final_v2.pkl、model_真_final.pkl。后来某次模型回滚时我根本分不清哪个版本用了哪份数据、哪套参数只能凭文件名猜差点酿成线上事故。从那以后我把MLflow接进了所有项目每次实验自动记录代码版本、参数、指标和模型产物回滚的时候一键就能拉出历史版本。管理实验的另一个关键点是一开始就要把随机种子固定下来。不固定种子同参数跑两次结果都不一样调参时根本没法判断是参数的影响还是随机的波动。我的习惯是全局设置一个SEED42并在所有涉及随机数的地方都传入它。别小看这一步它能帮你省掉很多无谓的调试时间。4.4 上线后的模型漂移静默的杀手模型上线后常见的现象是一开始效果不错过了一个月指标慢慢下滑。很多人第一反应是模型不行了重新训练一遍就完事。但如果没有监控你可能根本不知道下滑是“什么时候开始”的更不知道是“数据变了”还是“业务变了”。我当时监控库存预测服务时设置了两个简单的告警一个是预测值的均值偏离训练期均值的幅度超过20%触发告警一个是真实销量回填后计算当日预测误差滚动7天平均绝对值超过阈值触发告警。后一个指标需要把预测结果落库等真实值出来再回填对比虽然麻烦但这是唯一能判断模型是否“还在状态”的方法。一旦触发告警不要急着重训先分析漂移来自哪个特征再决定是更新特征、重新标注还是彻底换模型架构。5. 从零到一的下一步还能做什么5.1 从单机走向分布式训练与推理当你习惯了单机训练模型下一步就是理解“为什么大模型要分布式训练”。这不是说你必须马上搭一个GPU集群而是要知道数据并行、模型并行、流水线并行这些概念。至少要学会用PyTorch的DistributedDataParallel跑一个多卡训练的小实验理解其中的通信开销、梯度同步逻辑。推理侧的工程化也从单机扩展到水平扩展。比如同一个模型服务部署多个副本前面加负载均衡配合Kubernetes的自动伸缩让服务在流量高峰时自动扩容、低谷时缩容。这些操作不是背命令而是理解背后的原理容器编排、资源配额、优雅退出。能把这一步走通你的AI工程能力已经超越不少“只会训练模型”的同行了。5.2 LLM应用工程化是新的必修课现在几乎所有AI工程岗位都会聊到LLM应用所以建议把传统ML和LLM应用都上手一遍。LLM的AI工程和传统ML工程最大的区别在于传统ML的“模型”是一个静态权重文件而LLM应用里模型是外部API你真正要工程化的是Prompt、知识库、上下文管理和流式输出。我自己做过一个RAG客服机器人踩了不少坑。文本切分切得不好检索出来的片段经常是半句话回答质量一塌糊涂向量化模型选得不合适中文语义匹配效果很差召回率上去了但精排没做好中间夹了很多无关片段。这些环节每个都要单独评测和调优。另外Prompt版本管理同样需要纳入Git和MLflow因为Prompt就是LLM应用的“代码”改一个字都可能影响最终效果。如果你能把库存预测这样的经典项目、RAG问答这样的LLM项目都完整跑过一遍AI工程这条线基本就立起来了。我个人的体会是真正的成长不在于看了多少论文、调了多少参数而在于亲手把一个又一个项目从零拉起、上线、维护然后踩一堆坑、爬起来再优化。这套“建立-验证-迭代”的节奏才是AI工程最核心的复利。