作为一个在算法和工程之间来回折腾了快八年的老家伙，我见过太多"模型跑通就以为万事大吉"的团队。Notebook里F1分数再漂亮，一上线上就变成事故现场，数据延迟、特征穿越、模型膨胀、监控缺失，哪一件都能让你在凌晨三点被on-call电话吵醒。所以当我看到有人把"ai-engineering-from-scratch"当项目标题时，第一反应是欣慰——终于有人愿意从地基开始盖房子了。

这个标题翻译过来就是"从零开始的AI工程"，它不是一个具体的算法模型，也不是某个现成的框架，而是一条完整的修炼路径：从数据怎么进、特征怎么算、模型怎么训、服务怎么上，到线上怎么监控、怎么迭代，把所有环节用工程化的手段串起来。这篇文章就是想跟你聊聊，我理解的"ai-engineering-from-scratch"到底该怎么落地，包含哪些核心模块，有哪些必须提前避开的坑，以及一个普通工程师要怎么系统地把这套东西搭起来。

这篇内容适合三类人：刚入行的算法工程师想补工程短板的人，被"算法落地难"困扰的团队技术负责人，以及想转行进入AI应用开发领域的后端工程师。我会尽量用大白话讲清楚原理，并给出可以直接照着做的实操方案，哪怕你手头只有一个GPU和一台云服务器，也能一步步把系统跑起来。

1. 先想清楚终点：AI工程的完整链路长什么样

很多人一提"AI工程"就想到训练模型，这是最大的误区。模型的训练只是整条链路里很小的一个环节，就像装修房子时刷墙只是最后一步，水电改造、墙体结构、材料采购才是真正决定质量的东西。一个完整的AI工程链路，应该有下面这几个阶段。

1.1 数据获取与质量保障

数据是整个AI系统的地基。这一阶段要回答的问题包括：数据从哪里来（业务数据库、日志、第三方接口、用户标注等）？数据怎么采集、怎么同步？如何保证数据质量（完整性、一致性、时效性）？数据是否需要脱敏和合规审查？以我个人的经验，数据清洗和校验往往占据整个项目40%以上的时间，这不是浪费，而是必要的代价。数据问题的处理速度通常决定了一个AI项目的生死，因为脏数据会让后面的所有环节全都白做。

1.2 特征工程与存储设计

传统机器学习里有一句话叫"特征决定了模型的上限"，深度学习时代这句话依然成立，只是特征从手动设计变成了模型自己学。但工程上仍然需要解决特征怎么算（实时还是离线）、特征怎么存（特征仓库）、特征怎么对齐（训练时和推理时用同一套逻辑）的问题。特征穿越（用到了未来数据）是离线指标好看、线上效果崩盘的头号原因，必须在工程架构上彻底杜绝。

1.3 模型训练与实验管理

训练并不只是跑一次fit就完事。你需要管理训练数据版本、代码版本、超参数组合、模型产物，需要一个实验记录系统追踪每一次训练的效果差异。我见过太多团队"这次效果好了，但没人记得怎么复现"。没有实验管理的AI项目，最后都会变成一次性项目，不可持续。

1.4 评测体系

评测是AI工程最容易糊弄、也最不该糊弄的环节。除了常规的离线指标（准确率、召回率、AUC等），还要设计坏case分析流程、长尾场景覆盖测试、鲁棒性测试（输入扰动、异常输入）、以及必要的线上A/B测试。没有评测体系，你根本不知道模型上线后是在变好还是在变坏。

1.5 推理服务与成本控制

模型最终要被人调用，所以你得把它封装成服务，考虑延迟（P99）、吞吐量（QPS）、并发处理能力、资源占用。一个大模型的推理服务一天可能烧掉几百上千元的GPU费用，如果没有合理的缓存、批处理、模型压缩等优化手段，成本分分钟失控。

1.6 线上监控与反馈闭环

