入行AI工程快五年我越来越发现一个很反直觉的现象很多人的项目叫ai-engineering但实际做的是把某个开源模型跑通调个参数然后写个API包起来。这没错但它离工程还很远。真正的AI工程是从零开始把一个模糊的问题变成一套能持续迭代、能监控、能回溯、能扛住线上流量的系统。这套东西没有现成的速成课只能靠踩坑。我想把去年到今年做的一个从零搭建AI工程项目的完整过程整理出来题目就叫ai-engineering-from-scratch——不是教你怎么调模型而是完整走一遍需求分析、数据管道、模型训练、部署监控的全程告诉你哪些环节最容易被忽略哪些地方值得花时间。这篇内容适合谁适合已经会写Python、跑过几个notebook但没正经做过生产级AI系统的开发者也适合刚带团队做AI项目的技术负责人——你会看到很多看文档永远学不到的边界问题。1. 先别碰代码需求边界和评价指标才是真正的起点1.1 一个模糊需求带来的灾难很多人拿到需求就急着找模型这恰恰是AI工程里最致命的动作。我一开始接手的是一个做一个内容标签系统的需求。听起来很简单给文章打标签。但如果就按字面做你会在三个月后陷入无尽的返工。为什么因为标签的定义不清。是要预测文章的主分类还是提取关键实体还是判别写作风格评价标准是什么准确率90%是用什么口径算的正负样本比例是多少错误标签的代价是多少这些问题没定清楚后续所有技术选型都是空中楼阁。我用了一个星期拉着业务方一条一条把需求掰碎最后落成一张对照表需求问题模糊说法工程化定义任务类型给文章打标签多标签分类标签集为预定义的32个业务主题输出粒度标签每篇文章返回前3个标签附置信度分数错误容忍不能错太多线上允许标签预测错误率为15%以内但核心主题漏判率不得高于3%响应要求要快P99响应时间小于300ms离线T1补全数据范围所有文章仅中文原创文章排除转载和空内容页这张表救了我。因为后来算法选型、阈值设定、资源预算全是从这里倒推出来的。如果跳过这步你连模型不行和需求没说清都分不开。1.2 评价指标不是accuracy就行第二件容易糊弄的事是评价指标。很多教程告诉你用准确率、召回率、F1但到了真实场景你必须自己设计一个业务代价矩阵。比如标签系统漏掉核心主题比多打两个无关标签严重得多。这时你的离线评估就应该是核心主题的召回率达到95%而不是笼统的F1。我常用的方法是先建立一个最小的错误样本池——把业务方认可的正确标签和模型预测差异最大的50条case拿出来人工看。这比任何统计指标都先暴露问题。实测下来这个人工审计步骤能帮你省下至少两周的调参时间。因为大厂的公开标准不等于你的业务标准你的数据分布和人家不一样指标的绝对值没有意义相对提升方向和bad case才是核心。1.3 系统边界图画出你的AI系统要去哪儿在写任何依赖之前手绘一张系统边界图。我所谓边界不是架构图而是回答四个问题输入从哪里来存在哪里如何更新模型的推理是一次性批量还是实时在线预测结果如何反馈给业务系统模型多久需要重训谁负责触发我是在第二个项目才学乖的。第一个项目没画边界图导致数据管道和推理服务耦合在一个服务里模型一更新就要重新部署整个API差点把线上搞挂。从零做AI工程最值钱的动作就是——让数据、训练、推理、反馈四条线在逻辑上完全解耦。2. 数据管道的搭建从原始日志到可用训练集的系统工程2.1 别再手动跑清洗脚本数据管道是我见过最多人临时凑合的地方。最初我用一堆Python脚本手工处理CSV和JSON每次重新跑一遍先清洗再切分最后手动上传到训练环境。听起来还行但问题在于清洗逻辑改了历史版本不可追溯训练集里混进了一部分脏数据模型悄悄学坏数据处理和特征工程之间没有明确接口换个人接手完全看不懂。后来我统一改用DAG方式组织数据管道我用的是Airflow也可以用Prefect或Dagster看团队熟悉度。关键不是工具而是把每个环节拆成独立的、有版本的任务节点。我对数据管道的标准流程是抽取从多个数据源拉取原始数据每份数据带上来源标记和采集时间校验做非空校验、类型校验、唯一性校验比如文本长度、非法字符、重复文章ID清洗去重、去HTML标签、规范编码、把繁体转为简体如果业务有需要结构化把原始字段映射成统一的schema比如content_id, title, tags, publish_time, source写版本快照每个批次生成一个数据版本号日期hash存入数据湖。这个流水线跑通后我的数据质量问题大幅减少。有个细节每次清洗规则变更我坚持重新生成完整数据集而不是只处理增量。因为模型的离线评估必须在全量、一致的数据上进行否则你连这版模型为什么比上版差0.5个点都说不清。2.2 数据版本管理让模型可以回溯到当时的宇宙训练数据和代码一样需要版本管理。Git管代码但管不了几个GB的数据。很多人以为只要保存数据文件就行其实你还需要保存三个东西数据的schema定义样本的ID列表指出哪些样本进了训练集数据生成规则的版本号比如清洗脚本和特征定义。我推荐用DVCData Version Control它能和Git联动每次训练都能通过commit回溯到当时的数据集和特征版本。其实不用DVC的话也可以用最老土的方式每次训练前把配置文件和data lineage记录写进MLflow后面会提到只要保证代码配置数据版本三者锁定。举一个真实教训有一次我改进了一个特征结果模型效果提升2%。但两个月后数据源的字段定义变了特特征分布跟着漂移模型效果掉了8%。当时如果没记录数据版本我根本不知道是特征失效还是数据分布变了。有了版本管理后我切回旧版本数据重跑一次立刻定位到了字段含义变更导致特征失效——只花了半天。2.3 特征工程别做太多花哨的设计很多入门教程喜欢教你构造几十个复杂特征好像特征越多模型越聪明。实际工程中特征设计的第一原则是可解释、可监控、可回填。特别是引入外部数据或实时特征时你要问自己三个问题这个特征在模型上线那一刻还能获取吗如果获取失败默认值是否合理特征值出现异常比如超出正常区间时系统能否告警我曾在标签项目里做了一个文章时效性特征用发布日期距离当前日期的天数做衰减。离线测试时很有用但上线后发现很大一部分文章的发布时间字段是缺失的这个特征全部落到了默认值模型预测分布直接偏移。后来我在特征工程里加了一个覆盖率自动统计——每次训练前检查每个特征的覆盖率和取值分布低于阈值的特征直接丢弃或做特殊标记。这套机制让我的特征工程安全很多。这里想提醒AI工程里80%的收益往往来自干净的文本、合理的目标定义和稳定的数据管道而不是复杂的特征组合。我的原则是先用简单特征跑通一个强baseline再逐步加复杂度并且每次加特征都要在固定验证集上做显著性检验不要凭感觉。3. 模型训练与评估实验管理、资源调度与性能调优3.1 实验管理从Excel记录到MLflow你是不是也用文件名记录过实验比如bert_final_v3_fixed_20231001.ckpt。这个做法如果只是自己小范围试跑还没什么但项目一多你会彻底崩溃——参数是哪个学习率数据是哪一版结果在哪次运行里我强烈建议从第一天就接入实验管理工具我用的是MLflow开源的部署起来很轻。你只需要在训练脚本里加几行代码记录超参数、指标、模型artifact和data version。十几个实验之后你就能用表格视图横向对比哪个参数组合最优一目了然。一个常规的记录配置大概长这样import mlflow mlflow.set_experiment(content-tagging) with mlflow.start_run(run_namebert-base-chinese_20250401): mlflow.log_param(model_name, bert-base-chinese) mlflow.log_param(learning_rate, 2e-5) mlflow.log_param(batch_size, 32) mlflow.log_param(data_version, 20250401_batch_v3) mlflow.log_metric(val_macro_f1, 0.86) mlflow.log_artifact(model.pt, artifact_pathmodel)有了这个基础你才敢做大规模超参搜索。不然跑几十组实验最后都不知道哪个结果对应哪个配置等于白跑。我见过一个团队用CSV管理实验线上模型出问题时翻了三天的记录才找到当时的训练样本集。这不是技术问题是工程纪律问题。3.2 GPU资源调度算力也要钱别做败家子从零搭AI工程很少有人一开始就考虑资源成本。等你的训练任务开始排队、GPU利用率上不去、账单猛涨的时候你就知道这块有多重要。我的经验是分两个层面单机多卡场景下用PyTorch自带的DistributedDataParallelDDP就能解决大部分需求配合 accelerate 库可以显著减少样板代码。多机场景再考虑Ray或者SLURM但我个人建议小团队先别上分布式——分布式引入的通信开销和故障排查成本远大于你的中期收益。先把单机训练吃透包括用torch.utils.data.DataLoader的多进程加载数据num_workers设为CPU核数的一半避免CPU成为瓶颈混合精度训练AMP用torch.cuda.amp.autocast在N卡上能获得接近两倍的训练速度梯度累积当你显存不够的时候用scheduler.step()配accumulation_steps比强行开大batch好得多。另外我强烈建议在训练前做一个快速的小规模冒烟测试——用几千条样本跑一两个step确认loss正常下降、模型能保存能加载再启动全量训练。这种习惯能避免你因为数据管道里的一个空值白烧了一整晚GPU。3.3 评估指标的三重校验离线、在线、样本审计很多项目上线前只看一个AUC或者F1这是一个隐藏的地雷。我总结了一个三重校验流程第一重离线评估。在固定的验证集上跑指标。但这个验证集要保证和训练集完全隔离并且覆盖不同时间段或来源的数据。第二重在线灰度。把模型接上线但只放5%的流量和旧模型对比业务指标比如点击率、业务方满意率、人工修正率持续观察一段时间。这里要特别注意AI模型的预测结果对业务指标的影响往往是滞后的所以灰度期不要只跑一天至少一周。第三重bad case审计。这是最有效的。每周抽100条线上预测结果人工过一遍统计模型失误的类型。你会发现很多有趣的问题比如模型总把长文分析报告预测为新闻因为训练数据里该类别的标题特征不够明显。这种case统计比任何指标都更直接地指导下一步优化方向。我经常用这个表格来汇总审计结果bad case类型占比可能原因行动项核心主题A被预测为B32%A类训练样本过少扩充A类数据加数据增强长文本截断丢失关键信息27%输入长度限制512改用RoBERTa等长文本模型或加摘要机制新词/专业术语预测错误18%词表覆盖不足动态扩充词表这样每周迭代模型的业务价值才真正体现。否则指标再好看业务方也会觉得AI不靠谱。4. 部署与服务化从推理脚本到高可用API的那些细节4.1 模型封装不要直接把PyTorch模型丢进FastAPI许多从零起步的AI工程死在这一步训练完模型写个FastAPI接口model(input)返回结果感觉大功告成。然后流量一高就超时、显存溢出、推理结果偶尔异常。正确的做法是把推理逻辑拆成两层第一层模型服务层。负责加载模型权重、预处理、后处理暴露一个内部接口可以是Python函数或gRPC第二层API接入层。负责鉴权、限流、缓存、日志再给业务方提供HTTP接口。我在项目里用的是一个非常经典的三明治结构Client - Nginx - FastAPI(接入层) - TorchServe/self-hosted inference worker(模型层) - Model为什么不用单一FastAPI应用同时做HTTP处理和模型推理因为两者生命周期不同。HTTP层希望快速热更新、多实例伸缩模型层希望保持常驻显存、复用GPU资源。混在一起每次发布模型都要重启整个服务而且高并发时Python的GIL会卡在推理上。我的具体做法是使用ONNX Runtime或TensorRT对模型进行加速如果模型支持同时把前处理和标签映射逻辑用纯Python实现放进worker里worker采用进程池每个进程加载模型副本通过共享队列接收推理请求接入层用FastAPI做路由、鉴权、响应封装再通过Redis做一个进程间请求队列缓冲峰值流量。这个结构看起来重但一旦跑起来非常稳。我后来遇到突发流量API层横向扩容模型worker层定点扩机器完全互不干扰。4.2 推理性能优化量化、批处理、缓存三步走线上推理性能是AI工程的老大难。我从第一次上线到最终稳定大概经历了三轮优化第一轮把模型从FP32转成FP16或INT8。如果你的模型是在NVIDIA GPU上用PyTorch训练的用torch.compile配合half()可能就能快30%以上。如果你们接受轻微精度损失使用ONNX Runtime GPUExecutionProvider做INT8量化在实体标签任务上我只损失了0.5个点F1但延迟降低了55%。这是性价比最高的一步。第二轮引入动态批处理。在高并发场景下单个请求单独推理非常浪费GPU并行能力。我实现了一个简单的批处理器把到达请求在50ms窗口内攒成一个batch统一推理吞吐量提升非常明显。实现时要注意最大batch值和最长等待时间这两个参数需要根据响应时间要求做压测。第三轮给稳定结果加缓存。对于内容标签这类任务同一篇文章可能被多次请求比如不同用户查看文章详情页都会请求标签。我在Redis里加了一套缓存key是content_id模型版本号TTL为1天。实测命中率达到30%以上这部分请求完全不需要走模型P99延迟直接降到了30ms以下。这里有个容易踩的坑模型版本更新后缓存必须失效。我给缓存key加上模型版本号同时发布模型后主动清理旧版缓存。这个细节如果漏了会造成线上出现新旧标签混用的诡异现象。4.3 监控与告警模型也会生病模型上线不是终点而是运维的起点。你需要监控的不只是CPU和内存还有数据分布和模型自身的健康度。我第一次上线时只监控了CPU利用率和API错误率结果有一天模型突然大量预测无法识别查了半天发现是上游数据源改了字段格式导致特征全部为空。如果当时监控了特征覆盖率问题在第一个请求进来时就能发现。我现在会为每个模型服务配置四类指标基础设施指标GPU利用率、显存占用、CPU使用率、内存吞吐指标QPS、响应时间P50/P95/P99、错误率数据质量指标输入特征覆盖率、缺失值比例、关键特征的最大最小值/分布变化PSI业务效果指标预测结果分布各标签的输出占比是否偏移、人工修正率等。用Prometheus Grafana做展示用Alertmanager做规则告警。告警规则不要设太宽松否则天天半夜吵醒你。我的建议是先静默观察一周设定一条特征覆盖率低于90%启动P1告警和平均置信度连续30分钟低于阈值启动P2告警这两条能覆盖最常见的模型病因。5. 从零开始的经验清单我踩过坑之后沉淀的原则5.1 工程和算法的比例至少是7:3做了几个项目后我发现一个普遍规律一个AI系统真正花的精力大概只有30%在算法和模型上剩下70%都在数据、管道、部署、监控、质量保障上。很多从零开始的团队不习惯这个比例总想着找个更厉害的模型一劳永逸。实际上模型升级带来的收益远小于数据管道稳定和数据质量提升带来的收益。我自己的一个实操建议每周固定留一天做管道巡检看看数据任务有没有失败、数据 schema 有没有变化、特征分布有没有偏移。这就像健身房里的核心训练——看起来效果慢但最关键的是防止未来受伤。5.2 能跑和可维护是两种系统有一个判断标准我很喜欢如果一个AI项目在你休假一周后仍然可以稳定运行而且任何新人都能依据文档半小时内找到上线的模型版本和训练数据那才是合格的工程化系统。否则它只是能跑的脚本集合。为了实现这个目标我坚持三件小事每次训练结束把实验记录、数据版本、模型文件、评估报告打包留存每个上线模型都附一份模型说明写明输入schema、输出schema、已知限制和回滚方案数据管道代码和模型代码放在同一个仓库统一使用CI做代码检查和测试。这些事很容易被当成额外工作量而延期。但以我的经验它们不是装饰而是救命稻草。几次线上事故全靠随时能回滚、能快速定位到历史版本才没造成灾难。5.3 最后想分享的一点允许自己重新发明轮子一次网上有太多现成框架和模板但你还是要从零走一遍。为什么因为你只有自己亲手搭过数据管道、遇到过版本错乱、扛过线上服务崩溃才真正理解那些框架解决了什么问题。我在做ai-engineering-from-scratch这几个项目时早期坚持用最朴素的工具Python、SQLite、FastAPI、Docker不引入任何重量级框架。后来才逐步引入Airflow、MLflow、DVC、Prometheus。每一次升级都是因为我知道了痛点的具体位置而不是为了追新。这样反而学得最扎实。如果你也打算从零开始做AI工程我的建议是挑一个熟悉的小业务场景把从需求定义到上线监控的完整闭环走一遍。不要贪大哪怕只是给内部文档做关键词提取项目周期控制在两个月内。走完这个闭环你收获的不是会调用某个模型API而是一整套判断和解决问题的能力——这才是AI工程的核心。