坦白说我第一次认真琢磨“ai-engineering-from-scratch”这串字时脑海里冒出来的不是某个框架、某个平台的官方文档而是一个反差点AI圈子里聊“从零开始”的人很多但真正愿意把工程链条上每一个螺丝都亲手拧一遍的人很少。很多人以为“from scratch”意味着从手写神经网络、手推反向传播开始我恰恰不那么看。AI工程里的“从零”重点不在算法而在于把一个模型从实验脚本变成稳定服务的过程中每条数据怎么管、每个实验怎么记、每个接口怎么挂、上线之后怎么盯——这些环节你有没有稀里糊涂混过去。这篇文章想聊的就是按“从零搭建AI工程体系”这个思路走一遍的完整过程和踩坑记录适合刚入行想做工程化落地的算法工程师也适合已经有几个模型项目但总觉得“差点工程味”的同学参考。我会尽量少讲空话多讲我实际的操作、选型和教训。1. 从零的定义与边界不手写框架但也不放过任何环节先给“from-scratch”划个范围。我见过两类人一类恨不得什么都自己写连数据读取都要手撸一个类另一类什么都上现成平台模型堆上去、数据丢进去、点个部署按钮就以为完事了。这两类都容易翻车。前者的项目永远在造轮子主线进度被无限拖慢后者的项目一旦平台不满足需求想排错却发现整个链路像黑盒连模型服务挂了都不知道该查哪里。我理解的AI工程“从零开始”是在不用全家桶平台的前提下把一个AI系统所需的各个工程环节用最朴素、可理解、可掌控的方式亲手搭建出来。框架可以用工具可以选但每个环节的原理和边界必须清楚出了问题能进到那一层去排查而不是只能对着仪表盘干瞪眼。具体到路径上我建议的分工是这样的算法能力会训练、会调参、会评估这是基础不是工程部分的重点工程部分项目结构、环境管理、配置管理、数据版本、实验追踪、模型打包、接口服务、监控告警、迭代闭环。这两块的分界线很重要。我做“从零”项目时给自己定了一个规矩先把一个最小可用的端到端系统数据切分、训练、简单服务、手工检查完完整整跑通再去扩展复杂能力先追求“每一环都亲手搭过、坏了知道在哪修”再追求自动化、平台化。在实际操作中这个原则帮我挡掉过不少坑。比如早期我为了省事直接在一个巨大的notebook里完成了数据清洗加训练加评估模型效果看着不错但一个月后想换数据源重新跑一遍时发现清洗逻辑和训练逻辑搅在一起根本没法单独复现。后来我重新按照“数据、训练、服务”三个独立模块拆开虽然前期多花了时间但整个系统的可控程度完全不一样了。所以“从零开始”的真正含义不是拒绝工具而是拒绝把工具当黑盒不是从第一行代码写起而是从理解每一个环节、掌控每一个决策开始。2. 工程底座一套能复现的实验项目是怎么长出来的大部分算法项目的起点都是notebook这没毛病用来探索和验证想法很高效。但一旦想法验证完准备进入正式开发第一个要做的不是写模型代码而是把项目“底座”搭好。这个底座有几个关键组成部分项目目录结构、依赖管理、配置管理。2.1 项目结构src layout 带来的好处我强烈建议不用扁平化的“scripts目录塞一堆.py”结构而是用标准的src layout。一个典型的AI工程仓库长这样my_ai_project/ ├── pyproject.toml ├── README.md ├── configs/ │ ├── train.yaml │ └── serve.yaml ├── data/ │ ├── raw/ │ ├── processed/ │ └── manifest/ ├── src/ │ └── my_ai_project/ │ ├── __init__.py │ ├── data/ │ │ ├── loader.py │ │ ├── validate.py │ │ └── transform.py │ ├── models/ │ │ ├── architecture.py │ │ └── trainer.py │ ├── evaluate/ │ │ └── metrics.py │ └── serving/ │ └── app.py └── tests/ ├── test_data.py └── test_serving.pysrc layout的好处是强制大家把代码当成一个正式的包来组织而不是一堆散落的脚本。配合pyproject.toml可以用pip install -e .把项目安装成可导入的包测试和运行时的导入路径都变得干净清晰不会出现“脚本之间靠sys.path硬凑”的尴尬。2.2 依赖管理别让“在我机器上能跑”成为常态Python项目的依赖管理是我见过的最容易埋雷的地方。很多人直接在全局环境里pip install靠一份手写的requirements.txt勉强过日子等环境一换就暴露问题。AI项目的依赖尤其复杂pytorch、cuda版本、各类数据处理库版本错一个都可能让训练彻底挂掉。我现在的基础操作是用一个工具管理虚拟环境我目前的偏好是uv快且好用venv也完全够项目里维护pyproject.toml把依赖分成运行依赖和开发依赖生成并锁定lock文件确保全组所有人安装的是同一组版本。举个例子我会在pyproject.toml里这么写[project] name my-ai-project version 0.1.0 requires-python 3.10 dependencies [ torch2.1, pandas2.0, pyyaml6.0, ] [project.optional-dependencies] dev [ pytest7.0, black, ruff, ]然后执行uv lock生成锁文件。每次有人拉代码之后用uv sync或pip install -e .[dev]所有人都在同一批版本上工作就再也不用听那句经典的“我本地跑得好好的啊”。2.3 配置管理代码与参数必须分离模型代码里硬编码超参数是我早期最深的痛。后来我认真做了配置和代码分离原则很简单代码只负责逻辑所有可能变的参数都走配置。我的做法是用YAML文件描述配置用pydantic或者dataclass做配置校验。这样训练脚本、评估脚本、服务脚本共用一套配置规范字段写错立刻报错不至于等到运行到一半才发现学习率被拼成了字符串。一个训练配置的例子# configs/train.yaml project: name: sentiment_analysis output_dir: ./runs/sentiment_v1 data: train_path: data/processed/train.parquet valid_path: data/processed/valid.parquet batch_size: 32 shuffle_seed: 42 model: name: bert-base-uncased max_length: 128 train: epochs: 3 lr: 2.0e-5 weight_decay: 0.01 grad_clip: 1.0 save_every: 1000这样做的好处非常明显每次实验改动只需要改yaml或者通过命令行覆盖特定字段不需要动代码跑完实验后这份yaml本身就是实验记录的一部分可复现性直接拉满。3. 数据管道模型没动之前最值得花时间的部分很多AI项目死得不明不白不是模型不够好而是数据管道一塌糊涂昨天能跑的数据今天多了一列空值训练集和验证集混进了重叠样本线上特征和离线特征对不上号。数据环节我建议投入大量精力因为模型训练可以重来服务挂了可以重启但数据管道一旦出了问题往往会悄悄腐蚀掉整个系统的可信度。3.1 数据版本化让每一份数据都有身份证代码有Git管理数据同样需要版本管理。完整上MLOps全家桶可能对中小团队来说太重我推荐两条务实的路线方案A简单如果数据集规模不是特别大用DVC把数据文件挂在Git之外并记录元数据方案B轻量自建如果不想引入额外工具至少做一个manifest文件记录数据文件的路径、哈希值、生成时间、生成脚本版本。我自己很长一段时间用的是方案B。每次数据管道跑完生成一份JSON格式的manifest{ version: 2025-01-17-v1, created_at: 2025-01-17T10:00:00Z, files: [ { path: data/processed/train.parquet, md5: 9a2f3b..., rows: 125000, schema_version: 3 } ], source_commit: 7f9d3e2a }这样训练代码在启动时先校验manifest和实际文件的哈希是否一致数据文件被动过立刻就知道再也不会出现“跑了一周实验最后发现数据其实被覆盖过”的惨剧。3.2 数据校验越早发现脏数据成本越低数据校验这事很多人觉得是“质检员”干的活优先级不高。但我在生产环境里吃过大亏之后把它提到了和模型评估同等重要的位置一个坏模型顶多效果差一点一份脏数据可以毁掉整轮训练甚至污染线上判断。数据校验至少要覆盖三层行数检查样本量是否符合预期区间比如昨天5万条今天变3千条一定有问题schema检查列名、类型、空值率是否匹配预设规范业务规则检查比如年龄介于0到120岁之间、金额非负、时间戳单调递增。底层工具我用的是pandera它提供了一个很简洁的声明式校验方式。下面是一个最小示例import pandera as pa schema pa.DataFrameSchema( columns{ text: pa.Column(str, nullableFalse), label: pa.Column(int, pa.Check.in_range(0, 3)), score: pa.Column(float, pa.Check.ge(0)), }, checks[ pa.Check(lambda df: len(df) 1000, error样本量不足), ], ) schema.validate(raw_df)跑不通校验训练脚本直接抛异常退出而不是带着脏数据硬跑。这能让很多潜在问题在上游被拦截而不是等模型效果崩了之后反过来查数据。3.3 数据管道的可重放性离线在线必须一致特征处理是最容易制造线上线下不一致的地方。训练时你对着整整一列历史数据做标准化线上推理时只有一个样本没法再算全量均值。这个经典问题没有偏方只有一条工程纪律把所有的特征计算逻辑封装成同一个函数或同一个算子离线训练和在线推理都调用它而不是各写一份。我把常用的数值特征处理和文本向量化封装成独立的transform模块离线批处理用一套配置调用它生成训练样本线上服务加载同样的transform逻辑。这样能保证两边算出来的特征一致不会出现训练时特征分布长这样、上线后特征值变成另一副模样的怪事。4. 训练与实验台账从“能跑”到“出问题能定位”模型训练在大多数博客里被一笔带过仿佛关键在于GPU算力。但实际上训练环节真正的工程含量在于可控性一个训练任务跑了一半崩了能不能续上跑了八十个实验能不能确定哪个超参数组合效果最好同一个实验跑两遍结果有没有复现4.1 实验记录给每个实验套上结构化账本用记事本记实验参数的做法只适合做论文的探索期不适合需要长期迭代的工程项目。工程化实验记录至少要包含三块环境信息Python版本、依赖锁文件哈希、机器类型参数信息完整的配置内容尤其是超参数结果信息训练过程的关键指标序列、最终评估指标。工具上我见过用MLflow的、用WB的也有自己搭的。我的建议是初期如果只要几十个实验的记录自己建一个“实验台账”完全够用——每次训练启动时把配置、git commit、开始时间写进一个以时间戳命名的目录训练过程把每个epoch的loss/metrics追加进JSONL文件结束时再写一份summary。这样一个实验目录的结构类似runs/experiment_20250117_153000/ ├── config.yaml ├── metrics.jsonl ├── summary.json ├── checkpoint_last.pt └── logs/train.log这套结构的好处是轻量、透明、任何文本工具都能读。等实验数量明显增长或者多人协作需要横向对比时再迁移到MLflow这类专门工具迁移成本也不会高因为信息还是那些信息。4.2 checkpoint管理给模型留好后路训练中断最让人崩溃的往往不是重来而是“重来也复现不出之前的曲线”。这通常是因为优化器的状态没被保存或者随机种子没固定。在从零构建训练循环时我会把断点续训当成默认能力来做而不是事后补丁。checkpoint不只是存模型权重至少还要包含模型参数优化器状态Adam的动量、方差如果丢了续训的效果会差不少当前epoch和全局step数随机种子状态最佳指标值。保存文件命名我习惯带step数比如checkpoint_step_12000.pt并且保留最近N份和最优的一份防止训练过程的阶段性成果被覆盖。这样即使一次实验跑了三天后在第80%挂掉也能从最近checkpoint恢复损失的只是最后几个小时的时间。4.3 对比实验的科学性先固定一切能固定的从工程角度做实验对比有个原则叫“每次只动一个变量”。很多同学做对比实验时顺手改了好几个超参数效果变好了却说不清是谁的功劳这是AI工程最典型的时间黑洞。我的具体流程是这样的先固定全局seedPython、NumPy、PyTorch分别设置搭一个最简单的baseline配置跑通并记录指标后续每次实验只修改一个想验证的维度比如只改学习率、只改batch size、只改数据增强策略其他配置保持与baseline完全一致每个配置至少跑两遍观察指标方差别被单次运行的运气欺骗。一句话实验台账能不能成为决策依据取决于你对运行结果有多少信心运行次数不够、变量不干净台账就只是账房先生的流水账帮不上忙。5. 上线部署模型走出笔记本后的第一站模型部署经常被低估。把训练好的权重放进FastAPI接口里能跑和把模型稳定地跑在生产环境里是两回事。部署阶段要考虑的不仅是“接口通不通”还有“并发来了扛不扛得住”“依赖环境干净不干净”“模型热不热”“请求数据格式有没有校验”。5.1 推理服务的正确打开方式先写个干净的FastAPI我的推理服务首选项是FastAPI理由很简单自带请求校验和OpenAPI文档性能足够生态成熟。但很多人的FastAPI写法是“把模型加载和推理逻辑全部塞进路由函数里”这会让单元测试和模型热加载都很难处理。我的做法是把服务拆成三层加载层应用启动时负责加载模型和transform逻辑业务层负责请求预处理、调用模型、后处理路由层只做HTTP层面的输入输出不掺业务。一个精简示例from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class PredictRequest(BaseModel): text: str max_length: int 128 class PredictResponse(BaseModel): label: int confidence: float model None app.on_event(startup) def load_model(): global model model load_model_from_artifact(runs/best/) app.post(/predict, response_modelPredictResponse) def predict(req: PredictRequest): features transform_text(req.text, max_lengthreq.max_length) logits model(features) label, confidence postprocess(logits) return PredictResponse(labellabel, confidenceconfidence)Pydantic的请求模型天然给了第一层校验text缺失、max_length传成字符串这类问题根本进不到业务层。5.2 容器化别让“在我环境能跑”进化成“在镜像里不能跑”Docker基本是模型部署的默认打包方式但AI模型的镜像坑尤其多。最常见的是镜像体积失控把完整pytorch、CUDA工具链一股脑装进去镜像动辄几个G拉取慢不说还增加了镜像仓库的存储压力。我先说一套务实的策略用官方Python镜像或slim版作为基础镜像不要从零手写依赖锁定文件固定到具体版本GPU环境的镜像严格对齐CUDA版本、PyTorch版本和驱动需求这三者不匹配是线上最常见的“黑盒子问题”尽量把模型权重文件作为外部挂载或独立下载而不是打进镜像避免镜像更新时反复拉几个G的数据。还有一个小技巧进入容器后的健康检查要保留。Docker配置一个HEALTHCHECK定期请求服务的探活接口这样编排平台能自动发现“服务起来了但模型没加载完”这种经典假死状态。5.3 模型加载和推理的边界情况上线之后你会遇到一批训练时根本不会注意的问题第一个请求到达时模型还在加载怎么办并发高的时候GPU显存会不会爆模型推理偶尔返回一个nan怎么办这些都得提前想好。我的应对清单包括启动探活服务对外声称ready的条件必须是模型加载完成而不是进程刚启动预热服务启动后主动发几个构造好的请求跑一遍推理让CUDA context、算子库懒加载全部完成避免第一个线上请求卡出超时超时与降级推理请求设置合理的超时时间模型出现异常单例时要有fallback逻辑而不是把异常直接甩给上游输入边界对文本长度、数值范围做显式检查别让极端输入触发模型的预测崩溃。6. 监控与迭代上线只是开始不是结束模型上线那一刻不是项目的终点甚至可以说只是“后半场”的起点。AI系统最特殊的地方在于它的行为会随着数据分布变化而退化。如果上线后不做观测、不建反馈闭环这个模型迟早会在某个深夜悄悄变蠢而你毫无感知。6.1 在线监控三部曲系统指标、业务指标、数据漂移系统指标CPU、内存、显存、QPS、延迟是基础设施但只盯这些远远不够。真正的AI系统监控要延伸到模型本身的健康度。我通常分成三层来看系统层请求量、P99延迟、错误率、GPU利用率业务层预测分布、置信度均值、各类别占比这些指标的突变往往比“CPU升高”更早暴露问题数据漂移层输入特征的分布与训练时期的分布做对比比如文本长度分布、数值特征均值和分位数发生明显变化时要触发告警。业务层和数据漂移层可以先用最朴素的方式实现每个请求的预测结果和输入摘要写日志定时跑一个统计任务对比滑动窗口内的分布与基准分布。不需要一开始就上复杂的漂移检测框架先用描述性统计撑住等确有复杂需求再加。6.2 反馈闭环线上日志是最值钱的未标注数据很多团队上线模型之后只看监控不看日志分析白白浪费了最宝贵的真实数据资产。每一行线上日志里都包含真实用户的输入和模型的输出这些数据经过筛选、脱敏、抽样后是下一轮训练最贴近线上分布的数据源。我建议至少在日志里记录这些字段{ request_id: a3f9..., timestamp: 2025-01-17T23:59:00Z, input_length: 127, pred_label: 2, confidence: 0.83, latency_ms: 87, model_version: v1.2.0 }然后定期比如每天或每周做一个“线上日志抽样分析”把高频输入类型、低置信度样本、预测分布变化记录下来。这些数据稍加清洗配上人工或规则的标注就能变成训练集的增量。这一步做到之后整个系统才真正形成了“训练—上线—观测—回流—再训练”的闭环。6.3 定期重训还是触发式重训重训策略没有绝对答案取决于数据变化的速度和成本。我个人经验分两类如果数据分布变化比较平稳、有周期性用定期重训更省心比如每周跑一次自动化训练任务如果数据漂移检测发现关键指标的偏移超过阈值则触发一次紧急重训。不管哪种方式都要配套一个“重训晋升流程”新模型先在离线评估集上达到设定门槛再做小流量灰度对比表现稳定后才全量替换。直接拿旧模型换成新模型的风险很高尤其是那些标注噪声大、反馈周期长的业务场景。7. 一些踩过坑之后才想明白的工程心得最后这段不算是技术教程更多是我在实际项目中积累的、看起来不太“硬核”但影响很大的心得体会。第一文档不是写给别人看的是写给三个月后的自己看的。AI工程项目的坑往往藏在“当时为什么这样设定”的背后如果不随手记录三个月后你自己也看不明白当时的采样策略为什么是这样。我在每个实验目录下放一个简短的README几句话说清这个实验的背景、改动点和结论信息量不大但价值极高。第二从零构建不等于所有轮子都自己造但核心链条必须亲手走一遍。找工具前先问自己如果这个工具明天没了我能不能最快地恢复同等能力我的答案往往是“能恢复大部分”因为我知道每一步在做什么。第三工程边界感很重要。一边是别过度设计一个只有几百个请求的服务不需要上完整的服务网格和混沌工程另一边是别裸奔模型一上线就完全不管。凡事看规模和风险选择匹配当前阶段的工程强度。我至今仍记得第一次把一道完整的数据管道接好后看到训练脚本从头到尾零手动干预跑完时的成就感。AI工程从零开始这件事最吸引我的不是技术本身而是那种“整个系统每一块都是我亲手搭起来坏了我知道去哪修”的掌控感。希望这篇分享也能给你一点这种方向上的参照。