很多人以为“AI工程”就是把模型调出来、把精度刷上去其实那只占很小一部分。真正的AI工程是从数据怎么进、模型怎么训、服务怎么发、线上怎么监控、出错了怎么兜底这一整套链路。这篇文章我想用“从零开始搭建AI工程能力”的视角把整个体系拆开讲透适合已经入行但觉得自己只会跑通Demo、想补上工程化短板的人也适合想系统性入门的同学。省去那些虚的直接说实在的。1. 先搞清楚AI工程和AI算法研究是两条路1.1 你学的是工程能力不是论文复现机在没有任何正文细节的情况下我先根据“ai-engineering-from-scratch”这个标题做一个明确判断它瞄准的是“AI工程能力”不是“AI研究能力”。这两者的目标函数完全不同。AI研究追求的是“在某个指标上刷出新高”。发一篇论文、复现一个SOTA、跑通一个新的模型结构这些是研究的交付物。研究环境里数据可以是干净的、任务可以是简化的、评价可以是单一的因为它的目标是指标本身。AI工程追求的是“在真实场景中稳定解决一个业务问题”。模型精度只是其中一环甚至不是最重要的一环。工程环境里你要面对脏数据、缺失值、概念漂移、推理延迟、服务稳定性、成本控制、数据隐私、监控告警、模型回滚每一样都比“精度涨了0.5个点”更影响最终成败。从零开始学AI工程第一课就是把这个认知掰过来你是在用机器学习/深度学习技术做系统设计不是在做模型实验。你的最终交付物是一个运行在生产环境里、能持续产生价值的系统而不是一个在Jupyter Notebook里精确到小数点后四位的准确率。1.2 工程思维和实验思维的分水岭在哪我见过太多从算法研究转工程的人栽跟头也有不少做业务开发的调包侠被模型问题卡死本质都是思维模式没切换。实验思维是这样一种状态数据不够就用人家的开源数据集反正目标是看模型能力代码写得再乱也没关系只要能跑出结果超参数随便调手动改改也行反正就一个实验一次训练可能要几小时那就挂着等跑完了再分析。工程思维则完全不同数据不够就要设计数据生产方案包括标注流程、质量抽检、版本管理因为模型要依赖数据迭代代码写乱是绝对不行的因为要多人协作维护一套代码可能要跑一年超参数全部要纳入配置管理每次实验能复现不然后续优化无从谈起训练也不是一把梭要考虑分布式策略、资源调度、失败重试一跑可能不是几小时而是几天。一句话总结实验思维问“效果行不行”工程思维问“系统稳不稳、能不能长期维护”。这个认知是后面所有内容的地基。地基不正后面学的每一块砖都是歪的。2. 从零构建AI工程能力的技术栈选型2.1 语言层面Python为主但不止PythonAI工程的主语言几乎必然是Python这没什么好争的——生态太丰富了从数据处理到模型训练到服务部署整个链路都有成熟库。但只学Python不够工程化的边界会把你推向你从没想过的地方。生产环境里你至少还会碰到这些非Python内容数据管道可能用SQL处理大量的清洗和聚合逻辑写SQL比写pandas高效得多高性能推理可能要用C或CUDA尤其当你要用TensorRT做加速或者写自定义算子时服务化可能是Java或Go做的你是模型服务的提供者要和他们的RPC框架对接DevOps层面是Shell脚本和Dockerfile这些绕不开。所以我的建议是Python精通的前提下SQL必须熟练Shell能写Docker能搞定C和CUDA了解原理即可。你不需要成为每个领域的专家但得能看懂别人在干什么、能和他们对得上话这样才不会被工程链路卡住。这里有个很实在的好处当你具备这些跨层语言能力时你定位问题就不再是“模型报错了就找模型的事”而是能从整个链路去看——数据是不是在接口层就被截断了服务是不是因为内存问题崩了性能瓶颈是不是在数据序列化上。这种全局视野恰恰是“从零到工程化”最大的跨越。2.2 框架选型模型框架和工程框架是两套东西模型训练框架方面PyTorch是事实标准在研究和工业界都有绝对统治力生态完整从HuggingFace到各种开源模型都是PyTorch权重。TensorFlow也还在一些老系统里活着但新项目我基本不建议入坑。JAX在小圈子很火热适合研究高性能计算但工程团队用它要慎重。工程框架则是另一条线很多人会忽略。模型训练完不是终点怎么把模型跑起来、怎么管理实验、怎么搭服务这些需要专门的工程工具链。模型服务用FastAPI或Flask做轻量级的模型API大模型推理服务用vLLM或TGI实验管理用MLflow或Weights Biases特征存储用Feast或自建工作流编排用Airflow或Prefect模型监控用Prometheus Grafana搭指标看板。这里我想强调一个容易被忽略的点AI工程里的“框架”经常不止一个它们要组合成一个流水线而每增加一个组件运维复杂度就上一个台阶。所以选型的原则是能少用就少用能被云服务替代就优先云服务别一上来就搭一个Kafka Spark Flink的巨无霸数据处理平台——你的业务量和团队规模大概率撑不住。2.3 基础设施GPU、容器和CI/CD从零开始做AI工程绕不开算力基础设施的规划。这一块很多初学者完全没概念以为买几张显卡就能开干实际落地时会发现一堆问题。GPU层面个人学习和起步阶段用单卡就行RTX 4090这种消费级卡足够跑大部分中小模型但到了生产你必须考虑A100/H100这些服务器级GPU因为它们有更大的显存、更好的互联带宽、支持多卡并行。训练大模型时显存远比算力更容易成为瓶颈一张卡装不下的模型只能靠模型并行、流水线并行拆开。容器化不是可选项是必选项。Docker保证你的训练环境一致性上一周还能跑的代码这周系统升级后跑不起来了这种事我经历过太多次。Kubernetes用来管理训练任务和服务实例尤其当你有多个模型要同时跑、要弹性伸缩时K8s几乎是唯一解。没条件上K8s的至少也用Docker Compose管理好单机的多容器。CI/CD也要建立起AI版本。很多团队只把CI/CD用在Web服务上模型代码仍然是“本机跑通就上生产”的野路子。正确做法是训练代码进GitGit hook跑代码检查和单元测试训练触发用Docker镜像打包模型产出去带版本号。这样你才能回答一个最重要的工程问题——“线上这个模型是用哪份代码、哪个数据集、哪组超参跑出来的”3. 核心知识体系的搭建数学、模型与数据三板斧3.1 数学到底要学多深不超纲的实用路线很多零基础的人在“AI要学多少数学”这个问题上被劝退。我直接给结论做AI工程的人数学不需要学到数学系硕士的水平但必须把三个领域的核心概念吃透到能上手推导的程度。线性代数重点不是矩阵怎么乘而是“维度”这个概念。一个样本是一个向量一个批次是一个矩阵全连接层就是矩阵乘法注意力机制本质是矩阵点乘的计算图深度学习的每一步计算都是张量运算。你把维度变化理清楚模型结构基本就懂了一大半。概率统计重点是分布、期望、方差、条件概率以及它们在损失函数里的角色。交叉熵损失到底在算什么为什么分类问题用交叉熵不用均方误差这背后的概率解释你得懂。贝叶斯思想在做模型不确定性估计、A/B测试分析时也用得上。微积分核心是梯度和链式法则。反向传播就是在逐层求梯度学习率就是在控制参数沿着梯度反方向走多远。梯度消失为什么存在因为连乘导致梯度越来越小——你用这个原理就能解释为什么Sigmoid做激活函数在深层网络里会出问题也能理解为什么ReLU能缓解。我建议的学习方式是“用中带学”先跑一个简单的线性回归然后问自己为什么梯度下降会收敛去查公式先搭一个CNN做图像分类再问自己卷积层输出的形状是怎么算出来的去复习一下二维卷积的公式。这种带着问题学数学的方式比啃教材高效得多。3.2 模型演进路线从LR到Transformer再到LLM模型知识的学习也应该遵循一条演进路线从简单到复杂每一步都搞清楚“它解决了什么、代价是什么”。起点是线性模型和逻辑回归。虽然简单但逻辑回归是理解“学习”的启蒙——有一个函数有一个损失有一个优化算法三步循环不断迭代直到收敛。你把这个流程吃透后面所有模型都是在这个框架里换函数、换损失、换优化器。紧接着是树模型尤其是梯度提升决策树GBDT和XGBoost/LightGBM。你可能觉得深度学习是万能的但在表格数据上树模型的性能和可解释性依然碾压大多数深度模型。AI工程的现实是80%的业务场景是表格数据你需要树模型作为强 baseline 和常用主力。这也是为什么我在工程实践里始终坚持“先跑一个简单的逻辑回归或GBDT再考虑要不要上深度模型”。然后是深度学习的两个支柱CNN处理空间结构RNN/LSTM处理时间结构。CNN要理解卷积核、感受野、池化、残差连接这些概念RNN/LSTM重在理解它的顺序依赖问题和梯度传播困难以及为什么后来被Transformer取代。Transformer是当前所有大模型的基础结构你必须精读。重点理解从RNN到Transformer的转变序列建模从“逐步递归”变为“并行注意力”Self-Attention让每个位置都能看到整个序列位置编码补充顺序信息。多Head机制允许模型从不同表示子空间捕捉信息残差和LayerNorm让训练更稳定。有了Transformer大语言模型的原理铺垫就完成了预训练任务学习语言规律微调适配下游任务RLHF对齐人类偏好上下文学习In-Context Learning让模型无需更新参数就能完成新任务。这条路线走完你对“AI能做什么、不能做什么、模型为什么会这样”会有结构性的理解而不是背一堆名词却不知道模型之间的递进关系。3.3 数据处理能力80%的脏活累活都是AI工程的核心业界有一个被反复引用的说法数据准备要占到一个机器学习项目80%的时间。从我的实际经验看可能没那么夸张但60%-70%是有的。AI工程从零开始必须在数据能力上投入重兵。数据处理的核心能力可以拆成四块数据获取包括埋点、爬虫、第三方API接入、合作方数据交换在合规前提下解决“数据从哪来”的问题。数据清洗处理缺失值、异常值、重复样本、不一致格式。这块看起来基础但坑很多。比如处理缺失值的策略不是“全都删掉”或“全填均值”要结合业务场景判断缺失是随机的还是有偏的有偏的缺失本身就是一种信号。特征工程自动化和手工并存。自动化手段包括目标编码、多项式组合、嵌入特征手工特征来自领域知识比如做CTR预测时把“用户最近1小时点击同类商品的次数”这种特征加进去效果往往比模型结构创新还明显这仍然是工程降本增效最直接的杠杆。数据版本管理这一点最容易被忽略。你的模型因为数据变化导致性能下降时如果不能定位到具体是哪一批数据引入的问题排查会非常痛苦。数据要打版本、记录schema变更、保留历史快照和代码版本管理一样严格。做完这四块你的“工程能力”才算是真正起步。4. 从模型到系统AI工程化的完整流程拆解4.1 训练流程的标准管道一个可维护的AI训练管道至少包括数据验证、训练作业、模型评估、模型注册、审批发布这五个环节。数据验证要检查数据schema是否符合预期、统计特征是否出现漂移。曾经有个推荐模型上线后CTR突然暴跌最终排查发现是上游字段类型从int变成了string下游的JSON解析全部失败默认值填充后特征全部变弱——如果没有数据验证环节这类问题非常难定位。训练作业要可配置化所有超参数放进配置文件每次实验记录训练代码版本、数据版本、超参数、环境依赖和指标结果。模型评估不能只看单一指标要看分类报告、混淆矩阵、按业务分层的表现判断模型是否在各个细分场景里都靠谱。评估通过后模型要注册到模型仓库带上版本号、标签和元信息。审批发布则是人工把关确定风险可控才放行上线。4.2 推理服务的技术细节模型上线这一关看似简单细节丰富到超乎想象。先说最基础的模型推理是直接用模型文件的输出做一个HTTP服务这中间要处理输入校验、批处理、缓存、超时控制、错误处理、并发控制这些问题。再说性能优化ONNX/TensorRT可以对模型进行图优化和算子融合FP16/INT8量能用极小的精度损失换取数倍的推理加速这些工程技巧能极大改善线上推理延迟和GPU成本。还得考虑动态批处理。GPU是高度并行化的处理器一次推理处理一个样本和一次推理处理32个样本的耗时差不了太多所以把多个请求攒一起批量推理能大幅提升吞吐。但动态批处理有代价——你要设计攒批策略等多久凑一批、上限多少条、超时了怎么处理这些都需要权衡。然后是在线服务和离线预测的取舍。实时推荐、即时风控这类场景用在线服务用户体验要求高任何延迟都可能造成转化损失批量打标签、定期更新这类场景用离线预测每天凌晨统一跑一次成本低、实现简单。很多业务场景其实没那么需要实时没必要一上来就追求毫秒级延迟离线跑反而稳定可靠。4.3 模型评估体系Git可以做代码的版本控制模型也要有评估、监控、回滚的闭环。评估层面要建评测集和基准。评测集不是训练集要尽量贴近线上真实分布并且长期冻结不因为模型迭代就随意改动。基准是用作对比的当前线上最优模型每次新模型都要和它PK赢了才有资格上线。大模型时代也一样很多团队从通用模型和开源模型的对比起步建立一个基准测试集评测内容可以包括推理、知识问答、指令跟随、安全性等维度保证每次更新都“有理有据”。上线之后是持续监控。模型的性能会随时间变化数据分布一变模型效果就会衰减。你必须跟踪线上推断结果、输入特征分布、用户反馈信号当关键指标异常时自动告警。监控还分概念漂移和数据漂移数据漂移是输入分布变了但输入到输出的映射关系没变概念漂移是输入分布没怎么变但输入和输出之间的真实关系变了。很多资深工程师也会混淆这两种情况但它们对应的处理策略完全不同这是基本功。出了线上问题怎么办必须能一键回滚。模型仓库里要有历史的模型版本发布系统要支持切换流量到旧版本。注意新模型上线不是简单替换而是灰度——新老模型按比例分摊流量观察一段时间再全量切换这是最基础的稳妥思路。5. 大模型时代的AI工程新战场5.1 RAG和Agent带来的架构变化大模型时代彻底改变了AI工程的重心。从前你是训练一个模型来完成一个具体任务现在你更多是在编排一个或多个大模型配合知识库和工具完成一个复杂流程。这个变化催生了两个核心架构模式。RAG检索增强生成解决大模型“知识陈旧”“幻觉”的问题。核心思路是用户提问后先从知识库检索相关内容把检索到的内容拼进Prompt再让模型基于这些内容生成回答。工程上要解决文档切分、向量化、向量检索、相关性排序、上下文组装等一系列问题。Agent模式更进一步让模型能调用工具。模型先理解用户意图然后拆解成子任务顺序或并行地调用搜索、计算器、数据库查询、代码执行等工具最后汇总结果。工程架构上你要设计工具注册、任务规划、记忆管理、错误处理这些模块。5.2 提示词工程和微调的关系大模型时代的AI工程师还需要具备“用自然语言编程”的能力。提示词工程不仅是写几个Prompt模板而是要理解模型的决策过程和局限。系统提示词设计决定模型的行为边界和角色定位少样本示例决定模型的输出格式和推理方式思维链引导能让模型显式地展示推理过程大幅提高复杂任务的准确率输出约束决定模型的返回格式方便下游程序解析。什么时候用提示词工程、什么时候该微调我的经验判断是能用提示词解决的就不要微调因为提示词成本低、迭代快、风险小只有当提示词怎么调都达不到效果或者你需要让模型学到私有知识且知识量大时才考虑微调或继续预训练。很多团队一上来就花几十万微调一个开源模型最后效果还不如精心设计的Prompt RAG这个坑我见过不少。5.3 大模型应用的评测、成本和安全大模型的评测比传统模型困难得多。传统模型的输出是标签或分数可以直接算准确率大模型的输出是开放式文本没有唯一的正确答案。工程上可行的做法是分层评测任务指标层面写代码任务跑单测验证代码能否通过测试用例数学任务验证答案正确性偏好评估就用高质量标注的偏好集加Elo评分排序安全评估就用红队攻击脚本验证模型在面对恶意Prompt时的表现。成本控制也是大模型工程的核心命题。Token价格就是真金白银推理成本 Token数 × 单价怎么让输入更短、减少重复调用、缓存结果都需要精心设计。小模型解决大问题是成本控制的基本功先用一个小的、快的模型做分流只有它处理不了的请求才流转给大模型这种分层策略在真实场景里能省下大量成本。安全层面既要防数据泄漏比如不要把你的私有代码、用户隐私拼进Prompt发给外部API也要防提示词注入还要做好访问控制审计追踪。这些都是“能上线”和“安全地上线”之间的差距。6. 从零到落地手写一个端到端AI应用6.1 场景选择找一个你熟业务且数据可得的问题说了这么多理论真正让你蜕变的还是亲手做一遍端到端。我建议选择一个你熟悉业务且数据可得的问题完整走一遍流程。下面我以一个“个性化菜谱推荐系统”为例给你完整拆解一个从零到落地的最小可行方案。为什么选菜谱推荐因为它数据可获取各菜谱网站公开数据、自己构造都行业务规律清晰用户的偏好和场景是核心评价标准明确点击、收藏、评分基础设施要求不高单卡GPU甚至CPU就能跑。手写一遍你就把前面所有的内容串起来了。冷启动流程建议如下数据准备阶段爬取或构造菜谱数据集包含菜名、食材、做法、标签、口味、分类等字段切分为训练集和验证集。特征工程阶段对文本型的“食材”和“标签”做TF-IDF或Embedding编码对“口味”和“分类”做多热编码构造用户和菜谱的交互特征。基线和模型阶段先跑一个逻辑回归或GBDT做baseline再用一个双塔模型做用户和菜谱的Embedding匹配和baseline对比看深度模型到底带来了多少增量。服务化阶段用FastAPI把训练好的模型包成一个推荐服务输入用户ID和上下文输出TopN推荐的菜谱。监控阶段用Prometheus记录线上请求量、延迟、返回结果分布定期重算离线指标。6.2 踩坑实录我从这个项目里学到的东西这个项目看着简单做一遍能踩到不少典型的坑。只准备一个菜谱数据集每天热更快则三天慢则一周效果就崩了因为数据分布根本撑不住基于内容的自动冷启动。对菜谱做TF-IDF和Embedding编码后直接拼起来给全连接层当输入效果奇差因为稀疏特征和稠密特征的规模、分布差异太大特征是不同源同量纲的混合体直接拼接缺了规范化。双塔模型把用户和菜谱各自过Embedding层再点积相似度的时候搞了半天才发现正负样本比例没控制好负样本全是随机抽样把热门菜谱全当成了负样本导致模型学歪了——负样本要有策略地采样简单随机和大热门打压都有必要比例也要微调。模型上线用FastAPI直接读PyTorch的ckpt文件跑推理起初响应要两三秒把精度降成FP16后吞吐直接翻倍加上批处理又翻倍这是工程优化最直接的实践。还有最近最长教训粗糙地处理推荐结果的冷启动——新用户根本没看过任何菜谱协同过滤完全失效。后来我引入了热门兜底和基于场景关键词的规则匹配覆盖了冷启动的流量。这套针对冷启动的组合策略做推荐系统的人都值得重视。7. AI工程能力进阶的七个习惯做完端到端项目你的工程能力相当于有了一个骨架。接着要往“优秀”进阶我总结为七个习惯都是多年实践中提炼出的通用做法和具体技术栈无关。写代码要始终想着“六个月后的我和同事还能不能读懂”注释关注“为什么”而不是“是什么”做实验要严格记录版本、数据、超参、指标没有记录等于没做过做任何变更都要小步快跑小批量灰度收集证据再全量是应对不确定性的核心方式把底层的脏活累活自动化测试、部署、监控告警能自动就自动人应该去处理异常而不是重复劳动出现问题先复现再修复复现不了就别急着改代码盲修是灾难的开始所有的工作都要能追溯数据、代码、模型、线上版本、对应关系全部可以串起来是AI工程和“用AI调包”的分水岭持续跟踪前沿但不要盲目追新新框架新模型出来先问“它解决了我什么问题”想清楚再上。关于从零开始的最后一点体会做AI工程这一年多我最大的感受是这个领域的门槛其实不在数学、不在代码而在有没有把一个复杂问题拆成可验证小步骤的系统能力。你不需要一上来就掌握全套技术栈但一定要有“先跑通再优化、先baseline再深模型、先监控再放量”的节奏感。如果你现在正处在“刷了很多课但做不出完整项目”的阶段我的建议很简单给自己定一个底面向上完整交付的小项目哪一步卡住就攻哪一步做完你自然就知道下一步应该学什么了。技术栈会变模型会换但工程化的方法论是通用的。从零开始不是线性地学完再动手而是动手和学交替螺旋上升。祝你在工程化这条路上越走越顺。