把“ai-engineering-from-scratch”当项目名其实是给自己划了一条边界不碰现成的端到端平台不迷信一键部署从最底层把AI工程重新搭一遍。过去大半年我就在折腾这件事从零开始做数据管线、搭实验追踪、写模型服务、上监控告警完整走过了一遍。这篇文章就把整个过程记录下来包括工具选型、项目结构、实操步骤以及我在线上真实踩过的坑适合已经会训练模型、但还没把模型做成系统的朋友也适合被各种AI工程框架绕晕的初学者。1. AI工程不只是“训练模型”1.1 这三个词背后的真实工作AI工程拆开看是“AI”和“工程”工程意味着可重复、可维护、可度量。会用PyTorch训练模型只是入场券真正到了线上才会发现训练环节其实是整条链路里最短的一段。一个完整的AI工程至少包含六块数据获取与清洗、特征计算与存储、实验管理、模型训练与评估、版本管理、服务化部署与监控。任何一环出问题整个系统都可能崩掉。我最早做项目时只把精力放在模型结构上结果数据格式一换评估代码立刻报错模型上线时手动改参数改错一个小写字母线上请求直接全部失败。那段经历让我明白AI工程的核心不是模型本身而是围绕模型的整套基础设施。你可以训练出一个精度很高的模型但如果没人知道它怎么被训练出来、怎么被复现、怎么被部署成稳定服务那它依然只是一个实验品。1.2 为什么从零开始更靠谱现在MLflow、Kubeflow、Ray这些平台确实省事装上全家桶就能跑通一套流程。但太早依赖平台有一个坏处工程细节被掩盖了。你不知道数据版本为什么变不知道模型注册表里为什么会有冲突不知道线上环境到底装错了哪个依赖。出问题时你只能在黑盒外面瞎猜。从零开始搭一套精简但完整的系统哪怕代码量不大也能让你理解每一环为什么存在。比如为什么需要数据版本控制因为模型是数据和代码共同决定的只锁代码不锁数据实验就不可复现。为什么需要模型注册表因为要有Staging、Production这样的阶段划分否则谁都能把一个未验证的模型直接上线。把这些底层问题想明白了后面需要规模化时再替换成更成熟的中间件你会很清楚该换什么、为什么换。这也是我把这个项目命名为from scratch的原因不是为了重复造轮子而是为了把轮子的工作原理看明白。1.3 这套方案做完能到什么程度我会在后面讲到一套已经跑通的方案包括基于DVC的数据版本控制、基于MLflow的实验管理、FastAPI在线服务、Docker打包以及一个面向基础监控的告警配置。这套东西不重单机就能跑起来但你已经拥有了一个可以横向扩展的骨架。等团队需要协作、流量上涨、特征变多时你会很清楚该在哪个环节加机器、加队列、加缓存。2. 技术栈怎么选别急着上全家桶2.1 语言与基础工具技术栈我选了Python为主理由不用多说AI生态的轮子几乎都在Python里。但Python的依赖管理是公认的痛点版本冲突、隐式替换、环境漂移哪一个都能让人浪费几天。我的建议是每个项目独立环境用uv或poetry做依赖锁定把python版本和核心库版本全部固定住。刚开始多花十分钟写pyproject.toml后面复现实验时会省下好几个工作日。另外强烈建议给项目配置统一的配置管理。我习惯用pydantic写配置类把数据路径、特征列表、模型参数、服务端口都放进去。这样做的原因很简单配置一旦集中管理实验切换时只需要改一份文件而不是满项目地搜索硬编码。后面接入实验追踪时这份配置还能自动变成MLflow里的参数记录一举两得。2.2 数据管线的选择数据处理框架我建议先别上Spark、Flink这些重型设施单机pandas完全够起步。存储格式用parquet比csv体积小、读写快还保留schema信息不用担心读出来全是字符串。数据版本管理我用DVC它让数据和模型版本一起做git化管理。为什么不用git直接管数据因为文件动辄几百MB直接塞进git会让仓库尺寸爆炸clone一次能等半小时。DVC的做法是在git里只保存元数据和哈希真实数据放在本地或S3等存储里。要复现某个历史实验时一条命令就能把数据切回对应版本。数据管线本身我推荐写成函数式模块load_data、clean、feature_engineering、split。每个函数只做一件事输入输出定义清晰。这样写的好处是单元测试好写后面要扩展成DAG或流水线时也能直接拼接。我见过很多人把清洗和特征工程写在一个几百行的脚本里后面想改一个字段都不知道该从哪里下手。2.3 实验追踪与模型管理实验追踪我用MLflow因为它同时覆盖了实验记录和模型注册表两块。训练脚本里用autolog记录核心指标、参数、模型路径每次实验自动生成一个run。模型注册表尤其关键把在验证集上表现最好的模型标记为Staging线上验证通过后再标记为Production一旦线上效果变差可以一键回滚到上一版。这个习惯我强烈建议保留不管是单人项目还是团队项目都会让你省掉很多麻烦。我踩过的一个坑是只记录模型参数和指标没记录数据版本。结果实验A和实验B的代码、参数完全一样但训练数据换过一版指标根本不能对比。后来我强制要求每个run里面必须包含数据版本的哈希字段这个问题才算根治。记住一句话实验记录里不写数据版本等于实验白做。2.4 从Jupyter到生产服务化选型模型上线需要一层API壳我常用的组合是FastAPI写在线接口uvicorn作为服务进程Docker负责打包。模型本身用ONNX或TorchScript导出再通过ONNX Runtime做推理这样可以避开线上环境必须安装PyTorch全家桶的问题。导出时固定输入输出的shape和dtype并在本地用测试集对比原模型和导出模型的输出差异差异超过阈值就说明导出有问题常见原因包括动态shape不兼容或某些算子不被支持。如果你只是内部调用BentoML这类封装好的工具也很方便但我在这个项目里特意选择了手动组合FastAPIDocker目的是让整个调用链路都在自己手里。请求进来后要经过API鉴权、参数校验、特征拼装再传给模型推理最后把结果包装返回。每一步都能加日志、加超时、加隔离不会被框架的黑盒逻辑卡住。3. 从零到上线一条可以直接复制的项目路线3.1 项目目录怎么搭我推荐一个很常见的结构ai-engineering-from-scratch/ ├── configs/ # 配置文件与参数 ├── data/ # 数据文件gitignore ├── features/ # 经加工后的特征文件 ├── models/ # 模型产物 ├── src/ │ ├── data/ # 数据加载与清洗 │ ├── features/ # 特征工程 │ ├── models/ # 训练与推理脚本 │ └── serving/ # API服务 ├── tests/ # 单元测试与集成测试 ├── app.py # FastAPI入口 ├── pyproject.toml └── dvc.yaml # 数据管线定义这个结构的核心原则是数据和产物尽量不进git代码和配置才进git不同模块之间用清晰的接口通信避免单个脚本上千行。很多团队没有把代码和数据分开结果实验记录基本靠记忆实在痛苦。3.2 数据质检是这场工程的真正起点很多人拿到数据就开始训练结果后面到处救火。我的习惯是先做数据质检哪怕只花半天也能省下后面一周的调试时间。质检内容主要有五项数值字段的分布情况、缺失值比例、类别字段的取值个数、时间字段的范围、标签分布是否异常。我常用pandas-profiling生成快速报告再搭配几条自定义规则比如某个字段缺失率超过阈值就报警分布偏移超过倍数就暂停训练。一旦发现数据有问题就要立刻回答三个问题这是采样问题还是全量问题是上游系统改接口了还是历史脏数据需要修复还是过滤把这些问题记录到数据管线的文档里后面别人接手时就不用靠猜。数据质检还有一个隐藏价值它会逼你了解数据生成过程的每一个细节这些理解在后面的特征工程和模型调试中都会用上。3.3 特征工程落地成代码特征工程是AI工程里最容易乱的部分。我的原则是所有特征都写成确定性函数输入是原始数据输出是特征DataFrame不依赖任何全局状态不夹带随机种子。这样同一个输入在任何时候都能得到相同的特征输出。特征命名也必须要稳定一旦上线特征名不能随便改否则离线评估和在线服务会静默失配。建议在特征表里增加版本字段比如feat_v1_user_click_count每次变更就换版本号。我踩过的一个典型坑是训练时用了用户历史序列的长度做特征线上服务却因为取数超时把这个特征填成0。模型对0和真实历史长度分布完全不同结果线上指标直接崩掉。后来我在服务端增加了一个特征完整性校验缺失或超时就拒绝请求而不是用默认值偷偷顶替。特征工程里的一个基本要求是训练和线上代码共用同一套逻辑否则离线在线不一致迟早会咬你一口。3.4 训练过程的“科学化”改造在notebook里跑通模型和工程化训练是两回事。工程化训练至少要做到三点可复现、可观测、可治理。可复现需要四重锁定代码版本用git固定数据版本用DVC固定依赖版本用poetry.lock固定超参数用MLflow固定。任何一个实验拿到对应的四个标识都能完整重跑一遍。可观测是指训练过程要留下所有你想看的曲线和指标。除了loss和acc我还会记录学习率、梯度范数、显存占用、数据加载耗时。这些指标在排查训练不收敛、早停失效、OOM时非常有用。MLflow的autolog可以自动捕获一部分但自定义指标还是需要手动记录。可治理是指模型注册表要真的用起来。不要在训练完第二天就直接把那个模型放到线上至少要经过一次离线评估、一次影子验证然后标记为Staging再逐渐切流量到Production。出了问题时回滚到上一个Production版本应该是一键操作而不是从训练日志里手动翻找。3.5 模型评估不能只看ACC训练完成后的评估环节最容易自我感动。只看单点ACC或AUC只能说明一个大致方向真要判断一个模型能不能上线我至少会看四类指标。第一类是整体指标准确率、精确率、召回率、F1。第二类是分群体指标按用户活跃度分段、渠道分段、品类分段。第三类是鲁棒性指标在噪声扰动、缺失输入、极端样本下的表现。第四类是性能指标推理耗时、显存占用、吞吐量。分群体指标特别容易被忽视。我见过一个模型整体准确率很高但高频用户群体上准确率却比基线还低等于把最核心的用户得罪了。如果不分群去看这个问题直到线上才会暴露到时候影响已经扩散。所以评估报告里一定要有一张分群体结果表哪怕只按两个维度切分都好。3.6 导出与服务化模型训练完之后通常要导成推理格式。我的习惯是先转ONNX再用ONNX Runtime做推理。ONNX的好处是模型结构被固定下来体积相对小推理也比较快而且不受Python库版本影响。导出时要固定输入输出的tensor shape和dtype并在本地先用测试集跑一遍对比原模型和导出模型的输出差异。差异超过阈值就说明导出有问题常见原因是动态shape和算子不兼容。服务化我用FastAPI写接口核心就两件事把请求参数转成特征把模型结果转成响应。这里有一个经验特征转换逻辑只能有一份代码训练和线上必须共用。很多团队线上效果差很多最后定位原因往往都是特征逻辑各写一遍。你可以把特征转换做成一个Python包训练脚本和API服务都从同一个地方import这样一致性就有保障。3.7 上线后的监控闭环模型上线不是终点监控才是闭环的入口。我至少会监控三类信号。业务指标比如点击率、转化率、订单量模型指标比如预测均值、置信度分布、正类比例数据质量指标比如请求量、空值率、超时率。当模型指标发生漂移时要能及时告警并触发重新训练或回滚机制。我常遇到的问题是“模型上线时效果很好但一个月后没人知道它还行不行”。解决办法是给监控系统加一个“最近一次有效评估”的时间戳如果超过两周没有自动评估就发一条提醒。不一定每次都要重新训练但至少要主动判断一次模型是否仍然适用。很多AI系统就死在这个“没人主动看”上。4. 这些坑我替你踩过了4.1 可复现性失效现象同一个commit、同一份参数第二次训练的指标却对不上。排查方向先看数据是否被DVC正确锁定再看依赖是否被锁死最后检查代码里是否有全局随机种子或并行环境差异。很多问题出在“默认随机种子”上比如dataloader没设种子、GPU的cudnn benchmark开了、多进程里shuffle顺序不稳定。我的做法是把所有随机种子集中管理在训练开始时固定torch、numpy、python的random同时记录cudnn配置。这样99%的可复现性问题都能落地解决。4.2 数据漂移导致线上分数下降表现是线下eval很好线上运行一周后指标下滑。最常见的原因是数据分布漂移比如用户群体变了、上游特征变了、季节性影响来了。处理办法分三步先对比线上和训练期间的特征分布用PSI或KS统计量判断漂移程度再检查线上特征计算逻辑和训练时是否一致最后考虑定期重训或增量更新。监控里必须包含分布快照否则你根本不知道漂移是从哪一天开始的。很多团队看到指标下滑只能干瞪眼就是因为没有保存过历史特征分布。给关键特征存一份周期快照成本不高但排查漂移时作用巨大。4.3 推理延迟的隐性杀手用户反馈接口变慢平均延迟从50ms变成500ms。排查下来往往不是模型本身变复杂而是特征服务超时、日志库阻塞、或者GPU显存不足导致排队。我踩过的一个具体问题是模型推理里用了动态batch但上游每次只发一个请求动态batch根本没起作用反而增加了调度开销。后来我把服务改成固定batch加并发池并加了超时熔断延迟才稳定下来。记住延迟优化优先看网络和IO其次才看推理引擎。很多所谓的“模型优化”其实是在错误的方向上使劲。4.4 GPU显存溢出的排查思路训练时OOM很多人第一反应是调小batch size。其实先看这几项模型是否用了太大的embedding、数据加载是否缓存了过多样本、梯度是否累积但没有释放、显存碎片是否过多。我的习惯是在训练循环里打印每一段的显存占用定位是哪一步在涨。如果峰值出现在backward考虑梯度累积或混合精度如果出现在数据加载考虑降低prefetch因子或者用单独进程加载数据。以我个人的经验OOM问题的大头往往不是模型参数量而是数据加载缓存和中间激活值。一次性把batch全部预加载进GPU内存后续训练再大也容易爆。5. 写在最后AI工程的高墙说实话AI工程没有哪一步是不可逾越的真正的麻烦在于细节之间相互咬合。数据版本、特征逻辑、模型注册、服务部署、监控告警任何一环断了都会传导到线上用户侧。做from scratch这个项目我最大的收获不是代码量而是对整个链路的掌控感。后续可扩展的方向还有很多特征存储、A/B测试、自动重训流水线但这些都要建立在对基础环节理解透彻的基础上。如果你也想开始类似的项目我的建议是先选一个很小的业务场景比如一个简单的文本分类或排序任务把从数据到监控的完整闭环跑通再逐步加复杂度和数据量。不要一上来就追求微服务化和大平台先把单机版做到可信、可控、可复现工程能力反而增长得更快。这个项目后续我还会继续补充的内容包括在线A/B测试的接入方式以及模型回滚的自动化触发条件到时候再单独写一篇详细展开。