1. 项目概述为什么所有人都在说 AI 工程却没人告诉你从哪下手“ai-engineering-from-scratch”这个标题翻译过来就是“从零开始搞 AI 工程”。如果你在技术社区刷到过这个词大概率已经对 AI 的炒作免疫了——你很清楚现在缺的不是“用 AI 写一首诗”的 Demo而是能把模型稳定跑在生产环境里、能解决真实业务问题的工程能力。这个项目要解决的核心问题不是教你怎么调一个 Python 库而是帮你建立一套完整的 AI 工程思维框架让你面对一个实际需求时知道第一步做什么、第二步做什么踩坑后怎么定位。我见过太多人卡在同一个地方模型训练出来挺准一上线就崩或者是数据处理花了 80% 的时间却不知道哪些步骤其实可以砍掉更常见的是GitHub 上 clone 了一堆 AI 项目跑通一个 Demo 就以为搞定了结果换一个数据集就完全跑不起来。说白了大家缺的不是 AI 知识而是工程化能力。这个项目和学习路线就是冲着“把 AI 从实验环境搬到业务场景”这个目标去的。适合谁来参考我觉得有三类人最需要一是想转型做 AI 应用开发的后端工程师二是已经在做数据分析或算法、但总觉得“差点工程味”的同学三是刚入行 AI、面对铺天盖地的模型和框架完全不知道取舍的新人。如果你是这三类中的任何一类这篇文章值得你花点时间看完。我下面所有内容都是基于自己从零搭过多个 AI 服务的实战经验不扯理论大旗只讲怎么做。2. 核心思路拆解AI 工程不是“训练模型”而是“解决问题”2.1 工程思维和算法思维的差别在哪很多教程把 AI 工程等同于“训练一个模型”这是最大的误导。我自己的体会是模型训练在整个 AI 项目里通常只占 20% 甚至更少的工作量真正消耗精力的是把一个模糊的业务需求变成可量化、可落地、可持续迭代的系统。举个很直白的例子老板说“我们要做一个垃圾评论识别系统”。如果你用算法思维来想第一反应是“用 BERT 还是用 CNN”工程思维的第一反应完全不同——先要搞清楚什么叫“垃圾评论”是包含广告链接还是纯骂人还是刷屏如果没有数据怎么收集和标注系统误判的代价有多大每天要处理的量级是百条还是百万条延迟要求是秒级还是分钟级这些没想清楚选任何一个模型都是赌运气。所以我的第一个建议是把 AI 项目当成“带概率的软件工程”来做。模块拆分、接口约定、数据流转、监控告警、灰度回滚这些传统软件工程的方法论全部适用只是多了一项不确定性——模型不可能百分百正确你的系统设计必须把这种不确定性纳入考量。2.2 完整项目生命周期怎么拆解我习惯把一个 AI 工程拆成五个阶段不管项目大小这套框架都适用阶段核心任务典型产出问题定义把业务需求转成可评估的技术目标指标定义、基线数据、成本评估数据工程采集、清洗、标注、版本管理高质量数据集、数据 Pipeline建模实验选型、训练、调优、对比Baseline 模型、实验记录部署上线服务化、性能优化、监控推理服务、告警体系迭代闭环反馈收集、定期重训版本更新、效果报告这五个阶段没有哪个能跳过但每个阶段花多少时间取决于项目特点。如果是 To B 的合同项目问题定义和数据工程往往最耗时因为需求不明确、数据质量差是常态如果是自研产品部署上线和迭代闭环可能更关键因为用户体验和响应速度决定留存率。2.3 为什么“从零开始”这个路线本身很重要市面上很多 AI 课程喜欢让你直接用现成的服务比如一键调用云厂商的 API 识别图片、生成文本。这没问题效率确实高但如果你想拥有真正的工程能力必须从零手撸一遍核心链路。原因很简单只有亲手处理过原始数据你才知道数据集为什么脏、脏在哪只有亲手部署过一个模型服务你才知道 GPU 显存为什么不够、推理延迟是怎么产生的只有亲手从零写过评估脚本你才知道你的模型“准确率高”到底是真的强还是只是因为数据分布太简单。这些认知靠调 API 永远得不到。这也是“ai-engineering-from-scratch”这个项目路线的核心价值——不是拒绝使用现成工具而是优先走一遍底层流程建立起“故障直觉”。有了这套直觉后面用任何高级工具你都知道它在帮你干什么、偷换了什么。3. 从零开始的具体路径我的五步实操法3.1 第一步锁定问题边界先建一个愚蠢的基线不要一上来就想“我要做一个智能客服”“我要做一个推荐系统”先花一个星期把问题边界搞清楚。我建议你画一张问题定义的清单至少包含以下内容输入是什么是文本、图片、语音还是结构化数据输出是什么是分类标签、数值预测还是生成一段文字正确标准怎么定人工标注规则匹配用户反馈约束条件有哪些延迟要求、成本限制、部署环境云端 / 边缘 / 离线、数据隐私要求。做完这一步先别急着上深度学习。用最朴素的方法跑一个基线统计规则、逻辑回归、关键词匹配什么简单上什么。这个基线不需要效果好它的作用是提供一个参照系——后续如果复杂模型的提升幅度不大你就能判断是数据问题、模型问题还是问题定义本身就是个伪需求。我踩过一个典型的坑花三周微调一个 Bert 模型做评论分类准确率 92%比规则方法准确率 85%只高了 7 个百分点。但规则方法的推理延迟是毫秒级、不需要 GPU、代码不到一百行而 Bert 模型需要至少 2GB 显存、延迟 20 毫秒、维护成本高得多。如果一开始就搭规则基线做对比这个账早就算明白了。3.2 第二步数据工程要当作“脏活累活”来认真对待数据质量决定了模型效果的天花板这个道理谁都听过但真正动起手来大部分人都低估了数据工程的繁琐程度。我从实践中总结数据工程必须做好下面四件事。第一数据采集要带“元信息”。只保留文本和标签是远远不够的你还要记录数据来源、采集时间、采集渠道、标注人是谁。不然你以后想做模型迭代看到效果变差根本不知道是因为数据变了还是环境变了。第二清洗规则要“显式化”。很多人清理数据靠着一堆临时脚本今天去一下换行符明天抽一下重复值后天觉得某个特征没用就删掉最后数据集变成一个黑箱。正确的姿势是把每一步清洗操作都写成可追溯的代码最好封装成独立的函数或脚本让数据加工能回放、能重现。第三标注规范要写成文档。我见过最崩溃的情况是标注团队三个人对“广告评论”的定义理解完全不一致导致训练集里一堆互相矛盾的样本。花一个下午写清楚标注指南标出正例、反例、边界情况远比事后清洗省时。第四要建立数据集版本管理。用 DVCData Version Control或者简单的快照目录都行核心目的是让每次实验关联到确切的数据版本。否则回头你想复现某个实验发现训练数据早已被后面的人改过一切白搭。关于数据处理有个常用的小技巧分享如果你是做文本类 AI 任务样例清洗时先用“统计 n-gram 频率”的方式快速抽样看数据很多异常模式格式错乱、编码问题、机器生成内容通过高频片段一眼就能看出来比写正则快得多。3.3 第三步模型选型不是越贵越好要算全链路成本模型选型是大家最兴奋的环节恰恰也是我最想泼冷水的地方。用我自己的话说模型只是 AI 系统里的一个零件选型要放在整个系统的约束之下做。表面上看选模型是选效果和参数的组合本质上选模型是在选一组利益权衡成本权衡大参数的模型效果通常更好但每一条预测的成本也可能是小模型的几十倍。如果业务毛利本来就不高上线就是亏钱。延迟权衡有些场景要求毫秒级响应比如在网页上即时给用户反馈这时候就要考虑蒸馏、量化或是把模型分拆成两级——先出便宜的粗排结果再对候选集做精排。硬件与环境权衡你的部署目标是 GPU 服务器、CPU 机器还是手机上移动端模型现在主流是 1B 以下的小参数模型加量化技术和你在服务器上用大模型完全是两套打法。我还建议做一次“模型效果与模型大小的敏感性测试”。具体方法是拿同一份数据分别训练 Mini 版、Base 版和 Large 版模型记录准确率和资源占用画一张对比表。你会发现很多时候 Base 版和 Large 版的差距只在一两个百分点但 Base 版的推理速度快 3-4 倍显存占用少了几乎一半。就凭这张表就足以说明选型该怎么做。3.4 第四步训练实验要有“记录强迫症”训练实验阶段最大的坑不是模型不收敛而是做完了之后完全无法复现——卷积层的初始种子是多少学习率调度策略是什么数据预处理是不是后来改过这些细节一多人就糊涂了。我养成的一个习惯是每次实验必须同步填写一份实验日志至少包含以下字段实验编号: 0032 时间戳: 2025-01-15 14:23 数据版本: dvc-20250112 模型结构: bert-base-uncased 超参配置: learning_rate: 2e-5 batch_size: 32 epochs: 3 warmup_ratio: 0.1 seed: 42 预处理说明: 截断长度: 128 过滤规则: 去除纯符号文本 评测结果: accuracy: 0.9233 precision: 0.9034 recall: 0.8812 f1: 0.8921 备注: 加了类别加权缓解样本不平衡这个习惯坚持三个月你就拥有了一个“实验仓库”。后续调参不再是靠玄学而是有据可查地横向对比不同配置的效果效率会提升一大截。训练时还有一个关键经验不要用默认的评估指标。分类问题默认看 accuracy但如果你做的是极度不平衡的数据比如欺诈检测正样本往往只有 1%accuracy 会骗人——模型把所有样本预测成负类准确率也高达 99%。必须结合业务场景定义指标比如欺诈场景更看重“召回率”和“精准率”宁可多拦截也不能漏过一笔。3.5 第五步部署要“两条腿走路”——先服务化再优化性能模型训练的终点不是保存一个.pt文件而是成为可供其他系统调用的服务。实践里我分成两步走。第一步先把模型用最朴素的方式封装成一个 HTTP 服务。我用过 FastAPI也用过 Triton Inference Server各有利弊方案优势劣势FastAPI 自建灵活轻量、调试方便需要自己处理并发和批处理性能上限低Triton高性能、内置动态批处理、多模型管理配置复杂、学习成本高、定制化不灵活TensorFlow Serving生态成熟、与 TF 深度绑定其他框架的模型支持需要额外转换我的建议是如果你的项目并发量低于 100 QPS、模型不超过两三个FastAPI 自己封装足够开发效率最高如果并发量高、模型多、或者需要 GPU 资源池化管理再上 Triton 不迟。过早引入重型推理框架只会徒增运维负担。部署前必须想清楚的一个问题是“模型跑在哪台机器上”如果只是少量的预测请求CPU 推理加模型量化可能就够了——一台 8 核 16G 的普通机器就能扛住中等规模的文本分类服务不需要盲目上 GPU。如果一定要 GPU建议先算一笔账单卡能跑多少 QPS预留多高的显存给文本长度突发别开到 80% 显存用量还扛高并发不然线上分分钟 OOM。第二步服务上线后要加上三件套健康检查、指标监控、错误追踪。健康检查可以用/health端点每隔几秒探一次指标至少记录推理延迟分布P50、P95、P99、QPS、显存占用、CPU 利用率错误追踪至少要记录输入数据的异常指纹比如文本内容过长、数值特征为空方便复现问题。4. 常见坑和排除实录我踩过的五个地雷4.1 数据泄漏模型“分数高”是假的有一次我做客户流失预测验证集 F1 高到太不真实0.96。结果排查发现数据预处理的脚本不小心把“客户是否已流失”这个目标列当作特征塞进了训练集。模型等于一开始就偷看了答案。这类问题在时间序列数据里更容易出现——用未来数据来预测过去。现在我的铁律是特征工程和目标变量必须分开路径处理并且在划分训练集/测试集之前就要完成绝不能先整体清洗和归一化再切分。4.2 线下验证集和线上数据分布不一致模型在测试集上效果不错上线后效果崩了。这种例子太多了。最典型的原因就是训练数据和实际线上数据存在分布漂移。比如你做文本分类训练数据以新闻文章为主而线上实际输入大量是社交媒体短文本句式完全不同模型直接抓瞎。这一点上我推荐一个实操招法上线前采样一批线上真实请求人工标注 100-200 条用来做一轮“预上线验证”。如果在这个小样本上的评估结果比线下测试集低太多就说明数据分布有差异要么补充线上数据训练要么重新看问题定义。4.3 样本不平衡直接训练模型永远不会为你干活用不平衡的数据直接训练模型往往学会偷懒——多数类学得越来越好少数类直接放弃。解决办法不只是过采样或欠采样这些老套路我常用的三个方法优先级顺序为用类别权重class weight或焦点损失focal loss让模型更关注少数类数据增强对少数类做语义保持的变换比如文本替换同义词、加大句法变换增加其训练量如果少数类样本实在少降到“异常检测”任务做用无监督或单类分类模型反而更靠谱。4.4 推理延迟高得离谱先查预处理再查模型遇到一次图像分类服务延迟 800ms开始以为是模型太大、推断太慢。结果 profiling 一查瓶颈居然在图像预处理——图片解码和缩放用了 OpenCV 的高精度模式CPU 占用接近满载光预处理就花了 500ms模型推理只占 300ms。后来改成用 TensorFlow 自带解码函数并提前压缩图片尺寸延迟直接降到 120ms。这种问题特别典型延迟优化之前必须先做 profiling不要凭感觉猜瓶颈。工具上可以用py-spy dump看 Python 调用栈、用perf看系统级热点定位后再动手优化。4.5 模型版本和特征版本没有对齐出问题无从查起另一个常见的坑是线上跑的是 2.0 版模型用的特征配置却是 1.0 版的。尤其是你把特征工程拆成了多个模块之后很容易出现“训练时用的是新特征线上加载的是旧特征”这种混乱。解决方法是每次训练时把特征处理代码版本和模型版本一起固化部署时用同一个版本号打包推送。也就是说模型和特征是一个整体不允许拆开来各自升级。5. 学习路线与关键词延展AI 工程是“慢慢变快”的过程回到“ai-engineering-from-scratch”这个项目本身它不是一个短平快的教程而是一条系统的能力成长路径。这条路径我建议你至少分三个阶段来走阶段一打基础1-2 个月。掌握 Python 数据处理三件套Pandas、NumPy、Scikit-learn理解数据清洗、特征工程、基础模型原理。这个阶段不需要碰深度学习重点是建立“从数据到模型”的完整流程感。阶段二跑通一个全流程项目2-3 个月。找一个中等难度的、贴近真实业务的需求——比如“垃圾评论识别”“故障日志分类”——从数据采集到上线部署完整做一遍尽量别用现成服务自己动手。阶段三做优化与高并发1-2 个月。在阶段二的项目基础上升级加批量推理、异步处理、模型量化、多线程优化目标是让系统在保证效果的同时扛得住每天百万级调用。这个阶段才是区分“能跑 Demo”和“能做 AI 工程”的分水岭。对应的关键词和技术点我整理成一张速查表关键词作用我推荐的下手工具数据管道让数据流动可追溯Prefect、Airflow小项目直接用 Python 脚本特征存储统一特征定义与线上调用Feast起步用 Redis 特征表也行模型实验管理记录实验过程并复现MLflow轻量够用模型服务化提供稳定的推理接口FastAPI → Triton模型监控追踪效果、指标、漂移Prometheus Grafana加上自定义漂移检测脚本我这套路径最大的特点是“不突击不魔改”它强调的不是让你三个月速成“10 年经验”而是帮你把一个 AI 项目的坑都从头踩一遍等你上战场的时候能分辨出哪些是表现问题、哪些是数据问题、哪些是架构问题。从零开始不是最省力的路却是最不容易走歪的路。6. 我在实际操作中的一点体会做了这么多 AI 工程落地项目最大的感触是这个领域最稀缺的其实不是模型而是对整条链条的把控能力。数据怎么来、业务指标怎么定、模型上线后怎么运营和迭代任何一个环节松了整个系统都会垮掉、而且往往垮在一两月后发现不了的位置。与其追求“我也训了一个大模型”这种表象不如把一个朴素模型认真打磨做到稳定、可控、成本合理这本身就是一件门槛相当高的工程工作。另外分享一个我反复使用的小技巧每次接手一个 AI 项目先写一份一页纸的方案说明内容包括业务背景、目标指标、数据来源、模型方向、上线计划、风险点。不要小看这份文档它是你之后所有决策的依据也是团队对齐认知的工具。很多项目失败不是死在技术上而是死在所有人对目标的认知不一致上这份文档能救你的命。如果你目前在自学那就从今天着手选一个不依赖外部资源的小数据集完整走一遍数据清洗、模型训练、服务化部署的闭环。中间过程无论多手忙脚乱都把它记下来。这条路你只要完整走过一次后面再看到任何新框架、新模型你都会知道它属于链条上的哪个环节该用什么姿势去学这比到处刷教程有用得多。从零开始不是纯硬熬它是用一次较长的上坡换后面每一段路的平稳下坡这笔账越早算越划算。