上线不是终点，是起点。你需要监控线上推理请求的指标（延迟、错误率、流量分布）、监控输入数据的分布漂移（数据漂移），还需要建立明确的反馈闭环：线上的坏case如何回流、如何变成下一轮的训练数据。AI系统区别于普通软件的地方就在于它有一个"数据-模型-服务-反馈-再训练"的闭环，把这个闭环跑通了，才叫AI工程化。

2. 技术栈选型：不要把时间浪费在反复换框架上

技术选型是"ai-engineering-from-scratch"的第一步，也是最容易踩坑的一步。很多新手喜欢追新框架，今天用这个明天用那个，结果工具链换来换去，业务一点没推进。我的建议是：用主流的、社区活跃的、你团队已经有经验的技术，不要为了炫技选择冷门方案。

2.1 编程语言与项目脚手架：Python为主，工程规范兜底

Python是AI领域没有争议的主流语言，生态最全，社区最活跃。但Python的工程性也最差，所以必须有严格的工程规范来兜底。项目从0开始，我建议用下面的结构来组织：

├── configs/ # 配置文件（YAML/JSON） ├── data/ # 数据存放（通常通过gitignore忽略） ├── docs/ # 项目文档 ├── src/ │ ├── data/ # 数据下载、预处理、清洗 │ ├── features/ # 特征工程 │ ├── models/ # 模型定义与训练逻辑 │ ├── evaluation/ # 评测代码 │ └── serving/ # 线上服务封装 ├── tests/ # 单元测试与集成测试 ├── scripts/ # 运维脚本与批处理任务 ├── pyproject.toml # 依赖管理 └── README.md

这个结构的好处是：数据、特征、模型、服务、测试彼此隔离，任何人加入项目都能很快定位到对应模块。Python依赖管理我强烈建议用uv或poetry，而不是裸pip install加一个requirements.txt，因为后者的依赖冲突会让你在半年后怀疑人生。

2.2 数据存储选型：离线、实时、特征分开对待

数据的存储要根据使用场景分开选型，这是工程化的重要标志：

这里要特别提醒一点：不要在同一个库里又存原始数据又存模型产物。训练数据、测试数据、线上日志，这些东西的生命周期和访问模式完全不同，混在一起只会让运维变成噩梦。

2.3 训练框架：PyTorch为主，别两种框架混用

现在做AI工程，PyTorch基本是默认选项。TensorFlow当然也能做，但现在社区里新模型、新论文几乎都用PyTorch实现，你抄作业都更方便。如果你的团队已经有人熟练使用某个框架，那就直接用那个，框架迁移的成本远比想象中高。

训练基础设施方面，推荐用PyTorch Lightning或者Hugging Face Trainer来管理训练循环，它们把日志、checkpoint、分布式训练这些重复工作都封装好了，能省下大量时间。别自己造训练循环的轮子，除非你想深入研究底层机制。

2.4 部署方案：从FastAPI到推理服务框架

模型部署的最简方案是FastAPI + ONNX Runtime或者TorchServe。如果只做内部调用、QPS不高，FastAPI完全够用。如果要做高并发、低延迟的在线推理，建议直接上推理服务框架，比如NVIDIA Triton Inference Server，它能自动做动态批处理、多模型管理、GPU资源调度。Rust生态的mature框架也可以考虑，但对大多数团队来说不是必要选项。

2.5 可观测性：日志、指标、链路追踪三位一体

AI服务也是服务，所以可观测性不能缺席：日志收集用ELK或Loki，指标监控用Prometheus + Grafana，链路追踪用Jaeger或OpenTelemetry。很多AI工程师忽略这一块，觉得"模型能出结果就行"，直到线上出了问题才发现没有任何线索可查。在我的经验里，可观测性的投入应该在项目里占比不低于10%，这钱花得值。

3. 核心环节实操：从数据集到可交付模型的全过程

技术栈选好了，接下来就是实打实的干活环节。这一章我按"数据→特征→训练→评估"的顺序，把每一个关键环节的实操做法和配置参数写清楚，你可以直接对照着落地。

