from scratch这个短语在AI工程圈子里有一种天然的分量感。市面上教你三分钟训练一个模型的内容很多但真正把AI工程说清楚的路径很少——因为从零起步的人最缺的不是代码技巧而是对整个工程链路的全局认知。ai-engineering-from-scratch想表达的正是这种状态不是从调包开始而是从问题定义、数据理解、模型选型、训练评估、部署运维一路打通最后形成一个真正能跑的AI系统。这篇文章就是围绕这条路来写的适合准备进入AI工程领域的新人也适合已经在做算法但一直觉得模型上线很难的工程师。1. 先想清楚AI工程到底在解决什么问题1.1 AI工程不是AI研究也不是纯软件开发很多人刚接触这个概念时会把AI工程和算法研究混在一起我见过不少开发者的第一反应是AI工程是不是要把数学功底练到能推导新模型完全不是。AI工程的核心问题从来不是发明新算法而是让已有算法稳定、可靠、低成本地跑在真实业务里。换句话说AI研究解决的是模型能不能识别猫AI工程解决的是这个识别猫的系统能否每天处理一百万张图片、在200毫秒内返回结果、并且在数据分布变化后还能保持效果。这种区别在落地时极其明显。研究环境下一个模型的精度小幅提升就能发论文工程环境下精度的提升如果带来了延迟翻倍、显存暴涨或者推理成本上升那这个提升就没有任何产品价值。我接手过的多个AI项目都验证过这件事算法同学给出的SOTA模型在离线数据集上效果漂亮一旦接入真实流量就问题不断——不是模型变笨了而是工程链路跟不上。这其实是AI工程和算法研究的分水岭研究追求上限工程守护下限。所以从零学AI工程第一件要做的事是培养工程思维。什么是工程思维就是拿到一个需求时先不急着翻论文、选模型而是先问线上环境是什么约束数据从哪里来延迟、成本、准确率的优先级怎么排出现Bad Case时靠什么机制兜底这个习惯越早建立后面踩的坑越少。1.2 从标题拆解一条完整的学习主线如果只看ai-engineering-from-scratch这个标题可以拆出三个关键词ai人工智能技术、engineering工程技术、from scratch从零开始。这三个词合在一起实际上给出了一条明确的学习结构先从业务场景提炼问题再围绕问题搭建数据体系然后选择合适的模型并完成训练与评估最后把模型封装成服务并持续迭代。我把它总结成五个环节业务定义、数据工程、模型工程、部署工程、迭代治理。业务定义是搞清楚要做的事值不值得做数据工程是解决吃什么模型工程解决怎么学部署工程解决怎么用迭代治理解决怎么长期活。完整走一遍这五环才算入门AI工程任何一个环节是短板系统性翻车只是时间问题。这里要特别提醒一点不少人学习时把大量时间砸在模型训练上数据、部署、治理全都往后放。这在学习阶段还能接受一旦真进入项目数据质量往往决定模型效果的70%以上部署方案决定落地成本的70%以上。所以从scratch开始就应该按工程全链路来学而不是按照课本里机器学习—深度学习—强化学习的学术顺序走。2. 从零上手工具链和学习路线的选型逻辑2.1 基础工具链怎么选AI工程涉及的技术栈比较杂但启动并不需要一开始就把所有东西铺开。我用下来的建议是Python PyTorch Docker FastAPI PostgreSQL/对象存储这套组合可以在零成本的前提下覆盖从数据处理到服务部署的完整链路。选择Python没有争议生态最全团队协作成本低。PyTorch之所以是首选而不推荐TensorFlow主要原因是它的调试体验更符合工程习惯——你可以用正常的print和断点去看中间结果这对新手极其友好。Docker解决的是环境一致性问题我见过太多在我电脑上能跑的尴尬场景只要把训练环境做成镜像这种问题基本绝迹。FastAPI则负责把模型包装成HTTP接口它自动生成API文档、性能好、写起来简单非常适合模型服务这种场景。数据存储方面早期项目不必追求复杂的数仓体系一个PostgreSQL加一个对象存储或者本地文件系统就够了。PostgreSQL存结构化数据对象存储存图片、音频、文本原始文件。很多教程会推荐直接上Spark或Flink这属于严重的过度设计——数据量还没到那一步你真正要练的是理解数据、清洗数据、管理数据的能力而不是操作大数据框架的能力。2.2 学习路线的合理顺序结合我自己带人和自学的经历从零到可以独立完成端到端AI项目最顺的路线是分四个阶段走。第一阶段是掌握Python和基础数据处理。核心是pandas和SQL达到能独立完成数据清洗、聚合、统计的水平。这个阶段不碰模型只碰数据。第二阶段是机器学习基础。建议从sklearn入手理解分类、回归、聚类三大任务类型掌握交叉验证、特征工程、过拟合这些概念。这里不需要手推复杂公式但要对模型是怎么学出来的有个直觉。第三阶段才是深度学习。用PyTorch从零手写一个两层MLP、一个CNN、一个简单的Transformer把前向传播、反向传播、损失函数这些黑盒打开一遍。这个阶段最忌讳的是只调库不写代码哪怕写得丑也没关系手写一遍的印象远胜于看十遍教程。第四阶段是部署与上线实践。用FastAPI封装一个训练好的模型写Dockerfile构建镜像部署到一台服务器上跑起来然后用Prometheus或简单的日志监控采集指标。走完这四步你对AI工程的体验就完整了。很多人学了前三个阶段后依然觉得AI工程是个玄学问题就出在缺了第四阶段——只有当你亲手把一个模型变成线上服务并且肉眼看到请求日志、错误率、响应延迟这些真实指标时工程化的感觉才会落下来。2.3 为什么说先跑通再深挖比系统学习更有效我见过两种典型的学习风格一种是想把所有数学基础、数据结构、算法原理全部学完再上手项目另一种是拿到一个目标直接开始做缺什么补什么。在AI工程这个领域我强烈建议采用第二种。原因很简单AI工程的知识树非常庞大如果不知道实际项目会用到哪些知识很容易在细枝末节上消耗大量时间比如在看Boosting原理时死磕公式推导但实际工作中你只需要知道什么时候用XGBoost、怎么调几个关键参数。先跑通一个端到端项目再反过来根据项目中暴露的问题补充理论这样学习效率会高得多。举个例子当你真的遇到训练集和测试集分布不一致导致线上效果崩塌时再去读关于数据分布漂移的资料那种理解深度是任何教程都给不了的。我正在接触的一位学员就是这样她用了三周时间把一整套商品评论情感分析服务跑上线过程中补了特征工程、模型调优、Docker部署三块知识效果比之前闷头看两个月书好太多。3. 核心实操一个端到端AI项目的完整过程3.1 项目定义与方案设计为了把工程链路讲明白我以客服工单自动分类系统为例完整走一遍从零搭建的过程。这个项目非常典型业务目标清晰、数据容易获取可以自己造或者用开源数据集、模型不复杂但需要工程化处理特别适合用来演示AI工程全流程。第一步是定义问题和评估口径。客服工单自动分类就是把工单文本分成售后退换技术支持物流查询投诉建议等类别方便后续自动路由到对应处理小组。这里有一个非常关键的思路不要上来就追求模型精度达到99%而是先定义一个明确的业务成功指标。我做的是人工复检率——系统自动分类后只有抽检或置信度低于阈值的工单才需要人工介入。目标是让人工介入比例从100%降到40%左右同时分类准确率不低于90%这就比单纯追求一个学术指标有意义得多。3.2 数据采集、清洗与标注的实操要点这个项目的数据来源可以用公开的电商客服对话数据集也可以自己模拟。但无论来源哪里工程上都有一套标准处理流程。原始数据通常是CSV格式包含工单编号、用户描述、受理时间、处理结果等字段。拿到手的第一步是数据探查我会先做三件事看缺失值比例、看类别分布、看文本长度分布。前两件事通常好理解第三件事很多人会忽略。客服工单的文本长度差异极大短的只有几个字比如退钱长的可能是一大段描述。如果不做长度分布分析直接塞进模型短文本很容易被模型强行截断或补齐影响效果。我在这个环节的具体策略是保留原始字段同时增加一列归一化文本用规则做基础清洗去掉特殊符号、统一大小写、处理重复标点、把常见繁体替换为简体。类别分布问题同样要重点处理。客服工单里物流查询往往占一半以上投诉建议却可能只有5%。如果直接训练模型会对小类别严重不敏感。我采用的方案不是简单地过采样而是先算出每个类别的最低样本阈值再结合类别权重做训练。对于严重不足的类别还需要补充标注数据。在标注环节我的经验是哪怕用开源工具或人工粗标也至少要保证每个类别有几百条高质量样本而且标注规范要尽量统一。标注质量参差不齐后面很难排查问题到底出在模型还是出在数据。3.3 特征工程与模型选型的实际选择在这个项目中文本表示方案我对比了三种TF-IDF 线性模型、预训练模型嵌入 分类头、微调完整预训练模型。最终选的是第二种。原因是TF-IDF 线性模型虽然训练快、部署轻但在同义词、口语化表达上比较吃力微调完整预训练模型效果最好但对硬件和推理成本的要求都比较高对内部工具型项目来说有点浪费。预训练模型嵌入 分类头的方案是当前工程落地中性价比极高的选择用sentence-transformers或者直接取BERT的[CLS]向量把文本变成固定维度的向量然后接一个简单的MLP分类器。这样一来主干网络不需要训练或只需要浅层微调训练速度很快模型体积也小得多。训练时我通常会设置一个验证集策略按时间切分而不是随机切分。客服工单有很强的时间演进性——用户会不断发明新的表述方式产品政策也在变。如果只做随机切分验证集与训练集高度同分布线上效果会被严重高估。按时间切分才能模拟真实的预测场景这是工程判断里很重要的一环。3.4 模型服务的封装与部署模型训练完成后工程之路才走了一半接下来的部署环节才是很多新人翻车的重灾区。我在这里给出一个最简单但足够稳的部署方案用FastAPI封装推理接口使用Docker打包成镜像通过docker-compose管理外部依赖。在封装接口时很多人关注的是怎么调用模型但真正要提前想好的问题有三个输入数据如何校验和预处理、异常情况返回什么结构、如何统计每次预测的耗时和置信度。这三个问题如果不提前设计好写第一版时会很爽上线后会发现日志完全没法看。比如用户传了一个空字符串模型会报错还是返回默认分类再比如模型推理偶尔会很慢如何设置超时这些细节都必须在接口层面兜住。Docker部署的一个常见误区是把模型文件打进镜像就完事。模型文件动辄几百MB甚至几GB每次修改代码都要重新构建镜像非常痛苦。我建议的方式是镜像只装代码和依赖模型文件通过挂载卷或者对象存储路径访问。这样模型更新只需要替换文件不用重新build镜像迭代速度会快很多。FastAPI的启动命令要注意设置超时和最大请求体大小避免前端拿到长时间无响应的异常。部署完成后第一步测试不是直接压测而是先拿几条真实工单跑一遍确认接口返回正常、延迟可控。3.5 评估体系与上线后的指标观察上线不等于结束评估体系才是工程闭环的开始。这个项目的评估指标我分成三层首先是模型层看准确率、召回率、F1重点观察每个类别的单独表现其次是服务层看接口的响应时间、错误率、QPS确保系统稳定最后是业务层追踪人工复检率、处理时效提升、用户满意度变化。这三层缺一不可很多团队只盯第一层结果模型离线指标很好线上却业务价值寥寥。上线后我还会设置一个置信度阈值机制当模型对某条工单的预测概率低于0.8时自动转入人工处理不直接归类。这个机制虽然让自动分类率看起来低了一些但大幅降低了错误分类带来的业务风险。在早期宁可多让人工介入也要保证系统输出可信这是AI工程中需要反复强调的一种取舍——不是所有事情都要自动化而是在对的地方自动化。4. 常见问题与排查技巧实录4.1 数据问题导致的训练集效果很好、线上全面崩溃这是我见过最多的一类问题出现的频率远高于模型本身的问题。最典型的原因是数据切分方式不科学——很多新手拿到数据后习惯用train_test_split做随机划分但业务场景中的数据几乎都带有时间或用户偏好特征。随机划分会让训练集和测试集的数据分布极其相似模型在这种测试集上的表现自然很好线上面对真实的新数据时就露馅了。解决思路也不复杂优先按时间切分或者按某个与业务强相关的维度切分。比如客服工单按日期排序后用前80%做训练、后20%做验证。另外一个隐蔽的坑是标签泄漏清洗数据时用了整条记录里的某个字段作为预测目标但该字段实际上只在事后才会产生。排查时要逐个字段检查特征是否真的可以在预测时刻获得一旦发现泄漏就必须把这个字段从特征里删掉。4.2 推理延迟过高怎么定位和优化模型接口响应慢可能的原因链条很长。我个人的排查顺序是先看网络链路再看数据预处理最后看模型推理。其中数据预处理的问题最容易被忽视——比如每次请求都把原始文本重新分词、过滤、转ID这些步骤在离线脚本里用着流畅在线高并发时却会成为瓶颈。优化策略很实用把静态词典、分词结果、中间特征做成预计算缓存文本长度做截断或短文本补齐时用向量化操作而不是逐条循环如果模型中包含多重循环或递归结构考虑改用矩阵运算或预训练库的高效实现。还有一招很有效——为推理配置单独的GPU或CPU线程池但这个问题在新手项目中不常遇到。真要压测时可以用locust或wrk但要注意压测不能只跑几十个请求就结束至少要跑到超出预计峰值的水平才能暴露出模型并发推理时的真实瓶颈。4.3 长尾类别永远学不好怎么办客服工单分类里投诉建议这类样本少而多样是标准的难学长尾类别。提升它的常用操作有几个一是补充数据从历史工单里用关键词检索出更多相关样本二是调整损失函数比如用focal loss让模型更关注难样本三是做半监督方法比如用置信度高的预测结果进行伪标注扩充训练集。前两种我都很常用第三种要谨慎伪标注数据如果本身错误率较高反而会污染训练集。还有一个容易被忽略的点长尾类别在线上更容易出现新的表达方式。比如以前用户只会写投诉现在会出现平台竟然这样对我。这种问题不是靠模型能彻底解决的必须配合规则接口或者定期增量更新。所以工程上我会在分类接口里保留一个其他兜底类它表面上拉低了分类正确率实际上给系统留了宝贵的容错空间。在新手项目中其他类常被当作用不到的东西扔掉我每次都强烈建议保留。5. 从学习到实战一些值得养成的AI工程习惯到这一步一条完整的AI工程学习路径已经铺开。最后分享几个我在实践过程中觉得价值极高的习惯也算给准备从零开始的你一些落地参考。第一个习惯是先定评估标准再动手建模。很多项目的失败不是模型不好而是项目负责人从一开始就没想清楚什么叫成功。无论是做一个推荐系统还是做内容审核先定义清晰且可量化的业务指标等于整个项目有了坐标轴后面做的每一步都不会跑偏。第二个习惯是养成写实验记录的强迫症。我在训练模型时一定会记录每次实验的数据集版本、超参数、验证集效果、失败原因哪怕只是在本地做一个简单demo。原因是AI实验的变量极多不记录的话三天后回看就不知道自己调整了什么、为什么这么调。这个习惯在工作协作中尤其重要当团队需要复现你的结果时一份完整的实验记录比任何代码注释都管用。第三个习惯是每隔一段时间就重新审视数据和标签的质量。AI系统上线后并不是一劳永逸的用户行为、数据分布、业务目标都会变。我见过很多系统上线半年后效果悄然滑坡却很少有人去复盘数据质量的变化。把数据质量监控作为系统的一部分而不是一次性的准备步骤这是AI工程与一次性模型实验最本质的区别。说到底AI工程从零起步并没有想象中那么高不可攀它需要的不只是算法知识还有工程落地的方法论和持续迭代的耐心。动起手来从一个完整的小项目开始把数据、模型、部署、监控都走一遍你就会发现之前那些看起来玄乎的概念都会慢慢变成你手里实实在在的东西。这条路我走过也带不少人走过只要每一步都踏实你也能走通。