1. 先想清楚AI工程到底解决什么问题1.1 项目标题背后的真实含义如果你最近在GitHub、技术社区或者各类学习群里逛过大概率会对“ai-engineering-from-scratch”这种命名风格有印象。它不是一个具体的开源框架也不是某个公司的内部项目代号而是一种典型的“个人成长路线图”式项目——很多人把它当作自己的AI工程学习清单也有人直接拿这个标题建仓用来沉淀自己从零搭建AI系统的全过程。“from scratch”这几个字是关键。它不是让你从PyTorch手写一个Transformer也不是要求你脱离所有现成工具从汇编开始写代码。这里的“scratch”指的是不依赖任何现成的AI解决方案亲手把一个AI应用从数据处理、模型训练或微调、评估、部署到监控的完整链路搭起来。说白了就是用自己的手把整个AI工程闭环走一遍。这个项目标题最近热度很高背后其实是行业的一个真实变化AI工程师这个岗位正在从“会跑模型的人”变成“能交付稳定系统的人”。我见过太多能把模型精度调到刷榜水平的同学一到上线就翻车——接口超时、内存泄漏、数据分布漂移、成本失控全是工程问题。所以“ai-engineering-from-scratch”这类项目本质上是想回答一个问题怎么从只会调包变成真正能独立交付AI系统的人。这篇文章我就围绕这个主题把我自己从零搭建AI工程能力的过程中踩过的坑、验证过的路径、实际可用的方法完整梳理一遍。不管你是正打算转行AI工程师的开发者还是已经在写业务代码但想切入AI方向的程序员又或者是刚学完机器学习理论、工程经验几乎为零的同学这条路线都值得你跟着走一遍。1.2 会调API和做AI工程之间的那道坎先说一个很多人不愿意面对的事实会调OpenAI接口、会跑通一个HuggingFace上的模型离“AI工程”还有很大一段距离。调API这件事本质上是消费一个现成的智能服务——你只需要处理输入输出格式做一个壳子包住它。但AI工程面对的问题完全不同你的数据从哪里来格式怎么清洗标注质量怎么保证模型效果怎么衡量单条样例看着不错但整体准确率、召回率到底怎么样系统上线后模型表现会不会随业务数据变化而下降谁来发现、谁来处理1000个并发请求打过来GPU显存够不够延迟能不能压到业务要求的200ms以内成本一个月会不会把预算花爆这些问题没有一个是模型训练本身的数学问题全都是工程问题。而工程问题的特点是你可以靠“想当然”跳过但上线后一定会加倍还回来。我举个具体的例子。之前有个朋友做一个法律文档问答系统在线demo跑得特别漂亮客户看了很满意。结果一上生产当天就出问题真实用户上传的PDF有的是扫描件、有的是倾斜的图片模型直接识别成一堆乱码有的提问方式跟demo里的测试问题完全不一样检索模块召回的内容根本不对回答质量直线下降。这些问题不是模型的错是工程链路上每一个环节都在漏气。所以我一直觉得AI工程的核心不是模型而是围绕模型建立起来的一整套支撑系统。数据管道、评估体系、服务框架、监控告警哪一环弱了整个系统就不可靠。“from scratch”的意义就在于你把每一环都用自己手搭一遍才会真正理解它为什么存在、什么时候会出问题、出了问题怎么排查。1.3 从零开始搭一遍到底搭的是什么我自己的理解所谓“从零开始”是一个带有强烈个人色彩的学习策略。它的内核是不要第一步就上最成熟的平台、最完善的框架而是先用最朴素的方式把流程跑通然后再逐层替换成工具和最佳实践。这套策略的价值在哪里我拿做饭来类比。用预制菜包三分钟炒出一盘鱼香肉丝和从洗菜、切菜、调汁开始做一盘体验完全不同。预制菜确实方便高效但你也因此永远不知道肉丝为什么要在油温七成热时下锅、鱼香汁为什么要分两次勾芡。AI工程也一样——直接套用现成的MLOps平台你可以飞快跑通一个demo但对底下的每一个环节为什么这么设计完全没有体感。一旦平台不满足你的特定场景或者出问题需要深度排查你就卡住了。所以这个项目的搭法通常包含这么几个模块数据处理层写脚本清洗数据、构建训练集、做数据版本管理理解数据质量对模型的天花板效应。模型层微调一个开源模型或者用现成模型做推理理解训练和推理的差异。评估层搭建离线评估集定义指标量化模型效果。服务层封装API、处理并发、做缓存和限流把模型变成一个可以被业务调用的服务。运维层监控延迟、吞吐、成本和模型漂移建立告警机制。每一步都不需要做到专家级但必须亲手碰过。这套流程走完你对“AI系统”的理解会上升一个台阶——你不再只关心“模型怎么选”而是会主动思考“整个系统怎么长期稳定地运转”。2. 地基别省事基础能力的搭建顺序2.1 Python不是“会写”就行而是要写出能维护的代码很多人一上来就冲模型、冲框架Python基础约等于“能跑通notebook”。这在做AI工程的时候会非常痛苦。因为AI工程的核心特征是代码的迭代频率极高——你要不断调数据、换参数、跑实验代码如果写得乱七八糟改一个地方崩三个地方实验没法做下去。我自己的经验是做AI工程Python需要重点掌握这几个能力而不是去钻研语言冷门技巧第一类型注解。Python是动态语言但AI项目的数据结构复杂得很——一个训练样本里可能有文本、有标签、有特征向量没有类型标注过两周你自己都看不懂那个dict里存的是什么。第二虚拟环境和依赖管理。这是新手最容易忽略的。我见过太多同学在全局环境里装了一堆包版本冲突到天翻地覆最后只能重装系统。建议从第一天就学会用venv或conda隔离环境配合requirements.txt或pyproject.toml锁定依赖。第三异常处理和日志。写notebook的时候可以随便print但写工程代码必须用logging模块。为什么因为生产环境你不可能盯着控制台看你需要在出问题之后通过日志回溯当时到底发生了什么。我吃过这个亏——某个数据处理脚本跑了三天某天突然挂掉因为当时print的内容根本覆盖不了错误现场最后只好加了一堆日志重跑白白浪费三天。我给你一个可以直接抄的推荐路径先花两周时间把Python的虚拟环境、类型注解、logging、unittest/pytest、yield和context manager这几个知识点过一遍然后找一个中等规模的开源项目读一遍源码结构。不需要精通但要有“代码是给别人看的”这个意识。2.2 数学和机器学习基础补到什么程度才够用很多想入行AI的同学卡在数学恐惧上。我直接说结论做AI工程数学不需要学到研究生的深度但四个概念必须真正理解。第一个是向量和嵌入。你要能理解文本、图片如何被表示成向量余弦相似度到底在算什么。RAG系统、向量数据库、推荐系统全建立在这个概念上。第二个是概率和不确定性。模型输出的不是“唯一正确答案”而是一个概率分布。理解了这一点你才能明白为什么同一个问题模型会给出不同回答也才能设计出合理的置信度判断逻辑。第三个是损失函数和梯度下降。你不一定要能手推反向传播但必须理解“训练”的本质是降低损失、是沿着梯度方向调整参数。否则你连学习率、batch size这些参数为什么重要都理解不了。第四个是过拟合和偏差方差。这个直接决定了你在真实项目中怎么判断“模型训练得很好”是真是假。训练损失特别低、验证损失却很高这就是过拟合的典型信号。不是让你去啃完一整本《统计学习方法》才动手。更好的思路是先用起来遇到需要的数学概念再回头查。我做向量检索的时候发现自己对“维度”的理解太浅就专门花了一天补了线性代数里的基、维度和投影。这种“按需学习”的效率远高于从头到尾啃教材。2.3 从“能跑通”到“可复现”这是工程化思维的第一课从零开始做AI工程第一课不是学什么框架而是学会“让实验结果可复现”。这个意识的差距直接区分了“做实验的人”和“做工程的人”。什么叫可复现简单说**三个月后或者换一台机器你还能把今天跑出来的结果原样复现出来。**听上去简单做起来难。我见过太多人跑了个实验效果不错但问他“你用的哪个版本的库随机种子是多少数据的预处理脚本在哪里”——一问三不知。这种实验对工程来说是无效的因为你没法把它变成稳定可交付的东西。实操层面我建议从一开始就养成三个习惯第一固定随机种子。PyTorch、NumPy、Python内置的random都要分别设置种子很多坑都是“明明代码没变效果却不一样”结果是因为GPU的并行计算本身就带有随机性。固定的种子不能百分百保证复现但至少能消除一部分变量。第二配置文件与代码分离。不要把所有参数硬编码在代码里用YAML或者JSON单独维护一份配置。跑实验的时候顺手把配置存档跟实验结果记录放在一起。第三数据快照。原始数据、清洗后的数据、训练集验证集的划分结果都要按版本保存下来。数据变了模型结果就不可比了。我自己会按日期加序号的方式命名数据目录比方说data/20250214_v3简单但极其有用。这一步不需要任何高级工具养成习惯比掌握工具重要得多。等你真的吃过“结果复现不了”的亏就会明白这三个习惯有多值钱。3. 核心技能闭包把模型从试验品变成产品3.1 训练和微调关键技术在数据而不是模型参数很多人以为微调模型的核心是“调参数”我做了几个项目之后的体会完全相反**微调的质量80%由数据决定剩下的才是参数和算力。**为什么因为开源基座模型的通用能力已经很强了微调的目的从来不是让它“学会新知识”而是让它“熟悉你的数据分布和任务形式”。数据层面的实操要点我可以拆成三步第一步是清洗。这一步最脏最累但也最影响效果。编码问题、HTML标签、重复片段、敏感信息都要处理干净。我有一个特别深的印象某次微调之后模型回答总是莫名其妙多出一句固定的话排查了半天才发现是训练数据里有一条重复了300多次的样本模型把它当成了高频模式。第二步是格式化。把数据组织成模型期望的指令格式。现在主流做法是用对话模板比如sHuman: ... Assistant: ...这样的结构。这里有个很容易犯的错指令格式要和推理时保持一致。你训练时用了带系统提示词的格式推理时却忘了加效果就会明显退化。第三步是配比。训练集里不是样本越多越好不同类型数据的比例很讲究。通用对话数据占比过高模型会变得泛泛而谈领域数据占比过高又容易过拟合甚至灾难性遗忘。我一般会从7:3通用数据:领域数据起步根据效果上下调整。至于参数层面现在最主流的是LoRA这类参数高效微调方法。它的聪明之处在于只训练一小部分附加参数原始模型权重保持不变。好处是显存占用小、训练速度快而且不太容易过拟合。我实测下来大部分任务用LoRA的效果已经足够接近全量微调甚至在某些小样本场景下更好。所以不要一上来就全量微调那个成本根本不是在“从零开始”阶段该碰的。3.2 评估体系没有评测就没有工程如果说数据是AI工程的地基那评估体系就是承重墙。**没有合理评估体系的AI项目就是一口没有仪表盘的井——你都不知道它什么时候会干涸。**这也是“模型效果好”和“系统可交付”之间最大的分水岭。最基本的做法是构建一个离线评估集。我建议不要用训练时的验证集充当评估集而是专门留出一批“没见过的、贴近真实业务场景”的数据。评估集的设计有几个要点覆盖边界情况正常的、模糊的、极短的、极长的、带错别字的、中英混合的都要有。定义可量化的指标分类任务看准确率、召回率、F1生成任务可以用BERTScore或人工评分检索任务看命中率RecallK。定期更新每积累一批真实线上数据就从中抽样补充进评估集防止评估集和真实场景脱节。这里我想多提一句很多人评估大模型生成结果时喜欢自己看几条样例然后说“感觉不错”。这在大模型时代特别危险。大模型生成的答案千变万化人工看十条感觉不错跟系统真实效果可能差距很大。我现在的做法是先跑一遍系统把所有输出结果批量记录下来然后按规则匹配关键词或参考标准答案做初筛再对初筛有疑问的样例做人工复核。这样既保留了对质量的判断又避免了人工一条条看带来的不可持续。3.3 RAG和提示词工程看似人人在做实则处处有坑这两个概念是当前AI应用落地最热的两个抓手网上教程满天飞看起来门槛极低。但我自己做过之后才明白每一个环节全是细节每一个细节都在影响最终效果。先讲RAG检索增强生成。一句话解释它的原理让模型在回答前先检索相关文档把检索结果作为上下文再生成答案。为什么需要它因为模型的参数知识有截止日期而且会一本正经地编造事实也就是幻觉。RAG相当于给模型开卷考试让它可以查资料再作答。RAG的坑主要集中在三个地方。第一个是分块策略。文档切成多大多小的块直接决定检索质量。切得太小语义不完整切得太大混入大量无关信息检索精确度反而下降。我一般会先看文档的结构特征手册类按章节切问答类按问答对切长文按段落加重叠窗口切块大小和重叠量是实验调出来的不是拍脑袋定的。第二个是检索效果评估。很多人把RAG做完只看最终回答“像不像样”根本不单独评估检索环节。这就像炒菜只尝最后成品不管食材新不新鲜。我建议做一个简单的抽检把查询扔进去看召回的top5文档里到底有没有真正相关的。如果检索这块就不行后面模型再强也白搭。调优方向有两个一是向量模型换更强的比如bge系列或其他中文优化过的模型二是做混合检索——向量检索加BM25关键词检索再做一个融合排序。第三个是上下文长度管理。虽然现在模型上下文窗口越来越大但往里面塞得越多模型越容易“迷失在中间”时间和成本也在涨。检索回来的文档要过滤、去重、压缩只保留和当前问题最相关的片段而不是无脑全塞进去。再讲提示词工程。我的观点是提示词不是“写几句指令”那么简单它其实是你与模型之间的接口协议。写提示词要有结构化思维角色定义、任务描述、输入格式、输出格式、约束条件、示例每一样都清清楚楚。最容易被忽略的是“输出格式”和“约束条件”——你要告诉模型必须按JSON输出哪些情况要回答“不知道”而不是让它自由发挥。这里我推荐一个笨但有效的方法把提示词当成代码来管理。每个版本放到配置文件里记录修改时间、修改原因、对应的评估效果。没有版本管理的提示词改来改去改到最后你都不知道现在这个线上版本为什么好。3.4 推理优化响应速度和成本是两条不能回避的硬约束模型效果好不等于能上线。真正上线的时候你会被两个硬指标追着跑延迟和成本。先说延迟。业务方通常要求接口P99延迟在几百毫秒到一两秒之间但一个7B参数的模型在GPU上跑一次推理可能就要一秒钟甚至更久。怎么办几个常用手段量化把模型权重从FP16降到INT8甚至INT4速度翻倍、显存减半精度损失通常可以接受。像GPTQ、AWQ这些方法目前很成熟我实测下来7B模型INT4量化后回答质量肉眼几乎看不出差别。流式输出不用等服务端生成完整答案再返回而是边生成边推送给前端。用户的体感等待时间瞬间缩短这个体验优化性价比极高。缓存对于重复性高的查询比如常见FAQ按语义相似度做结果缓存命中缓存直接返回秒级响应。注意缓存策略要设计好过期时间防止数据更新后返回旧答案。再说成本。AI应用的成本大头是推理而大部分人算成本时只算“GPU价格”不算数据、标注、人工排查的时间成本。我的建议是上线前就建立一套简单的成本量化方式平均每个请求消耗多少token、多少GPU时间折算成钱设定合理的缓存命中和降级策略。这个在项目早期看起来麻烦但成本失控往往就是早期没在意、后期救不回来的。4. 工程化落地从笔记本到生产环境4.1 服务化部署先跑通一个不丢人的最小系统模型在notebook里跑通和生产环境提供服务中间差着一整层工程化的工作。我的经验是不要一上来就搞Kubernetes、服务网格那套先把一个最小可用的API服务跑通再谈大规模。对于一个从零开始的项目我推荐直接用FastAPI。原因很实在它对异步的支持好性能在线文档自动生成开发和调试的体验对新手极其友好。一个基本的AI推理服务需要的核心能力就三样模型加载模型要常驻内存不能每个请求都重新加载一遍。这是个新手高频会犯的错——把加载模型写在请求处理函数里结果并发一起来GPU和CPU都直接打爆。请求校验用什么schema接收输入超出长度怎么办非法JSON怎么处理用Pydantic顺手做掉别让脏数据打到模型层。并发控制如果同时来了50个请求是排队还是一次全上通常要用信号量或队列做限流。没有限流的服务一个慢请求可能把整个GPU显存拖垮连带影响其他请求。我给你的建议是第一版部署不要追求什么高可用、自动扩缩容。就在一台服务器上用systemd或supervisor把API服务常驻跑起来加个Nginx做反向代理能稳定跑一周不崩已经比很多人强了。等你真的理解了每个环节的职责再上容器化、上编排都是水到渠成的事。4.2 监控与可观测性让系统出问题时你第一个知道很多人部署完AI服务最关心的是“能不能跑”很少考虑“跑得好不好”“什么时候会坏”。直到线上出问题了才发现——日志没留够、指标没埋点、告警没配置什么都查不到。可观测性这个事必须在系统上线那天就做不能等到出了问题再补。AI服务相比普通Web服务多了一层独特的监控对象——模型行为本身。除了常规的QPS、延迟、错误率我强烈建议监控这几个AI特有指标Token消耗量这个直接跟成本挂钩异常突增往往意味着有用户在刷接口或提示词被注入了一些奇怪的超长内容。空响应和错误响应率模型输出为空、或抛异常的比例突然升高很可能说明输入数据分布漂移了。输出长度分布突然变长或变短都值得警惕。变短可能是模型退化变长可能被攻击或者上下文被过度填充。用户反馈数据如果产品里有“点赞/点踩”按钮这个数据的价值极高它是线上模型效果最直接的真实反馈。技术选型上如果不想一开始就上Prometheus和Grafana那套重的东西可以先从简单的入手——记录结构化日志、定期汇总统计配合一个简单的告警脚本。等量上来了、需求复杂了再迁到完整的监控平台。关键是要有这个意识在用户发现问题之前你先发现问题。4.3 自动化评估与持续集成把质量关写进流程里模型迭代必然会带来一个问题新模型真的比旧模型好吗如果只靠拍脑袋很容易出现一种尴尬情况——新模型在测试集上分数更高但线上用户反而觉得变差了。这背后要么是评估集有问题要么是对齐没做好。所以从零开始的项目我建议把“自动化评估”这个意识尽早建立起来。具体做法是写一个评估脚本输入是模型版本和测试数据输出是一份评估报告准确率、召回率、成本、延迟等关键指标。然后把评估脚本集成到CI流程里任何模型权重、提示词、检索策略的变化都必须跑一遍评估才能合并上线。这样做的好处很直接每一次改动的影响都清清楚楚回归问题能第一时间暴露而不是某次更新上线两周后业务方跑来告诉你“最近效果不太行但不知道哪天开始不行的”。持续集成这块很多人的误区是以为只有代码才需要CI。实际上AI项目里数据、模型、提示词、评估集都应该纳入版本管理和变更流程。数据变了大版本、模型换了权重、提示词改了措辞都应该像代码变更一样留下记录。不夸张地说这决定了你的AI系统是“越改越稳”还是“越改越乱”。4.4 数据闭环真正的护城河是人人都能做但没人坚持做的一件事技术圈有个说法AI项目的壁垒不在模型在数据。这句话不完全对但方向是对的——模型开源的可复现性越来越强技术方案可以互相学习但你的业务数据和用户反馈是外面拿不到的。数据闭环指的就是**把线上产生的真实数据有计划地回收、清洗、标注再回流到评估集和训练集里让系统越用越准。**这个循环听起来很简单真正落地的项目少之又少因为太繁琐了——需要产品埋点、数据管道、标注流程、质量抽检全都要有人做。但哪怕从最小粒度开始这个闭环也值得早启动。举个例子你的AI客服上线后用户满意和不满意的对话数据都可以留下来。每周抽50条不满意的人工看一遍原因是什么是检索没找到资料是答案不完整还是语气不对把原因归类对应地去修数据、改提示词、补知识库。坚持一个月系统的真实效果会有肉眼可见的提升。这个过程中有一个很容易被忽视的点不要只收数据不关注质量。用户反馈里包含大量无效噪音乱点、随意输入、机器人试探如果不做清洗直接回流训练模型反而会被带偏。人工抽样质检是必不可少的环节。5. 从零开始最常见的坑我替你踩过了5.1 数据泄漏模型的惊人表现可能是假象如果你在训练前就顺手看过测试集的内容那你的评估分数就是一场自欺欺人。听起来像常识但实际操作中有很多隐蔽的数据泄漏方式。举几个我见过或犯过的例子清洗数据时把去重做在划分训练测试集之后导致同一个内容同时出现在两边从网上下载的公开数据集本身就包含answer内容的痕迹构造评估集时从测试环境里复制了一部分数据但那些数据早就被模型训练时见过了。怎么防我的习惯是数据划分这件事一定要放在所有清洗和预处理流程之前完成。并且划分后的测试集要“锁死”——除了做最终评估任何环节都不应该再碰它。这就像一个考场试卷在考试前不能让考生见着。5.2 GPU资源不够时就先做“穷人的工程”不是每个人都能拿到A100集群绝大多数从零开始的人手里的资源可能只有一张消费级显卡甚至只有CPU云服务器。资源不足怎么做AI工程我的答案是工程能力恰恰是在资源受限时磨炼出来的。讲几个穷办法用小模型验证流程。不要上来就要跑13B的模型。先用一个小模型把数据处理、评估、服务化的完整链路跑通再换大模型流程不会变踩的坑也一样的。等小模型把问题全暴露完了你用大模型会顺利得多。用蒸馏数据代替真实数据做实验。用一个大模型生成一批模拟数据用来测试数据管道的逻辑和服务的健壮性不一定非要用真实数据才能做工程验证。API代替自建模型。如果自建模型的成本太高前期完全可以用成熟的API服务把业务逻辑跑通同时把评估、监控、数据闭环这套工程体系建起来。等业务验证真的需要自建模型了再考虑训练而不是一开始就抱着“必须自己训练”的执念。5.3 模型更新后线上效果反而变差先查评估对齐训练实验室出现过一个典型场景新模型离线评估分数全面提升满怀信心上线结果第二天发现用户投诉变多。排查了一圈最后发现原因是——评估时候的提示词、检索参数和线上配置不一致。这就是评估对齐问题测评环境跟生产环境配置不一致评估结果就没有参考价值。现在我每次评估前都会强制检查一遍提示词版本是否一致检索用的向量库、参数配置是否相同解码参数温度、top_p等是否相同这些细节任何一个不一致评估结果都可能是在“替另一个系统说话”。建议的做法是把线上配置导出为一个配置文件评估脚本直接读取同一份配置从根上避免两套环境走样。类似“为什么我在测试环境好好的上生产就崩”的问题多半都能用这种方式规避。5.4 学习资源太多反而学不动送你一条执行策略这个领域的信息量极其庞大每天都有新论文、新技术、新工具。很多人不是不努力而是被信息淹没陷入“收藏了就是学会了”的假性学习。我的执行策略很简单只有三条第一每个阶段只学一个主题。比如这个月专注RAG就只看资料只做相关实验别的热点先放放。一周内不被另一个新概念带跑你的进度就已经超过大多数人了。第二必须做产出。看完一篇技术博客就动手复现一个简化版学完一个概念就在自己的项目里用起来。AI工程是技能技能只能通过做来内化阅读和观望不会带来任何工程能力。第三拿一个真实项目贯穿始终。选定一个自己真正关心的小场景比如给个人知识库做智能问答、给团队做自动化周报把这个项目从数据到部署完完整整做完。项目做完的时候你的能力也就起来了。最后再说说我的体会。做了几年AI相关的工作之后回头看“从零开始”最值钱的地方其实不是那些具体的工具和框架——工具每年都在变去年的最佳实践今年可能就被淘汰了。真正值钱的是你亲手走完一遍之后形成的系统直觉看到一个AI需求能本能地判断难点在哪里、风险在哪里、成本在哪里出了问题能快速定位是数据的问题、模型的问题还是链路的问题。这种直觉没法靠看教程获得只能靠把一个又一个项目从零搭到跑、从跑通到优化、从优化到稳定一步步喂出来。所以如果你正打算开始自己的“ai-engineering-from-scratch”我的建议只有一句别收藏了现在就新建一个项目目录写下第一行代码。从最简单的数据清洗开始每一步都亲手做一遍踩坑之后记录下原因。几个月后你回头看这条从零走出来的路会觉得这是你在AI领域做过最值得的一件事。