3.1 数据管线：清洗、校验、版本管理

第一步是搭数据管线。最简单的做法是写一套可重复执行的ETL脚本，用dlt、dbt这类工具管理。清洗的步骤要固化成代码，不要用"临时处理一次"的Notebook。

数据质量校验是几乎所有人都会忽略的环节。一定要在管线里加入自动校验规则，比如：

• 字段完整性：关键列不能有超过1%的空值
• 类型正确性：数字列不能被存成字符串
• 值域范围：年龄必须在0~120之间，价格不能是负数
• 时间顺序：训练集的事件时间必须早于线上预测时间

每条规则失败时，管线要能自动告警并阻止训练任务启动。用Great Expectations或Pandera做校验都很方便。数据版本管理方面，可以用DVC或Delta Lake的time travel能力，确保训练结果可回溯。

3.2 特征工程实践：离线计算与线上一致的秘密

特征工程的工程化核心只有一个词：一致性。训练时怎么算特征，推理时就必须一模一样。为此，强烈推荐把特征计算逻辑封装成独立的模块，训练代码和推理服务都调用同一个函数或类，绝不允许各写一套。

举个例子，假设你要计算一个"用户过去7天平均下单金额"的特征：

# feature_definitions/user_features.py from datetime import datetime, timedelta class UserOrderStatFeature: def __init__(self, window_days: int = 7): self.window_days = window_days def compute(self, events: list[dict], current_time: datetime) -> float: """计算用户在current_time之前window_days天内的平均下单金额""" window_start = current_time - timedelta(days=self.window_days) filtered = [ e for e in events if e["event_time"] >= window_start and e["event_time"] < current_time ] if not filtered: return 0.0 return sum(e["amount"] for e in filtered) / len(filtered)

只要训练脚本和推理服务都调这个compute方法，就能保证特征一致性。注意里面有个容易被忽略的细节：时间窗口应该是"以预测时刻为终点往前推"，而不是"以自然日为单位"。很多feature leak就是这么产生的。

特征存储方面，我建议为每个实体（用户、商品等）建立一个特征表，用时间戳管理版本，线上读取走Redis缓存，离线训练直接查表。不要用"每次训练临时跑一遍特征任务"的原始方式，后面线上对不上你会痛苦得想辞职。

3.3 模型训练：配置管理、日志与超参数

训练实验的可复现性依赖三个东西：代码版本、数据版本、配置版本。代码用Git管理；数据用DVC或表格式的time travel管理；配置必须存到文件里，而不是散落在代码里。

我建议项目的配置目录长这样：

# configs/experiment_001.yaml model: name: "bert_encoder" hidden_size: 768 num_layers: 12 data: train_path: "s3://bucket/train/v003.parquet" eval_path: "s3://bucket/eval/v003.parquet" batch_size: 32 num_workers: 8 train: optimizer: "adamw" learning_rate: 2e-5 epochs: 5 gradient_clipping: 1.0 fp16: true save_every: 500 # steps evaluation: metrics: ["accuracy", "f1", "auc"]

每次开启新实验，复制一份配置改个名，训练日志里记录配置文件的路径和内容的哈希值，这样过了一个月你翻回来还能知道这个模型是怎么来的。训练过程中的日志用loguru或者Python内置logging，建议至少记录：每个step的loss、每个epoch的验证指标、GPU显存占用、学习率变化。

超参数调优方面，不要用网格搜索硬扫，太费时间和算力。用Optuna做贝叶斯搜索，先粗后细，先把关键的超参数（学习率、batch size、层数）找到合适的范围，再在这个范围里精细搜索。每个试验的记录要及时入库。

3.4 评估体系：别只看准确率，多维度评测才算数

模型评估是决定上线质量的关键，但也是大家最爱偷懒的地方。只算一个总准确率的评估体系等于没有评估，因为在绝大多数业务场景中，类别不平衡、长尾分布、case多样性都是比"平均表现"更重要的东西。

一份规范的评估报告至少要包含这些内容：

