1. 项目全貌AI工程到底在工程什么很多朋友看到“ai-engineering-from-scratch”这个名字第一反应是这不就是又一个人工智能入门教程吗实际上不是。AI工程这四个字重点落在“工程”上而不是“模型”上。我在算法岗做了几年后来负责从零搭建AI应用体系最大的感受是——面试时聊模型结构、损失函数能聊两小时但真正上线一个模型让它稳定跑上三个月不出问题才是最有挑战的部分。这个项目标题拆开看有三个关键词分量很重。一是“ai-engineering”指的不是写一个PyTorch训练脚本而是从需求分析、数据管道、模型训练、性能调优、服务部署到监控运维的完整链路二是“from-scratch”意味着不依赖现成的套壳方案不把“跑通别人代码”当成“自己会了”而是亲手把每一层打通三是隐藏在背后的“系统思维”也就是你做的不是单个模型而是一个能支撑业务迭代的AI子系统。谁适合看这份拆解想从纯算法转向工程落地的同学刚接手AI项目但不知道从哪下手的团队技术负责人还有那些已经在调库、但总觉得自己“离真正工程还差一层”的开发者。这个项目不会教你通读所有论文也不会让你背诵网络结构它给的是从零把模型变成产品的全过程路径以及每个环节里那些不踩一次就学不会的坑。2. 动手之前技术地基到底要铺多厚2.1 数学与代码能力够用就好但必须真够用“从零开始”最容易犯的第一个错误是先去把线性代数、概率论、凸优化全套重学一遍学完感觉自己行了一到写代码还是不会。我的建议是反着来——先从代码出发用到什么补什么。你写attention的维度变换时发现矩阵乘法不熟就回头补矩阵相乘的形状规则把q、k、v和注意力权重的shape变化算清楚你理解交叉熵损失时对信息论有点含糊就只补“分布之间差异”这一块。按需补课效率远高于系统重学。Python侧的工程能力常常是被低估的一环。类、装饰器、生成器、类型注解、异常捕获这五样是AI工程里最常用的语言特性。数据加载器要写成生成器节省内存配置解析要用类型注解提升可读性训练循环要包成类方便扩展。不少人调库很6但一写业务逻辑就一团乱麻这就是工程基本功没跟上。2.2 环境基建conda、Docker与版本锁定的三重保险“昨天还能跑的代码今天突然报错”这种事十有八九是环境问题。从零做AI工程我强烈建议第一天就建立三个习惯。第一用conda单独管理每个项目的Python环境并且通过environment.yml文件记录版本第二从项目一开始就写Dockerfile别等部署时再补第三把requirements.txt里的包全部锁到具体版本号而不是用“torch2.0”这种范围声明。我自己的惨痛教训是一个训练好的模型在交付时因为transformers库从4.35升到4.38tokenizer的默认行为变化导致数据预处理结果不同最终线上效果直接崩了。TypeError不可怕可怕的是数值悄悄变化、模型表现下降却查不到原因。有些朋友觉得Docker是运维的事自己不想碰。但AI工程恰恰是算法和运维的交界地带一个能独立构建镜像、调试容器、理解CUDA运行时依赖的算法工程师在团队里的作用相当于承上启下的桥梁。从零学Docker并不难先搞懂FROM、COPY、RUN、CMD四条指令再理解容器和宿主机的差异基本就能解决大多数问题。3. 核心链路拆解第一个端到端项目的完整落地3.1 项目选型与问题定义为什么我推荐从NER开始如果团队经验不深、又想快速看到全链路效果命名实体识别NER是我最推荐的首战项目。原因是它的链条短、指标明确、业务价值容易讲清楚。相比图像生成、对话系统这种高难方向NER的数据标注成本低一个非专业人员培训一小时就能标得八九不离十模型规模也小单卡甚至CPU都能做推理更关键的是它的上线效果肉眼可见“从合同里自动抽取公司名和金额”这句话业务方一听就懂。问题定义这一步比很多人想象的重要得多。我以前见过一个团队花了三周做实体识别模型精准度和召回率都调到了90%以上结果业务方说我们要的不是抽实体而是判断合同里“付款条款是否对我方有利”。需求压根就不是同一个。所以在动手之前先和业务方把边界谈清楚输入是什么格式的文档输出要落到什么字段允许的误差是多少处理速度要求是秒级还是分钟级。这些问题写成一个简短的需求确认文档工程侧所有后续决策都围绕它展开。3.2 数据管道从原始文本到模型输入的结构化过程原始数据几乎永远是脏的。我处理的合同数据里有扫描件的OCR噪声、有不同模板带来的格式差异、有PDF转文本时出现的乱码换行。处理经验是宁可写一个专门的数据清洗模块也不要今天在Jupyter里手动补一刀、明天在预处理脚本里再补一刀。越早把数据管道固化成可重复执行的代码后面的返工就越少。清洗完成之后是标注。标注之前必须写一份标注规范这是很多项目最容易忽略的环节。两个人标注同一段文本可能一个人把“北京市朝阳区”整体标为地点另一个人只标“朝阳区”这种标签不一致会让模型的upper bound直接降低。规范里要写清边界规则、歧义示例、特殊情况处理方式。做完一批标注之后还要做一致性检查计算标注员之间的Cohens Kappa系数如果低于0.8就要回头重新对齐规则。标注工具方面我用过doccano开源、部署简单一个docker-compose就能跑起来适合小团队试用。数据格式上推荐采用BIO标注体系——B表示实体开头I表示实体中间O表示非实体。BIO比BILOU少两类标签对新手更友好对模型表达能力的影响在这个场景下可以忽略。3.3 训练环节的细节把控五步踩出稳定的基线第一步是数据集划分。千万别直接随机切分要用分层抽样保证“公司名”“人名”“金额”这几个类别在训练集和验证集中的比例一致。金融文书里常见的情况是“日期”实体占了60%以上如果不分层切分某些稀有类别的实体可能在验证集里一个都没分到导致验证指标失真。第二步是tokenizer与标签的对齐。这是NER项目里最容易出bug的地方。预训练模型用的分词器会把一个word切成多个subword原来基于word级别的标签必须逐token地展开映射。用HuggingFace的tokenizer做序列标注时一定要关注offset mapping也就是从token映射回原始字符位置的索引。标签扩展这一步如果写错了训练不会报错但指标会一直上不去而且排查极其费劲。第三步是模型选型。起步阶段直接用Transformers库里预训练的中文模型比从零训练要靠谱得多。参数规模上不要一上来就上large先用base甚至small版本把整个流程跑通确认数据、训练、评估链路没有问题再考虑扩大模型。几年前我在一个真实项目里先用base模型跑通了流程之后换large模型时发现资源占用和训练时间都涨了三四倍但由于链路通畅替换只是改一个配置的事。第四步是训练超参数。学习率这一项在BERT类模型上5e-5到3e-5这个区间的区别通常不大但如果你用更大的学习率比如1e-3以上预训练知识会被快速覆盖模型表现得像是“学了新知识但忘了旧知识”。批量大小则受限显存一般单卡16到32比较合适。一个容易被忽视的参数是warmup ratio前5%到10%的step先让学习率从零爬升到目标值能明显缓解训练早期的不稳定性。早停策略也很必要盯着验证集F1连续三个epoch不涨就停下来省下的时间可以做更多尝试。第五步是把实验结果记录下来。很多人训练时只在笔记本上记了个大概过两天就忘了哪个配置对应哪个结果。从零开始建立AI工程体系我的建议是第一周就引入实验管理工具比如MLflow或wandb把每一组实验的超参数、数据集版本、代码commit、验证指标自动记录在案。这在调参阶段的意义不亚于代码本身。3.4 评估指标的隐性陷阱F1值好看不等于可用评估阶段NER项目最经典的坑是直接用sklearn的classification_report打印精确率、召回率、F1值看起来很专业实际指标可能是错的。为什么因为classification_report计算的是token级别的指标也就是每个token预测得对不对但业务关心的是“整个实体是否被完整抽出来”。一个实体有五个token只预测对了三个token级指标会认为这算部分成功但业务方拿到的是残缺结果等于失败。正确的做法是计算span级别实体片段级别的F1。一个预测实体和标注实体完全匹配才算一次成功预测。这个指标实现并不复杂核心逻辑是先解析出预测的实体span列表和标注的实体span列表再比较两者的交集。还要分别计算strict模式和relaxed模式——strict要求边界完全一致relaxed允许部分重叠。上线之前至少要看strict模式的指标否则大概率被业务方挑战。另一个隐性问题是数据泄漏。做NER时如果文档级的信息被直接当成了特征比如“所有包含‘公司’词的段落都预测为组织实体”这实际上就是模型在走捷径测试集上指标很高遇到新数据立刻打回原形。验证这一点的简单方式是用一个完全无语义信息的模型比如随机初始化BERT跑一遍完整流程如果它也能拿到异常高的F1说明你的数据或评估逻辑里有泄漏。4. 从Notebook到服务工程化的分水岭4.1 把代码组织成规范项目看得见的工程思维差异Notebook适合探索但绝对不适合部署。from-scratch项目的工程化改造本质上是把一把梭的脚本拆成模块清晰、职责单一、可测试的代码库。我的习惯是项目根目录下分几个核心目录config存放YAML配置文件data存放原始数据和处理脚本models存放模型定义train.py负责训练入口inference.py负责推理入口utils存放通用工具函数tests放测试用例。配置管理这一点值得多说几句。不要用argparse堆一堆命令行参数更不要用硬编码常量。直接把训练参数、数据参数、模型参数写在config.yaml里配合开源库Hydra做多级配置管理。不同实验的差异只需要切换到不同的YAML文件代码一行不用改。实测下来这套方案在多项目并行时的管理成本降低得非常明显。代码质量上至少要保证推理入口的函数能单测。训练代码的测试相对难写但推理路径完全可以做到稳定覆盖。我通常会写三个冒烟测试一是加载一个最小模型并跑一次前向传播确保shape正确二是用一条真实样例验证预处理到预测的完整链路三是测试batch推理和单条推理的结果是否一致。这三个测试跑通部署风险就降了一大半。4.2 推理性能优化从PyTorch到ONNX Runtime的实测记录模型能跑和能上线是两回事。PyTorch的eager模式推理对生产环境来说常常太慢、太吃资源。我在这类小模型上首选的优化手段是转成ONNX格式再用ONNX Runtime做推理。BERT-base规模的模型在CPU上从PyTorch推理切换到ONNX Runtime通常能快2到3倍如果再做Int8量化还能再快一截。对NER这种对延迟不极敏感的场景完全够用。这样做的原理并不神秘。PyTorch的动态图模式里每层计算都要经过Python调度也就是所谓的“Python开销”而ONNX Runtime导出的是静态计算图避免了逐层Python调度的开销。同时算子融合技术可以把多个计算步骤合成一个例如把LayerNorm内部的若干操作合并为一个算子内存访问次数因此显著减少。导出ONNX时有几个参数选择要格外注意。第一个是opset版本太老的操作集可能不支持新版模型的某些算子我的习惯是设为当前ONNX Runtime支持范围的中高版本避免兼容与性能两头损。第二个是dynamic_axes要在导出时显式声明batch维度和sequence维度是动态的否则转出来的模型只接受固定长度输入一条长文本就直接挂掉。第三个是externally_data遇到一个大模型导出后的文件非常占内存时用这个参数把权重数据落盘存储。量化环节如果你追求稳定就选动态量化静态量化对校准数据集要求高对分布漂移敏感在NER这种小词表场景性价比不高。4.3 部署形态FastAPI Docker 监控的经典组合部署选型我见过最简单也最稳的方案是用FastAPI封装推理服务再包进Docker镜像。为什么选FastAPI而不是Flask因为FastAPI自带类型校验、自动生成接口文档、原生支持异步调用对于模型推理这类输入输出结构清晰的服务写起来省心太多。接口设计上有几个细节。第一模型的输入输出必须是JSON输入形如{text: 请抽取这段文本中的公司名称}输出形如{entities: [{text: 某某科技有限公司, type: ORG, start: 3, end: 10}]}同时必带一个code字段表示状态方便调用方统一处理错误。第二建议加一个predict_proba开关默认时返回普通结果调试时能拿到置信度。第三健康检查接口要单独写一个/healthzDocker容器的心跳检测就挂在它上面。Dockerfile的写法也有讲究。基础镜像用python:3.9-slim比用python:3.9灵动得多镜像体积小一大半攻击面也小。依赖安装建议分两层先COPY requirements.txt并pip install再COPY其余代码这样能充分利用Docker构建的层缓存改代码后不用重新装包。最后一个原则是容器里用非root用户运行服务别问为什么会遇到权限问题问就是遇到过。监控是上线之后的第一道防线。至少要有三块指标流量指标QPS、性能指标延迟的P50、P95、P99分位数、饱和度指标CPU、内存、GPU显存使用率。延迟只看P50是不够的P95和P99能告诉你最差的那些请求是不是已经慢到不可接受。更进阶一点的监控是数据漂移检测定期比较线上输入文本的统计特征和训练集分布的差异一旦漂移指数超阈值就告警。漂移不会让服务立刻挂掉但会体现在模型效果每况愈下等业务反馈时已经晚了。5. 实战中那些必须避开的坑5.1 环境与依赖版本地狱的排查方法论环境问题占据了AI工程从零起步阶段至少三成的调试时间。最常见的一类问题可以叫“版本错位”——torch的CUDA版本和驱动版本不对transformers和tokenizers版本不匹配或者numpy版本和更新的包产生了API变动。这类问题最难受的地方在于报错信息经常毫无提示有的只给一句Segmentation fault有的甚至直接静默退出。我的排查思路是第一板斧锁定Python环境先确认当前conda环境是不是项目专用的有没有不小心用到base环境第二板斧检查包版本用pip list把关键依赖版本列出来对照项目锁定的版本号逐一比对第三板斧是二分注释法先把训练脚本里所有导入模块从下往上逐段注释定位到具体是哪个import开始报错然后针对这个模块单独重装。那个折磨了我一整天的“Dataloader多进程时莫名其妙崩溃”问题最后发现就是spacy和torch跟numpy的ABI不兼容把numpy统一到特定版本就解决了。5.2 数据与训练看似正常实则错误的典型模式数据侧的坑比环境更隐蔽因为错误常潜伏在安静的数据流中。一个高频bug是数据shuffle的遗漏。DataLoader里忘记设shuffleTrue只会让你验证集的loss呈现诡异的周期性波动模型看起来“每次epoch都学了一遍同一顺序的样本”不会报错却会限制泛化上限。另一个高频bug是label编号和模型输出头的冲突——预训练模型的classifier层默认输出类别数应该和你的label数量一致有人改backbone时忘了改输出维度训练开始就崩。第三个坑是梯度累积的步数设定。设置gradient_accumulation_steps4时如果学习率没有相应调大你会觉得训练变慢了但不清楚原因因为每次参数更新的有效batch确实变大了而学习率还按小batch的行为来设模型收敛缓慢。这些问题的共同特征是代码能跑指标不给力而且不好查。所以我后来立了个规矩任何训练实验的首次运行都用一条极小样本集跑一遍把loss打出来看看能不能下降、能不能过拟合。能过拟合说明模型的学习能力没有问题loss肉眼可见地下降说明梯度回传正常再把样本放大到全量才进入正式训练。每次改完代码先做这个小冒烟测试能筛掉一大半隐性bug。5.3 部署运行服务上线之后依然存在的坑服务上线以后还有一批运行期bug最经典的是device mismatch。多GPU机器上模型被torch自动放到了cuda:0但推理请求的数据却默认在CPU上生成一跑就报Expected all tensors to be on the same device。这个问题的根因是预处理和模型推理没有统一设备管理所以要封一个inference函数在函数入口处显式把输入tensor全部.to(device)。第二个常见坑是并发请求下的线程安全。同一个模型实例被多个线程同时调用时如果你在代码里用了共享的可变状态就会得到奇怪的结果。解决方式是推理函数内部只使用局部变量并把模型的eval模式与no_grad操作放到每次推理内而不是初始化时。最后还要说一个数据泄漏至服务层的事。有一次线上预测突然全返回NULL查了半天发现是输入文本中包含了JSON转义字符而预处理逻辑没做兼容转成token时全被过滤掉了。这类边界输入最好的防御手段是上线前准备几十条“奇怪但真实”的测试样本包含超长文本、纯符号文本、大量空白文本、表情符号等全部跑通后再放量。6. 个人经验这条路该怎么继续走从零起步搭建AI工程体系的过程本质上是一个“把不确定性拆解成确定性”的过程。模型有个特点你只管调参不管部署就永远觉得自己离产品很远你只管部署不管数据质量大型系统上线三个月后照样会被上游脏数据拖垮。真正拉开差距的往往是那些不起眼的工程决策——多写了一个自动化测试多留了一份实验记录多锁了一个依赖版本这些动作在半年后都会以翻倍的效率回报你。如果你想顺着这条路继续深入有几个方向值得花时间一是把上线流程做成标准化的CI/CD流水线从模型训练到发布做到一键触发二是逐步建立特征平台把不同业务线需要的特征统一管理起来让多个模型共用一套基础设施三是从单模型服务走向多模型编排用调度层来统一处理路由、限流和资源分配。每一步都建立在前面基础上的又一个循环。最后分享一个我自己的土办法每做完一个项目我都会写一份“复盘笔记”结构很简单——这次做对了什么、栽在了哪里、如果再做一个同类项目第一周就先做什么。写下来的东西比你脑子里的印象可靠得多。AI工程不是靠灵感而是靠一个又一个“确定的步骤”堆出来的从零开始这条路走一段时间你就会发现最难的不是学技术是把这些技术稳定地组合在一起。