先交代一个背景我并不是搞算法研究出身之前更多是在做后端和系统集成的工作后来因为项目需要被迫接手了一条AI功能的生产链路。当时最直接的感受是网上铺天盖地的教程都在讲怎么调用现成模型、怎么跑通一个notebook可一旦涉及到工程化落地——从数据准备、训练复现、模型版本管理到部署监控——几乎全靠自己蹚。那段时间我一边查文档一边拼碎片最后靠着一套“ai-engineering-from-scratch”的完整路径把整个AI项目从零搭了起来。这篇文章就是把这套路径里最关键的东西拆开讲清楚如果你是刚接触AI工程、或者被“模型能跑但项目落不了地”卡住的朋友按照这条路线走能省下大量盲目试错的时间。很多人一听到“AI工程”就以为要先把数学推导啃一遍、把Transformer源码逐行手写一遍这其实是个误区。工程化落地和算法研究是两套逻辑。算法研究追求的是模型效果的极限而AI工程追求的是在可控成本、可维护、可复现的前提下把模型稳定地跑进业务里。所以“from-scratch”并不意味着从微积分开始而是从一条完整生产链路的底层开始环境怎么搭、数据怎么管、训练怎么做、模型怎么发版、线上怎么监控。这一整套流程走通之后你会发现AI工程的核心能力其实是“工程能力AI思维”的组合而不是简单的写模型代码。1. 为什么我建议从零自建一条AI工程链路1.1 框架教程不会告诉你的“中间地带”日常看到的教程通常分两类一类是上手型帮你把预训练模型加载出来、输入一段文本、输出一个结果看起来很爽但生产环境里根本不够用另一类是论文型深入讲模型架构和数学原理可把你扔到真实的脏数据、不稳定的GPU环境、多机协作场景里依然无从下手。真正的AI项目卡点几乎都集中在这两类教程中间的灰色地带数据版本怎么管理、训练脚本怎么组织、模型换了一版如何回滚、推理服务怎么应对突发的流量抖动。这些内容在官方文档里散落各处没人帮你串成体系。所以我当时做了一个决定不以“跑通模型”为目标而是以“上线一个完整服务”为目标从零把全链路搭一遍每个环节都亲手做一次。1.2 全链路自建的收益踩坑免疫自建全链路的直接收益就是踩坑经验。你可能觉得“用别人封装好的平台不就行了”但从学习角度讲封装平台把最关键的错误隐藏了。你用别人家的AutoML平台跑通一个模型、点击部署完成整个流程里真正暴露出来的问题数据泄露、样本分布偏移、版本错乱都被抹平了等你自己写代码上线时依然一脸懵。而自建链路时每一步的失败都会给你留下印象——比如你会在某次训练时发现验证集指标挺好、线上A/B测试却一塌糊涂之后你就知道了离线评测和线上分布之间的坑在哪里。这类经验没法速成只能通过亲手踩一遍来建立直觉。1.3 明确边界什么算“从零”什么不算为了避免有人觉得“没手写梯度下降不算从零”我得先划好边界。在我看来AI工程意义上的from-scratch指的是不依赖任何一体化黑盒平台所有核心环节的技术选型、脚本搭建、服务部署都由自己掌控。你依然可以使用深度学习框架PyTorch、TensorFlow、依然可以使用预训练模型但这就像是做菜时使用基础调料而不是买料理包流程和配比在你手里。这个边界很重要因为它把学习重心放在“理解系统是怎么协同工作”上而不是重复造轮子。2. 学习路线总览先建骨架再填血肉2.1 核心知识模块拆解“ai-engineering-from-scratch”的学习路径我把它拆成五个大模块数据处理、模型训练、实验管理、服务部署、监控运维。这五个模块不是独立的而是像一条生产流水线前序的输出就是后续的输入。数据处理解决的是“喂给模型什么”模型训练解决的是“模型怎么学”实验管理解决的是“怎么确定现在的模型比上一个好”服务部署解决的是“模型怎么对外提供能力”监控运维解决的是“线上模型什么时候该更新”。很多人一上来就扑向模型训练天天调参却忽略了数据质量和实验管理的体系建设。但以我实际做过的项目来看前两个模块才决定了项目的上限。一个脏乱差的数据集配上精心调参的模型效果必然不如一个干净、分布合理的数据集配上普通的模型。而实验管理如果做不好你今天试了一个learning rate效果不错明天换个初始化又跑了一遍最后根本分不清哪个配置对应哪个结果项目必然失控。2.2 推荐的技术栈基线技术栈的选择不需要追求最流行但要保证生态成熟、社区活跃、遇到问题能搜到答案。我自己的基线是这样的环节选中方案为什么选它深度学习框架PyTorch动态图对调试友好社区资源最丰富数据处理Pandas Arrow中小规模数据够用上手成本低实验追踪MLflow轻量、自托管方便能同时管模型和指标模型服务FastAPI TorchServeFastAPI做接入层TorchServe管模型生命周期容器化Docker Docker Compose部署迁移成本低环境一致性有保障监控Prometheus Grafana开源标配自定义指标方便这套组合的好处是每个环节都是可替换的。你学会之后即使换公司换团队底层逻辑也不会变只是换了个工具壳。我在选型时反复权衡过“要不要上Kubernetes”后来决定先不用因为单机或几台机器用Docker Compose足够过早引入编排系统只会增加学习负担。等真正遇到多机部署和自动扩容需求时再演进也不迟。2.3 时间和精力投入的合理配比如果给你三个月业余时间建议这样分配第一月主攻数据和训练脚本第二月主攻实验管理和模型优化第三月主攻部署和监控。前一个月花费的时间占比最大因为数据处理和训练脚本是地基后阶段接触的东西其实更偏向传统后端知识上手会越来越快。这个配比可能和直觉相反但非常关键。很多新手把70%精力放在“把准确率提高一个点”上结果到了部署环节完全陌生上线时发现模型输出格式没设计好、请求超时处理没做前功尽弃。3. 实操从零搭一条文本分类生产链路3.1 项目背景与数据准备我用一个“消费者投诉文本自动分类”的小项目来走全流程。目标是把用户提交的投诉文本自动分到“物流问题”“产品质量”“退换货”“服务态度”等几个预定义类别。这个项目难点的核心在数据上原始数据非常不均衡物流问题的样本量是退换货的三倍以上而且同样的意思在不同用户那里表达差异极大比如“东西到了就坏了”和“收到货之后发现箱子跟被踩过一样”都属于产品质量问题但字面相似度很低。数据处理这一步我做了三件事去重、清洗、划分。去重不只是去掉完全重复的文本还做了近似去重用SimHash把相似度高于阈值的长文本聚到一起。清洗做了一些行业相关的词表归一化比如“快递”“物流”“配送”这类近义词通过同义词替换让模型更好学。划分的时候特别注意了“按时间切分”而不是“随机切分”——因为线上数据的分布会随时间变化如果训练集和验证集来自同一时间段模型过拟合到时间段特征的风险会很高。我把前80%时间段的样本作为训练集后20%作为验证集这样评测出来的指标才更接近线上表现。import pandas as pd from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics import classification_report # 模拟数据加载 df pd.read_csv(complaints.csv) df[text_clean] df[complaint_text].str.replace(rhttp\S|\S, , regexTrue) # 时间切分而非随机切分 cutoff df[created_at].quantile(0.8) train_df df[df[created_at] cutoff] val_df df[df[created_at] cutoff]3.2 训练脚本的组织结构训练脚本不建议写成一个超大的600行文件我吃过这个亏参数、模型定义、数据处理、训练循环全混在一起想换数据集结构的时候牵一发动全身。后来我按传统的工程分层方式重构成了四层config层、data层、model层、train层。config层用yaml或者dataclass管理所有超参数data层只负责把原始数据变成模型输入model层只定义网络结构train层负责训练循环、日志、checkpoint保存。# config.yaml 示例 data: train_path: ./data/train.parquet val_path: ./data/val.parquet max_len: 128 model: backbone: bert-base-chinese num_labels: 4 train: batch_size: 32 lr: 2e-5 epochs: 4 seed: 42训练循环里的几个关键细节值得说清楚。第一优化器我用的是AdamW而不是Adam因为AdamW把权重衰减和梯度更新解耦了配合Transformer类模型效果更稳。第二学习率需要配warmup前几百步把学习率从零线性升到目标值防止模型在初始阶段因为过大的更新步长震荡。第三每一个epoch结束都要保存一个checkpoint同时把优化器状态一起保存这样即使中途崩溃也能从最近的状态恢复训练而不必从头再来。3.3 从PyTorch模型到模型服务训练完成之后模型文件只是一个权重文件它是不能对外被直接调用的。要把它变成服务中间还有几步关键工作。首先是把模型导出为TorchScript或ONNX格式导出的过程其实就是把动态图固化成静态图结构这样推理时省去了Python层的大量调度开销。我用TorchScript做过一次实验导出后单次推理延迟从20毫秒降到了8毫秒左右效果非常明显。接下来是模型服务的架构。我采用了两层结构最外层是FastAPI服务负责参数校验、鉴权、限流这些Web层的事情内层是TorchServe加载模型进行推理。FastAPI收到请求后把文本传给TorchServe拿到推理结果再包装成统一的JSON响应返回给调用方。这样分层的好处是Web逻辑和模型逻辑互不干扰——如果模型需要升级只要重启TorchServe加载新版本如果接口需要加字段只改FastAPI层就行不必动模型环境。from fastapi import FastAPI, HTTPException from pydantic import BaseModel import requests app FastAPI() class PredictRequest(BaseModel): text: str app.post(/predict) def predict(req: PredictRequest): if not req.text.strip(): raise HTTPException(status_code400, detailtext不能为空) # 转发到TorchServe resp requests.post(http://torchserve:8080/predictions/text_model, json{text: req.text}) return {label: resp.json()[label], score: resp.json()[score]}3.4 使用Docker部署全链路部署阶段我用Docker Compose把三个服务编排起来FastAPI应用、TorchServe、Prometheus。每个服务一个容器通过docker-compose.yml里的网络互相通信。为什么要用容器核心原因是环境一致性。模型推理对版本极其敏感Python版本、CUDA版本、依赖库版本一旦不一致线上很容易复现不了训练时的效果。容器把整个环境固化成镜像之后“在我机器上能跑”这句话就从借口变成了现实。version: 3 services: fastapi: build: ./app ports: - 8000:8000 depends_on: - torchserve torchserve: build: ./model_server ports: - 8080:8080 volumes: - ./model_store:/home/model-server/model_store部署完成后一定要做的事是启动探活。FastAPI提供了一个/health接口返回服务状态和当前加载的模型版本号。这个探活接口有两个作用一是给负载均衡器做健康检查二是给监控系统一个可以定期拉取的数据点。如果模型服务挂了而网关还继续转发请求用户侧看到的就是“服务不可用”这是生产事故的第一来源。4. 实验管理与模型版本化最容易忽略的一环4.1 MLflow追踪每一步实验跑过几轮实验之后你就会发现人脑根本记不住哪个参数组合对应哪个指标。学界有个词叫“炼丹”但工程上我不喜欢这个词因为它让人觉得调参靠感觉。实际上调参应该是一个系统化的过程前提是每一组实验都留下了完整记录。MLflow就是干这个的它自动记录每次运行的参数、代码版本、输出指标以及产出的模型文件。我通常把每一个实验运行都附带一个“实验备注”记录这次实验改了什么、想验证什么假设。这样一周后回看历史每一行记录都像一份可复现的日志。MLflow的使用非常简单只要在训练代码里加几行import mlflow with mlflow.start_run(): mlflow.log_params(config.train) mlflow.log_metrics({val_acc: val_acc, val_f1: val_f1}) mlflow.pytorch.log_model(model, artifact_pathmodel)跑完后在MLflow的UI上就能看到每次运行的对比曲线谁优谁劣一目了然。我记得有一次实验里我把batch size从16调到32模型效果不升反降要是在以前我可能就归结于随机性了但因为有实验记录在我回去对比发现是32的batch配合2e-5的学习率实际更新步数减少了一半模型还没收敛就epoch结束了。后来我把学习率降到1e-5效果就追回来了。这就是实验管理的价值——它让每个偶然现象都可以回溯到原因。4.2 模型版本管理不能只靠文件名模型文件我见过有人命名为model_final_v2_final_0815.pt的这种习惯用在小项目还行一旦模型版本多了之后必乱。我的做法是三个层面MLflow负责追踪模型产出的来源哪个run产生的模型存储目录用版本号和时间戳双重标识模型服务的API响应里带上当前model_version字段。也就是说线上请求返回的结构里不仅有分类结果还有一个version字段这样一旦业务方反馈效果变差我可以通过version直接定位到线上跑的到底是哪一版模型、由哪次实验生成、用的什么数据集。模型更新策略也要提前想好。我经历过一次事故直接替换线上模型文件后服务重载了新版本结果指标明显下滑但因为旧版本已经被覆盖回滚非常痛苦。之后我改成了一种更稳的更新方式——保留两个版本的模型同时加载新版本先通过shadow模式在后台跑流量和旧版本的预测结果做对比确认新版本效果真的更好的时候才切流量。这个策略虽然实现上多写了一点代码但能避免很多线上事故。4.3 数据版本管理同步做模型版本管理如果缺少数据版本管理所有努力都会打折扣。因为同一次实验如果训练数据变了结果根本不可比。我用的方法比较朴素用dvcData Version Control对数据集目录做版本标签跑实验前记录当前数据版本的hash值和模型指标一起写进MLflow的run里。这样任何时候回溯都能完整回答“这个模型是拿哪份数据在什么参数下训出来的”。这一步看似不起眼等团队合作时它的价值就大了因为不同人拉的可能是过期的数据副本结论一对比就各种对不上。5. 部署上线之后监控与迭代才是常态5.1 监控指标怎么定模型服务的监控和传统后端服务的监控不太一样。传统后端的监控重点是延迟、错误率、QPS这些当然要监控但AI工程还有一类更关键的指标——数据分布指标和模型效果指标。例如我在推理服务里加了一个统计模块每隔5分钟统计一次输入文本的平均长度、类别预测的分布概率。为什么要统计类别预测分布因为如果某个退换货类别的预测比例突然从10%涨到30%大概率不是业务真的变了而是输入数据分布漂移了模型在陌生数据上产生了系统性偏差。这个信号可以做到在用户大规模投诉之前提前预警给运维留出反应时间。5.2 线上效果不等于离线指标这是我想强调的另一个认知离线验证集上的指标只能作为参考不能作为上线决策的唯一依据。因为离线验证集和你线上真实流量之间存在三大差异——时间差异、地域差异、用户行为差异。我遇到过一个典型案例离线验证集F1达到0.87的模型上线后实际表现只有0.79。排查后发现训练数据里“产品质量”类别的文本大多有“坏了”“碎了”“脏了”这类明显词而线上用户实际的表达是“塑料味很重”“感觉是翻新机”措辞风格完全不同。从那以后我给自己定了一条工作原则新模型上线前必须做小流量对比测试至少积累一周真实样本再决定是否全量切换。这比盲目相信离线指标靠谱得多。5.3 模型更新的迭代节奏模型不是训一次就完事的。业务在变用户在变语言表达也在变所以模型需要定期迭代。我通常的做法是“周度预测监控月度数据采样季度模型重训”。周度监控看的是分布漂移有没有异常月度采样是让人工标注员从线上抽样一批用户反馈补充进训练集季度重训则是把这几个月积累的新样本和原来的数据合并重新跑一遍训练流程。这个节奏可以根据业务变化速度调整但对于大多数内容分类、文本理解这类场景是一个比较稳的基线。注意重训不等于从零初始化再训练。更好的做法是拿上一个版本的模型权重作为初始权重用合并后的新数据继续训练这种增量训练的思路能保留旧模型已经学到的知识同时吸收新样本的信息训练效率也更高。6. 常见问题与排查技巧实录6.1 训练不收敛或收敛极慢如果loss在训练初期就不下降先别急着改模型结构按顺序排查数据预处理是否做了归一化、学习率是不是太大或太小、标签是否有大量错误。我遇到过最离谱的一次是数据里混入了大量空文本模型学到的是“空格对情绪类别贡献极大”loss当然怎么都降不下来。检查之后我把空样本过滤掉问题立刻消失。另一个常见原因是学习率没配合warmup尤其是Transformer这类模型一上来就被大学习率撞出正常优化轨迹。6.2 GPU显存溢出怎么办显存溢出OOM这个问题看似硬件的锅其实很多是代码的问题。单样本序列过长是其中一个原因可以启用梯度累积来降低单步显存占用把一个大batch拆成多个小batch先算梯度暂存起来凑满一个步数再统一更新参数。如果显存还是爆可以考虑用混合精度训练PyTorch自带amp模块fp16能把显存占用砍半很多情况下显存翻倍收益反而没那么值得。scaler torch.cuda.amp.GradScaler() for batch in dataloader: with torch.cuda.amp.autocast(): loss model(batch) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()6.3 线上推理延迟波动大推理延迟不稳定可以先区分是CPU端问题还是GPU端问题。我遇到的情况是请求量波动大时GPU利用率忽高忽低模型推理时有排队。解决方式是给推理服务加并发控制限制同一时刻进入模型推理的请求数量多余请求进入队列等待。结果队列长度大幅超过预设阈值时触发限流返回“忙”状态让调用方做重试。这样一个固定容量的服务才能稳定输出延迟用户体验才会变好。6.4 常见问题速查表现象首要嫌疑排查方法训练loss不降数据问题比模型问题更常见抽样人工查看输入输出对齐验证集指标高但线上差数据分布偏移或者时间泄露按时间切分验证集重新评估推理延迟忽高忽低推理队列无界增加并发限制和排队策略模型升级后效果下降版本没有留痕、回滚困难检查version字段、双模型切换服务OOM崩溃数据量增长但显存没扩容加监控看峰值占用考虑模型量化7. 从“跑通”到“可靠”进阶建议与后续扩展7.1 分布式训练什么时候引入如果你一个人做项目单卡训练基本够用分布式可以先不学。但如果数据量上了千万级单卡训练一次要三四天这时候分布式训练就不是可选项而是必需品了。建议从PyTorch的DistributedDataParallel练起它的使用门槛不高核心是理解数据并行和梯度同步的过程。还有一个重要经验分布式训练的问题排查比训练本身耗时更多一定要先在单机多卡上跑通再上多机不要一步跨到多机环境去调试。7.2 MLOps平台要不要自建关于MLOps平台我的观点是分阶段看。刚开始自己搭链路时能亲手写就亲手写这有助于理解每一步的机制但到了团队规模超过3人、模型数量超过10个的时候就应该考虑使用更成熟的MLflow或Kubeflow方案。自研平台容易踩的坑是“代码写完了但没人维护”它不像业务功能有直观的用户反馈优先级永远被排到最低。所以我的建议是用开源工具先行自研只做开源工具覆盖不到的补充不要重复造轮子。7.3 大模型时代还需要这套体系吗有人会问现在大模型这么火是不是就不需要传统AI工程的这套体系了我的答案是恰恰相反。大模型时代的工程链路只会更复杂。你要处理更长的文本、更大的显存、更精细的prompt版本管理、更复杂的评测体系、更昂贵的训练成本。这时候如果没有一套扎实的工程框架在支撑很难在这些复杂因素中找到头绪。传统AI工程的沉淀——数据管理、实验追踪、版本控制、监控体系——在大模型时代依然是整个系统运转的地基。从我个人的经验来看花三个月时间把“ai-engineering-from-scratch”这条路完整走一遍收益远超预期。你收获的不只是会调模型而是一套完整的工程直觉知道数据在哪一环容易出问题、知道模型上线后怎么判断它是否在退化、知道新版本和旧版本之间如何平滑切换。这些能力在任何一个AI项目里都是通用的也是在常规文档里很难查到的核心经验。如果你正站在AI工程的门口最有效的动作不是收藏一堆教程而是从今天开始亲手搭一条哪怕很小的生产链路。