• 分层的指标：按用户群体、按商品类目、按流量渠道分别统计效果
• 混淆矩阵或按阈值切换的Precision-Recall曲线
• 坏case分析：抽样看预测错的样本，归纳错误类型
• 鲁棒性测试：对输入做微小扰动、加噪声、缺字段，看输出是否稳定
• 与线上基线（或上一个模型）的对比测试

如果做的是在线推荐、搜索排序这类业务，还要评估模型对多样性的影响、对新鲜内容的友好程度。这些指标虽然在离线阶段不完全准确，但至少能提前暴露不少问题。

在评估代码里，我强烈建议把每次评估结果输出成一个报告文件（HTML或Markdown），附带样本展示，这样团队里非算法人员也能参与评审，有助于建立互信。说白了，算法不是做给自己看的，是给业务和老板看的，你要让他们看懂你的算法到底好在哪。

4. 部署上线与成本优化：让模型真正跑起来

训练做完，模型还只是"在实验室里跑通了"。真正把它变成能对外提供服务的系统，需要把部署和成本两件事都安排明白。

4.1 服务化封装：把模型包成一套标准接口

模型上线的第一步是封装。推荐用FastAPI把模型包装成一个HTTP服务，接口设计遵循下面这样的模板：

# serving/app.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel import onnxruntime as ort app = FastAPI() class PredictRequest(BaseModel): user_id: str item_id: str context: dict = {} class PredictResponse(BaseModel): score: float model_version: str latency_ms: float sess = ort.InferenceSession("models/model_v3.onnx") @app.post("/predict", response_model=PredictResponse) async def predict(req: PredictRequest): # 1. 实时特征拼接 # 2. 特征预处理（与训练一致） # 3. ONNX推理 # 4. 返回结果 ... return PredictResponse(score=score, model_version="v3", latency_ms=latency)

注意这里用了ONNX格式，它比直接用PyTorch做推理有几点好处：推理速度更快（有图优化）、内存占用更低、部署时不需要安装庞大的PyTorch环境。如果你觉得转ONNX麻烦，用PyTorch的torch.compile压缩后部署也可以接受，但长期来看ONNX或者TensorRT是更专业的路线。

4.2 容器化与资源估算：一台机器能扛多少流量

部署载体几乎无脑选Docker。Docker镜像要把项目依赖、模型权重、启动脚本全部打包。模型文件超过1GB时，注意镜像构建时不要用ADD直接塞模型，而是用运行时挂载或模型仓库拉取的方式，否则每次发布都要传几个GB的文件，非常痛苦。

资源估算是部署之前必须做的功课。用一个简单的公式估算：假设单机QPS上限为q，业务高峰期预测QPS为Q，那么最少需要的实例数约为Q / (q * 0.7)，0.7是安全系数，给突发流量留缓冲。而单机QPS需要用压测来确定，不要靠猜。用locust或wrk做压测，解出P99延迟和最大QPS，再倒推资源需求。

下面是一个简化的资源估算表，假设单个模型请求的平均处理时间5ms，单卡A100：

表格只是示例，实际数值因模型和硬件差异很大，一定要以自己的压测为准。压测的时候还要关注显存和内存的峰值占用，防止流量过大时OOM（内存溢出）。

4.3 性能优化：P99延迟从300ms降到50ms

性能优化是工程能力的分水岭。有几个常见的方向，按性价比排序：

第一，批处理。推理服务可以攒一小批请求一起计算，GPU利用率会大幅度提升。Triton推理服务自动支持这个功能，用FastAPI的话可以用asyncio.gather手动攒批。

第二，模型量化。把FP16换成INT8，显存占用减半，推理速度提升2~4倍，代价是精度可能下降0.5%~2%。如果业务对精度没有那么敏感，量化几乎是无脑的选择。推荐用TensorRT或ONNX Runtime自带的量化工具。

第三，缓存。对于同样的输入（比如同样的user_id和item_id），短时间内的预测结果如果一致，可以用Redis缓存，TTL设30秒到几分钟，命中率高的场景能省一半以上的算力。

