处理AI项目这几年我最常被问的一句话就是“别人家的AI工程是怎么搭起来的”说实话网上的教程大多教你调参、跑通一个demo但真正从零把一个AI项目做成能上线、能维护、能迭代的工程体系中间隔着大量没人系统讲过的细节。这也是我想写“ai-engineering-from-scratch”这一个话题的原因——它不是某个具体模型的训练教程而是一整套从零开始构建AI工程能力的思路、选型和实操路径。这篇文章我会以“从零搭建AI工程链路”为主线把我实操中积累的组件拆解、工具选型、踩坑记录和排查方法一次聊透。无论你是刚转AI工程方向的新人还是已经在做算法但想补工程短板的开发者这篇内容应该都能帮你把散落的知识点串成一条可落地的技术线。我会尽量少讲虚的多给可以直接抄作业的步骤和参数。1. 整体思路为什么“从零搭建”比“套用框架”更值得做先聊点理念层面的东西。现在AI技术栈已经很成熟HuggingFace、LangChain、各类MLOps平台都能让你快速起步。那为什么还要讨论“ai-engineering-from-scratch”我的看法是框架给你的是“轮子”但工程体系需要你自己设计“底盘”。你只有理解了每个组件在整个链路里为什么存在、解决什么问题才能在遇到框架解决不了的问题时做出正确的取舍。1.1 从零搭建的核心收益很多人低估了“从零搭建”这三个字的含金量。我用一个类比来解释如果你要开一家餐厅直接买预制菜包当然快但你要控制成本、保证菜品特色、应对食客的个性化需求就必须懂食材采购、后厨动线、火候控制这些基本功。AI工程也一样从零搭建的本质是让你掌握“食材”和“火候”。具体来说从零搭建有三个明确的收益完全可控的数据流每条数据从采集、清洗、标注到进入模型每一步都是你可审计、可回溯的出了问题能精确到具体环节。成本可预测不用被动接受平台的高价API或锁定效应你可以根据实际负载精确规划算力和存储资源。能力可迁移你积累的是底层方法论而不是特定平台的操作技巧。换了工具链、换了云厂商核心能力依然有效。以我自己做个例子我之前参与过一个文档智能解析项目最初用了某个现成的文档处理平台很快啊准确率也确实可以。但后来业务要求支持私有化部署还要在弱网环境下离线处理大批量文档平台方案直接卡死。于是我们重新用开源的OCR、版面分析、表格识别组件自己组装了一条处理流水线。虽然前期开发量大了不少但最终的灵活度和性能表现完全不是一个量级。1.2 工程链路全景图从零搭建AI工程首先要建立一张清晰的全景图。我习惯把整条链路切成五个核心环节数据工程层数据的采集、清洗、去重、标注、版本管理。这是整条链路里最脏最累但最重要的一环。特征与训练层特征工程、模型选型、训练调度、超参调优、实验管理。这个环节决定了模型效果的上限。推理与部署层模型序列化、推理服务、性能优化、灰度发布、版本回滚。模型上线只是开始稳定服务才是关键。评测与反馈层离线评测集构建、线上指标监控、badcase回流、自动重训。没有反馈闭环的AI系统效果只会随时间衰减。基础设施层算力管理、容器化、CI/CD、监控告警、成本治理。这层是大多数算法工程师容易忽略、但工程化程度高低全看它的部分。我给很多团队分享过这五个环节几乎每次都会被问到“哪一层最重要”。我的回答一直是在项目初期数据工程最重要在项目中期评测反馈最重要在项目后期基础设施最重要。这个回答听起来像废话但实际踩过坑你就明白AI工程的难点从来不在某一层而在于每一层之间的衔接。2. 关键组件拆解每一层具体做什么、怎么选型说实话这五个环节每一层展开都能写一本书。这里我就挑每个环节里头最容易翻车、也最能体现工程水平的关键组件来拆解。我会结合自己的选型经验和实际对比尽量说清“为什么选它”以及“不选另一个”的理由。2.1 数据版本管理你的数据集也需要Git先说数据工程层里最容易被人忽视的组件——数据版本管理。我见过太多团队的数据集就是一堆日期命名的文件夹data_1023、data_final、data_final_v2……这种搞法一开始没什么模型迭代两三轮之后你就会发现“这个结果是用哪份数据跑出来的”完全对不上号复现实验成了玄学。解决办法是用专门的数据版本管理工具比如DVCData Version Control。它的工作逻辑很好理解文件本身还是放在本地磁盘或对象存储里但DVC会用一份轻量的元数据文件去追踪每个数据集的版本、依赖关系和生成过程。配合Git使用你可以在代码里清晰记录“当前代码 当前数据版本 某个实验结果”。具体操作上你可以在项目里这样初始化# 初始化DVC环境 dvc init # 添加数据目录并远程存储 dvc remote add -d storage s3://your-bucket/dvc-store # 添加数据文件生成 .dvc 元数据文件 dvc add data/raw/documents之后每次数据更新只需要重新执行dvc add和git commit系统会自动记录新旧版本之间的差异。我常用的习惯是给数据版本加上语义化标签类似data_2025Q1_v3这样评审和复盘时一眼就能对上号。还要提醒一点数据版本管理不只是管文件还要管数据血缘。也就是你要清楚每条样本从原始来源到最终进入训练集经过了哪些处理步骤。工具层面可以用DVC的dvc.yaml定义pipeline把清洗、去重、切分这些步骤固化成可重放的流程。2.2 特征存储模型效果的隐形地基如果你做的是偏传统的机器学习或搜索推荐类项目特征存储Feature Store是你绕不开的组件。它的核心作用是让特征的定义、计算、存储和在线读取有一套统一的规范避免训练时用的特征和线上推理时用的特征不一致——这是最坑的线上事故之一。业内典型的开源方案是Feast它支持你在本地或云端配置特征仓库用类似下面这样的方式定义特征视图project: my_project entities: - name: user join_keys: [user_id] feature_views: - name: user_features entities: [user] features: - name: click_count type: int64 - name: avg_session_duration type: float配置好之后训练时你可以批量读取历史特征线上推理时用SDK实时获取最新特征两边共用同一套定义从机制上保证线上线下一致性。我个人的经验是项目初期特征不多、逻辑简单的时候不用急着上Feature Store先用一套定义清晰的SQL或Python函数管理就够了。但如果你发现特征数量超过50个、开始有多个团队共享特征、或者线上和线下口径经常对不上那就该认真考虑引入专门的组件了。2.3 训练任务编排把实验变成流水线传统算法工程师的习惯是把训练脚本一跑盯个三四小时看loss曲线。但在工程化的体系里训练必须变成可编排、可调度的任务。我常用的方案是把训练流程拆成多个步骤用流水线工具串起来。这里要展开讲一下选型。如果你追求轻量、团队本来就以Python为主那我推荐用Prefect或者Dagster它们比Airflow轻很多学习曲线也更平滑。但如果你所在的公司基础设施已经是Kubernetes为主而且团队有较强的运维背景那么Argo Workflows会是更好的选择——它天然和K8s生态集成资源调度能力极强。我自己在大多数中等规模项目里用的是Dagster选它的理由是数据资产的定义清晰、本地调试体验好、和DVC、MLflow都能很好地集成。一条典型的训练流水线长这样数据校验检查数据完整性、统计指标是否异常特征计算生成训练特征集模型训练跑训练脚本自动记录参数和指标模型评估在验证集上计算指标对比基线模型注册把满足条件的模型写入模型仓库并打标签用Dagster的代码结构也很直接核心就是定义asset和job。比如from dagster import asset, OpExecutionContext asset def cleaned_data(context: OpExecutionContext): # 读取原始数据并做清洗 ... return data_path asset def trained_model(context: OpExecutionContext, cleaned_data): # 调用训练脚本 ... return model_path这套机制的优点在于每一步都有输入输出定义、每一步都可以单独复跑不会因为中间某一步失败就得从头再来。2.4 实验追踪不要再用Excel记录超参数了每次我在团队里说“不要用Excel记录实验”都会有人觉得我在小题大做。直到有一天需要复现一个半月前的模型当事人自己也说不清当时学习率设的是多少、用了哪个数据版本大家才明白实验追踪的重要性。实验追踪组件的标配是MLflow它提供四块能力实验记录Tracking、模型打包Models、模型仓库Registry、项目打包Projects。对我来讲最常用的是前两块。在训练脚本里只需要简单的几行代码就能记录所有关键信息import mlflow with mlflow.start_run(run_namebert_finetune_v3): mlflow.log_param(learning_rate, 2e-5) mlflow.log_param(batch_size, 32) mlflow.log_metric(eval_f1, 0.872) mlflow.log_artifact(model/config.json) mlflow.pytorch.log_model(model, model)之后你可以在MLflow的UI界面里按指标排序、按参数过滤所有实验一目了然。我习惯在每轮实验里把“代码commit号、数据版本、关键参数、核心指标”这四要素完整记录缺一个都视为无效实验。2.5 推理服务框架从批量到在线的一步之遥模型训练完之后怎么把模型变成稳定的服务是很多初学者最困惑的地方。市面上方案很多Triton Inference Server、TorchServe、TensorFlow Serving、KServe各领风骚。我的选型逻辑是这样的如果模型类型单一比如主要是深度学习CV模型用TorchServe就够如果需要同时服务多种框架的模型、对吞吐和延迟有很极致的要求那就直接上NVIDIA Triton它的动态批处理、并发模型执行、内存管理做得非常成熟。Triton的核心概念是Model Repository你只要把模型按约定目录结构放好再写一个配置文件服务就起来了model_repository/ └── text_cls/ ├── 1/ │ ├── model.onnx │ └── config.pbtxtconfig.pbtxt里可以声明输入输出格式、动态批处理策略、GPU显存分配等。举个实际例子我用Triton部署一个BERT分类模型配置里设置max_batch_size为64开启dynamic batching之后吞吐量相比逐条请求提升了大约4倍延迟只增加了30%左右。这个收益在业务量大的时候非常可观。在线推理服务还需要配套的东西包括负载均衡一般用Nginx或K8s Service、健康检查/v2/health/ready接口、以及优雅的上线/下线流程。这些虽然听起来像是运维该做的事但AI工程师如果对这些没有一个基本认知线上出问题时会非常被动。2.6 监控与可观测性模型也会“生病”最后一块关键组件是模型监控。很多人以为模型上线之后就万事大吉实际上模型在真实环境里会因为数据分布漂移、上游特征质量变化等原因效果持续衰减。你如果不监控就像开了一家餐厅但从来不检查食材是否过期——迟早出事。监控的两大方向是性能监控和漂移检测。性能监控就是常规的延迟、错误率、GPU利用率这些指标漂移检测则要关注输入数据分布和模型预测分布的变化。常用的工具包括Prometheus Grafana做指标可视化Evidently AI或者WhyLabs做数据漂移检测。我给大家一个实用的兜底方案即便不上专门的ML监控平台也至少要做到两条——第一条线上请求的输入、输出全部落日志定期抽样做人工审计第二条每周自动计算线上预测分布的统计指标和训练时的基准对比超过阈值就告警。这两条做到了大部分模型衰减问题都能及时发现。3. 实操过程从零到一搭建完整链路的过程记录前面把组件都串起来了这一节我想用“假设我们要从零构建一个文本分类系统”的完整场景带你把整条链路过一遍。这套流程是真实可复现的所有选型和步骤都是我验证过的组合。3.1 环境初始化先把基础打牢整个实操流程的第一步是把基础环境搭好。我习惯统一用Docker做环境隔离避免“在我机器上能跑”的经典尴尬。下面这个组合是目前我用着最顺手的Ubuntu 22.04作为基础镜像Python 3.10CUDA 12.x如果你用GPU训练Poetry管理Python依赖Docker Compose编排本地依赖服务一个标准的开发环境docker-compose.yml大概长这样省略了一些细节:version: 3.9 services: mlflow: image: ghcr.io/mlflow/mlflow:latest ports: - 5000:5000 command: mlflow server --host 0.0.0.0 --backend-store-uri sqlite:///mlflow.db volumes: - ./mlflow_artifacts:/mlflow_artifacts postgres: image: postgres:15 environment: POSTGRES_USER: mlflow POSTGRES_PASSWORD: mlflow POSTGRES_DB: mlflow ports: - 5432:5432这样本地一下就把MLflow的追踪服务和它的元数据库同时拉起来了开发时随时记录实验不需要额外依赖远程环境。3.2 数据接入与清洗链路实现进入正题之后第一步是数据接入与清洗。我还是以文本分类项目为例原始数据可能来自多个渠道业务数据库导出的Excel、爬虫抓取的网页正文、用户反馈的工单文本。第一件事是统一schema把所有数据源映射到同一个标准格式dataclass class RawSample: sample_id: str text: str source: str created_at: datetime label: Optional[str]然后建立一个清洗pipeline按顺序执行这些步骤文本去重用MinHash算法处理大规模近似去重HTML标签剥除与特殊符号清洗语言识别过滤业务只处理中文数据时把其他语言样本剔除长度过滤过短或过长的样本往往质量差或无意义PII信息脱敏手机号、身份证号、邮箱等替换为占位符这个pipeline我建议用DVC固化这样每一步的输出都有记录后面排查问题能精确到环节。不要小看这个环节我在实际项目中遇到过因为清洗步骤顺序不当导致脱敏后的文本被下一步误判为异常符号删除白白丢掉了20%的有效训练数据。3.3 训练实验与效果验证的关键细节数据准备好之后进入训练实验环节。这里的核心方法论是不要一开始就上复杂模型先做基线。我会先用简单的TF-IDF 逻辑回归跑一版结果同时用BERT类的预训练模型跑一版两相对比才能判断复杂模型带来的增益是否值得额外的计算和部署成本。以中文文本分类为例代码层面你需要关注几个关键点。比如用HuggingFace的datasets库做数据切分时要保证分布一致性from datasets import Dataset, DatasetDict import pandas as pd df pd.read_parquet(data/processed/train.parquet) dataset Dataset.from_pandas(df) split dataset.train_test_split(test_size0.2, seed42, stratify_by_columnlabel) dataset_dict DatasetDict({ train: split[train], validation: split[test], }) # 确保每个类别的样本量不低于阈值 min_count 100 label_counts df[label].value_counts() assert label_counts.min() min_count, f类别样本过少: {label_counts.min()}训练时我用的是HuggingFace的Trainer接口它的好处是封装了梯度累积、混合精度、断点续训等一堆细节。但即便有封装我还是会手动控制几个参数learning_rate一般在2e-5到5e-5之间从大到小试weight_decay0.01是一个不错的起点gradient_accumulation_steps在显存不足时通过它等效增大batch sizewarmup_ratio0.1是安全值可以确保训练初期稳定训练完成后评估不能只看准确率。我至少会看每个类别的精确率、召回率、F1以及混淆矩阵。因为这些能告诉你的信息远多于单一指标某个类别样本少导致被牺牲了还是某两个类别本身存在语义重叠这些都是模型迭代方向的重要线索。3.4 模型上线与灰度发布实验跑通后真正的工程考验才刚刚开始。模型上线要做的事情远比“把模型文件放到服务器上”复杂。一个标准的上线流程应该是把模型注册到MLflow Model Registry标记为Staging使用Triton部署新模型到一个独立的服务端口在预发环境用小流量比如1%验证功能和延迟对比新旧模型的线上指标确认无回退后逐步放量全量后观察一段时间稳定则标记为Production这个流程里最容易出问题的是新旧模型的切换。我的建议是新老模型并行部署用网关层动态切流而不是直接替换文件。这样可以随时秒级回滚不至于因为一个上线操作引发大面积线上事故。关于模型格式我强烈建议在部署前把PyTorch模型转成ONNX或TensorRT格式原因很简单——推理性能差距巨大。一个BERT模型在PyTorch下如果单次推理需要15msONNX优化后有可能到8ms用TensorRT还能进一步压缩。这个过程需要安装onnx和onnxruntime-gpu转换脚本的大致逻辑是import torch from transformers import BertModel model BertModel.from_pretrained(bert-base-chinese) model.eval() dummy_input torch.randint(0, 1000, (1, 128)) torch.onnx.export( model, dummy_input, bert_base_chinese.onnx, input_names[input_ids], output_names[last_hidden_state], dynamic_axes{input_ids: {0: batch_size, 1: seq_len}}, opset_version14, )转换后务必做精度对比验证随机取100条样本分别用原始模型和ONNX模型推理确认输出差异在可接受范围比如最大误差小于1e-3–1e-4。这一步省略的后果你一定会后悔。3.5 评测反馈闭环搭建模型上线只是开始。为了让系统能持续演进我每次都会搭建一个完整的评测反馈闭环。这个闭环至少包含两条线一条是离线评测线持续积累一份高质量的人工标注评测集每次新模型训练完都要在这份评测集上跑分。这份评测集要覆盖线上遇到的长尾case和badcase不然评测指标会失真。另一条是线上反馈线线上用户的弱反馈信号点击、停留时长、后续操作和强反馈信号用户主动纠错、屏蔽必须被回收。技术实现上可以这样落地# 记录线上样本及预测结果的日志 log_payload { request_id: req_id, input_text: text, predicted_label: pred_label, predicted_score: pred_score, user_feedback: None # 由后续用户行为异步更新 }日志进入Kafka后经过一个定时任务汇总成“待标注池”定期抽样让人工标注持续回流到训练集。没有这个机制你的模型就是开环的——它永远学不会处理那些新出现的case最终只能靠频繁的手工重训来维持效果。4. 典型问题与排查技巧实录这一节我想把实操过程中积累的、几乎每个项目都会踩一遍的问题整理成排查手册。格式不用太正式就当是朋友之间交流经验但每条都是我掏真金白银换来的教训。4.1 数据类问题模型效果差的头号元凶问题现象训练跑了好几个epoch效果一直上不去调参也没用。排查思路先别急着调模型先查数据打印一条训练样本和对应label用肉眼确认是否合理。很多时候是label错位——标注时行没对上导致模型学的全是错的东西。检查训练集和验证集是否有重叠。我踩过一次很大的坑用train_test_split时忘了设random_state结果线上badcase刚好来自验证集里的重复样本评估指标虚高。检查数据分布。比如训练集中A类占90%B类占10%模型直接全预测A类就能刷到90%准确率。这时候必须用分层切分或者引入类别权重。经验法则数据问题导致的模型异常占比远高于算法和参数问题。每当你觉得模型“不听使唤”时先把数据样本翻出来看看。4.2 推理性能问题延迟高得离谱问题现象离线测试时模型推理速度还不错一到线上服务TP99延迟高到用户受不了。这里面常见的坑有三个第一个是没有开启动态批处理。大量用户请求同时到达时GPU是完全可以一次处理多条的但如果你的服务配置是一次一请求GPU利用率极低表现为延迟高且吞吐低。Triton里开启dynamic batching能看到立竿见影的效果。第二个是没有做输入截断。文本类模型的输入长度是决定计算量的关键因素BERT的时间复杂度是O(n²)n是序列长度。如果线上输入文本没有长度限制有些超长文本会把单次推理延迟拉到几十甚至上百毫秒。我的做法是统一截断到512token超过的做摘要或者分段处理。第三个是没有做并发压测就上线。我强烈建议大家上线前用locust或wrk之类的工具做一轮压测看看服务在预期峰值吞吐下表现如何而不是等线上告警了才手忙脚乱。压测可以顺带探测出线程池太小、数据库连接不够这种隐藏问题。4.3 线上线下效果不一致问题现象离线评测F1有0.9上线之后却只有0.7用户反馈经常出错。这里面最经典的根因是特征不一致。如果你在训练时使用了某个特征但线上推理时该特征的获取逻辑没有完全对齐模型看到的分布就会和训练时不一样效果自然回退。这种问题光看代码很难发现需要逐字段比对线上实际取到的特征值和训练时的特征值。其次是环境不一致。训练用的库版本是旧的部署时升级了一个大版本某个预处理函数的行为发生了变化就可能导致预测结果不一致。所以我在部署时强烈建议锁定依赖版本最好把整个训练环境打包成镜像作为部署基线。最后是数据滞后。比如线上特征实时计算的内容和训练时批量计算的时效性不同导致线上看到的分布和训练时不完全一致。这就是我之前提到的Feature Store要解决的根本问题。给一个快速自检的checklist确认训练和验证用的是同一份数据切片逻辑在线推理走一遍完整的预处理代码和训练时的输出对比用线上实际请求喂给离线模型看结果是否一致检查所有特征是否有默认值策略线上可能取到空值4.4 GPU资源利用率低问题现象GPU利用率只有30%左右跑一个训练要两三天成本高得离谱。排查的过程中按优先级检查和调整下面几个点第一数据加载是不是成了瓶颈。如果DataLoader的num_workers太少GPU会一直在空转等数据。我之前遇到过num_workers2导致GPU利用率只有20%的情况调到8之后直接翻倍。第二批大小是否合适。batch size太小导致计算无法充分利用GPU并行能力但也不宜太大要结合显存和模型收敛特性平衡。多试几个值16/32/64从指标曲线上能找到最优解。第三检查是否使用混合精度。对大部分深度学习模型自动混合精度AMP能在几乎不损失精度的情况下提升训练速度。PyTorch里开启方式很简单from torch.cuda.amp import autocast, GradScaler scaler GradScaler() with autocast(): loss model(batch) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()另外一个隐蔽但常见的坑是把模型留在了CPU上而不自知。排查时随手执行nvidia-smi看看当前进程是否真的在GPU上往往能省下大量排查时间。4.5 实验管理混乱问题现象每个人都在用自己的方式记录实验代码、数据、参数对不上号无法复现。这个问题的根源是缺少“强制规范”。工具只是辅助关键是流程。我推荐的最小规范是必选实验记录里锁定Git commit号必选记录数据版本DVC版本号或文件哈希必选记录全部关键超参不只是改了的那几个必选对每个模型归档训练日志文件和评估结果强烈建议把“成功实验的完整复现步骤”写成文档在MLflow里这些都可以通过tag和description来组织。一个好的实践是每个正式实验都写一行简短描述说明这次实验的动机和结论。你会感谢当初那个愿意多写一行字的自己。5. 一些可能对你有用的补充建议聊到这儿整个“ai-engineering-from-scratch”的核心链路和实操方法都过了一遍。工程落地这件事本质上不是“会不会某个框架”的问题而是一个“如何把散点串成线、把线织成网”的系统工程。我最后再分享几个从项目里总结出来的原则和做法希望能给你一些参考。5.1 用小项目练手不要一上来就搞大系统如果你现在还没有完整走通过一条AI工程链路我最实在的建议是找一个小到不能再小的项目比如一个二分类文本分类器从数据版本管理到模型上线完整走一遍。规模小没关系关键是让“数据-训练-部署-监控-反馈”这个闭环在你手里真实转动一遍。为什么要这么大费周折因为大部分纸面上的理解只有落到真实流程中才会暴露出缺口。比如你觉得自己会部署模型但第一次做灰度发布、第一次画监控大盘、第一次回滚版本之后你才真正理解“模型上线”这四个字的重量。5.2 标准化优先于优化项目初期花太多时间优化推理性能或调参往往得不偿失。我的经验是先用标准做法把全链路跑通再针对瓶颈做优化。所谓“标准做法”是指不出来花活、用社区验证过次数最多的方案。当整条链路是稳定可复现的你后续做的每一个优化才有衡量的基准。比如推理性能优化不要一上来就上TensorRT先用ONNX跑通确认线上收益再进一步。每次只改变一个变量确保你能判断变量的真实影响。这在实验阶段和优化阶段都适用。5.3 自动化一切可以自动化的流程当你的项目进入稳定期后把精力花在自动化上是ROI最高的投入。我现在不管什么新项目都会尽早搭好CI/CD的架子代码提交触发单元测试和代码检查数据变更触发数据校验训练完成自动在评测集上跑分并更新看板模型注册后自动触发预发环境部署和烟雾测试这套东西一旦搭好每次迭代的时间成本会大幅下降。而且更关键的是自动化把“人忘记”这个最大的风险消灭了。回顾我自己这几年做AI项目的过程最大的感受是AI工程能力的提升不是靠读多少篇论文、跑多少场比赛而是靠一次次完整的项目闭环积累出来的肌肉记忆。希望这篇围绕“ai-engineering-from-scratch”的梳理能帮你少走一些弯路。如果你正好也在搭建自己的AI工程体系不妨从小闭环开始试起来——做完第一版你再回头看这篇文章的很多细节就会有完全不同的感受。