这两年“AI工程”这个词越来越热但很多人其实是被吓住的——总觉得要懂分布式系统、要会写CUDA、要能调千亿参数大模型门槛高得离谱。我自己当初也是从“只会调库”的状态一步步走过来踩了不少坑才慢慢摸清楚这条路的真实面貌。所谓ai-engineering-from-scratch说白了就是一套从零开始、不打酱油的系统性学习路径核心不是让你背多少篇论文而是让你动手把一个模型从训练跑到部署真正落在地上。这个项目适合三类人一是刚入门的算法工程师想补工程短板二是后端或全栈开发想往AI方向转三是已经在做AI应用、但对底层原理总感觉心里发虚的人。这篇文章把我自己的完整思路、选型逻辑、实操细节和排查经验都整理出来希望能给正在这条路上摸索的你一个清晰的地图。1. 项目基调为什么“从零”不等于“从理论”很多人听到“from scratch”就以为要把神经网络从零写一遍这其实是个误解。我的理解更务实从零指的是不依赖那些封装过度的平台亲手把一套AI应用的基本链路走通。这种定位有几个现实原因。第一现在市面上的AutoML、低代码平台很多但越是这种工具越容易让你变成“只会点按钮的人”。一旦遇到边界情况比如数据分布变了、模型效果达不到业务要求没有底层认知根本无从下手。第二工程能力的核心是“拆解问题”而这只有通过亲手做、亲手调、亲手debug才能练出来。第三AI工程本身包含的环节非常多——数据准备、模型训练、性能优化、服务部署、监控迭代——每个环节都有大量细节这些东西不亲手碰一遍光看文档是记不住的。所以这个项目的设计原则很简单用最少的外部依赖把最重要的事情亲手做一遍。模型就用开源的小模型比如百亿参数以下框架就用PyTorch部署就用自己的服务器或者便宜的云主机把环节走通比把规模做大重要得多。整个项目我把它拆成五个阶段对应AI工程的核心链路。阶段核心主题关键产出1环境与基础可复现的开发环境2数据工程清洗、增强、管理3模型训练稳定跑通训练流程4模型服务化低延迟高并发API5调优与迭代效果与效率持续改进每阶段都有明确的“能做出来的东西”作为验收标准这是项目能够持续推进的关键。1.1 核心技能地图既然叫AI工程技能树就不能只盯着模型本身。我把需要的能力分成三层。最底层是基础设施能力Linux操作、Docker容器化、Python工程化虚拟环境、类型注解、单元测试、基本网络知识HTTP协议、并发模型。这些看起来很“不AI”但恰恰是工程稳定性的根基。我见过很多算法出身的人代码能跑但工程一塌糊涂——没有版本管理、没有测试、依赖冲突频发这种代码根本走不到生产环境。中间层是模型全链路能力数据处理清洗、采样、增强、模型训练分布式训练基础、超参数调优、评估体系构建离线指标与线上效果的关系、模型部署推理优化、服务框架选型。这一层是AI工程的核心也是这个项目投入时间最多的地方。最上层是系统化思考能力如何在资源有限的情况下做取舍、如何设计数据闭环、如何建立监控体系、如何评估一个模型真实的上线价值。说实话这一层靠上课很难学会必须在真实项目中反复历练。1.2 技术选型的底层逻辑围绕技能地图技术选型上我有几条经过验证的原则。第一深度学习框架选PyTorch而不是TensorFlow。原因很实际PyTorch的调试体验更友好出错信息可读性强整个生态的惯例也是“先出PyTorch版再出其他版”。对于从零开始的人来说这种即时反馈能节省大量学习成本。第二部署方向上优先考虑Triton Inference Server ONNX Runtime而不是图省事用Flask包一层。Flask虽然写起来快但高并发下性能瓶颈明显且缺乏动态批处理、模型版本管理等机制。而Triton虽然是NVIDIA家的产品但对CPU/GPU混合部署、多模型管理、动态批处理这些工程痛点的解决都很成熟值得花时间学。第三数据层面直接上Polars而不是Pandas。Pandas的API虽然熟悉但大规模数据处理的性能和内存占用都不理想。Polars借用Rust底层性能接近Spark但使用成本低得多对单人项目和中小团队非常友好。核心原则不要追新不要追大选那些生态成熟、文档清晰、社区活跃的“常规选项”。2. 环境搭建与数据集准备2.1 可复现开发环境的三件套环境的坑我一共踩了大概三次第一次是本机装了CUDA后系统崩了第二次是conda环境依赖冲突导致整个项目报废第三次是在服务器上配好了环境、结果换了一台机器又抓瞎。后来我固定下来一套“三件套”方案基本没有再出过问题。三件套就是Docker Poetry Makefile。Docker负责把操作系统级依赖锁死。我把CUDA、cuDNN、Python版本、系统库都写进Dockerfile这样不管是在自己的笔记本还是租来的服务器上跑起来的都是同一个环境。Poetry负责锁Python包版本和requirements.txt相比它能区分“直接依赖”和“间接依赖”并且自动生成锁文件。Makefile则是给人类用的入口把一长串命令压缩成make train这样简单明确的指令。Dockerfile的关键写法我分享一个经验基础镜像不要用带完整CUDA的比如nvidia/cuda:12.0-devel那个镜像体积太大反而容易出问题。更好的是先用pytorch/pytorch:2.1.0-cuda12.0-cudnn8-devel作为基础然后在此基础上只追加自己需要的系统库。FROM pytorch/pytorch:2.1.0-cuda12.0-cudnn8-devel # 设置工作目录并创建非root用户 WORKDIR /workspace RUN useradd -m -u 1000 appuser chown -R appuser:appuser /workspace # 系统依赖保持最小化 RUN apt-get update apt-get install -y git curl rm -rf /var/lib/apt/lists/* # 切换用户后续操作不再以root运行 USER appuser # 安装Python依赖管理器 RUN pip install --user poetry1.7.1这里有两个细节值得注意一是创建非root用户很多人在容器里直接以root跑这样权限太宽迟早出事二是每次apt-get后要清理缓存否则镜像体积会越积越大。2.2 数据集构建三板斧数据是AI工程里最容易被低估的环节。很多新手拿到个数据集就急着开训恨不得立刻看到loss下降但这样往往会掉进“模型很准、一上线就废”的大坑。我在项目里固定下来一套流程先探查、再清洗、后增强。探查阶段用Polars做快速统计字段缺失率、分类字段分布、数值字段的min/max/分位数。这个步骤的意义在于如果你连数据长什么样都不知道后面所有决策都可能是空中楼阁。我见过一个真实案例有人在训练集上效果很好结果上线就拉胯最后定位到的问题是训练集和线上数据的字段分布严重不一致——训练集里用户年龄集中在20-30岁线上真实人群却是全年龄段的。import polars as pl df pl.read_csv(data/raw/train.csv) # 快速概览缺失率、唯一值、样本量 total_rows df.height null_stats df.null_count().transpose(include_headerTrue).rename({column: 字段, null_count: 缺失数}) null_stats null_stats.with_columns( ((pl.col(缺失数) / total_rows * 100).round(2)).alias(缺失率(%)) ) print(null_stats)清洗阶段要处理的就是脏数据去重、修正格式、处理缺失值。处理缺失值不要一上来就填均值或众数先搞清楚缺失机制。如果某个字段缺失率超过60%这个字段大概率属于信息泄露很少或者系统采集本身有问题填了反而引入噪声。增强阶段则要根据任务性质来定图像任务做旋转/裁剪/颜色扰动文本任务做同义词替换/回译表格数据则主要做特征工程、构造组合特征。但增强不是越多越好过度增强会把模型训练时间拖长还可能让模型学到不真实的模式。我的习惯是先不加增强训练一个baseline再加增强训练一个对比版本用数据说话看增强是否真的有效。2.3 建议从这里开始一个最小数据集实验第一次尝试时建议你别直接碰那些几十GB的大数据集先用一个小数据集把闭环跑通。我用的例子是Kaggle的IMDb影评情感分类大概几万条文本大小刚好能在普通笔记本上训练。这样环境配置、数据处理、模型训练的整个链路能在半天内完全跑通给你建立信心。先从一个很小的模型跑通流程再逐步放大数据和模型规模是经验最少的试错路径。3. 模型训练的工程化实践3.1 从baseline到训练脚本的演进所有训练都要从baseline开始这个原则我一直坚持它是判断后续所有改进是否有价值的基准线。对分类任务baseline可以是“sentence-transformers embedding 逻辑回归”对序列任务baseline可以是一个只有一两层的LSTM。这些baseline模型的参数量很小跑一个epoch只需要几分钟但足以让你验证数据处理流程、评估代码、保存恢复流程是否都正确。拿情感分类任务举例我用一个预训练的BERT-base模型做baseline。import torch from transformers import AutoTokenizer, AutoModelForSequenceClassification from torch.utils.data import DataLoader, Dataset class TextDataset(Dataset): def __init__(self, texts, labels, tokenizer, max_len256): 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): encoded self.tokenizer( self.texts[idx], truncationTrue, max_lengthself.max_len, paddingmax_length, return_tensorspt, ) return { input_ids: encoded[input_ids].squeeze(0), attention_mask: encoded[attention_mask].squeeze(0), labels: torch.tensor(self.labels[idx], dtypetorch.long), } model_name bert-base-uncased tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForSequenceClassification.from_pretrained(model_name, num_labels2) train_ds TextDataset(train_texts, train_labels, tokenizer) train_loader DataLoader(train_ds, batch_size32, shuffleTrue) optimizer torch.optim.AdamW(model.parameters(), lr2e-5)这里的几个参数值得解释一下max_len我选了256是因为大多数IMDb影评的有效信息都在前100-150个token内更大只会白白增加计算量batch_size取32是我在验证集上比较过16/32/64之后的结果32在这个任务上稳定性和显存占用最平衡学习率2e-5是fine-tuning场景的标准值这个初始值是基于预训练模型的参数空间已经比较平滑太大的学习率容易把参数一下子带偏。3.2 训练流程中的关键机制Logger / Checkpoint / Early Stopping训练脚本不能是“跑完就完”必须有日志记录、断点保存和早停机制。日志记录我用Weights Biases不只是因为它能画曲线关键是它能把每次实验的超参数、代码版本、环境信息、模型结构全都固化下来。这比本地画几个matplotlib图实用得多——三个月后你再回头看能清楚知道当时为什么这么做。如果不想用外部服务完全可以用本地TensorBoard或MLflow只要能解决“记录可回溯”这个核心问题就行。Checkpoint的保存策略要谨慎每轮都存会占太多磁盘只存最后一轮又容易追悔莫及。我的做法是每轮保存一次但是只保留最近三次的权重同时记录一个“历史最优”的权重单独保存——如果验证集指标突破了历史最高值就把这个权重同步到best_model路径。best_f1 0.0 for epoch in range(epochs): model.train() for batch in train_loader: batch {k: v.to(device) for k, v in batch.items()} outputs model(**batch) loss outputs.loss loss.backward() optimizer.step() scheduler.step() optimizer.zero_grad()这里要特别注意optimizer.zero_grad() 的调用位置很多人习惯放在backward之后这没问题但必须保证每个batch都执行。如果忘了清零梯度会在多个batch之间累积导致训练崩坏。早期踩过这个坑现象是loss不稳定、大幅震荡排查了很久才发现是梯度累积的问题。Early stopping也是必要手段设定一个耐心值比如3轮连续3轮验证指标没提升就停止训练防止过拟合且节省时间。3.3 超参数调优的“人力替代方案”超参数调优是AI工程里极容易陷入“手动瞎试”的部分。虽然贝叶斯优化、网格搜索这类方法会让调参更科学高效但很多人还是不自觉地开始手动调——改个学习率跑一轮看一下再改回来。我的建议是除非有充分的先验信息否则别用纯手动调参。至少用Optuna做一次中等规模的搜索。它对算力的消耗可控大约几十次试验就能把主要超参数的合理范围找出来。定义搜索空间的好处是你反而会去思考“哪个超参数对这个任务影响最大”这样的问题这比盲目试更有价值。import optuna def objective(trial): lr trial.suggest_loguniform(lr, 1e-5, 1e-4) batch_size trial.suggest_categorical(batch_size, [16, 32, 64]) warmup_ratio trial.suggest_uniform(warmup_ratio, 0.05, 0.2) # 用这些超参数训练并返回验证集F1 model create_model() trainer Trainer(model, lrlr, batch_sizebatch_size, warmup_ratiowarmup_ratio) val_f1 trainer.train_and_evaluate() return val_f1 study optuna.create_study(directionmaximize) study.optimize(objective, n_trials30)调参过程中有一条经验值得分享很多情况下学习率warmup比例和batch size的关联性比想象中大batch size翻倍的时候学习率一般也应该跟着翻倍或做平方根缩放。这不是绝对真理但确实比“调完batch size、其他一律不动”要有效得多。4. 把模型变成真正的服务4.1 选择推理框架Triton的完整落地方案训练完的模型是“死”的服务的价值在于把它变成“活”的API。这部分的工程深度直接决定项目的完成度。我最终选择的是NVIDIA Triton Inference Server原因很简单它同时解决了并发性能、动态批处理和版本管理三个核心问题。Flask/FastAPI方案我并不是说不行适合原型验证但一旦流量上来Python GIL会卡死并发量。Triton用C实现的核心调度底层性能优势明显而且能直接加载ONNX Protocol Buffers格式的模型不需要改写推理代码。完整的部署分三步。第一步把PyTorch模型导出为ONNX格式。import torch from transformers import AutoModelForSequenceClassification model AutoModelForSequenceClassification.from_pretrained(best_model) model.eval() dummy_input { input_ids: torch.randint(0, 30000, (1, 256)), attention_mask: torch.ones(1, 256, dtypetorch.long), } torch.onnx.export( model, tuple(dummy_input.values()), model.onnx, input_names[input_ids, attention_mask], output_names[logits], dynamic_axes{ input_ids: {0: batch_size}, attention_mask: {0: batch_size}, }, opset_version14, )这里的dynamic_axes配置是重点。我刚开始导出模型时忽略了它导致出来的ONNX模型batch size被固定为1Triton的动态批处理完全派不上用场。指定dynamic_axes之后推理服务才能在不同batch size间自由组批。第二步写Triton的模型配置文件。每个模型在模型仓库下都有一个目录里面是model.onnx和config.pbtxt。model_repository/ └── bert_sentiment/ ├── 1/ │ └── model.onnx └── config.pbtxtname: bert_sentiment platform: onnxruntime_onnx max_batch_size: 64 input [ { name: input_ids data_type: TYPE_INT64 dims: [256] }, { name: attention_mask data_type: TYPE_INT64 dims: [256] } ] output [ { name: logits data_type: TYPE_FP32 dims: [2] } ] dynamic_batching { max_queue_delay_microseconds: 100 }动态批处理的核心参数是max_queue_delay_microseconds意思是当请求到达后最多等100微秒让更多请求凑成一批再一起推理。这个参数既可以把微小的请求碎片合并成较大的batch又不会让用户等待太久。具体值需要根据你的流量特征来测——流量大时这个值可以设大一些流量小时设太大会增加延迟。第三步启动服务客户端调用。docker run --gpus 1 -p 8000:8000 --rm \ -v $(pwd)/model_repository:/models \ nvcr.io/nvidia/tritonserver:23.10-py3 \ tritonserver --model-repository/models客户端用tritonclient发请求import tritonclient.http as httpclient client httpclient.InferenceServerClient(urllocalhost:8000) inputs [ httpclient.InferInput(input_ids, [1, 256], INT64), httpclient.InferInput(attention_mask, [1, 256], INT64), ] inputs[0].set_data_from_numpy(input_ids_np) inputs[1].set_data_from_numpy(attention_mask_np) outputs [httpclient.InferRequestedOutput(logits)] result client.infer(bert_sentiment, inputs, outputsoutputs) logits result.as_numpy(logits)4.2 自建服务架构的流量控制当你的API要把吞吐量做上去光有Triton还不够前面通常还需要一个接入层做鉴权、负载均衡和流量控制。如果不想引入Kubernetes这么重的方案也可以保持在“一台服务器上通过docker-compose编排多个容器”的规模。我常用的方案是三容器架构Nginx处理TLS和限流Python服务层FastAPI做鉴权和预处理Triton负责模型推理。三者通过docker-compose链接单机部署结构简单可靠。version: 3.8 services: gateway: image: nginx:1.24 ports: - 8080:80 volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro depends_on: - api api: build: ./api environment: - TRITON_URLtriton:8001 depends_on: - triton triton: image: nvcr.io/nvidia/tritonserver:23.10-py3 command: [tritonserver, --model-repository/models] volumes: - ./model_repository:/models deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu]Nginx层做限流的配置方法比较简单limit_req_zone $binary_remote_addr zoneapi_limit:10m rate20r/s; server { location /v1/ { limit_req zoneapi_limit burst40 nodelay; proxy_pass http://api:8000; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }rate20r/s表示平均每秒最多20个请求burst40表示允许短时突发。我自己测试下来如果业务方并不需要超低延迟这个参数就能很好地保护后端防止恶意刷量或异常流量把服务打挂。4.3 延迟与吞吐量的真实平衡很多人在做服务优化时只盯着一个指标要么无脑追求低延迟要么只关心高吞吐这其实是误解了系统优化。正确思路是在满足延迟约束的前提下最大化吞吐量。我把自己的实践跑了一遍列出延迟和吞吐量的关系表。实验配置P95延迟吞吐量(QPS)备注单请求模式150ms30每个请求单独推理不组批动态批处理(100us)165ms120batch_size最高冲到8动态批处理(500us)185ms180batch_size最高冲到16动态批处理ONNX优化170ms220开启图优化单请求快15%从表格可以看出纯粹关闭动态批处理虽然延迟最低但吞吐能力只能用惨烈来形容。把等待时间从100us提高到500us延迟只增加了约20ms但吞吐提升了50%。实际生产环境可以根据对延迟的容忍度调整这个值。我在调优时发现Triton模型配置里还有一个可以开启的引擎优化项ONNX Runtime的graph optimization level切到ORT_ENABLE_EXTENDED之后模型推理速度大约能快10%-15%这个白嫖的优化千万别漏了。5. 效果评估、性能诊断与迭代闭环5.1 离线评估和线上反馈的两条线模型上线之后很多人就以为任务结束了其实真正的工程挑战才刚刚开始。要建立一套可信任的反馈机制必须同时跑两条评估线离线评估和线上监控。离线评估的意义在于快速迭代但不能只看准确率/精确率/召回率这几个热闹指标。我至少会追加看分位误差、错误分布象限、混淆矩阵。比如在情感分类里模型在“较长文本带有讽刺意味”的样本上错误率更高这个信息不通过错误结构化分析是看不出来的。线上监控则是确认“离线好的模型上线也好的”唯一证据链。我在架设推理服务时必然会在API侧记录三项指标平均响应延迟、P95延迟、错误率。但更关键的是输出置信度分布的变化——正常业务的置信度分布应该是相对稳定的如果发生肉眼可见的偏移那就要警惕数据分布发生了变化。监控指标预警阈值预警动作P95延迟 200ms持续5分钟增加实例/关闭动态批处理API错误率 1%持续10分钟检查模型服务端日志平均置信度波动超过15%拉取近1小时数据重训练输入特征缺失率 30%检查上游数据链路上面的监控方案不需要特别复杂的平台用Prometheus Grafana搭一套最基础的就可以覆盖这些需求。5.2 性能诊断的经典案例说一个真实遇到过的案例模型用Triton部署后压测发现吞吐量上不去GPU利用率只有30%左右。我当时排查步骤是这样的。第一反应是看模型是否发生了CPU-GPU数据传输瓶颈。如果输入文本的长度很长且模型本身很小推理时间可能还没传输时间多导致整条链路的瓶颈在I/O而非计算。第二步我用nvprof或NVIDIA Nsight Systems跑了一次profiling分析。发现模型在GPU上推理阶段仅占总时长的20%而数据预处理占据了50%其中80%的时间花在了tokenizer的Python循环上。问题定位后我用两种方法解决。一是用了tokenizers库的batch_encode_plus而不是单条encode循环二是把tokenizer的预处理从前端API层挪到客户端执行服务端只接收编码后的input_ids。这样服务端只做张量分发和推理压力立刻小了很多。经过优化吞吐提升了约3倍GPU利用率从30%提到了70%以上。这个案例想说明的是很多AI系统的瓶颈压根不在模型计算而是在数据处理和传输链路。5.3 数据漂移检测与模型再训练机制业务跑起来之后最隐蔽的问题就是数据漂移——线上的数据分布和训练时不一样了。检测方法有很多种从简单的“字段均值突变检测”到“KS检验、PSI稳定性指标”都有。我建议先用量化方法代替肉眼比如对每个特征字段记录其训练集的统计分布均值、分位数、缺失率在线上实时计算当前窗口的统计量与训练集分布做比对超出阈值就告警。from scipy import stats def detect_drift(reference, current, threshold_pvalue0.05): # 用KS检验检测两个样本是否来自同一分布 ks_stat, p_value stats.ks_2samp(reference, current) drifted p_value threshold_pvalue return { ks_stat: ks_stat, p_value: p_value, drifted: drifted, magnitude: ks_stat * (1 threshold_pvalue - p_value) }检测到漂移后传统做法是“重新收集数据、标注、训练、上线”整个周期动不动要好几周。更轻量一些的处理是如果漂移只是局部特征可以先做特征适配或样本加权优先把服务救回来。如果是全局分布变了那就只能走重训练流程了。我自己的经验是永远不要等漂移严重了才做模型更新设置一个定期比如每两周用增量数据做一次微调的计划是成本最低的维护方式。6. 常见问题速查与项目复盘6.1 从零开始的避坑清单有一些问题几乎每个从零到一的项目都会遇到整理成速查表问题现象根因解决方案训练Loss不下降曲线平得像一条线学习率太大或太小先用学习率范围测试锁定合理范围Loss值波浪式震荡曲线像锯齿学习率太高/梯度裁剪未开降低学习率开启梯度裁剪训练集效果巨好验证集很差严重过拟合数据量太少/模型过于复杂添加正则化、数据增强、降低模型容量验证集效果好线上效果差数据分布不一致训练样本采集和线上逻辑不一致做数据分布对比修正采样方式GPU利用率低GPU占用率长期低于40%数据加载是瓶颈开启多进程DataLoader预取数据部署后延迟突增P95无限走高动态批处理参数不当调整max_queue_delay减少batch最大上限说几个我亲身踩过、尤其痛的坑。PyTorch的DataLoader多进程在Windows上会反复启动卡死训练流程Linux上要用ifname main保护代码但很多人只写脚本不注意到这点。另一坑是中文字符编码在读取CSV或JSON时如果忘记指定编码数据直接变成乱码而模型居然还会“学到”乱码的模式——也就是说你甚至可能不会发现数据是错的直到某个指标诡异到不得不查数据。还有浮点精度的坑模型保存和加载时如果用fp32训练但部署时压缩到fp16算子整体会有毫秒级的计算差异个别情况下精度会掉很多。所以启用fp16推理前最好先在离线验证集上跑一遍对比结果。6.2 项目整体复盘这套路径给我带来了什么把这个项目完整做完一遍后我对“AI工程师”这份工作的理解完全变了。以前我的认知是“把模型训出来就是成功”做完整条链路之后才发现那真的只是冰山一角。真正决定系统价值的是数据质量、工程稳定性和迭代机制。学到的最重要的东西是五个字用数据说话。每个改进都依赖实验对比——加不加这个特征、换不换这个优化器、用不用动态批处理——这些都通过对照组数据来决定不靠感觉。AI工程如果有什么“银弹”那就是“可衡量的实验”。另一点体会是工程效率的根在环境隔离和自动化。在这个项目之前我的时间大概有三分之一花在“想不起当时怎么装的包”和“为什么别人的机器上跑不通”上。把Docker和统一命令入口搭好之后这部分浪费时间几乎归零。6.3 内容还能怎么扩展这个框架本身是高度可复用的。面向不同的业务场景只要替换数据和模型整个链路不需要大改。我目前正在做的一个方向是把这套流程迁移到业务数据上针对内部场景做垂直化微调。后续扩展可以考虑的方向有三个第一把单机训练换成多机多卡分布式训练配合DeepSpeed或PyTorch FSDP第二加入自动化的CI/CD流水线每次代码提交后自动跑训练和评估把质量和效率卡在源头第三加上完整的监控告警体系接入已有运维平台让模型服务真正成为基础设施的一部分。对我个人而言这个项目更像是一张地图起点是“只会训练模型”终点是“能独立支撑一个AI系统的完整生命周期”。你现在看到的每一个小节背后都是当时某次手忙脚乱的排错经历。最后送给大家一条我自己的实践原则不要怕慢不要怕错每一步都把它背后的为什么弄明白你的成长速度会远超那些只跑通流程就觉得自己会了的人。这套东西做完你再去看现在的各种“AI应用”就不会只看到热闹而是能看到每一层背后到底在做什么。那感觉挺上头的。