第四，降低请求体大小。有些接口会传大量文本或几十个特征字段，序列化和反序列化本身就耗时，能精简的字段尽量精简，能用整数ID的不要用字符串。

我给过一个模型的P99延迟做了完整的优化，从380ms降到52ms，代价是精度损失0.6%，但业务方完全接受，因为这个模型的使用场景对速度比精度更敏感。这就是典型的工程取舍：不要追求最优指标，要追求"够用且最快"。

4.4 成本治理：看懂账单，做算力规划

AI项目的成本大头几乎都是GPU算力。成本治理的关键是：能离线算的不要实时算，能用CPU的不要用GPU，能用小模型的不用大模型。

先说离线与实时分离。推荐、搜索类业务的粗排阶段可以用小模型或者双塔模型离线算出候选集，线上只做精排。这样实时计算的压力会小一个数量级，成本大幅下降。我现在做的项目里，线上实时计算的比例只占全链路的10%，剩下90%都是离线批量计算加缓存。

再说自适应弹性。如果是跑在Kubernetes集群里，可以开基于负载的HPA（水平自动扩缩容），根据QPS和延迟动态调整实例数。高峰期自动扩容，低谷期自动缩容，成本能降30%以上。别忘了给训练任务设置最大并发数，防止某次调参实验偷偷吃光整个集群的资源。

5. 线上监控与持续迭代：AI系统能不能长期健康运行

AI系统上线之后，真正的挑战才开始。模型不是"静态代码"，它的输入分布会随时间变化，业务场景会变，用户行为会变，如果不做监控和迭代，模型效果会不知不觉地衰减，直到某一天业务方跑来质问"你们模型是不是坏了"。

5.1 监控指标设计：技术指标与业务指标分开看

AI服务的监控要分两个层面。技术指标和普通后端服务一样：请求量、错误率、P50/P95/P99延迟、GPU利用率、内存占用。业务指标则要结合模型效果：预测分数分布、正样本占比、TopK命中率、A/B测试的核心业务指标（点击率、转化率等）。

一个容易被忽视的细节是：预测分数分布本身就是一个很有效的前置告警信号。正常情况下，一个训练良好的模型的预测分数分布应该是稳定的。如果某天线上请求的平均分数从0.7突然变成0.5，那很可能不是因为模型坏了，而是输入数据发生了变化（比如用户群体变化、特征源挂了），这时候即使准确率还没变化，你也应该知道出事了。我习惯在Grafana里加一个"预测分数均值"的时序图，配合3-sigma告警规则，这个习惯救过我很多次。

5.2 数据漂移检测：监控"数据变了没"而不是"模型坏了没"

数据漂移是AI系统独有的问题。最简单实用的方法是定期对比线上实际输入特征分布与训练时特征分布的差异，用PSI（Population Stability Index）或KL散度量化。PSI计算方式并不复杂，一个简单的实现可以是：

import numpy as np def calculate_psi(expected, actual, bins=10): # 把两个分布都切成bins个桶 expected_counts, edges = np.histogram(expected, bins=bins) actual_counts, _ = np.histogram(actual, bins=edges) expected_rate = expected_counts / expected_counts.sum() actual_rate = actual_counts / actual_counts.sum() # 防止分母为0 actual_rate = np.clip(actual_rate, 1e-6, None) psi = np.sum((actual_rate - expected_rate) * np.log(actual_rate / expected_rate)) return psi

PSI超过0.2时就要开始警惕，超过0.25基本可以判定分布发生了显著变化。这里计算的不是单条请求，而是周期性的批次统计。你可以每天跑一个定时任务，把当天的特征分布和训练集特征分布做对比，输出到报表系统。

5.3 模型版本管理与灰度发布：上线前的安全网

模型上线最大的风险是"新版比旧版差"却没被发现。解决方案是灰度发布加完善的对比机制。我的做法是：

