上个月帮一个朋友团队复盘他们的AI项目，模型在离线测试集上跑出95%的准确率，领导兴奋得直接拍板上线。结果线上运行不到两星期，预测结果越来越离谱，用户投诉量翻了三倍。我扫了一圈他们的工程代码，发现问题一个接一个：训练数据和线上数据完全脱节，特征处理逻辑散落在五六个脚本里，模型版本靠文件名管理，没有一份评估集是带日期的。这其实是很多“AI项目”的通病——模型本身没问题，问题在于根本没有“AI工程”。
“ai-engineering-from-scratch”这个项目，核心不是在训一个更准的模型，而是围绕AI落地的全生命周期，把数据、模型、评估、部署、监控这些环节串起来，形成一套标准化、可复现、能运维的工程体系。如果你现在的工作还停留在“调参、训练、跑测试”的阶段，或者你正打算把一个笔记本里的demo变成一个真正能上线的系统，这篇文章就是给你看的。我会从工程架构、关键模块拆解、完整实操案例三个层面，把自己从零搭建AI工程的经验和踩坑记录都摊开讲清楚。
1. 先搞清楚AI工程到底在解决什么问题
1.1 模型只是AI系统里最小的一块
很多人对AI项目有个误解，觉得核心就是模型。模型当然重要，但它只是整个系统的一个环节。一个能稳定运行的AI系统，数据管道、特征工程、模型训练、部署服务、监控反馈，每一层都会决定项目最终的成败。在我评审过的项目里，模型性能翻车的情况反而是少数，更多的问题出在数据衔接、特征一致性、版本管理这些“工程细节”上。
举个例子。一个推荐系统团队，花了大量精力优化模型结构，AUC涨了0.5%。结果上线后发现，线上请求的特征取值和训练时的目标编码对不上，线上特征缺失率高达15%。这0.5%的离线提升，在线上直接变成了5%的指标下降。这不是模型问题，这是特征生产链路的工程质量问题。
AI工程化的本质，是把“做实验”和“做产品”彻底分开。做实验时，你可以随时调整数据，可以反复重跑训练，甚至可以容忍代码里有些临时修改。做产品不行，数据要有稳定的schema，特征要有统一的口径，模型要能追溯是哪份数据、哪份代码、哪个参数跑出来的，服务要有监控、要有回滚能力。这就是AI工程和调参之间的分水岭。
1.2 和数据科学的边界到底怎么划
数据科学家的日常工作重心在探索和建模：分析数据分布、设计特征、实验不同模型、调优超参数。AI工程师的职责则更宽，要在数据科学家给出的模型基础之上，搭建工业级的鲁棒系统。我见过很多团队，数据科学家把模型做出来了，却没人能把模型真正落地成一个服务，也没人能把数据和特征流程化、标准化。这个空缺，就是AI工程要补的。
更准确地说，AI工程继承了很多传统软件工程的理念，但又多了几个AI场景特有的难点。传统软件工程的输入输出是确定性的，一个函数传什么参数就返回什么结果。AI系统则建立在真实世界的数据之上，数据会漂移、会缺失、会包含噪声，模型本身也有概率性。这意味着AI工程不仅要管代码，还要管数据、管模型版本、管评估口径。这也是为什么这套体系需要单独拎出来系统化学习，而不是简单套用几个DevOps工具就能搞定。
1.3 为什么建议从零手写一遍工程骨架
现在市面上的MLOps平台很多，Kubeflow、MLflow、Airflow这些工具开箱即用。但我不建议新手一上来就铺一堆平台组件。这些工具抽象层级高，如果对底层的环节没有亲手搭建过，出了问题很难排查，也很难根据团队实际情况做出合理的技术选型。
“ai-engineering-from-scratch”这个名字，核心就是强调亲手搭建。不依赖重型平台，用最直接的方式，把数据版本管理、特征管道、模型注册、评估体系、部署监控每个环节写一遍。这个过程走通了，你对整套体系的每个齿轮都了然于胸，再去看那些MLOps平台，会发现它们的结构跟你手工搭的没有本质区别，只是做得更完善、更自动化。
2. 从零搭建AI工程的四块基石
2.1 数据层：让你的数据“可回溯、可复现”
数据是整个AI系统的地基。工程化意义上的数据管理，不只是把数据存起来，而是要回答三个问题：这版模型用的是哪个时间范围的数据？数据的schema是什么？如果数据发生了变化，怎么追溯？
我个人的做法，是把每次训练用的数据集当成一个“版本化产物”来管理。最简单的方式，是每次生成训练集的时候，记录下数据文件的哈希值、生成脚本的版本、原始数据的起止时间，并把这些信息写进一个dataset_manifest.yaml文件。这样后续任何一次模型效果异常，都可以迅速定位到是不是数据出了问题。
dataset_name: customer_ticket_train_v12 created_at: 2025-01-15T10:00:00Z source_data_version: 2025-01-14 data_interval: start: 2024-10-01 end: 2025-01-10 feature_engineering_code_version: 24a7f8c row_count: 85000 schema_signature: sha256:9f2a3c...不要小看这个yaml文件，在排查问题时它就是你的第一把钥匙。没有它，你面对一份数据文件，根本不知道它是哪来的、覆盖什么时间范围、用了什么逻辑处理后得到的。
数据处理管道的设计，我倾向于按“分层”的思路来组织。原始数据层保持不动，只做增量落盘和清洗；中间层做去重、格式标准化、ID统一；特征层做聚合、编码、切分训练集和验证集。每一层都有独立的代码模块，层与层之间通过数据接口解耦，而不是让脚本之间互相调用，避免牵一发而动全身。
2.2 模型层：把每一次实验都变成可追溯的记录
模型层面的工程化，重点在于“实验追踪”。很多数据科学家习惯在Jupyter Notebook里反反复复调参数，这个notebook存下来，但没有记录下数据集版本、结果指标、训练时长。两星期之后回头看，根本分不清哪个是更优版本，更别说复现当时的实验了。
工程化之后，每次训练都要产出一份结构化的实验记录。用MLflow可以，自己写个简单的JSON记录也行，关键是这些字段必须有：训练代码的commit号、数据集版本、模型配置（超参数全文）、评估指标（精确率、召回率、F1等）、模型产物的存储路径。这些信息统一汇总，就形成了逻辑上的模型注册表。
我这里分享一个轻量级的替代方案，不引入额外平台，用纯Python实现实验记录：
import json import hashlib import os from datetime import datetime def save_experiment_record(model_dir: str, config: dict, metrics: dict, dataset_version: str): record = { "experiment_time": datetime.utcnow().isoformat(), "git_commit": os.popen("git rev-parse HEAD").read().strip(), "dataset_version": dataset_version, "model_config": config, "metrics": metrics, "model_artifact_hash": hashlib.sha256( open(os.path.join(model_dir, "model.bin"), "rb").read() ).hexdigest(), } with open(os.path.join(model_dir, "experiment_record.json"), "w") as f: json.dump(record, f, indent=2, ensure_ascii=False)记录归记录，最终还是要解决“选用哪个模型上线”的问题。我的实践是，模型注册表里区分“实验模型”和“生产候选模型”。实验模型可以有很多个，随便折腾；只有通过评估门槛的，才允许打上生产候选标签，进入下一步的部署流程。这个门槛，不能只看单一指标，比如只看准确率，而要结合业务目标来判断，你是更怕漏判还是更怕误判，对应的评估口径完全不同。
2.3 评估层：建一套不会撒谎的评价体系
AI工程里最容易被低估的，就是评估环节。很多团队就是随机切一个train_test_split，然后看分数，然后结束。这个做法在工程化视角下是非常危险的，因为随机切分往往会引入数据泄露，比如用户ID在训练集和测试集里都有，模型实际记住了用户，而不是学到了规律。
一个健壮的评估体系，要有三个独立的评估集，分别是训练集、验证集和测试集。划分的粒度要依据业务最小单元，如果是用户行为预测，按用户ID划分，而不是按行为记录行划分；如果是时序数据，按时间窗口划分，严禁混用未来数据。每次上线前，模型要在测试集上做最终检验，并且测试集要尽可能冻结不变，避免反复用同一个测试集调模型导致过拟合。
除了静态评估集，还必须有一个回归测试集。回归测试集由历史线上日志构成，专门用来捕捉“新的修改是否让老case变差”的问题。这个思路搬自传统软件工程里的回归测试。在AI场景下，线上bad case、用户投诉样本、边缘边界样本，都要归集到这个集合里，每次新模型上线前必跑一遍。
评估指标的设定也要多想一步。二分类问题不要只看准确率。样本不平衡的时候，准确率会非常具有欺骗性。比如99%都是负样本，全预测成负类也有99%准确率，但这个模型一点用都没有。至少要看精确率、召回率、F1，再加上业务自定义的“混淆矩阵代价”，把误报和漏报加权算出一个综合成本指标。还需要跟踪预测置信度的分布，评估模型是否过度自信，这往往是线上风险的前兆。
2.4 部署层：先把在线推理的闭环跑通
模型部署是很多刚从Notebook走出来的团队最头疼的一环。第一个要接受的观念是：上线不是“把模型文件放到服务器上”就完了。部署至少包含服务化接口、特征加载逻辑、模型加载管理和推理性能保障四个部分。
服务化接口，我建议用轻量级的REST API起步，框架用FastAPI就非常合适。这里有个容易踩坑的地方：特征加载逻辑必须在服务内部和训练时保持一致。同一个特征，训练脚本里处理了缺失值、做了标准化，在线推理时也必须用同样的逻辑处理一遍。否则线上效果和离线评估就对不上。最稳妥的办法是，把特征处理函数封装成一个独立的模块，训练代码和服务代码都import这个模块，从源头上保证一致性。
from fastapi import FastAPI, HTTPException from pydantic import BaseModel import joblib app = FastAPI() model = joblib.load("./artifacts/model_v12.bin") class TicketRequest(BaseModel): title: str category: str user_tier: str def extract_features(req: TicketRequest): # 复用和训练阶段完全相同的特征处理逻辑 from feature_utils import build_features return build_features([req]) @app.post("/predict") def predict(req: TicketRequest): try: features = extract_features(req) prob = model.predict_proba(features)[0][1] return {"probability": round(prob, 4), "prediction": int(prob > 0.5)} except Exception as e: raise HTTPException(status_code=500, detail=str(e))模型加载不要每次都重新读文件。模型加载是I/O密集操作，每次请求前加载一遍模型，QPS稍微上来接口就废了。应该用全局变量的方式，服务启动时加载一次，放在内存里复用。如果改了模型，做好热加载机制，比如定期检查模型目录的变更，平滑切换到新版本，而不是重启进程。
推理阶段还有两个必须注意的点。一是要根据线上qps情况做好限流和超时控制，保护下游存储。二是要记录每条请求的模型版本号、特征快照和预测结果。这些日志是之后分析数据漂移和模型衰落的唯一证据，没有这套日志，监控体系就是空中楼阁。
3. 一个最小可落地的AI工程化实例：客服工单智能分类
聊完理论，我完整的把一套最小的AI工程化实现走一遍，让大家看看实际落地长什么样。我选一个非常常见的场景：客服工单自动分类。背景：某电商平台，每天上万张客服工单，需要自动划分到“退款/物流/商品质量/账号问题”等类别，并判断是否紧急。模型不需要多复杂，用简单的文本分类模型就能演示工程骨架。
3.1 数据管道的搭建与特征设计
原始工单数据存放在数仓的tickets表，每天凌晨增量同步，包含工单ID、用户ID、标题、描述、渠道、创建时间、处理状态等字段。数据管道做的事情，是把这些原始数据清洗成训练可用的规范结构。
我分了三步。第一步是格式清洗，把字段缺失比例大于30%的列剔除；把标题和描述文本合并成单一文本字段，全角半角统一，去除噪声字符。第二步是标签建设，以最终客服的处理结果作为弱标签来源，例如退款成功的工单标记为“退款类”，但这套标签有噪声，必须清洗掉明显打错标签的样本，比如“物流”类别里实际讨论的是退款退货问题。第三步是切分，这里我强调按时间切分，前八周做训练集，后两周做测试集，因为线上永远是预测未来，按时间切分才能模拟真实场景。
特征设计的思路也比较朴素。一个是文本类特征，包括文本长度、常见关键词命中、分词后的TF-IDF向量；另一个是用户侧特征，包括用户历史工单数、用户会员等级、近期是否投诉过。特征做完之后，统一做归一化和编码，特征的数目保持在50个以内。这个阶段不需要堆特征，核心是建立稳定的特征处理流程，后面调优再慢慢加。
3.2 模型训练与离线评估
模型我选了LightGBM，文本向量部分用TF-IDF。工程化要点不是模型多高级，而是可复现。我把训练代码固定在一个train.py里，接收配置参数，超参数全部外置到config.yaml。跑一次训练，产出一个模型文件和一个实验记录JSON。
model: name: lgbm_ticket_cls params: objective: multiclass num_class: 4 learning_rate: 0.05 num_leaves: 31 max_depth: -1 n_estimators: 800 early_stopping_rounds: 50 data: dataset_version: ticket_train_v12 feature_version: feature_eng_v4 evaluation: metric: macro_f1 test_set: ticket_test_20250115离线评估的运行结果我要详细看。模型在测试集上macro F1是0.82，看起来不错。但我进一步看了每个类别的表现，“账号问题”类别的召回率只有0.61，明显偏低。看了bad case，发现账号类工单文本里经常包含“登录”“密码”“验证码”等词，但这些词在“退款”类里也大量出现，仅靠词频无法区分。这是个典型的特征表达不足问题，和模型本身关系不大。
针对这个问题，我补充了规则特征，比如工单是否包含“资金变动”“无法登录”等强特征词，同时把关键词命中次数也作为数值特征加进去。重新训练后，账号类的召回率提到了0.73，整体macro F1提升到0.85。这里我特别说明一下，如果一开始只盯着整体指标，这类问题根本发现不了。
3.3 模型服务化：从训练产物到线上服务
离线验证通过之后，进入部署环节。我用FastAPI搭建推理服务，模型文件放到artifacts目录，特征处理函数从feature_utils.py导入，训练和服务共用一份特征代码。这一点我在前面强调过，是保证离线在线一致性的关键。
服务写完之后，第一步先在本地起一个测试，用几个线上真实样本调用一遍，检查返回格式和特征处理是否正常。然后我写了一个简单的压测脚本，模拟200个并发请求，观察响应时间和错误率。第一次压测就发现了一个瓶颈：特征处理模块中对每一个请求都重复加载TF-IDF向量器，这是非常规耗时的操作。我把向量器和模型都改成了模块级全局加载，QPS从120涨到600，效果很显著。
import joblib class InferService: def __init__(self, base_dir: str): self.vectorizer = joblib.load(f"{base_dir}/vectorizer_v4.joblib") self.model = joblib.load(f"{base_dir}/model_v12.bin") self.required_features = [ "text_len", "title_len", "keyword_hits_refund", "keyword_hits_login", "user_tier_encoded", "history_ticket_cnt", # ... 其余特征名 ] def predict(self, raw: dict): feat = self._extract(raw) feat_vec = self.vectorizer.transform([feat["text_clean"]]) runtime_feat = [feat[name] for name in self.required_features] # 组装最终特征矩阵 x = hstack([runtime_feat, feat_vec]).tocsr() proba = self.model.predict_proba(x)[0] return proba, int(proba.argmax())服务上线后，我顺手接了一个基础的监控看板。监控的指标主要有三类：系统类指标（请求量、耗时、错误率）、输入漂移类指标（关键词命中分布、工单文本长度的滚动均值、缺失率）、业务类指标（各类别预测占比、紧急工单占比）。这三层监控缺一不可。系统类指标保证服务活着，输入漂移指标提示数据环境是否变化，业务类指标反映系统的实际输出是否符合预期。一旦出现异常，直接触发告警，由值班工程师介入处理。
3.4 把模型更新做成一个闭环
模型上线只是生命周期的一部分，更关键的环节是持续更新。我为这个系统设计了半自动的更新闭环：每七天一个更新周期，重新用最近的数据训练一个新模型，离线评估跑一遍回归测试集。如果新模型的加权代价指标优于线上模型至少3%，就自动生成发布申请，人工审核后灰度上线。如果指标没提升，保留线上模型继续运行，新模型打回实验库。
这里要特别提示一个我在实践中反复遇到的坑：更新训练数据时，一定要把“时间窗口”和“标签延迟”考虑清楚。客服工单的最终处理结果往往要等好几天才出来，如果只用最新一周的数据训练，标签还没完全沉淀，数据本身就是残缺的。我通常的做法是训练数据截止时间比当前时间提前三到五天，留出标签沉淀期。这个细节没有做过真实系统的人，很少会想到。
4. 工程落地的常见坑与排查实录
4.1 数据泄露：离线指标虚高的头号元凶
我接手过好几个“离线效果很好、线上效果惨不忍睹”的项目，八成都是数据泄露。最常见的泄露是：样本切分时没有做实体隔离。还是拿客服工单举例，同一个用户可能提过多张工单，训练集和测试集都包含这个用户的历史记录，用户的固定特征就成了模型的泄露信号。模型在训练阶段变相记住了用户，测试时当然表现好，但遇到新用户就彻底失灵。
排查方法其实不复杂。我一般会看特征重要性排序，如果某个用户ID类特征的贡献度异常高，就要高度怀疑泄露。另外还有一种隐蔽的时序泄露：特征处理的时候用到了未来的信息。比如用户历史工单数，如果计算这个特征时把当前工单本身也算进去了，那这个特征就包含了未来标签的信号。做特征工程时，一切基于“当前时间点之前已发生的数据”来构建。
4.2 离线在线特征不一致：线上效果崩盘的头号杀手
这个问题太常见了，以至于我每次都要专门拿出来强调一遍。训练阶段处理缺失值，用的是训练集的均值或中位数填充；在线推理的时候，如果也临时算当前请求的均值，那就不可能和训练分布对齐。还有，文本清洗函数在训练代码里用的是高级版本，部署代码用的是最初写的旧版本，两边文本向量化后维度都对不上。这些问题都不是模型问题，而是典型的“同一份逻辑在不同环境里分裂了”。
我的解决方案前面也提到过，概括成一句话就是：特征处理代码只维护一份，训练、验证、推理全走这个统一模块。任何特征变更，都必须同时跑一遍离线回归，确保离线在线全程同构。上线之后还可以做一段时间的shadow mode影子模式，把线上流量复制一份打到新模型上，对比新旧模型的预测差异，只有差异可控的情况下才允许全量切换。
4.3 模型版本管理混乱：复盘无从下手
模型文件以model_final_v2这个名字存储的团队，我见得太多了。这个文件之后又来一个model_final_v3_final，再来一个model_final_v3_really_final。这种命名方式直接抹掉了模型的所有背景信息，过一个星期你就记不清v2和v3到底谁优谁劣，两个模型分别用了什么数据。
我在前面提到的实验记录JSON就是对抗这种混乱的武器。每一个模型文件旁边，必须有一份记录文件。记录文件里至少包含模型训练时间、git commit号、数据集版本、超参数、测试集指标，以及模型哈希值。再往上一层，建立一个models/index.json，汇总所有模型的记录，标注出当前线上运行的模型ID。这样任何时候复盘，都能快速回答问题：线上跑的模型是用什么数据训的？它的版本历史是什么？
4.4 监控告警的经典误区
很多团队的监控告警只会看系统指标，CPU、内存、QPS，但预测类AI系统最需要监控的恰恰是预测分布的稳定性。我看过一个风控模型，线上运行三个月后预测的逾期概率分布整体上移，系统指标全部正常，但模型实际上已经开始失准。如果没有监控预测分布，这个问题至少要再过几周才会被用户投诉暴露出来。
我建议三个必监控的分布指标：预测分数的分位数（P50，P90，P99）、输入特征的均值与方差滚动窗口、每个类别的预测占比。这三项覆盖了模型变化、输入变化和输出变化三个视角。告警阈值也需要反复调优，太灵敏容易被噪音淹没，太迟钝就失去了预警意义。我个人会先跑两周基线，确定正常波动范围，然后以这个范围的三倍标准差作为初始阈值。
5. AI工程能力的进阶方向
如果前面这套从零搭建的骨架你已经走通了，后面就可以沿着几个方向逐步深入。第一个方向是特征平台化。随着特征数量增多、多个模型复用特征，把特征统一管理起来能大幅减少重复开发和一致性问题。第二个方向是自动化。自动重训、自动评估、自动灰度发布、自动回滚，把整个闭环做成一套标准化的流程，减少人工介入的不确定性。第三个方向是大模型应用的工程化。大模型有它特有的问题，上下文管理、检索增强、评测体系构建、输出稳定性控制，这些和传统模型工程化既有重叠又有很多新命题，值得单独梳理。
我自己从零搭完这套体系的最大感受是，AI项目失败很少是模型不行，而往往是工程体系不行。把工程基础打好之后，换模型、换算法、换框架都不再是伤筋动骨的事情。如果你发现自己也总在同一类问题上反复挣扎，不妨先退一步，把自己手里这套AI工程骨架画出来，看看哪一环还是空的。数据可追溯了吗？评估能防作弊吗？特征逻辑是单一来源吗？线上监控覆盖了预测分布吗？这四个问题回答清楚了，你的AI系统距离真正的“工程化”也就不远了。
