1. 从零搭建AI工程能力：这个项目到底在解决什么问题
第一次看到 "ai-engineering-from-scratch" 这个标题，我脑子里蹦出来的第一个念头是：终于有人把这件事说明白了。市面上讲AI的教程铺天盖地，但绝大多数要么停留在调包层面——import torch 然后跑个预训练模型，要么直接跳到论文精读，中间那一大段工程化的空白地带几乎没人系统性地讲。而这个项目标题里的 "from-scratch" 恰恰戳中了这个痛点：它要做的不是教你用AI，而是教你从底层把AI工程这件事搭起来。
我自己带过不少刚入行的同学，最常见的困惑就是：模型能跑通，但一上生产就崩。推理延迟高得离谱、显存莫名其妙爆掉、数据管道三天两头挂、部署之后版本对不上……这些问题没有一个能靠调参解决，它们全是工程问题。ai-engineering-from-scratch 这个项目瞄准的就是这块——从最基础的环境搭建、数据处理、模型训练循环、评估体系，到推理优化、服务化部署、监控运维，把AI工程的全链路拆开揉碎讲清楚。
它适合谁？我认为有三类人特别值得花时间研究：第一类是有一定编程基础但没系统做过AI项目的开发者，你可能写过Web后端、写过数据处理脚本，但没完整走过一个AI项目的生命周期；第二类是做了一段时间算法但工程能力偏弱的同学，模型调得不错，但一到部署和优化就抓瞎；第三类是技术负责人或架构师，需要一套可参考的工程规范来指导团队。这个项目不是教你某个框架的API怎么用，而是教你一套思考方式——面对一个AI需求，从零开始该怎么拆、怎么选、怎么搭、怎么验证。
接下来我会按照这个项目的核心逻辑，把AI工程从零搭建的关键环节逐一拆解，包括整体设计思路、核心细节、实操流程和踩坑经验。每一部分我都会给出具体的参数、代码示例和选择理由，尽量做到你读完就能照着动手。
2. 整体设计与思路拆解：为什么这样搭而不是那样搭
2.1 从"能跑"到"能扛"的思维转变
很多人做AI项目的起点是"先把模型跑起来"，这没错，但ai-engineering-from-scratch的核心主张是：你得从第一天就考虑"这个东西怎么扛住真实流量"。这两种思维方式的差异，决定了你后面90%的技术选型。
我举个具体的例子。假设你要做一个文本分类服务。调包思维的做法是：加载预训练模型，写个predict函数，用Flask包一层，完事。但工程思维会问一连串问题：模型加载是一次性的还是每次请求都加载？如果是常驻内存，显存占用多少，GPU够不够？请求量上来之后是排队还是批处理？批处理的延迟上限是多少？模型更新时怎么做到不中断服务？这些问题在调包思维里根本不会出现，但在生产环境里每一个都能让你半夜被叫起来修故障。
这个项目的设计思路就是把这些工程问题前置。它在每个环节都会先问"这个组件在生产环境下的约束是什么"，然后再决定用什么方案。比如数据处理环节，它不会只教你用pandas读CSV，而是会讨论：数据量大了之后pandas内存扛不住怎么办？流式处理怎么设计？数据版本怎么管理？这些才是AI工程真正难的地方。
2.2 技术栈选型的底层逻辑
ai-engineering-from-scratch在技术栈选择上有一个很明确的原则：优先选生态成熟、社区活跃、文档完善的工具，而不是追求最新最酷的。这个原则背后是血泪教训——我见过太多项目因为选了一个star数很少的框架，结果遇到bug没人修，文档缺失只能读源码，最后整个项目被拖垮。
具体来说，Python生态里做AI工程，核心依赖基本就是这几个：PyTorch或TensorFlow做模型训练和推理，FastAPI或Triton做服务化，Redis或RabbitMQ做任务队列，PostgreSQL或MinIO做数据存储，Prometheus加Grafana做监控。这套组合不是唯一解，但它是经过大量生产验证的稳妥选择。
为什么推荐FastAPI而不是Flask？因为AI服务的请求往往涉及大量异步IO——等模型推理、等数据库查询、等缓存返回。FastAPI原生支持async/await，在高并发场景下吞吐量比Flask高出一个量级。而且它的Pydantic模型校验能帮你在入口就把非法请求挡掉，减少无效计算。
为什么推理服务推荐Triton而不是自己写？因为Triton内置了动态批处理、模型版本管理、多框架支持这些生产级功能。你自己用FastAPI写一个推理服务，光动态批处理这一块就得写几百行代码，还得处理各种边界情况。Triton把这些都做好了，你只需要配置一下就行。
2.3 分层架构的设计考量
这个项目在架构上采用了清晰的分层设计，我把它总结为四层：数据层、训练层、推理层、服务层。每一层的职责边界很明确，层与层之间通过定义良好的接口通信。
数据层负责原始数据的采集、清洗、标注、版本管理。这一层的核心挑战是数据质量和可复现性。你训练了一个效果很好的模型，三个月后想复现，结果发现数据已经变了，这就很尴尬。所以数据版本管理是必须的，可以用DVC或者自己基于对象存储做一套。
训练层负责模型定义、训练循环、超参调优、实验追踪。这一层的关键是实验管理——你跑了50组实验，哪组用了什么参数、什么数据、什么代码版本，必须能追溯。MLflow或Weights & Biases这类工具就是干这个的。
推理层负责模型加载、批处理、加速优化。这一层要解决的是延迟和吞吐的平衡。动态批处理是常用手段：把短时间内到达的多个请求合并成一个batch一起推理，能显著提升GPU利用率。但batch不能无限等，得设一个超时上限，否则单个请求的延迟会不可接受。
服务层负责API暴露、鉴权、限流、监控。这一层是离用户最近的，也是最容易出问题的。限流没做好，一个爬虫就能把你的服务打挂；监控没做好，出了问题你都不知道是哪里慢。
这种分层的好处是每层可以独立演进。比如你想换一个更快的推理引擎，只需要改推理层，数据层和训练层不受影响。想加一个新的API端点，只需要改服务层。这种解耦在项目规模变大之后价值会越来越明显。
3. 核心细节解析与实操要点：每个环节的关键决策
3.1 环境搭建：别小看这一步
环境搭建听起来简单，但它是AI工程里最容易埋雷的地方。我见过太多项目因为环境不一致导致"在我机器上能跑"的经典问题。ai-engineering-from-scratch在这块的做法是：一切容器化，一切版本锁定。
具体操作上，基础镜像选择很关键。不要用最新的CUDA镜像，用比你驱动版本低一到两个小版本的稳定版。比如你的GPU驱动支持CUDA 12.4，那就用12.1或12.2的镜像，留出兼容余量。Python版本建议锁定在3.10或3.11，这两个版本在AI生态里兼容性最好，3.12虽然新但有些库还没跟上。
依赖管理用pip-tools或者poetry，不要直接用pip install。原因是pip install不锁定间接依赖，今天装和明天装可能装出不同的版本组合。用pip-compile生成requirements.txt，把所有直接和间接依赖的版本都钉死。这样任何人任何时候重建环境，得到的都是一模一样的依赖树。
注意：CUDA版本、PyTorch版本、Python版本这三者之间有严格的兼容矩阵。装之前一定去PyTorch官网查兼容表，不要凭感觉装。我踩过这个坑，装完之后torch.cuda.is_available()返回False，排查了半天才发现是版本不匹配。
还有一个细节是随机种子的设置。AI项目里涉及大量随机操作——数据打乱、权重初始化、dropout。如果不设种子，每次跑的结果都不一样，你根本没法判断模型效果的波动是来自改动还是来自随机性。标准做法是在训练脚本开头设置Python、NumPy、PyTorch三个层面的种子，并且开启cuDNN的确定性模式。
import random import numpy as np import torch def set_seed(seed=42): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) torch.backends.cudnn.deterministic = True torch.backends.cudnn.benchmark = False注意cudnn.benchmark设为False会牺牲一点性能，但换来的是结果可复现。在实验阶段这个取舍是值得的，等最终确定方案要上生产了再打开benchmark优化速度。
3.2 数据处理管道：AI工程的隐形地基
数据处理是AI工程里最不起眼但最重要的环节。模型效果不好，80%的情况是数据问题，不是模型问题。ai-engineering-from-scratch在数据处理这块强调三个原则：可复现、可扩展、可监控。
可复现意味着你随时能从原始数据重新生成训练集。这要求你把每一步处理逻辑都代码化，不能有手动操作。比如你用Excel手动改了几行数据，这个操作就没法复现。正确做法是写一个清洗脚本，把清洗规则明确编码进去。
可扩展意味着数据量增长时管道不会崩。pandas在数据量超过内存时就会挂，所以生产级管道要用流式处理或者分片处理。PyTorch的Dataset和DataLoader天然支持流式加载，你只需要实现__getitem__和__len__方法，DataLoader会自动处理批处理、打乱、多进程加载。
from torch.utils.data import Dataset, DataLoader class TextDataset(Dataset): def __init__(self, file_path, tokenizer, max_len=512): self.data = [] with open(file_path, 'r', encoding='utf-8') as f: for line in f: self.data.append(line.strip()) self.tokenizer = tokenizer self.max_len = max_len def __len__(self): return len(self.data) def __getitem__(self, idx): text = self.data[idx] encoding = self.tokenizer( text, max_length=self.max_len, padding='max_length', truncation=True, return_tensors='pt' ) return { 'input_ids': encoding['input_ids'].squeeze(), 'attention_mask': encoding['attention_mask'].squeeze() } dataset = TextDataset('train.txt', tokenizer) dataloader = DataLoader(dataset, batch_size=32, shuffle=True, num_workers=4)num_workers设为4意味着用4个子进程并行加载数据。这个值不是越大越好，一般设为CPU核心数的70%左右。设太大反而会因为进程切换开销导致变慢。
可监控意味着你要知道数据管道每个环节的输入输出。比如清洗掉了多少条数据、截断了多少条、类别分布是什么样。这些指标要记录下来，方便排查问题。我建议在每个处理步骤后都输出统计信息，并且保存一份处理后的数据快照。
实操心得：数据清洗规则一定要写成配置，不要硬编码在代码里。比如"去掉长度小于10的文本"这个规则，应该是一个可配置的参数。因为不同任务对数据的要求不一样，硬编码会导致换个任务就得改代码。
3.3 训练循环：不只是forward和backward
训练循环是AI工程的核心，但很多人对它的理解停留在"前向传播、计算损失、反向传播、更新参数"这个层面。生产级的训练循环要考虑的东西多得多。
首先是梯度累积。当显存不够放下大batch时，可以用小batch多次前向，累积梯度后再更新参数。这样等效于大batch训练，但显存占用小。实现上就是在loss.backward()之后不立即optimizer.step()，而是等累积够步数再step。
accumulation_steps = 4 optimizer.zero_grad() for i, batch in enumerate(dataloader): outputs = model(**batch) loss = outputs.loss / accumulation_steps loss.backward() if (i + 1) % accumulation_steps == 0: optimizer.step() optimizer.zero_grad()注意loss要除以accumulation_steps，否则梯度会放大accumulation_steps倍。
其次是混合精度训练。用float16或bfloat16代替float32，能显著减少显存占用和加速计算。PyTorch的amp模块让这件事变得很简单：
from torch.cuda.amp import autocast, GradScaler scaler = GradScaler() for batch in dataloader: optimizer.zero_grad() with autocast(): outputs = model(**batch) loss = outputs.loss scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()GradScaler的作用是防止float16下梯度下溢。它会自动缩放loss，让梯度保持在float16能表示的范围内，更新完参数后再缩回来。
第三是检查点保存。不要只保存最终模型，要保存最佳模型和最近几个检查点。训练可能跑几天，中间挂了能从检查点恢复。保存时除了模型权重，还要保存优化器状态、学习率调度器状态、当前epoch和step。这样恢复后才能完全接着训练。
注意：保存检查点时用torch.save(model.state_dict())而不是torch.save(model)。前者只保存参数，文件小且加载灵活；后者保存整个模型对象，依赖具体的类定义，换个环境可能加载失败。
3.4 评估体系：别被准确率骗了
评估体系是AI工程里最容易被忽视的环节。很多人训练完看一眼准确率就完事了，但准确率在很多场景下是有欺骗性的。比如一个二分类任务，正负样本比例是1:99，模型全部预测为负，准确率也有99%，但这个模型毫无价值。
ai-engineering-from-scratch强调评估要分层次：离线评估、在线评估、业务评估。离线评估用held-out测试集，看precision、recall、F1、AUC这些指标。在线评估用A/B测试，看真实用户的行为变化。业务评估看最终的业务指标，比如点击率、转化率、留存率。
离线评估里，混淆矩阵是最直观的工具。它能告诉你模型在哪些类别上容易混淆。比如一个情感分类模型，把"中性"误判为"正面"的比例很高，那你就知道需要补充中性样本或者调整分类阈值。
from sklearn.metrics import classification_report, confusion_matrix y_pred = model.predict(X_test) print(classification_report(y_test, y_pred)) print(confusion_matrix(y_test, y_pred))分类报告会给出每个类别的precision、recall、F1和support。support是测试集中该类别的样本数，样本太少的类别指标不可信，需要谨慎解读。
实操心得：评估集一定要和训练集严格分离，而且评估集的分布要尽量接近真实场景。我见过一个项目，训练集和测试集是从同一个数据源随机划分的，结果模型在测试集上F1有0.95，上线后实际效果只有0.7。原因是真实场景的数据分布和训练数据差异很大，模型过拟合了训练数据的分布。
4. 实操过程与核心环节实现：从零到一的完整流程
4.1 项目初始化与目录结构
拿到一个AI工程项目，第一步是搭目录结构。好的目录结构能让协作效率翻倍，烂的目录结构会让项目变成一锅粥。我推荐的结构是这样的：
project/ ├── configs/ # 配置文件 │ ├── train.yaml │ └── inference.yaml ├── data/ # 数据目录（不纳入版本控制） │ ├── raw/ │ ├── processed/ │ └── interim/ ├── src/ # 源代码 │ ├── data/ # 数据处理 │ ├── models/ # 模型定义 │ ├── training/ # 训练逻辑 │ ├── inference/ # 推理逻辑 │ └── utils/ # 工具函数 ├── scripts/ # 可执行脚本 │ ├── train.sh │ └── serve.sh ├── tests/ # 测试代码 ├── notebooks/ # 探索性分析 ├── requirements.txt └── README.mdconfigs目录放配置文件，用YAML格式。为什么不用Python文件做配置？因为YAML可以被非程序员修改，而且更容易做版本对比。训练配置里应该包含数据路径、模型参数、训练超参、输出路径这些信息。
data目录分raw、processed、interim三层。raw是原始数据，只读不改。processed是清洗后可直接用于训练的数据。interim是中间处理结果，方便调试。这个分层的好处是任何一步出问题都能回溯。
src目录按功能模块划分。data放Dataset类和数据处理函数，models放模型定义，training放训练循环和评估逻辑，inference放推理相关代码，utils放通用工具。每个模块都应该有清晰的接口，模块之间通过接口调用，不要互相渗透。
4.2 配置管理与实验追踪
配置管理是AI工程里容易被低估的环节。我见过太多项目把超参硬编码在代码里，改一个学习率要翻遍整个文件。正确做法是把所有可配置项抽到配置文件里，代码只读配置。
# configs/train.yaml data: train_path: "data/processed/train.jsonl" val_path: "data/processed/val.jsonl" max_len: 512 batch_size: 32 model: name: "bert-base-chinese" num_labels: 5 dropout: 0.1 training: epochs: 10 learning_rate: 2e-5 warmup_ratio: 0.1 weight_decay: 0.01 gradient_accumulation_steps: 4 fp16: true output: dir: "outputs/exp_001" save_steps: 500 eval_steps: 500实验追踪用MLflow或者Weights & Biases。每次训练自动记录超参、指标曲线、模型文件。这样你跑了50组实验后，能快速找到效果最好的那组，并且知道它用了什么配置。
import mlflow mlflow.set_experiment("text-classification") with mlflow.start_run(): mlflow.log_params(config['training']) for epoch in range(epochs): train_loss = train_one_epoch() val_metrics = evaluate() mlflow.log_metrics({ 'train_loss': train_loss, 'val_f1': val_metrics['f1'], 'val_accuracy': val_metrics['accuracy'] }, step=epoch) mlflow.pytorch.log_model(model, "model")4.3 推理服务化：从模型到API
训练好的模型要变成可调用的服务，中间隔着工程化的鸿沟。ai-engineering-from-scratch推荐的方案是用FastAPI做API层，用Triton或TorchServe做推理层。如果规模不大，也可以直接用FastAPI加载模型做推理，省去Triton的部署复杂度。
from fastapi import FastAPI, HTTPException from pydantic import BaseModel import torch app = FastAPI() class PredictRequest(BaseModel): text: str max_length: int = 512 class PredictResponse(BaseModel): label: str confidence: float model = None tokenizer = None @app.on_event("startup") def load_model(): global model, tokenizer model = torch.load("outputs/best_model.pt", map_location="cuda") model.eval() tokenizer = AutoTokenizer.from_pretrained("bert-base-chinese") @app.post("/predict", response_model=PredictResponse) async def predict(request: PredictRequest): if not request.text.strip(): raise HTTPException(status_code=400, detail="text cannot be empty") inputs = tokenizer( request.text, max_length=request.max_length, padding='max_length', truncation=True, return_tensors='pt' ).to('cuda') with torch.no_grad(): outputs = model(**inputs) probs = torch.softmax(outputs.logits, dim=-1) confidence, pred = torch.max(probs, dim=-1) return PredictResponse( label=id2label[pred.item()], confidence=confidence.item() )这个服务有几个关键点：模型在startup时加载一次，常驻显存；推理时用torch.no_grad()关闭梯度计算，节省显存和计算；输入做了非空校验，避免无效计算。
启动命令用uvicorn，workers数设为GPU数量。如果是单GPU，workers设为1，因为多个worker会争抢同一块GPU，反而降低效率。
uvicorn src.inference.server:app --host 0.0.0.0 --port 8000 --workers 14.4 监控与告警：上线只是开始
服务上线不是终点，而是起点。没有监控的服务就像没有仪表盘的飞机，你不知道它什么时候会掉下来。AI服务的监控要关注几个层面：系统层、服务层、模型层。
系统层监控GPU利用率、显存占用、CPU、内存、网络IO。这些用Prometheus的node_exporter和nvidia_gpu_exporter采集，Grafana展示。GPU利用率长期低于30%说明资源浪费，长期高于90%说明可能成为瓶颈。
服务层监控QPS、延迟分布、错误率。延迟要关注P50、P95、P99，不能只看平均值。平均值会被大量快请求拉低，掩盖慢请求的问题。P99延迟如果超过业务容忍上限，就需要优化。
模型层监控输入分布、输出分布、置信度分布。如果输入分布发生漂移，比如突然来了很多训练时没见过的文本类型，模型效果会下降。输出分布的变化也能反映问题，比如某个类别的预测比例突然飙升，可能是模型退化或者数据问题。
from prometheus_client import Histogram, Counter REQUEST_LATENCY = Histogram( 'model_request_latency_seconds', 'Model request latency', buckets=[0.01, 0.05, 0.1, 0.5, 1.0, 2.0] ) REQUEST_COUNT = Counter( 'model_request_total', 'Total model requests', ['status'] ) @app.post("/predict") async def predict(request: PredictRequest): start = time.time() try: result = do_predict(request) REQUEST_COUNT.labels(status='success').inc() return result except Exception as e: REQUEST_COUNT.labels(status='error').inc() raise finally: REQUEST_LATENCY.observe(time.time() - start)注意：监控指标不要设太多，否则采集和存储成本会很高。核心指标控制在20个以内，每个指标都要有明确的告警阈值和处置预案。没有处置预案的告警就是噪音，时间长了大家就会忽略。
5. 常见问题与排查技巧实录：踩过的坑才是真经验
5.1 显存溢出：最常见也最头疼
显存溢出（OOM）是AI工程里出现频率最高的问题。表现是训练或推理时突然报CUDA out of memory。排查思路是从小到大逐层排查。
先看batch size是不是太大。这是最常见的原因。解决办法是减小batch size，如果减小后效果下降，用梯度累积补偿。梯度累积的步数等于原来batch size除以新batch size。
再看是不是有内存泄漏。PyTorch里常见的内存泄漏是保留了计算图。比如你把loss存到一个列表里，loss还带着计算图，显存就不会释放。正确做法是存loss.item()，只存数值不存图。
# 错误做法：loss带着计算图，显存持续增长 losses = [] for batch in dataloader: loss = model(batch) losses.append(loss) # 泄漏！ # 正确做法：只存数值 losses = [] for batch in dataloader: loss = model(batch) losses.append(loss.item()) # 安全还有一个容易忽略的点是验证阶段没关梯度。验证时如果忘了torch.no_grad()，会构建计算图，显存占用和训练时一样。验证阶段一定要包在no_grad里。
如果以上都排查了还是OOM，可以用torch.cuda.memory_summary()看显存分配详情，找出是哪部分占了大头。
5.2 训练不收敛：原因可能出乎意料
训练不收敛的表现是loss不下降或者震荡。排查顺序是：学习率、数据、模型、初始化。
学习率是最常见的元凶。太大导致震荡，太小导致下降缓慢。建议用学习率扫描，从1e-5到1e-3对数均匀取几个值，各跑几百步看loss曲线。找到下降最快的量级后再细调。
数据问题也很常见。标签错误、数据泄漏、预处理不一致都会导致不收敛。我遇到过一个案例，训练集和验证集的预处理方式不一样，训练集做了归一化验证集没做，结果训练loss正常下降但验证loss一直很高。排查了半天才发现是预处理的问题。
模型问题包括梯度消失和梯度爆炸。梯度消失表现为浅层参数几乎不更新，梯度爆炸表现为loss突然变成NaN。梯度消失可以用残差连接、BatchNorm、换激活函数缓解。梯度爆炸用梯度裁剪，把梯度范数限制在一个阈值内。
torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0)初始化问题在新模型上比较常见。如果模型是自己搭的，初始化方式不对可能导致训练困难。PyTorch默认用Kaiming初始化，大多数情况够用。如果不行可以试试Xavier初始化或者更小的初始方差。
5.3 推理延迟高：优化要抓主要矛盾
推理延迟高的问题，优化前先定位瓶颈。用profiler工具看时间花在哪里。是数据预处理慢、模型前向慢、还是后处理慢。
数据预处理慢的话，把tokenizer换成fast版本，或者把预处理放到GPU上做。模型前向慢的话，考虑量化、剪枝、蒸馏，或者换更小的模型。后处理慢的话，检查是不是有Python循环，能向量化的向量化。
动态批处理是提升吞吐的利器，但会牺牲单请求延迟。原理是把短时间内到达的多个请求合并成一个batch一起推理。batch越大GPU利用率越高，但等待凑batch的时间也越长。需要根据业务对延迟的容忍度来设batch大小和等待超时。
import asyncio from collections import deque class DynamicBatcher: def __init__(self, max_batch_size=32, max_wait_ms=50): self.max_batch_size = max_batch_size self.max_wait_ms = max_wait_ms self.queue = deque() self.lock = asyncio.Lock() async def add_request(self, request): async with self.lock: self.queue.append(request) if len(self.queue) >= self.max_batch_size: return await self._process_batch() await asyncio.sleep(self.max_wait_ms / 1000) async with self.lock: if request in self.queue: return await self._process_batch()这个简化版的动态批处理器展示了核心思路：请求先入队，队列满或者等待超时就触发批处理。实际生产里还要处理超时、错误传播、结果分发这些细节。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| CUDA OOM | batch太大、内存泄漏、验证未关梯度 | memory_summary查看分配 | 减小batch、修泄漏、加no_grad |
| loss不下降 | 学习率不当、数据问题、梯度消失 | 学习率扫描、检查数据 | 调学习率、修数据、加残差 |
| loss变NaN | 梯度爆炸、学习率太大 | 打印梯度范数 | 梯度裁剪、降学习率 |
| 推理延迟高 | 预处理慢、模型大、无批处理 | profiler定位 | 优化预处理、量化、动态批处理 |
| 服务不稳定 | 内存泄漏、连接池耗尽、限流缺失 | 监控内存和连接数 | 修泄漏、调连接池、加限流 |
| 效果不达预期 | 数据分布不匹配、过拟合、评估集问题 | 对比训练和线上分布 | 补数据、正则化、重建评估集 |
实操心得：排查问题时一定要先复现，再定位，最后修复。不要看到报错就瞎改，改了一堆地方问题还在，反而引入了新问题。复现的意思是找到一个稳定的、最小化的触发条件。比如OOM，要找到是哪个batch size、哪个输入长度下必现。有了稳定复现，定位就是二分法的事。
6. 工程化落地的几个关键取舍
6.1 自研还是用现成方案
AI工程里经常面临自研还是用现成的选择。我的原则是：核心业务逻辑自研，通用基础设施用现成。什么是核心业务逻辑？你的模型结构、你的特征工程、你的业务规则，这些是竞争力所在，值得投入自研。什么是通用基础设施？模型服务框架、任务队列、监控系统，这些有成熟方案，自研成本高收益低。
举个例子，推理服务用Triton还是自己写FastAPI？如果你的需求就是标准的模型推理，Triton开箱即用，动态批处理、模型版本管理都内置了，没必要自己造轮子。但如果你有特殊的预处理逻辑、特殊的后处理逻辑，那可以在Triton的基础上写自定义的backend，而不是完全自己写一个服务框架。
6.2 延迟和吞吐的平衡
延迟和吞吐是一对矛盾。追求低延迟就要牺牲吞吐，追求高吞吐就要容忍延迟。怎么平衡取决于业务场景。在线交互式服务对延迟敏感，P99延迟要控制在几百毫秒内，那就不能等太长的batch。离线批处理对吞吐敏感，延迟几小时都无所谓，那就把batch开到最大。
一个实用的做法是分级服务。对延迟敏感的请求走小batch快速通道，对延迟不敏感的请求走大batch慢速通道。这样既能保证核心用户体验，又能充分利用GPU资源。
6.3 模型更新策略
模型更新是AI服务特有的问题。传统软件更新是替换代码，AI服务更新是替换模型权重。更新策略有几种：全量替换、灰度发布、A/B测试。
全量替换最简单，但风险最大。新模型有问题的话所有用户都受影响。灰度发布是先让一小部分流量走新模型，观察一段时间没问题再扩大比例。A/B测试是同时跑新旧模型，对比业务指标，用数据决定是否切换。
我推荐至少做到灰度发布。实现上可以在服务层根据用户ID哈希分流，比如哈希值模100小于5的走新模型，其余走旧模型。观察24小时，如果新模型的错误率和延迟都正常，再逐步扩大比例。
def select_model(user_id): bucket = hash(user_id) % 100 if bucket < rollout_percentage: return new_model return old_modelrollout_percentage从5开始，每天翻倍，一周内完成全量。如果中途发现异常，立即把rollout_percentage设回0，回滚到旧模型。
6.4 技术债务的管理
AI项目特别容易积累技术债务。实验阶段的临时代码、硬编码的参数、没写的测试、没整理的notebook，这些东西在项目初期看起来无所谓，但项目变大之后会严重拖慢迭代速度。
我的建议是每个迭代周期留出20%的时间还技术债。把临时代码整理成模块，把硬编码参数抽到配置，给核心逻辑补测试，把有用的notebook整理成文档。这些工作短期看不到收益，但长期能让项目保持健康。
注意：不要试图一次性还清所有技术债，那会导致项目停滞。小步快跑，每次还一点，持续进行。就像健身一样，每天练半小时比一个月练一次十小时效果好得多。
7. 我个人的一些实操体会
做AI工程这些年，最大的体会是：工程能力比算法能力更稀缺。算法可以学，论文可以读，但工程能力是靠一个个项目喂出来的。你踩过的坑、修过的bug、熬过的夜，最后都会变成你的工程直觉。
ai-engineering-from-scratch这个项目最大的价值，是它把AI工程的全貌展示出来了。很多人做AI只盯着模型那一块，但模型只是冰山一角。水面下还有数据处理、训练框架、推理优化、服务部署、监控运维这一大堆东西。这些东西不性感，但缺了任何一个，模型都落不了地。
如果你刚开始做AI工程，我的建议是从小项目做起，但要用工程化的方式做。哪怕是一个简单的文本分类，也把配置管理、实验追踪、单元测试、监控告警这些加上。一开始会慢，但养成习惯之后，你会发现后面的大项目反而更快，因为该踩的坑在小项目里都踩过了。
最后分享一个我常用的调试技巧：遇到诡异问题时，先怀疑数据，再怀疑代码，最后怀疑框架。数据问题的概率远高于代码问题，代码问题的概率远高于框架问题。我见过太多人一上来就怀疑PyTorch有bug，查了半天发现是自己数据加载的时候把标签搞错了。从概率最高的地方开始排查，能省很多时间。
