1. AI工程的核心认知框架从模型到系统的思维转变先说一个我这两年感受最深的现象很多人在入门AI时第一步想到的是我要学PyTorch我要会训练模型但等到真正上手做项目、尤其是要把它放到线上环境跑起来的时候才意识到问题根本不是模型本身而是整个链条——数据怎么来、特征怎么对齐、服务怎么部署、效果怎么评估、出了偏差怎么发现。这一整条链路才是AI工程真正要回答的问题。ai-engineering-from-scratch这个项目标题本质上讲的就是这件事——不把注意力局限在某个算法的调参细节里而是从零开始把AI系统的各个组成部分逐一搭建起来。它适合的读者不是那些只想跑通一个notebook的爱好者而是真正想把AI能力做成一个稳定、可维护、可迭代的产品的工程师。如果你之前有后端开发经验或者有Python数据分析基础这套思维框架会让你少走很多弯路。1.1 AI工程与算法研究、传统开发的分野我在实际带项目的过程中常被问到一句话AI工程师到底跟算法工程师有什么区别我的理解是算法工程师的交付物是模型效果——一个精度指标、一份实验报告AI工程师的交付物是系统能力——一个延时可控、成本可算、效果可量化的服务。后者不仅包含模型本身还要处理数据漂移、服务稳定性、特征一致性这些在教科书上很少被提及、但在生产环境里几乎天天都会遇到的问题。用个生活化的类比算法工程师像是一位研究新菜谱的厨师核心是把味道调好AI工程师则更像一家餐厅的运营者——菜谱好还不够你得确保食材供应链稳定、出菜速度达标、不同门店口味一致、客人投诉有复盘机制。味道只是最终体验的一环前面后面全是工程。传统软件工程的核心是确定性——同样的输入代码执行一万次输出还是一样。AI工程里没有这种确定性模型是概率正确的数据会变效果会飘。所以AI工程不能照搬传统开发的流程它需要额外的机制来兜底数据版本管理、模型版本管理、线上线下的效果比对、灰度监控、回滚预案。这些机制在普通后端系统里不是必备的但在AI系统里缺一不可。1.2 为什么从零搭建是最快的理解路径直接上手一个成熟的AI平台比如一些AutoML工具或者现成的推理框架确实能快速出活但如果你没有经历过从零搭建的那个过程遇到问题时会非常被动。比如模型上线后效果突然变差你不知道是数据变了、特征计算逻辑对不上还是服务侧有bug。这些判断力不是在成熟平台上操作能训练出来的。从零搭建一个最小闭环意味着你要亲手处理以下这些问题数据如何采集、清洗、标注以及如何保证数据集的分布能被量化验证特征如何计算训练和推理之间的特征逻辑如何保持一致模型如何训练、如何评估以及离线指标与在线业务指标之间的映射关系推理服务如何部署、如何压测、如何做容错降级线上效果如何监控模型需要重新训练的触发条件是什么这些事情全部过一遍之后你再看任何成熟的AI平台就能看懂它每一步设计背后的用意而不是按钮在哪儿就点哪儿的盲目状态。我在后面的章节里会把一个从零搭建的最小AI工程完整拆开每一环节该做什么、为什么这么做都会讲清楚。2. 技术栈选型与工程架构设计先别急着写代码很多人在从零开始的时候第一反应是装环境、拉代码、跑demo。这个顺序其实反了。我自己的习惯是先想清楚整个系统要拆成哪几个模块模块之间怎么交互各自用什么技术方案。代码是最后才落地的。架构设计想清楚了后面的开发更多是体力活架构没想清楚后面你会发现每走一步都在打补丁。2.1 技术栈选型以Python生态为底盘AI工程的技术栈选型我的个人建议是从Python生态起步哪怕你后续要做高并发服务也可以用Python先跑通闭环再用Java、Go或者C重构性能瓶颈部分。原因很简单AI相关的工具链训练框架、数据处理库、模型评估库、推理优化工具在Python里的成熟度最高你用Python能够最小成本地贯穿全链路。一个从零搭建的AI工程典型的技术栈长这样层级推荐方案选型理由数据处理Pandas、Polars表格类特征处理方便能覆盖大部分结构化数据场景特征存储Parquet文件 特征组规范文件存储足够小规模场景统一特征组命名能避免混乱训练框架PyTorch生态完备调试灵活社区问题多可查实验追踪MLflow记录参数、指标、模型产物解决可复现性推理服务FastAPI自带OpenAPI文档异步支持好接入简单容器部署Docker Nginx环境一致性 流量入口管理模型监控Prometheus 自定义业务指标系统指标和应用指标分离开排查问题时视野清晰这个组合不是唯一答案但对于一个从零开始的项目它有几个明显的优点组件之间都是标准接口互相打通不需要额外适配社区资料丰富遇到问题搜一搜基本都能找到方案资源占用在个人电脑上跑得起来不一定非得有公司级别的GPU集群。2.2 架构分层数据、模型、服务、监控四层解耦我的架构习惯是把整个AI工程拆成四个相对独立的层数据层、模型层、服务层、监控层。每层有自己独立的生命周期层与层之间通过约定好的接口通信避免“牵一发而动全身”的紧耦合。数据层负责回答这个问题需要什么样的数据和数据长什么样。它管的是数据采集、数据清洗、数据标注、数据切分训练集、验证集、测试集这套流程。这里有个新手容易忽略的点数据层输出的不只是数据文件还要包含一份数据说明文档记录每个字段的含义、取值范围、缺失率。没有这份文档三个月后你自己都会忘记某个字段当初是怎么定义的。模型层负责回答问题用什么样的模型结构和训练策略。它包含特征工程、模型训练、超参调优、模型评估、模型导出。这一层很容易被当成AI工程的全部但在一个大工程里它只是四层之一。模型层的输出物除了模型文件还必须包含一份实验记录——用哪些数据、哪些参数、得到什么指标、踩过什么坑。服务层负责把模型变成可调用的线上能力。它包含模型加载、推理接口、预处理逻辑、并发控制、降级方案。服务层要重点处理的一个问题是训练时的特征处理函数和线上推理时的特征处理函数必须完全一致。这个问题我后面会在排查部分详细展开这是线上故障最高频的来源之一。监控层则是一个兜底机制。它持续追踪两类指标一类是系统指标请求量、延迟、内存、GPU利用率另一类是业务指标预测结果的分布、关键特征的分布变化、业务方反馈的badcase数量。没有监控层的AI系统就像没有仪表盘的汽车——开起来好像能走但你根本不知道什么时候会出问题。2.3 一个容易忽略但必须提前想的点数据版本控制传统软件工程里有代码版本控制Git已经解决了这个问题。但AI工程里模型是由数据训练出来的如果数据变了模型的产出就不可复现。所以数据本身也需要版本控制。我在早期做项目时没管这件事结果就是线上模型效果不好我想复现两周前的实验但当时用的数据已经被覆盖了。这种痛苦经历过一次就再也不想经历了。轻量级的做法不需要上一套复杂的数据平台只需要三个习惯每次训练用的数据集用固定的命名规则存一份快照比如按日期用途命名不得原地覆盖每个模型产物上登记它对应的数据版本号方便回溯时快速定位数据清洗脚本也要纳入Git管理因为清洗逻辑变了等于数据变了把所有数据文件上传到对象存储或者网盘它的优点是简单、直观、盘活历史缺点是不自动——所有操作都得靠手动执行一旦忘记就会留下漏洞。我给新手的建议是如果你的项目还在早期不必追求企业级的数据编排工具用上面这套命名规范脚本入库版本登记的轻量方案就够了。等团队变大了、数据管线变多了再上正式的数据平台不迟。因为过度设计在早期项目里往往是拖延进度的元凶。3. 核心细节解析数据、特征、训练、服务四个关键环节这一章是整篇的精华。从零搭建AI工程最怕的就是每个环节都懂一点但每个环节都做不深。我把自己做项目时的关键细节和判断依据全部摊开来讲这些都是普通教程里不太会提到的实操经验。3.1 数据处理清洗逻辑决定了效果上限我听过一句行业里的老话数据决定了效果上限模型只是逼近这个上限。做久了你就知道这句话是真的。我在做项目的时候数据清洗和特征工程的时间占比通常会超过模型调参的时间好几倍。一次完整的数据准备工作大致会经历以下流程第一步字段级探索。拿到原始数据后不要急着建模先把每个字段的描述性统计都过一遍——均值、中位数、标准差、缺失率、唯一值数量。这一步的目的是找出明显异常有些字段明明应该是数值型但里面混了文本有些字段缺失率超过了50%需要考虑是否继续使用。我会用Python脚本一次性输出这些统计信息比起肉眼翻表效率高得多。第二步缺失值处理。这里要区分随机缺失和有意义的缺失。比如一个用户上次消费距离现在的时间字段如果用户从没消费过那这个字段缺失是有实际意义的不能简单填充成0因为0会被模型理解为刚刚消费过会造成严重偏差。建议对这类字段单独造一个哑变量例如是否从未消费保留缺失本身的信息量。第三步异常值处理。异常值不等于错误值。比如在电商场景下一个订单金额是100万元虽然超出了常见区间但它可能是真实的B端采购订单不能一删了之。我的处理方式是先看异常值占比如果极低比如不到0.1%并且也没有业务上的合理性那可以选择剔除或平滑如果异常值背后有业务含义就要单独处理或保留并在文档里标注清楚。第四步数据切分。这里有一条铁律我每次必提切分数据集时必须尊重时间顺序。如果模型要预测的是未来行为那么训练集、验证集、测试集的划分就不能随机打乱否则会导致时间泄漏——模型在训练时提前看到了未来信息离线指标虚高上线后表现远差于离线评估。正确做法是按时间排序后先切测试集最末端的时间段再在剩余数据里切验证集和训练集。3.2 特征工程训练与线上一致性是第一优先级特征工程的重点是怎么从原始数据里提取对预测有用的信息并且让这些信息在训练和线上是同一套逻辑。前者属于建模问题后者属于工程问题。很多项目死就死在离线训练时AUC很高、线上表现奇差最后排查下来往往是特征计算不一致导致的。举个例子帮助理解。假设我们要预测用户是否会点击一个推荐位。原始数据里有用户上次点击时间这个字段。离线训练时因为你有完整的历史数据可以精确算出这个值但线上推理时你使用的是用户当前时刻之前的最新记录。如果你的离线切分逻辑没有严格按照每个样本只用其时间点之前的数据来计算特征那么离线阶段就会出现用未来数据算特征的情况而线上又不可能有未来数据。这种不一致会让模型在线上一上线就直接翻车。我的工程实践会把所有的特征计算逻辑封装成一组无状态的纯函数——输入一行原始记录输出该记录的特征向量。这组函数在离线训练时被调用在线推理时也复用同一套代码不另写一个线上简化版。这样就从机制上杜绝了不一致的可能。实践中这组纯函数可以做得很纯粹——不读取全局变量不依赖执行时的环境状态参数全部由调用方传入。这样离线在线复用同一套逻辑运行结果天然一致。3.3 模型训练从跑得通到有章法训练模型的环节是最容易让人自我感觉良好的——因为只要代码能跑loss在下降就仿佛一切尽在掌握中。但跑得通远远不够你需要有自己的训练章法。我把实操中比较有效的流程整理如下第一起点要低。不要一上来就上大模型、大学习率、花哨的trick。先用一个小规模的模型比如几层MLP在少量样本上过一遍全流程确认数据管线、训练循环、评估逻辑都能跑通。这一步的代价很低但能避免代码写了一星期跑起来才发现数据加载就是错的这种惨剧。第二固定随机种子。训练前固定随机种子是保证实验可复现的基础。PyTorch里需要手动设置所有相关库的种子。第三从少量样本跑通到全量样本分批逐步推进。比如先用1000条样本跑一轮确认loss收敛再用10000条样本跑一轮确认效果随数据量提升合理增长最后才上全量数据。如果全量数据的效果反而不如少量数据那说明数据里可能有异常片段需要回数据层排查而不是盲目调参。第四实验记录。每次实验记录下数据版本、特征版本、模型结构与参数、训练耗时、评估指标。我用的是MLflow因为它同时兼顾了参数记录、指标记录、模型产物管理的功能。这类工具的好处是当你做了几十轮实验之后你不会忘记哪一版模型是用哪一套配置得到的。模型调参的核心不在于搜索到最优超参数而在于理解每个参数影响的是哪个方面。比如学习率影响收敛速度与稳定性batch size影响梯度噪声与泛化特性隐藏层宽度影响模型容量、层深度影响抽象层级。带着这种理解去做调参你就是在有章法地试而不是盲目地碰到什么是什么。3.4 推理服务延迟、吞吐与容错模型训练完成之后还要解决一个问题怎么把它变成线上能调的服务。我在选推理方案的思路上习惯遵循从简到繁的原则——如果QPS要求不是特别高直接用FastAPI加载模型文件就能搞定只有当延迟指标真的扛不住的时候再考虑用ONNX、TensorRT这类推理优化方案。硬件资源也是一个大前提如果你连一块过得去的GPU都没有那么优化推理就不如优化业务本身更有价值。写一个最简单的推理服务核心代码就是加载模型 定义接口 预处理/后处理。这里有几个值得注意的细节模型加载一次放全局变量不要在每次请求时重复加载请求入口做超时控制模型推理超过阈值直接返回降级结果不能无限等待输入校验不能省线上的脏数据比训练时的脏数据形式更多样接口层要挡住关于并发Python的GIL决定了纯多线程并行推理效率不高但推理任务通常是IO密集和CPU密集的混合体使用FastAPI的async机制配合进程池或GPU推理队列能满足大部分中小规模的业务需求。如果是高并发场景现阶段也值得创建基于C或者Rust推理框架的方案但那是下一阶段优化的话题了。4. 实操过程从零构建一个AI工程的最小闭环前面讲了很多原理层面的内容这一章我完整演示一遍最小闭环是怎么搭起来的。为了更容易理解我会用一个电商场景的例子——预测用户下一个月的购买概率。这个场景足够简单数据好获取、评估指标直观、同时涵盖了数据、特征、模型、服务、监控的全流程。4.1 问题定义与指标选择做AI工程的第一步不是收集数据而是定义目标。模糊的目标带来的是无法落地的系统。预测用户下一个月的购买概率这句话看似明确但要拆成工程上可实现的方案还需要回答三个问题预测的目标是什么具体而言是否购买二分类还是购买金额回归这里先说预测是否会购买输出0-1之间的概率值方便后续采取运营动作。预测的时间窗口是什么从哪个时间点往后推30天要定义清楚。谁是这个预测系统的使用者运营团队用概率值来做用户分层那么接口要支持批量预测用户列表而不是一次只能预测一个。评估指标选择上因为是否会购买通常正负样本比例悬殊大部分用户不购买准确率会严重失真不适合做核心指标。实际更常用的是AUC排序能力和召回率在把概率最高的N个用户打标这个场景下的命中比例。AUC关注的是整体排序不错召回率关注的是业务方最关心的那部分用户有没有被抓准。定义清楚这些问题之后数据需求也就顺理成章地确定了我们需要一段历史时间窗口内的用户行为数据来训练需要当前时刻的用户特征来推理。4.2 数据管线建设实录在有明确目标之后数据的准备流程就有方向了。这个示例场景我用的数据有用户基础信息年龄、注册时长、用户行为汇总近30天/近90天的登录次数、浏览时长、加购次数、历史订单次数或金额、商品类目偏好特征等。原始数据的模拟生成不展开细说重点讲数据管线的代码结构。一个最小的数据管线大致包含以下三个组件提取脚本extract从数据库或者文件中读取原始数据输出为统一的DataFrame结构清洗脚本clean处理缺失值、异常值、格式统一特征脚本feature调用特征计算纯函数生成最终的特征宽表这里值得分享的一个习惯是以上三个步骤的代码分别放在独立的文件里用配置文件串联不要写成一个大脚本从头跑到底。因为实际项目中特征脚本会被复用训练和推理都要用清洗脚本里可能有复杂的业务规则需要单独维护。拆开之后你改任何一段都更有把握。特征宽表生成之后做一个数据快照保存记录版本号。这一步不要省它为你后续的实验复现提供了最基础的保障。4.3 训练实验的参数配置与选择训练环节我用的模型是一个简单的多层全连接网络。它的优势是结构直观、调用简单、代码量少。在最小闭环阶段不用追求网络结构的花哨重点在于把全流程跑通、建立评估基线。下面是训练脚本的关键配置逻辑这里核心需要解释的参数有三个学习率、batch size、训练轮数epoch。在实践里我会给刚入门的人几个快速起步的经验值——学习率先从1e-3开始观察loss曲线如果震荡明显就调低到1e-4如果收敛太慢就适当上调到3e-3。batch size在单机训练时取32或64通常不会有太大问题。训练轮数不要拍脑袋决定正确方法是设置早停机制每轮结束后在验证集上算AUC连续3轮AUC不再提升就提前终止防止过拟合。训练完成之后把模型产物和实验记录一并保存下来模型文件保存为统一的命名格式连带模型的评估报告和当时的超参配置一起归档形成一个可完整回溯的实验快照。4.4 在FastAPI上部署完整推理服务部署环节的完整流程如下先写一个推理接口实现输入用户ID、输出购买概率然后用Docker把服务打包成镜像保证环境一致性最后通过Nginx暴露对外访问入口。我从FastAPI接口的实现开始逐步展开。推理接口里的关键逻辑是把上一步做好的特征计算纯函数复用过来请求进来是用户ID先拉取用户特征数据也就是特征计算函数的输入调用函数得到特征向量再输入到模型得到购买概率。在样例服务里我把用户特征数据放在一个本地文件中模拟数据库。接口部分有两点需要特别说明。第一拉取用户特征数据的过程必须是独立的不能和训练时的数据处理代码写在一起否则会出现意外的依赖第二请求参数必须做校验——用户ID不存在时要返回明确的错误码而不是返回一个空概率值让上游业务方产生误解。部署到Docker的时候有几个容易踩的坑一是模型文件要打包进镜像别依赖宿主机挂载二是启动命令要带--workers参数多进程单进程扛不住线上流量三是一定要在容器里做一个health check接口方便云平台做存活检测和滚动更新。4.5 监控与迭代闭环的落地服务上线了不代表完事了。监控要做的是回答三个问题第一服务还活着吗这依赖系统指标监控——请求量、错误率、P95延迟。Prometheus采集指标Grafana做可视化这套组合在成本上是几乎为零的开销但它能让你在用户投诉前就发现问题。第二模型效果还稳定吗这依赖业务指标监控——比如每天预测为正样本的用户比例。如果这个比例突然从10%掉到3%大概率不是模型坏了而是数据分布漂移了比如运营策略变化、节假日效应、数据源字段调整。这时要回数据层排查而不是慌张重启服务。第三什么时候需要重新训练我的经验是不只以时间作为重训的触发条件而是定期 异常触发相结合。定期是指每周或每月固定训练一次异常触发是指当监控发现预测分布偏移幅度超过了合理阈值时要立即启动重训任务。5. 常见问题与排查技巧实录从零搭建AI工程一定会踩坑。下面这些坑是我在实际项目中遇到过的优先级也是在多个团队里反复排在前几名的高频问题可以直接当成排查手册来用。5.1 离线效果好、线上效果差的路由排查这是AI工程里面最经典的问题。我的排查顺序强烈建议按下面的优先级走先自查数据泄漏再核查特征一致性最后看评估指标与业务指标是否对齐。数据泄漏优先级最高。特征里是否混入了目标信息比如预测未来一个月是否购买但特征里包含了一个月后的订单信息离线指标自然高得离谱。排查方法是检查每个特征的时间戳是否严格早于样本预测起点。特征不一致第二顺位。训练和线上是否用了两套特征计算逻辑把线上的请求日志存下来用线上同样的输入数据在离线代码里重算一遍特征对比线上特征值有没有系统性偏差。指标口径错位第三顺位。离线评估用AUC线上业务看的是转化率离线AUC高不代表线上转化率提升。回到业务目标本身重新厘清核心指标到底是什么。5.2 概念漂移的识别与应对概念漂移是指数据分布随时间发生的变化导致训练时的规律不再适用于当下。识别它的信号是监控层里业务指标的大幅波动——比如用户行为特征均值连续多日发生趋势性偏移。应对方式分两步。第一步是快速止血如果漂移严重到模型完全失效要有一个预案回退到上一个稳定的模型版本或者启用基于规则的兜底策略。第二步是治本确定漂移是数据源问题还是场景业务本身演变再针对性地重训或重构训练样本。一个同事曾经给我讲过一个印象深刻的案例他们做了一个流失用户预测模型上线表现一直不错但春节期间流失预测准确率暴跌。排查后发现春节期间用户的行为模式和平时差异太大大量新用户涌入、老用户活跃度升高模型此前从未见过这种分布预测自然失灵。这是概念漂移里非常典型的周期性场景解决方案就是加入节假日特征并在节假日期间用特殊策略兜底。5.3 服务层性能瓶颈的二三事推理服务的性能瓶颈不是所有的原因都出在模型本身。有时是特征计算阶段就耗费了大量IO有时是数据校验阶段的正则表达式回溯过于耗时。定位瓶颈的正确做法是用火焰图或者profiling工具做一次性能剖析先看时间花在哪里再决定优化方向。Prediction IO的常见优化手段我之前在推理部分提到过包括特征计算结果缓存、合并请求降低网络RTT开销、模型版本预先加载而不是请求时才load、用批处理充分发挥GPU的并行能力。这些手段按性价比排序应用不要一上来就换推理框架那是最后手段而不是优先手段。5.4 训练资源不足的解法很多人问过我个人电脑做不了AI工程怎么办。说实话硬件资源确实会影响模型规模但它不该成为你从零开始搭建AI工程的障碍。我的建议路径是先用小规模数据几千条小模型几层网络在CPU上跑通全部流程。这一步验证的是你的工程链路是否通畅。然后再想办法搞GPU资源。有两种路径一种是买一块普通的消费级显卡比如3060 12G或者4070大多数中小规模模型的训练都够了另一种是考虑云GPU实例按需租用。无论哪种方式你的代码要设计成资源更大就能训练更大模型的结构——数据加载支持分批次、模型结构支持替换。这样当你有更好的资源时不需要重写工程代码。5.5 常见问题速查表症状可能原因排查动作训练loss不降学习率过大/过小、数据未归一化、标签噪声高尝试降低学习率多跑几轮、检查归一化、抽检标签离线AUC高但线上无提升特征泄漏、特征不一致、指标口径不符全量特征审查、线上特征对比、业务指标对齐服务内存持续上涨模型反复加载、中间结果集未被释放检查模型是否在请求内加载、优化批量处理内存释放线上预测值集中在单一区间特征分布偏移、模型输入标准化参数过期对比线上特征分布与训练时特征分布新数据加入后效果反而变差新数据分布与原训练分布差异大、清洗规则不一致检查新数据来源、检查清洗流程、考虑与旧数据混合训练批量请求时响应极慢单个请求被长尾请求阻塞、并发控制失效增加超时控制、优化队列处理策略、评估是否增加worker进程6. 个人实践心得与下一步扩展方向做AI工程这些年我最大的一个体会是这个领域入门不难但做深很难。入门只是学会几个框架的用法做深则要求在数据处理、系统工程、软件架构、模型原理甚至业务理解这几个维度上都有积累。没有任何一门课程能把这些全部教给你唯一的路径就是在项目中一个一个地踩坑、复盘、再踩新的坑。假如你正准备开始一段从零搭建AI工程的旅程我个人有三条朴素的建议第一条先做减法再做加法。第一版能跑通就是胜利不要指望第一次就做一个能支撑千万级流量的系统。小步快跑、快速迭代才是务实的路径。第二条把文档和记录当作一等公民。数据版本、实验记录、架构变更、踩坑经验全部都记下来。这些记录在项目早期看似是在浪费你的写码时间但在三个月之后它们会成为你最宝贵的参考资料帮你避免大量重复搜索和复盘。第三条别沉浸在跑通demo的兴奋里要逼自己走到监控与迭代这一步。只有当你亲眼看到模型上线后效果变差、然后通过监控定位到原因你才算真正理解了AI工程。模型训练真的只是这个宏大工程中的一环而已。最后再分享一个小技巧搭建自己的AI工程时我习惯把常用的功能模块比如特征计算基类、训练评估封装、服务部署模板沉淀成自己的独立工具包并统一管理配置。这样一来每启动一个新项目我不需要从零开始而是从自己沉淀的资产起步。这个习惯帮我省下的时间累计起来非常可观。希望这次的详细拆解也能帮你在自己的项目里少走一些弯路更快地建立起属于你自己的AI工程体系。
从零搭建AI工程：数据、特征、训练与推理服务全链路实践
1. AI工程的核心认知框架从模型到系统的思维转变先说一个我这两年感受最深的现象很多人在入门AI时第一步想到的是我要学PyTorch我要会训练模型但等到真正上手做项目、尤其是要把它放到线上环境跑起来的时候才意识到问题根本不是模型本身而是整个链条——数据怎么来、特征怎么对齐、服务怎么部署、效果怎么评估、出了偏差怎么发现。这一整条链路才是AI工程真正要回答的问题。ai-engineering-from-scratch这个项目标题本质上讲的就是这件事——不把注意力局限在某个算法的调参细节里而是从零开始把AI系统的各个组成部分逐一搭建起来。它适合的读者不是那些只想跑通一个notebook的爱好者而是真正想把AI能力做成一个稳定、可维护、可迭代的产品的工程师。如果你之前有后端开发经验或者有Python数据分析基础这套思维框架会让你少走很多弯路。1.1 AI工程与算法研究、传统开发的分野我在实际带项目的过程中常被问到一句话AI工程师到底跟算法工程师有什么区别我的理解是算法工程师的交付物是模型效果——一个精度指标、一份实验报告AI工程师的交付物是系统能力——一个延时可控、成本可算、效果可量化的服务。后者不仅包含模型本身还要处理数据漂移、服务稳定性、特征一致性这些在教科书上很少被提及、但在生产环境里几乎天天都会遇到的问题。用个生活化的类比算法工程师像是一位研究新菜谱的厨师核心是把味道调好AI工程师则更像一家餐厅的运营者——菜谱好还不够你得确保食材供应链稳定、出菜速度达标、不同门店口味一致、客人投诉有复盘机制。味道只是最终体验的一环前面后面全是工程。传统软件工程的核心是确定性——同样的输入代码执行一万次输出还是一样。AI工程里没有这种确定性模型是概率正确的数据会变效果会飘。所以AI工程不能照搬传统开发的流程它需要额外的机制来兜底数据版本管理、模型版本管理、线上线下的效果比对、灰度监控、回滚预案。这些机制在普通后端系统里不是必备的但在AI系统里缺一不可。1.2 为什么从零搭建是最快的理解路径直接上手一个成熟的AI平台比如一些AutoML工具或者现成的推理框架确实能快速出活但如果你没有经历过从零搭建的那个过程遇到问题时会非常被动。比如模型上线后效果突然变差你不知道是数据变了、特征计算逻辑对不上还是服务侧有bug。这些判断力不是在成熟平台上操作能训练出来的。从零搭建一个最小闭环意味着你要亲手处理以下这些问题数据如何采集、清洗、标注以及如何保证数据集的分布能被量化验证特征如何计算训练和推理之间的特征逻辑如何保持一致模型如何训练、如何评估以及离线指标与在线业务指标之间的映射关系推理服务如何部署、如何压测、如何做容错降级线上效果如何监控模型需要重新训练的触发条件是什么这些事情全部过一遍之后你再看任何成熟的AI平台就能看懂它每一步设计背后的用意而不是按钮在哪儿就点哪儿的盲目状态。我在后面的章节里会把一个从零搭建的最小AI工程完整拆开每一环节该做什么、为什么这么做都会讲清楚。2. 技术栈选型与工程架构设计先别急着写代码很多人在从零开始的时候第一反应是装环境、拉代码、跑demo。这个顺序其实反了。我自己的习惯是先想清楚整个系统要拆成哪几个模块模块之间怎么交互各自用什么技术方案。代码是最后才落地的。架构设计想清楚了后面的开发更多是体力活架构没想清楚后面你会发现每走一步都在打补丁。2.1 技术栈选型以Python生态为底盘AI工程的技术栈选型我的个人建议是从Python生态起步哪怕你后续要做高并发服务也可以用Python先跑通闭环再用Java、Go或者C重构性能瓶颈部分。原因很简单AI相关的工具链训练框架、数据处理库、模型评估库、推理优化工具在Python里的成熟度最高你用Python能够最小成本地贯穿全链路。一个从零搭建的AI工程典型的技术栈长这样层级推荐方案选型理由数据处理Pandas、Polars表格类特征处理方便能覆盖大部分结构化数据场景特征存储Parquet文件 特征组规范文件存储足够小规模场景统一特征组命名能避免混乱训练框架PyTorch生态完备调试灵活社区问题多可查实验追踪MLflow记录参数、指标、模型产物解决可复现性推理服务FastAPI自带OpenAPI文档异步支持好接入简单容器部署Docker Nginx环境一致性 流量入口管理模型监控Prometheus 自定义业务指标系统指标和应用指标分离开排查问题时视野清晰这个组合不是唯一答案但对于一个从零开始的项目它有几个明显的优点组件之间都是标准接口互相打通不需要额外适配社区资料丰富遇到问题搜一搜基本都能找到方案资源占用在个人电脑上跑得起来不一定非得有公司级别的GPU集群。2.2 架构分层数据、模型、服务、监控四层解耦我的架构习惯是把整个AI工程拆成四个相对独立的层数据层、模型层、服务层、监控层。每层有自己独立的生命周期层与层之间通过约定好的接口通信避免“牵一发而动全身”的紧耦合。数据层负责回答这个问题需要什么样的数据和数据长什么样。它管的是数据采集、数据清洗、数据标注、数据切分训练集、验证集、测试集这套流程。这里有个新手容易忽略的点数据层输出的不只是数据文件还要包含一份数据说明文档记录每个字段的含义、取值范围、缺失率。没有这份文档三个月后你自己都会忘记某个字段当初是怎么定义的。模型层负责回答问题用什么样的模型结构和训练策略。它包含特征工程、模型训练、超参调优、模型评估、模型导出。这一层很容易被当成AI工程的全部但在一个大工程里它只是四层之一。模型层的输出物除了模型文件还必须包含一份实验记录——用哪些数据、哪些参数、得到什么指标、踩过什么坑。服务层负责把模型变成可调用的线上能力。它包含模型加载、推理接口、预处理逻辑、并发控制、降级方案。服务层要重点处理的一个问题是训练时的特征处理函数和线上推理时的特征处理函数必须完全一致。这个问题我后面会在排查部分详细展开这是线上故障最高频的来源之一。监控层则是一个兜底机制。它持续追踪两类指标一类是系统指标请求量、延迟、内存、GPU利用率另一类是业务指标预测结果的分布、关键特征的分布变化、业务方反馈的badcase数量。没有监控层的AI系统就像没有仪表盘的汽车——开起来好像能走但你根本不知道什么时候会出问题。2.3 一个容易忽略但必须提前想的点数据版本控制传统软件工程里有代码版本控制Git已经解决了这个问题。但AI工程里模型是由数据训练出来的如果数据变了模型的产出就不可复现。所以数据本身也需要版本控制。我在早期做项目时没管这件事结果就是线上模型效果不好我想复现两周前的实验但当时用的数据已经被覆盖了。这种痛苦经历过一次就再也不想经历了。轻量级的做法不需要上一套复杂的数据平台只需要三个习惯每次训练用的数据集用固定的命名规则存一份快照比如按日期用途命名不得原地覆盖每个模型产物上登记它对应的数据版本号方便回溯时快速定位数据清洗脚本也要纳入Git管理因为清洗逻辑变了等于数据变了把所有数据文件上传到对象存储或者网盘它的优点是简单、直观、盘活历史缺点是不自动——所有操作都得靠手动执行一旦忘记就会留下漏洞。我给新手的建议是如果你的项目还在早期不必追求企业级的数据编排工具用上面这套命名规范脚本入库版本登记的轻量方案就够了。等团队变大了、数据管线变多了再上正式的数据平台不迟。因为过度设计在早期项目里往往是拖延进度的元凶。3. 核心细节解析数据、特征、训练、服务四个关键环节这一章是整篇的精华。从零搭建AI工程最怕的就是每个环节都懂一点但每个环节都做不深。我把自己做项目时的关键细节和判断依据全部摊开来讲这些都是普通教程里不太会提到的实操经验。3.1 数据处理清洗逻辑决定了效果上限我听过一句行业里的老话数据决定了效果上限模型只是逼近这个上限。做久了你就知道这句话是真的。我在做项目的时候数据清洗和特征工程的时间占比通常会超过模型调参的时间好几倍。一次完整的数据准备工作大致会经历以下流程第一步字段级探索。拿到原始数据后不要急着建模先把每个字段的描述性统计都过一遍——均值、中位数、标准差、缺失率、唯一值数量。这一步的目的是找出明显异常有些字段明明应该是数值型但里面混了文本有些字段缺失率超过了50%需要考虑是否继续使用。我会用Python脚本一次性输出这些统计信息比起肉眼翻表效率高得多。第二步缺失值处理。这里要区分随机缺失和有意义的缺失。比如一个用户上次消费距离现在的时间字段如果用户从没消费过那这个字段缺失是有实际意义的不能简单填充成0因为0会被模型理解为刚刚消费过会造成严重偏差。建议对这类字段单独造一个哑变量例如是否从未消费保留缺失本身的信息量。第三步异常值处理。异常值不等于错误值。比如在电商场景下一个订单金额是100万元虽然超出了常见区间但它可能是真实的B端采购订单不能一删了之。我的处理方式是先看异常值占比如果极低比如不到0.1%并且也没有业务上的合理性那可以选择剔除或平滑如果异常值背后有业务含义就要单独处理或保留并在文档里标注清楚。第四步数据切分。这里有一条铁律我每次必提切分数据集时必须尊重时间顺序。如果模型要预测的是未来行为那么训练集、验证集、测试集的划分就不能随机打乱否则会导致时间泄漏——模型在训练时提前看到了未来信息离线指标虚高上线后表现远差于离线评估。正确做法是按时间排序后先切测试集最末端的时间段再在剩余数据里切验证集和训练集。3.2 特征工程训练与线上一致性是第一优先级特征工程的重点是怎么从原始数据里提取对预测有用的信息并且让这些信息在训练和线上是同一套逻辑。前者属于建模问题后者属于工程问题。很多项目死就死在离线训练时AUC很高、线上表现奇差最后排查下来往往是特征计算不一致导致的。举个例子帮助理解。假设我们要预测用户是否会点击一个推荐位。原始数据里有用户上次点击时间这个字段。离线训练时因为你有完整的历史数据可以精确算出这个值但线上推理时你使用的是用户当前时刻之前的最新记录。如果你的离线切分逻辑没有严格按照每个样本只用其时间点之前的数据来计算特征那么离线阶段就会出现用未来数据算特征的情况而线上又不可能有未来数据。这种不一致会让模型在线上一上线就直接翻车。我的工程实践会把所有的特征计算逻辑封装成一组无状态的纯函数——输入一行原始记录输出该记录的特征向量。这组函数在离线训练时被调用在线推理时也复用同一套代码不另写一个线上简化版。这样就从机制上杜绝了不一致的可能。实践中这组纯函数可以做得很纯粹——不读取全局变量不依赖执行时的环境状态参数全部由调用方传入。这样离线在线复用同一套逻辑运行结果天然一致。3.3 模型训练从跑得通到有章法训练模型的环节是最容易让人自我感觉良好的——因为只要代码能跑loss在下降就仿佛一切尽在掌握中。但跑得通远远不够你需要有自己的训练章法。我把实操中比较有效的流程整理如下第一起点要低。不要一上来就上大模型、大学习率、花哨的trick。先用一个小规模的模型比如几层MLP在少量样本上过一遍全流程确认数据管线、训练循环、评估逻辑都能跑通。这一步的代价很低但能避免代码写了一星期跑起来才发现数据加载就是错的这种惨剧。第二固定随机种子。训练前固定随机种子是保证实验可复现的基础。PyTorch里需要手动设置所有相关库的种子。第三从少量样本跑通到全量样本分批逐步推进。比如先用1000条样本跑一轮确认loss收敛再用10000条样本跑一轮确认效果随数据量提升合理增长最后才上全量数据。如果全量数据的效果反而不如少量数据那说明数据里可能有异常片段需要回数据层排查而不是盲目调参。第四实验记录。每次实验记录下数据版本、特征版本、模型结构与参数、训练耗时、评估指标。我用的是MLflow因为它同时兼顾了参数记录、指标记录、模型产物管理的功能。这类工具的好处是当你做了几十轮实验之后你不会忘记哪一版模型是用哪一套配置得到的。模型调参的核心不在于搜索到最优超参数而在于理解每个参数影响的是哪个方面。比如学习率影响收敛速度与稳定性batch size影响梯度噪声与泛化特性隐藏层宽度影响模型容量、层深度影响抽象层级。带着这种理解去做调参你就是在有章法地试而不是盲目地碰到什么是什么。3.4 推理服务延迟、吞吐与容错模型训练完成之后还要解决一个问题怎么把它变成线上能调的服务。我在选推理方案的思路上习惯遵循从简到繁的原则——如果QPS要求不是特别高直接用FastAPI加载模型文件就能搞定只有当延迟指标真的扛不住的时候再考虑用ONNX、TensorRT这类推理优化方案。硬件资源也是一个大前提如果你连一块过得去的GPU都没有那么优化推理就不如优化业务本身更有价值。写一个最简单的推理服务核心代码就是加载模型 定义接口 预处理/后处理。这里有几个值得注意的细节模型加载一次放全局变量不要在每次请求时重复加载请求入口做超时控制模型推理超过阈值直接返回降级结果不能无限等待输入校验不能省线上的脏数据比训练时的脏数据形式更多样接口层要挡住关于并发Python的GIL决定了纯多线程并行推理效率不高但推理任务通常是IO密集和CPU密集的混合体使用FastAPI的async机制配合进程池或GPU推理队列能满足大部分中小规模的业务需求。如果是高并发场景现阶段也值得创建基于C或者Rust推理框架的方案但那是下一阶段优化的话题了。4. 实操过程从零构建一个AI工程的最小闭环前面讲了很多原理层面的内容这一章我完整演示一遍最小闭环是怎么搭起来的。为了更容易理解我会用一个电商场景的例子——预测用户下一个月的购买概率。这个场景足够简单数据好获取、评估指标直观、同时涵盖了数据、特征、模型、服务、监控的全流程。4.1 问题定义与指标选择做AI工程的第一步不是收集数据而是定义目标。模糊的目标带来的是无法落地的系统。预测用户下一个月的购买概率这句话看似明确但要拆成工程上可实现的方案还需要回答三个问题预测的目标是什么具体而言是否购买二分类还是购买金额回归这里先说预测是否会购买输出0-1之间的概率值方便后续采取运营动作。预测的时间窗口是什么从哪个时间点往后推30天要定义清楚。谁是这个预测系统的使用者运营团队用概率值来做用户分层那么接口要支持批量预测用户列表而不是一次只能预测一个。评估指标选择上因为是否会购买通常正负样本比例悬殊大部分用户不购买准确率会严重失真不适合做核心指标。实际更常用的是AUC排序能力和召回率在把概率最高的N个用户打标这个场景下的命中比例。AUC关注的是整体排序不错召回率关注的是业务方最关心的那部分用户有没有被抓准。定义清楚这些问题之后数据需求也就顺理成章地确定了我们需要一段历史时间窗口内的用户行为数据来训练需要当前时刻的用户特征来推理。4.2 数据管线建设实录在有明确目标之后数据的准备流程就有方向了。这个示例场景我用的数据有用户基础信息年龄、注册时长、用户行为汇总近30天/近90天的登录次数、浏览时长、加购次数、历史订单次数或金额、商品类目偏好特征等。原始数据的模拟生成不展开细说重点讲数据管线的代码结构。一个最小的数据管线大致包含以下三个组件提取脚本extract从数据库或者文件中读取原始数据输出为统一的DataFrame结构清洗脚本clean处理缺失值、异常值、格式统一特征脚本feature调用特征计算纯函数生成最终的特征宽表这里值得分享的一个习惯是以上三个步骤的代码分别放在独立的文件里用配置文件串联不要写成一个大脚本从头跑到底。因为实际项目中特征脚本会被复用训练和推理都要用清洗脚本里可能有复杂的业务规则需要单独维护。拆开之后你改任何一段都更有把握。特征宽表生成之后做一个数据快照保存记录版本号。这一步不要省它为你后续的实验复现提供了最基础的保障。4.3 训练实验的参数配置与选择训练环节我用的模型是一个简单的多层全连接网络。它的优势是结构直观、调用简单、代码量少。在最小闭环阶段不用追求网络结构的花哨重点在于把全流程跑通、建立评估基线。下面是训练脚本的关键配置逻辑这里核心需要解释的参数有三个学习率、batch size、训练轮数epoch。在实践里我会给刚入门的人几个快速起步的经验值——学习率先从1e-3开始观察loss曲线如果震荡明显就调低到1e-4如果收敛太慢就适当上调到3e-3。batch size在单机训练时取32或64通常不会有太大问题。训练轮数不要拍脑袋决定正确方法是设置早停机制每轮结束后在验证集上算AUC连续3轮AUC不再提升就提前终止防止过拟合。训练完成之后把模型产物和实验记录一并保存下来模型文件保存为统一的命名格式连带模型的评估报告和当时的超参配置一起归档形成一个可完整回溯的实验快照。4.4 在FastAPI上部署完整推理服务部署环节的完整流程如下先写一个推理接口实现输入用户ID、输出购买概率然后用Docker把服务打包成镜像保证环境一致性最后通过Nginx暴露对外访问入口。我从FastAPI接口的实现开始逐步展开。推理接口里的关键逻辑是把上一步做好的特征计算纯函数复用过来请求进来是用户ID先拉取用户特征数据也就是特征计算函数的输入调用函数得到特征向量再输入到模型得到购买概率。在样例服务里我把用户特征数据放在一个本地文件中模拟数据库。接口部分有两点需要特别说明。第一拉取用户特征数据的过程必须是独立的不能和训练时的数据处理代码写在一起否则会出现意外的依赖第二请求参数必须做校验——用户ID不存在时要返回明确的错误码而不是返回一个空概率值让上游业务方产生误解。部署到Docker的时候有几个容易踩的坑一是模型文件要打包进镜像别依赖宿主机挂载二是启动命令要带--workers参数多进程单进程扛不住线上流量三是一定要在容器里做一个health check接口方便云平台做存活检测和滚动更新。4.5 监控与迭代闭环的落地服务上线了不代表完事了。监控要做的是回答三个问题第一服务还活着吗这依赖系统指标监控——请求量、错误率、P95延迟。Prometheus采集指标Grafana做可视化这套组合在成本上是几乎为零的开销但它能让你在用户投诉前就发现问题。第二模型效果还稳定吗这依赖业务指标监控——比如每天预测为正样本的用户比例。如果这个比例突然从10%掉到3%大概率不是模型坏了而是数据分布漂移了比如运营策略变化、节假日效应、数据源字段调整。这时要回数据层排查而不是慌张重启服务。第三什么时候需要重新训练我的经验是不只以时间作为重训的触发条件而是定期 异常触发相结合。定期是指每周或每月固定训练一次异常触发是指当监控发现预测分布偏移幅度超过了合理阈值时要立即启动重训任务。5. 常见问题与排查技巧实录从零搭建AI工程一定会踩坑。下面这些坑是我在实际项目中遇到过的优先级也是在多个团队里反复排在前几名的高频问题可以直接当成排查手册来用。5.1 离线效果好、线上效果差的路由排查这是AI工程里面最经典的问题。我的排查顺序强烈建议按下面的优先级走先自查数据泄漏再核查特征一致性最后看评估指标与业务指标是否对齐。数据泄漏优先级最高。特征里是否混入了目标信息比如预测未来一个月是否购买但特征里包含了一个月后的订单信息离线指标自然高得离谱。排查方法是检查每个特征的时间戳是否严格早于样本预测起点。特征不一致第二顺位。训练和线上是否用了两套特征计算逻辑把线上的请求日志存下来用线上同样的输入数据在离线代码里重算一遍特征对比线上特征值有没有系统性偏差。指标口径错位第三顺位。离线评估用AUC线上业务看的是转化率离线AUC高不代表线上转化率提升。回到业务目标本身重新厘清核心指标到底是什么。5.2 概念漂移的识别与应对概念漂移是指数据分布随时间发生的变化导致训练时的规律不再适用于当下。识别它的信号是监控层里业务指标的大幅波动——比如用户行为特征均值连续多日发生趋势性偏移。应对方式分两步。第一步是快速止血如果漂移严重到模型完全失效要有一个预案回退到上一个稳定的模型版本或者启用基于规则的兜底策略。第二步是治本确定漂移是数据源问题还是场景业务本身演变再针对性地重训或重构训练样本。一个同事曾经给我讲过一个印象深刻的案例他们做了一个流失用户预测模型上线表现一直不错但春节期间流失预测准确率暴跌。排查后发现春节期间用户的行为模式和平时差异太大大量新用户涌入、老用户活跃度升高模型此前从未见过这种分布预测自然失灵。这是概念漂移里非常典型的周期性场景解决方案就是加入节假日特征并在节假日期间用特殊策略兜底。5.3 服务层性能瓶颈的二三事推理服务的性能瓶颈不是所有的原因都出在模型本身。有时是特征计算阶段就耗费了大量IO有时是数据校验阶段的正则表达式回溯过于耗时。定位瓶颈的正确做法是用火焰图或者profiling工具做一次性能剖析先看时间花在哪里再决定优化方向。Prediction IO的常见优化手段我之前在推理部分提到过包括特征计算结果缓存、合并请求降低网络RTT开销、模型版本预先加载而不是请求时才load、用批处理充分发挥GPU的并行能力。这些手段按性价比排序应用不要一上来就换推理框架那是最后手段而不是优先手段。5.4 训练资源不足的解法很多人问过我个人电脑做不了AI工程怎么办。说实话硬件资源确实会影响模型规模但它不该成为你从零开始搭建AI工程的障碍。我的建议路径是先用小规模数据几千条小模型几层网络在CPU上跑通全部流程。这一步验证的是你的工程链路是否通畅。然后再想办法搞GPU资源。有两种路径一种是买一块普通的消费级显卡比如3060 12G或者4070大多数中小规模模型的训练都够了另一种是考虑云GPU实例按需租用。无论哪种方式你的代码要设计成资源更大就能训练更大模型的结构——数据加载支持分批次、模型结构支持替换。这样当你有更好的资源时不需要重写工程代码。5.5 常见问题速查表症状可能原因排查动作训练loss不降学习率过大/过小、数据未归一化、标签噪声高尝试降低学习率多跑几轮、检查归一化、抽检标签离线AUC高但线上无提升特征泄漏、特征不一致、指标口径不符全量特征审查、线上特征对比、业务指标对齐服务内存持续上涨模型反复加载、中间结果集未被释放检查模型是否在请求内加载、优化批量处理内存释放线上预测值集中在单一区间特征分布偏移、模型输入标准化参数过期对比线上特征分布与训练时特征分布新数据加入后效果反而变差新数据分布与原训练分布差异大、清洗规则不一致检查新数据来源、检查清洗流程、考虑与旧数据混合训练批量请求时响应极慢单个请求被长尾请求阻塞、并发控制失效增加超时控制、优化队列处理策略、评估是否增加worker进程6. 个人实践心得与下一步扩展方向做AI工程这些年我最大的一个体会是这个领域入门不难但做深很难。入门只是学会几个框架的用法做深则要求在数据处理、系统工程、软件架构、模型原理甚至业务理解这几个维度上都有积累。没有任何一门课程能把这些全部教给你唯一的路径就是在项目中一个一个地踩坑、复盘、再踩新的坑。假如你正准备开始一段从零搭建AI工程的旅程我个人有三条朴素的建议第一条先做减法再做加法。第一版能跑通就是胜利不要指望第一次就做一个能支撑千万级流量的系统。小步快跑、快速迭代才是务实的路径。第二条把文档和记录当作一等公民。数据版本、实验记录、架构变更、踩坑经验全部都记下来。这些记录在项目早期看似是在浪费你的写码时间但在三个月之后它们会成为你最宝贵的参考资料帮你避免大量重复搜索和复盘。第三条别沉浸在跑通demo的兴奋里要逼自己走到监控与迭代这一步。只有当你亲眼看到模型上线后效果变差、然后通过监控定位到原因你才算真正理解了AI工程。模型训练真的只是这个宏大工程中的一环而已。最后再分享一个小技巧搭建自己的AI工程时我习惯把常用的功能模块比如特征计算基类、训练评估封装、服务部署模板沉淀成自己的独立工具包并统一管理配置。这样一来每启动一个新项目我不需要从零开始而是从自己沉淀的资产起步。这个习惯帮我省下的时间累计起来非常可观。希望这次的详细拆解也能帮你在自己的项目里少走一些弯路更快地建立起属于你自己的AI工程体系。
