AI工程从零开始：从数学基础到大模型部署的完整路线

要聊“ai-engineering-from-scratch”我得先说实话这年头敢把“from scratch”写进标题的人要么是真想把地基打穿要么是刚被某个AI教程坑过、决定不再当“调包侠”。我见过太多人顶着“AI工程师”的头衔实则连模型输入输出的边界都说不清楚更别提自己从头训练一个能用的模型。这个项目标题吸引我的地方恰恰是它不打算走捷径——它默认你愿意从数学、数据、代码、模型、部署这条长路一步步走下来而不是靠“复制一段prompt、换个API key”就算完事。这个项目适合谁两类人。一类是刚入行、被各种“五天搞定AI”的广告烦到不行、想老老实实把基本功补上的新人另一类是已经在做业务开发、但总觉得自己对AI的了解停留在“调接口”层面、想往底层多走一步的工程师。它会告诉你AI工程不是一门“玄学”而是一套可以被拆解、被练习、被验证的工程能力。下面我就以一份实操路线图的视角把这个“从零开始”到底该怎么落地、会踩哪些坑、哪些环节最容易被低估逐步拆开讲清楚。1. 整体设计与路线拆解为什么“从零”不是重复造轮子1.1 这套路线的底层逻辑“ai-engineering-from-scratch”并不是让你从晶体管开始造计算机也不是逼你手写反向传播然后哭晕在厕所。它的核心逻辑是你要理解AI系统每一层的关键机制并在关键节点亲手实现一遍从而获得对系统的掌控力。这就像学做菜——你不需要从种小麦开始但你必须亲手和过一次面、炒过一盘焦了的菜才能真正理解“火候”两个字意味着什么。全抄菜谱的人做不出自己的菜全凭感觉的人上不了宴席。所以这个项目的路线设计通常遵循一条清晰的依赖链数学基础 → Python工程能力 → 机器学习核心 → 深度学习 → 大模型应用与部署。每一层都建立在前一层之上跳过任何一层后面都会以“似懂非懂”的方式还回来。我在带人时最常看到的现象就是跳过数学直接上Transformer结果连“维度变换”都看不懂调参全靠猜跳过工程化直接跑模型结果代码写得像仓库里堆满了过期罐头。1.2 阶段划分与能力地图我建议把整个学习过程拆成四个阶段每个阶段设定明确的“交付物”而不是“学了多少小时”阶段一数学与Python基础。目标是能独立实现线性回归和KNN算法并写出一份整洁的代码。阶段二经典机器学习。目标是完成一个从数据清洗到模型评估的完整项目比如房价预测或垃圾邮件分类。阶段三深度学习与PyTorch。目标是理解自动求导、张量操作并亲手训练一个CNN或简单的Transformer模型。阶段四大模型工程化。目标是搭建一个基于RAG的问答系统或者完成模型微调与部署。这四个阶段看起来普通但你注意到没有每个阶段都有一个“亲手做出来”的标志性产物。这正是“from scratch”这个项目最反套路的地方——它用输出倒逼输入而不是用“收藏夹吃灰”代替“真正学会”。很多人学AI最大的误区就是“输入过载、输出不足”刷了一百个视频没跑通一个完整的项目。2. 第一阶段实操数学基础与Python工程能力怎么补2.1 别再被数学吓跑——按需学习才是正道很多人一听到“AI要学数学”就直接放弃或者反过来买了一堆《数学分析》《高等代数》啃了三个月然后发现跟AI离题万里。这两条路我都见过都不对。从AI工程的实际需求出发你需要掌握的数学并不是“整个数学系”而是四个板块的精选内容线性代数重点是矩阵乘法、向量空间、特征值分解、SVD。这是理解神经网络层与层之间数据流动的“语法”。概率论与统计重点是概率分布、期望方差、贝叶斯思想、最大似然估计。这是理解模型不确定性、损失函数设计、评估指标的“语义”。微积分主要是多元微积分重点是偏导数、链式法则、梯度。这是理解反向传播的“物理引擎”。最优化基础重点是梯度下降、学习率、损失曲面。这是理解模型为什么能收敛、为什么震荡、为什么陷入局部最优的“动力学”。我的建议是不要按教材顺序从头啃而是按项目需要倒推回去查漏补缺。比如你写线性回归时发现梯度下降公式推不动就回头补偏导数和链式法则你做矩阵分解时卡住了就回头补特征值和SVD。这样学下来的数学是“带着问题找答案”记忆深度完全不一样。2.2 Python工程能力——决定你能否走到最后数学决定你懂不懂AIPython工程能力决定你能不能把懂的做出来。这个观点我在多个场合强调过代码能力是AI工程师的“手”很多人脑子会了、手不会最后只能看着别人的开源代码发呆。你需要重点练这几项能力用NumPy实现张量操作包括广播机制、索引切片、矩阵运算而不是只会调PyTorch的API。写出结构清晰的Python代码函数拆分、类型标注、模块化设计。AI项目一旦变大代码混乱带来的心智负担会远超模型本身的复杂度。熟悉至少一种虚拟环境和依赖管理工具。很多新手在同一环境里装了三遍不同版本的PyTorch最后环境崩了还以为是模型代码的问题。这种低级事故会浪费你一周时间。我在实际带项目时会让新人先用纯PythonNumPy实现一个两层神经网络不许用PyTorch。这个练习逼着他们手动推导前向传播、反向传播、梯度更新的每一步。虽然写出来的代码可能比PyTorch版本慢一百倍但做完这个练习之后再回去看loss.backward()这行代码你会清楚地知道它背后发生了什么而不是把它当成魔法。3. 第二阶段核心经典机器学习——模型背后的“手感”3.1 从回归到树模型掌握模型选择的判断力到了这个阶段你会接触到线性回归、逻辑回归、决策树、随机森林、SVM、K-Means等经典算法。很多人觉得这些“过时了”但我告诉你经典机器学习是培养“模型手感”的最佳训练场这种手感在大模型时代仍然是稀缺品。什么叫手感就是你看到一个数据集能大概判断出这数据适合线性模型还是树模型特征之间是交互关系还是独立关系数据量级够不够支撑复杂模型类别不平衡需要怎么处理过拟合风险出现在哪里。这些判断力来自对经典算法的深入理解而不是来自“看了一篇综述文章”。实操上我建议你按这样一个流程走完至少一个完整项目数据探索EDA画分布图、相关性矩阵理解每一列的含义和分布。特征工程处理缺失值、类别编码、数值标准化、构造新特征。模型选型从线性模型开始再到树模型对比效果。评估与调参划分训练/验证/测试集使用交叉验证学习曲线诊断偏差与方差。这个流程表面平淡无奇但它教你一个核心习惯不要把模型当黑盒要用系统的证据链来做决策——这种习惯到了复杂的大模型项目里会救你的命。3.2 最重要的不是调参而是诊断第二阶段最容易走偏的地方是一头扎进“调参比赛”用网格搜索搜了几百组参数准确率从0.91提到0.92就觉得自己进步了。但真正的工程能力体现在——当模型效果不好时你能不能快速定位问题出在哪里。我给你一个超实用的排查顺序先查数据标签是否泄漏、训练集和测试集是否混入了未来信息、类别分布是否正常。再查基线一个简单的启发式规则比如预测众数能做到多少如果模型比基线提升有限说明特征或者模型能力有瓶颈。然后查拟合状态训练集损失高是欠拟合验证集损失高而训练集很低是过拟合两类问题的解法完全不同。最后才查超参数前面几步没问题才值得花时间调参。我见过一个真实的案例有人花了两周时间调一个分类模型准确率始终上不去最后发现是因为他把“用户ID”当成特征喂进去了导致训练集效果“虚高”验证集直接崩溃。这种问题靠调参永远解决不了必须靠诊断。4. 第三阶段关键跨越从机器学习到深度学习与Transformer4.1 PyTorch——从“会用”到“懂它”深度学习阶段的核心工具我首推PyTorch。为什么因为它把“动态计算图”这种灵活的设计作为第一原则对研究者和工程师都极其友好。TensorFlow虽然也很强但历史上它的静态计算图设计让很多新手在调试时痛苦不堪PyTorch的“跟写普通Python代码一样写模型”的特点大大降低了心智负担。但“用PyTorch写模型”和“理解PyTorch”是两码事。我建议你亲手做三件事用纯Tensor操作实现一个线性层包括初始化、前向、反向。手动写一个training loop包括数据加载、损失计算、optimizer.zero_grad()、loss.backward()、optimizer.step()。很多新手在这里漏掉zero_grad()导致梯度累积loss曲线乱成心电图。理解Dataset和DataLoader的机制以及batch_size、shuffle、num_workers这些参数对训练速度和稳定性的影响。做完这三件事你就算真正“上手”了PyTorch。我还可以告诉你一个小经验先学会阅读PyTorch报错再学写模型。框架的报错信息虽然有时候长到吓人但仔细读往往能精确定位问题。训练中超过一半的“模型不收敛”问题其实都是维度不对、数据类型不对、设备不统一造成的。4.2 从CNN到Transformer理解“注意力机制”不只是看看图现在AI工程绕不开Transformer。很多人靠一张“Attention is All You Need”的架构图以为自己懂了但真正实现一遍之后才会发现之前以为理解的地方全是模糊的。我的建议是分步骤实现一个简化版Transformer你可以参考以下顺序先实现多头注意力机制本身理解Q、K、V是怎么从输入变换来的、为什么除以sqrt(d_k)、为什么需要mask。再实现位置编码理解为什么Transformer没有天然的序列顺序感以及正弦位置编码的几何意义。然后组装Encoder层包括残差连接、LayerNorm、Feed-Forward Network。最后在玩具数据集比如“复制序列”或“简单加法”上训练它观察loss下降的过程。这整个过程可能需要你花一两周但做完之后你会获得一种“通透感”当你在大模型时代听到“上下文长度”“注意力掩码”“KV Cache”这些词时你脑子里会有具体的张量流动画面而不是一堆术语的空转。4.3 本地跑LLM的硬件门槛与实操选择走到大模型这一步很多人会被硬件门槛卡住我需要把真实情况说清楚。以我手头一台32GB内存的MacBook Pro为例跑参数量为7B到8B的量化模型Q4或Q5量化用CPU推理大概每秒能生成5到10个token完全可以用作实验和学习。如果想要更快的速度一块24GB显存的消费级GPU比如RTX 3090/4090可以非常流畅地运行7B到13B的量化模型甚至勉强尝试33B模型的极限量化版本。7B-8B量化模型MacBook Pro32GB可用CPU跑速度可控可用。7B-13B量化模型24GB显存GPU可流畅运行是本地实验的“甜点区间”。70B级别模型需要多卡或至少48GB以上显存消费级基本不现实建议走云服务。基于这个现实我建议初学者的本地实验路线是先用7B级别的量化模型比如Qwen2.5-7B-Instruct或Llama-3.1-8B跑通推理、RAG、Function Calling这些应用场景等需要微调时再根据显卡显存选择合适的基座模型。这样既能学到东西又不至于被硬件劝退。5. 大模型应用工程化从“会跑模型”到“会做产品”5.1 RAG、Agent与微调——怎么选到了大模型应用阶段你会面对三条技术路线RAG、Agent、微调。很多初学者在这里犯迷糊我的建议是先搞懂它们各自解决什么问题再决定从哪条路线入手。RAG检索增强生成解决的是“模型不知道你的私有知识”的问题它通过外挂检索系统给模型提供参考材料实现知识更新快、可控性强、幻觉率低。适合文档问答、客服助手、企业知识库等场景。Agent智能体解决的是“让模型会使用工具、完成多步任务”的问题它通过将大模型与工具调用、规划、记忆相结合处理复杂的任务流程。适合自动办公、代码助手、数据分析等场景。微调解决的是“让模型的行为模式适配特定风格或任务”的问题它直接改变模型的权重。适合领域术语极强、输出格式要求严格的任务。我的建议是初学者先从RAG入手。因为RAG的工程链路清晰、每一步都可以独立验证、出问题也容易排查。而Agent和微调都建立在“模型本身能力已经够用”的前提下如果模型基础能力不足强行做Agent会陷入无休止的prompt调试和工具联调地狱。5.2 动手搭一个RAG系统我带你过一遍最基础的RAG搭建流程这个流程是我在多个项目中反复使用过的基准方案文档加载与清洗用PDF解析器或文本抽取工具把原始文档转成干净的文本重点处理页眉页脚、表格、乱码。文本切分按语义边界切分文本块块大小通常在300-800字之间。这里有个经验值块太小会丢失上下文块太大则检索噪声增多。你需要根据你的文档类型实验。向量化用Embedding模型比如BGE或OpenAI的text-embedding系列将文本块转成向量。注意Embedding模型一定要与你的文档语言、领域匹配。向量存储与检索存入向量数据库比如Milvus、Qdrant、Chroma查询时用余弦相似度取Top-K相关块。提示词组装把用户问题和检索到的文档块组装成Prompt传给大模型生成回答并强制要求“如果参考文档中没有答案就坦诚说不知道”。这个流程跑通之后你才算真正体验了一次“大模型应用工程化”的完整闭环。之后你再优化重排序、混合检索、多路召回才是有根之木。5.3 模型部署的最后一公里模型写得好只是起点真正考验工程能力的是部署和上线。我在实践中体会到部署环节最容易被忽视的往往是这几件事模型量化把FP16模型压到INT8或INT4推理速度可能提升2-4倍显存占用大幅下降。用比如llama.cpp或vLLM来加载GGUF或AWQ格式的量化模型是本地和小规模部署的主流选择。并发与吞吐生产环境需要同时服务多个用户你的推理服务能不能扛住vLLM的Continuous Batching技术能大幅提升吞吐这是它成为部署首选的原因之一。可观测性我强烈建议从一开始就记录每次请求的响应时间、输入输出长度、Token用量方便后续优化和排障。很多人跳过了这一步等到线上出问题就两眼一抹黑。部署还有一种被很多人忽略的“轻量方案”如果并发要求不高比如内部工具或学习项目直接用FastAPI包一层模型推理接口就够了不需要上重型推理框架。我在原型验证阶段通常先用FastAPI等功能稳定后再迁移到vLLM做性能优化。6. 常见问题与避坑指南6.1 学习路线上的高频“翻车点”我根据带项目的经验整理了下面这份避坑清单每一条都是真实踩过或者看别人踩过的“拿来主义”式学习GitHub上clone了一堆项目跑通了就觉得自己会了。但你自己从头写过DataLoader吗没有的话换个数据集你可能就不知道从哪下手。数学恐惧症和数学贪食症两个极端要么完全不学数学要么一头扎进数学分析无法自拔。正确姿势是“项目驱动、按需补充”。死磕调参不重数据数据显示一切问题的根源。先看数据再谈模型。数据质量上去了随便一个模型效果都会提升。忽视代码工程规范训练脚本、评估脚本、配置文件全揉在一个文件里。等到你要复现三个月前的实验时那种痛苦会让你明白“规范”两个字的含义。用“看过”代替“做过”看了一百篇Transformer讲解不如亲手实现一个。知识的掌握程度以你能写出来的代码为准。6.2 本地推理的硬件坑与省钱方案硬件选择是另一个重灾区。我的建议是“先软件、后硬件”在你确认自己真的需要本地大模型之前不要急着买显卡。先用云GPU按小时租用比如AutoDL或各大云厂商的GPU实例把流程跑通、确认需求再决定是否投入硬件。这个策略帮我省下了不少钱也避免了冲动消费后吃灰的问题。如果你确实需要本地部署再考虑以下配置思路32GB内存的Mac或PC可以跑7B量化模型适合学习和轻量任务。24GB显存的NVIDIA GPU本地部署的“性价比甜点”7B-13B量化模型流畅运行可以做一些严肃的实验。多卡或48GB以上显存进入“高阶玩家”区间适合跑更大模型或并发服务。还有一个容易被忽略的问题散热和噪音。高负载跑模型时GPU风扇的噪音非常大如果你在办公室或家里部署一定要提前想好放置位置和散热方案。6.3 一个实操排查案例本地模型越聊越“笨”我遇到过一个很典型的排查案例。有个朋友部署了本地模型刚开始对话很正常但聊了一段时间后模型开始回答得越来越简短甚至有点“前言不搭后语”。他怀疑是模型出了问题重装了一遍依然如此。我问他是不是没清理对话历史他才想起自己的代码把整个对话历史都塞进了上下文窗口越塞越长模型能用的“有效注意力”越来越少回答质量自然往下跌。解决方式也很简单限制对话轮数、适时裁剪历史消息、或者做摘要压缩。这个案例特别典型因为它揭示了大模型应用工程中一个核心认知上下文窗口不是无限免费的资源它既是能力边界也是成本边界。很多“模型变笨了”的问题根因根本不在模型而在应用的上下文管理策略。7. 长期精进如何让“from scratch”的底子持续生长走到这一步你已经具备了一个从零开始构建AI系统的基本能力框架。但我要泼一盆冷水“from scratch”不是一次性的通关任务而是一种持续的学习姿态。技术栈会不断翻新。今天你熟悉的这些工具和框架很快就会过时。但你在“from scratch”过程中练出来的核心能力——拆解问题的能力、亲手验证的能力、读文档和源码的能力、快速定位问题根因的能力——这些东西不会过时。根据我个人的经验我建议你在完成基础路线后定期做三件事持续跟进开源社区的新模型和工具注意关注官方文档和release note而不是二手中文解读给自己设定一个有挑战性的项目目标比如“我能不能自己搭一个带RAG的私人知识助手”坚持输出和记录。写博客、写笔记、做分享都是很好的方式因为“能讲清楚”和“能写清楚”是最严格的验证标准。最后再说一个心态上的建议遇到不懂的不要慌去读源码、看官方教程、拆别人的代码。这个领域没有什么“看一眼就会”的神迹所有看似云淡风轻的输出背后都是一遍遍从零开始的笨功夫。