作为一个带过好几个从零转行 AI 的工程师我太清楚“ai-engineering-from-scratch”这个标题意味着什么了。它不是一门课不是一个框架而是一整套从地基打到屋顶的能力建设过程。很多人以为 AI 工程就是从 HuggingFace 上拉个模型跑个 demo结果真上了生产环境数据、评估、监控、成本每一环都在教你做人。这篇文章就围绕“从零开始做 AI 工程”这件事把我在实际项目中踩过的坑、总结出的路线、以及可以直接抄作业的实操方案完整梳理一遍。适合刚入门的学生、想转行的后端开发、以及已经在做模型但总觉得“差点工程味道”的朋友。1. 内容整体设计与思路拆解1.1 先搞清楚 AI 工程到底是什么AI 工程和“算法工程师”“数据分析师”这几个角色经常被混为一谈但实际干的活差别非常大。算法工程师的核心是模型结构、训练技巧、论文复现数据分析师的核心是统计、报表、业务归因而 AI 工程的核心是把模型变成一个稳定、可维护、可观测、成本可控的生产系统。换句话说AI 工程关心的是模型“上线之后的事”。数据漂移怎么检测推理延迟怎么压显存不够怎么办线上效果和离线指标对不上怎么办这些才是 AI 工程天天要面对的问题。这也是为什么我强烈建议从零开始学 AI 工程的人不要一头扎进“深度学习入门”的教程里。你先要建立一条完整的主线业务问题 → 数据 → 模型 → 评估 → 部署 → 监控。这条主线上的每一个环节都是 AI 工程的组成部分。1.2 为什么“从零开始”这个思路反而是捷径我见过不少有几年后端经验的朋友觉得 AI 工程就是“调 API 部署个服务”于是跳过基础直接上手大模型应用。结果遇到模型输出格式不稳定、上下文窗口爆掉、prompt 稍微改一个词效果就翻天覆地的时候完全不知道从哪里排查。因为他们缺少一个东西对模型行为的基本判断力。从零开始不是说要你把李航的《统计学习方法》从头推导一遍而是要把 AI 系统里最核心的那几个“为什么”弄清楚。比如为什么模型需要做 tokenizer 对齐为什么训练集和测试集要同分布为什么量化后精度下降不一定影响业务指标为什么 RAG 检索的召回率低生成质量一定上不去这些问题看着基础但它们决定了你在生产环境里遇到诡异现象时是两眼一抹黑还是有清晰的排查路径。从零开始搭一个项目就是把这些问题挨个亲手体验一遍这种肌肉记忆是看一百篇教程都换不来的。1.3 这条路线适合谁不适合谁适合的人有三类一是刚毕业想进 AI 应用层的应届生二是想从传统后端转 AI 工程的在职开发三是在校生想提前建立工业级思维的研究型同学。不适合的人也有三类只想速成 prompt 调优的“提示词玩家”对数学完全排斥、遇到公式就跳过的投机者以及指望看视频就能学会工程能力的旁观者。AI 工程是门手艺活不亲手把环境配坏几次、不把显存打爆几次、不把服务搞挂几次你很难真正学会。2. 核心技能栈与工具选型解析2.1 编程基础Python 之外的硬功夫Python 是 AI 工程的主语言这点没什么争议。但我要提醒的是AI 工程里的 Python 和普通后端开发的 Python侧重点差别很大。你不需要背一堆设计模式但必须精通这几件事虚拟环境管理conda、venv、poetry 至少要熟练一种。我见过太多人因为环境依赖混乱浪费时间在“装包报错”上一天能折腾掉半天。调试能力print 大法可以但更要会使用 pdb 和 IDE 的断点调试。模型训练时 loss 变成 nan你得能定位到是哪一层、哪个操作的数值出了问题。性能分析cProfile、memory_profiler 这些工具要会用。推理服务变慢了你得能快速判断瓶颈是在 CPU 数据预处理、GPU 计算还是网络传输。除了 PythonLinux 基础是另一个必须补齐的短板。绝大多数 AI 训练和部署环境都在 Linux 服务器上你不会用 systemd 管理服务、不会看 nvidia-smi、不会写基础的 shell 脚本连部署这关都过不去。2.2 机器学习与深度学习的核心概念从零开始学 AI 工程不需要你把 Transformer 论文的每个公式都默写出来但以下几个概念必须达到“能跟别人讲明白”的程度过拟合与欠拟合这是所有模型问题的根源。训练集 loss 一直降、验证集 loss 反弹这就是过拟合你得知道该加正则、加数据、还是减模型复杂度。样本分布与数据偏差训练数据里某个类别占了 90%模型学出来的就是个“瘸子”。这个理解会直接影响你后面做数据清洗和采样策略。评估指标的选择准确率高不代表模型好。二分类里正样本只占 1%你全预测负样本准确率也有 99%。这时候要看 precision、recall、F1甚至要看 AUC。深度学习方面核心是理解 Transformer 架构的输入输出逻辑。你不用手写 attention但要知道输入 token 序列怎么变成 embedding位置编码是干什么的多层堆叠是在做什么为什么 decoder-only 模型只能从左往右生成。这些东西是后面做微调、做 RAG、做 Agent 的底层认知。2.3 模型理解与选型不是越大的模型越好现在的模型生态已经从“一两家独大”变成了“百花齐放”。开源社区有 Llama、Qwen、Mistral、DeepSeek 等一众选择。选择模型的时候我一般按下面这个思路来考量维度具体问题选型倾向任务复杂度是简单分类还是开放生成简单任务用小模型生成任务考虑 7B 起步硬件预算自有 GPU 还是租用云服务显存不充裕优先考虑量化版或 API 调用延迟要求实时交互还是离线批量实时场景用小模型或蒸馏模型领域适配是否涉及专业术语和特有格式优先选在同类语料上有过预训练的模型我在实际项目中经常遇到一个误区上来就选最大的模型。其实在大多数业务场景里一个 7B 到 14B 的模型配合精心构造的 prompt 和检索增强效果已经足够好而推理成本和延迟能低一个数量级。工程的核心思维是“够用就好”不是“参数越大越厉害”。2.4 工程化工具链从实验到上线的全套配置从零开始做 AI 工程工具链的选择直接影响你的效率。我推荐一套经过验证的组合虽然不是唯一的方案但足够帮你跑通完整流程实验追踪MLflow 或 Weights Biases记录每次训练的指标、参数、代码版本。数据版本管理DVCData Version Control让数据集和代码一样可以回溯。模型注册与仓库MLflow Model Registry 或者直接用 HuggingFace Hub 做模型管理。推理服务FastAPI Uvicorn 是起步标配高并发场景再引入 vLLM 或 TensorRT-LLM 这类推理加速框架。容器化与编排Docker 打包环境Kubernetes 或 Docker Compose 管理服务。早期用 Docker Compose 就够了。监控与告警Prometheus Grafana 抓取系统指标自定义业务指标如平均回复长度、检索命中率也要埋点。这套组合的成本很低但每一样都在解决真实问题实验追踪解决“哪个参数组合效果最好”的记忆问题数据版本管理解决“这个模型当时用的是哪份数据”的追溯问题监控解决“线上效果怎么突然崩了”的发现延迟问题。3. 实操过程与核心环节实现3.1 从零搭建数据管线拿真实数据练手理论说再多不如动手搭一个项目。我建议第一个从零项目不要选那种“黄赌毒”皆可的聊天机器人而是选一个领域边界清晰、数据容易获取的任务比如中文新闻标题分类、电商评论情感分析、或者企业内部的工单自动分派。以新闻标题分类为例数据管线是这么搭的import pandas as pd from sklearn.model_selection import train_test_split df pd.read_csv(news_titles.csv) # 先看一眼类别分布 print(df[category].value_counts()) # 清洗去掉空值、去重、过滤过短文本 df df.dropna(subset[title, category]) df df.drop_duplicates(subset[title]) df df[df[title].str.len() 5] # 类别过少的样本直接去掉避免训练时类别极端不均衡 min_count 100 counts df[category].value_counts() valid_categories counts[counts min_count].index df df[df[category].isin(valid_categories)] train_df, temp_df train_test_split(df, test_size0.3, stratifydf[category]) valid_df, test_df train_test_split(temp_df, test_size0.5, stratifytemp_df[category])这段代码里有几个关键点值得展开讲一下。第一stratify参数一定要加它保证切分后各类别占比和原始数据一致否则类别不均衡会在切分时被进一步放大。第二清洗逻辑里“过滤过短文本”很多人会忽略但实际文本里一堆长度为 2 的乱码和标点留着只会给模型添乱。第三类别少于 100 条的样本直接删掉这看起来有点粗暴但从工程角度样本太少的类别训练出来也是过拟合的不如先砍掉保证主干类别的质量。数据管线的最后一步是构建 tokenizer 和 DataLoader。如果你用的是 HuggingFace 生态代码非常简洁from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(qwen/Qwen2.5-7B) def tokenize_function(examples): return tokenizer( examples[title], paddingmax_length, truncationTrue, max_length64 ) tokenized_dataset train_df.map(tokenize_function, batchedTrue)注意这里的max_length64新闻标题一般就二三十个字给 64 个 token 足够给太长反而浪费计算资源。这个“长度设计”就是工程思维的一部分——先看数据分布再定参数而不是无脑套默认值。3.2 从零训练一个基线模型先别急着微调大模型很多人一上来就想微调大模型但第一个项目我强烈建议先用一个简单的模型把流程跑通。比如用 scikit-learn 的 TF-IDF 逻辑回归或者用一个小的 BERT 类模型做分类。为什么先跑基线两个原因。第一它帮你建立评估基准知道复杂模型到底比简单模型强多少。第二它帮你检验数据管线和评估流程是否正确如果最简单模型的结果都异常好或异常差那大概率是数据泄露或者标签错乱了。TF-IDF 逻辑回归的基线代码from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.pipeline import Pipeline from sklearn.metrics import classification_report pipeline Pipeline([ (tfidf, TfidfVectorizer(max_features50000, ngram_range(1, 2))), (clf, LogisticRegression(max_iter1000, C1.0)) ]) pipeline.fit(train_df[title], train_df[category]) preds pipeline.predict(valid_df[title]) print(classification_report(valid_df[category], preds))一个经验参考在新闻标题分类这类任务上TF-IDF 逻辑回归的 F1 通常能到 0.85 以上Bert 类模型能到 0.92 左右。如果你的基线 F1 连 0.7 都不到先别急着上深度学习回去检查数据。基线模型跑通之后再上预训练模型微调你才会真正体会到“从零到一”的工程感觉数据、评估、训练、保存、加载、推理每一个环节都亲手敲过后面不管换成什么任务都有底气。3.3 微调与优化参数是怎么算出来的当你决定用预训练模型微调时第一个问题是训练参数怎么设。这里我给出一套经过验证的初始值以及背后的计算逻辑。假设你用一张 24GB 显存的 RTX 3090 或 A10微调一个 7B 模型。7B 参数如果全部用 FP16 训练光模型权重就要占 14GB 显存加上梯度、优化器状态AdamW 要保存两倍的动量变量再算上激活值一张 24GB 的卡根本放不下。所以通常选 LoRA 这类参数高效微调方法只训练一小部分注入的低秩矩阵from peft import LoraConfig, get_peft_model lora_config LoraConfig( r8, lora_alpha16, lora_dropout0.05, target_modules[q_proj, k_proj, v_proj, o_proj] ) model AutoModelForCausalLM.from_pretrained(qwen/Qwen2.5-7B, torch_dtypefloat16) model get_peft_model(model, lora_config) model.print_trainable_parameters()r8意味着每个 LoRA 矩阵的秩是 8相比原矩阵压缩了非常多。lora_alpha16是缩放系数实际更新幅度是 alpha / r 2。这组参数是社区里大量验证过的起步值一般不用大改。训练超参的设定逻辑也很清晰。学习率用 2e-4 到 5e-4 之间LoRA 微调比全参数微调可以接受更大的学习率batch size 受显存限制用 gradient_accumulation_steps 凑出等效 batch size序列长度根据任务设分类任务 64 到 128生成任务 512 到 2048。显存不够时的梯度累积设置trainer Trainer( modelmodel, argsTrainingArguments( per_device_train_batch_size4, gradient_accumulation_steps8, # 等效 batch size 4 * 8 32 learning_rate3e-4, num_train_epochs3, fp16True, logging_steps50, eval_strategyepoch, save_strategyepoch, ), train_datasettrain_dataset, eval_datasetvalid_dataset, )等效 batch size 的计算公式是per_device_train_batch_size × gradient_accumulation_steps × 设备数。在显存不足时优先保证等效 batch size 在 16 到 32 之间这样收敛曲线会比较平滑。微调这件事我的经验是先花 70% 的精力把数据质量和格式搞定再花 20% 搞评估集最后 10% 留给调参。反过来做的人基本都在浪费时间。3.4 评估与部署让模型真正跑在业务里模型训练完评估不能只看测试集指标。我强烈建议做三件事第一人工抽样看预测结果。随机抽 100 条验证集人眼扫一遍模型的输出你会发现很多指标解释不了的错误模式比如模型总是把体育类新闻分到娱乐类因为标题里都有明星名字。第二设计“边界测试集”。专门构造一些模棱两可、带引导性的样本比如“XX队夺冠后宣布解散”这种既有体育又有娱乐因素的标题看模型会不会崩。边界测试能暴露模型的真实鲁棒性。第三记录每个版本模型在“硬样本集”上的表现。这个硬样本集是你在迭代中积累的所有让模型翻过车的样本每次迭代都拿它做回归测试。这是工程上最值得投资的资产。部署方面第一个项目用 FastAPI 加简单的批处理就够了from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class PredictRequest(BaseModel): title: str app.post(/predict) def predict(req: PredictRequest): result pipeline.predict([req.title])[0] return {category: result}启动命令也很简单uvicorn main:app --host 0.0.0.0 --port 8000。先用 curl 或 Postman 验证接口再挂到 Docker 里最后用 Docker Compose 把模型服务、前端、监控一起编排起来。这一步走完你就拥有了一个完整的从数据到上线的 AI 工程闭环。4. 常见问题与排查技巧实录4.1 环境与依赖问题从零开始的人第一道坎几乎都是环境。我这里整理几个高频问题的排查思路报错CUDA out of memory先看当前进程占了多少显存用nvidia-smi。然后按顺序排查batch size 是不是太大、序列长度是不是太长、有没有别的大进程占用显存。最傻的情况是自己在同一个 GPU 上同时跑了两个训练任务。报错No module named torch或者版本对不上先检查你激活的是不是正确的虚拟环境再用python -c import torch; print(torch.__version__)确认实际环境里的版本。Zsh 和 Bash 下激活虚拟环境的命令要注意很多人 conda 和 pip 混用导致环境一塌糊涂。报错Killed进程被杀多半是内存溢出了。数据加载时一次性把整个数据集怼进内存遇到大文件很容易被杀。改用datasets库的流式加载或者分批处理。4.2 训练过程中的典型坑训练 loss 不降先检查学习率一个常见的错误是学习率设置得太小模型每步都在原地踏步。学习率设得太大loss 会剧烈震荡甚至变成 nan。如果 loss 变成 nan十有八九是数值不稳定可以先降低学习率、检查是否有 inf 值混入数据、或者在 loss 计算时加 epsilon 这样的防御。还有一个很容易被忽略的坑tokenizer 的 padding 方向。某些老模型要求左边 padding因为生成时它要自动把 padding 遮掉方向错了会导致生成的文本开头全是填充符。这个问题当年坑了我整整一天后来在 HuggingFace 文档里翻到说明才明白。另一个经验微调过程中保存模型的频率别太密。一个 7B 模型每个 checkpoint 就是十几个 GB每 epoch 保存一次够了。磁盘不够用也是我见过的高频事故。4.3 部署与推理性能问题模型部署后性能不达预期排查路径要按层拆分。第一步看网络层是不是响应 body 太大加了不必要的序列化开销。第二步看模型层用torch.cuda.synchronize()统计纯模型推理耗时如果单次推理就要 2 秒那就跟网络无关该考虑量化、剪枝或者换小模型。第三步看并发层并发请求上来后显存占用会线性增长如果服务没有正确的 batching 机制每个请求都独占一份显存那迟早爆。vLLM 这类框架的核心优势就是通过 PagedAttention 和 continuous batching 显著提升吞吐。如果你做的是大模型生成服务上线前直接用 vLLM 而不是裸的 Transformers 代码能省掉后面一半的优化工作。4.4 数据与评估问题离线评估和线上效果对不上这是 AI 工程里最经典的问题。常见的根因有三个一是训练数据跟线上真实数据的分布不一致比如你训练用的是清洗后的规范文本线上进来的却是夹杂乱码的噪音数据二是评估指标选得不对比如分类任务只看了准确率但线上场景更关心误报率三是测试集太小随机波动导致的误差超过了真实效果差异。解决方法是建立“线上回流”机制从线上采样真实请求定期人工标注后混入测试集。虽然听起来繁琐但这是唯一能让离线评估逐渐逼近线上效果的方法。我从零搭建项目时第一个月就把这套回流机制建好了后面所有的迭代决策都建立在可信的评估之上效率高了很多。5. 个人经验与避坑心得5.1 学习节奏用项目倒逼知识我在带新人的时候最推荐的方式是先定一个目标项目然后让需要的知识“自己冒出来”。比如你想做一个智能客服问答系统自然就会遇到检索召回、重排、上下文管理、并发控制这些问题每一个问题都会把你推向对应的工具和理论。这种“以项目为骨架以知识点为血肉”的学习方式比按教材顺序从第一章背到最后一章要高效得多。第一个项目建议控制在三到四周完成不要贪大。三周时间足够完成数据收集、基线模型、微调、简单部署和一轮问题排查。跑完这个闭环你对 AI 工程的认知会超过看半年教程。5.2 建立自己的“调试日志”这个习惯是我最想推荐给所有人的。每次遇到问题把现象、排查思路、最终原因、解决方案记下来。坚持三个月后你会发现自己对很多问题的敏感度大幅提升很多别人折腾一天的问题你看一眼日志就能定位。这个习惯的价值会在你工作几年后越来越明显。调试日志不需要花哨GitHub 上的一个私有仓库、或者本地一个 Markdown 文件就够。关键是“遇到问题就记”这个动作要持续。我在自己的调试日志里光“OOM 问题”就记了十几个不同场景后来每一次都能在五分钟内解决同类型问题。5.3 最后再分享一个小技巧每次训练前先用一个极小的数据子集比如 500 条跑一个只包含两三个 step 的实验确认数据加载、模型前向传播、loss 计算、反向传播、参数更新整个链路是通的。这个小技巧可以帮你避免“训练了两小时才发现数据格式有 bug”的悲剧。我在所有项目里都强制自己执行这一步成本几乎为零收益高到离谱。从零开始做 AI 工程说到底不是因为这条路简单而是因为只有亲手走过每个环节踩过每个坑你才会真正理解模型、数据和系统之间是怎么咬合在一起的。别怕慢把基本功打扎实后面你的成长速度会超出你自己想象。6. 延伸从个人项目走向生产级系统6.1 什么时候可以开始接生产项目做完两到三个从零项目你大概就有能力评估一个生产级 AI 系统的状态了。判断标准很简单你能不能回答清楚下面几个问题线上模型的输入数据格式是怎么定义的有没有校验和兜底逻辑模型服务挂了或者效果变差了你能不能及时发现监控指标是什么如果数据分布变了你有没有机制感知到多久能发现模型需要更新时整个流程要多长时间谁负责触发能回答清楚你的工程闭环就建立起来了。回答不清楚那还不是接手生产系统的时候。6.2 从个人项目到团队协作的关键转变个人项目里所有代码都是你自己的“草稿”生产系统里代码是团队的公共资产。这个转变带来的要求是代码要做模块化配置要跟代码分离模型训练过程要可复现实验记录要可追溯。具体到操作层面就是从第一行代码开始就把项目结构组织清楚。我推荐一个简单的目录结构project/ ├── configs/ # 配置文件包含所有超参数和数据路径 ├── data/ # 原始数据和预处理脚本 ├── src/ │ ├── data/ # 数据加载和清洗逻辑 │ ├── models/ # 模型定义和训练逻辑 │ ├── evaluate/ # 评估逻辑 │ └── serve/ # 推理服务 ├── experiments/ # 实验记录和指标输出 └── tests/ # 单元测试和集成测试这个结构的核心理念是一个人也能按“多人协作”的标准写代码。等真正加入团队的那一天你不需要痛苦的改代码结构只是在现有结构上继续加代码而已。我个人在实际操作中的体会是AI 工程能力的提升从来不体现在你会调多少参数、背多少论文而体现在你面对一个模糊的“把这个模型落地”需求时能快速拆出清晰的任务节点、识别风险点、并一步步把系统搭起来。这个能力只能通过一次次真实的项目打磨出来。如果你正准备从零开始别犹豫先动手搭第一个项目跑通闭环之后你自然会知道下一步该学什么。