这些年我见过太多从零开始学AI的人卡在同一个地方课程刷了一堆GitHub上仓库clone了不少可真要独立把一个需求变成能稳定跑的在线服务心里就没底。这个叫“ai-engineering-from-scratch”的项目本质上是想解决这个痛点——它给“会跑通Notebook但不会做系统”和“会写代码但不懂模型”的人画了一条能落地的完整路径。它不是论文复现指南也不教你怎么调一个炼丹参数而是从数据怎么来、模型怎么选、训练怎么记、服务怎么部署、上线之后怎么盯把AI工程化这件事从头到尾串起来。这个项目适合三类人刚入门想系统构建AI能力的工程师、算法岗想补工程短板的研究生、以及在小团队里被迫“全栈”的开发者。内容跨度很大但我按自己的实操经验做了取舍把每个环节的必备动作和常见坑都写进去。下面这些内容就是我在整理这个项目时的核心思路和实战记录。1. 先把“AI工程”这件事拆清楚你不是在写算法是在造系统1.1 从一段训练代码到一套可交付系统中间隔着的就是工程很多人觉得AI工程就是“训练模型”这是最大的误解。训练模型只是中间一环真正占时间和精力的是数据清洗、实验管理、服务封装、性能优化、灰度发布、监控告警。我见过不少算法功底不错的人模型在离线测试集上指标很漂亮但一旦部署上线就状况百出——不是线上特征和训练时对不上就是单次推理太慢把服务拖垮再或者模型对某个小众但高价值的场景频繁预测错误。这也是ai-engineering-from-scratch这个项目想传达的第一件事算法和工程是一个系统的两条腿缺一个都站不起来。工程能力不是“写点接口把模型包起来”那么简单它涵盖了数据版本管理、实验可复现、推理延迟控制、资源成本控制、模型监控与持续迭代。这套东西在业界常被归到MLOps或LLMOps名下但叫法不重要重要的是你能不能把它跑通。1.2 从零起步的四个阶段对应不同的能力层次我把整个学习路径拆成四个阶段不追求一次到位而是每层解决一个问题阶段核心目标关键能力产出物第一阶段工具链跑通Python、PyTorch、Git、Docker能复现一个公开模型的训练第二阶段最小闭环数据处理、模型微调、离线评估一个端到端的离线项目第三阶段质量与效率实验管理、自动化评估、特征治理一套反复迭代的流水线第四阶段生产级稳定服务化、监控、告警、回滚一个抗得住线上流量的系统第一阶段最容易被人忽视很多人一上来就想学大模型微调结果连CUDA环境都配不明白。我的建议是老老实实把Python虚拟环境、Docker镜像、Git分支、PyTorch基本训练循环过一遍这些工具看着不起眼但后面每个阶段都会用到。第二阶段开始接触真实业务数据理解数据和模型之间的交互。第三阶段重点解决“改一个参数之后到底有没有变好”这个信任问题。第四阶段才谈得上稳定性、容灾和成本控制。这个结构的价值在于每个阶段都有明确的验收标准。你不用再问“学完机器学习基础下一步该干什么”因为每个阶段都有一堆子任务等着你去完成。2. 核心设计思路用“可交付”倒推学习路径而不是按课程目录来2.1 为什么我坚持项目驱动而不是按算法分类学传统学习路线是先学线性代数再学统计学习再学深度学习再学自然语言处理……这套体系在学术上很严谨但实操起来问题很大。大多数人不是要成为算法研究员而是要解决“把简历分类”“把客服对话自动摘要”“预测下个月的销量”这类具体问题。按算法分类学你会陷入“学了一大堆但不知道用哪个”的困境。所以我为ai-engineering-from-scratch定的方法论是从一个可交付的完整项目入手按需学习底层原理。比如要做一个评论情感分类服务你需要先搞清楚文本怎么变成向量再搞懂一个预训练模型怎么加载然后处理数据不均衡还要把模型封装成HTTP接口。整个过程涉及的知识点跨了数学、机器学习、软件工程三个领域但每一项都对应一个具体动作学完就能用。这样做还有一层好处你从一开始就建立“系统思维”。你会意识到数据处理方式和模型结构同样重要评估指标要跟着业务目标走一个线上服务要考虑并发和延迟。这些能力在纯理论课程里学不到却在日常开发中天天用到。2.2 一个循环往复的AI工程闭环整个项目围绕一条主循环展开业务需求 → 数据采集与清洗 → 基线模型 → 离线评估 → 迭代优化 → 服务部署 → 线上监控 → 回到需求。这条闭环看着简单但每个节点都有独立的方法论。我总觉得很多人做不好AI项目就是因为这个环是断的比如只负责训练模型不知道业务方真正关心的是“错误样本会带来多少损失”比如模型部署上线之后不再看它等到业务方反馈质量下降才后知后觉。闭环里的“离线评估”和“线上监控”是新手最容易水的地方。离线评估不是只看一个准确率还要做分维度评估——比如不同长度文本的效果、不同情感极性上的表现、置信度校准情况。线上监控则要盯住预测分布和特征的漂移。我在项目里专门把这些环节单独开章因为它们是模型能持续发挥价值的关键。2.3 关于“从零”的两个常见误解第一个误解是“必须把数学推导搞透彻才能动手”。我承认数学很重要但“从零开始”不等于“从公式开始”。现代AI框架已经把大量底层逻辑封装好了你需要理解的是“为什么用交叉熵做分类损失”“梯度下降在做什么”这个层面的直觉。数学短板可以在遇到具体问题时补而不是前置到劝退自己。第二个误解是“什么都得自己写”。我见过有人为了练习手写梯度下降、手写Transformer、手写数据加载器结果一个月过去连一个完整项目都没跑完。工程领域的正确做法是站在巨人肩膀上用PyTorch当自动微分框架用Hugging Face的Transformers管理预训练模型用FastAPI做服务封装。自己写代码的目的是理解机制和满足定制需求而不是重复造轮子。3. 技术栈选型每一层我都帮你试过一遍3.1 数据层从Pandas到Polars再配上版本管理AI工程里最不缺的就是数据操作。小规模数据用Pandas足够数据量到几千万行时Pandas的内存占用和处理速度会让你怀疑人生这时候可以切到Polars。Polars基于Rust实现采用多线程和惰性计算处理速度通常在Pandas的数倍以上而且API设计对Pandas用户很友好迁移成本不高。数据版本管理很多人完全忽略。训练集被悄悄改了一行可能就导致实验结果无法复现这在新手项目里是高频事故。我用DVCData Version Control来管理数据集版本它能把数据快照和Git提交关联起来每次实验用哪份数据、哪个代码版本一查便知。配上云存储或Linux文件系统做远程缓存一个小团队完全玩得转。数据质量检查也不要等训练时才做。我在项目里会先写一批断言式的检查脚本比如字段缺失率不能超过5%、类别分布不能偏移超过阈值、数值范围必须在合理区间。批处理阶段用Great Expectations这类工具可以自动化做校验小项目的话自己写几个assert也足够。3.2 模型层以PyTorch为主吃透一个框架比泛泛了解三个强现在AI框架有很多选择PyTorch几乎成了研究到工程的事实标准。它的生态太完善了从Hugging Face到Lightning再到各种部署工具天然围绕PyTorch构建。我不会在这上面搞多框架对比老老实实把PyTorch的数据集类、模型定义、训练循环、分布式原语吃透后面做什么项目都顺。模型库直接拥抱Hugging Face生态。你不需要自己实现BERT或者LLaMA的注意力机制transformers库提供了一致化的接口。几行代码就能加载一个预训练模型做推理再配合PEFT库做参数高效微调即使只有一块消费级显卡也能对亿级参数模型做微调实验。这里的核心知识点是搞清楚tokenizer、model、dataset这三个组件如何协作把加载流程和推理流程理解到位胜过手动实现十个结构。3.3 训练层先用单卡跑通再考虑规模化新手最容易踩的坑是一上来就研究分布式训练结果环境配置比模型训练还痛苦。我在项目里的建议很明确单卡能解决的问题不要用两台机器来解决。先用单卡把一个全流程跑通、指标跑准再去考虑DDP、DeepSpeed或者Kubernetes上的弹性训练。实验管理我用Weights Biaseswandb每一组实验的超参数、Loss曲线、评估指标、模型二进制都会自动记录。它的价值不只是画几张好看的曲线图而是让你在回头排查时能精确回答“第几组实验在哪个版本的数据上得到了这个结果”。这个能力在团队协作时尤其重要。3.4 部署层FastAPI做服务封装轻量场景足够能打模型部署远不止一个model.predict()。生产环境要考虑请求鉴权、超时控制、并发限制、批量推理、缓存策略。我大多数项目的服务端会选择FastAPI它基于ASGI性能好、原生支持异步配合Pydantic做入参校验非常顺手。如果模型推理比较耗时可以用批处理队列把请求攒起来一次推理显著提升吞吐。比服务框架更重要的是推理引擎。PyTorch的原生部署方式直接又笨重换成ONNX Runtime或者TensorRT之后推理速度经常能有2到5倍的提升。我习惯先把模型导出为ONNX格式再根据部署环境决定是否进一步优化。要不要上Triton Inference Server这类专业推理平台主要看你的并发规模和多模型管理需求小流量场景FastAPI单机扛得住没必要一上来就上重型武器。3.5 可观测层没有监控的模型就是一颗定时炸弹上线不是终点。线上模型的性能会因为数据分布变化、上游特征变更、用户行为演化而慢慢劣化。所以ai-engineering-from-scratch把可观测性放在和模型训练同等重要的位置。我至少会监控三组指标一是服务本身的状态包括QPS、延迟P50/P99、错误率、超时率二是模型输出的行为比如预测类别分布有没有发生突变、平均置信度是否在下降三是输入特征的质量比如某些关键特征是否大面积缺失、取值范围是否偏移。前面两类用Prometheus加Grafana就能搭起来第三类需要通过特征统计任务定期计算我一般用PSIPopulation Stability Index来量化分布偏移程度超过阈值就触发告警。4. 最小可复现案例从零做一个评论情感分类服务光讲方法论不够我拿项目里的一个具体案例来演示整个流程——给在线评论做情感极性分类区分正面和负面。4.1 任务定义与数据准备任务输入是一句用户评论文本输出是positive或negative。我用一个公开的电商评论数据集总共大概两万条正负样本比接近1.5:1。第一步先把数据切成训练集、验证集、测试集比例是8:1:1。切分时要注意按文本去重避免同一条评论的变体同时出现在训练集和测试集否则评估结果会虚高。这里有个容易被忽略的细节标签的构造方式会直接影响后续所有环节。比如“这个商品还行但物流太慢”这句评论到底算正面还是负面我选择按评分阈值来定4星及以上为正面1到2星为负面3星直接丢出训练集。定好规则后写进数据说明文档这是工程化的第一步——让每个人对数据的理解完全一致。4.2 数据处理与Tokenizer的坑文本型数据最核心的处理是和Tokenizer配合。中文评论没有天然空格需要先做分词或直接按字符切分。在这个项目里我用的是BERT系列的中文预训练模型它的Tokenizer自带WordPiece机制对中文基本上按字切分所以不需要额外引入结巴分词。关键操作是设置max_length为128超过截断、不足填充然后生成input_ids、attention_mask这两个张量。注意填充和截断要在batch维度上做而不是全局固定同一个长度。先在数据集上统计文本长度分布再选一个能覆盖95%样本的长度作为截断值可以有效减小计算浪费。我写了一个标准的Dataset类把原始文本映射成模型输入同时保留label字段用于后续计算损失。这个类本身不复杂但它决定了数据加载的效率和正确性。from torch.utils.data import Dataset class CommentDataset(Dataset): def __init__(self, texts, labels, tokenizer, max_len128): self.texts texts self.labels labels self.tokenizer tokenizer self.max_len max_len def __len__(self): return len(self.texts) def __getitem__(self, idx): text str(self.texts[idx]) label self.labels[idx] encoded self.tokenizer( text, truncationTrue, paddingmax_length, max_lengthself.max_len, return_tensorspt, ) return { input_ids: encoded[input_ids].squeeze(0), attention_mask: encoded[attention_mask].squeeze(0), label: torch.tensor(label, dtypetorch.long), }4.3 模型微调从零训练不现实站在预训练肩膀上在这个任务上我不会从零初始化BERT然后训练。语料规模才两万条从零训练的结果大概率不如直接用预训练模型微调。我用transformers库加载中文BERT权重替换分类头实现一次端到端微调。所谓微调就是让模型在预训练学到的语言知识基础上用我们的业务数据调整最后一层和部分编码器参数。这里我选择冻结前8层参数只微调后4层和分类头既保持了预训练特征又减少了过拟合风险同时训练速度更快。分类头的设计是dropout - 线性层 - 二分类logits。训练参数上第一个版本先用batch size 32、学习率2e-5、最大轮数3。很多人不理解为什么BERT微调的学习率要这么小因为预训练权重已经在一个很好的局部最优附近学习率过大会直接把学到的特征冲乱。代码里我用AdamW配合线性学习率衰减并设置了随机种子保证实验可复现。from transformers import AutoTokenizer, AutoModelForSequenceClassification from transformers import Trainer, TrainingArguments model_name bert-base-chinese tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForSequenceClassification.from_pretrained( model_name, num_labels2 ) training_args TrainingArguments( output_dir./checkpoints, num_train_epochs3, per_device_train_batch_size32, per_device_eval_batch_size64, learning_rate2e-5, warmup_ratio0.1, evaluation_strategyepoch, save_strategyepoch, logging_dir./logs, seed42, disable_tqdmFalse, ) trainer Trainer( modelmodel, argstraining_args, train_datasettrain_dataset, eval_datasetvalid_dataset, tokenizertokenizer, ) trainer.train()如果你没有GPU或者显存只有4G左右我建议把模型换成bert-base-chinese的蒸馏版distilbert-base-chinese参数量少一半推理速度快很多在情感分类这种相对简单的任务上精度差距很小。另外训练时打开混合精度fp16True显存占用和训练时间都能降下来不少。4.4 离线评估准确率之外还要看错误成本训练完成后我先把测试集上的准确率跑出来大概在0.93上下。但只看准确率会掩盖一个重要问题模型把多少负面评论错判成了正面。这两类错误的业务代价完全不同。对电商平台来说把差评漏掉可能意味着售后风险升级反之把正常评论误判为负面最多是客服多看一眼。所以我同时看混淆矩阵、Precision、Recall、F1。如果业务上更在意“不能漏掉差评”就要拉高Recall代价是会增加一些误伤。这里我引入了一个简单的手段在预测时设置概率阈值不是默认的0.5。比如要求negative的概率大于0.6才判为负面否则归为正面可以在保持整体准确率基本不变的情况下显著降低漏报率。评估代码要沉淀成脚本而不是散落在Notebook里。我在项目里维护了一个evaluate.py输入是模型目录和测试集路径输出是各项指标和按文本长度、评论文本来源分组的细粒度结果。这样每次迭代后我一键就能看到变化不需要重新写评估代码。4.5 封装成服务模型权重和代码分离确认模型效果达标后进入服务化阶段。我习惯先把模型推理逻辑封装成一个纯Python类再交给FastAPI调用这样方便单元测试团队其他成员也容易复用。import torch from transformers import AutoTokenizer, AutoModelForSequenceClassification class SentimentService: def __init__(self, model_dir): self.device torch.device(cuda if torch.cuda.is_available() else cpu) self.tokenizer AutoTokenizer.from_pretrained(model_dir) self.model AutoModelForSequenceClassification.from_pretrained(model_dir).to(self.device) self.model.eval() torch.no_grad() def predict(self, text): encoded self.tokenizer( text, truncationTrue, paddingTrue, max_length128, return_tensorspt ).to(self.device) logits self.model(**encoded).logits prob torch.softmax(logits, dim-1) neg_prob prob[0][0].item() return {positive: 1 - neg_prob, negative: neg_prob}FastAPI接口里我会加入超时控制和批量入口。实际压测下来这个服务在CPU上单条推理大概120毫秒左右用GPU显存小模型不到30毫秒。单机带上8个worker进程和外部队列缓冲扛住每秒几十次的请求没有问题应对中小规模的内部业务已经足够了。服务启动前还要过一遍安全清单接口是否需要鉴权Token输入长度是否限制模型输出是否保留原始文本日志用于后续分析请求量是否做了限流。这些细节决定了一个模型服务能不能真正交给另一个团队使用。5. 让系统活着监控、迭代与长期维护5.1 上线之后模型性能一定会下降很多团队的模型上线后半年不管等业务方反馈“最近推荐效果变差了”才去排查。等到你再训练的时候可能已经损失了不少业务收益。数据漂移和概念漂移是AI系统最隐蔽的威胁数据漂移是输入分布变了比如新用户比例变大、评论风格变得更网络化概念漂移是输入分布没变但“什么是正面的”这个定义变了比如某种黑话成了负面的。我在项目里搭了一个轻量监控方案服务端记录每一次预测的输入特征摘要和输出概率分布批处理脚本每隔一小时统计一次这些指标的变化。重点看两个数字——预测正例比例和平均置信度。今天新上线的模型预测正例比例是52%两周后如果掉到40%先别急着怀疑新模型大概率是线上数据分布变了。5.2 黄金样本集与回归测试随着迭代次数变多你可能会改数据处理逻辑、换模型结构、调超参数。这时候最怕的问题是“改了一版旧的好案例反而变差了”。我的解决办法是维护一个黄金样本集规模不需要大几百条即可但必须覆盖高频场景和历史上出过错的重要案例。每次模型迭代后先在黄金样本集上做回归测试确认核心能力没有退化再进入完整测试集评估。这个做法在业务协作中尤其重要。当你拿着新模型说“整体F1提升了2个百分点”业务方不一定会买账但如果你补充一句“过去半年出过的几类典型投诉案例测试全部通过”信任感完全不同。这种回归测试机制是整个AI工程体系里投入产出比最高的组件之一。5.3 Bad Case驱动的迭代方法模型上线之后怎么继续提升我推荐做bad case驱动迭代。从线上日志里定期抽取模型预测错误且置信度高的样本人工打标归类找出模型犯错的系统性规律。比如“对含emoji的评论判断不准”“对带引号的反讽识别不出来”。每一类bad case都对应一个可行的改进方向加训练数据、扩充词典、增加特征维度、或者在预处理阶段特殊处理。这个流程一周做一次每次挑出三到五类问题定向优化。比起盲目加数据和调参这样更可控也更容易向团队解释“我们为什么做这次改动”。AI工程的迭代从来不靠玄学靠的就是把问题分类、归因、解决的循环。6. 新手必看高频问题的排查实战速查表我从过往的带人经验里整理了下面这些高频问题几乎每个从零开始做AI工程的人都会遇到。症状可能原因排查思路解决建议训练时Loss不降学习率过大/过小、数据标签错乱、模型没有正确进入训练模式先看训练和验证Loss是否同步变化再检查数据样例和标签对应关系固定随机种子小规模数据上先跑10个step确认Loss在下降GPU显存OOMBatch size过大、序列过长、模型过大看报错堆栈定位到具体张量用nvidia-smi观察显存占用调小Batch size启用梯度累积切混合精度缩序列长度推理结果和离线测试不一致训练时有数据增强或Dropout部署时忘了model.eval()逐一对比离线推理和在线推理的输入张量部署前固定推理模式把Tokenizer参数和训练时完全统一线上预测分布突变特征缺失、上游数据格式变更、模型被回滚查看监控面板中特征缺失率和分桶分布用PSI算法定位漂移大的特征检查上游数据血缘GPU利用率低但显存占用高数据加载成为瓶颈或模型太小、通信开销占比高观察训练日志中step间隔测一下数据加载单独耗时增加DataLoader的num_workers用pin_memoryTrue考虑加大Batch size训练速度远慢于预期数据没有打乱、频繁同步、CPU预处理过重用profiler定位耗时热点Transformers库可以开torch.compile或者优化预处理管线这张表没法覆盖所有场景但排查思路是通用的不要盯着模型参数反复调而是先确认数据对不对、环境对不对、复现路径通不通。我见过太多人卡在“模型LibLoss不降”其实是标签文件里多了一行空数据。7. 一些个人体会把ai-engineering-from-scratch这个项目从大纲整理到每个章节的具体案例我最大的体会是AI工程本质上是一种“可交付的确定性”。你写的每一行数据处理代码、每一个评估脚本、每一条监控告警都是在把不确定性慢慢压缩让系统从“运气好能跑”变成“稳定能跑”。如果你现在还在从零开始我建议你挑一个足够小的真实场景把那套闭环亲手跑一遍。不要贪多不要纠结最新模型先用最经典的结构把流程走通。等到你独立完成过一遍“数据到服务”的完整链路再回头看各种论文、框架和工具你会发现它们都变得好理解了很多。工程能力不是看出来的是一轮一轮交付磨出来的。