“ai-engineering-from-scratch”这个题目我第一次看到的时候心里想的是终于有人把“AI工程”和“AI算法”这两件事分开了。这两年“AI engineering”这个词在技术社区里出现频率越来越高但大部分人的第一反应还是先去刷几个模型结构、跑通一两段开源代码然后觉得自己已经算入门了。等真把一个模型放到线上被数据、评估、部署、监控这些东西轮番折腾一遍才发现前面那点积累根本不够看。这篇文章我想从自己的实践经验出发把“从零开始做AI工程”这件事拆开揉碎讲清楚它到底要解决什么问题核心链路是什么最容易踩的坑在哪里以及一条比较稳的学习路线。不管你是刚转行的算法工程师还是想往AI方向靠的后端、数据开发这都应该能帮你少走不少弯路。1. 从零开始先弄清楚AI工程到底在“工程”什么1.1 模型不等于系统AI工程的第一课我见过太多团队在项目启动时把全部精力押在“训练出一个更高精度的模型”上仿佛模型指标一上来产品就成功了。但真实情况是落地一个AI功能模型只是其中一环而且往往不是最耗时的一环。一个能稳定运行的AI服务至少由这几块拼成数据采集与清洗、训练与评估、服务化接口、线上监控、失败兜底、迭代机制。拿汽车来类比模型是发动机但AI工程是整车——你光把发动机做得再猛没有底盘、转向、刹车车还是不能开上路。我自己带过几个项目最深的体会是训练模型可能只占整个项目周期的两到三成剩下的时间全在跟数据较劲、跟评估指标较劲、跟线上诡异的行为较劲。如果你一开始就把“AI工程”理解成“AI建模”后面大概率会被现实教育。1.2 能力地图一个AI工程师需要覆盖的六个层面“从零开始”真正难的不是某一个技术点而是你心里有没有一张完整的能力地图。我按自己的习惯把它分成六层每一层对应不同的问题和工具层级要解决的问题我常用的工具/技能数据层数据从哪来、质量如何、怎么保证可复现SQL、pandas、dvc、Label Studio实验层模型怎么训练、怎么调参、怎么对比PyTorch、scikit-learn、MLflow服务层模型怎么被业务方稳定调用FastAPI、TensorFlow Serving、Docker可靠层线上效果怎么量化、怎么发现恶化Prometheus、Evidently、自定义监控脚本迭代层数据闭环怎么转起来、重训怎么触发Airflow、Cron、版本化Pipeline协同层多人怎么协作而不互相踩脚Git、Code Review、模型注册表这张表不是让你一次性全学会而是让你在动手之前就有个全局概念我做任何一步都要能回答“它在这六个层面里属于哪一块、前后依赖谁”。这么想问题你搭出来的东西才不是一堆孤立脚本的拼凑而是一个成体系的系统。2. 最小可用AI服务从数据集到接口的完整搭建2.1 先锁定一个窄问题领域与目标函数理论学习可以铺得很开但动手实践一定要从一个极窄的问题开始。我建议你自己选一个小而真实的场景例如“给客服工单按紧急程度打标”输入是一段客户反馈文本输出是“紧急/普通/咨询”三分类。窄问题的好处是数据可控、评估指标清晰、端到端链路短你能在几天内看到全貌。在动手之前先把成功标准写下来。比如紧急工单的召回率不低于90%漏掉紧急工单代价最大整体准确率不低于85%单次预测延迟在200ms以内每天需要人工复核的比例低于20%这一步看起来简单但实际上最重要。目标函数定义错了后面所有工程动作都是白做。我见过一个项目把“准确率”当唯一指标结果模型为了准确率把稀有但致命的坏样本全部判成正常上线第一天就把业务方得罪了。所以先定义清楚“什么叫做得好”再谈怎么做。2.2 数据管线的工程化处理很多新手拿到数据直接就开始train_test_split这是个大坑。数据管线至少要处理这几件事去重、清洗、标注一致性校验、防止时间泄漏。我通常会用一段简单的Python脚本先跑通流程import pandas as pd from sklearn.model_selection import train_test_split df pd.read_csv(tickets.csv) # 1. 去重同一个用户重复提交的工单只保留最早一条 df df.drop_duplicates(subset[content], keepfirst) # 2. 清洗去除空值、无意义短文本 df df[df[content].str.len() 4].dropna(subset[label]) # 3. 按时间切分避免时间泄漏 df df.sort_values(created_at) train, temp train_test_split(df, test_size0.3, shuffleFalse) val, test train_test_split(temp, test_size0.5, shuffleFalse) print(train.shape, val.shape, test.shape)这里有两件事新手最容易忽略一是去重线上用户会产生大量重复反馈模型见过重复样本之后会“作弊式”地记住文本而不是学习规律二是按时间切分如果不打散时间顺序你等于拿未来数据去预测过去离线指标会虚高上线立刻现原形。标注一致性是另一个隐蔽问题。两个人标注“这个反馈算不算紧急”可能分歧很大。我的做法是先让两个人独立标同样的200条样本计算标注一致率低于85%就说明分类定义本身不清楚回去改标注规范而不是急着训模型。数据质量不行后面模型再强也是白搭。2.3 模型选型的逻辑不是越新越好数据管线就绪后很多人急着上BERT、上大模型但我的建议是先做一个最简单的baseline。对于文本三分类TF-IDF加逻辑回归通常已经能跑到80%以上的准确率而且训练快、可解释、部署成本低。有了这个baseline你才知道复杂模型到底值不值得上。方案可解释性训练成本推理延迟适合场景TF-IDF LR高极低毫秒级文本分类、小样本快速验证小型预训练模型中中等几十毫秒数据量中等、语义复杂大模型微调/提示低高数百毫秒以上语义理解极强、数据量很大我处理这类任务时会先用TF-IDF LR跑通全链路再视情况换更复杂的模型。这样做有两个好处一是链路尽早打通后面的部署、监控、迭代逻辑不会因为“模型太复杂”而阻塞二是你手里有一个对比基准后面换模型后能明确说出“提升到底值不值这个成本”。3. 评估、失败模式与数据漂移AI工程和传统软件最大的分水岭3.1 离线和在线评估的落差做传统软件开发时功能和Bug是相对确定的测试过了就是过了。但AI系统不一样你在离线评测集上看到的指标和线上真实分布的指标可以差得很远。原因很简单你评测时用的是“过去某个时间段的数据”而线上系统面对的是“不断变化的新数据”。用户表达方式会变、业务规则会变、甚至数据采集方式变了都会导致分布漂移。我有一次上线一个文本分类模型离线AUC做到0.95自认为很稳。结果线上跑了一周准确率直接掉了七八个点。查下来发现离线测试集用的是三个月内的工单但线上进来的新工单里出现了大量新的产品名和口语化表达模型从来没见过这些词。从那以后我对“离线指标高”这件事始终保持警惕。3.2 数据漂移的监测与处理数据漂移是AI工程里最需要持续盯的事情但也是最容易被忽视的事情。简单说漂移分两种特征漂移指模型输入本身的分布变了概念漂移指同样的输入对应的正确答案变了比如公司突然改了紧急工单的定义之前“无法登录”是紧急现在有专门的快速通道后不再算紧急。我的监测做法是每天统计线上预测样本的特征分布和训练集做对比。常用的指标包括PSI群体稳定性指数和KL散度也可以用更直观的方式比如看某个关键特征的均值、分位数是否偏离。例如在工单分类任务里我会盯“工单长度分布”和“高频词Top50变化”一旦发现显著偏移就告警出来。import numpy as np def calculate_psi(expected, actual, buckets10): expected np.array(expected) actual np.array(actual) # 按分位数切分 breaks np.percentile(expected, np.linspace(0, 100, buckets 1)) breaks[0] -np.inf breaks[-1] np.inf exp_counts np.histogram(expected, binsbreaks)[0] 1e-6 act_counts np.histogram(actual, binsbreaks)[0] 1e-6 exp_ratio exp_counts / exp_counts.sum() act_ratio act_counts / act_counts.sum() psi np.sum((act_ratio - exp_ratio) * np.log(act_ratio / exp_ratio)) return psi经验值是PSI小于0.1表示稳定0.1到0.2需要留意大于0.2基本可以判定漂移严重。触发告警后不是马上重训而是先人工复核一批bad case搞清楚是数据质量问题、业务规则变了还是真的需要重新采集标注数据。看到漂移就盲目重训往往会把偶尔的噪声当成趋势白白浪费算力和人力。3.3 失败模式的分类与预案除了整体指标我还会专门给AI系统定义“失败模式”。这词听起来复杂其实就是问自己模型会以哪些方式出错每种错误发生后系统该怎么办我通常先建一个表格来梳理发现情况可能原因应对动作置信度低于0.5的预测占比升高输入分布漂移、新类型样本出现自动转入人工队列每天抽样分析紧急工单被判定为普通概念漂移或标注噪声提高紧急类的重采样权重补充标注高频词突然变化业务热点事件暂时增加人工复核比例不急着重训单特征缺失比例上升上游数据接口异常先查数据链路而不是动模型把失败模式列清楚之后AI系统就不再是一个“黑箱赌运气”的东西而是变成一套有兜底机制的服务。这也是我认为AI工程和传统软件开发最像的地方你不是追求模型永远不会错而是让每种错误都有预案整个系统在出错时依然可控。4. 从Notebook到生产环境部署、监控与迭代的实战经验4.1 Notebook思维与工程思维的差距Notebook是探索利器但绝对不是交付物。我经常看到有人把训练好的模型权重往共享文件夹一扔然后写个接口草草上线过两周想复现结果时发现谁也说不清当时的数据版本、参数、训练脚本是哪一份。这就是典型的Notebook思维。工程思维要求你做三件事依赖锁定、模型可追溯、服务可回滚。依赖锁定的意思是Python环境和包版本必须通过requirements.txt或conda环境完整记录而不是“我机器上能跑就行”。模型可追溯是说你上线的不光是模型权重还要记录它对应的训练数据版本、代码版本、超参数最好用一个模型注册表统一管起来。服务可回滚则是说新模型上线后如果监控指标恶化必须能在几分钟内切回旧版本。4.2 部署形态的选择API服务、批处理还是边缘端很多人觉得部署就是把模型挂成一个HTTP接口实际上部署形态要根据业务需求选。三类形态各有各的适用场景部署形态延迟要求成本特征更新频率典型场景API服务实时百毫秒级常驻资源成本高可频繁更新在线客服、实时风控批处理任务分钟到小时级按需运行成本低低频更新每日报表、批量审核边缘端离线运行设备资源受限更新慢要谨慎移动App、IoT设备我大多数项目会先用API服务把链路跑通但如果是数据量巨大、实时性要求不高的场景我一律建议走批处理。批处理的好处不只是省钱更重要的是它天然适合“每天人工复核一批结果”的工作流第一天模型预测完第二天人工检查发现问题可以及时调整。4.3 模型上线只是开始监控指标与版本管理我见过太多团队模型上线那天锣鼓喧天之后一个月没人再看一眼。正确的姿势是从第一天就开始盯四类指标业务指标比如工单自动分派的准确率、系统指标延迟、QPS、错误率、数据漂移指标特征分布、PSI和运营指标人工复核率、用户投诉率。把这些指标放到La这样一套监控机制建立起来后你会发现AI系统变成一个可以持续维护的生命体而不是上线即终结的“一次性消费品”。5. 学习路线与常见误区零基础怎么走更稳5.1 分阶段学习路径别一上来就啃深度学习很多人学习AI工程喜欢从“深度学习入门”开始我反而建议顺序反过来。先学数据操作再跑通全链路最后再深入模型细节。具体路径大概是阶段一花一两周把pandas、SQL这些数据操作练熟这是所有AI工程的底座。阶段二选一个分类任务从数据清洗到训练再到接口部署强行跑通一遍流程。阶段三给全链路加上评估、监控、告警让系统“可观测”。阶段四再回去系统补模型原理你会发现看理论清晰得多因为你已经知道每个理论是解决什么问题的。阶段五尝试做迭代闭环也就是根据线上bad case定期重训模型逐步把人工复核率降下来。这个顺序我试过两次一次是自己一次是带新人效果都很好。它最大的优势是你始终知道“学这个有什么用”而不是在抽象的理论里迷失方向。5.2 我见过最多的几个“从零开始”误区踩过足够多坑后有些误区几乎是每个新手都会犯的。我列举几个最有代表性的只卷模型不看数据花几周换模型结构提升0.5%却从不在数据质量上花时间。实际上数据清洗带来的提升常常远大于模型调参。跳过baseline直接上复杂方案没有简单模型的对比你没法判断复杂模型是真提升还是偶然波动。把Notebook当线上代码没有依赖锁定、没有版本管理、没有监控代码在本地能跑完全不代表能在线上稳定运行。用随机划分代替时间划分时间序列场景里随机切分会让模型“偷看未来”离线指标虚高上线立刻现原形。上线后完全不看监控模型上线不是终点而是监控与迭代的起点这部分我在前面已经反复强调过了。这些误区看起来都很基础但在实际项目中它们每天都在发生。我自己的经验是一个人如果能主动避开上面任意三条交付的AI系统质量就已经能超过大多数团队。最后说点个人的体会。做AI工程这几年我最大的感受是这个方向真正考验人的不是你能不能把某个模型的AUC刷到多高而是你有没有办法让一个AI功能在真实业务里稳定、可控、可迭代地运行下去。把“从零到一”跑通、再看住“一到一百”的稳定性这个能力比任何单个算法技巧都值钱。希望这篇东西能帮你把那条路看得更清楚一些。