• 旧模型保持在线，新模型先以5%流量试运行
• 对分到新模型的流量做实时埋点，记录预测分数和业务结果
• 每天跑一个对比报告：新旧模型的线上效果指标对比、分数分布对比、延迟对比
• 如果连续3天新模型核心指标不低于旧模型，再逐步放量到30%、50%、100%
• 如果任何一天新模型出现异常，立即切回旧模型

这个流程依赖一个很重要的前提：新模型和旧模型必须同时在线且能够被独立观测。所以服务启动时要带上版本号，预测结果的log要记录版本信息。版本号在日志、监控、响应体里都要带，这样排查问题时才知道是哪个模型在处理请求。

5.4 反馈闭环：让线上的坏case变成下一轮的训练数据

AI系统持续变好的核心是反馈闭环。具体来说，要把线上预测错误或者用户反馈不满意的case回流到标注系统，由人工评估标注，然后并入下一轮的训练集。这一步听着简单，但很多团队卡在"没有反馈通路"上。

落地时至少要打通三条通路：

• 日志通路：线上推理日志定期导入数仓
• 标注通路：从日志中抽样的坏case推送到标注平台，标注结果入库
• 训练通路：标注数据合并到增量训练集，触发新一轮训练

我在实际项目里遇到过最遗憾的情况是：一个推荐系统上线后，用户点击数据每天都在产生，但没有任何人把这部分数据用来更新模型。团队以为模型上线就万事大吉，结果三个月后点击率比刚上线时跌了20%。反馈闭环不是可选项，而是AI系统的"保养系统"，没有它，模型就是一次性的消耗品。

6. 常见问题与排查实录：那些年我踩过的坑

做AI工程这么久，踩过的坑可以装一卡车了。这一节挑几个常见的系统性故障，写成速查表，希望能帮你省掉几个加班的夜晚。

这中间最值得展开说的是"特征穿越"。有一次团队训练了一个CTR预估模型，离线AUC高达0.82，比线上旧模型高了不少，大家都很开心。结果上线压测时发现效果一塌糊涂。后来排查才发现，训练集里一个"近7天是否点击过该商品"的特征，清洗脚本里误用了整个时间段的未来数据。这样的问题离线几乎无法发现，只能靠严格的时间特征校验来终结。所以在做特征工程时，务必确认：特征计算只能依赖当前预测时刻之前的信息，这是一条铁律。

另一个高频问题就是线上请求和训练数据的特征拼接。训练时特征都是从离线表里查的，而线上推理时有些特征根本拿不到（比如"用户当天是否浏览过该商品"，线上还没产生这个行为）。这种情况必须在特征设计阶段就预判，把实时拿不到的特征改成"取用户最近一段时间的历史行为"。这个坑几乎每个人都会踩，只能靠对业务的理解来规避。

7. 写在最后：给正在搭这套系统的人几句掏心窝的话

"ai-engineering-from-scratch"说起来是一个项目标题，但真正做起来，它是一整套关于"如何让算法稳定产生业务价值"的方法论。我个人这几年最大的体会是：AI工程化的难点从来不在于算法有多前沿，而在于每个环节是否都足够朴素、足够扎实。数据干净吗？特征一致吗？监控及时吗？回滚方便吗？这些问题没有一个是"高难度算法"，但每一个都能让一个AI项目夭折。

最后再分享一个实用的小技巧：无论项目多小，从第一天开始就要写"项目工程文档"，记录架构图、数据流、依赖项、上线checklist。遇到问题更新排查记录。这个文档平时看起来不起眼，但当团队从1个人变成5个人、从日活一万变到日活百万时，它会成为整个系统能否持续演进的基石。

如果你正准备从零开始搭AI工程，别追求一步到位，先把最小闭环跑通：一份干净的数据、一个能复现的训练脚本、一个简单有监控的推理服务。在此基础上迭代，比一开始就想做一套"完美平台"要靠谱得多。祝你的模型上线顺利，也祝你再也不用凌晨三点被报警电话吵醒。