我做了几年AI工程，带过不少从算法岗转过来的新人，也接过不少从“写了个notebook”到“上线给业务用”的项目。说实话，标题叫“ai-engineering-from-scratch”的项目，市面上看着多，真正从零把工程闭环跑通的人很少。大家不缺模型，不缺论文，缺的是把散落的数据、代码、环境、评估、部署串成一个可维护系统的能力。
这篇不是教程合集，而是我在多个项目里反复踩过坑之后总结出来的实操路径。不管你是准备转行做AI工程，还是已经在做模型训练想补工程短板，都可以把这篇当作一条主线来参考。我会讲清楚每一步为什么这么做、用什么工具、卡在哪、怎么排查，尽量把那些文档里不写但在现场一定会遇到的问题也一并交代。
1. 项目概述与核心思维转变
1.1 什么算AI工程，什么不算
先说一个很容易被误解的点：AI工程不是“调包跑模型”。跑通一个预训练模型、在测试集上刷个高分，那叫实验，不叫工程。工程意味着可重复、可监控、可回滚、可交接——哪怕你明天请假，同事拿到你的仓库和文档，也能把流程继续推进下去。
这个项目的核心，就是把“从零开始做AI”这件事拆成一条完整链路：业务问题定义、数据获取与清洗、基线实验、特征与模型选型、训练管理、离线评估、模型部署上线、线上监控与迭代。缺了任何一环，短期看着能跑，长期一定出问题。
我见过很多团队死磕模型结构，却在数据校验上翻车；也见过模型效果很好，却因为没做推理优化，上线后被QPS压垮。AI工程要解决的不是某一个惊艳指标，而是整套系统在真实环境里的稳定性、成本和可维护性。“从零开始”并不是说所有东西都自己造轮子，而是说你要具备从一张白纸开始，把系统搭起来、跑通、调优、交付全过程的判断力。
1.2 从零开始的三层基本功：数据、模型、工程化
如果要把这个项目涉及的能力分成三块，我会这样分：
- 数据基本功：知道怎么采集、怎么清洗、怎么标注、怎么切分，更重要的是知道数据分布里藏着什么偏见，脏数据是怎么一步步毁掉模型效果的。
- 模型基本功：不是要求你从零手写Transformer，而是要知道主流模型结构适合什么任务、损失函数和评估指标怎么选、过拟合怎么识别、超参怎么调。
- 工程化基本功：环境怎么管理、代码怎么组织、实验怎么追踪、模型怎么部署、服务怎么监控。这一层是算法工程师最容易忽视、但实际工作里最耗时间的部分。
这三层不是先学完再做事，而是围绕一个具体项目边做边补。九层之台起于累土，但真正让我对“累土”有敬畏感的，不是一次成功，而是同一个模型在换了一台机器、换了一批数据后，结果对不上时的崩溃瞬间。工程化能力，说白了就是减少这种“玄学”时刻的能力。
2. 技术栈搭建与环境准备
2.1 硬件与云资源怎么选
很多初学者一上来就问“要不要买4090”，我反而建议先想清楚两个问题：你跑的是什么规模的任务？你打算训练多久？
如果是文本分类、小规模微调、RAG实验，一张消费级显卡甚至纯CPU都能撑得住；如果要预训练或全量微调百亿级大模型，那就必须考虑多卡集群或云上按需租赁。这里面有个朴素但实用的原则：先把流程跑通，再上规模。
我自己做项目时的选择逻辑是这样：
- 原型验证期：用云上的CPU实例或T4/A10这类入门卡，跑小数据、小模型，验证思路可行。
- 正式训练期：根据显存需求租用A100或H100，按小时计费，跑完就释放，避免闲置成本。
- 推理服务期：优先用支持动态批处理和量化推理的部署方案，必要时用多实例横向扩容，而不是直接上大显存卡。
显存估算有个粗糙但常用的公式：模型显存占用大约是参数量的2倍（FP16下每10亿参数约2GB），再加上激活值、梯度和优化器状态。比如7B模型在FP16下，光权重就要14GB，推理至少需要16GB以上显存，训练则要40GB起步。所以很多人发现7B模型在消费级显卡上推理勉强能跑，训练却爆显存，就是这个原因。
2.2 Python环境与依赖管理
环境管理是“从零开始”最容易踩的第一个坑。Python版本冲突、CUDA版本不对、依赖地狱，几乎每个项目都会遇到。我的建议是直接用conda建独立环境，Python版本锁定，比如3.10或3.11。
conda create -n ai-env python=3.11 -y conda activate ai-env装PyTorch这一步值得单独强调。别用pip默认源，也别一股脑装最新版，先到PyTorch官网按CUDA版本选安装命令。比如CUDA 12.1对应的是这个：
pip install torch==2.1.2 torchvision==0.16.2 --index-url https://download.pytorch.org/whl/cu121装完以后一定要验证CUDA是否真的可用：
python -c "import torch; print(torch.cuda.is_available())"输出True才算装好。我见过不少人装了半小时，最后发现装的是CPU版本，原因就是没看仔细安装界面的标识。依赖管理方面，尽量用requirements.txt锁定版本号，关键包用==精确锁定，不要用>=。机器学习库的版本兼容性极其敏感，今天能跑通的代码，明天升级个依赖就可能给你报出莫名其妙的错误。
2.3 版本控制与实验追踪
Git是每个做AI工程的人都绕不开的基础工具，但很多人只是把代码传上去，数据、模型权重、超参数、实验结果全都散落在本地。这等于把整个项目的可复现性扔掉了。
我在项目里会强制自己做好这几件事：
- 代码全部走Git，分支管理按feature、experiment、release来划分。
- 数据不传Git，用DVC或者简单的文件目录+版本说明管理，至少做到知道每份数据是谁在什么时候生成的。
- 实验参数用配置文件管理，比如YAML或JSON，而不是散落在代码里。
- 用MLflow或WandB记录每次实验的指标、参数、模型产物。
拿MLflow来说，它的设计理念很实用：一次run记录下代码状态、超参、指标和模型文件，后面回看的时候，一行命令就能把历史实验捞出来。我的习惯是每次训练都设置一个实验名，然后把config、日志、指标全打进去：
mlflow.set_experiment("exp1-first-run") with mlflow.start_run(): mlflow.log_params(config) mlflow.log_metrics(metrics) mlflow.pytorch.log_model(model, "model")这个习惯养成之后，你再也不会出现“上周那个91分的结果是用什么参数跑的？我忘了”这种尴尬。
3. 第一个工程化项目设计
3.1 先定义可度量的问题
如果让我给AI工程新人一个最重要的建议，那就是：启动项目之前，用自然语言把“成功长什么样”写出来，然后翻译成可度量的技术指标。
比如你接到一个“提高搜索相关性”的需求。业务侧说的相关，可能很主观；你需要把它拆成：给定一个问题和一个候选文档，模型预测的相关性分数与人工标注的一致程度有多少？用离线指标比如Recall@K、NDCG@K来度量；在线指标则关注搜索点击率、无结果率、用户停留时间。
这一步价值在于：它帮你判断要不要用AI、用哪种AI。很多问题用一条规则、一个检索式就能解决，根本不需要上模型。规则系统完全可控，没有推理延迟，出了问题一眼能定位；模型上限高，但意味着数据、训练、调优、监控整套成本。AI工程师的职责不是尽量用模型，而是选择性价比最优的方案。
一旦指标定下来，就要写进项目文档，作为后续所有实验的对标基准。没有这个基准，后面很容易陷入“感觉这个模型比上个好”的主观判断里。
3.2 数据管道与数据质量
数据管道在项目里承担的角色，就像生产线上的供料系统：原料坏了、断了、混了杂质，后面再好的机器也产出不了合格品。我经手的数据问题里，最常见的不是“没有数据”，而是“数据质量没检查”。
一个标准的数据处理管线至少包含这么几步：
- 采集与抽取：从日志、数据库、API或公开数据源拿数据，注意字段的完整性和合法性。
- 清洗：去重、去空值、处理异常文本、统一格式。
- 标注：如果是监督任务，设计标注规范，计算标注一致性（比如用Cohen's Kappa衡量不同标注者之间的吻合度）。
- 切分：训练集、验证集、测试集要按时间或按用户分层切，防止数据泄露。
这里特别提醒两个坑：
第一，切分数据时不能直接随机打乱再做划分，因为业务数据往往有时间序列特征，或同一个人出现在多个样本里。随机切分会让模型“作弊”，离线指标偏高，上线立刻崩。应该按照时间先后或实体分组切分，确保测试集的分布更接近线上真实场景。
第二，一定要写数据校验脚本。我常用的做法是对每个字段检查取值范围、缺失率、分布变化，连续值看均值和分位数，离散值看类别数列表。别嫌麻烦，等到训练完才发现训练集和线上数据字段对不上，才是最耗时的。
3.3 基线模型与度量
很多人一上来就用大模型，但合格的AI工程师第一件事是先建一个“无脑基线”——比如最简单的逻辑回归、规则匹配、或者直接用现成的预训练零样本模型。基线不是为了追求高分，而是为了校准：后续你做了一堆复杂工作，效果提升到底有多少？如果复杂模型只比基提升高1个点，而这1个点带来的复杂度，可能不值得。
建基线这件事还有个隐藏价值：它帮你验证了数据管道是通的。很多新人第一次跑实验就死在数据读取、特征命名、标签编码这种地方。用最简单的模型把全流程跑通一次，后面换复杂模型时心里才踏实。
评估指标的选择也要贴合业务。分类任务不能只看准确率，尤其是正负样本不平衡时，要看Precision、Recall、F1、AUC；排序任务看NDCG、MRR；生成任务用BLEU、ROUGE，但说到底这些自动指标都只能作为参考，关键时刻还是得人工看样例。我每次实验完都会做一件事：单独抽一批错误样本，打印出来逐条看。这个习惯帮我发现了无数指标看不出来的问题——标签错、数据重复、模型对某种表述系统性误判。
4. 从模型到服务
4.1 训练与评估细节
模型训练环节，工程上的关注点不是“调出最高分”，而是“让训练过程稳定可控”。我自己的训练脚本里，固定包含这么几个组件：
- 固定的随机种子，保证可复现；
- early stopping机制，在验证集指标不再提升时自动停止，避免过拟合也省时间；
- 学习率调度，比如warmup后线性衰减，简单有效；
- 定期保存checkpoint，并且只保留最好的一版；
- 每个epoch结束，打印训练损失、验证损失和关键指标。
很多新手训练时喜欢开着loss曲线盯着看，一有波动就慌。其实训练初期loss波动很大是正常的，真正需要警惕的是：训练loss下降但验证loss一路上升——这是过拟合信号；或者验证集指标在某个epoch后突然崩掉——那往往是数据处理有bug，或学习率跑偏了。
评估环节，除了看整体指标，还要分组看。比如按文本长度、按类别、按数据来源分Group计算指标，能快速定位模型在哪些子集上表现差，比笼统给个平均值有用得多。
4.2 模型导出与推理优化
训练好模型只是开始，上线前通常还要经历“把PyTorch模型转成可高效推理的格式”这一步。以常见场景举例，把PyTorch模型导出为ONNX，再交给ONNX Runtime或TensorRT做推理加速，是工程里常用的做法。
导出这一步的坑我踩过不少。最常见的是动态shape问题：输入尺寸如果不固定，导出时要把dynamic_axes参数设对。还有算子在转换时不兼容，直接报错，这时候要么换实现，要么把某些操作挪到模型外处理。我的建议是：早点做导出验证，不要等全部代码写完了再转，否则排查问题很痛苦。
量化是另一个提速手段。把FP16的权重量化到INT8，在支持量化算子的硬件上，推理速度通常能提升一到两倍，显存占用减半。代价是精度有少量损失，所以要量化就要配合评估集做验证，别只看推理速度的提升。
提示：不是所有模型都适合量化。如果你发现量化后某个关键指标掉得离谱，就回归FP16，优先保证效果，再考虑优化。
推理优化这件事，通用的思路是：先减少计算量（结构简化、量化），再减少IO开销（批处理、缓存），最后才考虑上更多硬件。一上来就加机器，既浪费钱也没解决根本问题。
4.3 API服务框架与负载测试
模型端就绪后，还要把它包装成服务。FastAPI是Python生态里我最常用的框架，轻量、自带异步支持、文档自动生成，几行代码就能起一个推理接口。
一个简单的推理服务长这样：
from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class PredictRequest(BaseModel): text: str @app.post("/predict") def predict(req: PredictRequest): result = model_predict(req.text) return {"prediction": result}这个阶段有几件必须做的事：
第一，把模型加载放到模块级别，不要在每个请求里重新load，否则延迟会高到没法用。
第二，做batch推理。把多个请求攒起来一次性交给模型计算，是提升GPU利用率、降低整体延迟的常用手段，尤其是小模型场景下性能差距非常明显。
第三，做本地压测。至少在部署前用Locust或wrk打一波请求，看看服务在多少QPS下延迟开始暴涨、有没有内存泄漏。否则上了生产环境，流量一上来直接雪崩。
上线以后还要盯监控：请求量、延迟P50/P95/P99、错误率、显存占用、模型效果指标。P95和P99尤其关键——平均值好骗人，长尾延迟才真实影响用户体验。
5. 大模型时代的AI工程实践
5.1 RAG与Agent工程化
现在聊AI工程，绕不开大语言模型应用。最近的所谓ai-engineering热词，很大部分都集中在怎么把大模型接入实际业务，而不是自己从头训练一个大模型。在这个背景下，RAG（检索增强生成）和Agent是两种最主流的范式。
RAG的核心思路很简单：大模型不知道你私有数据里的答案，那就先从你库里检索出相关内容，拼到上下文里，让它基于这些材料回答。它不修改模型权重，只把“知识库”外挂给模型，所以落地快、易更新、可解释。
但RAG工程化之后，很多细节都会影响效果：
- 文档怎么切块？切大了找不准，切小了语义割裂。我最常用的经验是先用标题层级做结构化切块，再配合重叠窗口，保证每个块里有足够的上下文又不至于太长。
- 向量化用哪个模型？中文场景要选中文语义理解强的Embedding模型，不要默认用英文模型跑中文，否则检索质量明显下降。
- 检索结果怎么用？不是简单地把Top-K文档全塞进去，还要做相关性重排，把不相关的块过滤掉，避免上下文污染。
Agent工程化就更复杂了。它让模型自主决定调用哪些工具、按什么顺序执行，这带来了不确定性和安全风险。我的建议是：初期的Agent不要给太多自由，用“流程编排+模型选择分支”的方式，把工具调用范围、执行步骤边界提前写清，关键节点加入人工确认，先保证可用性再谈智能化。
5.2 评估与回归、成本与延迟
大模型落地后，评估和回归变成了头号难题。传统模型可以用带标签的测试集算精确指标，但生成式模型输出千变万化，很难用一套自动指标完全覆盖。我的做法是建立一套“三层评估”体系：
- 自动指标层：对输出做规则检查、相似度计算、结构化字段抽取比对，适合高频低成本的回归筛选。
- 模型评分层：用GPT-4或开源强模型作为裁判，对生成结果打质量分，用关联度、完整度、安全性几个维度做统一评分，覆盖自动规则无法判断的语义质量。
- 人工抽检层：对线上真实流量抽样，让人工评定，作为最终效果的裁判标准。
这套体系不是一次建完就结束，而是要沉淀成回归评测集，每次改prompt、换模型、调参数，都跑一遍，防止“修好一个case，打破十个case”的情况出现。
成本和延迟这两个问题，在大模型场景下必须提前想清楚。推理成本跟token数强相关，所以控制prompt长度、减少无效检索、结果缓存都是省钱的直接手段。延迟方面，流式输出能显著改善用户感知——让第一个token尽快出来，而不是等全部生成完一次性返回。我自己的经验是，大模型应用上线，第一个版本不要求效果好到极致，但延迟和成本一定要求可控。
6. 常见问题与排查技巧实录
6.1 训练中的隐形坑
训练环节的问题，我按出现频率排个序，基本就是这几类：
- 显存不够：报的是CUDA out of memory。处理思路是减小batch size、用梯度累积、做混合精度训练（FP16/BF16）、必要时用模型并行或卸载优化器状态。千万别一爆显存就买新卡，先看代码里有没有把不需要的中间张量留在图上。
- 复现不了：同一份代码跑两次结果不一样。原因一般是没固定随机种子、数据加载用了多线程导致顺序变化、或者GPU上非确定性算法。固定种子后仍然无法完全一致的话，至少保证关键指标在合理范围内波动。
- 训练loss是nan：优先检查学习率是否过大、数据里有没有inf、损失函数有没有出现log(0)之类的操作。我遇到过最蹊跷的一次，是某列特征里有NaN，前向传播出来就直接崩了。
- loss下降但验证集纹丝不动：大概率是特征泄漏的逆问题——训练时用到的信息在验证时被抹掉了，模型学到的是训练集特例。
排查训练问题，我的顺序永远是：先看数据、再看Loss曲线、最后才怀疑模型结构。90%以上所谓“模型问题”，最后都是数据问题。
6.2 部署中的隐形坑
部署环节也有几个高频事故现场：
模型服务启动慢，冷启动时间几十秒。处理方法是启动时预热：先发几个假请求把显存和线程池拉起来，再接入真实流量。否则第一个真实用户会替你完成这个预热过程，然后给你报一个超时。
显存泄漏。模型服务长时间运行，显存占用不断上涨直至崩溃。常见原因是推理框架的显存缓存机制没有正确释放，或者每个请求新建了张量没有清理。排查方式是周期性打印内存占用，找到泄漏窗口再做针对性修复。
并发一高就超时。很多人以为加机器就行，但其实先看有没有用异步、有没有开batch推理、有没有设置合理的超时重试。服务的高延迟往往不是算力不够，而是排队和调度不合理。
6.3 个人学习路线的建议
从零开始做AI工程，最容易走的弯路就是“知识焦虑”——今天看深度学习，明天看分布式，后天看RAG，什么都想学，什么都没学透。我的建议是强行收窄，选一个真实项目，把链路完整走通一遍。哪怕是一个小型文本分类服务，也比看十篇讲解视频有用。
具体的路径，我建议按这个顺序推进：
- 第一步：选一个明确的小任务，比如“把一堆新闻标题自动分类”，用规则方法做一版。
- 第二步：用预训练模型微调，完成训练、评估、导出的全流程。
- 第三步：把模型包装成API服务，本地压测、部署上线。
- 第四步：引入数据版本管理、实验追踪、自动化评估，把项目改造成可维护的系统。
每走一步，都要能回答“为什么这么选”“这个工具解决什么问题”。这样积累出来的能力，才是真正可迁移的工程能力，而不是只会跟着教程敲命令。
注意：这个领域没有“学完”的那一天。工具链、模型结构、部署方式都在快速变化，但工程方法论的内核——定义问题、控制变量、量化评估、灰度验证——是长期不变的。
My journey with this project
这个“ai-engineering-from-scratch”的项目我实际上做过好几轮了。坦白讲，第一轮我完全失败：把大量时间花在尝试各种SOTA模型上，最后做出来的服务没人用，因为业务方根本不关心我用的是哪个模型，只关心这个服务能不能稳定处理他们的数据。第二轮开始，我强迫自己先写清楚问题定义，再搭数据检查脚本，最后才碰模型。那一版反而一个月就上线了。
现在回看，AI工程里最值钱的能力不是模型调优，而是对全链路的把控力——你知道哪个环节会出问题，你知道出了问题去哪查，你知道什么方案在什么条件下才成立。这些东西不靠读论文获得，就靠一遍遍在真实项目里摔打出来。
最后分享一个我一直在用的小技巧：每个项目都准备一个“问题日志”，把踩过的坑、根因、解决办法按时间记录下来。这不仅是自己的弹药库，复盘的素材，也会成为你未来带新人时最宝贵的教材。工程能力说到底，就是能把过去的失败变成未来的确定性。
