1. 拆解"ai-engineering-from-scratch"：AI工程到底学什么、怎么学
1.1 这个标题真正想说的话
先把这个标题放慢读一遍：ai-engineering-from-scratch。它一字排开，真正想表达的其实不是"我要做一个AI产品"，而是一个学习立场——把AI工程当成一门需要系统打基础、需要动手反复锤炼的学科。很多人觉得AI工程就是"调个接口、部署个模型"，这是最大的误解。真正做AI落地的人每天都在跟数据、评估、监控、版本、失败模式打交道，模型训练只是其中一小块。
所以这个从零开始的路径，我的理解是三层要求：第一，你要懂AI，起码要知道模型是怎么训练出来的，loss是什么，为什么同一个模型在不同数据分布下表现会崩；第二，你要有工程能力，代码结构、测试、部署、监控、复盘，一样都跑不掉；第三，你要有"从零"的耐心，不是直接抄一个开源的推荐系统，而是把整条链路手搓一遍，哪怕做得很丑，也要理解每个环节为什么存在。我会围绕这三层展开，并把"ai-engineering"这个关键词落在一个具体可复制的项目上。
1.2 AI工程师不是半个算法工程师
我见过太多背景各异的同学进入这个领域，有人从纯后端转过来，有人从数据分析转过来，也有人在校期间只跑过MNIST。他们最容易犯的错，是把自己定位成"算法工程师的廉价平替"。实际上AI工程的能力画像和算法研究差得很远。我用一张表把这几个角色拆开看：
| 维度 | 数据工程师 | 算法工程师 | AI工程师（工程化主线） |
|---|---|---|---|
| 核心产出 | 可靠的数据管道 | 高精度的模型权重 | 稳定运行的AI系统 |
| 关注指标 | 数据时效、完整性、成本 | 离线指标Acc、F1、AUC | 在线指标、延迟、可用率、回滚效率 |
| 主要工具 | SQL、Spark、Airflow | PyTorch、实验框架 | Docker、K8s、模型仓库、监控系统 |
| 典型痛点 | 数据怎么按时到 | 效果怎么涨上去 | 模型上线后为什么没人用/出了问题怎么查 |
这张表不是说AI工程师不需要算法知识，而是说算法只是上游的输入之一。一个正经AI工程项目的生命周期，包括业务问题定义、数据获取与清洗、特征分析、模型训练、离线评估、上线部署、灰度放量、线上监控、数据回流、模型迭代，这十步里有七步都发生在模型训练之外。你把GPT的接口接得再好，如果不知道输入日志该记什么、不知道效果下降时如何快速定位是数据变了还是模型变了，那依然谈不上AI工程。
2. 先别急着碰大模型：AI系统与软件工程的分岔点
2.1 从"确定性逻辑"走向"概率性逻辑"
我在带新人时，第一周不会让他碰任何模型代码，而是先花两天讲清楚一个问题：AI系统到底和传统软件有什么本质不同。传统软件里，if-else、数据库事务、接口签名，这些逻辑在相同输入下永远给出相同输出；你可以用单元测试把行为锁死。而AI系统里，输入经过一个非线性模型，做的是概率预测，同样的输入可能因为上游特征缺失、数据分布变化、模型版本不同，输出完全不一样。
这个差别带来的连锁反应非常大。传统软件的错误可以被精确定位到某一行代码，AI系统的错误往往是"系统性的、模糊的、需要统计证据的"。比如推荐系统点击率下降5%，你不能说是哪一行代码出错了，你只能说：数据特征分布偏移、新用户群体变化、最近排序模型的某个loss项权重调得不对，这些可能性同时存在。这就意味着，AI工程的调试方式和传统工程完全不同，你需要实验、基线、对比、日志、可解释性工具，而不是打印堆栈。
2.2 反馈回路：模型会改变它自己的输入
软件系统的逻辑是单向的：用户请求进入，系统处理，任务结束。AI系统不一样，模型上线后会直接影响用户行为，再通过新产生的数据影响下一轮训练。我举个最简单的例子：一个预测用户点击概率的模型上线后，系统会倾向把某些内容推给用户，用户的行为数据又变成下一天的训练样本。如果模型有偏，这个偏误会被自己的输出持续放大，这在系统设计上叫闭环反馈。
这也是为什么AI工程里永远要保留"随机性"和"探索"。你必须在推荐策略里放进一部分随机流量，否则你永远看不到模型没推荐的候选在真实世界中表现如何。很多人觉得这就是个参数问题，实际上它是工程架构问题：探索流量怎么分配、实验版本怎么切分、埋点能不能支撑归因分析，这都得在系统设计阶段就定下来。
2.3 所以"从零开始"到底要学哪些地基
把上面两个差异想透之后，你会发现真正要学的不是某个框架，而是一整套配套能力。我把它列成四个地基：
- 数据管理能力：版本化数据集、数据质量检查、训练/验证/测试切分的口径、数据漂移的感知；
- 实验管理能力：怎么把一次训练的参数、代码、数据、评估结果完整记录下来，保证三个人合作时能复现；
- 推理与部署能力：模型加载、并发处理、延迟优化、批处理策略、失败降级；
- 监控与迭代能力：线上指标追踪、输入特征统计、异常报警、一键回滚。
这四个地基贯穿一位AI工程师实际工作的每一天。你会发现它们都是一些"不酷"的东西，但恰恰是这些不酷的东西决定了系统能不能长期跑在生产环境里。很多从零开始的人一上来就学Transformer架构、梯度推导，结果做了两轮demo之后还是不知道线上模型出了故障该从哪查起。
3. 用新闻短文本多分类把这个流程完整跑一遍
自觉光讲理论没有用，我把一个最典型的AI工程项目拆给你看。项目很小，但五脏俱全：用中文新闻标题做多分类，把数据、训练、评估、上线、监控整条链路走通。这个项目非常适合作为ai-engineering-from-scratch的起点，因为它数据易得、模型不大、问题边界清晰，但工程环节一样不少。
3.1 数据准备与版本化
我用了一个公开的中文新闻标题数据集，包含财经、体育、娱乐、科技、健康等十几个类别。拿到数据后的第一个动作不是训练，而是检查质量和分布。我一般先跑这样一段代码：
import pandas as pd df = pd.read_csv("news_title_dataset.csv") print(df.shape) print(df["label"].value_counts()) # 基础质量检查 print("空标题数量:", df["title"].isna().sum()) print("空标签数量:", df["label"].isna().sum()) # 按标签统计长度异常样本 df["title_len"] = df["title"].str.len() print(df.groupby("label")["title_len"].describe())这一步的价值在于：你会在真正训练前就发现脏数据。比如你可能发现某个类别只有几十条样本，或者标题里混进了大量表情符号，又或者是同一类新闻被标成了两个近似标签。处理完这些之后，一定要做数据版本化。哪怕只是把处理好的文件加上日期和commit号存到对象存储里，也比几个月后找不到"当时到底是哪份数据训的这个模型"要强得多。我在团队里吃过这个亏，所以现在每次训练我都会记录一份data_manifest.json，里面写清楚数据来源、清洗规则、切分比例和生成时间。
3.2 训练脚本的骨架
数据准备好了，我用预训练语言模型来做迁移学习。新手常有个误区，觉得必须自己从零训练一个大模型才叫AI；实际上工程上绝大多数场景都是站在预训练模型肩膀上，把精力花在数据、评估和上线这些环节上。核心训练脚本骨架大致长这样：
from datasets import Dataset from transformers import ( AutoTokenizer, AutoModelForSequenceClassification, Trainer, TrainingArguments, ) model_name = "bert-base-chinese" tokenizer = AutoTokenizer.from_pretrained(model_name) def tokenize_fn(batch): return tokenizer( batch["title"], truncation=True, padding="max_length", max_length=64, ) train_dataset = Dataset.from_pandas(train_df).map(tokenize_fn, batched=True) valid_dataset = Dataset.from_pandas(valid_df).map(tokenize_fn, batched=True) training_args = TrainingArguments( output_dir="./news_cls_checkpoints", evaluation_strategy="epoch", save_strategy="epoch", learning_rate=2e-5, per_device_train_batch_size=32, num_train_epochs=3, logging_dir="./logs", load_best_model_at_end=True, metric_for_best_model="f1", ) trainer = Trainer( model=AutoModelForSequenceClassification.from_pretrained( model_name, num_labels=len(label_list) ), args=training_args, train_dataset=train_dataset, eval_dataset=valid_dataset, compute_metrics=compute_metrics, ) trainer.train()这里我想让你注意的细节是：metric_for_best_model我选了"f1"而不是"accuracy"。原因很简单，新闻分类的类别不完全均衡，准确率看似很高，但小类别的表现可能很差。工程上选模型不能只看一个总分，必须结合业务场景看，有些类别错了代价很大，那在评估阶段就要把这种代价体现进去。
3.3 评估不只有一个准确率
很多初学者拿准确率当唯一标准，这是错的。我跑完上面的训练之后，一定会做三件事：
- 打印每个类别的precision、recall、f1，而不只看总体准确率；
- 画混淆矩阵，找出哪些类别互相容易混（比如"娱乐"和"体育"里涉及明星和比赛的内容）；
- 挑出模型预测结果置信度最低的200个样本，人工看一遍，判断是标注错了还是模型能力不足。
第一个容易理解，第二个和第三个往往更关键。看低置信度样本，能直接告诉你数据里有没有误标、类别定义是否清晰、特征够不够。我曾经在一个项目里发现模型经常把"游戏"分类成"科技"，一查原始数据发现大量标题写得就是"科技改变游戏产业"，这种边界样本需要在标签定义层面解决，靠继续调参很难根除。所以项目里我建议每个人都保留一个error analysis的代码块，每次训练完自动导出错分样本，方便小组讨论。
如果你只做离线评估，没做这三件事，这个模型根本不敢上线。因为离线分数再高，你也说不清它会在哪些输入上崩，而这种不确定性正是AI工程风险的来源。
3.4 部署成HTTP服务，跑通最小上线流程
模型训好之后，下一步是部署。我用FastAPI搭一个最小推理服务，原因很朴素：生态成熟、异步支持好、和Pydantic结合后做参数校验非常顺手。典型代码：
from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class NewsTitle(BaseModel): title: str class Prediction(BaseModel): label: str score: float probabilities: dict def load_serving_model(): # 加载训练好的权重，和训练时使用同一个tokenizer后处理逻辑 model = AutoModelForSequenceClassification.from_pretrained("./best_model") model.eval() return model serving_model = load_serving_model() @app.post("/predict") def predict(item: NewsTitle): inputs = tokenizer( item.title, truncation=True, padding="max_length", max_length=64, return_tensors="pt", ) with torch.no_grad(): logits = serving_model(**inputs).logits probs = torch.softmax(logits, dim=-1).tolist()[0] idx = max(range(len(probs)), key=lambda i: probs[i]) return Prediction( label=label_list[idx], score=probs[idx], probabilities={label_list[i]: round(probs[i], 5) for i in range(len(probs))}, )部署之后不要高兴得太早，还得做压力测试。我自己的经验是，用最简单的方式先压一下：模拟100个并发请求，记录P99延迟、内存占用、GPU是否够用。如果P99超过200ms，就要考虑换更小的模型、加缓存、做batch推理。这个压测环节是你评估"模型真的能上线吗"的第一步。别急着上K8s，先把单机压测跑明白，搞清楚瓶颈在模型计算还是网络IO，再谈架构扩展。
3.5 最小监控回路：从日志到再训练
服务上线后，工程闭环还差最后一步：监控。我的最小方案是先落两类日志：一类是请求日志，记录标题、预测类别、置信度、耗时；另一类是特征统计日志，记录每个请求的标题长度、文本中有没有特殊字符等统计量。每周跑一个任务对比本周和上周的置信度分布、类别分布和标题长度分布，一旦发现明显偏移就报警。
这就是一个非常朴素的漂移检测雏形。你不需要一开始就上全职监控平台，先把日志存下来、把统计跑起来，这些数据会成为你下一轮训练和优化的依据。很多项目死在"模型上线那天就是项目终点"，而没有设计"模型越用越准"的闭环，这个毛病从做第一个项目时就要修正过来。
4. 数据、指标、漂移：从零到一真正难啃的骨头
4.1 数据质量决定模型天花板
模型练得再好，数据本身是脏的，效果上限就摆在那里。工程上说"garbage in, garbage out"，这句话在AI系统里被放大得更厉害，因为模型会主动从错误中学习规律。我处理过最典型的例子是标签体系前后不一致：同一个业务线的数据，早期标注人员在"价格"和"营销"两个标签上理解不同，导致同一类样本被拆成两类。这种问题不会直接降低准确率很多，但会让你后续分析永远带着一个说不清的噪声源。
所以从零开始的项目里，应该在数据准备阶段就建立一份"数据契约"：每个字段的含义、取值空间、缺失值策略、标签定义的例子和反例。这份契约不一定要写成很重的文档，但要写成一个可以自动校验的schema，比如用pandera这样的库在数据管道入口做检查。宁可让管道在数据异常时跑失败，也不要让脏数据悄悄流过整条链路。
4.2 离线指标和在线指标的鸿沟
训练时我们看准确率、F1，上线后产品经理关心的是用户留存、点击率、转化率。这两类指标经常不一致，因为离线数据集是静态的历史切片，而线上数据是实时变化的，还有各种选择偏差。我举一个例子：你训练了一个"标题是否吸引点击"的模型，离线测试准确率很高，上线后发现点击率反而下降，因为线上的内容分布和训练集差异巨大，而且推荐系统本身已经过滤了最受欢迎的标题，实际到模型手里的都是"难啃的骨头"。
缩短这个鸿沟的方法主要有三个：
- 从业务指标反推评估口径，离线评估时尽量构造与线上分布一致的评价集；
- 做A/B实验时，把模型输出和当前线上策略并存一段时间，用分流的办法度量真实增益；
- 定期从线上回流困难样本，人工标注后加入训练集，让模型不断适应新分布。
这三种方法都不炫酷，但它们才是AI工程里"效果"和"收益"之间的桥梁。做一个真正能赚钱的AI系统，靠的往往不是某个灵光一现的模型结构，而是这一步步缩小离线与在线差距的迭代功夫。
4.3 漂移监控到底监控什么
漂移这个词听起来抽象，落到代码上其实就是两组统计分布的比较。你可以用KL散度、PSI或者更简单的"分布窗口对比"来判断。工程上不要纠结用哪个统计量，先跑起来再说。我常用的最小实现是：每天记录线上预测类别的频次和平均置信度，存到一个表里，然后用最近7天做基准窗口，计算当天的分布和基准窗口的距离。
如果类别分布明显变了，通常说明两种可能：一是用户的输入内容真的变了，比如新闻热点切换导致类别偏移；二是模型本身出问题了，比如上游某个特征构建服务挂了，把所有文本都变成了空字符串。这两种情况的处理方式完全不同，前者可能需要重新训练，后者需要紧急修复特征管道。所以你在设计监控指标时，一定同时监控模型的"输入特征统计"和"输出分布统计"，只看输出不看输入，遇到问题会无法定位。这是一条我从真实事故里学到的教训，后面会展开讲。
5. AI工程入门最常见的五个认知误区
5.1 把"调参跑分"当成了AI工程
很多初学者把时间都花在调learning rate、换backbone、刷榜单分数上，认为AI工程的核心就是模型效果。但真实项目里，效果只是链条中的一环。我的建议是，第一次跑新闻分类项目时，不要超过两天就停止调参，赶紧进入上线流程。因为调参的边际收益递减得很快，而数据质量、评估口径、部署稳定性带来的收益却大得多。
5.2 以为"调一个API"就是完成了AI系统
现在有很多现成的大模型接口，一行请求就能得到结果。但这不等于你会AI工程。AI工程的难点在于，真实场景的输入千奇百怪、成本约束、延迟约束、失败处理、隐私合规，这些都不在API调用层。你至少应该亲手做一次微调、部署和监控，才知道那些现成的接口背后省略了什么。
5.3 上线前没设计失败模式
传统软件也有bug，但AI系统多了一种独有的失败：它不是崩溃，而是"静静地返回一个错误答案"。所以你需要为低置信度结果设计兜底策略，为模型接口超时设计降级逻辑，为上游特征缺失设计默认填充。我自己的项目里会专门用一个断言列表把失败场景列清楚，比如"当置信度低于0.5时不允许进入自动决策流程"。这个习惯越早养成，后面踩的坑越少。
5.4 用传统软件的测试思路测试AI系统
传统软件可以枚举输入输出做断言，AI系统做不到这个，它的行为空间太大了。AI测试更接近于"用统计指标约束行为边界"，比如：测试集上每个类别的最低recall不能低于0.75、置信度校准误差不能超过某个阈值、恶意或异常输入必须触发拒答。我建议每个AI项目都单独维护一份"行为风控清单"，把安全约束写在上面，并在CI流程里加入自动化评测任务。这个观点很多教科书不会写，但生产环境的可靠性恰恰从这里来。
5.5 忽略人机反馈闭环
模型部署不是终点，而是学习曲线的起点。真实用户的使用反馈、客服收到的投诉、运营发现的badcase，这些都是最便宜的标注数据。我见过很多团队把模型部署上线之后就不管了，等到三个月后业务变差才开始救火。正确的做法是从第一天就建立bad case回流渠道，每周固定抽出时间分析和标注，形成"线上数据被采集、被标注、被训练、再上线"的循环。AI系统真正值钱的能力，就是在这个循环里长出来的。
6. 二十周从零到一项目主线怎么排
如果按照ai-engineering-from-scratch的思路给自己规划一条学习路径，我会把它切成三个阶段，每个阶段都要交付一个可运行的东西，而不是"看完某本书"。
6.1 第一阶段：基础设施与数据管道（1-6周）
这个阶段只做一件事：把数据从原始状态变成可以稳定喂养给模型的格式。学习目标包括Python数据处理、SQL、Airflow/Prefect这类编排工具、数据质量校验、数据集版本管理。项目交付物很简单：一个能每天自动从数据源拉取新闻标题、清洗、校验并产出训练集的管道。别小看这个阶段，未来你80%的调试时间都会花在数据管道上。
6.2 第二阶段：模型训练与评估工程化（7-13周）
这个阶段开始碰模型。学习目标包括：用Transformers库微调一个预训练模型、建立实验追踪（比如用MLflow记录每次训练的指标和超参数）、构建离线评估报告。项目交付物是一个带完整评估报告的新闻分类模型。这里要刻意练习的不是训练本身，而是实验的组织方式。
6.3 第三阶段：交付与迭代闭环（14-20周）
这个阶段把模型做成真正的服务。学习目标包括Docker容器化、FastAPI服务编写、单机压测、日志规范、漂移检测脚本、badcase回流标注流程。项目交付物是完整可演示的在线服务，以及一份"如果模型效果下降，我能在24小时内定位原因"的操作手册。
以下是我建议的每周重心分布参考：
| 周次 | 每周核心任务 | 关键交付物 |
|---|---|---|
| 1-3 | Python工程化、Git规范、数据探索 | 可复现的探索性分析脚本 |
| 4-6 | 数据清洗管道与质量校验 | 自动化的数据管道+数据契约 |
| 7-9 | 预训练模型微调基础 | 第一个有效模型checkpoint |
| 10-11 | 评估体系、误差分析 | 类别级评估报告 |
| 12-13 | 实验追踪与模型版本管理 | 可追溯的模型档案 |
| 14-16 | 服务化部署与压测 | 可调用的HTTP推理服务 |
| 17-18 | 监控指标与异常报警 | 漂移检测脚本+监控看板 |
| 19-20 | 全链路复盘与文档沉淀 | 一个完整可演示的AI工程项目 |
你会发现这个路径里没有一个环节叫"把准确率刷到最高"。因为从零开始的AI工程，真正要建立的是"在约束条件下交付可用系统"的全局能力，而不是单点技术指标的巅峰。
7. 文档之外的一些真实体会
最后，想写一点不太会出现在roadmap里的东西。从零开始接触AI工程，最容易产生挫败感的时刻不是模型训练不出来，而是训练出来了却不知道下一步干嘛。我把这个状态叫做"demo瘫痪"——你手里有一个看起来还行的模型，但距离一个能持续迭代的产品还差很远。
我个人的体会是，别去追求完美，先做一件最丑的端到端闭环。模型可以只有80分，服务可以只有单机部署，监控可以只是跑脚本看日志，但只要数据、训练、评估、部署、监控、回流这个循环转起来了，你后续每加一块能力都是在一个真实系统上叠加，而不是在真空里练功夫。这比看完十遍教程有用得多。
还有一件我踩过不止一次的事：日志没记全。早先我在一个文本审核项目里，上线后效果突然下降查了三天毫无线索，最后发现是上游特征服务在某天开始静默地把异常输入替换成了空字符串。因为我没有记录特征侧的统计量，根本没法判断数据是从哪一环开始坏掉的。从那以后，所有AI项目的日志规范我都坚持一条原则：模型输入侧的原始特征、模型输出的概率分布，必须同时落盘。这个习惯，真的能救命。
如果你也在沿着ai-engineering-from-scratch这条路线走，我的建议是：别迷信一次性的系统学习，也别迷信某个热门框架。找一个真实的小场景，把整条链路亲手搭一遍，记录下每一次故障和修复，然后让这个系统陪你迭代上三个月。那个时候你再回头看，你已经不是一个"会跑模型"的人，而是一个真的在"做AI工程"的人。
)
