“ai-engineering-from-scratch”这个项目名我之前在好几个技术社区都看到过。说实话一会儿是学习路线图一会儿是开源仓库一会儿又是一堆教程的合集挺多人把它当成收藏夹里吃灰的资源。但如果你真的想认真走一遍AI工程这条路这个标题其实点出了最关键的一招别急着上框架、别急着套模板先搞清楚底层是怎么回事再一步步把系统搭起来。我做了几年AI方向的落地项目也带过不少新人今天就用一篇长文把“从零开始学AI工程”这件事拆开讲清楚这条路到底涉及哪些技能、按什么顺序学、学到什么程度算过关、实操时最容易在哪儿翻车。不管你是刚毕业的学生、想转行的后端工程师还是已经在用API调模型但想深入一层的开发者这篇文章应该都能给你一个可执行的参考框架。1. 先别急着写代码AI工程这条路到底该怎么走1.1 为什么“从零开始”是最好的起点很多人学AI的第一步不是补基础而是直接去跑别人的开源项目。我之前也这么干过克隆一个仓库pip install一把梭跑通demo的那一刻确实爽但换个数据集、换种业务场景就立刻抓瞎。问题出在哪出在你只看到了“别人的结论”没看到“别人的决策过程”。“from scratch”的核心价值就是强迫你走一遍完整的决策链路为什么要用这个模型而不是那个模型为什么要这样处理数据损失函数为什么选交叉熵而不是均方误差这些东西在教程里往往被一句带过但恰恰是面试和实际项目里最常考、最常卡住的点。我的建议是前三个月不要碰任何深度学习的封装库先用NumPy把线性回归、逻辑回归、简单的两层神经网络手写一遍。这个过程很痛苦但效果是立竿见影的——你会真正理解梯度下降在干什么、反向传播到底怎么把误差传回去的、学习率为什么不能随便调。这些底子打牢了后面用PyTorch、用Transformers库都只是换工具的事而不是重新学一遍。1.2 AI工程的核心能力地图AI工程不是一个单一技能而是一组能力的组合。我习惯把它分成四层理论基础层线性代数、概率统计、微积分、最优化方法。不需要你达到数学系水平但至少要能看懂公式、能推导简单的梯度表达式。算法模型层经典机器学习算法回归、分类、聚类、树模型、神经网络基础、Transformer架构、大语言模型的核心机制。这一层是“算法工程师”和“AI工程师”的重合地带。工程实现层Python编程、数据处理、模型训练与调优、模型部署、API服务、性能优化。这一层是AI工程师区别于算法研究员的关键。生产落地层数据管道、评测体系、监控告警、实验管理、成本控制。这一层决定了你的模型能不能在真实业务里活下来。如果你只想调API做应用那第三层和第四层的前半段就够了。但如果你想成为真正意义上的AI工程师前两层不能跳过。市面上很多速成班让你三个月就从零冲到ChatGPT套壳开发结果就是大家都会套壳但一遇到模型效果不好就没人知道怎么调。你可以拿下面这个清单自测一下看自己在哪一层还有缺口能力维度核心问题过关标准数学基础能解释softmax的推导过程吗能徒手写出梯度表达式模型原理能说清Transformer的attention机制吗能画出attention的计算流程图编程能力能独立处理一个脏乱的数据集吗能写出可维护的数据处理管道训练调优模型不收敛时知道怎么排查吗能系统地调整学习率、正则化、数据增强部署上线能把模型包装成低延迟的API吗能处理并发、超时、显存溢出等问题评测体系能设计合理的离线评测集吗能结合线上指标做A/B测试2. 地基三件套数学、Python与机器学习基础2.1 数学不是要你成为数学家但要够用我见过最极端的两个案例一个是从头啃完三册《数学分析》结果代码一行没写一个是完全零基础直接上手Transformer结果连损失函数都看不懂。这两种都不可取。AI工程所需的数学是“够用”就行关键是知道自己缺哪块、去哪补。线性代数里最核心的是矩阵乘法、转置、逆矩阵、特征值与特征向量。你不需要会证明但要能直观理解矩阵乘法为什么对应特征变换特征向量在PCA里有什么用。这些在Transformer的QKV计算里会反复出现——Q K^T这一步本质上就是在做相似度计算而缩放因子sqrt(d_k)是为了防止点积过大导致softmax梯度消失背后的数学直觉就是高维向量的模长会随着维度增大而增大。概率统计方面重点掌握概率分布正态、伯努利、多项分布、条件概率、贝叶斯定理、极大似然估计、期望与方差。交叉熵损失函数为什么要配softmax使用因为softmax把logits变成概率分布交叉熵衡量的是预测分布和真实分布的差异这两个搭配起来梯度计算最稳定。这个理解是面试高频考点也是你排查训练问题时的重要工具。微积分这边核心是偏导数、链式法则和梯度。反向传播的整个算法就是链式法则的工程化应用——你只需要记住一件事每一层梯度的计算都依赖后一层的梯度所以叫“反向”传播。最优化的核心是梯度下降及其变体要理解学习率、动量、Adam优化器为什么这么设计。2.2 Python生态与工具链Python是AI工程的事实标准语言但“会Python”和“会写AI工程的Python”是两码事。除了基本的语法、数据结构、面向对象编程之外你需要熟练掌握以下工具链NumPy所有数值计算的基础。要熟练使用向量化操作尽量避免写Python循环——同样的计算向量化之后通常快几十倍。Pandas数据处理的主力工具。要掌握数据清洗、分组聚合、缺失值处理、特征工程的常见操作。Matplotlib Seaborn可视化分析。模型训练时你需要看loss曲线、看数据分布这些工具是基本功。PyTorch深度学习框架。重点是理解nn.Module、DataLoader、optimizer、loss_fn这四件套的配合方式。很多人会纠结要不要先学TensorFlow。我的建议是直接学PyTorch。不是TensorFlow不好而是当前学术界和工业界的生态已经明显向PyTorch倾斜绝大多数预训练模型、研究代码、工具库都以PyTorch为基础。你学会PyTorch之后再去看TensorFlow或者JAX很多概念是互通的。这里有一个实用的学习技巧不要对着文档刷API而是找一个真实的小项目比如Kaggle上的Titanic生存预测从数据加载、特征工程、模型训练到提交结果完整走一遍。过程中遇到什么API不会就查什么API这样记得最牢。2.3 机器学习核心概念一次讲透机器学习的基础概念不需要多但每个都要“真懂”。我按重要程度排个序第一个是过拟合与欠拟合。这是整个机器学习里最核心的现象。模型在训练集上表现好但在测试集上表现差这是过拟合在训练集上就表现很差这是欠拟合。对应的方法分别是增加数据量、增加正则化、减小模型复杂度以及增加模型复杂度、减少正则化、训练更久。这个判断思路贯穿你整个AI工程生涯因为调模型80%的时间都是在和过拟合博弈。第二个是评估指标的选择。分类问题里准确率在类别不平衡时会骗人——比如99%的样本都是负样本那模型全预测负样本就有99%的准确率但一点用没有。这时候要看Precision查准率、Recall召回率和F1分数。回归问题要看MSE、MAE其中MSE对异常值更敏感MAE更稳健。这个选择直接影响你对模型效果的判断一定不能只盯着一个指标看。第三个是数据划分与交叉验证。简单随机划分在大多数场景下可行但时间序列数据必须按时间顺序划分否则就是“用未来预测过去”测试指标虚高。交叉验证能更稳定地评估模型但代价是训练时间翻倍。在深度学习场景下通常的做法是固定一个验证集而不是做K折交叉验证因为大模型训练成本太高了。学习这一部分时我强烈建议搭配动手实验自己构造一个线性可分的数据集、一个非线性数据集、一个高噪声数据集然后用逻辑回归、决策树、随机森林分别去跑观察它们的决策边界和性能差异。这个过程能帮你建立非常重要的“模型直觉”——看到什么样的数据分布大概就知道什么模型会表现好。3. 从训练到应用亲手构建一个完整的AI系统3.1 第一个里程碑用手写数字识别建立全局认知MNIST手写数字识别被称为“深度学习界的Hello World”但它值得做的原因不是简单而是能让你在最短时间内把一套深度学习流程完整跑通。我当时做这个项目时给自己定了一个要求用三层不同的实现方式各做一遍。第一遍用NumPy手写一个全连接网络。这一遍最痛苦因为你要自己实现前向传播、反向传播、梯度下降。写完你会明白loss.backward()这行代码背后到底发生了什么——它其实是在计算图中从输出端往输入端逐层求梯度每一层的梯度都依赖上一层从输出方向看的梯度。第二遍用PyTorch实现同样的网络但不用nn.Module而是手动定义权重和梯度更新。这一遍的目的是建立PyTorch和手写实现之间的映射F.linear其实就是一个矩阵乘法加偏置F.relu就是一个逐元素的非线性变换。一旦你建立了这个映射PyTorch对你来说就不再是黑盒。第三遍才用完整的PyTorch工程化写法nn.Module定义模型、DataLoader管理数据、optimizer管理参数更新、torchvision做数据增强。这一遍是给你以后做项目打样的后面的所有项目都可以复用这套模板。做完这三遍之后你还应该做一个实验把学习率分别设成0.1、0.01、0.001观察loss曲线的差异把网络层数从2层加到5层观察过拟合现象往训练集里注入20%的随机标签观察模型如何从“学规律”退化为“死记硬背”。这些实验的成本很低但对理解“模型为什么这样表现”帮助极大。3.2 大模型时代应用开发的范式转移2023年之后AI工程的重心明显从“训练模型”转向了“应用大模型”。这不是说传统深度学习不重要了而是工程范式发生了变化。现在的主流做法是以一个强大的基座模型比如LLaMA、Qwen、GPT系列为基础通过提示词设计、检索增强生成RAG、微调、Agent等手段解决具体的业务问题。这几条路线有清晰的适用边界选错方向会很痛苦提示词工程模型本身的通用能力够用只是需要把问题描述清楚。成本最低见效最快。适合客服问答、文本分类、信息抽取等场景。核心技巧是少数样本few-shot示例、思维链CoT提示、结构化输出约束。RAG检索增强生成模型需要回答私有领域知识或最新信息。把资料库切片、向量化用户提问时先检索相关内容再把检索结果塞进提示词让模型生成回答。它的本质是“外挂知识库”不用重新训练模型更新知识只需要重新索引一遍文档。微调需要模型稳定地模仿某种风格、输出格式或者需要掌握私有领域的特定行为模式。训练成本高但能改变模型的行为模式。适合代码生成、特定领域写作、结构化信息提取等。Agent需要模型自主完成多步骤任务比如调用API、操作工具、做计划。让模型循环思考“当前状态→下一步动作→观察结果→继续”本质是把大模型变成一个“决策大脑”。这四个方向不是互斥的真实项目里经常组合使用。我见过一个很典型的组合企业内部合同审核系统用RAG解决法律条款检索用微调让模型输出标准的审核意见格式再用Agent自动调用合同比对API做差异分析。3.3 实战拆解一个RAG问答系统的搭建过程RAG是当前大模型应用里最值得深入掌握的技术因为它在企业内部的落地场景非常广。我以一个“公司内部知识库问答系统”为例拆解完整的搭建过程。第一步文档加载与分块。这一环看似简单但直接决定系统效果的上限。你可能会想“我直接把整篇文档塞给模型不就行了”问题在于模型上下文窗口有限而且长文档里的大部分内容是噪音会影响检索和回答质量。我的做法是按语义分块段落级优先可以用LangChain或LlamaIndex的RecursiveCharacterTextSplitter先按段落分再按句子边界调整让每个块保持语义完整。块大小有一个经验区间中文场景200到500字比较稳太短会切断语义太长会引入无关信息。第二步向量化。用嵌入模型把每个文本块转成向量。嵌入模型的选型很关键有几点经验供参考领域匹配度比模型大小更重要法律文档优先用法律领域微调的嵌入模型中文场景优先考虑对中文分词友好的BGE系列等本土模型这些模型在中文语义理解上通常优于通用英文嵌入模型向量维度不是越高越好不要盲目追求大模型——要结合向量数据库的检索性能综合取舍。第三步构建检索链路。用户提问后把问题向量化在向量数据库milvus、FAISS、pgvector都可以里做相似度检索取Top-K个最相关的文档块。这里有两个细节需要特别注意一是“检索”不只是向量相似度像BM25这种传统的关键词检索在某些场景下效果反而更稳很多生产系统会把向量检索和BM25做混合检索hybrid search然后做结果融合排序二是Top-K不是越大越好通常取3到5个块就够了——太多了会把不相关的噪音塞给模型反而降低回答质量。第四步提示词组装与生成。把检索到的文档块拼进提示词明确告诉模型“请基于以下参考资料回答用户问题如果资料中没有相关信息请直接说明不知道不要编造。”这个“拒绝编造”的指令非常重要因为大模型的幻觉问题是RAG系统面临的最大风险。输出格式也建议结构化比如要求返回“回答”和“参考依据来源”两个字段这样用户可以溯源也便于后续评测。第五步评测迭代。这是RAG系统能不能长期维护的关键。你需要准备一份评测集——50到100条真实业务问题每条标注正确答案和对应的文档来源。每次改动检索策略、分块方式、提示词或嵌入模型都要在评测集上跑一遍对比回答准确率和检索命中率。我见过太多团队把RAG系统上线后就再也不管了结果是业务数据更新了、问题分布变了系统效果悄悄下滑却没人察觉。4. 工程化是真正的分水岭让模型跑在生产环境4.1 部署从Notebook到API服务的最后一公里训练好模型只是完成了前一半工作怎么让模型在真实环境中稳定服务才是AI工程师和算法工程师拉开差距的地方。我自己第一次部署模型时就吃过不小的亏在Notebook里推理一切正常封装成API一压测就发现单请求耗时飙到1.2秒根本没法用。部署时的核心考量有这么几个首先是推理加速。模型加载到GPU后推理速度的主要瓶颈是显存带宽和计算效率。常用的手段包括混合精度推理FP16/INT8量化、批处理把多个请求合并成一个batch、模型蒸馏用大模型教小模型。对于大语言模型vLLM这类高性能推理框架是生产环境的标配它通过PagedAttention和Continuous Batching技术把吞吐量提升了数倍实测下来非常稳。然后是服务框架选型。FastAPI是目前最适合AI服务部署的Python框架原生支持异步、自动生成API文档、性能也不错。关键是要处理好两个问题一是模型加载要放在全局Gunicorn多进程模式下每个worker加载一次避免重复加载二是服务要支持超时控制和优雅重试——大模型推理不稳定偶发超时很正常客户端需要正确的重试策略。最后是容器化与资源管理。Docker是基本功你要能写出规范的Dockerfile——基础镜像要选带CUDA的版本依赖要用requirements.txt或poetry锁定版本模型文件通过启动脚本在容器启动时从对象存储拉取而不是打进镜像里否则镜像动辄几十GB发布一次要传半天。GPU资源的调度在生产环境通常交给Kubernetes管理但对于个人项目或小团队用Docker Compose加单机GPU通常就够了。4.2 评测与监控没有评测就没有优化我踩过最大的一个坑就是上线了一个精心训练的模型业务方反馈效果“很差”但离线测试指标明明很好看。后来排查发现离线测试集和线上真实数据分布严重不一致——测试集是人工精心标注的标准案例而线上输入五花八门很多噪声和特殊情况离线完全没覆盖到。这个教训让我建立了两个习惯值得所有做AI工程的人参考。第一个习惯是评测集要和业务一起设计。建模型之前先拉着业务方定义清楚“好”和“坏”的标准什么场景必须答对、什么场景可以容忍模糊、什么场景绝对不能出错。然后围绕这些标准构造评测集覆盖边界情况和异常输入。评测集里的每一条都要带着“为什么选这条”的意图而不是随手从历史数据里抽样。第二个习惯是线上监控必须从第一天就做。模型上线不仅仅是发布一个API而是要构建一整套监控体系输入特征分布漂移检测训练时的数据分布和线上新进来的数据是否逐渐偏离、预测置信度分布、业务指标的实时变化比如问答系统的用户满意度、推荐系统的点击率、以及系统稳定性指标延迟、错误率、GPU利用率。建议在服务部署的第一天就接入基础的日志和监控哪怕先记录到日志文件里也比事后补救强得多。4.3 MLOps基础让AI系统“可维护”而不是“一次性”很多个人项目和初创团队做AI模型模式是“训练一次、跑通就完了”。但模型不是写死的一次性代码它在生产环境里是需要持续维护的活体系统。MLOps要解决的就是让这个系统可重复、可追踪、可恢复。先说实验管理。训练模型的过程本质上是“探索”你今天改了学习率明天改了模型结构如果不做记录几周之后就完全搞不清哪个配置产出了哪个结果。目前主流工具是MLflow和Weights Biases它们可以自动记录超参数、训练指标、模型文件、代码版本。哪怕只是个人项目也建议养成一个习惯每次训练都在MLflow里留一条记录标注数据版本、代码commit号、超参数和结果指标。再说数据版本管理。模型效果和训练数据强相关数据一变模型行为就可能完全变了。DVCData Version Control这类工具能把数据集纳入版本管理和Git联动。这样每次训练用的数据都能精确复现——排查线上问题或复现某个历史实验结果时能轻松找到当时用的是哪一版数据。最后是模型版本与回滚机制。生产环境里模型升级必须支持“平滑发布”和“快速回滚”。平滑发布是让新旧模型模型同时在线按比例切流量比如先5%新模型观察指标稳定后再逐步扩大快速回滚是当新模型出现问题时能一键切回旧版本。这个机制不是可选项而是生产环境的必需品——大模型时代任何预先评测都有可能漏掉线上风险发布机制本身就是最后一道防御。5. 踩坑实录与进阶方向5.1 新手最容易翻车的五个坑这些年带新人和做项目踩过的坑实在太多挑五个最高频的分享出来都是血泪教训。坑一数据质量没验证就训。新手最常见的行为是拿到数据集不做EDA探索性数据分析直接就开始训练。结果训练loss降不下去查了半天才发现数据里有大量重复、缺失、标签错乱。更隐蔽的是标签泄漏——有些特征实际上包含了未来信息比如用“是否退款”去预测“是否满意”训练时模型表现得特别好一到真实场景就原形毕露。我现在的习惯是动手训练之前至少花半天时间做数据探索——看每个特征的分布、检查异常值、做特征和标签的相关性分析、确认没有泄漏。坑二过度依赖AI调试AI。大模型时代的一个新坑是“AI辅助开发依赖症”——出了问题直接把报错信息扔给ChatGPT照着回答改改完还错就再扔回去。不是说不能用AI工具而是你先要有自己的判断你应该先读报错信息、看调用栈、复现问题形成自己的假设再用AI工具验证。如果完全依赖AI你会失去最重要的“调试直觉”——而这种直觉正是AI工程师的核心竞争力。坑三不读源代码。很多新手用熟了某个库就不再打开它的源码。但我强烈建议至少每个主流库的核心模块要读一遍源码。比如PyTorch的DataLoader是怎么实现多进程加载的Transformers库的generate方法是怎么实现beam search的这些读一遍你对框架的理解会从“用户”升级为“参与者”。“from scratch”精神在这个时代的最佳体现不是什么都自己造轮子而是拆开轮子看一遍再装回去。坑四只看准确率不看业务指标。技术上“模型效果不错”和业务上“这个系统能用”之间往往隔着很大的鸿沟。准确率提升2个百分点如果线上用户根本感知不到这个提升就没有业务价值。做AI工程项目你要学会和老业务方对齐指标你提出“准确率90%”他们关心“能省多少人力工时”你说“召回率提升了10%”他们要问“这能带来多少转化率提升”。学会把技术指标翻译成业务收益这是中级工程师到高级工程师的必修课。坑五忽视成本控制。大模型API按token计费GPU训练按小时计费成本说失控就失控。我见过一个团队做客服机器人大模型改造直接调用外部商业API上线第一个月账单就超预算三倍。后来改造为本地部署开源模型提取高频问题缓存答案成本降了80%效果还更稳定。做AI工程模型层面的优化是必要的但成本思维同样重要——好的AI工程师不只是把模型做出来还要在效果和成本之间算清账。5.2 学习路径优化怎样安排更高效根据我自己的经验从零基础到能独立负责一个AI工程项目的周期大约是6到9个月前提是保证每天2到3小时的投入。这比很多速成班承诺的时间长但踏实得多。时间分配可以参考这样的比例阶段时间占比核心目标结束标志基础补齐数学Python20%能看懂公式、能写清晰代码能用NumPy实现线性回归经典机器学习20%理解核心算法和评估体系能独立完成一个Kaggle入门项目深度学习与PyTorch20%掌握神经网络训练全流程能训练并调优一个CNN/Transformer模型大模型应用开发25%掌握Prompt、RAG、微调能搭建一个完整的RAG问答系统工程化与部署15%能把模型上线并监控能部署一个可访问的API服务有个容易被忽略但非常关键的建议早点开始写博客或做输出。不用等到全学完了再写学到一个新知识就用自己的话整理成笔记。输出是最好的学习方式——当你试图向别人解释一个概念时你会发现自己哪里“以为懂了但其实没懂”。我自己很多知识盲区就是通过写博客暴露出来的。5.3 下一步从AI工程师到AI系统架构师如果你已经能独立完成一个AI应用从训练到上线的全流程那接下来就可以往AI系统架构师的方向走了。这个阶段的核心不再是“把某个模型训好”而是“设计一个稳定、可扩展、成本可控的AI系统”。需要刻意锻炼的能力包括大规模数据管道的设计亿级数据的清洗、存储和调度、多个AI服务之间的编排与协同比如Agent架构下的多模型调用链、AI系统与业务系统深度集成权限控制、审计日志、与现有CRM/ERP打通、以及系统可靠性设计故障转移、降级策略、压测和容量规划。我的建议是不要急着跳槽或追求头衔而是找一个真实业务场景把一个系统的全链路问题都摸一遍。比如你做一个智能客服不只是做一个问答API而是把工单系统对接、用户身份识别、知识库更新机制、人工接管流程、会话日志分析全部拉通。这个过程会逼你面对大量“训练模型之外”的问题——而这些才是AI工程真正的深水区。最后分享一个我个人的体会AI工程领域变化太快今天学的框架可能半年后就过时了今天的主流模型可能下个月就不是最优选择了。但底层的东西——线性代数、概率统计、算法逻辑、工程方法论——是不变的。这也是“from scratch”最值得坚持的原因它让你拥有的是稳固的底层框架而不是一套精致但脆弱的工具技巧。构建自己的底层框架需要耐心和时间而这恰恰是快速迭代的行业里最稀缺也最有价值的资产。